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