Subject: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.txt

From: Alessandro Vesely <[email-masked]>
Date: Tue, 1 Feb 2022 18:52:53 +0100

On Mon 31/Jan/2022 16:46:54 +0100 internet-drafts wrote:
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-as-04

Section *Use of SMTP Extensions* is the most noticeable addition.

I'd question one extension:

  *  Enhanced Mail System Status Codes [RFC5248]

The implementation I use, Courier-MTA, does not implement it.  The argument I 
heard about not having it is that, in fact, only the first byte of the response 
is needed to interoperate.

How is that "MUST be supported by SMTP senders and receivers" going to affect 
usage practice of that software?

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 1 Feb 2022 21:13:16 -0500

>is needed to interoperate.

I think you're confusing the three digit status codes like 250 that are at
the beginning of a response, and the three part enhanced status codes like 2.1.5
that go at the start of the text portion, e.g.

 250 2.1.5 Address accepted

>usage practice of that software?

Probably not at all.  When you asked Sam, what did he say?

R's,
John
xs

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 2 Feb 2022 10:22:08 +0100

> Probably not at all.  When you asked Sam, what did he say?

When the topic appeared on courier-users, he replied as quoted above.  That is, 
saying that of "250 2.1.5 Address accepted" only the leading "2" is needed to 
interoperate.

I'm asking this list about the intended effect of that MUST before notifying Sam.

IME, I collect 4xx and 5xx responses from mail logs.  Gathering data from 1186 
reports, I find 8107 lines with a number after [45]xx response and 2021 with a 
non-number.  So there seems to be a majority of receivers using extended status 
codes.

However, when I glance at those reports I notice better prominent multi-line 
responses, URLs (since they are colored in the mailed report), and extremely 
short responses.  The enhanced status codes are not much helpful.  Are they 
actually used when gathering data?

Best
Ale
--

---

From: Laura Atkins <[email-masked]>
Date: Wed, 2 Feb 2022 09:28:48 +0000

Just as a FYI: Yahoo is not currently supporting RFC5248 Enhanced Status Codes.

220 mtaproxy308.free.mail.ne1.yahoo.com ESMTP ready
EHLO
250-mtaproxy308.free.mail.ne1.yahoo.com
250-PIPELINING
250-SIZE 41943040
250-8BITMIME
250 STARTTLS

laura 

> On 2 Feb 2022, at 02:13, John Levine <[email-masked]> wrote:
> 
> Emailcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emailcore

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
[email-masked]		

Email Delivery Blog: http://wordtothewise.com/blog

---

From: "John R Levine" <[email-masked]>
Date: 2 Feb 2022 10:15:25 -0500

On Wed, 2 Feb 2022, Alessandro Vesely wrote:
> When the topic appeared on courier-users, he replied as quoted above.  That 
> is, saying that of "250 2.1.5 Address accepted" only the leading "2" is 
> needed to interoperate.

He's right.  Now I'm scratching my head and wondering what it means to 
support extended codes.  Have some way for servers to add them?
Clients Log them on incoming messages?

Bulk mailers look at the extended codes trying to tease out every possible 
hint about why their mail is or isn't getting delivered but in my 
experience their main use is that when something odd happens, you look at 
the logs and see if the codes tell you anything surprising.

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: Wed, 02 Feb 2022 11:39:16 -0500

--On Wednesday, February 2, 2022 10:22 +0100 Alessandro Vesely
<[email-masked]> wrote:

>>> The implementation I use, Courier-MTA, does not implement
>>> it.  The argument I  heard about not having it is that, in
>>> fact, only the first byte of the response  is needed to
>>> interoperate.
>> 
>> I think you're confusing the three digit status codes like
>> 250 that are at the beginning of a response, and the three
>> part enhanced status codes like 2.1.5 that go at the start of
>> the text portion, e.g.
>> 
>>> How is that "MUST be supported by SMTP senders and
>>> receivers" going to affect  usage practice of that software?
>> 
> When the topic appeared on courier-users, he replied as quoted
> above.  That is, saying that of "250 2.1.5 Address accepted"
> only the leading "2" is needed to interoperate.
> 
> IME, I collect 4xx and 5xx responses from mail logs.
> Gathering data from 1186 reports, I find 8107 lines with a
> number after [45]xx response and 2021 with a non-number.  So
> there seems to be a majority of receivers using extended
> status codes.
> 
> However, when I glance at those reports I notice better
> prominent multi-line responses, URLs (since they are colored
> in the mailed report), and extremely short responses.  The
> enhanced status codes are not much helpful.  Are they actually
> used when gathering data?

Ale,

I think several different things are getting confused in your
questions, at least as I understand them.

First, those original three-digit status codes, as generated by
an SMTP-receiver, were intended to serve three separate purposes:

(i) To tell the SMTP-sender whether the message (or its
elements) were acceptable for further processing.   For that
role, "ok", "continue", "try later", and "no, fatal error" is
sufficient information and the SMTP-sender paying attention only
to the first digit is sufficient.  RFC5321 more or less says
that and, as usual, if you have suggestions as to how to better
explain it, text or specific suggestions would be welcome.
Whatever the SMTP-sender might want to do about logging is a
largely separate issue, at least until the day that someone
writes a spec about what MTAs are required to log and gets it
through the system.

(ii) Even then, some of the more differentiated information is
important if the SMTP-sender chooses to pay attention to it.
To take an example from part of a different recent discussion,
there really is a difference among {500, 501, 502, 503, 504,
555} and 550: the first group indicates that the server thinks
the client messed up and is not following the specs, while 550
represents a specific problem with the address.  If I were
maintaining SMTP-sender software, I'd certainly want to know
about that even though the action I might take on that
particular message might still depend only on that first digit.
It is probably not a bug if the SMTP-sender ignores that
information, but it shows a certain level of indifference and
would not be, IMO, good programming practice.

(iii) To give the SMTP-sender (which might be a Submission
server or even an MUA) sufficient information to deliver
meaningful "delivery failed or delayed" information to the
sending human.  Now SMTP says nothing about those messages and
their presentation and the DSN/NDN specs go only a bit further.
One of those end systems would be conforming if all 5yz codes
were explained to the sending user as "you lose" with no
additional information but I would not expect users to be happy
about that.   I don't know if it was on the minds of Jon or
others when RFC 821 was written but, in more recent years, we've
found it very helpful to be able to have most of the information
in the text rather than depending on delivering the
English-language explanatory strings to users, something that
5321 calls out.    However, the three-letter codes turned out to
be seriously insufficient for the originating system (and/or
DSN-generating one) to produce explanations to the user about
what went wrong that would contain a satisfactory amount of
information and, in "multlingual" contexts, to permit
presentation of that information in the user's language.  And
_that_ is at least part of the reason for the extended status
coded.  Does software acting as an SMTP-sender need the
additional information to figure out what to do?  No, and, if it
does, we are messed up significantly.  Should an SMTP-receiver
be supplying the additional information so that whatever those
message-origination user see makes sense to them?  I certainly
hope so... and I think that "SHOULD generate" is entirely
sensible if the mail system, as seen by those users, is going to
do much better than "you lose".

Now, my personal guess is that the proposed text in the A/S
could use improvement to explain at least a bit of that.  But
the recommendation, if interpreted as "SMTP-servers should
provide both meaningful three-digit codes and extended codes",
is probably correct.  On the other hand, one implication of the
analysis above if that, if one wanted to split hairs, extended
status codes are much more important for failure or delay cases
than for successful message transfers so one might limit the
SHOULD to those cases... but my guess is that it wouldn't make
much difference in practice.

   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Feb 2022 11:51:53 -0500

> 250-mtaproxy308.free.mail.ne1.yahoo.com

Laura,

This may be an argument for somewhat more differentiation in
what the A/S has to say on the subject (and maybe some
clarification in 5321bis is needed), but the example above does
not provide useful information, because...

RFC5321 (and 5321bis) specify the <ehlo-line> (all lines of the
response after the initial one with the domain information) as 
   ehlo-line =   ehlo-keyword *( SP ehlo-param )
and the <ehlo-keyword> is required to be consistent with the
extension name.

If that is not clear enough in 5321bis, open a ticket.  And, if
it is not clear enough in the extended status code specs, at
least an erratum, and probably an explicit update from the A/S,
would be in order.

So, as I read it, no extended reply codes are allowed in the
EHLO reply and anything that puts them in is non-conforming.

I don't know what Yahoo does, but I think one would have to run
a test against commands in a mail transaction to determine
whether or not they are available.

   john

---

From: Claus Assmann <[email-masked]>
Date: Wed, 2 Feb 2022 17:07:21 +0000

