Suggestion noted. My notes indicate that the existing text was
worked out after considerable discussion, so I don't know how
the group will react.
FYI, "suggestion noted" means that, when
draft-klensin-rfc5321bis-00 appears, this suggestion will be
marked in the text for consideration.
john
--On Friday, January 30, 2009 6:37 -0700 David MacQuigg
<david_macquigg(_at_)yahoo(_dot_)com> wrote:
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