At 11:18 AM 1/29/2009 -0500, John C Klensin wrote:
5321 rather carefully explains
what is valid and what is not. To be valid under 5321, it must
meet the syntax rules for either a Domain or for an address
literal. If it looks like a Domain, it must be a resolvable
FQDN. The server is also encouraged to check the relationship
between the EHLO argument and whatever else it knows about the
sending machine (particularly its IP address from the
connection) but told that it must not reject the mail simply
because whatever tests it applies at that level fails. That
doesn't somehow make the argument "valid" or "invalid" as far as
5321 is concerned, it just means that an optional test failed,
one whose results the server is prohibited from using to reject
the message.
This is too broad. The "whatever tests" could include a CSV test on the
heloname.
If the intention of the text was to say "the argument to EHLO is
noise and you can ignore it", that certainly could have been
said, and probably should have been. The following are all
perfectly valid decisions under 5321 as written:
* Rejecting the EHLO command and message because the
argument does not follow the syntax rules.
* Rejecting the EHLO command and message because the
apparent FQDN in the argument does not resolve at all in
the public DNS.
* Noticing that the EHLO argument does not resolve to
the address obtained from the connection, writing a
private-use header into the message that records that
fact, and then forwarding/delivering the message anyway.
* Noticing that the EHLO argument does not resolve to
the address obtained from the connection, delivering the
message anyway, but delivering it to a folder different
from the one that would normally be used for incoming
messages associated with the RCPT command address.
If others disagree with that interpretation, we should discuss
it. If people believe that the text needs further
clarification, I'd welcome suggested text modifications.
This sounds a lot better than previous discussions. The RFC says "corresponds
to". I see you are using "resolves to" in the examples above, which to me at
least, implies a matching address record. The RFC should be more clear. How
about this:
Existing text:
An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis.
Suggested revision:
An SMTP server MAY verify that the domain name argument in the EHLO
command has an address record matching the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis.
This avoids what appears to be a blanket prohibition against IP-based
authentication of the heloname.
-- Dave