|
|
There are a number of good documents on the web (see the links on the right) that describe how to set up sendmail and other mail transfer agents on Linux machines. The problem is, most of them couch their level of description a little bit higher than a novice (such as I) finds useful, as they don't relate the logical actions of the MTAs to what actually happens on the machine at the file and directory level. These notes are an attempt to plug that gap.
These notes are based on my knowledge of sendmail and fetchmail. Other MTAs might do things slightly differently, but I think that almost all of them follow the same conventions as sendmail.
Preamble and Definitions
First, a few definitions. There are three types of program that manipulate email: Mail User Agents (MUAs), which are used by people to read and compose emails; Mail Transfer Agents (MTAs), which move the emails from user to user and machine to machine; and Mail Delivery Agents (MDAs, also known as Local Delivery Agents, LDAs) which process mail just before it arrives at a user (for instance, doing spam filtering). Examples of MUAs are KMail, Evolution, Firebird, Outlook, and the Unix command-line mail. Examples of MTAs are sendmail, qmail, and fetchmail. There is generally only one MDA used, and that's procmail. End users never interact directly with MTAs, but get their MUAs to do it for them. End users might set up some options for their MDA, but after that the MTA handles calling the MDA.
There are also two types of mail servers around, each with their own communication protocol. Simple Mail Transfer Protocol (SMTP) is for sending email from one machine to another, and the machines on the receiving end of these transfers are called SMTP servers. Post Office Protocol version 3 (POP3) is used to talk to the machines (POP servers) that hold on to email until it can be transferred to the next machine that needs it. (There are other protocols used, such as IMAP, but their differences are irrelevant for this discussion.) (As a point of information, you should realise that email is not sent direct from your machine to the recipient's machine, but is passed in a series of hops from email server to email server, as and when, until it eventually arrives at its destination.)
Most MUAs are able of communicating directly with your ISP's SMTP and POP servers, so many people get along just fine without using any MTAs on their own machine. But having an MTA has the advantage of convenience, particularly with a dialup connection: the MTA can queue messages sent from the MUA, so you haven't got to be online when you press the 'send' button in your mail client. You can also set up your machine to automatically dial up your POP server in the middle of the night and collect your email, so it's waiting for you in the morning. Also, you can use an MDA such as procmail to filter email, such as detecting viruses and spam. Note, however, that MDAs are only invoked on messages being delivered to a local user.
Important Places
 How email manipulation is plumbed together |
There are five important places to know about when it comes to the use of an MTA. The sending and receiving of email boils down to moving email messages (or rather, the files that contain the messages) between these places. It is the MTA that does the moving. The figure shows these places and how they are connected.
Two of the places are owned by your ISP: the SMTP server, where all your outgoing email needs to end up; and the POP3 server, which holds your emails until you connect and collect them.
Another place is where your MUA stores the emails it knows about. This is generally somewhere like /home/username/Mail/ (for KMail) or /home/username/evoution/ (for Evolution). There is one of these directories for each MUA used by each user. Your MUA needs its own place for these messages so that it can keep track of the mail folders you define and the messages within them.
The final two important places are owned by sendmail, and they are the message spool directories. /var/spool/mqueue/ holds all messages that are awaiting delivery. The /var/spool/mail/ directory holds the emails that have been delivered by the MTA to local users, but which haven't yet been collected by the user's MUA. They are held in mbox files, one per user. Your MUA will recheck this spool file when it does it's normal 'Check for new mail' polling. (The command line mail MUA reads these files directly.)
A note on files
Emails reside in files. MUAs generally use either mbox format (one big file containing lots of messages, internally separated) for maildir format (a directory containing one file per email message). If you have sorted your email into folders, there will generally be one mbox or maildir for each folder. In both cases, there are generally additional index files, in the same places as the mbox or maildir, used by the MUA to quickly locate the messages.
Messages in /var/spool/mqueue/ exist as pairs of files with names like dfiABKKSDM010615 and qfiABKKSDM010615. The 'd' file contains the message and the 'q' file contains the mail headers. If you want to delete a message from the spool, delete both of these files (you'll need to be root to do it).
How it Works
Now we've got the structure, we can see how it works in practice. This is easier with an example. Let's say you've written an email in KMail, your MUA, and press 'send.' At this point your MUA give the message to sendmail and considers the email sent. Sendmail looks at the destination of the email; what it does next depends on where it's heading for.
| If the message is for another user on the local machine: | If the message is for a user on a machine elsewhere on the internet: |
|
|
That's great for sending mail, but how do you fetch mail from your ISP's POP server? That's where fetchmail comes in. Fetchmail is a single-minded beast. It does one thing, and one thing alone: it takes mail from a POP server, readdresses it to a local user, and places it in the /var/spool/mqueue/ directory. (It needs to readdress the messages to handle the situation that people may have one username with their ISP but use a different login name on their local machine.)
This means that now, when sendmail examines the contents of /var/spool/mqueue/, some messages will be for delivery to the internet and others will be for delivery to local users. In the latter case, sendmail proceeds in exactly the same way as described in the left column above.
What we haven't talked about is procmail. Procmail is used to pre-process email before it reaches the MUA. Generally, it is used to put email messages in places other than the /var/spool/mail/username mboxes. It is often used to implement an individual's own spam filter, by placing spam messages in another mbox (or deleting them altogether). It can also be used to automatically forward notification of emails to other people, such as setting up an auto-responder. But, essentially, procmail doesn't alter the processing of email so you can ignore it unless you really have to get involved with it.
And that's it. It isn't really that complicated, once you understand how all plumbing works.
For a worked example of setting it all up, see the MTA setup and procmail setup sections in my Fedora Core 2 setup notes.
More advanced and detailed information can be found at: