Host Corporate Email — Part 4

In part three of this four-part series, we took a look at MX records, and how properly-configured DNS is essential for email hosting. In this final installment, we'll take a look at ways to insure uninterrupted service and handle high volume for your corporate Macintosh-based email server.

Deploying A Backup MX Server:

If you've followed along with this series, you should now have a functioning well-configured mail server, available to the internet and exchanging messages from inside and outside your company. That's an adequate solution until a power outage, a loss of internet connectivity, or a hardware failure takes place. When disaster strikes, this machine becomes a single point of failure for your entire communications system, with employees unable to send or receive mail.

Historically, the answer to this problem has been to always have a backup MX, a secondary server that handles mail in the event the primary server is unreachable or inoperative. For most organizations that's still the best solution, as it allows not just redundancy but lets you geographically separate the machines on separate power grids and ISPs if you have a second office.

To set up a backup MX server, first add an additional MX record in both your internal and external DNS. The record name traditionally indicates that it's your secondary MX (such as mx2.makemacwork.com) and is set with a lower priority (and therefore, a higher number) like 20. This tells anyone sending your domain email to attempt delivery to your backup MX should connection to the primary MX fail.

Next, configure a second Mac OS X Server as you did the first, but using the second server's name as both the "Domain name" and "Host name" in the "General" pane of the Server Admin mail settings. Make sure IMAP is disabled, but check "Relay outgoing mail through host" and fill in the name of your primary mail server.

As a last step, you'll need to go back to your original server, and configure it to allow relaying from your backup host. In the "Relay" pane of the Server Admin mail settings, add the IP address of your secondary mail server. This allows any mail stored on your backup MX while your primary is down to be accepted without further authentication. Restart the mail service on your main host, and you should now have redundant mail receipt and delivery.

This time-proven method is how businesses and universities have avoided mail outages for the last twenty years, and few operating systems make it as easy to set up as Mac OS X. Ideally, your backup MX server will be housed, powered, and connected to the internet separately. If that's not possible, simply putting the machine on a separate circuit with a cheap cable or DSL connection can still get you through a host of unexpected problems (and more importantly, through routine maintenance).

XSan Mail Clustering:

From the old-school to the new-fangled, the more modern way of handling the need for mail service redundancy is mail clustering, where mail service can be handled by multiple servers all sharing a common real-time storage pool which holds incoming and outgoing messages. Mail clustering itself isn't a new idea, but Apple's version of it (requiring both Leopard and XSan 2) is so recent it doesn't yet even have documentation.

Nonetheless, if you're familiar with XSan implementation, the new clustering features aren't hard to take advantage of. The XSan 2 Admin tool allows you to create new Volumes optimized for Mail and assign them Affinities through a simple configuration wizard. You can then choose "Clustering" from the "Advanced" pane in Server Admin's mail settings, and click the "Change" button to launch another wizard to reconfigure your mail setup across multiple XSan client servers.

The advantage to Xsan mail clustering over the backup MX approach is primarily one of performance, with huge arrays of disks able to process mail more quickly and store it more efficiently. The disadvantage in most cases is that those arrays must be physically attached to multiple servers in the same location. Still, this setup eliminates the majority of reasons you might outsource your company's email service. If your organization needs redundant delivery and scalable performance, the only thing now standing in the way is next year's budget.

Special Thanks: Our friend and colleague Eddie Kelley, technician extraordinaire at Portland's Mac Pac, volunteered how to set up a backup MX without ever resorting to the command line.

Recommended Reading: If you're planning on maintaining a Macintosh mail server, it's important to have at least a passing understanding of Postfix, the open-source mail system OS X uses. By far the best reference is Ralf Hildebrandt and Patrick Koetter's Book of Postfix, available in PDF from publishers No Starch Press.

Host Corporate Email — Part 3

In part two of this four-part series, you set up user accounts, storage restrictions, and authentication methods for new email hosting on an OS X server. This week, we'll look at what it takes to bring your new mail server up smoothly on your internet domain.

Testing An Isolated Email Configuration:

As much work as you've done up until now, the only machine that knows you're running mail service is the email server itself. Take advantage of that fact to adequately test your existing configuration, sending messages to a test account (from both inside and outside your network), collecting them using an IMAP client configured specifically for this purpose, and using the machine as an SMTP server to send mail out to other addresses. It's ten minutes of mild annoyance, but it could save you hours of frustration if there are problems you don't find until the system is live.

MX Records And The Domain Name System:

Once you know your server can send and receive mail properly, it's time to let the whole world know it's there. Like most internet services, successful communication between machines requires that the appropriate DNS information be available to every computer involved in the transaction. While it's unlikely you'd implement your own mail system without a strong working knowledge of the Domain Name System, email is unusual in that you'll need to adjust DNS both inside your own network and out on the internet.

On your internal DNS servers, you'll have to point to your mail servers (in the form of MX records). In the DNS Zones settings of Server Admin, simply click the "plus" button next to the "Mail Exchangers" field and fill in the hostnames for the email servers you're about to configure. Then assign the priority (the order mail delivery is attempted) to those hosts, usually 10 for the primary MX (the only server set up so far).

If the DNS servers you administer control the DNS for your external domain as well, then mail will start moving towards your new servers as the new MX records propagate across the internet Domain Name System. More likely, your external DNS is controlled by a parent company or bandwidth vendor. In those cases, you'll need to have them change your external MX records as well.

Testing Your MX Records:

When an email client sends mail to an address like user@example.com, it queries it's DNS servers for the MX record to the example.com domain, and makes an SMTP connection to send mail to the server address that's returned. So once you hit "Save" in the bottom right of the Server Admin window (or your ISP does the equivalent on their end), every machine that receives your updated information will start sending mail to your new servers.

Once you've flipped the switch, it makes sense to check the MX records for your local environment immediately. Open the Network Utility application, select the "Lookup" pane, then "MX Record" from the pull-down menu. Enter your domain name and click "Lookup" to see the current data offered by your immediate DNS provider.

Be aware, however, that DNS is propagated in fits and starts, as each server synchronizes MX record changes at their own pre-determined schedules across the internet. Machines which share your primary name server may begin using the updated MX records immediately, with large ISPs following suit in a matter of minutes, while international providers or smaller services could take hours or (in a worse case but not uncommon scenario) days.

As a rule of thumb, you'll want to have your DNS settings in effect at least 48 hours before your users need to rely on dependable mail delivery (with a common strategy being to enact changes Friday evening one the office is empty). Come Monday morning, your users should have a brand new mail system, fully operational and under your company's control.

Next Week: In our fourth and final installment, we'll take a look at strategies for redundancy and high-availability to make OS X email truly suitable for corporate use.

Recommended Reading: Paul Kincaid-Smith's article Configuring DNS For Standards-Based Mail Service gives an excellent overview of the issues administrators most often face with MX records.

Host Corporate Email — Part 2

In part one of this four-part series, we took a look at configuring basic email service on OS X Server, determining which domains we'd receive mail for, and what kind of messages we'd allow to get through. This week, you'll decide whose mail you'll accept (and distribute), how much of it you can reasonably store, and where to put it all.

Setting Up Email User Accounts:

Moving away from Server Admin for a moment, where you've done all your mail service work up until now, open Workgroup Manager and choose "Accounts" from the toolbar. Select the "Users" icon from the strip above the left column (represented by a single silhouette), and highlight each user you wish to host email for. Select the "Mail" pane from the strip across the top right, and click "Enabled" button.

In the "Mail Server" field, fill in the name of your primary mail host to accept messages for each user, while under "Mail Access" you'll want to choose "IMAP only" to ensure messages can be properly synchronized to multiple devices. In between those two options, you'll need to choose a "Mail Quota" to determine how much email the server will store for that user. While quotas may be necessary for capacity planning, it's good to remember that the cost of disk space is relatively low compared to the expense and hassle of lost or deleted data.

Back in Server Admin, navigate to the mail settings "Quotas" pane. It makes sense to "Enable quota warnings" to alert users as they come close to their storage limits, and the preset threshold of 90% seems wise. The default setting to "Refuse messages larger than" 10MB makes little sense, though, when most Macintosh environments are in video or graphics production. Somewhere between 50-250MB is likely more appropriate, providing the timely mail delivery while still allowing exchange of media files.

Deciding On Email Storage Locations:

While you're determining how much space you can use to retain live email, it's a good time to think about just where on your server you'd like to put it all. Two tabs down from your quota settings is the "Advanced" pane, and skipping to the third option on the strip below are the email "Database" settings. OS X Server uses the open-sourced Cyrus IMAP system for mail access, and unless you specify otherwise, keeps the email database itself in /var/imap and user's messages in /var/spool/imap. The biggest problem with these locations is that they reside on (and without quotas could potentially fill) the boot volume. A better choice is to relocate them to a separate RAID partition or volume before you ever start the mail service. You can do so by simply clicking the "Choose..." button to the right of each option.

Securing Email Access:

In order to send or receive email, a client application must convince the server it's authorized to do so. In the early academic days of the internet, users collected their mail with plain text (or unencrypted) passwords, and sent mail from any available server. To fit the needs of the modern business world, however, requires the authentication options in the "Security" pane of the "Advanced" mail settings.

