[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [FW1] NULL "Mail From:<>" headers...



    [ The following text is in the "iso-8859-1" character set. ]
    [ Your display is set for the "US-ASCII" character set.  ]
    [ Some characters may be displayed incorrectly. ]


OooooK!!!..   :)

This is how my setup looks like:

(rule A) smtp->resource accept

The SMTP resource checks as follows:

From: *
Rcpt: *@mydomain.dom

This is the only inbound SMTP mail it should accept... all others should be
dropped.. and it does WORK..

However, if you specify a NULL From: field, the SMTP security server relays
the message!!!.. here is  an excerpt from transmission:

---begin excerpt---
Escape character is '^]'.
220 Secure SMTP Gateway.  Authorized Users ONLY!!!  Violators will be
prosecuted to fullest extent of the law.
helo
250 Hello
mail from:<>
250 <>... Sender ok
rcpt to:<someone@somewhere.com>
250 <someone@somewhere.c... Recipient ok
data
354 Enter mail, end with "." on a line by itself
Subject: Null mail!!!..woohooo...

Yep.. still relaying SMTP mail with null From: field with
a recepient somewhere outside...

.
250 Ok
---end excerpt---

...hehehehehe..  I should also mention the config:

Windows NT 4.0 (SP4)
FireWall-1 4.0 (SP2) (vpn+des+strong)
{ 
 doing HIDE and STATIC mode NAT for internal networks/devices...
 Using FireWall-1's SMTP security server...
}

I have tried the following:

- BLANK in the From: field
- *@* in the From: field
- *@*.* in the From: field
- * in the From: field

so... question remains... how does one check for a NULL From: field?
Or is this a bug?



Amin Tora, Internet Engineer
ICN - Internet Solutions Group
Phone: (703) 550 - 0101 x514
Fax:     (703) 550 - 7697
mailto://amint@icn.com
http://www.icn.com



-----Original Message-----
From: Daniel J Blander - Director of Technical Services for ACS
[mailto:Daniel.Blander@ACSacs.Com]
Sent: Thursday, April 01, 1999 1:14 AM
To: Amin Tora
Subject: RE: [FW1] NULL "Mail From:<>" headers...



Given a personal interpretation, no it would not be breaking the RFC.
Your mail server is not for the use of the public and the RFC does
not demand it - only that you allow <>'s in for the purpose of allowing
error notifications to arrive....(if they're not for you its not your
problem right??) ;-)

I would try using the string:

 <>

Since that is often how the mailer will pass it to the next host.
Start from that assumption....

On Wed, 31 Mar 1999, Amin Tora wrote:

> 
> Alrighty people... here is what ORBS has to say about denying NULL From:
> fields:
> 
>  ==start excerpt==
> > This directly states that I should not implement step three of
> > your "checks" against my SMTP gateway (eliminating the null
> > email from), as it can cause more problems than it solves for
> > our users.
> 
> Not quite. All the SMTP checks should be aimed at preventing
> relaying, not to reject senders outright. Even an external null
> sender has no reason to relay via your server to another server
> unrelated to your operation and should be denied access if this is
> attempted.
>  ==end excerpt==
> 
> Basically, they want you to deny any mail with null From: fields relaying
> via your SMTP server to a domain not belonging to you.  However, if the
mail
> with the null From: field is directed to your domain, then you can still
> allow it.
> 
> My question here is, by following the above recommended deny and allow
> scenario, will a secure SMTP gateway be "violating" the RFC ?
> 
> Next question that remains unanswered is: 
> How do I check for the null From: fields..  if I am to implement the above
> deny and allow rules...??  
> 
> I tried  *@*  and it doesn't work!... 
> 
> .peace.
> 
> 
> Amin Tora, Internet Engineer
> ICN - Internet Solutions Group
> Phone: (703) 550 - 0101 x514
> Fax:     (703) 550 - 7697
> mailto://amint@icn.com
> http://www.icn.com
> 
 


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================