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
<riaan(_dot_)olivier(_at_)striata(_dot_)com> 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.
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp