test

Message Archiving Using the Sun Compliance and Content Management Solution

Setting Up A Compliance Archiving Deployment

The Archive and Portal Server must be installed and configured as per the AXS-One Server documentation. It should be installed on a separate server for best performance. Messaging Server should be in full operation. Note that archiving can be done with an SMTP MMP proxy in front of the MTA host.

Compliance archiving uses the MTA's spam filter interface to specify the message stream to be archived. Be sure to understand this interface before setting up a compliance archiving system. Complete documentation is at Specifying the Messages to Be Filtered in Sun Java System Messaging Server 6.3 Administration Guide.

ProcedureConfiguring Messaging Server for Compliance Archiving

  1. Make sure the Archive Server has been installed and configured as per the AXS-One documentation.

  2. Make sure that the Archive and Messaging Server system users belong to the same UNIX group.

    The AXS-One UNIX system user name is axsadm. The Messaging Server UNIX system name is typically mailsrv. Both need to be in the same UNIX group. See Creating UNIX System Users and Groups in Sun Java System Messaging Server 6.3 Administration Guide for details on how to do this.

  3. Set up a shared directory for messaging archival.

    The staging directory can be a local or NFS mounted drive.

  4. Ensure that the configutil parameters store.archive.compliance and store.archive.path are correctly set.

    store.archive.compliance - Set to ON (default).

    store.archive.path - Set to directory shared by the Archive Server and Messaging Server for messaging archiving in the previous step. This should be the same as the DIRECTORY variable in the AXS-One configuration file.

  5. Edit the option.dat file.

    Include following parameters:

    SPAMFILTERx_LIBRARY=/opt/SUNWmsgsr/lib/libarch.so

    SPAMFILTERx_CONFIG_FILE=/opt/SUNWmsgsr/filename

    libarch.so is the AXS-One API for Messaging. filename is an arbitrarily named text file containing the AXS-One configuration information (see next step).

    In both parameters, x is a number from 1 to 8 specifying the filtering software, in this case AXS-One. This number is used in subsequent attributes to reference the AXS-One filtering. (See step 7.)

  6. Create the AXS-One configuration file. (Called filename in the previous step).

    This file must be readable by the mailsrv user. It must include the following two entries:


    STYLE=1 
