DSNs
This page contains notes about DSNs generated by various MTAs.
sendmail
Here is an excerpt from a DSN generated by sendmail 8.12.11 .
The DSN conforms to RFC 3464 .
The original message was received at Sun, 27 Aug 2006 22:03:44 +0200
from localhost.localdomain [127.0.0.1]
----- The following addresses had permanent fatal errors -----
<hjp@wsr.ac.at>
(reason: 550 <nagios@aragorn.wsr.ac.at> doesn't exist according to 143.130.16.20: 550 no such user <nagios@ar...n.wsr.ac.at>. Unchanged since 2006-08-27T22:03:49+0200, next check 2006-08-27T22:03:49+0200 (#5.1.8))
----- Transcript of session follows -----
... while talking to samkar.wsr.ac.at.:
>>> DATA
<<< 550 <nagios@aragorn.wsr.ac.at> doesn't exist according to 143.130.16.20: 550 no such user <nagios@aragorn.wsr.ac.at>. Unchanged since 2006-08-27T22:03:49+0200, next check 2006-08-27T22:03:49+0200 (#5.1.8)
550 5.1.1 <hjp@wsr.ac.at>... User unknown
<<< 503 RCPT first
The (very long) message text has been shortened to about 200 characters by omitting some characters in the middle (marked like this ). Unfortunately, that obscured the email address. The message is complete in the transscript though, so no information is lost.
postfix vs. lotus domino
This example is seriously fubared. The DSN was created by postfix, but received by a lotus domino server. The message/delivery-status part looks ok, the explanatory part at the beginning was completely replaced by the domino server (postfix DSNs contain different text), and the Received headers were rearranged:
Received: from igsorian.wsr.ac.at ([143.130.16.20]) by spiridon01.wsr.ac.at (Lotus Domino Release 7.0) with ESMTP id 2006082813472811-858 ; Mon, 28 Aug 2006 13:47:28 +0200 Received: from hermes.wsr.ac.at (HELO hermes.wsr.ac.at) (143.130.50.113) by samkar.wsr.ac.at (qpsmtpd/0.32) with ESMTP; Mon, 28 Aug 2006 13:47:26 +0200 Received: by hermes.wsr.ac.at (Postfix) id 05029701D; Mon, 28 Aug 2006 13:47:25 +0200 (CEST) Received: from [143.130.50.123] (bernon.wsr.ac.at [143.130.50.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.wsr.ac.at (Postfix) with ESMTP id A5E547018 for <schul22@wsr.ac.at>; Mon, 28 Aug 2006 13:47:23 +0200 (CEST) Message-ID: <44F2D7CB.8060700@wsr.ac.at>
These are the Received headers from the DSN. In fact these are a mixture from the original mail (which was sent from bernon to hermes, which couldn't forward the mail) and the DSN (which originated at hermes and was sent via samkar to spiridon01 (the domino server). The Message-ID is also the ID from the original mail: The DSN had the Message-ID <20060828114725.05029701D@hermes.wsr.ac.at>
Received: from igsorian.wsr.ac.at ([143.130.16.20]) by spiridon01.wsr.ac.at (Lotus Domino Release 7.0) with ESMTP id 2006082813472811-858 ; Mon, 28 Aug 2006 13:47:28 +0200 Received: from hermes.wsr.ac.at (HELO hermes.wsr.ac.at) (143.130.50.113) by samkar.wsr.ac.at (qpsmtpd/0.32) with ESMTP; Mon, 28 Aug 2006 13:47:26 +0200 Received: by hermes.wsr.ac.at (Postfix) id 05029701D; Mon, 28 Aug 2006 13:47:25 +0200 (CEST) Message-ID: <44F2D7CB.8060700@wsr.ac.at>
These are the received headers quoted as part of the bounced mail. In fact these seem to be the real received headers of the DSN, the received headers of the original mail have been moved to the Received headers of the DSN.
And here is how this looks in the web interface: There is again a different explanation, and you can't look at the Received headers so it doesn't matter that they're wrong. The suggestion to send the mail again doesn't look very reasonable for the error message "550 no such user" (but maybe the suggestions would be better if the error message contained an extended status code.
postfix
This is almost the same as the postfix+domino example above, but this time the DSN was delivered to another postfix system.
The received headers of the DSN ...
Received: from igsorian.wsr.ac.at (samkar.wsr.ac.at [143.130.16.20]) by bernon.wsr.ac.at (Postfix) with ESMTP id 81879A048 for <hjp@bernon.wsr.ac.at>; Mon, 28 Aug 2006 15:14:51 +0200 (CEST) X-Spam-Status: No, hits=-1.2 required=5.0 tests=ALL_TRUSTED,MAILTO_TO_SPAM_ADDR X-Spam-Check-By: samkar.wsr.ac.at Received: from hermes.wsr.ac.at (HELO hermes.wsr.ac.at) (143.130.50.113) by samkar.wsr.ac.at (qpsmtpd/0.32) with ESMTP; Mon, 28 Aug 2006 15:14:47 +0200 Received: by hermes.wsr.ac.at (Postfix) id B5AAA7020; Mon, 28 Aug 2006 15:14:46 +0200 (CEST)
... and the quoted bounced mail ...
Received: from [143.130.50.123] (bernon.wsr.ac.at [143.130.50.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.wsr.ac.at (Postfix) with ESMTP id 68981701D for <schul22@wsr.ac.at>; Mon, 28 Aug 2006 15:14:45 +0200 (CEST)
... look ok.
The explanatory text ...
This is the Postfix program at host hermes.wsr.ac.at. I'm sorry to have to inform you that your message could not be be delivered to one or more recipients. It's attached below. For further assistance, please send mail to <postmaster> If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program: host samkar.wsr.ac.at[143.130.16.20] said: 550 no such user (in reply to RCPT TO command)
... doesn't contain a transscript like sendmail's DSNs but at least the relevant error message and the context that it occured in. The address <postmaster> is unfortunately hard-coded and not very useful. It would be better if it could be changed to the postmaster of the reporting MTA.
The DSN conforms to RFC 3464 .
Microsoft Exchange
DSN messages from MS-Exchange also conform to the letter of RFC 3464 and there seems to be no funny stuff like rewriting recipient headers going on. However, neither the explanatory text ...
This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. michael.ramprecht@bbg.gv.at
... nor the status-notification ...
Reporting-MTA: dns;BBG-00-6.bbg.local Received-From-MTA: dns;brzmg-fb00.pab.local Arrival-Date: Mon, 21 Aug 2006 16:14:53 +0200 Final-Recipient: rfc822;michael.ramprecht@bbg.gv.at Action: failed Status: 5.1.1
... normally contain any human-readable hint as to why the delivery failed. Those who know about RFC 3463 can look up status code 5.1.1 and find that it means "Bad destination mailbox address".
qmail
DSN messages from qmail don't conform to RFC 3464, but use a qmail-specific format called QSBMF . The information included is basically the same (a human-readable problem description, the exact error message per failed recipient, the bounced message including full headers), but everything is in a single text/plain part.
The error messages frequently (but not always) have blanks replaced by underscores, and extended status codes are sometimes included in in the format (#X.Y.Z):
<st.idle@aon.at>: 195.3.96.71_failed_after_I_sent_the_message./Remote_host_said:_554_mail_server_rejected_message:_spam_or_virus_detected_(#5.3.0)/
exim
DSN messages from exim look similar to those from qmail. The information included is basically the same (a human-readable problem description, the exact error message per failed recipient, the bounced message including full headers) as in RFC 3464, but everything is in a single text/plain part.
The example shows a multi-line response:
a9103103@imap.unet.univie.ac.at (generated from a9103103@unet.univie.ac.at) SMTP error from remote mail server after RCPT TO:<a9103103@imap.unet.univie.ac.at>: host imap.unet.univie.ac.at [131.130.221.38]: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown
Kerio Mailserver
Kerio Mailserver doesn't send RFC 3464 conforming messages. The message is a simple text containing the reason and some headers. The headers don't include the message-id.
This is an informative message sent by Kerio MailServer 6.0.10 at mailserver. Your mail message did not pass the server content filter: From:To: To: Subject: Fwd: Re: ITS ME ALEX. Date: Tue, 19 Sep 2006 01:06:26 +0200 Problem: Virus found MIME type: application/x-zip-compressed File name: KODAK_FOTO_62.zip Virus name: Downloader-ZL Antivirus: McAfee Scanning Engine (4853/4.4.00) All invalid attachments of the message were deleted and the message was delivered to the recipient.
There are two other notable facts about this DSN:
- It is a DSN concerning a detected virus. Almost all viruses today use faked return paths, so sending DSNs is not useful.
- The DSN is actually a "delivery status notification", not a "non-delivery status notification".