5.6. Mac OS X Mail Server

While most enterprises will already have a stable messaging and groupware infrastructure, Mac OS X Server can also be leveraged for much of the same type of functionality. We have already extolled the virtues of the Address Book, iCal, and iChat; Mail rounds out the groupware offerings quite nicely and also enables Push Notification to handheld devices. In environments where an incumbent solution exists for mail, the Mac OS X mail service can provide ancillary messaging services, such as supplemental or archival mail storage, listserv functionality, virus and spam filtering before mail goes into a separate solution, or act as a relay.

While the Mac OS X Server's mail service doesn't provide as many services for other platforms as it could, it's not because the services that make up the Mac OS X Server mail service are immature. Mac OS X Server uses Dovecot for the message database (POP and IMAP), Mailman for listservs, and Postfix for mail services (SMTP). These tools, deeply rooted in Unix, go back sometimes decades and are as stable, when used for the appropriate environments, as Microsoft Exchange.

5.6.1. Setting up a Mail Server

Setting up Mac OS X Server to be a mail server is much like setting up the other services that have been described. To enable the service, you can use the Server Preferences application. Click on the Mail icon and you will see some simple settings that can be configured for the Mail service (see Figure 5-32). Use the check boxes to enable a few features and then move the slider to the ON position to fire up the service:

• Relay outgoing mail through ISP: Enables all mail being sent from or through the server to be routed through the organization's ISP, which, among other benefits, eliminates the need for reverse DNS.

• Reject email from blacklisted servers: Use spam blacklist server (DNSBLs): Enables spamhaus blacklist servers (default is zen.spamhaus.org).

• Enable junk mail and virus filtering: Enables ClamAv for virus filtering and SpamAssassin for antispam and allows you to set how aggressively it filters email.

  Figure 5.32. Mail Service Server Preferences settings

  

The features available in Server Preferences are minimal and it is highly likely that any substantial user base will require far more configuration. As usual, you can also use Server Admin to configure the Mail Server, with much more granularity.

5.6.2. Configuring Mail with ServerAdmin

To configure mail services with the Server Admin tool, you must first enable the service in the server overview pane, as described with other services. You can then configure numerous details, as shown in Figure 5-33. Here are the general global settings you can configure:

• Domain name: The domain name of the primary mail domain.

• Host name: The host name of the mail server (defaults to the name entered at the time the server was setup if it has not since been altered).

• Push Notification Server: Allows the server to be used with the push notification service to provide iPhone compatibility.

• Enable SMTP: Enables the SMTP service and daemon.

• Allow incoming mail: Enables inbound mail acceptance for configured users.

• Hold outgoing mail: Do not send outgoing mail until it is manually released.

• Relay outgoing mail through host: Relays all mail not destined for local storage through specified server. This option enables an OS X mail server to operate as an intermediate Mail Transfer Agent (MTA), which can be used to route local email to a centralized company SMTP server or to an ISP's SMTP server. The extensibility of the postfix MTA engine means you can use it to provide customized e-mail filtering, which can ultimately be integrated into existing business systems.

• Authenticate to relay with user name: The username for the SMTP server specified in the previous field.

• Password: The password for the SMTP server.

• Copy undeliverable mail to: If an e-mail address is specified, it will be copied on all non-delivery reports (NDRs), a good measure for proactive admins.

• Copy all mail to: Allows for a backup account to store a copy of each incoming and outgoing e-mail that routes through the SMTP daemon. A good measure for the guy who has the "I read your e-mail" bumper sticker, and means it.

• Enable IMAP with maximum of: Enables the IMAP service and allows you to limit the maximum number of connections to it.

• Enable POP: Enables the POP service but does not allow you to throttle the number of connections.

• Deliver to "/var/mail" when IMAP & POP are disabled: stores messages as flat files in the /var/mail directory if no services have been enabled to route mail to.

  Figure 5.33. Configuring Mail in Server Admin

  

You can also configure the supported authentication mechanisms. To do so, click on the Advanced tab, where you will be able to configure authentication options for SMTP and for POP/IMAP services, as shown in Figure 5-34. Of these options, login, PLAIN, and Clear all actually utilize cleartext passwords, so you should think twice about enabling them without SSL configured. CRAM-MD5 is the preferred authentication method and all popular mail clients support it. However, there will be times when your best (or only) option is SSL + cleartext authentication. Notably, if you are using an Active Directory back end for authentication, you will likely need to use this option. Additionally, if you plan to enable webmail, the backend squirrelmail process will require cleartext authentication to be enabled in its default configuration.

5.6.3. Protecting the Mail Servers

Once the settings are configured, click on the Relay tab, shown in Figure 5-35. Here you can configure how the server manages attempts to relay SMTP traffic through it. Using the Accept SMTP relays only from these hosts and networks option, you can configure which IP addresses (and ranges) are able to relay mail through the SMTP service. With Refuse all messages from these hosts and networks, you can also configure a blacklist of IP addresses that you will never accept mail from (for example, those you feel are abusive). Finally, you can configure the Use these junk mail rejection servers (real-time blacklist) option to indicate multiple RBL servers that your SMTP server will use when checking the source server that is attempting to relay or deliver mail.

It is worth noting that in the Accept SMTP relays... option, the networks and IP addresses listed specify unauthenticated external relay only. Relay in the context of SMTP means that the mail is destined for a different mail exchanger. Messages destined for a mail user stored locally on the mail server are not messages requiring relay, but rather delivery. E-mails bound for local users will be accepted from hosts that are not explicitly listed in the Refuse all messages list, or designated as a spammer by a specified RBL. Be particularly careful when configuring IP address relays, as a poorly planned relay configuration can result in your email server being flagged as an "Open Relay," meaning that your server has been determined to be delivering SPAM. For this reason, it is recommended that you leave the allowed relay list relatively sparse and instead require your users to authenticate in order to relay mail.

You can also configure junk mail and spam filters by clicking on the Filters tab (see Figure 5-36. Here are options you can set:

• Enable junk mail filtering: enables the spam filter, which is based on the open source spam filter SpamAssassin

• Minimum junk mail score: When junk mail filtering is enabled, each message is assigned a score that identifies the likelihood the message is spam. You can use this field to identify the score that a message would need to exceed before it is flagged as spam and the appropriate action (defined in the Junk mail messages should be field) to be taken.

• Accepted languages: Allows you to configure acceptable languages for incoming mail. All mail determined to be not on the list will be marked as junk and the appropriate action will be taken.

• Accepted locales: Defines acceptable geographical regions that mail will be accepted from.

• Junk mail messages should be: Defines the appropriate action that will be taken with regard to mail identified as being junk mail.

• Attach subject tag: Can be used to augment the subject line of incoming mail flagged as spam.

• Encapsulate junk mail as MIME attachment: Moves mail flagged as spam into an attachment, which requires user interaction before the mail client will attempt to parse and present the message.

• Enable virus filtering: Enables ClamAv scanning for incoming messages.

• Infected messages should be: Defines the appropriate action to be taken on e-mail identified as containing a virus.

• Send notification to: Allows infected mail to be sent to a specified mailbox.

• Notify recipients: Sends an email advising the receiver of an infected message without sending the message itself.

• Update the virus database: Updates the virus database on a timed interval, defined in number of times per day.

• Enable server side mail rules: Enables preprocessing of rules for all mail coming into the server.

Another way to protect the mail server is to keep users from abusing resources. Not that anyone will do so on purpose, but storage in many environments is a finite resource while consumption typically is not. Therefore, you can configure how mailbox quotas are handled globally using the Quotas tab, shown in Figure 5-37 (quotas themselves are set per mailbox using the Quotas tab on a per-account basis in Workgroup Manager). Here, you specify settings that match your organization's business logic:

• Refuse messages larger than: Identifies the maximum attachment size for incoming mail to the organization.

• Enable quota warnings: Warns users when their mailbox exceeds a specified size.

• Disable a user's incoming mail when they exceed 100% of quota: Blocks a user's mail if his mailbox is full.

  Figure 5.37. Configuring Mail service quotas

  

5.6.3.1. Mailing Lists

Mac OS X Server comes with a fully functional listserv. To configure it, click on the Mailing Lists tab in Server Admin and check the box for Enable server group mailing lists (see Figure 5-38). You can then use the Enable mailman mailing lists check box to enable actual lists. Use the plus icon (+) to create mailing lists, and then the Users & Groups button to drag users to the list.

Mailman is a far more complex solution than this simple screen seems to imply. The configuration files provide an abundance of further options that can be used to tailor the system to your liking, including full support for automated subscription and unsubscription via e-mail. Mailman is a tried and true solution and is pretty much the same beast on OS X as in other environments.

5.6.3.2. Logging

Mac OS X Server by defaults logs events from the mail server. You can customize these events on the Logging tab. Here you can customize the log levels for SMTP and IMAP/POP, as well as for junk mail and viruses (Figure 5-39). Additionally you can set logs to be compressed on a timed schedule by using the Archive logs every field, which specifies the number of days logs are stored before they are compressed.

5.6.3.3. The Command Line

The Mac OS X Mail Service is one of the most feature-rich, with pages of options that can be configured using serveradmin, as described in previous sections. The following command will display a list of settings:

serveradmin settings mail

You can also leverage the various configuration options provided by each of the OS X mail servers' underlying packages. Postfix, for instance, is robust and highly extensible and can be made to work with many plug-ins. For instance, you may wish to inject your own filtering code into the MTA process to watch for emails with particular criteria. To inject your own filter into the MTA pipeline, you would modify the postfix master process config file found at /etc/postfix/master.cf. The main.cf file is another file that controls the overall behavior of Postfix. While the administration GUI in Server Admin provides a decent amount of configurability, it exposes only a small subset of Postfix's capabilities. Through the direct modification of these files, much, much more flexibility can be wrangled out of the system.

While on the topic of Postfix, there are numerous command line-binaries that can assist in the day-to-day management of your mail server. For instance, the postqueue command can be used to manage basic delivery queuing. The following command will output a list of all queued massages:

postqueue -p

Messages in the queue can be flushed (re-sent) either by specifying the -f flag to flush all queued mail, or by specifying the -i flag and a queueid to resubmit just a single email:

postqueue -f
postqueue -i B8EB9C6BDBD

If you have queue problems, sometimes the only solution is to delete certain messages from the queue altogether. Malformed messages can certainly cause problems. To delete a message from the queue, the postsuper command must be used. Postsuper is very similar to postqueue, but it includes (and requires) superuser access to utilize it. Postsuper also provides the only supported way to delete particular mail messages from the queue. For instance, to delete a specific queued message:

sudo postsuper -d 308AE53AF9

or to release all messages on hold:

sudo postsuper -r hold

It is also extremely easy to send an e-mail using postfix's sendmail compatibility features. For example, the following single line of shell code will send an e-mail to user [email protected]:

printf "To:[email protected]
From:[email protected]
Subject:This is the subject


This is the message body.
"  | sendmail -t

5.6.4. Choosing Mailbox Locations

The internal storage of a Mac OS X Server is often not where you'll want to store the database of the mail service. Instead, if you have spacious and fast external storage, you will often use that (obviously, number of users and intensity of use would define the storage requirements). If you want to move the mail database, click on the Advanced tab of the Mail Settings and then on the Data Store subtab, where you will see the location of the default mail store, as shown in Figure 5-40. The default store can stay here, or it can move to external storage by using the Choose button to select an alternate location. The key point, however, is that you can create multiple mail stores at multiple locations, allowing you to use different storage for different tiers of users depending on speed, department, or other requirements you put in place to determine whose mail goes where.

If you are satisfied with your settings, click on the Save button and then restart the Mail service. Once you have created additional mail partitions, you assign individual users to each in Workgroup Manager, under the user's mail tab.

5.6.5. The Dovecot Mailstore

Starting with Snow Leopard, Mac OS X Server uses the Dovecot mailstore as the storage mechanism for mail. The Dovecot mailstore by default exists at /var/spool/imap/dovecot. This folder contains two subdirectories, sieve-scripts, which holds third-party sieve scripts, and mail, which contains subdirectories with user data, named after the respective user's GeneratedUID value. To determine a particular user's GeneratedUID, you can use the dscl command

dscl /Search read /Users/jdoe GeneratedUID | awk '{print $2}'

which generates the output, which will be the name of our folder:

C3C4E3BB-1FE8-4A6E-B445-5474CC4E3223

Each user folder is owned by the respective user and contains index and cache files, mailboxes, and e-mail messages. For e-mail message storage, dovecot uses a flat-file system. That is, every message is represented by an associated file that contains the e-mail's contents, including any attachments in a standard mime-encoded format. Each of a user's mailboxes is represented by dot-prepended directories. Thus, for the mailbox Sent Messages, a folder called .Sent Messages is created. Each of these mailboxes contains a number of files and directories for storage. For each mailbox, e-mails are stored in a subdirectory named cur. These files are stored with a standardized file name that includes a unique identifier, the message size, and the message flags. The user's IMAP Inbox is represented by her root folder on the file system. Specifically, for user jdoe, his inbox is represented by e-mails existing in the folder /var/spool/imap/dovecot/C3C4E3BB-1FE8-4A6E-B445-5474CC4E3223/cur, using the GeneratedUID value found earlier. In order to optimize mail listings, dovecot creates per-mailbox index files that are used to provide accelerated access to commonly queried data, though the index files themselves do not contain any otherwise unrecoverable data. Dovecot utilizes the following cache files:

• dovecot.index: Main index file, contains mailbox summary information, including number of messages and size of and pointer to message cache file

• dovecot.index.cache: Cached mailbox data, including message headers, sent date, and other message information.

• dovecot.index.log: Transaction log file. Used to improve performance in situations where there are multiple concurrent connections.

• dovecot.index.log.2: Rotated transactional log file.

Rebuilding a mailbox in Dovecot is pretty straightforward. To rebuild the index for any Dovecot user's mailbox, you can simply remove the cache and index files mentioned above. The index file will be automatically re-created, and the cache file will begin to repopulate with data as it is requested. If you want to rebuild all index files for a user, the command is fairly simple:

find /var/spool/imap/dovecot/mail/C3C4E3BB-1FE8-4A6E-B445-5474CC4E3223 -name 

  "dovecot.index*" -exec rm {} ;

This command will delete all index files for the user, which will subsequently be rebuilt. While this can be done on a live system, you are deleting files that contain synchronization data, so it's probably a good idea to ensure there are no active connections to the user's mailstore. Upon reconnecting to the server, there may be slight delays for the user as the index files are rebuilt.

5.6.6. Setting up Public folders

Public folders in dovecot can be configured a few different ways. The easiest way is to simply use symlinks. A dot prefixed symbolic link to external directories will be properly resolved by Dovecot and will be presented to the user as a standard mailbox. When setting up such a public share, it is important to note that Dovecot operates within the user context. Thus each user who is granted access to the public folder via symlinks must also have the appropriate file system permissions, designated via either standard POSIX or ACL management. To set up a shared folder in this manner, you can run the following commands:

## cd into the mail store so we can use relative paths
cd /var/spool/imap/dovecot/mail

## create our shared folder and mailbox
mkdir -p Shared/.MySharedFolder

## setup POSIX and ACL privileges on the mailmox for our users
chgrp -R staff  Shared/.MySharedFolder
chmod -R g+rwx Shared/.MySharedFolder
chmod +a "staff allow 

list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,

writeextattr,readsecurity,file_inherit,directory_inherit" Shared/.MySharedFolder

## create our symlinks for our users. We first cd into our user's folder so that we can
## use relative paths on our links
cd C3C4E3BB-1FE8-4A6E-B445-5474CC4E3223
ln -s ../Shared/.MySharedFolder .MySharedFolder

At this point, user jdoe will have full access to the mailbox MySharedFolder. We could then symlink the same directory to another user, say janedoe. The beauty of file-system-level permissioning here is that you can do all kinds of cool stuff with ACLs. For instance, you could prevent janedoe from deleting items, leaving her only with the ability to add new items to the store.

5.6.7. Backing up Mail

With the introduction of Dovecot in 10.6, backing up mail got quite a bit easier. In 10.5, the cyrus database risked potential for corruption when backed up live. Though this was far less of an issue than with earlier versions of OS X, the reality was that it was still recommended to take the system offline to back it up. No longer! Now, mail can be backed up by your standard backup program, be it Netvault, TiNa, or rsync, or even Time Machine. Because each message is stored as its own file system entity, granular message-level or mailbox-level restores are possible.

To perform a restore, just replace the appropriate e-mails or directories into the user's mail root. You can restore entire mailboxes simply by placing the respective dot-prefixed folder there or: alternatively, you can create your own "restore" mailbox, using the following command (here we use 'jdoe' in the mail paths for brevity, it is necessary to use the user's GeneratedUID, as discussed above):

## create the new Mailbox Restored, and it's cur subdirectory, which holds the mail files
mkdir -p /var/spool/imap/dovecot/mail/jdoe/.Restored/cur

## copy our backed up email files into our restore mailbox's cur/ directory.
rsync -avu /path/to/my/backupemaildir/ /var/spool/imap/dovecot/mail/jdoe/.Restored/cur/
## make sure the new user is the owner
chown -R jdoe /var/spool/imap/dovecot/mail/jdoe/.Restored
## Delete our index file, forcing them to be rebuilt
rm /var/spool/imap/dovecot/mail/jdoe/.Restored/dovecot.index*

You can also copy individual e-mail messages into pre-existing mailboxes without much fanfare, though it is once again recommended that you remove the index file.

There are other notable mail-related configurations and database files that you may want to backup, though it's not strictly required:

• /var/amavis: Contains filtering information, including the SpamAssassin Bayes database (all learned junkmail)

• /var/clamav: Contains the latest virus definitions

• /etc/freshclam.conf: ClamAv configuration file

• /etc/amavisd.conf: Amavisd configuration file.

• /etc/mail/spamassassin: SpamAssassin configuration files.

If you are running a 10.5-based mail server, it is recommended to backup its Cyrus database without the service running. An excellent tool named mailbfr can be found at http://osx.topicdesk.com. It is a free utility and manages the backups of the 10.5 database, including stopping and starting the services as necessary.

