Get Going With E-Mail

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 labs.cmil.com with an IP address of

192.168.1.15. Client machines running e-mail software (such as Eudora, Outlook Express,

Netscape mail, etc.) need to be set to use the server (192.168.1.15) as SMTP and POP3

host, and every user’s e-mail address will be user@labs.cmil.com.

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 labs.cmil.com. However, that is not how we want our mail to go

out to the world–our addresses are of the format user@cmil.com. 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 achitnis@cbconsulting.com, then our

server labs.cmil.com will try to deliver the message directly to cbconsulting.com

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/sendmail.cf. Do it now with the

command joe /etc/sendmail.cf

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 DSgiasdl01.vsnl.net.in.

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 mbg.vsnl.net.in,

in Bombay it is giasbm01.vsnl.net.in, 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 cmil.com, so

we changed it to DMcmil.com. This will masquerade all mail coming from this

server as coming from our domain (in our case cmil.com). 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 cmil.com, else it will try to deliver this mail further, since it does not

know that labs.cmil.com is also the mail server for cmil.com. That’s

quickly achieved by editing the file /etc/sendmail.cw by using the command joe

/etc/sendmail.cw.

Just add a line to that file giving the name of the domain

that you accept mail for, in our case cmil.com and save the file. Then restart

sendmail using the command /etc/rc.d/init.d/sendmail. Now, restart and you are all

done.

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/sendmail.cf 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=, F=mDFMuX, S=11/31, R=21, E=\r\n, L=990,



T=DNS/RFC822/SMTP,


A=IPC $h


Mesmtp, P=, F=mDFMuXa, S=11/31, R=21, E=\r\n, L=990,


T=DNS/RFC822/SMTP,


A=IPC $h


Msmtp8, P=, F=mDFMuX8, S=11/31, R=21, E=\r\n, L=990,


T=DNS/RFC822/SMTP,


A=IPC $h


Mrelay, P=, F=mDFMuXa8, S=11/31, R=61, E=\r\n, L=2040,


T=DNS/RFC822/SMTP,


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

anyway.

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

Internet.

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 cmil.com) to an account on VSNL’s server (in our case pcq@giasdl01.vsnl.net.in),

and that account has a password mypassword, then your fetchmailrc will look like

this.)

set daemon=0



poll giasdl01.vsnl.net.in with protocol POP3:


no dns, aka cmil.com


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



#!/bin/sh


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!