Subject: [ietf-smtp] Updated draft for "SMTP Response for Detected Spam"

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 30 Mar 2022 17:37:27 +0000

Hey folks,

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.

https://www.ietf.org/archive/id/draft-brotman-srds-01.txt
https://datatracker.ietf.org/doc/html/draft-brotman-srds-01

Thanks

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Mar 2022 10:55:52 -0700

> 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…

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-masked]> 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 Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Michael Peddemors <[email-masked]>
Date: Wed, 30 Mar 2022 11:06:36 -0700

While there is not anything TECHNICALLY wrong with the concept, the 
problem is that most people in the threat detection space have already 
decided NOT to advertise to a potential spammer that they know the 
message is spam.

And any RFC which says you SHOULD and yet will promptly be ignored, is 
probably not the best use of time/RFC's.

But for those who DO want to advertise it to the sender, it is good if 
there is a standard set out, but the RFC should be clear that this is 
simply a standardization, and NOT a recommendation.

As a company who spends a lot of time doing analysis directly in the 
SMTP layer, it also opens up a can of worms.

Do we add a code for every use case?

258 Deliver to the Marketing Folder
257 Stripped Attachments before delivery
256 Added your IP to our Blacklist
254 Accepted, but stripping headers

(Poor examples, but helps address my point)

Suggest that for those that want to present additional information, that 
it simply be textual on the 250 OK.  Especially since the same message 
from a different sending MTA might get a different result, or maybe we 
only want to help a certain MTA or company get more information, eg an ESP

Hope my feedback is valuable.

On 2022-03-30 10:37, Brotman, Alex wrote:
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: "John Levine" <[email-masked]>
Date: 30 Mar 2022 14:07:55 -0400

It appears that Brotman, Alex <[email-masked]> said:
>Hey folks,
>
>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.

I'm still not thrilled but anyway

It needs to define an SMTP extension so servers know that they can reply 259 rather than 250
at the end of data, e.g.

ehlo cruddy.mail.org
250-sceptical.server.com
250-STARTTLS
250-PIPELINING
250-ENHANCEDSTATUSCODES
250 MAYBESPAM

mail from:<[email-masked]> MAYBESPAM
250 2.1.0 Sender accepted.

rcpt to:<[email-masked]>
250 2.1.0 Recipient accepted.

Although there used to be server replies that contained strings for
the client to parse, they're all obsolete and these days clients only
look at the three digit status code and the three part extended status code.
Don't have a great suggestion for how else to encode it other than maybe
a range of enhanced status codes 2.6.20 through 2.6.29 for spam scores 0/10
to 9/10.

R's,
John

---

From: Claus Assmann <[email-masked]>
Date: Wed, 30 Mar 2022 18:13:24 +0000

> 254 Accepted, but stripping headers

Please don't use up all the 25x codes,
use the enhanced status code for this purpose.

-- 
Address is valid for this mailing list only, please do not reply
to it directly, but to the list.

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 30 Mar 2022 19:00:35 +0000

I wanted to use a code for some of the reasons below.  I would like to avoid a sender to having to guess at what the response means, whether it be a standard/extended code.  Senders (of all sorts) have to do entirely too much of that already.  Some receivers are intentionally vague, and then senders are left wondering if it's a me/you problem, or something else entirely.  I've seen several presentations about how someone is using ML to try to infer what the MBP means.  Hopefully this makes it easier to get helpful information.

As for the use case, the primary driver is to provide feedback to senders (again, of all sorts) so if they can recognize they're doing something bad, they may be able to lessen the abuse.  I'm not overly worried about divulging the information to malicious actors.  If it were an ESP, I'd hope they can either identify a spammer in their platform, or fire one who appears to be doing testing (and I’m not sure what kind of logs they share with customers anyway).  For an MBP, it's not likely that the sender/customer would get a notification of a successful delivery.  There's a section in the draft that talks about only using this with "trusted" partners/senders via some sort of ACLs.  I wouldn't imagine a MBP would use 259 with a netblock assigned to a wireless carrier's end-user space for example.

John, I see your point about defining the extension.  The receiver can't respond 259 (if this were deployed at large) unless they're reasonably sure the sender will treat it properly (as a successful delivery).

Thanks so far folks, much appreciated.

> -----Original Message-----
> From: John Levine <[email-masked]>
> Sent: Wednesday, March 30, 2022 2:08 PM
> To: [email-masked]
> Cc: Brotman, Alex <[email-masked]>
> Subject: [EXTERNAL] Re: [ietf-smtp] Updated draft for "SMTP Response for
> Detected Spam"
>
> >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.
>
> It needs to define an SMTP extension so servers know that they can reply 259
> rather than 250 at the end of data, e.g.
>
> ehlo cruddy.mail.org
> 250-sceptical.server.com
> 250-STARTTLS
> 250-PIPELINING
> 250-ENHANCEDSTATUSCODES
> 250 MAYBESPAM
>
> Although there used to be server replies that contained strings for the client to
> parse, they're all obsolete and these days clients only look at the three digit
> status code and the three part extended status code.
> Don't have a great suggestion for how else to encode it other than maybe a
> range of enhanced status codes 2.6.20 through 2.6.29 for spam scores 0/10 to
> 9/10.
>
> R's,
> John

---

From: Richard Clayton <[email-masked]>
Date: Wed, 30 Mar 2022 22:25:26 +0100

In message <[email-masked]>, Claus Assmann <ietf-
[email-masked]> writes

>use the enhanced status code for this purpose.

Since the receiver knows the message is spam I was wondering why the
code was 259 rather than 559 ...

... also, the text mentions all sorts of terms of art like "spam folder"
and "Email Service Provider" which I can't find in RFC5598 or defined in
later sections (assuming that their meaning is relevant ?)

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: John C Klensin <[email-masked]>
Date: Wed, 30 Mar 2022 21:01:00 -0400

--On Wednesday, March 30, 2022 10:55 -0700 Dave Crocker
<[email-masked]> 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.
> 
> 
> 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-masked]> 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/
> 

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Mar 2022 18:08:37 -0700

> (2) Alex should consider whether an enhanced code of the RFC

My note was intended not to get into detail, but process and technical 
details certainly should affect choice for this.  And, too, enhanced 
codes -- RFC 5248, with 3 IANA registries -- seem reasonable to me.

d/

---

From: John C Klensin <[email-masked]>
Date: Wed, 30 Mar 2022 22:15:59 -0400

--On Wednesday, March 30, 2022 22:25 +0100 Richard Clayton
<[email-masked]> wrote:

> In message <[email-masked]>, Claus
> Assmann <ietf- [email-masked]> writes
> 

Claus,  Yeah.  See the note I just posted for an extra reason or
two to use enhances codes rather than making up a new primary
one. 

> Since the receiver knows the message is spam I was wondering
> why the code was 259 rather than 559 ...
> 
> ... also, the text mentions all sorts of terms of art like
> "spam folder" and "Email Service Provider" which I can't find
> in RFC5598 or defined in later sections (assuming that their
> meaning is relevant ?)

Richard, as I understand the text, the plan is to tell the
sender-SMTP that the message is believed to be spam, but then
deliver it to one of those "spam folders" anyway.   That calls
for a 2yz code (I think 250 with one or more new enhanced status
codes for different cases) because returning a 5yz code and then
delivering the message anyway (no matter to whom and which
folders, whatever a folder is) would be a rather serious
violation of the SMTP specification and model.

As Dave Crocker has at least hinted, there are several other
issues with (or at least questions about) this document.  As one
example, if one looks at SMTP, the introductory paragraph of
this I-D is just plain wrong.   All SMTP does is move mail
transactions from a sender-SMTP to a receiver-SMTP.  If we are
talking about an "inbox" or some sort of folder, that isn't
about SMTP any more.  It might be something specific to what
SMTP calls the final delivery server or system, but there we
need to start thinking about exactly how to define what is often
known as a Message Delivery Agent (MDA) and, while we use the
term informally and there is at least one clear definition (in
RFC 5598), there has never been a standards-track specification
for what one of those does and how it behaves (i.e., one
paralleling RFC 6409 at the other end of the pipeline).  As Dave
also more or less suggested, if a version of this document were
to be considered for Standards Track, I think all of those
issues would need to be sorted out.  For an Experiment, some of
them could probably be deferred.

   john

