by September 6, 2001 0 comments

One of the biggest advantages Linux offers is that it is a
fully functional electronic mail server–right out-of-the-box. Using it you can
instantly offer internal e-mail to everyone within your organization.

If you are only looking at internal e-mail, then there is
very little that needs to be done. Just add users to the system, set their mail clients to
use the server for SMTP and POP3 (either specify using the IP Address of the server or the
hostname, if the client has been set to use the server as a DNS server). For example, in
our set-up, the server is known as with an IP address of Client machines running e-mail software (such as Eudora, Outlook Express,
Netscape mail, etc.) need to be set to use the server ( as SMTP and POP3
host, and every user’s e-mail address will be

However, if you plan to exchange mail with external users,
there are a few things you need to do. First of all, you need to have a registered domain
name. This is easy, though slightly expensive, because not only do you require the domain
name, but also a place where your mail arrives. If you are permanently connected to the
Internet and have a fixed IP address (if you have a leased line, for example) this is not
really an issue, because you yourself will be the target host. But in case you are
connected only periodically to the Internet, such as through a dial-up, you will need to
have a place where your mail arrives and is stored until you pick it up.

Usually, the provider with whom you contract for Web/mail
space will also do the name registration for you. Even VSNL has recently started offering
these services, albeit at a very high price. You can get much better deals by contracting
with a provider outside the country. More on this later.

By default, the server is set up to send and receive mail
in the name of the host–in our setup, that would mean that all mail would be sent to
and be received by However, that is not how we want our mail to go
out to the world–our addresses are of the format Therefore, we
need to make a few changes.

Before we do, we also need to address another issue. Any
SMTP mail host will, by default, try to direct-deliver every piece of mail going to the
outside world. This means that if a message is sent to, then our
server will try to deliver the message directly to
or its designated mailhost.

This has some serious disadvantages. Every address will
have to be resolved before the message can be delivered, and not all hosts are always
immediately reachable. To get around this, we need to deliver mail to our relay server–a
host run by our ISP (in our case VSNL) that will then do the work for us.

To achieve the two goals (proper domain names in mail and
using a relay host), we need to edit the file /etc/ Do it now with the
command joe /etc/

The first thing you want to do is turn of the word-wrap
feature that could otherwise mess up the file–hit Ctrl-TW to turn off word-wrap.

Now scroll down until you find the line beginning with DS.
And change it to Dsyourrelayhost.

For example, in our case, we change it to

Note that you must use a name and not an IP address
here. If you are in another city, use the hostname for your city–in Bangalore, it is,
in Bombay it is, and so on. Check with your provider for the
actual name. Now scroll down further until you find a line starting with DM. Change
it to reflect your desired domain. In our case, the desired domain is, so
we changed it to This will masquerade all mail coming from this
server as coming from our domain (in our case That’s it. Save the file with Ctrl-KX. At this
point, you are all set. All that is now required is to tell sendmail to also accept
mail for, else it will try to deliver this mail further, since it does not
know that is also the mail server for That’s
quickly achieved by editing the file /etc/ by using the command joe

Just add a line to that file giving the name of the domain
that you accept mail for, in our case and save the file. Then restart
sendmail using the command /etc/rc.d/init.d/sendmail. Now, restart and you are all

An offline mail server

One problem that we need to address is that your machine
may not always be connected to the Internet, and hence the machine

  • cannot always deliver mail immediately
  • cannot resolve external names

To get around this, we need to resort to some trickery.

First of all, we will tell sendmail not to try and
deliver mail outside our host immediately (internal mail, that is, mail between users in
the same office
will be delivered imemdiately).

To do this, edit /etc/ again. Scroll down
until you find O HoldExpensive=False, and change it to O HoldExpensive=True.
Now scroll down further (way down) until you find the following:

Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990,
A=IPC $h
Mesmtp, P=[IPC], F=mDFMuXa, S=11/31, R=21, E=\r\n, L=990,
A=IPC $h
Msmtp8, P=[IPC], F=mDFMuX8, S=11/31, R=21, E=\r\n, L=990,
A=IPC $h
Mrelay, P=[IPC], F=mDFMuXa8, S=11/31, R=61, E=\r\n, L=2040,
A=IPC $h

This may look gibberish to you, but don’t worry. All
you need to do is place a small e at the end of the F= field in each one of
these M settings.

For example, F=mDFMuX will become F=mDFMuXe.

This tells sendmail that these Mailers are expensive,
and our previous setting (O Holdexpensive=True) will ensure that these mailers will not
try and deliver mail unless explicitly told to. Save the file (Ctrl-KX). Now we must stop
sendmail from attempting to send out mail on its own every now and then. Edit the file /etc/rc.d/init.d/sendmail
and change the following line daemon /usr/sbin/sendmail -bd -q15m to daemon
/usr/sbin/sendmail -bd —os
and save the file. Now restart sendmail (/etc/rc.d/init.d/sendmail restart)
and you have solved part of the problem.

What happens now is that any mail destined for the outside
world will be queued up for later delivery. When you are online and wish to force all
external mail to be processed, you issue the command /usr/sbin/sendmail
—q &.
This will start the mail flushing process in the background. If you
want to watch the mail going out, use /usr/sbin/sendmail —q —v instead.

Normally, the former command (/usr/sbin/sendmail —q
) is used in a script immediately after connection to the Internet. However, many
of us would rather be in control of what is happening, and hence, have this command as a
part of a script that sends out all mail, then picks up all mail for this domain and
distributes it.

We will write such a script in a little while. Let’s
address the other problem first–the one which stops sendmail from being able to
resolve names–thereby causing serious delays while accepting mail from a client.

Sendmail is the server software that accepts and delivers
e-mail under most Unix systems, including Linux. It does a number of things, and is a very
complex software.

One of the things it does is to make sure that the address
of the mail it is being asked to deliver actually exists. It can do this only if it finds
a running name server on your system (which it will, since we set one up for you during
the pcqupdt time).

The minus-point here is that if you aren’t connected
to the Internet, sendmail (or rather the nameserver) will not be able to resolve names
outside your own domain. It takes quite a while before it finally gives up and assumes
that you (the person sending the mail) know what you are doing, and accepts the mail

These delays can be very frustrating. Luckily, in the DNS
article in this issue, we have described how to set up your nameserver in such a way that
it will not try and resolve names on the Internet when it isn’t connected to the

At this time, we urge you to read Configuring DHCP and
DNS Services
, if you haven’t already. That takes care of all these issues.

A dial-out mail server

Let’s look at a method to run a mail server that is
connected to the Internet only at certain times (typically through a dial-up). First of
all, you will need to have an Internet domain–without this, you cannot have
mail coming to everyone in the office. To get a domain, you have to do two things:

  1. Register a domain with the InterNIC
  2. Contract with a provider to service this domain.

Typically, you will find that the provider himself can
register the domain for you. He will register the domain for you with the
InterNIC. The
bill for this will come to you directly from the InterNIC –the amount will be US $70
(it used to be $100) for the initial two years. You need to get a US $ International Money
Order from any authorized bank, and send the amount to the InterNIC. With this, you will
own the domain. Now your provider will set up his server to answer your
mail-domain (and possibly host your website, if you have contracted for that, too–something
you normally do). All mail coming in for your domain will then be redirected to a single
account–either on the provider’s server or to a VSNL account that you specify.

Now we are receiving mail for the domain, but your server
still isn’t picking it up and redistributing it. To achieve this, you need to set up
a nifty little program calledfetchmail.

Fetchmail does only one thing, but it does it rather well–it
uses POP3 to pick up all messages from an account, examines the headers, and then forwards
each message to the correct user account on your server.

Setting up fetchmail is very simple–all you need to do
is create a file called .fetchmailrc (don’t miss the leading dot!) in the root
account’s home directory (typically /root). Here’s what you need to put
in it:

(Assuming that your provider redirects all mail for your
domain (in our case to an account on VSNL’s server (in our case,
and that account has a password mypassword, then your fetchmailrc will look like

set daemon=0
poll with protocol POP3:
no dns, aka
user pcq is * here
password password

You can now create this file using the text editor we have
been using so far– just run joe /root/.fetchmailrc, type in the above (with
your values, of course), and save the file with Ctrl-KX.

Note that fetchmail will refuse to use this file if it is
readable by all (makes sense–it has your password in it!). So run this command: chmod
600 /root/.fetchmailrc

Done. Let’s test this. Connect to the Internet (if you
haven’t yet configured your machine to do so, read Connecting To The Internet).

Now run the following command: fetchmail —k —a
—v —d 0 —N

Fetchmail will pick up all messages in your account, look
at the headers, and deliver them to the corresponding user on your server. If any mail
coming in has invalid user addresses for your domain (or mail for which fetchmail cannot
figure out the appropriate user), it will be delivered to the root account–you can
then check the messages and take appropriate action, like forward it to the correct user.

Note that in the command shown above, we used the —a
and —k flags–normally they are not used, but while we are testing, they
tell fetchmail to pick up all messages (-a) even if they had been picked up before, and
not to delete the messages from the remote server
(-k). In a production environment, you would not use these flags. OK, now assuming that things work fine, we will create a
script that does all the sending and receiving in one shot:

joe /sbin/mailrun
echo Sending out all mail waiting for delivery…
/usr/sbin/sendmail –q $*
echo Picking up all mail waiting to be received…
/usr/bin/fetchmail –d 0 –N $*
echo Done.
Save the file with Ctrl-KX, and then make it executable:
chmod +x /sbin/mailrun

Now try it out! Connect to the Internet, and then type the
command mailrun –v. The –v parameter is passed to sendmail and
fetchmail in the script, causing them to be verbose—you can see what happens.

If there were any messages waiting to be sent out, sendmail
will send them out. Then, fetchmail will pick up all messages waiting for you, and that’s
it! You can disconnect now!

Wind up

Whew! This was a really complex setup! Sorry about that,
but it is a one-time only situation—once you have everything running, you won’t
have to touch these settings again.

If you have managed to get everything done as described
above, you should now have a working mail server, and your users can happily send and
receive mail to and from each other, and to and from people on the Internet.

Because of the complexity of this setup, we expect that you
can have problems. The biggest one we see is that of getting a domain and choosing a
provider who can service that domain. We will try and put up a list of providers who offer
such services on the PC Quest website. However, this may take a while, so please be
patient! If you cannot wait, call VSNL and ask them for references—almost all their
agents offer domain services.

Best of luck!

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.