On 1/2/20 1:17 PM, John C Klensin wrote:
--On Thursday, 02 January, 2020 12:14 -0500 Keith Moore
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 , 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
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
ietf-smtp mailing list