email security

It's TRULY a "Very Bad Idea" to send a copy of every mail to a single mail address, if your server is of any size.

If you're not talking about large numbers of total messages, you can indeed send copies of all messages to a single mail address. Here's how to do both. Please understand that sending very large numbers of messages to a single mailbox will hit limits for both performance and maximum number of messages in a mailbox.

Saving Messages for Document Retention

If the reason you want to capture a copy of the message is for document retention, then you will want to take advantage of the new "capture" sieve action. You have to have iMS v5.2 or better to use this facility. The capture action can only be specified in a system or channel sieve; it is not available in user sieves. The general syntax is

capture "monitoraddress"

The monitor action is the same as the capture action. Users are encouraged to use the 'capture' instead of monitor as it best reflects the function being performed.

This action sends a DSN containing the original message in its entirety to the specified capture address. Since this is a DSN it is effectively a completely separate message so there's little chance of it causing side effects that will alert anyone to the monitoring. In particular, no addresses from the original message appear in the DSN header so there's very little chance of the capture copy getting forwarded to the wrong person by mistake. And even though the original message is encapsulated, it is a MIME encapsulation which means the content is easily accessible in any MIME-compliant user agent.

The capture action is nonstandard and undocumented. It was originally intended to be part of the habanero release, but the backporting of direct LDAP support to 5.2 means it is available in 5.2 as well. We certainly intend to support it in the future.

Saving Messages for Replay

There is an undocumented functionality in iMS for making a copy of messages for archival purposes. It's intended for saving sent messages in the event that they need to be replayed. We did this for folks who send mail via bad links to places where the mail may be received OK by an intermediate host but then subsequently lost on its way to the final destination.

This is done with the MESSAGE-SAVE-COPY mapping table. Entries in that table have the form

MESSAGE-SAVE-COPY

out-channel|from-address|D|msg-filename result

where

out-channel -- name of the channel the message is flowing out

from-address -- originator's address (envelope From: address)

D -- the letter "D" (stands for "dequeue" )

msg-filename -- name of the message file being dequeued.

result -- where to rename the file

Outbound Traffic

To save only messages out to the Internet, do

MESSAGE-SAVE-COPY

tcp_local|*|D|/instance-root/queue/tcp_local/*/* (tab-or-space)$Y/msg_save/$1/$2

Be aware that the archive isn't made until the message is actually dequeued from iMS (i.e., sent successfully or bounced). A rename operation is done (as opposed to a copy operation). As such, the message file has to remain on the same disk that the IMTA_QUEUE lives on.

Inbound Traffic

To capture inbound mail will want to have good control of what machines/pathways a message will take on its way into your systems. If your setup is such that mail always enters the site via an INBOUND relay and leaves the site via know outbound gateways, then inbound message flow is from INBOUND-MTA --> MsgStore machine.

Since you can have multiple MsgStore machines behind any one INBOUND-MTA, you will want to make configuration on the INBOUND-MTA machine such that it will use a dedicated queue to talk to the MsgStore machines. For instance, on the INBOUND-MTA machine, you could setup a rewrite rule in your imta.cnf file for MsgStore-A, MsgStore-B, ... MsgStore-Z like:

!

Node-A.store.domain.com.au $U%$D@tcp_to_store-daemon

... ...

... ...

... ...

Node-Z.store.domain.com.au $U%$D@tcp_to_store-daemon

!

and a corresponding 'tcp_to_store' channel which looks like:

!

! tcp_to_store

tcp_to_store smtp mx single_sys subdirs 20 noreverse maxjobs 7 \

pool SMTP_POOL maytlsserver allowswitchchannel \

saslswitchchannel tcp_auth

tcp_to_store-daemon

!

This has the effect of routing all mail to any of your MsgStore machines through tcp_to_store channel. Transactions to other machines in your setup will take the tcp_intranet channel.

With this in place you can then throw in a MSG-SAVE-COPY mapping table which reads:

MESSAGE-SAVE-COPY

*|*|D|/instance-root/imta/queue/tcp_to_store/*/* $Y/msg_save/tcp_to_store/$2/$3

the net effect will be a number of queue files in the /msg_save/tcp_to_store directory which are ready for replay. Note the $2 in the sample represents the subdir that the message was already in. As such if you have 'subdirs 20' on your tcp_to_store channel, you will want to precreate the /msg_save/tcp_to_save/000 thru 019 subdirectories with the appropriate ownership and permissions.

To initiate the replay, you want to simply move the /msg_save/tcp_to_store/### directories to the /instance-root/imta/queue/reprocess and issue the command 'imsimta cache -synch'. The MTA will start pushing out those messages to the store(s).

If you want to have multiple replays happening you can kick off parallel runs of the reprocess channel by doing 'imsimta run reprocess &' a number of times.

And, If you want to segregate the storage for each MsgStore machine, you can make new channel in addition to the one suggested 'tcp_to_store' channel. You would then have groups of rewrite rules directing traffic over those channels or you could have one rewrite rule per channel block that you setup. That way you can have distinct entries in your MSG-SAVE-COPY mapping table.

Finally, since there is a rename operation taking place when you use the MSG-SAVE-COPY mapping table, you will want to make sure that at the first pass that /msg_save is on the same device that your queues live on.

Short Term Arvchival

You could setup a process in cron to move those files to a new device on a periodic basis. Better yet, schedule this via the job_controller. For instance, these lines at the top of your job_controller.cnf file:

!

[PERIODIC_JOB=archive_mover]

command=/usr/iplanet/sitescripts/arc_mover.sh

time=/00:10

!

will run the arc_mover.sh script for you every 10 minutes. Your arc_mover.sh could look something like:

#!/bin/ksh

# ***Script is untested - should generate some ideas though****

DUMMY=`test -d /var/tmp/timestamp.dir || mkdir -p /var/tmp/timestamp.dir`

cd /msg_save

#

# First pass

#

for dir in `find ./ -type d`

do

DUMMY=`test -d /real/storage/area/$dir || mkdir -p /real/storage/area/$dir`

cd $dir

for msgfile in `find ./ -type f -newer /var/tmp/timestamp.dir -name "*.00"`

do

mv $msgfile /real/storage/area/$dir/

done

cd /msg_save

done

touch /var/tmp/timestamp.dir

#

# Second pass cause we do not know how long we took.

#

for dir in `find ./ -type d`

do

DUMMY=`test -d /real/storage/area/$dir || mkdir -p /real/storage/area/$dir`

cd $dir

for msgfile in `find ./ -type f -newer /var/tmp/timestamp.dir -name "00"`

do

mv $msgfile /real/storage/area/$dir/

done

cd /msg_save

done

exit

jay_plesset at 2007-7-7 3:39:51 >