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
