Notification message format

The MTA generates standard notification messages (DSNs and MDNs) in the formats defined by the respective Internet standards, in particular  RFC 3462 and RFC 3464 in the case of DSNs, and  RFC 3798 in the case of  MDNs. Shown in Example non-delivery DSN is a sample non-delivery DSN with annotations.  Example non-delivery DSN

Return-Path: &#x3c;&#x3e;                                                     (1) Received: from process-daemon.host1.domain.com by host1.domain.com (Sun Java (2) System Messaging Server 6.2-3.04 (built Jul 15 2005)) id   &#x3c;0JRJ00301JFFR300@host1.domain.com&#x3e; for user1@domain.com (ORCPT       user1@domain.com); Thu, 15 Nov 2007 01:25:45 -0800 (PST) Received: from host1.domain.com (Sun Java System Messaging Server 6.2-3.04  (built Jul 15 2005)) id &#x3c;0JRJ0038FJIWYS00@host1.domain.com&#x3e; for     (3) user1@domain.com (ORCPT user1@domain.com); Thu, 15 Nov 2007 01:25:45 -0800 (PST) Date: November 15, 2007 1:25:45 AM -0800 (PST) From: Internet Mail Delivery &#x3c;postmaster@host1.domain.com&#x3e;          (4) Subject: Delivery Notification: Delivery has failed                 (5) To: user1@domain.com Message-Id: &#x3c;0JRJ0038MJIXYS00@domain.com&#x3e; Mime-Version: 1.0 Content-type: multipart/report;                                     (6) boundary="Boundary_(ID_7qPwt/LotX5gy1oVEHL7SQ)"; report-type=delivery-status Original-Recipient: rfc822;user1@domain.com --Boundary_(ID_7qPwt/LotX5gy1oVEHL7SQ) Content-type: text/plain; charset=us-ascii                          (7) Content-language: en-US Content-transfer-encoding: 7BIT This report relates to a message you sent with the following header fields: (8) Message-id: &#x3c;01MZZ7DIEUG400LXL0@host1.domain.com&#x3e;                 (9) Date: Thu, 15 Nov 2007 01:23:18 -0800 (PST) From: user1@domain.com To: bogus@remote.com Subject: test to generate a bounce -- please ignore Your message cannot be delivered to the following recipients:       (10) Recipient address: bogus@remote.com                               (11) Original address: bogus@remote.com                                (12) Reason: Remote SMTP server has rejected address Diagnostic code: smtp;550 5.1.1 &#x3c;bogus@remote.com&#x3e;... User unknown Remote system: dns;mx1.remote.com (TCP&#x7c;129.146.11.74&#x7c;42429&#x7c;129.156.85.165&#x7c;25) (sunmail5.uk.sun.com ESMTP Sendmail 8.13.8+Sun/8.13.7/ENSMAIL,v2.2;   Thu, 15 Nov 2007 09:25:44 GMT) (13)(14) --Boundary_(ID_7qPwt/LotX5gy1oVEHL7SQ) Content-type: message/delivery-status                               (15) Original-envelope-id: 01MZZ7DIEUG400LXL0@host1.domain.com Reporting-MTA: dns;host1.domain.com (tcp-daemon)                    (16) (17) Original-recipient: rfc822;bogus@remote.com                         (18) Final-recipient: rfc822;bogus@remote.com                            (19) Action: failed Status: 5.1.1 (Remote SMTP server has rejected address) Remote-MTA: dns;mx1.remote.com (TCP&#x7c;129.146.11.74&#x7c;42429&#x7c;129.156.85.165&#x7c;25) (sunmail5.uk.sun.com ESMTP Sendmail 8.13.8+Sun/8.13.7/ENSMAIL,v2.2; Thu, 15  Nov 2007 09:25:44 GMT) Diagnostic-code: smtp;550 5.1.1 &#x3c;bogus@remote.com&#x3e;... User unknown --Boundary_(ID_7qPwt/LotX5gy1oVEHL7SQ) Content-type: message/rfc822 Return-path: &#x3c;user1@domain.com&#x3e;                                     (20) Received: from &#x5b;129.158.87.66&#x5d; by host1.domain.com (Sun Java System Messaging (21)  Server 6.2-3.04 (built Jul 15 2005)) with ESMTPA id   &#x3c;01MZZ7D1WINK00LXL0@host1.domain.com&#x3e; for bogus@remote.com (ORCPT   bogus@remote.com); Thu, 15 Nov 2007 1:25:08 -0800 (PST) Date: Thu, 15 Nov 2007 01:23:18 -0800 (PST) From: user1@domain.com Subject: test to generate a bounce -- please ignore To: bogus@remote.com Message-id: &#x3c;01MZZ7DIEUG400LXL0@host1.domain.com&#x3e; MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT test --Boundary_(ID_7qPwt/LotX5gy1oVEHL7SQ)-- 

  As with all standard notification messages,   the envelope From is empty, as shown/recorded here in the Return-path:    header line. 

  By default, notification messages are   enqueued to the process channel;   but see the    channel option. Note that   the Received: header line below this one---the very "first"    (in time) Received: header line---corresponds to the initial enqueue of    the notification message from the channel that determined that a    notification message was needed to the process channel. (If the initial   channel that determined that a notification message was needed had a      specified other than the process    channel, the initial enqueue would instead have been to that alternate     .) Thus by default (no      used) this second-from-the-bottom    Received: header line, this second-from-oldest Received: header line,    on any notification message generated by the Messaging Server MTA,    will show the notification message coming from the process channel. 

  Note the   "  "    clause present in this Received: header line. That such a clause is   present shows that at this point in time, the message had only one    recipient, and that the (default)     channel option was in  effect. Note   that the fact that there was only one recipient for the message at that    point (initial enqueue to the process channel),   indicates that the    postmaster was not being copied on this notification: that one of      or     was in effect. 

  By default, the MTA-wide postmaster address   is used in the From: header line for notifications; see the      and     MTA options. But override postmaster addresses may be set on a   per-channel basis (see the      and     channel options), or on a per-domain basis    (see the   attribute, or more    precisely, the attribute named by the        MTA option), or on a    per-message basis via the      mapping table&#x27;s     or   flags. 

  The Subject: field for DSNs has the default   text shown in  Table of DSN types and their default Subject:   field text. The default may be overridden for all   types of DSNs using the   SUBJECT option in the    file, or may be overridden on a    per-type-of-DSN basis using the   flag of the      mapping table. </li>

 <span id='call_049'> DSNs at the outermost MIME level have type: Content-type: multipart/report; ... report-type=delivery-status </li>

 <span id='call_050'> The MIME header lines for the first message   part (the human-readable part) are controlled by the    file. Which language-specific  file is used may    be controlled by the       mapping table. </li>

 <span id='call_051'> This line (or optionally multiple lines) of   introductory text is also set in the      file. Normally,  also includes a      substitution to cause insertion of (a sample of) the    original message headers. </li>

 <span id='call_052'> The    file controls exactly which    header lines a   substitution inserts. The     substitution itself is located in the language-specific      file. </li>

 <span id='call_053'> This line of text is set in the appropriate     file, corresponding to the type of DSN being generated:     ,  ,  ,     ,  ,  ,     ,  ,  ,     , or. In the case of this sample   DSN, this is a " " DSN (the original    message could not be delivered), so the      file sets the line of text, as well as causing insertion of a list of    the message&#x27;s recipients via a   substitution. </li>

 <span id='call_054'> If the relevant     file requested it via a   substitution, then a    description of the recipients of the original message (and what    happened for each such recipient) will be included. (Note tht the exact form of recipient address reported as  "Recipient address:" may be affected by the setting on the source   channel -- the channel generating the notification -- of   ,  ,   or  .)   Overall, this is intended as    a more human-readable version of the information also presented (in    standard, machine-readable form) in the second part of the DSN, at    (17). In particular, the text labels for each of   these fields (e.g., " Recipient address: "---note    the two leading spaces as well as the terminal colon and trailing space    are considered part of the label) are configurable via the    language-specific        file (selected via the      mapping table). </li>

 <span id='call_055'> Optionally, additional, alternate text can be   configured per SMTP enhanced status code (e.g., in this    example 5.1.1); if such alternate text has been configured in the      file corresponding to the enhanced    status code being reported, then it would be presented after the    "Original address: "    (ORIGINAL_ADDRESS) line    and before the "Reason: "    (REASON) line. </li>

 <span id='call_ex1'> If the     MTA option is enabled (the default) and the original message has a history of   delivery attempts, then some delivery history, up to the limit specified by  , will be  included here (after the   recipient information),   having the format: Delivery attempt history for your mail: time-stamp'delivery-detail'time-stampdelivery-detail ... </li>

 <span id='call_ex2'> Note that the   file used when generating a delayed delivery warning often  includes additional text after the   recipient substitution, (and hence after any delivery history detail, as discussed in (13)),  detailing how much longer the MTA will continue to attempt delivery. For instance, the distributed English language version of   causes inclusion of text: The mail system will continue to try to delivery your message for an additional N time-units. where   is derived from the  final value, and   is derived from the    setting.

</li>

 <span id='call_056'> This second part of a DSN is a   machine-readable part. Note that unlike the first, human-readable part   of a DSN, see (7), the machine-readable part is    not subject to customization/localization/alternate language    selection. This part uses the format and fields specified in   RFC 3464    (An Extensible Message Format for Delivery Status Notifications). Because this part is in a precisely specified, machine-readable format,   clients or gateways that choose to do so can in principle make choices    of their own on how and whether to present this part to users,    potentially including performing their own (client or gateway level)    translation of the (precisely defined) content of this part. </li>

 <span id='call_057'> The reporting MTA (the MTA that is   generating the notification message) is reported here. Note that this   is not necessarily the MTA that rejected the message: as in the case of    this example, where the rejection occurred at the SMTP protocol level,    with the message being rejected by a remote host, but where the    "local" MTA then had responsibility for generating the    notification message. Note also that the Received: header lines on the   DSN itself---in particular the first (in time, so lowest in the header)    Received: header line---also show you what MTA generated the DSN. But   whichever place you gather this piece of information from, note that it    is a critical piece of information: you can only    customize the    DSNs that your system generates! </li>

 <span id='call_058'> Some additional fields can potentially appear   here, including X400-Content-identifier:, Content-identifier:, and    UA-content-id:. As of MS 7.0, Arrival-date: and   Future-release-request: also may potentially appear. </li>

 <span id='call_059'> A set of information fields is output for   each of the recipients of the original message, describing what    happened for that recipient. </li>

 <span id='call_060'> The exact form of recipient address reported as the  "Final-recipient:" may be affected by the setting on the source channel   (the channel generating the notification) of    ,  ,   or. </li>

 <span id='call_061'> The Return-path: records the envelope From of   the original message. </li>

 <span id='call_062'> The third and final part of the DSN contains   the original message (or merely the headers of the original message, if    the sender originally set the NOTARY non-return-of-content flag, or if    the MTA was obliged to set or perform non-return-of-content due to    message size restrictions). The entire header of the original message   is included. </li>

