You are here probably because you got email which begins like this:
This is a collection of reports about email delivery
process concerning a message you originated.
Some explanations/translations for these reports
can be found at:
http://www.zmailer.org/delivery-report-decoding.html
The ZMailer Message Transport Agent software produces varying reports for messages going thru it, depending what is happening to the message, and what user has requested to be informed about.
Sometimes people maintaining systems running this software are getting questions in style of: "What this (report) means in language XYZ?"
Unfortunately the original Internet Mail environment[1][2] creators were purely English speaking (American), and thus all supplementary texts created by systems were created in English, only. (And back then the language question was not something to be worried about.)
Now latter as user population has grown, even most English speakers can't understand the often terse technical jargon explanations for diagnostics given in the classical SMTP[1] email transfer environments, and it has become necessary to augment that information with some additional details, plus enabling Mail User Agents to be written which could present the formal (machine readable) sections in a language[3] which the user wishes to see.
These Delivery Report messages are structured messages per specification RFC1894 [5], which has parts:
The purpose of this formal structure is to support MUA software so that they can decode and present numeric codes present in the formal part in user chosen language.
If Your MUA software is unable to do that presentation, You should ask your software vendor, when will they provide such a version.
The formal part contains ``Action:'' elements which carry one of these four tags:
This does not mean that the recipient has read the message!
(This recipient address may yet report other kind of reports, but not DELIVERED.)
To: sender@domain
From: The Post Office <postmaster@local.server>
Subject: Delivery reports about your email [FAILED(1)]
Date: Wed, 1 Mar 2000 15:20:53 +0200
[-- Appendix #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 1.7K --]
This is a collection of reports about email delivery
process concerning a message you originated.
Some explanations/translations for these reports
can be found at:
http://www.zmailer.org/reports.html
FAILED:
<smtp some.server.dom user.name@some.server.dom 99>: ...\
expired after 3 days, problem was:
smtp; 500 (connect to some.server.dom [11.22.33.44|25|55.66.77.88|1879]: Connection refused)
FAILED:
<smtp other.server.dom user@other.server.dom 60000>: ...\
<<- RCPT To:<user@other.server.dom> ORCPT=rfc822;user@other.server.dom
->> 550 <user@other.server.dom>... Relaying denied
FAILED:
<smtp other.server.dom user@other.server.dom 60000>: ...\
<<- RCPT To:<user@other.server.dom> ORCPT=rfc822;user@other.server.dom
->> 552 <user@other.server.dom>... Unknown User
[ Removed second and third appendix contents from this. ]
[-- Appendix #2 --]
[-- Type: message/delivery-status, Encoding: 7bit, Size: 0.5K --]
Reporting-MTA: dns; local.server
Arrival-Date: Wed, 1 Mar 2000 15:19:53 +0200
Local-Spool-ID: S92519AbQCANTx
Original-Recipient: rfc822;user.name@some.server.dom
Final-Recipient: RFC822;user.name@some.server.dom
Action: failed
Status: 5.4.1 (TCP/IP-connection failure)
Diagnostic-Code: smtp; 500 (connect to some.server.dom [11.22.33.44|25|55.66.77.88|1879]: Connection refused)
Remote-MTA: dns; somemx.server.dom (11.22.33.44|25|55.66.77.88|1879)
Last-Attempt-Date: Wed, 1 Mar 2000 15:20:53 +0200
Original-Recipient: rfc822;user@other.server.dom
Final-Recipient: RFC822;user@other.server.dom
Action: failed
Status: 5.1.1 (bad destination mailbox)
Diagnostic-Code: smtp; 550 (<user@other.server.dom>... Relaying denied)
Remote-MTA: dns; mx.third.dom (22.33.44.55|25|55.66.77.88|2345)
Last-Attempt-Date: Wed, 1 Mar 2000 15:20:53 +0200
Original-Recipient: rfc822;user@other.server.dom
Final-Recipient: RFC822;user@other.server.dom
Action: failed
Status: 5.1.1 (bad destination mailbox)
Diagnostic-Code: smtp; 550 (<user@other.server.dom>... Unknown User)
Remote-MTA: dns; mx.third.dom (22.33.44.55|25|55.66.77.88|2345)
Last-Attempt-Date: Wed, 1 Mar 2000 15:20:53 +0200
[-- Appendix #3 --]
[-- Type: message/rfc822, Encoding: 7bit, Size: 0.2K --]
From: Sender <sender@domain>
To: user.name@some.server.dom
Cc: user@other.server.dom
Subject: demo
Date: Wed, 1 Mar 2000 15:19:53 +0200
demo
This may be radically different from ``Original-Recipient'' in some cases, which may make original address identification rather difficult without the DSN ORCPT facility.
Tells what happened to the message:
This does not mean that the recipient has read the message!
(This recipient address may yet report other kind of reports, but not DELIVERED.)
User's Mail User Agent (MUA) should use this code to explain to user in user's desired language what the message treatment was.
If report has ``Action: DELAYED'', other reports may well appear latter.
Usually indicating problems at remote servers.
This is a configuration error somewhere, either at the destination domain DNS service, or at relay servers configurations.
The numeric status codes are defined at RFC 1893 [4].
Like any codesets, these are not quite adequate for all uses, but better than original ones at the SMTP [1], which use very few codes to simply indicate that an error has occurred without giving numeric explicite code about what the error really is about.
The codes look like following:
2.2.0 4.5.3 5.7.1
That is, three decimal digits with dots in between.
This supplies rough classification on the codes:
Success specifies that the DSN is reporting a positive delivery action. Detail sub-codes may provide notification of transformations required for delivery.
A persistent transient failure is one in which the message as sent is valid, but some temporary event prevents the successful sending of the message. Sending in the future may be successful.
A permanent failure is one which is not likely to be resolved by resending the message in the current form. Some change to the message or the destination must be made for successful delivery.
There is no additional subject information available.
The address status reports on the originator or destination address. It may include address syntax or validity. These errors can generally be corrected by the sender and retried.
Mailbox status indicates that something having to do with the mailbox has cause this DSN. Mailbox issues are assumed to be under the general control of the recipient.
Mail system status indicates that something having to do with the destination system has caused this DSN. System issues are assumed to be under the general control of the destination system administrator.
The networking or routing codes report status about the delivery system itself. These system components include any necessary infrastructure such as directory and routing services. Network issues are assumed to be under the control of the destination or intermediate system administrator.
The mail delivery protocol status codes report failures involving the message delivery protocol. These failures include the full range of problems resulting from implementation errors or an unreliable connection. Mail delivery protocol issues may be controlled by many parties including the originating system, destination system, or intermediate system administrators.
The message content or media status codes report failures involving the content of the message. These codes report failures due to translation, transcoding, or otherwise unsupported message media. Message content or media issues are under the control of both the sender and the receiver, both of whom must support a common set of supported content-types.
The security or policy status codes report failures involving policies such as per-recipient or per-host filtering and cryptographic operations. Security and policy status issues are assumed to be under the control of either or both the sender and recipient. Both the sender and recipient must permit the exchange of messages and arrange the exchange of necessary keys and certificates for cryptographic operations.
The third digit (x.x.N) is meaningfull only in connection with the middle-digit. The list is long, and therefore not included in here.
Full details are available in English: See part 3 of RFC 1893 [4].
No single programmer(team) can create software which is able to give meaningfull text in all of those languages, especially when protocols carrying other information don't begin protocol exchanges with language and characterset information exchange...