Difference between revisions of "Log diagnostics MTA option"

From Messaging Server Technical Reference Wiki
Jump to: navigation, search
m (Bulk update)
m (Bulk update)
Line 5: Line 5:
 
== Transaction logging MTA options:  <code>log_diagnostics</code> (0-3) ==
 
== Transaction logging MTA options:  <code>log_diagnostics</code> (0-3) ==
  
(New in 7.0-3.01.) Bit 0 (value 1), if set in <code>log_diagnostics</code>,  causes diagnostics information to appear in certain log entries. Bit 1 (value 2), if set, causes diagnostics information to be included in  [[LOG_ACTION mapping table#LOG_ACTION_mapping_table|<code>LOG_ACTION</code> mapping]] probes.  For instance, in the case of "B" records (bad commands received by the SMTP server), the diagnostic field will show the SMTP server error response. In the case of connection close "C" records, the diagnostic file will show the reason why the connection was closed, ''e.g.'', reaching some session disconnect limit. In the case of authentication "U" entries (which note are generated as connection transaction entries, rather than message transaction entries), the result of an authentication attempt is shown in the diagnostic field. Appears just after the reason field (see the <code>log_reason</code> MTA option) and before the time-in-queue field (see the <code>log_queue_time</code> MTA option). In XML-compatible format  ([[log_format MTA option#log_format|<code>log_format</code>]] set to 4), diagnostic information, if enabled, appears as the <code>di</code> attribute.  
+
(New in 7.0-3.01.) Bit 0 (value 1), if set in <code>log_diagnostics</code>,  causes diagnostics information to appear in certain log entries. Bit 1 (value 2), if set, causes diagnostics information to be included in  [[Triggering effects from transaction logging with LOG_ACTION#Triggering_effects_from_transaction_logging_with_LOG_ACTION|<code>LOG_ACTION</code> mapping]] probes.  For instance, in the case of "B" records (bad commands received by the SMTP server), the diagnostic field will show the SMTP server error response. In the case of connection close "C" records, the diagnostic file will show the reason why the connection was closed, ''e.g.'', reaching some session disconnect limit. In the case of authentication "U" entries (which note are generated as connection transaction entries, rather than message transaction entries), the result of an authentication attempt is shown in the diagnostic field. Appears just after the reason field (see the <code>log_reason</code> MTA option) and before the time-in-queue field (see the <code>log_queue_time</code> MTA option). In XML-compatible format  ([[log_format MTA option#log_format|<code>log_format</code>]] set to 4), diagnostic information, if enabled, appears as the <code>di</code> attribute.  
  
 
This option defaults to 1 in order to maintain compatibility with previous releases, where diagnostics information was always logged.  
 
This option defaults to 1 in order to maintain compatibility with previous releases, where diagnostics information was always logged.  

Revision as of 23:05, 7 August 2015



Transaction logging MTA options: log_diagnostics (0-3)

(New in 7.0-3.01.) Bit 0 (value 1), if set in log_diagnostics, causes diagnostics information to appear in certain log entries. Bit 1 (value 2), if set, causes diagnostics information to be included in LOG_ACTION mapping probes. For instance, in the case of "B" records (bad commands received by the SMTP server), the diagnostic field will show the SMTP server error response. In the case of connection close "C" records, the diagnostic file will show the reason why the connection was closed, e.g., reaching some session disconnect limit. In the case of authentication "U" entries (which note are generated as connection transaction entries, rather than message transaction entries), the result of an authentication attempt is shown in the diagnostic field. Appears just after the reason field (see the log_reason MTA option) and before the time-in-queue field (see the log_queue_time MTA option). In XML-compatible format (log_format set to 4), diagnostic information, if enabled, appears as the di attribute.

This option defaults to 1 in order to maintain compatibility with previous releases, where diagnostics information was always logged.


See also: