Wednesday Feb 07, 2007

Messaging Server and Email Disclaimers: Pros & Cons

So you want every sent email from every employee to carry a company disclaimer message. Whether because of increased awareness of confidentially, legality, or fashion, appending disclaimer messages to out-going mail is here with us.

But before asking how to do this with the Sun Java System Messaging Server MTA, step back and ask if you really need to do this. Start by reading the following:

http://www.goldmark.org/jeff/stupid-disclaimers
http://www.goldmark.org/jeff/stupid-disclaimers/apply.html

Here's perhaps the money quote:

"In the end, I think, although I am vastly ignorant of the law here, that adding disclaimers only makes you more vulnerable. This is because without disclaimers reasonable conventions and existing law apply. But once you add the disclaimer you had better get it exactly right and on exactly the right messages, and you sacrifice reasonable convention."

Okay, let's say that in spite of this advice, you want to proceed full steam ahead anyways and get every outgoing message from the MTA to bear this disclaimer stamp. Our experts advise the following:

  1. First, be aware that there is no way to fully implement this at the server level. The only proper way to do disclaimers is to have a policy requiring users to insert them in their mail clients.
  2. The next best approach is to write a conversion channel to add the disclaimer. The conversion channel can be used to perform arbitrary processing on each message on per body part basis. In this case, you want the processing to be that of appending a disclaimer. You end up modifying the MTA configuration files so that all your mail passes through this conversion channel. At a minimum you'd want to construct one conversion to account for text/plain message body and one to account for html. You'll need to add more if the actual messages being sent have some other sort of MIME structure unique to your deployment.

For more information, see the following:

http://docs.sun.com/app/docs/doc/819-2650/6n4u4dtr3?a=view

Some Troubleshooting Advice

If you configure the MTA as described above, and run into problems where the disclaimer is not appearing, you should begin by looking at your conversions file, and get a master_debug conversion channel debug log file. (The tcp_local_slave.log-\* file, and the mappings file, are just about getting the message to the conversion channel. The appending of the disclaimer would be done by the conversion channel, so you need to see what the conversion channel itself is doing.)

Friday Feb 02, 2007

Messaging Server 6.3 Spotlight: Messaging Archiving

As we get closer to releasing Messaging Server 6.3 (part of Communications Suite 5), I thought I'd provide a bit more detail on some of the major feature enhancements. This entry focuses on Message Archiving, also known as AXS-One Archiving.

What Is Message Archiving?

A message archiving system saves all or some specified subset of incoming and outgoing messages on a system separate from Messaging Server. Sent, received, deleted, and moved messages can all be saved and retrieved in an archive system. Archived messages cannot be modified or removed by email users so the integrity of incoming and outgoing is maintained.

How Is the Archiving Support Provided?

In 6.3, Messaging Server supports archiving through the AXS-One archive system.

How Is Message Archiving Useful?

There are two ways to look at archiving, compliance and operational. Compliance archiving is used when you have a legal obligation to maintain strict retrievable email record keeping. Selected email (selected by user(s), domain, channel, incoming, outgoing and so on) coming into the MTAis copied to the archive system before being delivered to the message store or the internet. Archiving can be set to occur either before or after spam and virus filtering. Operational archiving is used for mail management purposes, for example to reduce storage usage on the Messaging Server message store by moving less used (older) messages to an archiving system which uses lower cost storage (that is, an alternative for data backup). Note that compliance and operational archiving are not exclusive. That is, you can set up your system so that it does both compliance and operational archiving.

Where Can You Get More Information?

The Messaging Server 6.3 Administration Guide will have overview information on message archiving. The Message Archiving Using the AXS-One System technical note will contain detailed deployment instructions. As usual, you'll be able to get these docs through the docs.sun.com web site, or better yet, through the Communications Suite Hub Library tab.

Note: If you have access to the Beta, you can read the AXS-One technical note now at (sorry for those who don't, it's password protected):

http://docs.sun.com/app/secure/doc/819-6991

