Factotum: Documentation Handyman

Lemonade refers to an IETF working group formed to address the requirements of supporting standards-based email in a mobile or other resource-constrained environment. A "resource-constrained" environment is one where any or all of the following might be encountered:

• Low bandwidth, high latency networks
• Intermittent network connectivity
• Scarce power and compute cycles
• Minimizing data usage is a goal

The Lemonade Profile (RFC 5550, http://tools.ietf.org/html/rfc5550) defines a set of IMAP and SMTP extensions that address these constraints. Sun Java System Messaging Server implements the extensions defined in RFC 5550.

For more information on how Messaging Server supports Lemonade, see Messaging Server Lemonade Profile 1 Support.

Hacked Email

The Messaging Server community certainly knows how to deal with this:

• Settin Up a No Phishing Zone
• Protecting Against Spammers Who Compromise Messaging Server User Accounts
  

Last week, I drew attention to a new page of information available on the Communications Suite wiki, recommending that all Messaging Server installations go to the 64-Bit Edition. Today, I updated this page with some more data points that you might want to keep in mind. These points in no way detract from the recommendation, but they do round out the issue. Once more, here's the page: Why Using Messaging Server 64-bit Edition is Better

Yet another Messaging Server expert "caves" to the peer pressure of having a blog. Welcome aboard, Kelly!

Using Messaging Server 64-bit Edition

Beginning with the release of Messaging Server 6.3, on Solaris OS, you have had the choice to install the 64-bit version of Messaging Server. The Communications Suite Product team now recommends that you install 64-bit Edition for new installations on Solaris OS, and upgrade your existing Solaris OS 32-bit Messaging Server deployments to the 64-bit version as time permits. You should no longer be installing the 32-bit version of Messaging Server on Solaris OS.

Reasons to use or switch to Messaging Server 64-bit Edition include:

• Solves the problems with large store.idx files (described in Large store.idx Files Issue).
• Ability to run a reasonable number of imapd processes instead of running dozens of them.
• Better LDAP cache utilization (see also LDAP Cache Tuning in Messaging Server).

  Read the complete writeup.

With the continued move towards using Solaris Zones for creating a Messaging Server installation of multiple instances, another approach to this situation might be getting lost in the mix. New in the Communications Suite installer (available with Messaging Server 6.3p1 and 7.0) is an "altroot" power user feature that enables you to install multiple instances of Messaging Server on the same host.

For more information, see the following document:

Performing Multiple Installations with an Alternate Root

A few caveats with this approach:

• This feature gets limited operational testing, so we recommend field testing before deployment in your environment.
• You have to configure the different instances to use different interfaces (for all the components) to prevent conflicts.
• There are a few Messaging Server features that just won't work (for example, SNMP), and others that might require hand-editing to work (for example, SMF startup).
• You need to understand the implications of altroot patching as well (it creates a SVR4 package/patch datastore separate from the main OS datastore for that information).

Hat tip CN

Not sure how in demand this is for the Comms Community, but just in case, Rajesh posted a nice how-to last month, detailing how to hook up the Portal Server Addressbook provider with Communications Express. Here's the link:

http://blogs.sun.com/rajeshthekkadath/entry/address_book_provider_channel_uwc

Ah, the good ol' days. (BTW, gas price was under $1.50/gallon back then, at least in CA.)

Hat tip Doug G.

There was a question posed the other day about what, if any, character limitations there are for the userPassword attribute in our schema. The questioner pointed out that for the uid attribute, a number of characters are disallowed, including:

$ ~ = # * + % ! @ , { } ( ) / < \> ; : " ” [ ] & ?

Apparently, there are no such restrictions on the userPassword attribute. One of our Messaging experts reports to have seen most, if not all, of the disallowed characters for the uid attribute used in the userPassword attribute.

However, this does not necessarily mean that it is a good idea to consider all of these characters for use in the userPassword attribute.

In general, best practice would be to disallow characters that can be confused by a Unix shell or web page to be a seperator, wildcard, grouping symbol, or other meta character. For example, think about what could happen to a migration script or LDIF output that had userPassword: !/bin/sh;rm -r /*. Instead of just reading the password characters, imagine the damage this could cause if a typo or bad code spawned the command.

The takeway: Just because something is "allowed" doesn't make it a good practice.

Note: uid, which is a synonym for userID (defined in RFC 1274), is used by Messaging Server not only for logging in, but also in hashed form, to specify part of the file path where user messages are stored. Thus, Messaging Server needs additional restrictions on the uid so that the file path constructed using the uid is good and safe. Furthermore, to avoid ambiguity with IMAP ACL syntax, the Message Store also enforces a restriction that the leading character of the uid cannot be a hyphen (-).

Hat tip KH and DL.

An oldie but a goodie: In Case You Missed it, Messaging Server 6.3 Now Supported on Sun Cluster 3.2.

Note also that only Messaging Server 6.3 supports Sun Cluster 3.2 software. Previous versions of Messaging Server do not support Sun Cluster 3.2 software.

BTW, if you're looking for what's supported for the Communications Suite 5 version of Messaging Server (and Calendar Server), here's the scoop.

We just posted a new technical article on how to install, configure, and verify Cloudmark Anti-Abuse Client (CAAC) with Sun Java System Messaging Server.

The component products covered by this technical article are:

• Sun Java System Messaging Server 6.3 and Sun Java System Messaging Server 6 2005Q4
• Cloudmark Anti-Abuse Client (CAAC) 1.3.1.4

Get the article.

What started as a blog discussion here has resulted in the following technical note, published to BigAdmin:

Preferred Practices for Deploying Sun Java System MTA

Synopsis:

Typically, a Sun Java System Messaging Server deployment consists of front-end and back-end services. The front-end services enable users access to the system, while the back-end services store and provide access to data. In the past, we've heard disputes about how to deploy the MTA on the front end: either as an entrance gateway to the system, or “behind” an anti-spam/anti-virus service that also provides an MTA functionality. This article describes the recommended way to deploy your MTA with respect to anti-spam/anti-virus services.

The throw-weight of the Messaging Server documentation is quite impressive. I've been able to adjust the height of my monitor to correct ergonomic proportions with the Messaging Server Administration Guide for years now.

One thing we're missing is a comprehensive Error Guide. Such a guide would have been helpful for the following query:

Why does the ImapProxy_* log files for Messaging Server front end hosts show the following errors:

/opt/sun/messaging/config/ImapProxyAService.cfg (sid 0x39a8bd8)

SSL negotiation failed for IP xxx.xxx.xxx.xxx: Encountered end of file (-5938).

The error reports on two IP addresses, most likely due to the load balancer. Otherwise, the service is running without problems.

If only the mythical Messaging Server Error Guide were able. The user could have then discovered that the above message merely indicates that a connection was made to the IMAP SSL port on the Messaging Multiplexor (MMP), but no SSL negotiation took place. (By the way, you can reproduce this sort of behaviour by simply telnetting to the IMAP SSL port, disconnecting, and then looking at the log files.)

Cause of the error message? In general, load balancers are the culprits. Load balancers tend to connect to each back-end server port they provide load balancing services for to determine if the service is running or not, and then disconnect.

The bottom line on this error message? It's merely information, and from an administrative perspective, you needn't worry.

Hat tip AM

The Radicati Group just released a new report on business use of messaging and collaboration services.

The Good: Messaging is certainly being used within the business workplace to the tune, on average, of users receiving nearly 100 emails a day. (That's a slow day at Sun, by the way.)

The Bad: Spam accounts for 75 percent of email traffic, though only about 18 percent of total messages received are spam, indicating that AV/AS services are working to keep spam out of user's inboxes.

The Ugly: 77 percent of respondants indicate forwarding, at times, business email to personal email accounts. Security policies be damned.

Get more info here.

Reader rolf had this to say about my draft doc titled Messaging Server: MTA Preferred Practices:

I'm very pleased to see this document. It has a clear structure and is easy to read.

If time permits I'll post a more descriptive review. One of the first things that I noticed is that SPF is mentioned, but DKIM is not. From a marketing perspective it is a good idea to mention SPF, but from a technical point of view it's more important to mention DKIM, and the way it can be used in such a configuration.

To respond to this comment, we brought up the topic of DKIM up with an MTA engineer. In brief, the answer is that how you perform DKIM checks has no bearing on how you implement your AS/AV solution with respect to the MTA. On the other hand, your implementation of AV/AS services in front of the MTA definitely impacts SPF, because of its dependency on IP address information.

Additionally, we have omitted describing DKIM in this paper because it raises no unique issues of its own in regards to deployment design that aren't already there for other reasons.

Note: DKIM is a signature-based mechanism. The signature validation is done based on information provided through a header. As such, the system can perform DKIM checks whether or not you place an AS/AV appliance in front of the MTA. (An AV/AS appliance may alter message content in such a way as to break the signature, but that is highly unlikely).

Update, 12/13/07:

We understand that DKIM is something a lot of people want to know more about and we'll undoubtedly have additional materials discussing DKIM in the future - especially once the SSP part of DKIM is finished.