create new tag
, view all tags
The sketches on this page show various configurations of an email server in Linux and other useful information about how email is handled on the Internet.

This is one of several pages on WikiLearn that tries to explain email. Some of the others are listed below. Eventually they may be combined, but for now they are not. It may be worthwhile looking at some of these pages for a possibly different perspective. In particular, where this page includes small sketches showing various parts of an email server, the EmailOverviewSketch shows a comprehensive sketch of email handling in a local email server. Also, it has (will have) notes to describe the email configuration I set up on my home LAN.

Looking at the sketches today (10 Oct 2006), I think that I probably have the blocks for Port 110 (and Port 143) in the wrong place--I show them on the sending computer, I'm pretty sure they should be on the receiving computer. (The blocks for Port 25 seem to be shown in the right location.) So if I ever modify these sketches, I should confirm and then fix these.)



Aside: Corrections Made to This Page

This page has lived through a few iterations. Although it is not my intent to call your attention to every revision, earlier versions of this page had some significant mistakes. The intent of this list is to call your attention to some of those so that any wrong impressions from previous versions of this page have a better chance of being recognized and corrected in your understanding of email.

  • Port for IMAP is now shown correctly as 143 instead of 220 (220 might be the port for an older version of IMAP?? i.e., I don't know where I got Port 220 from).
  • Sending of email from an IMAP client is now shown correctly as being via SMTP to port 25 instead of from the IMAP server. (I have not read the RFC for IMAP to know that what I described cannot be done, but I am not aware of any client that takes that approach.)
  • ifup is not a program to check if an interface is up, but instead a program to bring an interface up (InterFace UP)
  • <Rewrite these in a more active tense.>

Re: Incoming mail: David Emerson has created an updated sketch (a .gif from Windows Paintbrush and some comments on the incoming mail portions of the sketches. See #Incoming_Mail_Alternate_Sketches.


On a Windows workstation, the most common approach to handling email is to install an email client which interfaces with an ISP's email server.

On a Linux workstation, a very common approach (at least historically) is to install an email server which relays mail to and from an ISP's email server. (Linux can also use the email client approach, but my purpose here is to (1) give insight into why Linux sometimes takes the approach it does, and (2) focus on email servers rather than clients.)

Regardless of how mail gets to an ISP's email server, once there, email is relayed from machine to machine on the Internet until it reaches first the ISP serving the final recipient and then his workstation.

Beyond the different typical approaches of Linux and Windows, there are many ways to set up an email server in Linux. These sketches are intended to introduce some of the primary approaches so that you can pick an approach which fits your needs.

Handling email is complicated by the need to handle multiple addressees or carbon copies, the continued existence of older email systems, and other factors. The sketches on this page show the simpler situations -- the more complicated situations may be discussed on other WikiLearn pages as the need arises.

Note that the Windows approach (an email client connected to an ISP's email server) can be used in Linux, and is, IMHO, by far the easiest approach if it meets your needs.

I have some needs beyond the simplest approach -- see MyEmailServerNeeds.

The functions of an email server are usually not performed by a single program but by a combination of programs. The division of effort between these programs is somewhat standardized based on the roles of MTA, MDA, MUA, and MAA, and other considerations, but also varies somewhat depending on the capabilities of the programs selected to fulfill each role.

In addition to the MTA, MDA, MUA, and MAA two other programs, procmail and fetchmail, fulfill special roles for special situations in an email server.


See EmailServerTerminology for definitions of some terms related to email and email servers, like MUA, MTA, MDA, pop server, pop3 protocol, imap server, imap protocol, smtp protocol, etc.

Special Programs


Procmail can serve many functions and be set up in a variety of configurations. It is known as an MDA (Mail Delivery Agent) but can serve as an email filter for many tasks, including each individual's email.

When used to filter an individual's mail it should be shown as an additional block taking mail from the user's main incoming email directory and distributing it among the user's named mailboxes according to filtering rules that the user can set up.

So far, I have not shown procmail serving this function on these sketches.


See the sketches dealing with incoming mail and notice fetchmail. Fetchmail is important for systems that do not have a continuous connection to the Internet.

Cron jobs can be set up to fetch the mail at intervals, or scripts can use various means to check that an interface to the ISP is up and then fetch the mail. (An example: ping the ISP and check for success.)

Outgoing mail works better when it is tied to the same cron job so that mail is sent out when the interface to the ISP is up. (One reason is that if email is deferred, it goes into a queue with an "exponential backoff", meaning that each time the mail fails to be sent, it waits for a(n exponentially) longer period before another attempt is made to send it.)

<further work:> <discuss sendmail -q as an alternate way to kick the mail queue, discuss postfix's mechanism for retrying mail at doubling time intervals, discuss ?>

Incoming Mail Alternate Sketches

David Emerson provided these notes and the following modified sketch -- thanks, David! For now, I'm simply posting his comments and sketch here -- later I may try to integrate it better.

I found the email server config INCOMING mail diagrams a little confusing.

There are 3 different diagrams showing 3 different configs.

The first thing to notice is that, once the mail gets to /var/spool/mail/ , the three diagrams are topologically identical (though they have been drawn separately by hand, so they LOOK slightly different) so it took me a moment to figure out that there were no differences there, that part of the diagrams is irrelevant for what is being explained (and thus maybe it should be cut and put in another diagram that just shows /var/spool/mail/ -> destinations)

With all of that horizontal space cut out, the three examples could actually fit side by side each other, as seen in the attachment ... then they can all be explained together, with one common diagram that can be referred to, where the similarities and differences are obvious. (Excuse the sloppiness! I'm using windoze paintbrush and it sucks...)

Then from /var/spool/mail/ -> destinations can go in a separate diagram of its own.



Windows Style Email Client, POP3 / SMTP based

Note: Linux email clients including modern ones like kmail, sylpheed, Mozilla as well as some of the old standbys like Pine can be set up like this also.

Edit drawing `test4` (requires a Java 1.1 enabled browser)

Windows Style Email Client, IMAP based

Note: Linux email clients including modern ones like kmail, sylpheed, Mozilla as well as some of the old standbys like Pine can be set up like this also.

Edit drawing `test5` (requires a Java 1.1 enabled browser)

Email Relaying on the Internet

Once email has been transferred to your ISP, email is relayed from Internet email server to Internet email server until it reaches the ISP closest to the final destination. The following sketch shows only (the first) two relaying email servers.

Edit drawing `test6` (requires a Java 1.1 enabled browser)

Email Server Configurations

Email Server, Incoming Mail, Postfix as MTA, Procmail as MDA

This shows the incoming mail route only (and outgoing mail to users on the (local) LAN) -- see #Email_Server_Outgoing_Mail for outgoing mail to the Internet.

Edit drawing `test` (requires a Java 1.1 enabled browser)

Email Server, Incoming Mail, Postfix as MTA and MDA


This shows the incoming mail route only (and outgoing mail to users on the (local) LAN) -- see #Email_Server_Outgoing_Mail for outgoing mail to the Internet.

< most refactoring stopped here, making a first pass through the rest of the document>

Postfix as an MDA

Postfix should not be considered an MDA, although it has some MDA capability. Postfix can deliver mail to multiple mailboxes (by username, at least) and can filter mail based on regular expressions. (This filtering occurs between port 25 and the postfix "incoming" mail queue.)

Usually, Postfix's "local delivery agent" passes the email off to a separate MDA, for example, procmail, which does its magic. If there is no separate MDA, Postfix "delivers" the mail by writing it to the spool file.

The best source of documentation I've found for this kind of stuff about postfix is the html documentation that comes with postfix, including a block diagram called big_picture.html. I don't know if postfix can sort the mail to different mailboxes for a single user -- if not it is certainly less capable than procmail, and I probably want procmail for my purposes.

Aside: See FetchmailWithNetscape. Edit drawing `test2` (requires a Java 1.1 enabled browser)

No Email Server, Incoming Mail

With no local MTA, we need some way to fetch the mail from the remote MTA. fetchmail is perfect for this.

Interesting! In this case the outgoing mail route shown in the next sketch probably doesn't make much sense (it seems like overkill). The approach I can think of is using mail clients that are SMTP capable and each of them connecting to the ISP directly and sending outgoing mail by that route. But, then local mail distribution would not work, so maybe the MTA is not overkill. What's your thinking, Faber? -- RandyKramer - 20 Feb 2002

You need an MTA to deliver mail. Period. Whether you use a local or a remote one depends on your needs. I run a local one so I can rewrite my headers to "faber@linuxnj.com" since my web host doesn't supply me with a mail server, my ISP domain name is uselessto me, and my local domain is "faber.nom".

Before Windows became a popular client on the Internet, most (unix) clients had sendmail already installed. This way, each individual machine would transfer its mail to the recipient's MTA. It was only with the advent of Window's clients (which had no built in MTA) that ISPs starting needing to supply them. -- FaberFedor - 21 Feb 2002

Interesting "historical" perspective. I recognize that MTAs are required to deliver mail, but there is a significant difference between me needing an MTA on my local system, and me using the MTA supplied by my ISP.

I'll refactor this section a few days from now. -- RandyKramer - 25 Feb 2002

Edit drawing `test1a` (requires a Java 1.1 enabled browser)

Email Server, Outgoing Mail

  • This shows outgoing mail only, for incoming mail see one of the two previous sketches

Edit drawing `test3` (requires a Java 1.1 enabled browser)

Postfix Block Diagram

Update: For the time being, the big-picture.html sketch that comes with the Postfix documentation seems adequate for my needs (and saves me from creating another sketch). It comes in the html documentation that comes with and is installed with postfix. It is also available on the Internet (IIRC) but I can't fine a URL right now.

The intent will be to show postfix in more detail, including the various daemons and where they move mail from and to, and maybe the various databases that contain aliases, forwarding addresses, or whatever.


This page is reasonably accurate but I want to "normalize" the sketches (that is make things that are identical between sketches be the same size and in the same position so that your eye is called to the differences). Note that, for example, the representation of the ISP and the alternate paths for 24/7 and intermittent operation shown on figure 1 (the fourth sketch on the page wink ) should be shown similarly on figure 2 (the fifth sketch on the page) and maybe other places. The ISP on figure 1 should be shown with a connection to the Internet (perhaps the Internet cloud?).


  • RandyKramer - 16 Feb 2002
  • FaberFedor - 18 Feb 2002
  • <If you edit this page, add your name here, move this to the next line>

Page Ratings and Drawing Files (Attachments)

Topic attachments
I Attachment History Action Size Date Who Comment
GIFgif flow_in.gif r1 manage 15.7 K 2003-02-25 - 22:21 RandyKramer David Emerson mod sketches (.gif from Paintbrush)
Unknown file formatdraw test.draw r28 r27 r26 r25 r24 manage 15.0 K 2003-02-21 - 15:41 RandyKramer  
GIFgif test.gif r28 r27 r26 r25 r24 manage 11.5 K 2003-02-21 - 15:41 RandyKramer  
Unknown file formatdraw test1a.draw r5 r4 r3 r2 r1 manage 11.6 K 2002-09-02 - 17:18 RandyKramer  
GIFgif test1a.gif r5 r4 r3 r2 r1 manage 8.1 K 2002-09-02 - 17:18 RandyKramer  
Unknown file formatdraw test2.draw r14 r13 r12 r11 r10 manage 14.0 K 2002-09-02 - 17:16 RandyKramer  
GIFgif test2.gif r13 r12 r11 r10 r9 manage 10.4 K 2002-09-02 - 17:17 RandyKramer  
Unknown file formatdraw test3.draw r12 r11 r10 r9 r8 manage 6.7 K 2002-02-18 - 23:41 FaberFedor  
GIFgif test3.gif r11 r10 r9 r8 r7 manage 6.9 K 2002-02-18 - 23:41 FaberFedor  
Unknown file formatdraw test4.draw r10 r9 r8 r7 r6 manage 7.9 K 2006-10-09 - 09:07 BhuvanaAradhya TWiki Draw draw file
GIFgif test4.gif r9 r8 r7 r6 r5 manage 7.6 K 2006-10-09 - 09:07 BhuvanaAradhya TWiki Draw GIF file
Unknown file formatdraw test5.draw r9 r8 r7 r6 r5 manage 10.4 K 2002-09-02 - 15:09 RandyKramer  
GIFgif test5.gif r8 r7 r6 r5 r4 manage 12.4 K 2002-09-02 - 15:09 RandyKramer  
Unknown file formatdraw test6.draw r5 r4 r3 r2 r1 manage 10.8 K 2002-09-02 - 17:13 RandyKramer  
GIFgif test6.gif r4 r3 r2 r1 manage 12.4 K 2002-09-02 - 17:13 RandyKramer  
Edit | Attach | Watch | Print version | History: r48 < r47 < r46 < r45 < r44 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r48 - 2006-10-10 - RandyKramer
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look