SMTP (or Simple Mail Transport Protocol) is what relays messages from their sender to their intended recipient. Unsecured SMTP servers (also known as open relays) are the source of most Spam, and a good way to get your mail server blacklisted so that others won't accept its messages. Check the "CRAM-MD5" box below the SMTP options to insure that only users with a valid, encrypted password can send mail through your server. While less commonly supported, Kerberos authentication (the security mechanism behind Open Directory) also makes sense for VPN or internal networks.

For IMAP, restricting who can collect email from server accounts is equally important. Again, CRAM-MD5 and Kerberos are reasonable options, while less secure methods only make sense if backwards compatibility with older systems is a priority.

Finally, to encrypt not just passwords but all of your email traffic from server to client, consider utilizing SSL certificates (most commonly used for web servers). If you already have one from a certificate authority, you can take advantage of it for email as well. Select "Use" (but not "Require" unless all your email devices support SSL) for SMTP and IMAP, then select the appropriate certificate from the pull-down menu. Hit "Save" in the bottom right, then "Start Mail" on the bottom left, and you're almost ready to start running your own corporate mail service.

Next Week: In part three, we'll configure DNS and MX records to properly direct email to your new email server.

Recommended Reading: You can learn more about SMTP, which carries all email across the internet, at Daniel J. Bernstein's excellent (and very detailed) reference site. For a better understanding of Cyrus System Administration, Dianna Mullet & Kevin Mullet offer a free chapter from their excellent (if slightly dated) volume "Managing IMAP".

Host Corporate Email — Part 1

Email has become the electronic life's blood of a company, the primary means used to communicate with co-workers and customers alike. This makes the stability and dependability of your email system the foremost responsibility of any IT team. In this four-part series, we'll take a look at the best ways to configure new mail service for businesses on OS X Server, and why you might consider other options.

The Argument Against Hosting Your Own Email:

Since even before the popularity of the World Wide Web, running an internet email server has been synonymous with being an systems administrator. Windows-based organizations are most often built around Exchange systems, and few companies want to pay extra for outsourced services when they're already paying someone good money to handle their IT needs.

There's one good reason, though, to consider having your organization's email handled by a dedicated hosting company: They'll probably do a better job than you. More accurately, their environment is likely more robust, with multiple servers dedicated to mail, internet connections from several providers, and redundant power from two or more grids. Hosting services also include spam filtering, meaning that full-time spammers can fight full-time filtering systems instead of eating up your time and energy in an escalating arms race. With external hosting costs at $3-5 per user monthly, it's worth adding up what hosting your own email might actually cost you.

Outsourcing email doesn't make sense for every business (such as those with data centers, full-time IT staff, and/or regulatory requirements like HIPAA or Sarbanes-Oxley). For smaller companies, though, or those with limited resources, it's an option to consider before implementing mail service on your own servers.

Configuring Basic Mail Service:

If your company decides to host email for its new domain in-house, the first step is to set up the Mail service on the machine you've chosen as your MX (or Mail Exchange) server. Open Server Admin and select the first server, choosing "Settings" from the toolbar and enabling "Mail" from the checkboxes below. Then select Mail from the left column, choose "Settings" from the toolbar once again, and start with the "General" configuration pane. Fill in the name of your domain (such as makemacwork.com) and of the machine you're configuring (like mx1.makemacwork.com) in the "Domain name" and "Host name" fields.

Next, uncheck "Enable POP", the more common of the two Unix email-retrieval protocols, which deletes messages from the server as they're collected. While POP (designed in the days of dial-up connections) utilizes low bandwidth, it significantly increases the chances of messages being misplaced or deleted by users and isn't really designed for enterprise use. Instead, enable IMAP (which can synchronize mail on the server with multiple devices such as laptops, iPhones, or a webmail interface), with no limit on the number of connections.

To allow incoming mail to be accepted by the server, check "Enable SMTP", and below it "Allow incoming mail". If your business is required by law to retain copies of all communications, you can check the "Copy all mail to" box and fill in an address to archive to, but be prepared that a company of reasonable size could fill up Terabytes annually with this approach.

Email Filtering Tools And Strategy:

Starting email is easy. It's stopping it (or rather, handling it selectively) that takes work. OS X includes a number of mechanisms to regulate what kind of email users can receive and from whom the server will accept messages.

Moving to the "Relay" pane, you'll find the first option already checked by default. Apple configures the OS X mail server to only allow relaying (the resending of messages from an external source) from machines on your local subnet. Unless you're confident your network is locked down tight, you'll want to consider removing those listings, instead adding only other mail servers within your domain, or even just the machine's own IP for troubleshooting purposes. Be aware that at this point, only the addresses you've just added will be able to send email through this server. We'll add the ability for client machines to send mail when we set up authentication methods later on.

