Notification message types

The MTA may generate notification messages itself automatically. These may be Delivery Status Notifications (see RFCs 3461-3464, which are  updates to RFCs 1891-1894),  such as a notification of a successful message delivery (a so-called  "delivery receipt"), or a  warning to the original message sender that the delivery of their  message has been delayed or has failed. The MTA can also optionally (see the   and     channel options) generate notifications to the  postmaster regarding  failed and/or delayed message delivery; such a notification to the  postmaster is more-or-less a copy of the notification going back to the  original message sender. (In particular, note that the postmaster gets a copy in the same language chosen based upon the original sender&#x27;s language selection.)

Or MTA-generated notification messages may be Message Disposition Notifications (see RFC 3798, which updated RFC 2298) generated due to  Sieve filter actions such as. Note that a common case of Message Disposition Notifications is the case of so-called  "read receipts", which in Message Disposition Notifications  correspond to a disposition of "displayed" (since whether or  not a user actually read a message is a subjective question  for the user, whereas the display of a message is something  mail user agent software can detect); in any case, such "read  receipt" notifications are generated by end user mail clients,  not by the MTA (which merely relays them as with any other  message).

The MTA will also automatically generate notification messages (DSN format messages of "error" type) to report certain sorts of  syntax errors. Syntax errors in Sieve filters will be reported to the  "responsible" address via a notification message: syntax  errors in channel level Sieve filters or  the system Sieve filter    (or in legacy configuration, the  CONFIGROOT  file, located prior to MS 7.0.5 via the    MTA Tailor option) will be reported to the postmaster;  syntax errors in user Sieve filters will be reported to the individual  user to whom the Sieve filter belongs;  syntax errors in  "head of household"  (also called  "parental control") Sieve filters will be reported to the  head of household filter "owner" (see the    MTA option).

Similarly, (as of MS 6.1) the MTA will report syntax errors in alias or group definitions  (that is, errors of non-existent putatively  "local" users in the alias/group membership, or clearly  syntactically invalid addresses in the alias/group membership) to the  entire alias/group membership. These error reports are in DSN format. Note:



 There is a critical, fundamental distinction between a mailing list (where errors in list definition as well as problems with  list message deliveries get reported only to the list  "owner" as specified via an     attribute overriding the original message envelope From address)  vs. a group (which has no   attribute  and hence retains the original message envelope From address). From the MTA point of view, a group is merely a---possibly large -- alias---an  "auto-forwarder" in Internet e-mail terms. 

 The group definition syntax errors reported to the entire group membership are  not message delivery failures---which in the case of a group would be  reported merely to the original message sender---but rather are those  syntactic errors in the group definition which are apparent to the MTA  at group alias expansion time. (Because a group, when properly used, is a set of aliases for a single person or small, closely related set of  people, problems with the group membership definition are considered  problems with the alias setup that the rest of the group members should  be informed about so that they can fix the definition.) 



The MTA will also generate messages that have the form of notification messages (they have an empty envelope From and contain the original  message as an encapsulated part, usually perceived as an  "attachment") in response to typical forms of capture configuration:  that is, when a "capture" attribute (see the     and   MTA options)  is set on a user or domain, or when an explicit  Sieve " " action  applies to a message, or when "capture" is triggered via  another mechanism such as   an address-based    mapping table "capture" flag. The capture message, having the superficial form of a notification message, will be  sent to the address specified to receive the capture copies. Though the form of such capture copies is similar to other sorts of notification  messages, the intended purpose is usually quite different, as  capture of messages  is usually intended either for monitoring (of a user&#x27;s  e-mail) or archiving purposes.

The MTA may also issue SMTP level rejections of attempted message submissions. In such cases, the MTA is not generating the notification message itself; in such cases generation of a notification  message is the responsibility of the SMTP client attempting to send  the message. (And the SMTP client may or may not include the MTA&#x27;s actual SMTP rejection text in the message text that it generates to display or  send to the original message sender.)

The Message Store can generate "notifications" that a user is over quota; such quota "notifications" are deposited directly into the Message Store (without  passing through the MTA at all); see   Message Store notifications that a user himself is overquota.

Also, other non-MTA components of Messaging Server (such as msprobe) may have capabilities for generating alarm messages "from" some form of postmaster address and "to" some form of postmaster address; see the  and    Alarm options.

Furthermore, the MTA also processes numerous notification messages generated by systems other than the MTA -- notification messages that  arrive in to the MTA just like any other messages.

All of these cases involve different issues, and different configuration choices. Whenever a question about a notification message arises, it is critical to first determine what type of notification  message is involved. Note that looking at the outermost header of the notification message is the most important  first step in determining what type of notification message  one is dealing with.

See also:
 * copysendpost Option
 * copywarnpost Option
 * use_precedence MTA Option
 * Sieve filters
 * systemfilter MTA Option
 * Sieve vacation extension
 * Head of household Sieve filters
 * ldap_hoh_owner MTA Option
 * Aliases
 * ldap_errors_to MTA Option
 * Message capture
 * ldap_capture MTA Option
 * ldap_domain_attr_capture MTA Option
 * Recipient access mapping tables
 * Message Store notifications that a user himself is overquota
 * noticesender Option
 * noticercpt Option
 * Alarm options
 * Postmaster addresses
 * Notification messages