Linux can make a great replacement for many Windows services, including e-mail. Here's how to configure your Linux server to act as an e-mail server.
Linux has been making more and more inroads into corporate networks, replacing Windows servers for common tasks that include acting as e-mail servers. Running a mail server can be really complicated or, thanks to Linux, really simple. It takes a few minutes to configure an Internet connection and bang! You've got a new e-mail server without the hassle and expense of running Exchange. But the question, especially for Windows administrators, is how to make Linux act as an e-mail server. Here's how it works.
For simplicity, this article will assume that all e-mail users are local to the mail server. If e-mail users are not local, everything in this article will still apply, but another level of software will be required. Remote users are those who use e-mail programs such as Mozilla Thunderbird and Eudora. This article is based on SuSE Linux 9.0, but should apply to just about any flavor of Linux.
How does e-mail work?
In order to effectively configure a new mail system, it's important to understand how e-mail is sent and received. The first concept to understand is the structure of an e-mail. An e-mail contains two parts: the mail headers and the mail body. The mail headers contain the sender and receiver addresses, a unique identifier, the date sent, the subject, and other data used by the system.
The second concept to understand is the underlying structure that moves an e-mail from the sender to the receiver. There are several components in that structure:
- MUA (mail user agent)—The MUA is the component of the mail system that most users think of as the e-mail program. It's responsible for providing the interface used to enter the two parts of an e-mail. An MUA often provides user features such as an address book and a spelling checker. The MUA is also responsible for handing the message off to the MTA.
- MTA (mail transfer agent)—The MTA is the component of the mail system that most users never see. It takes the message provided by the MUA, decodes the header information to determine where the message is going, and delivers the message to the MTA on the receiving machine. The MTA on the receiving machine adds data to the header of the received e-mail message.
- LDA (local delivery agent)—The LDA is the component of the mail system that takes a received message from the MTA and appends the message to the receiving user’s incoming mailbox.
Figure A displays an example e-mail sequence showing the order in which these components are used in a normal mail transaction.
|A sample e-mail sequence|
In order for the MTAs on various machines to pass e-mail traffic, they must know where to find each other and how to communicate. The MTA decodes the receiving address and uses the portion to the right of the @ sign to find the proper machine. Internet services such as DNS are used to determine how to route to the decoded address. (I won't explain the use or setup of DNS or other network facilities; I'll assume the configuration is completed and working.)
Once the route has been determined, an MTA needs to know how to communicate to another MTA. This is accomplished using SMTP, a standards-based method that mail servers use for communication. All mail servers understand and respond to the limited set of commands that are defined in the standard.
When two MTAs communicate, they use a service port. Service ports are reserved ports on each machine where applications listen for commands. In the case of MTAs, port 25 is the standard port used. Service ports are generally reserved in the /etc/services file. When you use the grep command to find the ports used, you'll see something like this:
# grep smtp
smtp 25/tcp mail
# Simple Mail Transfer
smtp 25/udp mail
# Simple Mail Transfer
Sendmail, the most common MTA, is one of the oldest, most used components ever developed. It's also one of the most cryptic and difficult to compile and configure. There are binary versions available for download from the Web, but the configuration has to be managed on each machine individually. Sendmail provides several options for almost any situation for any mail server, but again, it's very cryptic. Another downfall of sendmail is there are many security holes that need to be addressed. Because sendmail is so flexible, during configuration, it's easy to leave out something needed for security.
SuSE Linux provides a simpler MTA known as postfix. Postfix is installed by default with the operating system and is likely already running on the SuSE machine. To verify that postfix is running, use ps and grep:
# ps -ef | grep post
1 0 Jul20 ? 00:00:07 /usr/lib/postfix/master
1078 0 Jul20 ? 00:00:02 qmgr -l -t fifo -u
1078 0 02:38 ? 00:00:00 pickup -l -t fifo –u
The first portion represents the main daemon, which is listening on port 25 for SMTP requests; the last portion represents the helper applications such as the LDA.
Configuring the mail server
On SuSE, the configuration for postfix and for most of the system is done using YAST (Yet Another Setup Tool). To configure postfix, you must be logged in as root. YAST has both a character and graphical mode. Logging in to the console of the SuSE machine will allow the use of the GUI.
For the purposes of this article, the following assumptions apply:
- You have a full-time Internet connection.
- This machine is the outgoing mail server.
- This machine is the incoming mail server.
- Only users of this machine will be using it for e-mail services.
From the initial YAST screen, choose Network Services. From the list of Network Services, choose Mail Transfer Agent. It will take a minute or two for YAST to read all the necessary information about the installed mail server and to determine the installation options available.
The first three options on the Connection Type screen—Permanent, Dial-up, and No Connection—are mutually exclusive, so choose the appropriate one for the installation. A Permanent connection is where the mail server is always connected to the Internet; a Dial-up connection requires a step to connect to the Internet; and No Connection means no connection to the Internet, so only local mail can be sent and delivered.
The last option on the Connection Type screen, Enable Virus Scanning (AmaViS), is an add-on feature that allows both inbound and outbound mail to be checked for viruses. For this example, choose Permanent, leave the virus option disabled, and then press Next.
The next screen, Outgoing Mail, allows you to enter the outbound mail server, but since this article assumes the local machine is the outgoing mail server, you don’t need to enter anything here. The Masquerading option allows mail to always appear to come from a central machine, instead of from the local machine. This is useful in situations such as a company that would like all e-mail to appear as:
Without masquerading, e-mail would appear as:
Many users prefer standardized e-mail addresses, which allow you to use central virus checking and provide a way to have only one machine accessible via the Internet for mail.
The Domains For Locally Delivered Mail option lets you specify what mail will be delivered on this machine. List as many machine names or aliases as are available. For example, the machine may be known as Eastnj officially, but might have aliases such as Turnpike and Somerset. Adding all three will allow mail to be delivered to users at all of those addresses.
By using Masquerade Other Domains, you can have other domains send mail as if they belong to the master domain. This is useful in a situation such as corporate acquisitions, when you want to allow mail to arrive at the old company name, while translating any outgoing mail to the new company name.
The last option in the dialog box provides the ability to directly translate a user address to a standard address. For example, if the company standard is to use an e-mail address such as firstname.lastname@example.org, and the user name is firstname, it would be possible to add a translation from email@example.com, so all of that user's e-mail is addressed properly.
For this article, we won't worry about masquerading. Choose OK to return to the Outgoing Mail screen. The Authentication option relates to the outgoing mail server and is not useful for this example.
Pressing Next brings up the Incoming Mail screen, which shows the options for accepting incoming mail messages. Since we're assuming this machine is the incoming mail server, check Accept Remote SMTP Connections to enable incoming mail.
When you click Finish, a dialog box will be presented for writing the configuration. Choose Continue. YAST will write the configuration to the system and restart the postfix daemon. Choose Quit to leave YAST. The mail system is now configured. It can be tested using the mailx utility from the command line or the KMail utility from the GUI.