Tuesday Mar 20, 2007

Calendar Server Pop-ups: Not Just For Breakfast Anymore

Ya know, it's actually kinda cool when we use our own products. I'm talking about getting pop-up reminders on your desktop for your Calendar Server appointments. As long as you're running both Calendar Server and Instant Messaging, you can make this happen. And believe it or not, we actually do just that at Sun. Here's how.

To get pop-up reminders, you must have Instant Messaging installed on your network and you must be logged into Instant Messenger. (Instant Messenger can be iconified if you like). With Sun Java Communications Suite 5, the IM configuration wizard configures the iim.conf file for pop-up notifications and there is nothing you need to add to the iim.conf file, unless you want to define an optional password. You still need to modify the Calendar Server ics.conf file and enable calendar reminders in the IM client.

How to do it:

  1. Edit the Instant Messaging iim.conf file as shown below, and restart Instant Messaging. (Only required for versions of IM prior to IM 7.2. You can skip the iim.conf configuration steps if running IM 7.2 or later.)
    ! calendar event config
    \*Note: .domain is the fully qualified hostname of the calendar server such as megademo.demo.iplanet.com
  2. Edit the Calendar Server ics.conf as show belown, and restart Calendar Server.
    caldb.serveralarms = "yes"
    caldb.serveralarms.dispatch = "yes"
    caldb.serveralarms.url = "enp:///ics/customalarm"
    caldb.serveralarms.contenttype = "text/xml"
    caldb.serveralarms.dispatchtype = "ens"
  3. Click the "Show Calendar Reminders" checkbox in the Instant Messenger client. This is contained in the "Alerts" tab in the Instant Messenger "Settings" popup.

Monday Mar 19, 2007

Messaging Server News: Telstra Completes Upgrade

Interested in improving your mail system, and refreshing your aging software and hardware. (Man, if that doesn't sound like a marketing intro, I don't know what is.)

Read about how Telstra (with a 300,000-strong ISP customer base) consolidated onto Messaging Server, T1000/T2000 servers, and Solaris 10 OS:

Sun completes TelstraClear mail upgrade
TelstraClear completes successful email systems consolidation

As I understand it, the Sun Groupware Migration Toolkit played a large part in this upgrade. You can read more about SGMT here:

Escaping Vendor Lock-in: Life After Microsoft Exchange

Monday Mar 12, 2007

Locking Down a Sun Java System Instant Messaging Deployment

Occasionally, someone at Sun actually reads the documents that I write. (Just kidding.) And when they do, they just might not find what they were looking for. So, like good little Sun people, they file a documentation bug. And through the miracle of modern email, that bug ends up in my inbox, alerting me to the dire crisis in the doc.

Don't get me wrong, doc bugs are a good thing, a necessary thing, it's just that I might have an opinion if it's the most important priority that I should be addressing in my Sun life, or if it can wait until some time when I'm not dealing with the usual fires.

That's what happened around the following body of information for Instant Messaging. Some group within Sun, which is tasked with ensuring that we are providing the proper security planning information on all our software products, nailed me for lack of information on Instant Messaging. Here, then, is a summary of what you'll find in the forthcoming Sun Java Communications Suite 5 Deployment Planning Guide.

Overview of Instant Messaging Security

Instant Messaging supports the following levels of security:

  • No Security. Communication is all plain text from client through the multiplexor to the server.

  • Legacy SSL. Secure communication between client and multiplexor, and plain text between multiplexor and server. (This is only relevant if you are using the multiplexor).

  • startTLS. End-to-end secure communication between client and server. If you enable the multiplexor, it does not process any data but instead passes it on to the server.

The startTLS option enables end-to-end encryption (the communication between client-multiplexor-server is all in encryption form), while legacy SSL enables encryption between the Instant Messenger client up to the multiplexor: the communication between multiplexor and server is in plain text (though in a proprietary protocol). Use startTLS if you require a higher level of security. If you use startTLS, you do not need an alternate means of securing the multiplexor-to-server communication (it will be secure).

Protecting Instant Messaging Server and Multiplexor

Instant Messaging supports TLS (Transport Layer Security) and legacy SSL (Secure Sockets Layer) for secure communications. Instant Messaging uses a startTLS extension to the Transport Layer Security (TLS) 1.0 protocol for client-to-server and server-to-server encrypted communications and for certificate-based authentication between servers. In addition, Instant Messaging supports a legacy implementation of the SSL protocol (version 3.0) for encrypted communications between the Instant Messenger client and the multiplexor.

