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

[sirving@ca.ibm.com]

If you are getting what you say below and icn.com is not the equivalent of
your myclientdomain you mention below then you have not setup something
right on the firewall.  I just tested this and the reply you should get
back (even with a null from) is a 554 Mailbox unavailable.



Amin Tora <AminT@icn.com> on 04/01/99 09:53:01 AM

Please respond to Amin Tora <AminT@icn.com>

To:   "FW-1-MailingList (E-mail)"
      <fw-1-mailinglist@lists.us.checkpoint.com>
cc:    (bcc: Stuart Irving/Markham/IBM)
Subject:  RE: [FW1] NULL "Mail From:<>" headers...






Appreciate your input.. however I am doing what you have recommended...
Checking the RCPT TO: fields for  *@myclientsdomain

however, it still allows me to relay mail with null FROM: fields...

as follows:

---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:<amint@icn.com>
250 <amint@icn.com>... Recipient ok
data
354 Enter mail, end with "." on a line by itself
Subject:NULL mail...

null mail!!..works....hmmm....

.
250 Ok
---end excerpt---

NOTE: icn.com is not my client's domain...

.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



-----Original Message-----
From: Paul D. Robertson [mailto:proberts@clark.net]
Sent: Thursday, April 01, 1999 9:01 AM
To: Amin Tora
Cc: FW-1-MailingList (E-mail)
Subject: RE: [FW1] NULL "Mail From:<>" headers...



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 ?

This is fine.  Denying 3rd party relaying is perfectly acceptable, no
matter

what the from address (null, bozo@theclown.org,
president@whitehouse.gov, proberts@clark.net....).  Relaying in SMTP is
based on who the message is to, not who it's from, so I'm not sure that
you're not taking the long way around this?

> 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!...

Shouldn't you be checking the rcpt to:<> field(s) to find out if it is a
local user, and denying the mail if it isn't?  That would solve all cases
of

relay abuse, place no burden on anyone not trying to relay mail to third
parties, and keep everyone happy.

Don't forget that SMTP allows multiple RCPT TO:<>'s in a single
conversation when you're testing.  Any RCPT TO: that isn't in your domain
should be rejected.  Rejecting with a 4xx error will make it possible to
live through DNS failures, with a 5xx will make most of the spammers go
away.

Also, don't forget that mail should be accepted to the canonical address
of the mail exchanger record in square brackets.  So if my.mail.gateway
has an IP address of 10.0.0.1, then I should accept mail to
<user>@my.mail.gateway, <user>@[10.0.0.1], and any other instances
necessary.  At the very least, you should do this for <user> ==
postmaster.  It's very frustrating to try to report brokeness to a site
where you can't get mail to the person who should be able to fix it
because their gateway is rejecting mail due to a configuration problem,
*especially* if it's a DNS problem and all the contacts have addresses in
the same domain.

Paul
---------------------------------------------------------------------------
-
-
Paul D. Robertson      "My statements in this message are personal opinions
proberts@clark.net      which may have no basis whatsoever in fact."

PSB#9280



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


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






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