---

From: Richard Clayton <[email-masked]>
Date: Thu, 31 Mar 2022 10:34:35 +0100

In message <EDDB8A4D3F9043845213F866@PSB>, John C Klensin <john-
[email-masked]> writes

>violation of the SMTP specification and model.

I was aware of that :-) ... my point being, as I'm sure you know but I
want to labour it, that "spam folders" are not actually used for spam
(people would hate it if every possible message addressed to them was
actually accepted! they'd receive 6 to 10 times as many messages as they
do at present)

Spam folders are a common (but not ubiquitous) mechanism for the
temporary storage of messages where the MTA, despite all the machine
learning and heuristics, cannot be entirely sure whether or not the
message is actually going to be wanted by the recipient, but on balance
it is felt to be unlikely.

But given that the intent of 259 is to allow "grown-ups" to adjust
behaviour dynamically in the middle of mail sending campaign, a 559
serves pretty much the same purpose of forcing a rethink.

Perhaps a rewrite which doesn't use such ill-defined terms as "spam"
will make it more obvious that there are message which an MTA is
prepared to accept, but somewhat reluctantly.

>If we are
>paralleling RFC 6409 at the other end of the pipeline).

When the IETF strays from "on the wire" then what it proposes, or the
language it uses (one might soon need a dictionary to understand the
notion of "secretary") seldom stands the test of time -- because it's no
longer about interoperability but about user convenience or developer
innovation ...

- -- 
richard                                                   Richard Clayton

---

From: "John Levine" <[email-masked]>
Date: 31 Mar 2022 13:08:16 -0400

>list that now appears in 5321, following the model of RFC 7504.

This reminds me, why don't we have an IANA registry for SMTP return
codes?  That would greatly simplify exercises like this.

I suggested to Alex that his draft needs to define an extension to let
client MTAs tell servers that they understand 259:

 ehlo cruddy.mail.org
 250-sceptical.server.com
 250-STARTTLS
 250-PIPELINING
 250-ENHANCEDSTATUSCODES
 250 MAYBESPAM

 rcpt to:<[email-masked]>
 250 2.1.5 Recipient accepted.

 data
 354 Go ahead
 -- blah blah blah --
 .
 259 2.6.8 That smelled pretty bad.

In that case it doesn't update 5321, since it's not changing what SMTP
clients and servers do in the absence of that extension, but it would
be nice to have a registry so the codes don't accidentally overlap.

With respect to 259 vs 559, Comcast is a pretty big mail system. If
they think this could be useful, which they apparently do, I think it
would be a fine idea to try the experiment (which does not need an RFC
since we are still not the Network Police) and then later perhaps
advance the proposal with experience of what it does. Experiments
would be easier if it were possible to reserve the code points without
a lot of overhead.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Mar 2022 10:17:31 -0700

On 3/31/2022 10:08 AM, John Levine wrote:
> would be a fine idea to try the experiment

In its current form, it is far too tentative about utility.

1.  It needs to be specific and specify meaningful action
2.  It really should have a demonstrated base of interest, to give some 
indication that returning the code(s) will be useful to at least some 
client SMTPs.

d/

---

From: Ned Freed <[email-masked]>
Date: Thu, 31 Mar 2022 10:45:48 -0700 (PDT)

In our world at least, use of previously undefined status requires an
extension. This is because a certain library for a certain language whose
name begins with "J" throws an exception when it sees a status code it
doesn't recognize.

Of course you can modify the app to catch and ignore the exception, but
customrs are curiously reluctant to do that.

Maybe this implies that a ACCEPTANYSYNTACTICALLYVALIDSTATUSCODE extension
would be useful. Or not.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 31 Mar 2022 13:55:51 -0400

In case it wasn't clear I am *not* proposing that they advance it as an 
RFC at this point.  You don't need an RFC to do an experiment.  You just 
do it.

A registry is useful to keep experiments from accidentally stepping on 
each other.

With respect to clients, it would take about 10 milliseconds for a bunch 
of ESPs (bulk senders) to sign up for this.  That's not a problem.

R's,
John

On Thu, 31 Mar 2022, Dave Crocker wrote:

> indication that returning the code(s) will be useful to at least some client SMTPs.

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Mar 2022 15:18:47 -0400

John,

First of all, I completely agree with Dave's recent comments
about the draft.  Without changes that respond to those points,
it is not possible (at least for me) to respond to most
questions or issues without speculating on what the draft
accomplishes and where it fits in the scheme of things.

More below...

--On Thursday, March 31, 2022 13:08 -0400 John Levine
<[email-masked]> wrote:

>> 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.
> 
> This reminds me, why don't we have an IANA registry for SMTP
> return codes?  That would greatly simplify exercises like this.

Personal opinion: Simplifying "exercises like this" is not
necessarily a useful goal.  Please note the last two paragraphs
of Section 2.2.1 of RFC 5321 (and its equivalents in its
predecessors going back to RFC 1425).   While those comments
were written specifically about extensions, they also apply to
addition of reply codes for specific purposes, especially reply
codes that deal with needs and situations that are specific
enough that the odds of broad support (beyond "look only at the
first digit" seem fairly low.  In addition, 5321 has a rather
extensive treatment of reply codes, their relationships, and the
underlying relationships in Section 4.2 (with predecessors going
back to RFC 821).  Capturing all of that information, including
the relationship between a new code and older ones, in an IANA
registry would be daunting, especially if most of the
information in Section 4.2 (and elsewhere in 5321) were not
moved to the registry and 5321bis rewritten to adjust for that
change.  The latter would probably not be impossible, but it
would be difficult, error-prone, result in larger changes than
any difference we've seen between 5321 and 5321bis so far.   I
suspect, given discussion so far, that we'd want a new
subsection of Section 4.2.4 of rfc5321bis or some considerable
enhancement to the existing Section 4.2.3 to explain the
applicability of the code -- again, not a job for an IANA
registry.     Momentarily putting on my editor's hat, please
don't go there unless there is a _very_ strong set of reasons.
 
> I suggested to Alex that his draft needs to define an
> extension to let client MTAs tell servers that they understand
> 259:
> 
>  ehlo cruddy.mail.org
>  250-sceptical.server.com
>  250-STARTTLS
>  250-PIPELINING
>  250-ENHANCEDSTATUSCODES
>  250 MAYBESPAM
> 

While it might work for, e.g., Comcast->Comcast messages and
some others (see below), I don't see it working well with the
model.  Suppose we have a sender at example.net who generates a
message in an MUA, hands it off to a submission server, which
then then looks up Comcast and starts using its MX records.  If
the submission server does not recognize and advertise
MAYBESPAM, either the mechanism is dead or it is useless: it
won't include MAYBESPAM in its MAIL comment and, if Comcast
sends the code anyway, there is no point.  In addition, Comcast
today lists the same preference for all of its MX records and
presumably, each of those servers can perform MDA functions (see
earlier comments about "inboxes" and "spam folders").   But
suppose they change their strutural setup and become more like,
e.g., Google or, for that matter, dcrocker.net and use
multiple-preference MXs.  Now, even if all of the systems
involved advertise MAYBESPAM (on their server side) and
including it in the MAIL command (on their client side), those
intermediate servers either have to take the message content
apart looking for spam (seriously violating provisions of
RFC5321 and, at least so far, 5321bis) or all they can do is
open a connection and send it off to a server listed in a
better-preference MX record.  If it does the latter, it must
(probably MUST) return 250 because it just does not have enough
information to return anything else.  And, when the message gets
to the delivery server and it determines that the message is
maybe spam, we are in MDN territory, not that of reply codes.

So, let me add a third item to Dave's list:

3. It needs to have a sufficient case analysis that includes the
above and other situations and an analysis of how each would
affect usability.

> In that case it doesn't update 5321, since it's not changing
> what SMTP clients and servers do in the absence of that
> extension, but it would be nice to have a registry so the
> codes don't accidentally overlap.

And that, it seems to me, is another argument for one or more
enhanced status codes rather than messing with the SMTP reply
code set.  I have a relatively open mind and, given answers to
Dave's two requirements and my additional one, could easily
change my mind.  But, right now...
 
> With respect to 259 vs 559, Comcast is a pretty big mail
> system. If they think this could be useful, which they
> apparently do, I think it would be a fine idea to try the
> experiment (which does not need an RFC since we are still not
> the Network Police) and then later perhaps advance the
> proposal with experience of what it does. Experiments would be
> easier if it were possible to reserve the code points without
> a lot of overhead.

See above.  But, precisely because Comcast is a pretty big mail
system, sending and receiving mail from at least four domains I
can think of immediately (and assume there are more), with at
least two different sets of DNS-listed mail servers (some of
which use multiple preference levels), I recommend some
intra-company experiments.  That would require no RFC-type
documentation at all.  A report on those experiments would
contribute significantly to the information Dave and I are
asking for.  And, if desired, I would hope that it would be
really easy to get a well-written document that was a report of,
and recommendations from, Comcast's experiment published: much
easier than starting off with a tentative proposal.  

Even for that experiment, I'd still suggest using enhanced codes
with 250 (again, the message is being delivered and to which
folder is not an SMTP problem).  2.6.8, as you suggest above, is
not available because it is used for something involving UTF-8
mailbox names.  But perhaps they could use
   2.6.11  That smelled pretty bad.  
and
   2.6.12 I am too far from the recipient inbox to analyze its
smell
which would even address the relay problem outlined above.

If, on the other hand, they had a need for a new SMTP reply code
--something that clearly has not been demonstrated -- I haven't
done the analysis of 259 against Section 4.2.1's "theory"
requirements.  If they authors have done that, it should be in
the draft too.

Finally, with apologies in advance if anyone finds this snarky,
if the justification for this discussion --and several of us
spending time trying to make suggestions about fixes or
alternatives to the provisions of a document that feels more and
more like an incomplete set of ideas (or incomplete
documentation of more extensive  thinking) is that "Comcast is a
pretty big mail system", with little or no demonstration or the
workability of the idea for the many and varied systems on the
public Internet (even as an experiment), the discussion is
rapidly deteriorating into free consulting for Comcast.  Maybe
there are better ways for them proceed.  

best,
   john

---

From: "John R Levine" <[email-masked]>
Date: 31 Mar 2022 15:29:56 -0400

On Thu, 31 Mar 2022, John C Klensin wrote:
> predecessors going back to RFC 1425). ...

