Notification message generation timing

Many sorts of notification message the MTA generates immediately  whenever the relevant type of event occurs. For instance, if a message suffers a permanent rejection upon a delivery attempt, then the MTA  will immediately generate a non-delivery report (often referred to as a  "bounce message") to send back to the original message  sender. If the MTA is expanding a mailing list (looking up the mailing list name  to determine the members of the list) and discovers a clearly invalid member address (i.e., a syntactically invalid address, or an address claiming to be in a local domain that does not in actuality correspond to any configured user/mailbox), then the MTA will immediately generate a non-delivery report regarding that address back to the list owner (list report address). Notifications generated due to a Sieve " " or  " " action  are generated when such a Sieve filter is  evaluated (when an original message that triggers the Sieve  " " or " " action is processed). Similarly, notifications warning of a Sieve syntax error  are generated  whenever the relevant Sieve filter is processed in an attempt to apply  it to an incoming original message.

Another trigger for MTA generation of notification messages is postmaster use of the    utility or    utility&#x27;s   command to  explicitly, immediately bounce specified messages.

But notification messages regarding temporary delivery problems, or those reporting a message delivery failure due to finally "timing  out" after repeated delivery attempts,  are instead generated upon a periodic  (configurable) schedule; see the   channel options for configuration of eligibility for such notifications, and the MTA  &#x27;s scheduling for actual generation of such notifications. Similarly,  Message-Store-generated user overquota warnings may be issued periodically; see the   Message Store option (legacy configuration   configutil parameter).

The reporting of delayed (or eventually timed-out-and-given-up-on) messages is triggered by the  MTA ,  which checks the settings  of any    channel options in order to decide  whether it is time to generate a notification message regarding the  delayed (or eventually failed due to timing out) message. The MTA   must thus be  scheduled as appropriate for a site&#x27;s needs in  relation to the generation of such notification messages. As of MS 6.0, the Messaging Server Scheduler,  , is normally  used to schedule the running of the MTA&#x27;s. (In previous versions, such scheduling was normally performed by the  Job Controller  via a PERIODIC_JOB definition---an approach that is now deprecated.)  In Unified Configuration, the Scheduler configuration, besides its   option, consists primarily of a    option setting for each scheduled job. In particular, in Unified Configuration the MTA   schedule is set via the   option setting: msconfig&#x3e; show task:return_job.crontab role.schedule.task:return_job.crontab = 30 0 &#x2a; &#x2a; &#x2a; lib/return_job In legacy configuration, the Scheduler configuration is controlled by   parameters; for  the MTA&#x27;s , see in particular the    parameter, whose default value is  30 0 &#x2a; &#x2a; &#x2a; /opt/SUMWmsgsr/lib/return_job This is UNIX crontab format, i.e., minutes-after-hour hour day-of-month month-of-year day-of-week script So the normal setting corresponds to the  being set to run  at 30 minutes after midnight every day, (with the asterisks indicating,  respectively, every day of the month, every month of the year, every  day of the week).

See also:
 * Sieve filters
 * return utility
 * qm utility
 * notices Option
 * enable Option
 * crontab Option
 * Notification message types
 * Proper use of lists rather than groups
 * use_precedence MTA Option
 * Message Store notifications that a user himself is overquota
 * Notification messages