The Instant Messaging default installation supports only SASL Plain. If you require a higher level of security, use the Instant Messaging public Service Provider Interface. SASL Plain and jabber:iq:auth are two forms of plain text authentication. That is, in both, the password is sent in the clear (encoded perhaps, but still clear text) and so both are insecure forms of authentication. Nevertheless, this is an issue only if end-to-end encryption (through startTLS for direct socket connection, and HTTPS for httpbind) is not enabled. If end-to-end encryption is enabled, the password is not “seen” in the clear on the network.

Alternatively, if you do not want to transmit passwords in the clear (even if over an encrypted stream), use the Instant Messaging SPI for plugging in authentication mechanism's at the server side through SASLRealm. You can implement custom SASL mechanisms as implementations but you will then need an Instant Messaging client that supports this custom mechanism. The Sun Java System Instant Messaging client supports only SASL Plain, jabber:iq:auth (both insecure).

Providing Instant Messaging Client Access Through a Firewall

The XMPP/HTTP Gateway (httpbind) provides Instant Messaging access to XMPP-based clients, such as HTML based clients, and clients that are behind firewalls that allow HTTP traffic only and don't permit XMPP traffic. The gateway proxies Instant Messaging traffic to the XMPP server on behalf of HTTP clients.

Protecting the Instant Messaging Archive

Instant Messaging has the capability to archive instant messages for later retrieval and searching. If you enable the email archive, you need to decide which administrators will receive email containing archived instant messages. You can configure a separate list of administrators to receive polls, news, conference, alerts, or chat sessions. You can also configure Instant Messaging to use the extended RFC 822 header. Doing so allows mail clients to filter messages based on the header content. If you do enable the Portal archive, you can decide which administrators can access the Portal archive database.

Thursday Feb 08, 2007

Adding Capacity to Sophos PureMessage AV/AS

The self-described "lone sysadmin" has a good post up on adding capacity to his Sophos PureMessage AV/AS configuration for his Messaging Server (and sendmail) deployment.

Messaging Server supports Sophos, and a number of other AV/AS solutions, as I posted here.

Messaging and Calendar, Say Hello to Norway

Norwegian Governmental Services To Be Powered by Sun Solutions, Including Messaging Server and Calendar Server

The Norwegian government announced a deal with Sun to use the Solaris 10 Operating System, and Sun servers and software, including Messaging Server, Calendar Server, and Portal Server, to enable citizens to have secure, browser-based public access to government services through a secure and personalized portal interface. The complete end-to-end Sun solution allows the government to drive innovation and provide an online platform for citizens to vote, pay taxes, obtain social security benefits, register and manage automobiles, communicate with public officials and conduct other civic initiatives and services.

» Read the Entire Article

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:


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:


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.)

Monday Feb 05, 2007

New in Messaging Server 6.3: MeterMaid

In the current version of Messaging Server 6.x (and for that matter, 5.x), to limit email coming to the Messaging Server MTA from a particular sending host (IP address), you use the shared library, conn_throttle.so in the Port Access mapping table. Limiting connections by particular IP addresses can be useful for preventing excessive connections used in denial-of-service attacks. This technique is also referred to as "throttling" a host (or IP address).

Messaging Server 6.3 will extend this ability with MeterMaid. MeterMaid enables throttling by determining when an IP address has recently connected too often and should be turned away for awhile. MeterMaid represents the officer patrolling the streets, looking for those who have exceeded their allotted amount. It is a repository process that supplants conn_throttle.so, providing similar functionality but extending it across the Messaging Server product. In addition, MeterMaid is more configurable than conn_throttle.so. Of note: No further enhancements will be made to conn_throttle.so going forward.


The primary improvements by MeterMaid are that it is a single repository of the throttling information that can be accessed by all systems and processes within the Messaging Server environment. It continues to maintain an in-memory database to store this data to maximize performance. Restarting MeterMaid will lose all information previously stored, but since the data is typically very short lived, the cost of such a restart (done infrequently) is very low.


MeterMaid is accessed from the MTA through a mapping table callout using check_metermaid.so. It can be called from any of the _ACCESS tables. When called from the PORT_ACCESS table, it can be used to check limits based on the IP address of the connection which will be the most common way to implement MeterMaid as a replacement for the older conn_throttle.so. If called from other _ACCESS tables, MeterMaid can also be used to establish limits on other data such as the envelope from or envelope to addresses as well as IP addresses.

Only one entrypoint in check_metermaid.so is defined. The throttle routine contacts MeterMaid providing two subsequent arguments separated by commas. The first is the name of the table against which the data will be checked, and the second is the data to be checked. If the result from the probe is that the particular data being checked has exceeded its quota in that table, check_metermaid.so returns "success" so that the mapping engine will continue processing this entry. The remainder of the entry would then be used to handle this connection that has exceeded its quota.

Again, your definitive source of information on MeterMaid, once 6.3 is out, will be the chapter 19 in the Messaging Server 6.3 Administration Guide.

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):


Friday Jan 26, 2007

Messaging Server Basics: Defragmentation

Let's face it, Sun Java System Messaging Server is a complex product. The MTA is a very powerful piece of code, enabling you to do all kinds of email routing/filtering/etc. I won't even pretend to understand it to the extent that I should.

What I can do, as a writer, though, is to try and pass along those aspects of the product, that, if we had the time, would make up the basics, those concepts that seem to come up regularly within our internal aliases and set of questions. One of those examples would be defragmentation.

The MTA in Messaging Server contains a feature that enables automatic defragmentation of messages or partial messages. What does this mean? To quote from the Messaging Server 6 2005Q4 Administration Guide:

"The MIME standard provides the message/partial content type for breaking up messages into smaller parts. This is useful when messages have to traverse networks with size limits, or traverse unreliable networks where message fragmentation can provide a form of “checkpointing,” allowing for less subsequent duplication of effort when network failures occur during message transfer. Information is included in each part so that the message can be automatically reassembled after it arrives at its destination."

You implement defragmentation by using the defragment channel keyword and the defragmentation channel. Furthermore, the defragment channel only retains messages in the defragment channel queue only for a limited time. When one half of the time before the first nondelivery notice is sent has elapsed, the various parts of a message will be sent on without being reassembled. This choice of time value eliminates the possibility of a nondelivery notification being sent about a message in the defragment channel queue.

Okay, knowing all this, where does that leave us? Well, you might use the imsimta qm > summarize command to look at what is happening with your MTA message queues, and you might observe that there are x number of messages queued up in the defragmentation channel. Furthermore, in diving into reading the defrag'd files, you see that there are actually y number more parts to the messages. Is this a problem, you begin to wonder, with the defragmentation channel?

The short answer is no. In fact, the MTA and the defragmentation channel are working normally. What has happened is that a message has been fragmented into y parts but you only have x parts in the defragmentation channel queue. Because y is greater than x, no matter what the specifics of the messages in the queue, there are not enough parts present for reassembly to be performed. This situation continues until either all the parts arrive or the time limit for reassembly (noted above) is reached, at which point the message fragments will be sent on unassembled.

A basic, best practice for defragmentation is also to put the defragment keyword on a channel destined for a third-party scanner box, since scanners might take the approach of rejecting all fragmented messages (if the scanner cannot assemble the fragments together itself).

I hope to do more of these Messaging Server "basics" pieces over time. Stay tuned for more.

Monday Jan 22, 2007

Communications Suite - Overlooking the Obvious?

I get lots of email concerning all kinds of aspects of our Communications Suite products. As a writer, part of my job is to sift and dig through this constant heaping of information, and ultimately help determine what to do with it.

Here's a quick grab bag of facts that seemed perhaps obvious and then again, perhaps not. If we had a Frequently Asked Questions document, this is where I would locate such information. (Note: I am investigating a means to do this on a Sun external site, such that the FAQ would be editable by anyone. Stay tuned for details.)

PDA Access to Communications Express?

You need Sun Java System Communications Sync, which syncs PalmOS and Windows Mobile 5.0 PDAs to Sun calendar and contacts.

Communications Express Without Access Manager?

It's a current requirement, when running Communications Express 6 2005Q4 to have to use Schema 2 and Access Manager. The Access Manager requirement is evidentally removed in the upcoming release (Communications Suite 5, Communications Express 6.3). The Communications Express 6.3 Administration Guide will have the details.

Will a New Messaging Server 6.x MTA Function with a 5.2 Message Store?

It depends on your setup. You cannot mix Messaging Store 5.2 store executables with 6.x MTA executables. However, you may deploy a 6.x MTA running on one host delivering mail to a 5.2 Message Store running on another host. In such a deployment, you'll also need a 5.2 MTA on the store machine because LMTP isn't supported in Messaging Server 5.2, but such a setup will function.

ACLs Missing from Messaging Server 5.2 imsbackup?

The imsbackup utility in Messaging Server 5.2 does not back up the ACLs. This is a known issue. Unfortunately, this could impact maibox migrations. As a workaround, you can get the ACL list from the old store with the following command:

mboxutil -l -p pattern -x

then set it with readership -s after the migration.

Adding New Spelling Dictionaries to Communications Express?

The dictionaries in Communications Express are from ispell, which can be downloaded here:


See the Communications Express Customization Guide for details on installing the new dictionaries.

Calendar Server: Linux or x86 Front-end with a Solaris SPARC Back-end?

Beginning with Calendar Server 6.3, mixing different architectures for front-end and back-end machines is now supported. The hardware platforms no longer must be the same on each end. The big-endian vs.small-endian incompatibility no longer applies and you can now use both an x86 platform machine and a SPARC platform machine in the same Calendar Server deployment containing front-end and back-end machines. You can also mix Linux and Solaris x86 systems for front-end and back-end machines.

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.

Wednesday Dec 20, 2006

Messaging Server & Communications Express: Improved Migration of Personal Address Books

As I wrote about previously on this blog, I've been working on a Sun BluePrints article on how to migrate the Messenger Express Personal Address Book to the Communications Express Address Book Store. This BluePrints article is now available here:



The Messenger Express Web-based email client includes a Personal Address Book (PAB) application for storing and managing user's personal information, such as email addresses and phone numbers. Sun Java System Communications Express, the unified Web client introduced in Sun Java Enterprise System 2004Q2 supersedes Messenger Express and Calendar Express. Communications Express also includes Address Book Store (ABS) that provides all of the functionality of PAB and is better integrated with mail and calendar components.

When upgrading from Messenger Express (also known as Webmail) to Communications Express, you need to migrate users' PAB entries to ABS. (This migration does not occur automatically as part of the upgrade process.) A new tool, pab2abs.pl, has been made available that provides improved performance over the earlier migration tool, runMigrate.sh. This article describes how you can use the pab2abs.pl tool to either migrate a single or a few users, or to migrate your entire PAB database.

Messaging Server and Mailstore Best Practices - "Muling" Over Your Options

When it comes to setting up the disk partitions on your mailstore, the Messaging Server experts agree: spread your mailboxes out across multiple partitions. The benefits include:

  • Faster times to back up and restore mailboxes
  • Less risk of data loss (you lose only those mailboxes on a particular partition instead of all mailboxes on a single partition)
  • Increased performance and scalability (assuming the partitions are accessing separate spindles)
  • The ability to run many imsbackup instances in parallel, one per partition, which can help to back up many gigabytes of mail in the 6-8 hours you normally have
For information on configuring mailstore partitions, see Chapter 18, Managing the Message Store, in the Sun Java System Messaging Server Administration Guide.

Deciding on The Number of Partitions

To decide upon the number of partitions to create, consider the following:
  • Partitions are logical objects, so equate the partition to a file system. Because of this, your partitions depend on the file system type.
  • With UFS you have a limited set of inodes to manage. Pay attention to the expected mailbox population (number of mails, attachments, minimum and maximum size, and so on) to estimate the number of inodes needed. Based on that, define your file systems/partitions. In the Solaris OS environment, use the df -o i command to see the inodes your file systems have.
  • As a best practice, limit a single partition's size to less than 1 TByte. It is further suggested that you use no more than 900 GB per partition.

Quick Primer on Configuring Mailstore Partitions

To configure a mailstore partition, you make the mailstore aware of the partitions by using the configutil command, for example:

configutil -o store.partition.nickname.path -v path

where nickname is the logical name of the partition and path indicates the absolute path name where the partition is stored.

Next, on the user directory entry, set the mailmessagestore attribute to the nickname of the partition.

Additionally, you can set the default partition (if the user doesn't have a mailmessagestore attribute) by using the configutil store.defaultpartition attribute as well as the default primary partition with the following command:

configutil -o store.partition.primary.path -v path

Monday Dec 18, 2006

Great Ideas in the History of Sun Java System Messaging Server, Vol. I

We're all taught in school and in business, no question is a dumb question. It's just that some of the ideas we get might be not so brilliant to begin with. One needs to fully understand the situation before getting into trouble with one's brilliant ideas.

Take for example, the idea that crops up every now and then in the Messaging Server world of disabling the SMTP banner to not show the server name and the version of the application that is running. On the surface, this sounds like a good request, one to ensure more system security. After all, one can't be to concerned about security.

However, let's break this down a bit.

Messaging Server does not support not returning a server name because it is contrary to the SMTP standard. Not returning the SMTP banner causes all sorts of problems with lost or bounced mail. (See RFC 2821 for more information.)

Now, if you want to change the server name that's returned, you can use the BANNER_HOST TCP channel option. Furthermore, you can change the additional information that is returned by setting the CUSTOM_VERSION_STRING TCP channel option.

But perhaps the best thing to do before embarking on such a course is to understand that not returning the SMTP banner makes a site less secure and not more secure. A recommended read before doing anything is Bruce Schneier:


As with most things in administering a complex environment (and in life), doing your homework first will save you a lot of headaches later.

Stay tuned for more "Great Ideas in the History of Sun Java System Messaging Server."


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


« July 2016