[Mimedefang] Rejecting forged senders - comments?

[Jan-Pieter Cornet]

On Wed, Sep 20, 2006 at 06:51:10AM -0700, John Rudd wrote:
> >>1) to reject based on the content of the HELO string is an RFC violation
> >This is a blatant and oft-repeated lie. Section 4.1.4 in RFC2821 contains
> 
>   An SMTP server MAY verify that the domain name parameter in the EHLO
>   command actually corresponds to the IP address of the client.
>   However, the server MUST NOT refuse to accept a message for this
>   reason if the verification fails: the information about verification
>   failure is for logging and tracing only.
> 
> You MUST NOT reject based on the presence of bogus host information in 
> the HELO/EHLO command.

No, those last two lines are your words. Please read what it says,
literally (esp: "for this reason if the verification fails").

To give an example:

IF a host says:
    "EHLO friend", you're free to drop it right there (not a FQDN).
    "EHLO 1.2.3.4", you're free to drop it (invalid format).
    "EHLO [128.129.130.131]", where 128.129.130.131 is your IP,
                              you are free to drop it (loop prevention)
    "EHLO your.hostname.example.tld", (giving actually your hostname),
                      you are free to drop it (again, loop prevention).
    "EHLO gslb2-dr6-sw0.net.aol.com", but the connection comes from
          62.150.82.34, _THEN_ you are, according to this RFC,
	  not allowed to reject it, because of an IP mismatch in
	  otherwise valid fields. (You can still drop it because
	  it's listed in the CBL, however).

However, completely contrary to the point I'm trying to make, in
dealing with spammers, I wouldn't really follow the RFCs down to the
last letter anyway ("they started it!" :)

For example, according to the RFCs, when you say "OK" to a HELO or
"MAIL From", you cannot come back on that later. But that's precisely
what I do now, because some things aren't checked until "RCPT To" time,
because they differ per recipient. Some recipients don't like certain
sender domains, or HELO patterns, but others do. This is done so
abuse@ and postmaster@ can be forgiving for certain errors.

On the gripping hand, _every_ spam countermeasure so far that we've
introduced, has resulted in false positives, even if just a few. There
are always well-meaning idiots using really really broken and outdated
setups, that get caught up in the cracks.

In the end, I just do what I think is right, carefully reading the RFCs
and my logfiles, but taking neither as gospel.

-- 
Jan-Pieter Cornet <johnpc at xs4all.nl>
!! Disclamer: The addressee of this email is not the intended recipient. !!
!! This is only a test of the echelon and data retention systems. Please !!
!! archive this message indefinitely to allow verification of the logs.  !!