Notification message routing

When the MTA needs to generate a notification message, its default is to enqueue the notification message to the  process channel. The new notification message will be enqueued to the process channel from  whatever channel encountered the condition that required the  notification message to be generated. For instance, a   channel when attempting to send a message out to the Internet (that is,    operating as an SMTP client) may need to generate a  notification message if a message it is attempting to deliver  encounters a permanent rejection error from a remote SMTP server. Or the   channel&#x27;s SMTP server may need to generate a notification  message if an incoming message that it is attempting to process is  addressed to a local recipient who has a Sieve filter containing a  syntax error; in this case while the original message gets delivered as  "normal", the   channel also needs to generate a  notification message to the local  Sieve filter owner letting them know that  their Sieve filter has a syntax error.

The process channel, having had a notification message enqueued to it,  will then run to send the notification message onwards to an appropriate destination  channel. (This is in fact the main purpose of the process channel, namely to handle notification messages: accept them being generated by other  channels, and then properly enqueue them onwards to their destinations.)

Optionally, the MTA may be configured, on a per-channel basis, to enqueue notification messages to alternate   channels via the    and     channel  options. This may be useful when a site processes a large number of notification messages. Splitting up notification message traffic into different   channels,  and then optionally using  source-channel-specific rewrite rules (or the    mapping table)  to route the messages coming from different   channels out  through different destination channels, may aid in managing large  volumes of notification messages. (In particular, this may be of interest with special purpose channels that are subject to unusually high volumes of notification messages, or  when dealing with rejections of spam messages that had forged From:  addresses claiming to come from unresponsive rather than clearly  nonexistent domains.)

For instance, suppose one adds new, special channel definitions that are variants of the usual   and    channels, so along the  lines of: tcp_local_dsn_out smtp mx single_sys subdirs 20 maxjobs 7 pool SMTP_POOL \ loopcheck tcp-dsn-out-daemon process_dsn_out process-dsn-out-daemon then adds  to the  regular   channel definition: tcp_intranet ...usual-keywords... notificationchannel process_dsn_out tcp_intranet-daemon and configures special routing  by using CONVERSIONS IN-CHAN=process_dsn_out;OUT-CHAN=tcp_local;CONVERT  \ Yes,Channel=tcp_local_dsn_out This will result in notifications generated by the   channel  regarding messages originally from Internet senders (notifications back  to Internet senders regarding the Internet senders&#x27; messages originally  addressed to recipients on other internal hosts) to be routed out the  special   channel, rather than out the usual     channel. This can then allow for special handling, or special tuning of the handling, of such messages.

Also, the new-in-6.3P1   flag in the  FROM_ACCESS mapping table provides,  among other things, another way to do special routing of incoming  notification messages (messages with empty envelope From). That is, this provides a way to associate a special source channel (and hence do  special destination channel routing, or other special source-channel  based handling) for notification messages generated external to this  MTA. E.g., with new, special channel definitions that are variants of the usual   and    channels, so along the  lines of: tcp_local_dsn_in smtp mx single_sys remotehost inner switchchannel \ subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver maysaslserver \ saslswitchchannel tcp_auth missingrecipientpolicy 0 loopcheck tcp-dsn-in-daemon tcp_lmtpcs_dsn_out defragment lmtp multigate connectcanonical \ fileinto @$4O:$U+$S@$D port 225 nomx single_sys subdirs 20 maxjobs 7 \ pool SMTP_POOL dequeue_removeroute lmtpcs-dsn-daemon then use mappings along the lines of: FROM_ACCESS TCP&#x7c;&#x2a;&#x7c;SMTP&#x2a;&#x7c;MAIL&#x7c;tcp_local&#x7c;&#x7c;&#x2a; $Y$~tcp_local_dsn_in CONVERSIONS IN-CHAN=tcp_local_dsn_in;OUT-CHAN=tcp_lmtpcs;CONVERT   \ Yes,Channel=tcp_lmtpcs_dsn_out to cause notifications coming in from the Internet destined for LMTP recipients to get routed out the special    delivery  channel, rather than out the usual   delivery channel.

See also:
 * Process and reprocess channels
 * notificationchannel Option
 * dispositionchannel Option
 * CONVERSIONS mapping table
 * FROM_ACCESS mapping table
 * Notification messages
 * Bounces of spam messages
 * Alternate channel routing via the CONVERSIONS mapping
 * Typical TCPIP channels and servers
 * Sieve filters
 * Sieve language