Sndopr_priority MTA option

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

Syslog MTA options: sndopr_priority (0-127)

The sndopr_priority MTA option sets the syslog level (facility and severity) of syslog messages generated by the MTA under certain circumstances, including most cases where the MTA would generate a syslog message for an "event notice" type purpose. In particular, MTA syslog messages affected by sndopr_priority include:

  • problems creating or deleting message files
  • problems creating temporary files while buffering incoming SMTP messages
  • (new in 8.0) MESSAGE-SAVE-COPY mapping table problems renaming or copying a message file
  • an empty or otherwise invalid format message file is found in the MTA disk queue area
  • problems updating MTA message or association counters
  • problems executing the imsimta reload utility
  • if log_sndopr is set, problems writing to the MTA transaction log files
  • if held_sndopr is set, certain cases of sidelining of messages as .HELD files
  • if spamfilterN_optional if set to -2 or 2, and trouble occurs getting a result back from the Nth spam/virus filter package
  • notices configured in the LOG_ACTION mapping table or various access mapping tables that happen to support generating syslog notices via the $< and $> flags

The default is 5 (that is, LOG_NOTICE on UNIX). (If the facility has not been explicitly specified in a sndopr_priority setting, as is the case with a value of 5, then the system's default facility is used: usually but not always LOG_USER.)

Note that sndopr_priority does not affect the optional copying of MTA transaction entries to syslog, which would more typically be serving a normal logging purpose rather than an "event notice" type warning purpose; the syslog level of MTA transaction entries are instead separately controlled by the exact values of log_messages_syslog or log_connections_syslog, as relevant.

See also: