At 12:12 AM 18-12-2019, Eliot Lear wrote:
If one looks at RFC 5321, there are three reasons to think that
really the standard does not prohibit the behavior being
described. First, the text in 4.1.4 doesn't actually prohibit the
rejecting literals. Here is what is said:
If the EHLO command is not acceptable to the SMTP server, 501, 500,
502, or 550 failure replies MUST be returned as appropriate.
At this point in the transaction, it may not be readily apparent
that the EHLO indeed is unacceptable. That's because the server may
need to gather more information, such as the recipient, in order to
check against SPF records or other inputs delivered later to make a decision.
The text in Section 4.1.4 is about the restrictions on the order in
which commands may be used. The is also a bug fix for STD 10 in that
section. As a nit, the SPF verification is done on the "MAIL FROM"
identity (RFC 7208).
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.
That "MUST NOT" conflicts with the most important principle we have
to go with in order to defend against spam and malware, as clearly
stated in Section 7.9:
There was a time when not adhering with the above requirement would
cause rejection of (valid) mail messages from a well-known mail service.
It is a well-established principle that an SMTP server may refuse to
accept mail for any operational or technical reason that makes sense
to the site providing the server.
And so the server chose to reject a message. I would add that an
erratum should be filed to resolve this conflict.
There is the following sentence after the one which you quoted:
"However, cooperation among sites and installations makes the
Internet possible". That sentence, and the sentence which follows
it, serves as an explanation for the recommendation at the end of the
What is the purpose for the (suggested) erratum? Is it to fix a
technical defect in the specification?
ietf-smtp mailing list