</ol>

The MTA generates "autoreply" or "vacation" messages, whether requested due to the  use of    attributes in a user&#x27;s LDAP entry, or  requested due to explicit use of the  " "  action in a user&#x27;s Sieve filter, as a form of notification message  also. Such "vacation" messages may optionally be generated either in standard MDN format, or (for the benefit of recipients whose  user agents lack good handling for standard MDN messages) as more  "simple" messages consisting of a single text part. (Standard MDN format for a "vacation" message is requested by use of    in the user&#x27;s LDAP entry, or use  of the   argument to a   action in  the user&#x27;s Sieve script. The "simple" form of  "vacation" message is requested by use of    in the user&#x27;s LDAP entry, or use  of the   argument to a   action  in the user&#x27;s Sieve script.)

Selective choice of language used in, and customization of the contents of, notification messages is possible, as discussed in  DSN language and customization  and  MDN language and customization  below. But keep in mind that any such language usage and customization must be  within the guidelines of the overall  notification message format, which in many cases is prescribed by the  above-mentioned Internet standards.

See also:
 * DSN language and customization
 * MDN language and customization
 * NOTIFICATION_LANGUAGE and DISPOSITION_LANGUAGE sample mapping tables
 * Process and reprocess channels
 * notificationchannel Option
 * receivedfor Option
 * errsendpost Option
 * nosendpost Option
 * return_address MTA Option
 * return_personal MTA Option
 * returnaddress Option
 * returnpersonal Option
 * ldap_domain_attr_report_address MTA Option
 * FROM_ACCESS mapping table
 * langdir MTA Option
 * The sample header lines in DSNs: the return_header.opt file
 * The required full set of DSN type-specific return_...txt files
 * includefinal Option
 * suppressfinal Option
 * useintermediate Option
 * The optional return_option.opt file
 * return_delivery_history MTA Option
 * history_to_return MTA Option
 * notices Option
 * return_units MTA Option
 * DSN language and customization
 * Sieve vacation extension
 * MDN language and customization
 * Notification messages