Configuring Brightmail with Sun Java System Messaging Server

Configuring the Messaging Server MTA for Symantec Brightmail

The Sun Java System Messaging Server MTA supports the use of up to four separate spam/virus filtering packages. Typical usage would be to configure Symantec Brightmail as spam/virus filter package #1 as shown in this section, using a minimal set of option.dat options. However, if one or more other spam/virus filter packages are already in use and Symantec Brightmail is to be added as yet another spam/virus filter package, then configure Symantec Brightmail by setting an appropriate pair of (previously unused) SPAMFILTERn_CONFIG_FILE and SPAMFILTERn_LIBRARY options.

In the following example, Messaging Server has been installed in the /opt/SUNWmsgsr directory.

ProcedureTo Modify the option.dat and imta.cnf Files

  1. Modify the option.dat file as follows.

    Here the Symantec Brightmail client is located under the /SYMSDK/BSDK directory.

    ! Brightmail Stuff

    Consider also setting SPAMFILTER1_OPTIONAL=-2 (or SPAMFILTERn_OPTIONAL=-2, as appropriate) in the option.dat file. If the MTA encounters an error contacting Symantec Brightmail, then in addition to temporarily rejecting incoming SMTP messages, the MTA will also generate a syslog notice. For syslog notices to be routed appropriately, you might also need to adjust the SNDOPR_PRIORITY option.dat option and your syslog.conf file.

  2. Modify the imta.cnf file as follows.

    Symantec Brightmail scanning can be selected in the MTA in a variety of ways, including via use of a per-user LDAP attribute, or via use of a per-domain LDAP attribute, or according to source or destination channel. A typical usage is to perform Symantec Brightmail scanning on all messages destined to locally hosted users: that is, on all messages being delivered to users via an ims-ms channel, or via tcp_lmtp* client channels. For instance, to trigger Symantec Brightmail “spam” filtering on all messages being delivered to the store via the ims-ms channel, if Symantec Brightmail is being used as spam/virus filter package # 1, add destinationspamfilter1optin spam to the ims-ms channel definition in the imta.cnf file. Such a channel definition might then look something like the following:

    ! ims-ms
    ims-ms defragment subdirs 20 notices 1 7 14 21 28 \
     backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" \
     maxjobs 2 pool IMS_POOL fileinto $U+$S@$D \
     destinationspamfilter1optin spam
  3. Compile the MTA configuration.

    ./imsimta cnbuild

  4. Restart the MTA dispatcher.

    imsimta restart dispatcher

    This will cause use of the new compiled configuration (enabling Symantec Brightmail use) by the MTA's (new) SMTP server processes.

ProcedureTo Verify Messaging Server MTA

Use one of the following steps to verify that the Messaging Server MTA is functioning properly.

  1. Run the imsimta test -rewrite command on a sample local user address. There should be no errors. For example:

    # /opt/SUNWmsgsr/sbin/imsimta test -rewrite -debug=level=4 -filter
    12:32:29.33: - passed.
    12:32:29.33: - send_access mapping check:
    12:32:29.33: Mapping 4 applied to
    12:32:29.33: Final result
    12:32:29.33: - passed.
    12:32:29.33: - adding address user99@ims-ms-daemon to channel ims-ms
    12:32:29.33: Closing URL context 1, new type = 7
    12:32:29.33: - adding address to headers.
    12:32:29.33: Copy estimate after address addition is 2
    Expanded address:
    Submitted address list:
      user99@ims-ms-daemon (orig, inter, host ims-ms-daemon)
    Submitted notifications list:
  2. Compose and send an email. Look at the Symantec Brightmail server logs under the /var/log/brightmail directory and verify that the bmserver_logs file contains information about this message.

    Note –

    You can also log in to the Control Center and check for statistics.

  3. If you set SPAMFILTER1_OPTIONAL=-2 in the option.dat file, as previously explained, then you can check for warning syslog messages to verify the MTA/Symantec Brightmail operation.

  4. If you set LOG_FILTER=1 in the option.dat file, you can check that “expected” results are showing up in the filter field in mail.log* records. See Adding More Information to Message Transaction Records for more information.