Job Controller priority-based processing

New in 8.0, the MTA supports the MT-PRIORITY SMTP extension defined in RFC 6710 (SMTP Extension for Message Transfer Priorities). An explicit MT-PRIORITY value overrides any of the older Priority: header line base priority settings, or the MTA&#x27;s old size-based priority adjustment effects. See the discussion of the  MTA option for a description of how MT-PRIORITY values are mapped to the older Priority: values. So a message with an explicit MT-PRIORITY value will get priority handling based on the mapping of that MT-PRIORITY value to the older Priority: value. Only a Sieve filter   action can override a message&#x27;s explicitly specified MT-PRIORITY value.

The standardized Priority: header field, defined in RFC 2156 (MIXER: Mapping between X.400 and RFC 822/MIME), is respected by the MTA. Note that this MTA message processing priority, as indicated in a Priority:  value, affects MTA processing priority: that is, it affects when the  MTA processes that message especially in contention with other messages  of differing priority, and potentially how long the MTA continues to  reattempt delivery of messages experiencing temporary delivery failures. Note that this Priority: effect is completely different from the sort of user e-mail client display feature requested via a Precedence: or  Importance: header field (though users sometimes confuse and conflate  these different sorts of effects). Keep in mind that time-criticality (processing priority) is not necessarily the same thing as importance:  a relatively insignificant message may be time-critical due to  time-limited relevance, or conversely a message of significant  importance may concern an event far removed in time.

Priority: is an MTA-level feature, not typically appropriate for arbitrary users to set themselves (though specially privileged users  such as administrators may desire and be entitled to access to priority  adjustment). Priority handling may come at a "cost", whether that cost is simply additional work by the MTA, additional charges to the user, or  an effect that delivery attempts abort sooner (thus causing messages to  potentially be less likely to get through, being bounced sooner rather  than getting additional delivery attempts if the message can&#x27;t be  delivered "quickly"). Importance: or Precedence: on the other hand, are user-level features, appropriate for users to set on the  messages they send to request special handling by recipients or special  display features when recipients&#x27; e-mail clients display the messages.

By default Priority: values are honored and make a "difference" in the MTA&#x27;s message handling, affecting  handling by the Job Controller, though that "difference" is  generally small and hardly noticeable.  The Job Controller sorts messages, by priority, into separate internal processing queues. With just default configuration, the Job Controller will preferentially process " " messages  before " " messages before  " " messages among those messages all eligible  for delivery at the same time. However, under normal circumstances there are so many messages flowing through the MTA so quickly, with so  many messages being handled in parallel, that this sort of difference  in handling based on priority tends to be pretty much moot. Unless there&#x27;s a big enough backlog of newly submitted messages that the  usually fairly "immediate" delivery attempts are a bit  delayed, the Job Controller&#x27;s automatic sorting of messages by priority  doesn&#x27;t much matter; instead, with no backlog, each freshly submitted  message can get an essentially "immediate" delivery attempt,  regardless of the message&#x27;s priority.

When it comes to delivery retries on messages that didn&#x27;t get through on first attempt, there the default MTA configuration (with only the    channel option set) is to retry  urgent messages at  shorter periods than normal messages, and retry nonurgent messages at  longer periods. This may be precisely controlled further via the     channel option  settings. So by default, priority does have an (in principle) noticeable effect on the delivery retries scheduled by the  Job Controller -- but once you&#x27;re in the regime of having to retry to  deliver, the messages are by definition "delayed", and the  exact length of retry interval may matter little compared to the time  scale of whatever is causing the delivery attempts to fail. So again, this is a difference, but perhaps not a difference that  "matters" much.

As for how long messages are retained if they continue to fail to be deliverable, there the MTA default (the default handling by the   )  is that priority doesn&#x27;t have an effect -- though you can change  that via the     channel option settings. But note that even if your own MTA hasn&#x27;t been configured to make a distinction, other MTAs that your  messages pass through in principle might care and bounce  " " messages sooner if they fail  delivery---this is one of the potential "costs" of higher  priority processing mentioned above.

Now, if you choose to configure different Job Controller delivery execution windows,  you can potentially have very different handling of  different priorities of messages, even for freshly submitted new  messages. With that (non-default) configuration, then you could see very noticeably different handling of different priorities of messages. See the ,  , and    Job Controller options.

In particular, one type of use of priority delivery execution windows is to defer the processing of " "  messages to "off hours"; e.g., in legacy configuration set in the   file: ! Add to a pool definition to postpone delivery attempts of non-urgent ! messages to the hours between 11:00 PM and 4:00 AM any day, or any time ! Sunday. ! NONURGENT_DELIVERY=23:00 - 04:00, Sun 00:00 - 23:59 Or in Unified Configuration, set via: msconfig&#x3e; set option job_controller.job_pool:SMTP_POOL.nonurgent_delivery "23:00 - 04:00, Sun 00:00 - 23:59" When priority "matters", note that the MTA has ways of overriding the priority specified on a Priority: header line. The priority that the MTA actually uses is the effective  priority---normally what is specified on a Priority: header line,  unless overridden in some way. The    channel options, for instance, and the new in   Messaging Server 7.4-0.01  system Sieve  action    can be used to override the original  processing priority, setting a new effective processing priority. As of the 8.0 release, an explicitly specified MT-PRIORITY value on a message will override any Priority: header based setting, or MTA size-based priority adjustment. Only the Sieve filter    action can override an explicitly specified MT-PRIORITY value.

See also:
 * Job Controller operation
 * backoff Option
 * notices Option
 * nonurgent_delivery Option
 * normal_delivery Option
 * urgent_delivery Option
 * nonurgentblocklimit Option
 * normalblocklimit Option
 * urgentblocklimit Option
 * mtprioritiesallowed Option
 * mtprioritiesrequired Option
 * mtpriority_policy MTA Option
 * Sieve setpriority and setmtpriority extensions