[Top] [All Lists]

Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version

2019-12-18 12:33:20
Hi Eliot,
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 paragraph.

What is the purpose for the (suggested) erratum? Is it to fix a technical defect in the specification?

S. Moonesamy
ietf-smtp mailing list