Well, the alternative is to squat on return codes and take your chances. 
Be careful what you wish for.

How about a registry with an expert review rule that new codes need to be 
enabled by an extension or else standards track RFC.

> message in an MUA, hands it off to a submission server, ...

Naah.  The people using this will be ESPs, people who send bulk mail for 
commercial clients.  I promise you they'd implement in in the 
aforementioned ten milliseconds.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Mar 2022 15:32:56 -0400

--On Thursday, March 31, 2022 10:45 -0700 Ned Freed
<[email-masked]> wrote:

> In our world at least, use of previously undefined status
> requires an extension. This is because a certain library for a
> certain language whose name begins with "J" throws an
> exception when it sees a status code it doesn't recognize.

Hmm.  Should I assume that it has been pointed out to the
authors of said library that they are in violation of a rather
specific provision of RFC 5321 and that they are not listening?

> Of course you can modify the app to catch and ignore the
> exception, but customrs are curiously reluctant to do that.
> 
> Maybe this implies that a
> ACCEPTANYSYNTACTICALLYVALIDSTATUSCODE extension would be
> useful. Or not.

Not really an extension because of the paragraph of Section 4.2
of RFC 5321 that starts

	"An SMTP client MUST determine its actions only by the
	reply code,..."

if that paragraph is not sufficiently clear that clients are not
allowed to throw exceptions (or otherwise have fits) when they
receive a reply code of three digits starting with 2, 3, 4, or
5, this would be a good time to suggest improvements.  
	