DIRECTORY=Message_Archival_Staging_Area

    STYLE specifies the AXS-One configuration. At this time the only legal value is 1.

    DIRECTORY specifies the directory shared by the AXS-One server and Messaging Server for messaging archiving.

  7. Specify the messages to be archived.

    Messages can be archived by user(s), domain, channel, incoming or outgoing mail. Use the spam filter interface to specify precisely the message stream you wish to archive. This is described in detail at Specifying the Messages to Be Filtered in Sun Java System Messaging Server 6.3 Administration Guide.

    Below are some examples

    Example 1. To archive all incoming and outgoing messages for users, specify an user opt-in attribute using LDAP_OPTINx and add this attribute to your directory schema. For example:

    LDAP_OPTIN1=AXS-One

    Now add the opt-in attribute-value pair to the LDAP user entry of any user whose mail you wish to archive. For example:

    AXS-One: archive

    Example 2. To archive all incoming and outgoing messages for a particular domain, specify a domain opt-in attribute using LDAP_DOMAIN_ATTR_OPTINx. For example:

    LDAP_OPTIN1=AXS-One

    Now add the opt-in attribute-value pair to the LDAP domain entry of the domains whose mail you wish to archive. For example:

    AXS-One: archive

    Archiving by Channel. Archiving by channel can provide greater flexibility and granularity for archiving, but it can also be a very complex process requiring deep knowledge of how messages flow between various channels and systems. Careful attention to the archiving requirements and to the email system and architecture is mandatory. Additionally, if the system is modified by adding new MTAs or channels or how channels direct message flow, then the channel archiving configuration will have to be examined.

    Archiving creates a tension between keeping records of everything and avoiding the creation of unnecessary and space-wasting copies. The idea is to make exactly one copy of each message as it passes through the transport infrastructure. But in order to make just one copy and not miss anything you have to understand every possible way mail can flow.

    The following two examples describe archiving by channel.

    Example 3. This example shows how to archive all mail sent by local users to other local users that actually gets delivered. In this example we assume that you don't care about messages inserted directly into some other user's mailbox using IMAP, or messages sent by a local user to another local user who forwards that mail to an outside address. You don't mind if some spam gets archived occasionally. You don't care what version of a given message gets archived as long as it gets saved at some point and you'd like to avoid duplication in archiving but you don't insist on it. Finally, this example assumes that ingress and egress points follow the usual norms we recommend for messaging server setups.

    Such a setup would most easily be implemented by putting a sourcespamfilterX (or sourcespamfilterXoptin as required) keyword on each channel that serves as a point of ingress for local user mail and disabledestinationspamfilterX on each point of egress that heads out to the open Internet. (An ingress channel is the channel at which a message enters the MTA, and an egress channel is a channel at which a message leaves the MTA.)

    So sourcespamfilterX would be put on tcp_submit, tcp_auth, and tcp_intranet, and disabledestinationspamfilterX would be put on tcp_local.

    Typically, tcp-local receives inbound messages from remote SMTP hosts and outbound messages from internal users. Depending on how the system is configured, outbound messages are sent directly to remote SMTP hosts or to the smarthost/firewall system. tcp-local is an ingress point for incoming mail and an egress point for outgoing mail. disabledestinationspamfilterX will disable spam filtering if a message came from a channel that enabled spam filtering. Thus, if a message from any of the three channels with sourcespamfilterX goes to tcp-local, it will not be archived.

    Example 4. This example archives all Messaging Server incoming and outgoing messages as well as internal mail. It makes the same long list of assumptions listed in Example 3above.

    Put sourcespamfilterX on tcp_local, tcp_auth, and tcp_submit on inbound relays, and put sourcespamfilterX on tcp_intranet, tcp_auth, and tcp_submit on outbound relays.

  8. Compile the MTA configuration with imsimta cnbuild followed by imsimta restart

MTA Options and Channel Keywords of Interest When Archiving

The UNIQUE_ID_TEMPLATE MTA option specifies a template used to convert an address into a unique identifier. The template's substitution vocabulary is the same as that for DELIVERY_OPTIONS (see Option File in Sun Java System Messaging Server 6.3 Administration Reference). The AXS-One archiving facility will generate and use unique identifiers instead of email addresses if this option is set.

AXS-One requires the computation of a hash of each message inserted into the archive. The following MTA options control how this hash is generated:

MESSAGE_HASH_ALGORITHM specifies the hash algorithm. Can be any of md2, md4, md5 (the default), sha1, md128(for RIPE-MD128), or md160 (for RIPE-MD160).

MESSAGE_HASH_FIELDS — Comma separated list of fields from the header to hash (in order). Any known header field can be specified. If this option is not specified it defaults to message-id, from, to, cc, bcc, resent-message-id, resent-from, resent-to, resent-cc, resent-bcc, subject, content-id, content-type, content-description.

ProcedureTesting Your Compliance Archiving Deployment

  1. Create two email users.

  2. Set up your system as described in the previous section.

  3. Send email between these users.

  4. Verify if the staging directory contains *.info, *.body.txt, and *.eml files.

    If these files exist on the staging directory, then the system is working on the messaging side.

ProcedureAdministering, Maintaining and Monitoring Your Compliance Archiving Deployment

  1. Refer to the AXS-One documentation.

ProcedureTroubleshooting Your Compliance Archiving Deployment

  1. Make sure that the AXS-One and Messaging Server system users belong to the same UNIX group.

  2. Verify that the spam filter interface is properly configured to capture the message stream you wish to archive.

  3. Verify that the AXS-One Configuration file exists and is configured properly.

  4. Check to see if there are any error messages in the mail.log_current.

    Logging must be enabled (see Enabling MTA Logging in Sun Java System Messaging Server 6.3 Administration Guide).

  5. Verify that the staging directory has provided write permissions to the mail server user (mailsrv) and its group.