At the bottom of the pane, you'll find a field to use what Apple calls "junk mail rejection servers". Also known as DNS blacklists, these servers store the IP addresses of supposed or suspected spammers. While blocking the addresses on these lists can significantly reduce the amount of junk mail a server receives, this method (like any filtering scheme) runs the risk of creating false positives and denying legitimate mail.

The "Filters" pane addresses the spam issue by content rather than by origin, allowing the server to check for common spam characteristics. Checking "Scan email for junk mail" enables this feature, while the "Minimum junk mail score" determines how many matching patterns flag a message as spam. Unless you're deleting suspected spam without warning, a lower, more aggressive score will probably yield results users prefer.

The big question, once you've marked mail as "junk", is what to do with it. Of the four options, the most polite (or lenient) is to deliver the mail, usually with some warning in the subject line. This option also puts a junk warning in the message headers that most email clients can interpret. For users with little spam, this may be a sufficient step, but in many environments you're better off bouncing suspected messages and letting legitimate senders contact the intended recipient when they've been filtered. If you do choose this option, it's best to have a clear mail-handling policy in place that's shared with users prior to implementation. You'll also want to avoid configuring a "Send notification to" address, which will fill up with thousands (if not hundreds of thousands) of messages every day.

Also in the "Filters" pane are anti-virus options. While viruses haven't been an issue on OS X, certain scripts can still effect the Microsoft Office products or be manually forwarded back to Windows users. There's no compelling reason not to "Scan email for viruses", which can simply be bounced back to the sender and the recipient notified.

Next Week: In part two, we'll look at configuring quotas, determining authorization methods, and enabling user accounts for corporate mail.

Recommended Reading: Back in 1993, Terry Gray at the University of Washington compared IMAP vs. POP. Surprisingly little has changed since then. In 2006, Wikipedia posted it's first comparison of DNS blacklists, which has been kept current ever since. For more information on the spam and virus protection built in to OS X Server, check the SpamAssassin and ClamAV websites.

Secure Instant Messaging

In many business environments, instant messaging has replaced email (and even the telephone) as the tool of choice for brief and casual contact. While easy, real-time chat has been embraced by most users, it still poses a number of challenges for network administrators. Most message services use no encryption by default, run your private conversations through their own servers, and offer no means to retain a permanent record of what could be important business communications. Running your own iChat Server can solve those problems.

In Server Admin, select your server from the left column, then click "Settings" from the toolbar. In the "Services" pane, check "iChat", and save your changes at the bottom of the window. Now choose the iChat service on the left, then hit "Settings" once again and begin with the "General" configuration pane. The current hostname of your server will already be listed under "Host Domains". If you'd prefer to use a service-specific name, such as ichat.makemacwork.com, you'll need that set up in your DNS listings.

Next, select the SSL certificate you'd like to encrypt message traffic with. You can use the unsigned "Default" certificate that's created by OS X Server, but many Jabber clients (including Apple's own iChat) will complain that they can't verify the server's identity. If your company doesn't already act as it's own certificate authority, it's easiest to use a third-party vendor such as Digicert, Thawte, or Go Daddy.

For "Authentication", Kerberos is the most secure option, but becomes unwieldy for users outside of your domain. The "Any Method" option will use Kerberos when possible, and otherwise default to a username and password. If you're required by law or policy to archive chat transcripts, move to the "Logging" pane, and check "Automatically save chat messages". When you're finished, click "Save".

Now everyone with a user account on your server can log in using any "Jabber-compatible" client. This includes iChat and Adium for Macintosh, as well as Trillian and Pidgin for Windows, among others. If you're planning to offer instant messaging from outside your office (for traveling employees, clients, or vendors) you'll also need to forward ports 5060, 5190, 5222, and 5223 through your firewall for this configuration.

Finally, there's one feature in Leopard's "Standard" server setup that somehow missed inclusion in the more flexible and configurable "Advanced" option. To automatically add every iChat user to every other user's Buddy List, you'll currently need to run the following on the command line after each user logs in initially:

sudo /usr/bin/jabber_autobuddy -m

Keep in mind that "Auto-Buddy" is a neat idea for small workgroups, but can quickly become unwieldy as your user base grows. If the feature appeals to you, it makes the most sense to automate the process by adding a launchd script that runs the command on a scheduled basis.

With these steps in place, anyone involved with your organization can send and receive secure instant messages through your OS X Server.

Recommended Reading: To learn more about the Jabber protocol (on which iChat Server is based), check out the information at Jabber.org.