Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321

[Keith Moore <[e-mail]>]

On 9/27/20 9:51 PM, Sam Varshavchik wrote:

> Keith Moore writes:
>
>> I thought it was about advice to the server which is currently that 
>> the server MUST NOT refuse to accept a message based on failure of 
>> EHLO argument verification.
>>
>> My argument is that EHLO verification is, in the long run, poor 
>> practice and should not be encouraged by 5321bis even if it seems 
>> like an effective spam
>
> To me, "SHOULD NOT" is a better match for "should not be encouraged". 
> The current phrasing, "MUST NOT", prohibits it.

I might agree with that, though I would also like to see some 
elaboration as to why it's a Bad Idea in the long run, rather than just 
SHOULD NOT.

(I have a little but of trouble with the current 5321 language, because 
it conflicts with the notion that an SMTP server can reject mail for any 
reason.    At best the juxtaposition of these two seems conflicting and 
confusing even though I think that EHLO verification is overall a 
shortsighted idea that should be discouraged.)

>
> Whether or not EHLO domain validation is prohibited or not, it is used 
> in practice right now, and the current language in 5321 is being 
> ignored, to some degree. The same language also existed in 2821, so 
> this has been ignored for a while. An Internet standard that does not 
> reflect current practice is not as valuable as one which is.

I actually disagree.   The purpose of a protocol specification standard 
should not be to reflect current practice; it should be to specify 
desirable practice.    And it's important to not confuse the two goals.

However I will admit that if the standard specifies a practice that 
doesn't interoperate well with current practice, it can harm the 
effectiveness of the standard.

Keith