And, for this particular case, perhaps an
IAMINTERESTEDINWHATTHEMDATHINKSOFTHISMESSAGE extension, which
would generalize from MAYBESPAM and include "maybe highly
focused phishing attack" and other possible conclusions from
analysis on the delivery system, would be useful.  Or not.

  john

---

From: Ned Freed <[email-masked]>
Date: Thu, 31 Mar 2022 14:34:54 -0700 (PDT)

> specific provision of RFC 5321 and that they are not listening?

It's been pointed out. It may even have been fixed. But then there's
the issue of release and deploying. Getting this sort of thing out
of the field takes a long time.

	
> analysis on the delivery system, would be useful.  Or not.

Yep. All sorts of elaborations are possible.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Mar 2022 20:59:02 -0400

--On Thursday, March 31, 2022 15:29 -0400 John R Levine
<[email-masked]> wrote:

>> necessarily a useful goal.  Please note the last two
>> paragraphs of Section 2.2.1 of RFC 5321 (and its equivalents
>> in its predecessors going back to RFC 1425). ...
> 
> Well, the alternative is to squat on return codes and take
> your chances. Be careful what you wish for.

As I hope you know, a few recent issues with SMTP
notwithstanding, I've become an increasingly strong advocate of
low-threshold registrations to prevent naming conflicts and
discourage squatting.   But let's look at this one:

(1) The name (or, in this case, number) space is quite
restricted, especially when new codes are expected to conform to
the "what is each digit about" theory of 821-> 2821 -> 5321.
Restricted name spaces are, as you know, one of the legitimate
reasons given in the assorted documents for restrictive
registration policies.  Dropping that theory to promote
registrations by people with half-baked ideas isn't obviously a
good tradeoff.

(2) Because of that rule about SMTP clients making operational
decisions based on the first digit only, SMTP is fairly robust
against bogus or unknown codes, a at least ones that otherwise
conform to the digit meaning theory.  Where it makes a
difference, I'd prefer "pay attention to the full code if you
recognize it and it makes a difference and resort to looking
only at the first digit otherwise" to either just looking at the
first digit or the behavior exhibited by the library Ned
described.  However, one of the places it makes a difference is
the distinction between codes in which recipients of the reply
are, or are not, expected/required to look at the text strings.
That involves an explicit list of codes in 5321 (a list that
this one would need to be on because of that numeric assessment
level).

(3) As I have said earlier, the discussions in 5321 of the
codes, their applicability, and whatever special circumstances
apply are fairly complex.  I don't see a registry --at least any
IANA registry arrangement I ever remember seeing-- being
structured to handle that complexity.  One basically needs a
narrative (ideally one that is easier to follow than 5321) and
that isn't what IANA normally means by "registry".  That list of
codes that require the code-receiving client to pay attention to
the content of strings --which I had forgotten until I ran
across it earlier today-- is just another example of the
complexity.

(4) You may have data that shows a lot of reply code-squatting
but, to the best of my knowledge, there have been no serious
requests for new codes since RFC 7505 was published in 2015
(partially to support your "null MX" spec).  Now, my definition
of "serious" gets back to a good approximation of Dave's list
about demonstrating utility and being much less tentative.
YMMD.  I think it also requires an affirmative demonstration of
why some new, fine-grained, enhanced code or codes would not do
the job.  The present document does not qualify on either
condition (although some future revision might).

> How about a registry with an expert review rule that new codes
> need to be enabled by an extension or else standards track RFC.

Better.  But that still does not account for the interactions
within 5321[bis] and the associated registry complexities, the
practical limitations on the size of the code space (at first
glance one might guess there are 999 possible codes, but there
are actually much, much, less than 400), and so on.  And AFAIK,
EMAILCORE has yet to reach consensus that extensions require
less than serious standards-track consideration.

I had a thought that a simple registry of codes in use might be
helpful, all of them pointing back to SMTP for explanations.
But then I realized that might actually be an invitation to
squatters by telling them what codes were not in use.  

A different suggestion that I'm not sure I think it a good idea:
Define codes starting with 7yz and 8yz for experimental use.
Indicate explicitly in 5321bis that the model for the second and
third digits does not apply.  Set up an IANA registry as FCFS,
FCFS with verified contact point required and included in the
registry, or as Specification Required.  Given the tendency of
SMTP implementations and libraries to get indigestion about
codes with unrecognized first digits (they would be captured by
any unrecognized code test, of course), it would more or less
assure that the experiment would be carried out only among
consulting adults who were prepared to send and receive that
(temporary) code.

>> model.  Suppose we have a sender at example.net who generates
>> a message in an MUA, hands it off to a submission server, ...
> 
> Naah.  The people using this will be ESPs, people who send
> bulk mail for commercial clients.  I promise you they'd
> implement in in the aforementioned ten milliseconds.

But... (i) that makes the experimental code plan more plausible
(ii) I still don't understand why an enhanced code (or a few of
them) wouldn't do a better job, and (iii) after spending those
ten milliseconds and however much longer it took to deploy the
thing (see Ned's note), they would likely get really frustrated
if it didn't work as (what they construed as) advertised.  And
that gets back to Dave's comment about needing a really clear
explanation of expected utility.

In addition, it has been a long day and I might be missing
something, but I'm not sure that I see the use case for them
with the plan about a reply code as specified.  If they are
originating the message, all they need to implement is code,
probably in their submission servers such that, if they actually
get the 259 reply code, they know what to do with it.   They
presumably do no need to implement receiver-SMTP or special MDA
code at all.   They originate and send a message, to, using your
example, <[email-masked]>.  Assuming the mailbox  exists,
they can get back:

   259 2.6.8 That smelled pretty bad (8/10) -or-
   250 OK

but they have no clue as to whether the 250 indicates 
  inspected and looks ok
  intermediate relay does not play this game  -or-
  destination server for somewhere.wft does not play either.

all they can really learn from getting back that 259 response is
that the message might have reached someone's "spam" or "trash"
folder.   "Might" because I can't find anything in the spec that
says, e.g., "a server that issues the with the 259 code and a
score about 7/10 MUST deliver the message to a "spam folder".
They would learn a bit more from maybe three enhanced codes:

   250    2.6.11  That smelled pretty bad, but I'm delivering it
to the inbox it anyway (4/10).
   250    2.6.12  That smelled really bad, so I'm delivering it
to the spam folder (8/10).
   550    5.6.11  Horrible odor (10/10), please bounce the thing.
   550    5.6.12  Really horrible odor (11/10), please do not
return content to sender because it is probably dangerous.
   250    2.6.13  Conforming to 5321, I'm not opening the
message far enough to determine what I think of it.
   250    2.6.14  I am too far from the recipient inbox to
analyze its
smell

(I'd have to think some more about whether the last two are
different,  For the use case I think you are describing, 5.6.12
would probably never occur, especially if the ESP were a good
citizen who never allowed seriously malicious messages or
attachments to be sent or if the relevant receiver-SMTP/MDA
simply dropped such messages.

In any of those cases, either 250 or 550 alone would imply "no
support for that feature" of which "server does not belong to
Comcast and has not implemented support for this stuff" is a
subset.

That actually suggests that, if a new reply code is needed at
all, two are needed -- perhaps 259 and 559 -- to indicate
support for this feature.  However see comments about the size
of the code space for reply codes.  If one did the MAYBESPAM
extension, that would be unnecessary because offering and
requesting the extension could be specified as requiring that
the extended codes be present and interpreted however the
extension specified.

And, again, I'm not sure implementing the extension and/or
support for the new code would really add much value to the ESP
unless either (i) almost everyone to whom they send mail had
Comcast as a mailbox provider or (ii) this were put into a 5321
update as a "MUST support" and the delivery servers for almost
every mailbox on the net (few of which would belong to those
distribution-oriented ESPs) moved to rapidly deploy it.

What am I missing?

   best,
    john

p.s. I'm not certain those extended codes should be in the x.6.y
series rather than x.7.7 or a whole new x.8.y one.