Adding More Information to Message Transaction Records

If you are currently logging message transactions (have the logging keyword enabled in your imta.cnf file), consider also setting LOG_FILTER=1 in the option.dat file.

If you enable “logging,” make sure that you have a method in place to manage the resulting log files. See Chapter 21, Managing Logging, in Sun Java System Messaging Server 6 2005Q4 Administration Guide for more information.

LOG_FILTER=1 will cause inclusion of an additional field in the message transaction records in the mail.log* files that will record both other sorts of Sieve filter results, as well as Symantec Brightmail results applied to each message recipient. Exactly what will appear in the Symantec Brightmail result portion of this field depends upon what verdict or destination Symantec Brightmail returns, and how the MTA in turn is configured to react to that verdict or destination. But the general form will be:

spamfiltern:encoded-string Sieve-action(s)-comma-separated

where in general (when other forms of Sieve filtering are also in use) this is one part (also comma-separated) within the overall filter field. For instance, a message recipient with no general MTA Sieve, no applicable channel Sieve, no applicable domain Sieve, and no personal Sieve, but where Symantec Brightmail returned a “null destination-data” result (normally configured to be interpreted as a request to discard the message, it having been determined to be spam), where here Symantec Brightmail is assumed to be configured as spam/virus filter package # 1, might show in the filter field as:

’spamfilter1:encoded-string , discard;’

Or, if Symantec Brightmail has been configured to return a “spam” destination-data (normally configured to be interpreted as a request to file the message to a “spam” folder), in the case of messages determined to be spam, then this might show in the filter field as:

’spamfilter1:encoded-string fileinto "spam";’