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 <[email protected]> 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 > >
