John C Klensin wrote:
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.
Yes
* Rejecting the EHLO command and message because the
apparent FQDN in the argument does not resolve at all in
the public DNS.
Not sure about this one. The wording says:
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis.
It doesn't say 'if the domain argument resolves to a different IP
address than that of the client it MUST NOT refuse to accept the message
on that basis'. It says 'if the verification fails', that could
potentially be 'host not found' as well as different IP address or whatever.
The 'verifying the argument corresponds to the IP address' is also a bit
vague. One person could say that this means that the A record for the
argument should match the IP address, but what about CNAMEs, or, could
the argument be a name which has an MX record which has an A record
matching the IP address. In a sense, that still means the argument
corresponds to the IP address (especially since we're talking about mail
here).
Given that you shouldn't refuse the message on that basis, it doesn't
matter what you mean by 'corresponds', but if people are starting to
refuse the message (or even 'redirect' it), it might need clarification.
This could affect your point above, where 'domain.com' doesn't have an A
record (so "doesn't resolve in the public DNS") but does have an MX
record referring to the host.
* 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.
Yes.
There's also the 'not bothering to check the EHLO argument at all',
which is valid under 5321 AFAICS.
Also AFAICS, it could also use the failure of the EHLO argument as a
'hint' for further spam filtering. Eg, if the EHLO argument didn't
resolve to the IP address, it could treat it as 'more suspicious', so do
more rigorous spam checking, as long as it doesn't refuse to accept the
message solely on the basis of a failed IP address verification.
--
Paul Smith
VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows