| Contents |
|---|
| Email Server |
| Internal Mail Setup |
| Linking with External Mail Accounts |
| Maintenance |
| Conclusion |
| Resources |
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 username@internal.hobbitware.com. 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
“internal.hobbitware.com” 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
“merry@dns.internal.hobbitware.com”, they could
just write “merry@internal.hobbitware.com”). 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 pop.hobbitware.com with protocol POP3: no dns, aka hobbitware.com user Frodo_Baggins%hobbitware.com is frodo here password \x70\x61\x73\x73\x77\x6f\x72\x64 user Samwise_Gamgee%hobbitware.com 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 Frodo_Baggins@hobbitware.com 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",
argv[0]);
fprintf( stderr, "Usage: %s <ENTER>\n", argv[0]);
return 1;
} /* End if */
else
{
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
internal.hobbitware.com, 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 hobbitware.com with the correct mapping to the external id. Thus mails sent by frodo@internal.hobbitware.com were rewritten to appear to have come from Frodo_Baggins@hobbitware.com.
Sendmail usually reads its configuration information from the
file “/etc/sendmail.cf”, 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 “linux.smtp.mc”.
Sam tweaked this file until it looked something like this:
include(`../m4/cf.m4') VERSIONID(`linux for smtp-only setup')dnl OSTYPE(linux) FEATURE(nouucp)dnl FEATURE(genericstable, btree /etc/mail/genericstable)dnl FEATURE(virtusertable, btree /etc/mail/virtuserstable)dnl GENERICS_DOMAIN_FILE( /etc/mail/generics-domain)dnl FEATURE(masquerade_envelope)dnl FEATURE(relay_local_from)dnl MAILER(local)dnl MAILER(smtp)dnl MASQUERADE_AS(hobbitware.com) Cwinternal.hobbitware.com Cwhobbitware.com DSsmtp.shirenet.com
Of course, this was all according to the instructions given in the
life-saving Sendmail FAQ. The reference to the server
smtp.shirenet.com 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 <linux.smtp.mc >/etc/sendmail.cf
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:
#!/bin/bash makemap btree virtuserstable <virtualusermaps makemap btree genericstable <genericusermaps
The “virtualusermaps” file looked like
this:
Frodo_Baggins@hobbitware.com frodo Samwise_Gamgee@hobbitware.com sam @hobbitware.com %1@pop.hobbitware.com
And the “genericusermaps” file looked like
this:
frodo Frodo_Baggins sam Samwise_Gamgee
Finally, the “generics-domain” file looked like
this:
internal.hobbitware.com
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 Frodo_Baggins@hobbitware.com would automatically
be routed to his internal mailbox corresponding to the address
frodo@internal.hobbitware.com, 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.
Maintenance
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.
Conclusion
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.
Resources
The following resources proved immensely useful to Sam during the setup of the mail server:
- Linux Mail HowTos: The set of documents that helped Sam get started on the mail server setup and taught him various concepts.
- 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.
- qmail: The other mail server that Sam could have used (and would have preferred) had his needs not been so complicated.
- 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.
- Fetchmail: The powerful, automated mail retriever program that enabled Sam to merge the external and internal email accounts.
- Quota mini-HowTo: The document that Sam used to understand how to set up usage quotas for users under Linux.
Feed
Blog
Twitter