ietf-smtp
[Top] [All Lists]

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

2020-01-02 13:20:59
On 1/2/20 1:17 PM, John C Klensin wrote:

--On Thursday, 02 January, 2020 12:14 -0500 Keith Moore
<moore(_at_)network-heretics(_dot_)com> 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


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>