Re: Updated draft for "SMTP Response for Detected Spam"

--On Wednesday, March 30, 2022 10:55 -0700 Dave Crocker
<[email protected]> wrote:

> On 3/30/2022 10:37 AM, Brotman, Alex wrote:
>> I wanted to send an update for this draft.  I received
>> (negative) feedback from one person via the list, though
>> several outside of the list were supportive.  I wanted to try
>> to clear up some of the language in the draft.  Appreciate
>> feedback from those who are interested to read.
> 
> 
> The basic idea of this spec seems reasonable to me.
> 
> However, many reasonable ideas ultimately don't work out, for
> a wide variety of reasons.  To try to mitigate against that
> outcome, a specification needs compelling clarity about use
> and benefits, and a base of community support that wants that
> use and benefit.
> 
> Perhaps I've missed it, but it appears that the spec lacks
> both of these, as of now.  The question, then, is how to
> develop both?
> 
> I think the document has quite a bit of language that is
> tentative and I think that is appropriate, at this point.
> 
> Absent a decisive technical criticism -- which I'm not seeing,
> so far -- I suggest that the document seek processing through
> the Independent stream, rather than the IETF stream, and that
> it seek Experimental status, rather than Standards track.
> 
> Assuming that the Independent Stream Editor <
> [email protected]> is willing(*), that stream has /far/
> less hassle and unpredictability than the IETF, which is
> subject to all sorts of unexpected issues, depending on who
> offers criticism.  (Notice I didn't say 'whether'...)
> 
> Experimental has the benefit of being an explicit request for
> community action /and feedback/.  This can serve to develop
> that base of community support.
> 
> d/
> 
> (*) The editor is new to the task and so there's no track
> record to consult.

Dave,

Let me add one thing to your suggestions.  While it does not
appear in the headers, the last sentence of Section 1 of the
current draft claims that this updates RFC 5321.  I suppose that
is necessary because it adds a reply code that is not in the
list that now appears in 5321, following the model of RFC 7504.
However, if an update to 5321 (or its successor) is needed, that
immediately forces the document into the IETF stream.   If Alex
wants to pursue this as an Experiment, as you suggest (and which
I agree might be a good idea), he should have a discussion with
the ART ADs about whether it would be possible, today, to follow
the model of RFC 1846, which added a code experimentally but
with no pretence of updating RFC 821 and its reply code list.

Two alternatives, more or less for completeness: 

(1) It would certainly be inconsistent with positions both of us
have taken about minimal changes and with my concerns about the
fragility of 5321/5321bis,  but it would be possible to make a
proposal that the reply code materials in RFC 5321 (and, so far,
in rfc5321bis), be removed from that document and placed in an
IANA registry.   That would make documents like this much easier
to handle.

(2) Alex should consider whether an enhanced code of the RFC
3463 persuasion would meet his needs equally well.  While a
receiver would need code changes to recognize and utilize an
enhanced code and whatever supplemental information is provided
with it, it would also need code changes to actually recognize
"259" rather than having it treated as unrecognized and falling
back to the first digit only convention.  That would have the
added advantage of not violating an implicit SMTP convention
about reply codes which is that, except for VRFY and EXPN
commands and systems that use extended codes, we've tended to
let the primary code capture all of the available information.
>From that perspective, the reply text after the code is helpful
for human debuggers who read English but "all information in the
reply code" makes things much simpler for MUAs in non-English
environments who get the responses because they can just use
their own tables of text strings for each code rather than
having to translate.  If 259 requires that the receiver parse
the string looking for an assuredness indicator, especially one
at the end (unlike VRFY and EXPN), it requires even more
special-case treatment.

best,
   john