> not provide useful information, because...

Really? Shouldn't
250-ENHANCEDSTATUSCODES
be in the list if Enhanced Status Codes were supported?

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

---

From: Laura Atkins <[email-masked]>
Date: Wed, 2 Feb 2022 17:11:37 +0000

> On 2 Feb 2022, at 16:51, John C Klensin <[email-masked]> wrote:
> 
> 
> 

Yahoo is not providing RFC5248 Enhanced Status Codes in their SMTP service. I use Yahoo specifically as an example of a large provider not using enhanced SMTP responses in my class for delivery folks who want a more technical understanding of email. 

Yahoo isn’t the only MTA not giving out enhanced status codes when they reject a mail. There are a lot of MTAs that don’t provide them. Today I was processing logs for a customer. Out of 870 entries, only 149 of them contain enhanced status codes. 

In terms of the filters / MTAs involved here: 

mimecast: 	544
office 365:	121
ironport: 		26
proofpoint:	19
google apps: 	17

Even more that have them but don’t actually follow the spec. This was from an entry last week: 

550 5.7.1 Connection refused We could not accept your email because the message was sent to a non-existent customer/user. These errors should be treated as an “unsubscribe” by the sender, if a bulk mailer.

User unknown is specifically defined in 5248 and 5.7.1 is not it. 

I didn’t see any discussion on the list about the wording of section 2.4. I think, at a minimum, it should be a SHOULD and not a MUST. I think there should also be some wording about how the enhanced status codes are to be used. I say this as someone who is doing a lot of work reading SMTP logs to deal with email delivery issues. Receiving MTAs are the status codes and enhanced status codes are so all over the place, I just ignore them and go to the text string to figure out what they’re trying to tell me. 

I do understand where Sam is coming from in terms of Courier - the first number gives you almost all the data you need to handle that transaction (2, you’re good to go; 4 - stop and come back later; 5 - stop and don’t come back with this email again). The challenge is that we’re using SMTP response codes for bulk mail handling (do you try a new email to this address in the future?) or when we’re trying to identify a spam block. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Feb 2022 13:50:54 -0500

--On Wednesday, February 2, 2022 17:11 +0000 Laura Atkins
<[email-masked]> wrote:

>> clarification in 5321bis is needed), but the example above
>> does not provide useful information, because...
>> 
>> RFC5321 (and 5321bis) specify the <ehlo-line> (all lines of
>> the response after the initial one with the domain
>> information) as  ehlo-line =   ehlo-keyword *( SP ehlo-param )
>> If that is not clear enough in 5321bis, open a ticket.  And,
>> if it is not clear enough in the extended status code specs,
>> at least an erratum, and probably an explicit update from the
>> A/S, would be in order.
>> 
>> I don't know what Yahoo does, but I think one would have to
>> run a test against commands in a mail transaction to determine
> Yahoo is not providing RFC5248 Enhanced Status Codes in their
> SMTP service. I use Yahoo specifically as an example of a
> large provider not using enhanced SMTP responses in my class
> for delivery folks who want a more technical understanding of
> email. 
> 
> Yahoo isn't the only MTA not giving out enhanced status
> codes when they reject a mail. There are a lot of MTAs that
> don't provide them. Today I was processing logs for a
> customer. Out of 870 entries, only 149 of them contain
> enhanced status codes. 
> 
> Even more that have them but don't actually follow the spec.
> This was from an entry last week: 
> 
> 550 5.7.1 Connection refused We could not accept your email
> because the message was sent to a non-existent customer/user.
> These errors should be treated as an "unsubscribe" by the
> sender, if a bulk mailer.
> 
> I didn't see any discussion on the list about the wording of
> section 2.4. I think, at a minimum, it should be a SHOULD and
> not a MUST. I think there should also be some wording about
> how the enhanced status codes are to be used. I say this as
> someone who is doing a lot of work reading SMTP logs to deal
> with email delivery issues. Receiving MTAs are the status
> codes and enhanced status codes are so all over the place, I
> just ignore them and go to the text string to figure out what
> they're trying to tell me. 
> 
> I do understand where Sam is coming from in terms of Courier -
> the first number gives you almost all the data you need to
> handle that transaction (2, you're good to go; 4 - stop and
> come back later; 5 - stop and don't come back with this
> email again). The challenge is that we're using SMTP
> response codes for bulk mail handling (do you try a new email
> to this address in the future?) or when we're trying to
> identify a spam block. 

Laura,

I was not commenting on what Yahoo was doing, only on the
example in your note.  I am completely confident that your
experience and analysis is accurate.  

That said...

I think the A/S probably should say something about enhanced
status codes.  What it could say (carefully avoiding 2119/8174
terminology for the moment) could be anything from "these seemed
like a good idea at the time but they are not being widely
enough supported to be useful" to "good idea and anyone not
supporting them ought to be explaining their reasons" to
"anything not supporting these is as non-conforming to modern
Internet email norms as they would be if they were still sending
'HELO'".   Which would you pick and why?

I do note that at least one of the systems you list has,
historically, been notoriously indifferent to what the email
standards say.  So, at minimum, it is unlikely that anything we
do or do not say will change their behavior.  And, as I have
said about other things, if we make a provision that requires
existing implementations to change their behavior, it would be
very helpful to explain why we think that change is important,
not just lay down a requirement and expect everyone to salute.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Feb 2022 14:15:00 -0500

> be in the list if Enhanced Status Codes were supported?

Maybe.  Definitely so if there were a firm requirement that, if
enhanced status codes are used, that extension must be
advertised and accepted.  However, neither RFC 1893 nor RFC 3463
imposes such a requirement (the latter does not even reference
RFC 2034).  While RFC 2034 specifies the ENHANCEDSTATUSCODES
extension, I can find nothing there that _requires_ a server
returning such codes to advertise that fact and its Section 5 is
very clear that there is no way for the client to insist that
such codes be sent or not sent.  In addition to the reasons that
RFC gives, such requirements would be very tricky given the very
flexible language in RFC 5321 about text following the
three-digit code (and space or hyphen).  

So, AFAICT, a server that returned the enhanced codes without
advertising that extension would still be conformant to RFC
3463.  I won't go as far as to suggest what it "SHOULD" be
doing, but I think I stand by my assertion that the only way one
can tell reliably whether a server is providing enhanced status
codes would be to look at responses within the mail transaction.

Probably it would be worth opening a ticket to see if the A/S
should clarify that situation and relationship and, if so, in
what way.

best,
   john

---

From: "John Levine" <[email-masked]>
Date: 2 Feb 2022 15:00:53 -0500

>'HELO'".   Which would you pick and why?

I'd pick the middle one, implement them unless you have a good reason not to
(which might be, our code is a twisty maze with poor documentation, so we're
not changing anything we don't have to.)

Adding the codes is generally pretty easy, put them in the strings you
are already using for the status messages, and they can be useful for
diagnosing problems, particularly for people not fluent in the
language in which the text messages are written.

This is sort of crossing wires, but I would make the advice stronger
for submission than for SMTP, since there is more likely to be a live
user getting the report back.

My opinion about the ENHANCEDSTATUSCODES keyword is considerably more
sceptical. The three numbers are either there or they aren't, and I
don't see any benefit of an assertion or non-assertion about them
which might be wrong.

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 2 Feb 2022 21:36:22 +0000

> EHLO reply and anything that puts them in is non-conforming.

I suspect what Laura is pointing out is the lack of
an rfc2034 "ENHANCEDSTATUSCODES" EHLO keyword,
not that the EHLO response has/has-not an extended
response.
-- 
Cheers,
   Jeremy

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 2 Feb 2022 21:37:15 +0000

On 01/02/2022 17:52, Alessandro Vesely wrote:
> The implementation I use, Courier-MTA, does not implement it. 

Exim, likewise, takes no notice of RFC 5248 extended codes
supplied to it in responses, and generates none (in its hard-coded
source; a configuration can supply customised messages and those
could include them).

And, I think, nobody has ever requested that it do so.
Certainly I don't recall a bug recording such.

My initial reaction to a standard requiring implementation
would likely be "we don't support that standard" (or rfc 2034).
-- 
Cheers,
   Jeremy

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Feb 2022 17:11:52 -0500

> would likely be "we don't support that standard" (or rfc 2034).

So, Jeremy, let me ask you a variation on the same question I
asked Laura.  If the reality is that few significant
implementations or email providers are supporting the extended
codes and/or the SMTP extension, should the A/S say "this looked
like a really good idea but there has been little support in the
last quarter-century; implementations MAY support the codes and
MAY (or SHOULD ?) support the SMTP extension if they do?

And should anyone proposing anything stronger (like a SHOULD or
MUST implement) be required to provide a convincing explanation
for you, your users, Ale, and the MSPs Laura deals with as to
why this is actually important enough that they should press for
support?

     john

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Feb 2022 17:21:35 -0500

--On Wednesday, February 2, 2022 15:00 -0500 John Levine
<[email-masked]> wrote:

>> terminology for the moment) could be anything from "these
>> seemed like a good idea at the time but they are not being
>> widely enough supported to be useful" to "good idea and
>> anyone not supporting them ought to be explaining their
>> reasons" to "anything not supporting these is as
>> non-conforming to modern Internet email norms as they would
>> be if they were still sending 'HELO'".   Which would you pick
>> and why?

> I'd pick the middle one, implement them unless you have a good
> reason not to (which might be, our code is a twisty maze with
> poor documentation, so we're not changing anything we don't
> have to.)

FWIW, me too, but I have very little personal skin it this
particular game other than a desire that, since the issues have
been brought up, we clarify a bit.
 
> Adding the codes is generally pretty easy, put them in the
> strings you are already using for the status messages, and
> they can be useful for diagnosing problems, particularly for
> people not fluent in the language in which the text messages
> are written.
 
> This is sort of crossing wires, but I would make the advice
> stronger for submission than for SMTP, since there is more
> likely to be a live user getting the report back.

Unless these things go into DSNs and NDNs if they are available,
in which case there may be live users either way.

I would also make it stronger for any SMTP system that had, or
expected to have, any significant amount of traffic involving
users who are not fluent in English (or, with some
qualifications about what conforms, any language in which the
text portions of the replies are written).  Indeed, I could see
a rather strong requirement for the codes when SMTPUTF8 is in
use so as to cut down on the translation problems for free text.

>...

   john

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 2 Feb 2022 22:56:19 +0000

> MAY (or SHOULD ?) support the SMTP extension if they do?

If that "few" holds:

- saying "MAY support the codes" seems pointless but would
do no harm.  If present, I'd say some exposition of what
support means is needed.

- re MAY/SHOULD "support the SMTP extension": I'd assumed
the extension was inextricably bound to the use of the codes.
I see you pointing out there's no particular logical reason.
I'd expect others to be as confused as me by them being
disconnected, but I guess if there were a document one
could refer to saying that then it's not a long-term disaster.

So I'm ambivalent on this one.

> why this is actually important enough that they should press for

Yes.

-- 
Cheers,
   Jeremy

---

From: "John Levine" <[email-masked]>
Date: 2 Feb 2022 21:50:03 -0500

It appears that John C Klensin  <[email-masked]> said:
>If the reality is that few significant
>codes and/or the SMTP extension, ...

Big gorillas Google and Microsoft support both the code and the
extension. Tucows, who provides white label support for large
companies as hostedemail.com does, too.

But GMX, which is mail.com and a large European mail operator doesn't.

I think Laura's point was that while support is widespread, it is not universal.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 2 Feb 2022 21:55:18 -0500

>I see you pointing out there's no particular logical reason.

The codes were defined in RFC 1893 in January 1996, while the SMTP
extension was in RFC 2034 in October 1996.

Ned Freed wrote the latter document so maybe he remembers what the plan was.

R's,
John

---

From: Laura Atkins <[email-masked]>
Date: Thu, 3 Feb 2022 09:25:50 +0000

<snip a bunch of discussion> 

> 'HELO'".   Which would you pick and why?

Not being widely enough supported to be useful, to be quite honest. Every system using them picks codes that, to me as an observer, seem to be random. The choices are often in contradiction to the RFC text. I’d be thrilled if we could encourage people to correctly report enhanced codes, but I really think that ship has sailed.  

> not just lay down a requirement and expect everyone to salute.

That was my point as well. If this goes out as is, then we’ve published a protocol that will be unsupported by the majority of mail providers. Language added to this newest draft in 2.4 says “Enhanced status codes MUST be supported” without any underlying guidance or justification. If we’re going to endorse using enhanced codes, I think the language needs to be worked on for that section. 

I can take a look at it. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
[email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 3 Feb 2022 10:41:08 +0100

On Wed 02/Feb/2022 17:39:16 +0100 John C Klensin wrote:
> --On Wednesday, February 2, 2022 10:22 +0100 Alessandro Vesely <[email-masked]> wrote:

And that works remarkably well.

> would not be, IMO, good programming practice.

As I said, I sort and count unique messages, getting lines like these:

       3  421 Offline: HELO/CC
       3  421 mcc-ibgw-token.ext.cloudfilter.net cmsmtp Connection refused, too many sessions from 62.94.243.226 AUP#POL
       2  550 Mailbox is full / Blocks limit exceeded / Inode limit exceeded
       2  550-5.1.1 The email account that you tried to reach does not exist. Please try
          550-5.1.1 double-checking the recipient's email address for typos or
          550-5.1.1 unnecessary spaces. Learn more at
          550 5.1.1  https://support.google.com/mail/?p=NoSuchUser <token> - gsmtp

(The /token/ above replaces unmeaningful random data.)

The number of mail servers is sufficiently low that collecting a catalogue of all such strings doesn't seem to be a daunting project.

IME, most end users only experience misspelled addresses, otherwise they ask for support.

I think Laura described well how extended codes are used by mass mailers.  In fact, 550 is used for no such user as well as for any policy reason determining not to accept that message.  Although careful analysis and comparison to other cases may lead to educated guesses, she says mass mailers use extended status codes.  Privacy can be a reason not to produce them.

> do much better than "you lose".

Yes, some systems produce very long winded bounce messages (in English).  To me they look confusing.  I don't know how they are perceived by unaware, naive users.  Certainly, the topic of how to present bounces, especially on submission, needs advanced skills, extraneous to SMTP.

> much difference in practice.

A MUST sounds excessive.   Perhaps even a SHOULD.

Best
Ale
--

---

From: Laura Atkins <[email-masked]>
Date: Thu, 3 Feb 2022 09:56:14 +0000

> The number of mail servers is sufficiently low that collecting a catalogue of all such strings doesn't seem to be a daunting project.

That has not been my experience. https://wordtothewise.com/wp-content/uploads/2019/11/BouncesFrustrationBlog-1.png <https://wordtothewise.com/wp-content/uploads/2019/11/BouncesFrustrationBlog-1.png> was something I did for a client who wanted to handle bounces from three different outbound systems. 

> I think Laura described well how extended codes are used by mass mailers.  In fact, 550 is used for no such user as well as for any policy reason determining not to accept that message.  Although c…

I don’t think that is actually what I said. 

My experience is that the extended status codes aren’t very useful in terms of handling subscribers. 

However, in the bulk space we’re overlaying a lot of context onto rejections that our completely outside of the spec. The RFCs are about what to do with that message. A lot of the practical usage is what to do with the next message and how to handle large bulk mail operations. 

> Yes, some systems produce very long winded bounce messages (in English).  To me they look confusing.  I don't know how they are perceived by unaware, naive users.  Certainly, the topic of how to pr…

They are long winded, and the often contradict the SMTP and the extended SMTP codes in use. 

> A MUST sounds excessive.   Perhaps even a SHOULD.

I agree here. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
[email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 4 Feb 2022 11:27:04 +0100

> That has not been my experience. https://wordtothewise.com/wp-content/uploads/2019/11/BouncesFrustrationBlog-1.png <https://wordtothewise.com/wp-content/uploads/2019/11/BouncesFrustrationBlog-1.png…

Nice diagram.

I didn't attempt a taxonomy.  I just try and eliminate (some) "tokens" 
as they ruin response aggregation.  (What's their usage?)

> I don’t think that is actually what I said.

Sorry, I obviously misread your post.

> My experience is that the extended status codes aren’t very useful in terms of handling subscribers.

Yes, my conclusion is the same.

> However, in the bulk space we’re overlaying a lot of context onto rejections that our completely outside of the spec. The RFCs are about what to do with that message. A lot of the practical usage i…

The only kind of bulk sending I do is for abuse reports.  Since my 
firewall differentiates offenders whose IPs are managed by a team 
which has a real abuse mailbox from those who can act without 
mitigation, I try to detect invalid addresses.  In that respect, 
invalid domain fingers a non-real abuse mailbox, while mailbox full 
does not.  Trying to recognize NDN's (and autoresponder's) templates 
seems more promising than discriminating mere responses, for that task.

The reason I look at bare responses is to spot possible SMTP-sender 
misconfigurations, which is more or less the reason John K exposes in 
the quote above.

Best
Ale
--