5.6.8. Clustering Mail Services

As mentioned previously, the Mail Service provided by Mac OS X Server can be clustered, provided you have shared storage with file-level locking. Currently, the only supported means to implement mail clustering is through Xsan.

To set up a cluster, you must first run the Service Configuration Assistant, found by clicking the Change button on the Mail services Clustering tab. Once the assistant fires, you will be presented with the option to create a new cluster or join an existing one, provided that the system detects an available Xsan volume, as shown in Figure 5-41.

Once a cluster is established, it will be stored in a hidden directory, .MailCluster, at the root of the volume. The Mail Service Cluster will be managed by the first host that is added to it. Inside of the .MailCluster folder, you will find a directory named after the name of the Xsan volume, and inside of it reside both configuration files and the mail datastore:

bash-3.2# ls /Volumes/MyCoSAN/.MailCluster/MyCoSAN/
MailClusterConf.plist          config                                     data                                        lock_files

Inside of the config folder you will find both standard dovecot and postfix configuration files. The data folder contains the mail store, smtp spool, mailman datastore, and serverside email rules (vacation messages, serverside filters, and sievescripts). Worth mentioning in this folder is the MailClusterConf.plist file, which contains data relevant to the configuration of the mail cluster, including a list of member servers:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
                <key>cluster_name</key>

<string>MyCoSAN</string>
                <key>cluster_path</key>
                <string>/Volumes/MyCoSAN</string>
                <key>cluster_type</key>
                <string>combined</string>
                <key>members</key>
                <array>
                                <string>snowcat.lbc</string>
                </array>
                <key>name</key>
                <string>MyCoSAN</string>
                <key>path</key>
                <string>/Volumes/MyCoSAN</string>
</dict>
</plist>

Once the cluster is configured, you can verify in the Mail Service's overview that clustering is enabled, as seen in Figure 5-42.