Friday Jan 19, 2007

Messaging Server: Security Issues with Anti-Spam and Anti-Virus Deployments

When planning to deploy anti-spam or anti-virus technology with Sun Java System Messaging Server, keep in mind that an incorrect deployment can defeat your security measures. The following figure shows an incorrect deployment of an anti-spam/anti-virus filter solution.

The next figure shows a correct deployment of an anti-spam/virus filter solution.

The Messaging Server MTA performs certain functions well, including:

  • Rejecting messages as early as possible
  • Per-user configuration and policy
  • Email security and routing policy
  • Mail queue management

The anti-spam/virus filter is good at determining if an email is spam or has a virus, but is generally not nearly as good at doing the things expected of a good MTA. Thus, do not depend on an anti-spam/virus filter to do those things. Your deployment is more "correct" when the anti-spam/virus filter is well integrated with the MTA, which is the case with Messaging Server. Messaging Server spam filter plug-in support provides all the potential reasons to reject a message early and applies all reasons at the same time.

A robust MTA, such as Messaging Server's, contains security features (SSL/TLS, traffic partitioning by IP address, early address rejection to reduce denial-of-service attacks, connection throttling by IP address/domain, and so on), which are defeated when an anti-spam/virus filter is deployed in front. Furthermore, anti-spam/virus filters that communicate by using the SMTP protocol often do not follow the robustness requirements of SMTP and thus lose email when they shouldn't. A correct deployment should have the anti-spam/virus filter working in conjunction with a robust MTA.

Monday Jan 08, 2007

First Line of Defense Against Spam: Greylisting & Messaging Server

What is Greylisting?

Per Wikipedia: Greylisting is a method of defending electronic mail users against email spam. A mail transfer agent which uses greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again to send it later, at which time the destination will accept it. If the mail is from a spammer, it will probably not be retried, and spam sources which re-transmit later are more likely to be listed in DNSBLs (DNS "black lists") and distributed signature systems such as Vipul's Razor.

Greylisting requires little configuration and modest resources. It is designed as a complement to existing defenses against spam, and not as a replacement.

If you're interested in configuring greylisting for Sun Java System Messaging Server, there's a nice solution called Gross, which was written by a current Messaging Server user.

The "magic" of this solution is based on the observation that spammers almost never queue their mail. In general, spammers send their message just once, and, if the attempt does not succeed, the message is not retried. By giving a temporary error on the first spam attempt, you are able to deny most spam immediately.

Note that Gross works well for sites that have "conservative" spam policies. Greylisting can delay legitimate messages as well. Because Gross imposes greylisting only for those hosts found on various dnsbls, the impact for legitimate mail is minimal.

Friday Jan 05, 2007

Extracting Tasks and Events From Sun Java System Calendar Server

There are a couple of ways to get task information for Sun Java System Calendar Server users, including:

# ./cscal -v list calid

# ./cscomponents list calid

# ./cscomponents -t task list calid

However, these commands merely return the number of tasks for the calid (user) specified.

I'm currently working on documenting an in-house way we have of providing our Sun Java System Calendar Server users with a daily summary of their Sun Java System Calendar Server events and tasks, emailed to their inbox or mobile device each weekday morning. This tech tip will show you how to create a Bourne shell script, which uses Web Calendar Access Protocol (WCAP) commands. On a daily basis, this script finds all events and tasks from users' calendars then emails them to the individual users. A cron job executes the script according to your preferences. The email that users receive resembles the following:

Times shown in America/Los_Angeles
---Event---
Directory setup meeting
 Starts  10/23/2006 14:00
Reminder: Directory setup meeting
 SunIT Directory setup meeting 866 835 8198 9325445
---Event---
Writer's Workshop
 Starts  10/23/2006 18:00
 Writer's Workshop
---Task---
Car - book service
 Starts  10/23/2006 09:00 

Look for this tech tip to be published very shortly.

About

Reporting about Unified Communications Suite Documentation, including news, Comms 101, documentation updates, and tips and tricks.

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today