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

[Keith Moore <[e-mail]>]

On 12/29/19 5:08 PM, Barry Leiba wrote:

> I'd like to see us keep to a plan of folding in errata, doing some
> sensible reorganization, otherwise minimizing changes, and
> republishing 5321 with a target of "Internet Standard", which it
> clearly is.
>
> I'd like to see us then address some of these other issues in a
> separate document, which can go out as BCP or Proposed Standard
> (applicability statement) -- and there are other options as well --
> that would aim to give normative advice about these sorts of things
> but that is not part of the Internet-Standard level spec at this
> point.

I find myself wanting something fairly similar to that.   Whether the 
difference is significant I can't quite tell.

IMO 5321bis should be viewed as the long-term stable document, and as 
such should refrain from making recommendations about how to deal with 
short-term, local, or ephemeral considerations.   It should define the 
SMTP protocol and clean up any remaining ambiguities in that protocol.  
To the extent that 5321bis can be simplified while still fulfilling the 
task of accurately documenting the SMTP protocol, that might be a Good 
Thing.  It should be mostly about protocol, with policy considerations 
kept to a minimum.

IMO most of the spam-filtering criteria I've seen are countermeasures 
for short-term, local, and/or ephemeral conditions.   Either the 
filtering is just exploiting some coincidence that can be expected to 
change over time, or the countermeasure is something that spammers will 
discover and be able to work around.   I could make a case for spam 
filtering being entirely out-of-scope for 5321bis, except perhaps for 
some slight tweaks for about servers being able to impose their own 
policies for rejecting messages, and some recommendations for whether 
and how to report failed delivery due to spam filtering.

IMO to the extent that there's spam filtering advice that's broadly 
applicable across all sites,  that advice still doesn't have the 
maturity of 5321[bis] and its predecessors, and should not go in an 
Internet Standard document.

IMO there's lots of valuable work that could be done to improve 
reliability of Internet mail in the face of spam and spam filtering, but 
none of that work should creep into 5321[bis] or pace it.

Keith