Hands on: Mac OS X Server Mail Service Boot Camp, Part 1: The Basics

zyc8211

　　Mac OS X Server includes a robust suite of mail services that make it a powerful solution for organizations looking to host their own email, webmail, and mailing list server. However, understanding how to configure those services properly is crucial to creating a reliable and secure mail server. In the first of three articles covering Mac OS X Server's mail services, Ryan Faas gives you the background and the basics you need to know to implement a Mac OS X mail server.
　　How to configure the Mac OS X Server mail services is a topic that is not often discussed when talking about server management. In fact, mail services have been removed from the Apple Mac OS X Server Essentials course curriculum and exam. This series discusses the basics of how to configure Mac OS X Server as an email server. It focuses on configuration basics using Server Admin and some of the advanced configuration that can be done from the command line.
　　Mail services under Mac OS X Server have actually gone through an interesting series of changes over the past few years. The original mail service was developed by Apple based on the email server included with AppleShare IP (Apple’s classic Mac OS server platform). However, in Mac OS X Server 10.3, Apple dropped this earlier email platform in favor of a series of open source Unix mail daemons. Apple has integrated these tools into the Server Admin graphical interface and has also included some interaction between these tools and Open Directory to allow you to manage email accounts as part of general Mac OS X user account management. They can also be managed from the command line as they would be under any other Unix or Linux operating system.
Mail Protocols and Service Overview
　　Properly configuring a mail server requires a basic understanding of how email as a whole functions. Sending and receiving email through the Internet requires not only a server but also the proper DNS configuration. Regardless of whether you are using private IP addressing and/or NAT to manage Internet connectivity for your organization, your mail server must have an IP address that is accessible to the Internet at large. You can connect it to a DMZ or other external port on your firewall or router, or you can configure a port forwarding rule that forwards any communication from the Internet over the standard mail protocol TCP ports (25, 110, and 143) to your public IP address to the internal address of the server.
　　The DNS records for your domain name also need to include an address and mail exchanger (MX) record for your server. The address record includes the server’s fully qualified domain name (that is, mail.mydomain.com) and its public IP address so that other mail servers (and email clients) can reach it. The mail exchanger record tells other mail servers which server handles email for the domain. A mail exchange record can actually specify multiple mail servers if you have a large organization and want to implement a backup mail server along with a value to identify the order in which each server should be used in the event that the first server cannot be contacted. Some ISPs will offer to allow you to use their mail servers as a backup server temporarily. Configuration of the DNS records for a domain should be accomplished with your ISP or domain name registrar.
　　The SMTP protocol manages the process of send email. Under Mac OS X Server, SMTP service is handled by the Postfix daemon. When an email is sent by an email application, it gets transmitted to the mail server by SMTP over port 25. The SMTP server (Postfix in this case) examines the recipient headers of the email. If need be, it queries a DNS server to determine the appropriate destination server and that server’s IP address. It then establishes a connection to that server and transmits the messages (again using the SMTP protocol). The message is then routed to the appropriate mail storage location, where it waits for the recipient to receive it.
　　Receipt of email is managed by one of two other email protocols: POP and IMAP. POP is the older and simpler of the two. Email clients connect to a mail server using POP over TCP port 110, supply user credentials, and then transfer the message to the computer on which they are being run. Typically, the message is then deleted from the server. POP servers deal only with the download of received messages and do not keep track of whether the message has been read (a job left to the email clients).
　　IMAP manages email in a more hands-on approach. When an email client connects and authenticates to an IMAP server, mail can be read, but it remains stored on the server. The server also identifies messages that have been read. This enables email clients on multiple computers (as well as web-based email clients) to be able to access the same mailbox and see the same series of messages and note which ones have been read. IMAP also supports caching a copy of received messages on email clients for faster and offline access. IMAP supports a wider range of authentication methods, making it a more secure protocol. However, the storage of all messages on the server also means that IMAP servers require more resources than POP servers.
　　Virtually all email clients today support both POP and IMAP. Both protocols are also managed by the same mail server component, Cyrus, under Mac OS X Server. You can choose to encourage users to use one of the two protocols in your organization and you can even choose which of the two will be available on your mail server.
　　
Mac OS X Server includes a robust suite of mail services that make it a powerful solution for organizations looking to host their own email, webmail, and mailing list server. However, understanding how to configure those services properly is crucial to creating a reliable and secure mail server. In the first of three articles covering Mac OS X Server's mail services, Ryan Faas gives you the background and the basics you need to know to implement a Mac OS X mail server.Basic Mail Server Configuration with Server Admin
　　Although mail services under Mac OS X Server are a collection of Unix tools traditionally managed from the command line, Apple has made the initial setup and basic management functions conveniently accessible as part of Server Admin and Workgroup Manager. The Server Admin Mail pane makes configuring the majority of email functions very simple and creates a one-stop place to configure Postfix, Cyrus, and Mailman (the Unix service that manages mailing lists under Mac OS X Server). For new administrators, using Server Admin to set up and manage mail services can ease not only the process but also the learning curve. Even for experienced administrators, it can provide a more efficient tool for viewing and changing basic configuration options.
　　To get started, launch Server Admin and authenticate to the appropriate server (provided that you run Server Admin remotely instead of on the server itself). Select Mail in the Computers And Services list. As with most Server Admin panes, the Mail pane contains five panes, including Overview, Logs, Connections, Maintenance, and Settings.
　　Overview, which is initially displayed, gives you a snapshot of your mail server (including whether or not mail services are running, which mail transfer agents are running (outgoing SMTP, incoming SMTP, POP, and IMAP), how many users are currently connected to the server using IMAP, and the status and number of mailing lists being hosted by the server.
　　Logs provide an easy way to view the various mail server logs. You can view the logs for each of the component mail transfer agents as well as a series of logs for specific mailing list–related events and logs for virus scanning and junk mail filtering. The Connections pane displays the current IMAP and POP connections to the server. Maintenance, which we’ll discuss more in part 3 of this series, enables you to view the status of current email accounts, message queues, mail store databases, and to configure email migration from mail services under Mac OS X Server 10.2 and earlier.
　　The Settings pane, as you might guess, is the place in which you manage most of the mail server configuration. It contains seven tabs: General, Relay, Filters, Quotas, Mailing Lists, Logging, and Advanced. The first of these, General, contains the major functions needed to set up mail services.
　　As shown in Figure 1, the General tab contains a number of checkboxes that manage the mail services configuration. The first two checkboxes are to enable POP and IMAP access. When IMAP is enabled, you can specify a maximum number of connections. You might take advantage by limiting the number of connections to only the number of email accounts that you actually create or the number of computers in your organization. There is also an option to deliver all incoming email to the /var/mail folder in the event that POP and IMAP are both disabled.
　　Figure 1 Mail service general settings


　　　　The next option is to enable and configure SMTP. You have the option of enabling SMTP as a whole and the option of allowing or disallowing incoming mail. The capability to disallow incoming mail can be useful if you find your server is the target of a large amount of spam or a mail-based network attack. By disallowing incoming mail, your users will still be able to exchange internal email and send email outside of your organization while you work to deal with the problem.
　　Next are the fields in which you can enter both the Internet domain name and the host name of the mail server. These should match the domain and mail exchanger configured for your DNS records. If you are using an internal DNS configuration that is strictly internal to your network as well as external DNS managed by your ISP, use the domain name and hostname registered with your ISP because this is how other mail servers will communicate with your mail server.
　　The next option, Hold Outgoing Mail, enables the server to accept messages from email clients but not attempt to send them. This can be a useful feature if your Internet connection goes down because it enables your users to write and send email without error messages during the outage. After the problem is resolved, you can unselect this checkbox, and the server will attempt to deliver and hold mail.
　　Relay Outgoing Mail Through Host is the next option. This option enables you to route outgoing emails through another mail server instead of attempting to send email directly. In larger organizations with multiple email servers, this option can be used to have a single server that connects to the Internet, which is often placed on a demilitarized zone (DMZ) port on a firewall to provide increased security. It is also used in small organizations to allow your ISP to manage the actual transfer of email beyond your network. If selected, the appropriate server address in the associated field.
　　The last two options enable you to designate that copies of emails be sent to a separate email address from the recipient of the message. The first checkbox specifies this for mail that is undeliverable. This is good if someone leaves your organization but outside contacts (vendors, customers, and so on) still send email to that address because it provides an option for responding to them with a correct email address or forwarding the message to the appropriate person. It can also act as a catchall for emails incorrectly addressed to your organization.
　　The final option copies all emails to a specified address. This option can be controversial because it means that any email your users send is recorded without their knowledge. Although there are any number of reasons why a business or school might choose to use this option (to monitor the use of the organization’s email server or as a result of suspicion of confidential information being released for two examples), there is a privacy issue. If you opt to use this option (or are asked to use it), it is best to include a computer use policy that says all emails may be monitored. Also, consider that this could potentially affect the storage of your mail server as large numbers of emails are copied to the specified address. In fact, the sheer number of messages could make it difficult to sort through for signs of inappropriate activity.
　　The next tab on the Settings pane is Relay (shown in Figure 2). It contains three listboxes, each of which has a checkbox to enable or disable its contents. The first and most important is Accept SMTP Relays Only From These Hosts And Networks. SMTP relay (sometimes referred to as outgoing SMTP) is the method by which SMTP clients transfer emails to a server, which then connects to other SMTP servers to deliver those messages. Relaying is therefore important, but if you simply allow relaying from any computer (known as open relay), any email client on the Internet could send mail through your server. Most spam operators work by finding open relays on the Internet and send spam by using them. This can lead to overloading and blacklisting of your server.
　　Figure 2 Mail service relay settings


　　　　This option enables you to specify that only relays from computers with certain IP addresses will be accepted by your server. You can either enter individual IP addresses or use cider notation to specify networks or subnets. Users from other network locations will either not be able to send email through your server or will need to authenticate in order to send email. (We’ll cover how to configure such authentication in part 3 of this series.) By default, this option is selected and includes the loopback address for the server (which should always be included) and any IP address within the same network as the server’s IP address. You should specify subnets more granularly than this. To add, remove, or edit the entries in the listbox, use the plus, minus, and pen icon buttons next to it.
　　The second listbox, Refuse All Messages From These Hosts And Networks, is used to specify the IP addresses of individual mail servers or whole networks known to perpetrate mail-based network attacks or spam. Again, you should specify networks using cider notation. Because you might not know in advance the addresses of server generating spam or network attacks, you will typically have to wait until such events present themselves to input the appropriate address into this listbox.
　　The third listbox, Use These Junk Mail Rejection Servers (Real-Time Blacklist), offers you the ability to subscribe to one or more blacklist servers. Blacklist servers contain records of networks that are either known to be used for sending spam, are open relays, or are identified as being at risk of use for spam or network attacks by some set of criteria (which can vary depending on the servers being used). Blacklists can be helpful for providing a preemptive approach to avoiding spam or attacks. However, there are times when servers will be inadvertently added to a blacklist when they are not being used maliciously or are not open relays. In these cases, using a blacklist can prevent legitimate emails from not being delivered to your network. Also, it can be difficult to get a server removed from a blacklist after it has been added. This is a good reason to ensure that your server is not an open relay and that it is not used for malicious purposes by your users. To use a blacklist server, enter the appropriate address of the server in this box.


　　NOTE
　　I recommend that you research blacklist servers before using them.
　　　　The Filters tab enables you to configure automatic scan options for junk mail and viruses. There are also additional tools that can be added to your server from the command line. (Filters will be discussed in the third article of this series.)
　　The Quotas tab (shown in Figure 3) enables you to configure the way the server responds to mailbox quotas for your users (quotas themselves are configured for users when creating their accounts in Workgroup Manager). It also enables you to designate a maximum size for incoming messages. This can be very helpful because extremely large messages can reduce overall performance of your Internet connection as well as affect the transfer of other email. To set a maximum message size, check the Refuse Incoming Messages Larger Than X Megabytes and enter a size in the appropriate field.
　　Figure 3 Mail service quota settings


　　　　The other two options deal with what happens when users reach quotas and when warning messages should be sent. The first option is a checkbox to disable incoming mail for use when they reach their quota (along with an associated message that will be delivered to their mailbox). The second option is to enable warnings before the quota is reached. With this option selected, you can enter the text of the warning message as well as at what percentage of the quota the warning should be received (the default is 90%). You can also designate how often (in days) a warning message should be delivered (the default is one per day).
　　How you use quota is up to you. Needless to say, for the sake of storage space and other resources, you should encourage users not to let their mailboxes get out of hand. However, many people today rely on saved email; if you are using IMAP, those saved emails need to reside on the server. If you opt to turn off email access after a quota is reached, you should most definitely use warnings. I would set them to be sent at around 75% of the quota so that users have some time to either clean out their mailboxes or request an increase in their quota some time before email access is disabled.
　　The Mailing Lists tab (shown in Figure 4) enables you to create mailing lists. Like the other mail services in Mac OS X Server, mailing lists are handled by a Unix tool called Mailman. However, the mailing list functions are significantly less integrated with Open Directory compared with the other mail components. Although the Mailing List tab includes a button to display the users and groups available to the server through Open Directory, it is merely a reference for easily including mail-enabled user accounts. As a result, when you create mailing lists you must specify mailing list permissions explicitly for the Mailman when adding users to the list. You must also specify an administration password for all mailing list management. Also, unlike mail services in Mac OS X 10.2 and earlier, AppleShare IP, or Microsoft Exchange, you cannot directly specify groups as being used for email distribution.
　　Figure 4 Mailing Lists Settings Tab


　　　　The first step in working with mailing lists is to enable Mailman. The simplest way to do this is by checking the Enable Mailing Lists checkbox on the Mailing Lists tab. The first time you enable mailing lists, you will be asked to specify a mailing list master password and one or more email addresses for users who will act as mailing list administrators. These users will be made members of a Mailman mailing list and will receive an email containing the administration password.
　　You can create additional mailing lists by clicking the plus sign below the Lists listbox (you can also use the minus sign button and the pencil button to delete or modify a selected list). When you create a new list or edit an existing list, you see a dialog sheet that includes fields for the listname and admin user. The name of the list will be used as the first half of the list’s email address (the second half after the @ symbol will be whatever domain name is assigned to the server). The dialog sheet also includes an option to allow users to self-subscribe to the list (if you don’t select this option, you will need to manage the list membership manually); a pop-up menu to select the default language for the list, and a series of checkboxes to identify which languages or character sets will be supported for emails sent to the list; and you can also choose to enter a maximum size for messages in kilobytes.
　　You can subscribe users to a list in two methods of user Server Admin. The first is to press the Users & Groups button to display a drawer containing the available user accounts from Open Directory. You can then drag one or more users into the Members listbox while the appropriate mailing list is selected in the Lists listbox. The downside to this approach is that each user will automatically receive the same mailing list permissions (subscribe and post). If you want to alter them, you will need to deselect the appropriate checkboxes next to each address. Remember that when you do this, all that is really happening is the email address specified in the user’s account is being copied to Mailman.
　　The second method is to click the add (plus sign) button underneath the Members listbox while the appropriate list is selected. This brings up a dialog sheet in which you can enter a complete email address or user account identifiers (which basically means user shortname from Open Directory), or you can drag users from the Users and Groups drawer if it is displayed. You can also select which mailing list permissions to apply to all the users you specify.


NOTE
　　Mailman includes additional features that can be managed by a web-based interface, if available. These features include mailing list administration, the ability for 　　users to self-subscribe to lists, and archiving options. These will be discussed in more detail in part 2 of this series).
　　　　The Logging tab enables you to configure which mail-related events are recorded into the various mail server logs and to set archiving options for the logs—pretty much as you would do with any other services using Server Admin. You can set the logging details independently for SMTP, IMAP/POP, and Junk Mail/Virus scanning. The available options for each include Critical, Error, Warning, Notice, Information, and Debug (Critical is the least informative—only logs serious—whereas Debug includes information about any server event). The exact events logged at each level vary slightly for each of the three options, and selecting each level will show the details of what is logged.
　　The Advanced tab, which will be discussed in greater detail in part 3 of this series, contains three tabs: Security, Hosting, and Database. The Security tab enables you to define which encryption techniques are allowed to be used by email clients when transmitting usernames and passwords when sending or receiving email. This is also where you can determine whether or not the server will use SSL to ensure that emails are securely transmitted between the server and email clients and the security certificates used for SSL. The Hosting tab enables you to configure virtual hosting and local host aliases for the server. The Database tab enables you to change the location(s) where mail is stored as well as the location of the mail server database.
　　
Mac OS X Server includes a robust suite of mail services that make it a powerful solution for organizations looking to host their own email, webmail, and mailing list server. However, understanding how to configure those services properly is crucial to creating a reliable and secure mail server. In the first of three articles covering Mac OS X Server's mail services, Ryan Faas gives you the background and the basics you need to know to implement a Mac OS X mail server.Enabling Email Accounts in Workgroup Manager
　　Although the mail services can be configured using Server Admin, configuring individual accounts is done using WorkGroup Manager. To configure mail options for a user, launch WorkGroup Manager, authenticate to the appropriate Open Directory domain, and select a user account in the accounts list. In the right pane, select the Mail tab. There are three mail options available: None, Enabled, and Forward. None means just what it says: the account is not mail-enabled. Selecting Forward enables you to enter an email address that is not hosted by your server. Any email sent to the user’s account on your mail server will instead be forwarded to the address you enter. Enabled creates an email account for the user and enables you to configure it.
　　Once you’ve mail-enabled a user, you will see the fields displayed in Figure 5. The first field enables you to identify the server that will be hosting the user’s account (that is, the mail server you configured earlier). You can enter the server using its IP address or fully qualified domain name. The next option is the user’s mailbox quota in megabytes. The third option shows whether the user will be able to access their email using POP, IMAP, or both. The final option is to use an alternate location or partition to store email. This last option requires that you have configured the mail server to use alternate storage locations using the Database portion of the Advanced Settings tab in Server Admin (again we’ll cover this in more detail in part 3 of the series. After you’ve entered the appropriate information and saved the user’s account, they should be able to send a receive email using the account.
　　Figure 5 Mail options for a user in WorkGroup Manager

　　　　You can mail-enable users in both shared and standalone Open Directory domains. You can also create mail-enabled accounts with the Access Account option deselected on the Basic tab in WorkGroup Manager. This will create an account that can be used solely for email purposes. Also, be aware that mail-enabling an account does not populate a user’s email address on the Info tab in WorkGroup Manager. Finally, you may notice that a user’s email account is not listed in the Mail service’s Maintenance pane in Server Admin after you create an email account in WorkGroup Manager. This is because a user’s email account isn’t actually created until either they receive an email or they check their email for the first time.
　　
Mac OS X Server includes a robust suite of mail services that make it a powerful solution for organizations looking to host their own email, webmail, and mailing list server. However, understanding how to configure those services properly is crucial to creating a reliable and secure mail server. In the first of three articles covering Mac OS X Server's mail services, Ryan Faas gives you the background and the basics you need to know to implement a Mac OS X mail server.What’s Next?
　　Part 2 of this series will look at how to enable and configure a web-based interface for users to be able to check their email as well as how to work with the advanced options for mailing lists using Mailman’s web interface. In part 3, we’ll discuss the various advanced options and mail-filtering functions available to mail services under Mac OS X Server, along with some of the details about extending mail configurations beyond what can be easily performed using Server Admin and tips to ensure the security of your email server.