OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: HELO is CNAME -> reject ??
From: Bodo Moeller (bmcdc.informatik.tu-darmstadt.de)
Date: Wed Apr 12 2000 - 05:41:15 CDT

On Tue, Apr 11, 2000 at 12:38:49PM -0400, Greg A. Woods wrote:
> [ On Tuesday, April 11, 2000 at 13:59:58 (+0200), Bodo Moeller wrote: ]

>> Subject: Re: HELO is CNAME -> reject ??

>> It's not a contradiction, it's the old principle "Be liberal in what
>> you accept, and conservative in what you send" (see, e.g., section 2.9
>> of RFC 2360 [= BCP 22]).

> It *IS* a contradiction (i.e. that which is in RFC 1123 5.2.5).

Not a contradiction in the mathematical sense of that word.
RFC 1123 section 5.2.5, 2nd paragraph, specifies the recipient's
behaviour for a case that can never happen if the sender's software
and operator obey the first paragraph of the very same section [1].
Call that paragraph redundant, but it's not a contradiction.
("Let p = 11. If p is even, then p is not prime" is not a
contradiction either.)

> The robustness principle has *nothing* to do with matters of policy or
> security.

Of course everyone may elect to reject mail that should be accepted
according to RFC 1123. If you think that verifying HELO messages
provides good heuristics for detecting spam messages, then go for it;
similarly, it may make sense to reject messages when a RCPT TO:
address is sent all in upper case, when the Date header looks bad,
or when the message body contains more exclamation points than full
stops, or if there are illegal 8-bit characters in the header or
in the message body. (Many spam messages that reach me fulfil
at least one of these criteria.)

[1] Because of DNS TTLs, the first paragraph dictates a complicated
     procedur for host renaming for IP adresses from which SMTP mail is
     sent: First, add the new name and keep the old A and PTR records.
     Then, determine when the secondary DNS servers have obtained the
     updated zone files. Then, after the TTL for the old data has
     expired, the mail server finally may use the new host
     identification in its HELO messages; at this point, after
     waiting a couple of minutes for any pending HELO verifications
     by remote hosts, the old host name may finally be removed from
     the zone files. I doubt this is often done correctly.