Explanation for SMTP error codes (5.x.x) ???
Spam Guy
and trying to figure out what exactly they mean.
I'm specifically interested in knowing which of these are indicating
that
a) the left-hand-side of the destination address was wrong, or
b) the recieving server did not like me, or my server, or my e-mail,
and did not want to put it into the recipient's inbox.
---------------------------
5.0.0 Message too large (a 3 kb message ?!)
5.1.0 Unknown address error 550-'5.1.1 unknown or illegal alias
5.1.0 Unknown address error 554-'Too many hops'
5.1.0 Address rejected
5.1.1 User unknown
5.1.1 Invalid recipient
5.1.1 Diagnostic-Code: smtp; 550 No such user
5.1.1 550 Requested action not taken: mailbox unavailable
5.1.1 Recipient address rejected: undeliverable address
5.1.1 Recipient address rejected: User unknown in virtual alias table
5.1.1 Recipient address rejected: User unknown in local recipient table
5.1.1 Recipient address rejected: User unknown in relay recipient table
5.2.0 mailbox unavailable
5.4.1 Recipient address rejected: Access Denied
5.7.0 Local Policy Violation
5.7.1 Your mail server has been marked as sending spam
5.7.1 554 Recipient address rejected: "NO LONGER ACCEPTING EXTERNAL
EMAIL" (in reply to RCPT TO command)
---------------------------
The above were parsed / extracted from automated "return to sender" or
error-notification messages in response to failed e-mail sending
attempts. They come from a wide variety of different destination
servers.
And also note this: The return address (ie - the sending address) that
triggered these various return messages has a domain component that has
a valid / registered / working MX record (just in case some of you think
that the rejections happened because of a non-existant MX record
belonging to the sender's domain).
Parsing these return messages is somewhat confusing, as they seem to mix
a variety of reporting styles - frequently mixing 5.x.x and 5yy codes
together - sometimes on the same line.
If anyone can explain the usage or rational of these various styles
(5.x.x vs 5yy) please do.
Also note the various messages that different servers use when denoting
the same 5.x.x error code.
I'm also interested in the usage of 5.4.x and 5.7.x codes in terms of
exactly what error condition they indicate. Again, did I (the sender)
get the address wrong? Or am I being denied the ability to place an
e-mail in the sender's inbox?
I'll also include the following error-message fragments:
--------------
Your message was not delivered because the return address was refused.
Action: failed
Status: 5.1.1
--------------
and
--------------
5.3.0 Mail from (my ISP SMTP output server) rejected;
see http://www.mail-abuse.com/
--------------
The first of those seems to indicate that code 5.1.1 is what that server
is using to denote a rejection based on the sender's return address.
The second is using the code 5.3.0 to indicate that it doesn't like my
ISP's SMTP output server.
So to re-cap:
- Which of these 5.x.x codes indicates an incorrect recipient
address, vs a failed delivery attempt based on some characteristic
of the sender?
- Why are there 5.x.x AND 5yy codes, and why are they used
simultaneously in the same error message, and why is their use
not consistent (specifically, 550 and 554) ?
Sam
> I've been looking through some undeliverable "return to sender" messages
> and trying to figure out what exactly they mean.
>
> I'm specifically interested in knowing which of these are indicating
> that
>
> a) the left-hand-side of the destination address was wrong, or
>
> b) the recieving server did not like me, or my server, or my e-mail,
> and did not want to put it into the recipient's inbox.
Any mail server is free to reject any delivery attempt, for any reason the
mail server deems to see fit.
You may attempt to interpret the mail server's error message. But there is
no universal, global, uniform set of error codes that all mail servers use.
There is no such thing.
Although there is a defined set of error codes that convey a more specific
reason for rejecting a delivery attempt, all the mail server cares about
whether the message was: accepted, rejected, or deferred with a temporary
error code. For the purposes of mail delivery, nothing else matters. It does
not matter, to a mail server, whether the delivery attempt was rejected
because a recipient mailbox does not exist, or a spam filter kicked in. The
message was rejected, and a delivery status notification gets sent to the
sender.
> The above were parsed / extracted from automated "return to sender" or
> error-notification messages in response to failed e-mail sending
> attempts. They come from a wide variety of different destination
> servers.
Correct. There is no end to all possible error messages you will see. Mail
servers generally examine the first digit of the SMTP status code, which
specifies whether the message was accepted, rejected, or deferred. Nothing
else matters, especially the free-form text part of the SMTP reply.
> Parsing these return messages is somewhat confusing, as they seem to mix
Correct. That's because they are not meant to be parsed.
> Also note the various messages that different servers use when denoting
> the same 5.x.x error code.
Correct. That's why it's called "free-form text" part.
> The first of those seems to indicate that code 5.1.1 is what that server
> is using to denote a rejection based on the sender's return address.
>
> The second is using the code 5.3.0 to indicate that it doesn't like my
> ISP's SMTP output server.
Right. In either case, the message delivery attempt failed. The actual
reason why the delivery attempt failed is irrelevant. Whatever the reason
is, the sending mail server always does the exact same thing: return the
message as undeliverable. It may matter to you, but it does not matter to
the mail server.
> So to re-cap:
>
> - Which of these 5.x.x codes indicates an incorrect recipient
> address, vs a failed delivery attempt based on some characteristic
> of the sender?
Nobody cares. Doesn't matter. The message, in either case, gets returned as
undeliverable.
> - Why are there 5.x.x AND 5yy codes, and why are they used
They are two different things. An smtp status code, and an extended error
message. But it's generally irrelevant, as far as the mail delivery status
is concerned.
> simultaneously in the same error message, and why is their use
> not consistent (specifically, 550 and 554) ?
It is perfectly consistent. All 5xx status codes mean exactly the same
thing: the message is undeliverable.
Spam Guy
> It is perfectly consistent. All 5xx status codes mean exactly the
> same thing: the message is undeliverable.
Why did you even bother to compose a reply?
There was absolutely no useful information content in your response.
Spam Guy
> > Why did you even bother to compose a reply?
> >
> > There was absolutely no useful information content in your
> > response.
>
> Just because you did not understand it, does not mean that
> there was no useful information.
There was nothing to understand.
All you said was that any server can do what it wants.
That is not new information.
Thor Kottelin
news:4BD1053E...@Guy.com...
> Sam wrote:
>
>> It is perfectly consistent. All 5xx status codes mean exactly the
>> same thing: the message is undeliverable.
> There was absolutely no useful information content in your response.
If you would prefer an answer that may be less useful but more in line
with the question as you phrased it: I suggest reading the relevant
sections of RFCs 821, 5321, 3463, 4468, 4954 and 5248. Those documents
explain, among others, the difference between reply codes, enhanced status
codes and text strings.
Follow-ups set.
--
Thor Kottelin
http://www.anta.net/
Spam Guy
> If you would prefer an answer that may be less useful but more in
> line with the question as you phrased it: I suggest reading the
> relevant sections of RFCs 821, 5321, 3463, 4468, 4954 and 5248.
> Those documents explain, among others, the difference between
> reply codes, enhanced status codes and text strings.
Will reading those RFC's tell me if code 5.1.1 indicates an incorrect
(non-existant) address, or if it indicates a server policy of not
accepting my message for an otherwise correct address. ?
Will reading those RFC's tell me the difference between 5.1.0, 5.1.1,
5.4.1 and 5.2.0?
Will reading those RFC's tell me why there seems to be two different
error-message constructs or formats (5.x.x and 5yy), and explain why
they are frequently used simultaneously?
MrD
You want someone to read them for you? Shit, just looking at the titles
would have been quicker than composing that post; e.g. "RFC 3463
(rfc3463) - Enhanced Mail System Status Codes".
--
MrD.
Sam
> Thor Kottelin wrote:
>
>> If you would prefer an answer that may be less useful but more in
>> line with the question as you phrased it: I suggest reading the
>> relevant sections of RFCs 821, 5321, 3463, 4468, 4954 and 5248.
>> Those documents explain, among others, the difference between
>> reply codes, enhanced status codes and text strings.
>
> Will reading those RFC's tell me if code 5.1.1 indicates an incorrect
> (non-existant) address, or if it indicates a server policy of not
> accepting my message for an otherwise correct address. ?
>
> Will reading those RFC's tell me the difference between 5.1.0, 5.1.1,
> 5.4.1 and 5.2.0?
Why don't you read them, and report back to us.
Inquiring minds want to know.
Spam Guy
> > All you said was that any server can do what it wants.
> >
> > That is not new information.
>
> It was obviously new, to the OP.
You might want to think it was new - but it wasn't.
Spam Guy
> Why don't you read them, and report back to us.
RFC 821 defines the SMTP reply code as follows:
--------------
An SMTP reply consists of a three digit number (transmitted as three
alphanumeric characters) followed by some text. The number is intended
for use by automata to determine what state to enter next; the text is
meant for the human user.
-------------
These are 3 digit codes that are not separated by periods.
It lists the following codes which all *seem* to be related to the use
of an incorrect (non-functional) destination email address:
251 User not local; will forward to <forward-path>
450 Requested mail action not taken: mailbox unavailable
[E.g., mailbox busy]
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
451 Requested action aborted: error in processing
551 User not local; please try <forward-path>
452 Requested action not taken: insufficient system storage
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed
[E.g., mailbox syntax incorrect]
554 Transaction failed
RFC 821 does not explicitly state that it proposes to arrange the codes
in terms of logical groups. It does not explain or define a structure
whereby codes 1xx, 2xx, 3xx (etc) are meant to denote groupings of error
conditions which do not overlap each other (which would have been
logical). The codes listed seem like a hap-hazzard list with little
thought to hierarchical structure. For example, code 450 is listed as
"mailbox unavailble", but so too is code 550. Same with 452 and 552.
RFC 5321 has a section called "Reply Codes by Function Groups" but this
does not actually describe these functional groups, but instead simply
lists individual codes much the same way as RFC 821. The ad-hoc nature
of this code structure was cast in RFC 821, and 5321 continues this with
no refinement or alteration.
RFC 3463 seems to recognize the poor organization state of these codes
because it's title is "Enhanced Mail System Status Codes". From the
overview of 3463:
--------------
There is a need for a standard mechanism for the reporting of mail
system errors richer than the limited set offered by SMTP and the system
specific text descriptions sent in mail messages. There is a pressing
need for a rich machine-readable, human language independent status code
for use in delivery status notifications [DSN]. This document proposes
a new set of status codes for this purpose.
--------------
RFC 3463 originates the 3-digit code sequence separated by periods as
follows:
status-code = class "." subject "." detail
class = "2"/"4"/"5"
subject = 1*3digit
detail = 1*3digit
I have never seen error codes implimented exactly along these lines.
This scheme calls for up to 3 digits to be used between periods, but I
have never seen more than a single digit in actual use.
The classes used by RFC 3463 seem to originate in the interpretation of
the original goals of the codes defined by 821. These classes are:
2.XXX.XXX Success
4.XXX.XXX Persistent Transient Failure
5.XXX.XXX Permanent Failure
It's unfortunate that this code scheme was not designed around the needs
of end-users, who simply want to know if their message was delivered -
and if not, was it because they got the destination address wrong during
composition.
According to 3463, the code that I see most often is this:
X.1.1 Bad destination mailbox address
----------------
The mailbox specified in the address does not exist. For Internet mail
names, this means the address portion to the left of the "@" sign is
invalid. This code is only useful for permanent failures
----------------
Why so many servers formulate various different "friendly" messages to
go along with this code is bizarre:
5.1.1 User unknown
5.1.1 Invalid recipient
5.1.1 Diagnostic-Code: smtp; 550 No such user
5.1.1 550 Requested action not taken: mailbox unavailable
5.1.1 Recipient address rejected: undeliverable address
5.1.1 Recipient address rejected: User unknown in virtual alias table
5.1.1 Recipient address rejected: User unknown in local recipient table
5.1.1 Recipient address rejected: User unknown in relay recipient table
RFC 3463 gives this definition for X.4.a:
-----------------
Code X.4.1 No answer from host
The outbound connection attempt was not answered, because either the
remote system was busy, or was unable to take a call. This is useful
only as a persistent transient error.
----------------
Yet in actual usage, I've recieved this:
5.4.1 Recipient address rejected: Access Denied
The friendly message does not seem related to RFC intention.
Codes x.7.x are defined as relating to Security or Policy Status, and
their usage seems to match the friendly messages that I've seen.
So basically the use of 2 different error reporting styles arises from
the desire to support both the original and enhanced reporting code
schemes.
In my opinion, the enhanced scheme defined by 3463 should have specified
an exact friendly string that should be used with the listed codes.
And it appears that some servers or SMTP software is using the 5.1.1
return code when they should be using a 5.7.x code.
I haven't looked at RFC's 4468, 4954 and 5248, but I don't suppose they
propose anything new or different in terms of the usage of these
response codes.
Sam Wrote:
> You may attempt to interpret the mail server's error message. But
> there is no universal, global, uniform set of error codes that
> all mail servers use. There is no such thing.
You incorrectly claim that there is no "universal, global, or uniform
set of error codes that all mail servers use", but there really is no
evidence to support such a specious claim.
There clearly *IS* a uniform set of codes, and I don't believe I've ever
seen an error code or error message that didn't mention such a code.
That some of these codes are used incorrectly is another matter.
Sam
> Sam Wrote:
>
>> You may attempt to interpret the mail server's error message. But
>> there is no universal, global, uniform set of error codes that
>> all mail servers use. There is no such thing.
>
> You incorrectly claim that there is no "universal, global, or uniform
> set of error codes that all mail servers use", but there really is no
> evidence to support such a specious claim.
It is sheer folly to expect proof of a negative.
> There clearly *IS* a uniform set of codes, and I don't believe I've ever
> seen an error code or error message that didn't mention such a code.
Maybe in your world every mail server uses an identical set of SMTP status
codes, but that's clearly not the case on my world.
Spam Guy
> > You incorrectly claim that there is no "universal, global, or
> > uniform set of error codes that all mail servers use", but
> > there really is no evidence to support such a specious claim.
>
> It is sheer folly to expect proof of a negative.
Then why did you put forward a statement that can't be proved?
Isin't that "sheer folly" ?
> > There clearly *IS* a uniform set of codes, and I don't believe
> > I've ever seen an error code or error message that didn't
> > mention such a code.
>
> Maybe in your world every mail server uses an identical set
> of SMTP status codes, but that's clearly not the case on my
> world.
Does your world use something different than a set of 3-digits
(sometimes separated by periods) ?