| Grabber Softwares : Enhance Your Computing |
Get Going With E-Mail A step-by-step guide to setting up an Internet mail server 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 [email protected]. 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 [email protected]. 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 [email protected], 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
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 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:
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 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:
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 [email protected]), and that account has a password mypassword, then your fetchmailrc will look like this.)
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 OK, now assuming that things work fine, we will create a script that does all the sending and receiving in one shot:
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! |