Email Server
Internal Mail Setup
Linking with External Mail Accounts

Email Server

Hobbits are a merry lot and believed in sharing jokes, amusing anecdotes, etc. whenever they could. They mostly used emails for these, even though some (or all) of the recipients sat in the same office. In addition, all the official communications happened over email (hobbits did not quite like the idea of cutting down trees to produce paper and tried to aim for a “paperless office” long before the term became a fashionable buzzword). Sending and receiving these mails consumed most of the limited bandwidth that the company had, and therefore Sam had to find some way of reducing this unnecessary overhead.

The natural solution for this problem was to set up an internal mail server. Sam looked at all the available options and then settled on Sendmail because of its power and almost endless configurability, even though it was somewhat complex for a novice. He found that qmail was far simpler and much faster, but not quite as powerful as Sendmail, especially for some of the things that Sam ultimately wanted to do.

Again, he could have built Sendmail from its source code, which was freely available, but decided not to, as the binaries that came with his distribution were perfectly all right for his job.

To avoid unnecessary frustrations in the setup of the mail server, Sam made sure that he read up the excellent Linux Mail HowTos. And without the essential Sendmail FAQ, Sam would not have been able to set up anything.

Internal Mail Setup

Simple internal mail setup with Sendmail was a no-brainer - Sam just installed Sendmail and created user accounts on the server for all the hobbits of the company. Every hobbit in the company then had an internal email address of the form To send and receive internal mails, each hobbit had to give the Intranet server as the SMTP and POP3 servers in the configuration for his favourite email client. The Linux distribution that Sam used had automatically installed a simple POP3 daemon, so he didn't have to install one separately. (Sam could also have used the IMAP and POP3 servers that come with the PINE distribution.)

In the DNS server configuration, the Intranet server was listed as an “MX (Mail Exchanger)” entry for the “” domain, so that the email address did not have to explicitly contain the address of the mail server (i.e. instead of having to specify “”, they could just write “”). This enabled location transparency for the addresses - Sam could now easily move the email server to a different machine if needed, without asking everyone to update their address books - all he had to do was to update the entry in the DNS server.

Sam used the Quota support in Linux (referring to the great Quota mini-HowTo of course), to limit the total size of files that the users could store on the server. This automatically limited the capacity of the mailboxes for the hobbits and prevented abuse of the server.

Linking with External Mail Accounts

For a while things looked great - the internal mail setup considerably reduced the load on the Internet link. However, now most hobbits had to deal with at least two email accounts - the internal mail account and the externally visible account - not to mention other accounts, mostly hosted by free web-based email services. The least Sam could do was to link the “official” mail accounts.

The first step for Sam was to ensure that the hobbits also get to see their “external” mails when they checked their internal mails. He used the really nifty Fetchmail program to enable this. He just installed the version that came with his distribution and then configured it. His Fetchmail configuration (stored in the home directory of the super-user as the file “.fetchmailrc”) looked something like this:

set daemon 900
poll with protocol POP3:
no dns, aka
user is frodo here
password \x70\x61\x73\x73\x77\x6f\x72\x64
user is sam here
password \x70\x61\x73\x73\x77\x6f\x72\x64

The first line of the configuration file asked Fetchmail to run in the “daemon mode” and wake up every 900 seconds (or 15 minutes) to check user mails. The next line asked it to connect to the company's external POP3 server and retrieve the user mails. Each user's external id with the relevant password was listed alongwith the mapping to the internal mail id. Thus, any mail sent to would be automatically fetched by the program and routed to the mailbox of the local user frodo. Frodo would then get to see the mail the next time he checks his internal mails.

Since this file contained passwords for users for the external mail accounts, it had to be protected by having read permissions only for the super-user. Furthermore, the passwords were obfuscated by using the following C program:

* ObPass: A very simple program that converts a given
* word into C-style hex escape sequences for entering
* into the runtime configuration file for Fetchmail.
#include <stdio.h>
#include <unistd.h>
int main( int argc, char* argv[])
char *str;
if( argc != 1)
fprintf( stderr,
"%s: Obfuscate a password into a C-style hex sequence\n",
fprintf( stderr, "Usage: %s <ENTER>\n", argv[0]);
return 1;
} /* End if */
str = getpass( "Please enter the password: ");
for( ; *str != '\0'; str++)
printf( "\\x%x", *str);
} /* End for */
printf( "\n");
} /* End else */
} /* End function main */

Sam added Fetchmail to the system startup scripts, so that it automatically started up when the system booted. Fetchmail ensured that the hobbits could see their internal and external emails in one place.

This setup was not without problems however. The default configuration of the SMTP server on the Intranet server did allow mails to be sent to external users, but almost always resulted in “Sender domain must exist” style errors. And for the mails that did get through, the recipients could not reply to the message as the sender address was the internal email address of the form, which was meaningless to their mail clients.

Here is where the power of Sendmail came to Sam's rescue: Sam could configure Sendmail to rewrite the sender's address so that was always of the form with the correct mapping to the external id. Thus mails sent by were rewritten to appear to have come from

Sendmail usually reads its configuration information from the file “/etc/”, but this is usually too complex for the average person to tweak himself. Therefore it comes with scripts that automate the generation of this configuration file. Sam's Linux distribution placed these scripts and sample configuration files in the “/usr/src/sendmail” folder. Under the folder “cf/cf” in this folder, was a sample configuration file named “”. Sam tweaked this file until it looked something like this:

VERSIONID(`linux for smtp-only setup')dnl
FEATURE(genericstable, btree /etc/mail/genericstable)dnl
FEATURE(virtusertable, btree /etc/mail/virtuserstable)dnl
GENERICS_DOMAIN_FILE( /etc/mail/generics-domain)dnl

Of course, this was all according to the instructions given in the life-saving Sendmail FAQ. The reference to the server was there to ensure that all external mails were processed and delivered by the ISP's SMTP server rather than the Intranet server. This process was called “relaying” and helped save the bandwidth further. Sam ran the m4 macro processor on this file to generate the final Sendmail configuration file like this:

m4 < >/etc/

The next step was to create the “generics table” and the “virtual users map” (refer to the Sendmail FAQ) in the “/etc/mail” folder (Sam had to create this folder). These were in-file databases and were created using the “updatemaildbs” shell script that Sam wrote:

makemap btree virtuserstable <virtualusermaps
makemap btree genericstable <genericusermaps

The “virtualusermaps” file looked like this:	frodo	sam

And the “genericusermaps” file looked like this:

frodo	Frodo_Baggins
sam Samwise_Gamgee

Finally, the “generics-domain” file looked like this:

The updatemaildbs shell script took these text files and generated the appropriate in-file databases (with the .db extension). These files together ensured that any mail sent to an external user will have the sender's address rewritten to use the external email address and any mail sent to the external address of a user will automatically be routed to his internal mailbox. Thus any mail sent to would automatically be routed to his internal mailbox corresponding to the address, saving the unnecessary trip to the external SMTP server.

This was a setup as close to the ideal as possible - no mail would waste the available bandwidth if it could somehow be routed internally. And the hobbits got a single convenient “magical” mail account that made the best use of the bandwidth and could be used for both internal as well as external communications.


As more employees joined the company, Sam had to keep the mail server configuration up to date. He had to create the account for the new employee, update the Fetchmail configuration file, update the generic users table and the virtual users map for Sendmail. He had to ensure that the servers read the modified configuration (by sending them the “HUP” signal through the kill command).

From time to time, he looked at the messages produced via syslog to proactively weed out potential problems with the system.


The mail server setup considerably reduced the load on the available bandwidth. Further, the linking of the external and internal accounts provided a convenient single interface to the hobbits to access all of their “official” mails.

Since sending and receiving mails had become so easy, the Hobbit Resources (HR) department was able to roll in effective processes for various activities.


The following resources proved immensely useful to Sam during the setup of the mail server:

  1. Linux Mail HowTos: The set of documents that helped Sam get started on the mail server setup and taught him various concepts.
  2. Sendmail: The mail server implementation that Sam used. The Sendmail FAQ was an extremely useful resource without which he possibly couldn't have worked out the magic.
  3. qmail: The other mail server that Sam could have used (and would have preferred) had his needs not been so complicated.
  4. PINE: The email client which comes with the IMAP and POP3 servers that Sam could have used as an alternative to those that came with his distribution.
  5. Fetchmail: The powerful, automated mail retriever program that enabled Sam to merge the external and internal email accounts.
  6. Quota mini-HowTo: The document that Sam used to understand how to set up usage quotas for users under Linux.