Edgar asked me to forward this to the list, since he forgot to CC it in.
-----Original Message-----
From: Edgar Lovecraft [
mailto:exim-list@cox.net]
Sent: Tuesday, June 15, 2004 1:48 PM
To: David Brodbeck
Subject: RE: [Exim] AOL - SPF - and EXIM
David Brodbeck wrote:
>
> > -----Original Message-----
> > From: Edgar Lovecraft [mailto:exim-list@cox.net]
>
> > It does provide usefull information. It provides usefull information
> > for that stage of the SMTP transaction. A proper HELO/EHLO string
> > allows the 'system' to be 'verified' as actually being the host they
> > say they are.
>
> True, but this is *only* useful for a human trying to trace things out
> later, anyway.
No, automated systems can track things on their own just as well.
> RFC2821 doesn't allow for rejecting mail just because
> the IP does not verify.
Only if you accept the HELO command in the first place, It says nothing
about rejecting the HELO command because of verification failures.
Please note that both the 2821 "Standards Track", and the official
1123 specificatons only say that the server must not refuse to accept
a message if verificaition fails, neither say that the connection
can not be terminated, nor do either say that the HELO/EHLO
command must be considered acceptable when verification fails.
Both allow the server to send a 5xx error when the HELO/EHLO
command is not acceptable, that is, not acceptable for any
reason, there is no definition of what 'acceptable' has to be,
nor should there be. If I decide that everything that HELO/EHLO's
me has to send the string "You.The.Boss" or it is not acceptable,
then I can do so. The RFC's never say that I cannot refuse to
accept an unverified HELO/EHLO command, only that I should not
refuse to accept a message AFTER I have OK'd the HELO/EHLO string.
That is a big difference, and exactly what Greg has been pointing out.
--
--EAL--
<RFC 2821 "Standards Track">
4.1.4 Order of Commands
If the EHLO command is not acceptable to the SMTP server, 501, 500,
or 502 failure replies MUST be returned as appropriate. The SMTP
server MUST stay in the same state after transmitting these replies
that it was in before the EHLO was received.
The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a valid principal host name (not a CNAME or MX
name) for its host. If this is not possible (e.g., when the client's
address is dynamically assigned and the client does not have an
obvious name), an address literal SHOULD be substituted for the
domain name and supplemental information provided that will assist in
identifying the client.
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.
</RFC 2821 "Standards Track">
<RFC 1123 "Official Specification">
5.2.5 HELO Command: RFC-821 Section 3.5
The sender-SMTP MUST ensure that the <domain> parameter in a
HELO command is a valid principal host domain name for the
client host. As a result, the receiver-SMTP will not have to
perform MX resolution on this name in order to validate the
HELO parameter.
The HELO receiver MAY verify that the HELO parameter really
corresponds to the IP address of the sender. However, the
receiver MUST NOT refuse to accept a message, even if the
sender's HELO command fails verification.
DISCUSSION:
Verifying the HELO parameter requires a domain name lookup
and may therefore take considerable time. An alternative
tool for tracking bogus mail sources is suggested below
(see "DATA Command").
Note also that the HELO argument is still required to have
valid <domain> syntax, since it will appear in a Received:
line; otherwise, a 501 error is to be sent.
IMPLEMENTATION:
When HELO parameter validation fails, a suggested
procedure is to insert a note about the unknown
authenticity of the sender into the message header (e.g.,
in the "Received:" line).
</RFC 1123 "Official Specification">
