Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP

[Keith Moore <[e-mail]>]

On 1/2/20 1:17 PM, John C Klensin wrote:

> --On Thursday, 02 January, 2020 12:14 -0500 Keith Moore
> <[e-mail]> wrote:
>
>> On 1/2/20 9:56 AM, Hector Santos wrote:
>>
>>> If some local sites decide to reject IP-literals based on
>>> decision  that contains bias so be it, they will deal with
>>> the false positives,  but it is not SMTP.
>>>
>> I agree that it doesn't belong in the SMTP spec.  But the
>> cumulative effect of receiving sites' ad hoc and ill-informed
>> filtering policies is to degrade the utility of Internet email
>> for everyone.    It's not only a problem for the sites that
>> set the policies.
> With regard to this and many other issues [1], I think there is
> a higher-level answer if we know that "many" sites are doing
> something other than what the spec recommends.  Whether we
> change the spec to follow their practices or retain and clarify
> the recommendation, it seems to me that we are going to need
> text, somewhere, that explains our decisions, why we are giving
> whatever advice we are providing, and why people should follow
> that advice.  That text, which probably belongs in a separate
> document from RFC531bis, may actually be more important than
> whatever we put in 5321bis. Absent our providing a persuasive
> explanation of why people should, or should not, do something,
> experience, both on the anti-spam side and based on continuing
> references to 2821, suggests that sites will do whatever they
> (locally) think best and that some of those decisions will be
> ill-informed.

Agree with this, and (as I just wrote in a separate message) I think 
policy recommendations need to be in a separate document from syntax anyway.

For me the test of whether something belongs in the revised SMTP 
specification is: do implementors of SMTP protocol engines need to know 
about it?   That's entirely a question of protocol rather than policy.   
So for instance, does the revised SMTP specification need to specify 
HELO?   I would argue yes, because there are probably still SMTP servers 
out there not supporting EHLO.   But the protocol specification could 
also say something like "clients MUST try EHLO before falling back to 
RSET then HELO if necessary".   That's still a matter of protocol 
because it affects the client's state machine.

But does the revised SMTP specification need to specify VRFY and EXPN?   
Here I would probably argue no, except perhaps to point out that certain 
commands defined in previous specifications cannot be reused, because 
there's already a well-defined error code for command not implemented 
and it's not necessary or helpful for a client to use those when sending 
mail.   A modern SMTP implementation doesn't need to handle those cases 
specially.

Keith