Subject: [ietf-smtp] New Enhanced Mail System Status Codes

From: Riaan Olivier <[email-masked]>
Date: Fri, 6 Mar 2015 16:34:14 +0200

I have been looking and monitoring the Iana page for SMTP Enhanced
Status Codes and read most of the RFC's and drafts related to this.
I started using the RFC to process the the message replies that we
receive from mail servers around the world and I came across a few
discrepancies and have some new suggestions that I think can be added.
Could you please take the following scenarios into consideration

Discrepancies:
===========

Scenarios 1
----------------
The RFC read as follow:

   X.2.2   Mailbox full

   The mailbox is full because the user has exceeded a per-mailbox
administrative quota or physical capacity.
   The general semantics implies that the recipient can delete
messages to make more space available. This
   code should be used as a persistent transient failure.

Iana page shows Associated basic status code as "Not given"

The above states that the code is only useful for a persistent
transient failure, but I believe that the Subject, Detail could be
used as a permanent failure as well. A good example of this is when a
user's mailbox has been full for longer than a period then the Class
could be 5 because the server will already know that the mailbox is
full and that it won't deliver.

See example below of mail servers that uses it for this reason:
5.2.2 The email account that you tried to reach is over quota. Please
direct 5.2.2 the recipient to 5.2.2
http://support.google.com/mail/bin/answer.py?answer=6558
cg2si4818136wjb.78 - gsmtp
5.2.2 User has been over quota for > 1 week, email rejected
What is your view on this? Can we add support for this?

Can I suggest us changing the "This code should be used as a
persistent transient failure." to "This may be useful as a persistent
transient failure or permanent failure code. It would be a persistent
transient failure in standard and a permanent failure if the mailbox
has been over quota longer than a certain period."

Scenarios 2
----------------

The RFC read as follow:

   X.4.6   Routing loop detected

   A routing loop caused the message to be forwarded too many times,
either because of incorrect routing
   tables or a user forwarding loop. This is useful only as a
persistent transient error.

Iana page shows Associated basic status code as "Not given"

The above states that the code is only useful for a persistent
transient failure, but I believe that the Subject, Detail could be
used as a permanent failure as well. A good example of this is when a
user sets up a forwarding rule that causes a infinite loop and the
server is setup to stop the email after 20 hops, then in this case the
server can use this code as a permanent failure.

See example below of mail servers that uses it for this reason:
554 5.4.6 Error: too many hops (in reply to end of DATA command)
What is your view on this? Can we add support for this?

Can I suggest us changing the "This is useful only as a persistent
transient error." to "This may be useful as a persistent transient
failure or permanent failure code. It would be a persistent transient
failure in standard and a permanent failure if the mail server detects
that the email is in a infinite loop because of mail forwarding
rules."

Scenarios 3
----------------

The RFC read as follow:

  X.2.1   Mailbox disabled, not accepting messages

   The mailbox exists, but is not accepting messages.  This may be a
permanent error if the mailbox will never
   be re-enabled or a transient error if the mailbox is only
temporarily disabled.

Iana page shows Associated basic status code as "Not given"

The above states that the mailbox exist but is disabled. There is
another scenario that fits into this grouping and its where the
account was created but never activated.

Can I suggest us changing the description and name to include this.
Eg.
X.2.1   Mailbox disabled or not activated, not accepting messages

The mailbox exists, but is not accepting messages. This may be a
permanent error if the mailbox will never be activated or re-enabled
or a transient error if the mailbox is only temporarily disabled.

New additions to Enhanced Status Codes:
================================

Can I suggest two a new Mailbox Status as below:

   Code:                    X.2.5
   Sample Text:        Unattended Mailbox
   Associated basic status code:  5
   Description:          The mailbox is unattended mailbox and the
email send to this mailbox will not be read. The general
                                semantics implies that the email will
not be read and should be removed of the users email list. This
                                is useful only as a permanent error.

   Code:                    X.2.6
   Sample Text:        Unsubscribed Mailbox
   Associated basic status code:  5
   Description:          The mailbox was unsubscribed from receiving
email from the from domain or from address. This can
                                also been seen a suppression of
messages coming in. This is useful only as a permanent error.

I think the last one can become a anti-spamming technique and RCF on its own.

Can I suggest a new Mail System Status as below:

   Code:                    X.3.7
   Sample Text:        System out of memory
   Associated basic status code:  5
   Description:          Mail system memory has exceeded. Mail system
may not be able to accept or deliver messages
                                because its out of memory.

Thanks
Riaan Olivier
Striata - Global Application Specialist

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2015 10:00:43 -0500

Riaan,

With the understanding that this is just a personal opinion and
carries no authority at all, a few comments:

(1) I assume you are aware that the key protocol requirement is
that you take actions based on, or at least consistent with, the
three-digit SMTP "basic" reply codes and, under most
circumstances, the first digit of that code.  Enhanced status
codes provide additional information but, if they are
inconsistent with the basic codes, they should be ignored.

(2) Your note makes several substantive suggestions.  It is very
hard to process substantive suggestions in the IETF on the basis
of an email message.  That is why we've gone to the trouble to
write and process and I-D just to add one basic code and more
information about another.  So, if you want to see these
suggestions pursued, I suggest you generate an Internet Draft
that describes the changes that should be made and the reasons
for them.   http://www.ietf.org/id-info/ contains pointers to
information about how to do that.  If you have questions not
answered there, ask (where SMTP topics are concerned, this is
usually a fairly friendly and low-noise list and I think most of
the people on it would be happy to help you).

It is impossible to make promises but, in general, people have
been pretty receptive to changes that improve the precision or
expressiveness of enhanced status codes and/or that improve the
quality of the IANA registry.

best,
     john

--On Friday, March 06, 2015 16:34 +0200 Riaan Olivier
<[email-masked]> wrote:

> I have been looking and monitoring the Iana page for SMTP
> Enhanced Status Codes and read most of the RFC's and drafts
> related to this. I started using the RFC to process the the
> message replies that we receive from mail servers around the
> world and I came across a few discrepancies and have some new
> suggestions that I think can be added. Could you please take
> the following scenarios into consideration
> 
> 
> Discrepancies:
> ===========
> 
> Scenarios 1
> ----------------
> The RFC read as follow:
> 
>    X.2.2   Mailbox full
> 
>    The mailbox is full because the user has exceeded a
> per-mailbox administrative quota or physical capacity.
> transient failure, but I believe that the Subject, Detail
> could be used as a permanent failure as well. A good example
> of this is when a user's mailbox has been full for longer than
> a period then the Class could be 5 because the server will
> already know that the mailbox is full and that it won't
> deliver.
> 
> 5.2.2 The email account that you tried to reach is over quota.
> Please direct 5.2.2 the recipient to 5.2.2
> persistent transient failure." to "This may be useful as a
> persistent transient failure or permanent failure code. It
> would be a persistent transient failure in standard and a
> permanent failure if the mailbox has been over quota longer
> than a certain period."
> 
> 
> 
> Scenarios 2
> ----------------
> 
> The RFC read as follow:
> 
>    A routing loop caused the message to be forwarded too many
> times, either because of incorrect routing
> transient failure, but I believe that the Subject, Detail
> could be used as a permanent failure as well. A good example
> of this is when a user sets up a forwarding rule that causes a
> infinite loop and the server is setup to stop the email after
> 20 hops, then in this case the server can use this code as a
> permanent failure.
> 
> 554 5.4.6 Error: too many hops (in reply to end of DATA
> command) What is your view on this? Can we add support for
> this?
> 
> Can I suggest us changing the "This is useful only as a
> persistent transient error." to "This may be useful as a
> persistent transient failure or permanent failure code. It
> would be a persistent transient failure in standard and a
> permanent failure if the mail server detects that the email is
> in a infinite loop because of mail forwarding rules."
> 
> 
> Scenarios 3
> ----------------
> 
> The RFC read as follow:
> 
>    The mailbox exists, but is not accepting messages.  This
> may be a permanent error if the mailbox will never
> The above states that the mailbox exist but is disabled. There
> is another scenario that fits into this grouping and its where
> the account was created but never activated.
> 
> Can I suggest us changing the description and name to include
> this. Eg.
> The mailbox exists, but is not accepting messages. This may be
> a permanent error if the mailbox will never be activated or
> re-enabled or a transient error if the mailbox is only
> temporarily disabled.
> 
> 
> 
>    Description:          The mailbox is unattended mailbox and
> the email send to this mailbox will not be read. The general
> semantics implies that the email will not be read and should
> be removed of the users email list. This
>    Description:          The mailbox was unsubscribed from
> receiving email from the from domain or from address. This can
>    Description:          Mail system memory has exceeded. Mail
> system may not be able to accept or deliver messages
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp