More Linux Server Topics - Network Diagram - About This Site

Chapter 21

Configuring Linux Mail Servers

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

In This Chapter

Chapter 21

Configuring Linux Mail Servers

Configuring Sendmail

Configuring Your POP Mail Server

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

This chapter will help to show you how to set up a mail server for your home network. It covers Sendmail which is responsible for relaying your mail to a remote user’s mailbox and also POP mail which is used to retrieve the mail from the mail box to your local PC via a mail client such as outlook Express.

Configuring Sendmail

An Overview Of How Sendmail Works

Sendmail is the most popular Linux program for processing mail. Once the mail arrives on the mail server it can be read in a number of ways:

o Linux users logged into the mail server can read their mail directly using a text based client such as "mail" or a GUI client such as Evolution.

o Windows users can use an email client such as "Outlook" or "Outlook Express" to download the mail to their local PC via POP. Windows users also have the option of either keeping or deleting the mail on the mail server after it has been downloaded.

The process is different when sending mail via the mail server:

o If the mail is destined for a local user then sendmail will place the message in that person’s mailbox so that they can retrieve it using one of the methods above.

o If the mail isn't destined for the mailbox of a local user, then sendmail will attempt to relay it to the appropriate destination mail server via the Simple Mail Transport Protocol or SMTP. One of the main advantages of mail relaying is that when a PC user "A" sends mail to another user "B" on the Internet, the PC of user "A" can delegate the SMTP processing to the mail server.

Note:If mail relaying is not configured properly then your mail server could end up relaying SPAM. Simple sendmail security is outlined on this page.

Configuring DNS

Remember that you will never receive mail unless you have configured DNS for your domain to make your new Linux box mail server the target of the DNS domain's MX record. See either the Static DNS or Dynamic DNS pages on how to do this.

Installing And Starting Sendmail

Most RedHat Linux software products are available in the RPM format. Downloading and installing RPMs isn’t hard. If you need a refresher, the chapter on RPMs covers how to do this in detail.

o It is best to use the latest version of sendmail as older versions have had a number of security holes. As of this writing the latest version of the sendmail suite was version 8.12.5-7. Install all the packages in this order:

[root@bigboy tmp]# rpm -Uvh sendmail-cf-8.12.5-7 .i386.rpm
[root@bigboy tmp]# rpm -Uvh sendmail-8.12.5-7 .i386.rpm
[root@bigboy tmp]# rpm -Uvh sendmail-devel-8.12.5-7 .i386.rpm

o You can use the chkconfig command to get Sendmail configured to start at boot:

[root@bigboy tmp]# chkconfig --level 35 sendmail on

o To start/stop/restart sendmail after booting

[root@bigboy tmp]# /etc/init.d/sendmail start

[root@bigboy tmp]# /etc/init.d/sendmail stop

[root@bigboy tmp]# /etc/init.d/sendmail restart

o Remember to restart the sendmail process every time you make a change to the configuration files for the changes to take effect on the running process. You can also test whether the sendmail process is running with the pgrep command, you should get a response of plain old process ID numbers:

[root@bigboy tmp]# pgrep sendmail

Restart Sendmail After Editing Your Configuration Files

In this chapter we’ll see that Sendmail uses a variety of configuration files which require different treatments in order for their commands to take effect. This little script encapsulates all the required post configuration steps.

#!/bin/bash

cd /etc/mail
make
m4 /etc/mail/sendmail.mc > /etc/sendmail.cf # RH Ver 7.3-

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf # RH Ver 8.0+

newaliases
/etc/init.d/sendmail restart

Use this command to make the script executable.

chmod 700 filename

You’ll need to run the script each time you change any of the sendmail configuration files described in the sections to follow.

The line in the script that restarts sendmail is only needed if you have made changes to the /etc/mail/sendmail.mc file, but it has been included so that you don’t forget. This may not be a good idea in a production system. Delete the appropriate "m4" line depending on your version of RedHat.

Both the newaliases and m4 commands depend on the sendmail-cf RPM package. This must be installed, if not, you'll get errors like this when running the script:

Errors With The Newaliases Command

[root@bigboy mail]# newaliases
Warning: .cf file is out of date: sendmail 8.12.5 supports version 10, .cf file is version 0
No local mailer defined
QueueDirectory (Q) option must be set
[root@bigboy mail]#

Errors With The m4 Command

[root@bigboy mail]# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
/etc/mail/sendmail.mc:8: m4: Cannot open /usr/share/sendmail-cf/m4/cf.m4: No such file or directory
[root@bigboy mail]#

Errors When Restarting sendmail

[root@bigboy mail]# /etc/init.d/sendmail restart
Shutting down sendmail: [ OK ]
Shutting down sm-client: [FAILED]
Starting sendmail: 554 5.0.0 No local mailer defined
554 5.0.0 QueueDirectory (Q) option must be set
[FAILED]
Starting sm-client: [ OK ]
[root@bigboy mail]#

The /var/log/maillog File

Sendmail throws all its status messages in the /var/log/maillog file. It is always good to monitor this file whenever you are doing changes. Open two telnet, SSH or console windows. Work in one of them and monitor the sendmail status output in the other using the command

[root@bigboy tmp]# tail -f /var/log/maillog

The /etc/mail/sendmail.mc File

Most of sendmail's configuration parameters are set in this file with the exception of mailing list and mail relay security features. It is often viewed as an intimidating file with its series of structured "directive" statements that get the job done. Fortunately in most cases you won't have to edit this file very often.

The two most basic steps in configuring a Sendmail server are to modify this file to enable Sendmail to listen on the NIC interface and to make Sendmail to accept mail from valid web domains.

Why Sendmail Only Listens On The Loopback Interface By Default

All Linux systems have a virtual loopback interface that only lives in memory with an IP address 127.0.0.1. As mail must be sent to a target IP address even when there is no NIC in the box, Sendmail therefore uses the loopback address to send mail to users on the local box. To become a server, and not a client, Sendmail needs to be also configured to listen for messages on the NIC interface.

We can verify that sendmail is running by first using the pgrep command which will return the sendmail process ID number once sendmail is running. If it isn't running, then the return value will be blank.

[root@bigboy tmp]# pgrep sendmail
22131

[root@bigboy tmp]#

We can also see the interfaces on which Sendmail is listening with the “netstat” command. Sendmail listens on TCP port 25, so we use "netstat" and "grep" for "25" to see a default configuration listening only on IP address 127.0.0.1 (loopback).

[root@bigboy tmp]# netstat -an | grep :25 | grep tcp
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
[root@bigboy tmp]#

Edit /etc/mail/sendmail.mc To Make Sendmail Listen On NICs Too

To correct this you'll have to comment out the daemon_options line in the /etc/mail/sendmail.mc file with "dnl" statements. It is also good practice to take precautions against SPAM by not accepting mail from domains that don't exist by commenting out the "accept_unresolvable_domains" feature too. See the italicized lines in the example below.

dnl This changes sendmail to only listen on the loopback device 127.0.0.1
dnl and not on any other network devices. Comment this out if you want
dnl to accept email over the network.
dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
dnl NOTE: binding both IPv4 and IPv6 daemon to the same port requires
dnl a kernel patch
dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')
dnl We strongly recommend to comment this one out if you want to protect
dnl yourself from spam. However, the laptop and users on computers that do
dnl not have 24x7 DNS do need this.
dnl FEATURE(`accept_unresolvable_domains')dnl
dnl FEATURE(`relay_based_on_MX')dnl

You need to be careful with the accept_unresolvable_names feature. In our sample network, bigboy the mail server will not accept email relayed from any of the other PCs on your network if they are not in DNS. The chapter on DNS shows how to create your own internal domain just for this purpose.

Regenerate The sendmail.cf File

Once finished editing the file, we have to regenerate a new sendmail.cf file and restart sendmail.

Note: When sendmail starts, it reads the file sendmail.cf for its configuration. sendmail.mc is a more user friendly configuration file and really is much easier to fool around with without getting burned. The sendmail.cf file is located in different directories dependent on the version of RedHat you use. /etc/sendmail.cf for versions up to 7.3, and /etc/mail/sendmail.cf for versions 8.0 and higher.

Redhat versions up to 7.3

[root@bigboy tmp]# m4 /etc/mail/sendmail.mc > /etc/sendmail.cf

Redhat versions 8.0+

[root@bigboy tmp]# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Restart sendmail to load the new configuration

[root@bigboy tmp]# /etc/init.d/sendmail restart
Shutting down sendmail: [ OK ]
Starting sendmail: [ OK ]
[root@bigboy tmp]#

Now Make Sure Sendmail Is Listening On All Interfaces

Sendmail should start listening on all interfaces (0.0.0.0)

[root@bigboy tmp]# netstat -an | grep :25 | grep tcp
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
[root@bigboy tmp]#

A General Guide To Using The sendmail.mc File

The sendmail.mc file can seem jumbled. To make it less cluttered I usually create two easily identifiable sections in it with all the custom commands I've ever added.

The first section is near the top where the FEATURE statements usually are, and the second section is at the very bottom.

Sometimes sendmail will archive this file when you do a version upgrade. Having easily identifiable modifications in this file will make post upgrade reconfiguration much easier. Here is a sample:

dnl ***** Customised section 1 start *****
dnl
dnl
FEATURE(delay_checks)dnl
FEATURE(masquerade_envelope)dnl
FEATURE(allmasquerade)dnl
FEATURE(masquerade_entire_domain)dnl
dnl
dnl
dnl ***** Customised section 1 end *****

The /etc/hosts File

It is very important to have a correctly configured /etc/hosts file. Here is a brief example:

127.0.0.1 localhost.localdomain localhost
192.168.1.100 bigboy.my-site.com bigboy mail www

Here the IP address is followed by the hostname.domain (bigboy.my-site.com) followed by the hostname and all the DNS CNAMEs assigned to the server's IP address.

Sendmail uses this file to determine:

o The system name

o The domains it is responsible for relaying

Sendmail looks for the IP address of your NIC in /etc/hosts and then assumes the first name after it is the fully qualified domain name of the server such as bigboy.my-site.com. If bigboy had an entry like this:

192.168.1.100 my-site.com (Wrong!!!)

Sendmail would assume the server's name was my-site and that the domain was all of ".com". The server would therefore be open to relay all mail from any ".com" domain and would ignore the security features of the access and relay-domains files we'll describe below.

If you fail to put the IP address of your NIC in the /etc/hosts file altogether, then you run the risk of having all your mail appear to come from localhost.localdomain and not bigboy.my-site.com.

Symptoms Of A Bad /etc/hosts File

As discussed above, a poorly configured /etc/hosts file can make mail sent from your server to the outside world appear as if it came from users at localhost.localdomain and not bigboy.my-site.com.

Use the sendmail program to send a sample email to someone in verbose mode. Enter some text after issuing the command and end your message with a single "." all by itself on the last line.

[root@bigboy tmp]# sendmail -v example@another-site.com
test text
test text
.
example@another-site.com... Connecting to mail.another-site.com. via esmtp...
220 ltmail.another-site.com LiteMail v3.02(BFLITEMAIL4A); Sat, 05 Oct 2002 06:48:44 -0400
>>> EHLO localhost.localdomain
250-mx.another-site.com Hello [67.120.221.106], pleased to meet you
250 HELP
>>> MAIL From:<root@localhost.localdomain>
250 <root@localhost.localdomain>... Sender Ok
>>> RCPT To:<example@another-site.com>
250 <example@another-site.com>... Recipient Ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 Message accepted for delivery
example@another-site.com... Sent (Message accepted for delivery)
Closing connection to mail.another-site.com.
>>> QUIT
[root@bigboy tmp]#

Localhost.localdomain is the domain that all computers use to refer to themselves, it is therefore an illegal internet domain. If mail sent from computer PC1 to PC2 appears to come from a user at localhost.localdomain on PC1 and is rejected, the rejected email will be returned to localhost.localdomain. PC2 will see that the mail originated from localhost.localdomain and will think that the rejected email should be sent to a user on PC2 that may not exist. You will probably get an error like this in /var/log/maillog if this happens:

Oct 16 10:20:04 bigboy sendmail[2500]: g9GHK3iQ002500: SYSERR(root): savemail: cannot save rejected email anywhere

Oct 16 10:20:04 bigboy sendmail[2500]: g9GHK3iQ002500: Losing ./qfg9GHK3iQ002500: savemail panic

Note: You may also get this error if you are using a SPAM prevention program, for example a script based on the PERL module Mail::Audit. An error in the script could cause this type of message too.

Another set of tell tale errors caused by the same problem can be generated when trying to send mail to a user , in this example "root", or creating a new alias database file. (The newalias command will be explained later):

[root@bigboy tmp]# sendmail -v root
WARNING: local host name (bigboy) is not qualified; fix $j in config file
[root@bigboy tmp]# newaliases

WARNING: local host name (bigboy) is not qualified; fix $j in config file
[root@bigboy tmp]#

With the accompanying error in /var/log/maillog log file that looks like this:

Oct 16 10:23:58 bigboy sendmail[2582]: My unqualified host name (bigboy) unknown; sleeping for retry

The /etc/mail/relay-domains File

The /etc/mail/relay-domains file is used to determine domains from which it will relay mail. The contents of the relay-domains file should be limited to those domains that can be trusted not to originate spam. By default, this file does not exist in a standard RedHat install. In this case, all mail sent from my-super-duper-site.com and not destined for this mail server will be forwarded.

my-super-duper-site.com

One disadvantage of this file is that it can only control mail based on the source domain which can be spoofed by SPAM email servers. The /etc/mail/access file has more capabilities, such as restricting relaying by IP address or network range and is more commonly used. If you delete /etc/mail/relay-domains, then relay access is fully determined by the /etc/mail/access file.

Sendmail has to be restarted after editing this file for the changes to take effect.

The /etc/mail/access File

You can make sure that only trusted PCs on your network have the ability to relay mail via your mail server by using the /etc/mail/access file. That is to say, the mail server will only relay mail for those PCs on your network that have their email clients configured to use the mail server as their "outgoing SMTP mail server". (In Outlook Express you set this using: Tools Menu -> Accounts -> Properties -> Servers)

If you don't take the precaution of using this feature, you may find your server being used to relay mail for SPAM email sites. Configuring the /etc/mail/access file will not stop SPAM coming to you, only SPAM flowing through you.

The /etc/mail/access file has two columns. The first lists IP addresses and domains from which the mail is coming or going. The second lists the type of action to be taken when mail from these sources / destinations is received. Keywords include RELAY, REJECT, OK (not ACCEPT) and DISCARD. There is no third column to state whether the IP address or domain is the source or destination of the mail, Sendmail assumes it could be either and tries to match both. Sendmail will REJECT all other attempted relayed mail that doesn't match any of the entries in the /etc/mail/access file. Despite this, my experience has been that control on a per email address basis is much more intuitive via the /etc/mail/virtusertable file.

In the sample file below, we allow relaying for only the server itself (127.0.0.1, localhost), two client PCs on your home 192.168.1.X network, everyone on your 192.168.2.X network and everyone passing email through the mail server from servers belonging to my-site.com. Remember that a server will only be considered a part of my-site.com if its IP address can be found in a DNS reverse zone file:

localhost.localdomain           RELAY
localhost                       RELAY
127.0.0.1                       RELAY
192.168.1.16                    RELAY
192.168.1.17                    RELAY

192.168.2 RELAY

my-site.com RELAY

You'll then have to convert this text file into a Sendmail readable database file named /etc/mail/access.db. Here are the commands to do that:

[root@bigboy tmp]# cd /etc/mail

[root@bigboy mail]# make

Remember that the relay security features of this file may not work if you don't have a correctly configured /etc/hosts file.

The /etc/mail/local-host-names File

When sendmail receives mail, it needs a way of determining whether it is responsible for the mail it receives. It uses the /etc/mail/local-host-names file to do this. This file has a list of hostnames and domains for which sendmail will accept responsibility. For example, if this mail server was to accept mail for the domains my-site.com and my-other-site.com and the host server.my-site.com then the file would look like this:

my-site.com

my-other-site.com

In this case, remember to modify the MX record of the "my-other-site.com" DNS zonefile point to my-site.com. Here is an example (Remember each "." is important):

my-other-site.com. MX 10 mail.my-site.com. ; Primary Mail Exchanger for my-other-site.com

Which User Should Really Receive The Mail?

Sendmail uses two different methods to determine who the ultimate mail recipient will be. It checks these methods in this order:

The /etc/mail/virtusertable file

This file has two columns.

o The first lists the destination to which the original sender intended to send the mail.

o The second column lists the single true destination.

The true destination in the eyes of the mail server could be a local Linux user, a mailing list entry in the /etc/aliases file or the email address of someone on some other mail server to which the mail should be automatically forwarded.

The /etc/aliases file

This file has two columns too. It could be viewed as a mailing list file. The first column has the mailing list name (sometimes called a virtual mailbox) and the second column has the members of the mailing list separated by commas.

o If the mailing list member doesn't have an "@" in the name, then sendmail assumes the recipient is on the local box.

o It will then search the first column of the aliases file to see if the recipient isn't on yet another mailing list.

o If it doesn't find a duplicate, it assumes the recipient is a local user.

o If the recipient is a mailing list, then it goes through the process all over again to determine each individual in the mailing list and when it is all finished, they will all get a copy of the email message.

The /etc/mail/virtusertable file

This file contains a set of simple instructions on what to do with received mail. The first column lists the target email address and the second column lists the local user’s mail box or remote email address to which the email should be forwarded.

In the example below; mail sent to:

o webmaster@my-other-site.com will go to local user (or mailing list) "webmasters", all other mail to my-other-site.com will go to local user "marc".

o "sales" at my-site.com will go to the sales department at my-othersite.com.

o "paul" and "finance" at my-site.com goes to local user (or mailing list) "paul"

o all other users at my-site.com receive a "bounce back" message stating "User unknown"

webmaster@my-other-site.com webmasters

@my-other-site.com marc

sales@my-site.com sales@my-other-site.com

paul@my-site.com paul

finance@my-site.com paul

@my-site.com error:nouser User unknown

After editing this file you'll have to convert it into a sendmail readable database file named /etc/mail/virtusertable.db. Here are the commands to do that:

[root@bigboy tmp]# cd /etc/mail

[root@bigboy mail]# make

The /etc/aliases File

This file is really a list of email aliases for local users. It contains a list of virtual mail boxes (or mailing lists) in the first column, and members of the mailing lists in the second column. In the example below, you can see that mail sent to users "bin", "daemon", "lp", "shutdown", "apache", "named"... etc by system processes will all be sent to user (or mailing list) "root". In this case "root" is actually an alias for a mailing list consisting of user "marc" and webmaster@my-site.com.

Note: The default /etc/aliases file installed with RedHat has the last line of this sample commented out with a "#", you may want to delete the comment and change user "marc" to another user.

# Basic system aliases -- these MUST be present.
mailer-daemon:        postmaster
postmaster:           root

# General redirections for pseudo accounts.
bin:                  root
daemon:               root
lp:                   root
shutdown:             root
mail:                 root
apache:               root
named:                root
system:               root
manager:              root
abuse:                root

# trap decode to catch security attacks
decode:               root

# Person who should get root's mail
root:                 marc,webmaster@my-site.com

Notice that there are no spaces between the mailing list entries for “root”. This is important as you will get errors if you add spaces.

After editing this file you'll have to convert it into a sendmail readable database file named /etc/aliases.db. Here is the command to do that:

[root@bigboy tmp]# newaliases

Simple Mailing Lists Using Aliases

In the simple mailing list example above, mail sent to "root" actually goes to user account "marc" and webmaster@my-site.com. Here are a few more list examples for your /etc/aliases file.

Mail to "directors@my-site.com" goes to users "peter", "paul" and "mary".

# Directors of my SOHO company

directors: peter,paul,mary

Mail sent to "family@my-site.com" goes to users "grandma", "brother" and "sister"

# My family

family: grandma,brother,sister

Mail sent to admin-list gets sent to all the users listed in the file /usr/home/admin/admin-list. The advantage of using mailing list files is that the admin-list file can be a file that trusted users can edit, user “root” is only needed update the aliases file. Despite this, there are some problems with mail reflectors. One is that bounce messages from failed attempts to broadcast goes to all users. Another is that all subscriptions and unsubscriptions have to be done manually by the mailing list administrator. If either of these are a problem for you, then consider using a mailing list manager like majordomo.

# My mailing list file

admin-list: ":include:/home/mailings/admin-list"

After editing this file, you'll have to convert it into a sendmail readable database file named /etc/aliases.db. Here is the command to do that:

[root@bigboy tmp]# newaliases

An Important Note About The /etc/aliases File

By default your system uses sendmail to mail system messages to local user "root". When sendmail sends email to a local user, it will have no "to:" in the email header. If you then use a mail client like Outlook Express with a SPAM mail filtering rule to reject mail with no to: in the header, you may find yourself dumping legitimate mail.

To get around this, try making root have an alias for a user with a fully qualified domain name, this will force sendmail to insert the correct fields in the header. Here is an example:

# Person who should get root's mail
root: webmaster@my-site.com

Sendmail Masquerading Explained

If you want your mail to appear to come from user@mysite.com and not user@bigboy.mysite.com then you have two choices:

o Configure your email client, such as Outlook Express, to set your email address to user@mysite.com. This explained later in this chapter in the POP Mail section.

o Set up masquerading to modify the domain name of all traffic originating from and passing trough your mail server.

Configuring masquerading

In the DNS configuration, we made bigboy the mailserver for the domain my-site.com. You now have to tell bigboy in the sendmail configuration file sendmail.mc that all outgoing mail originating on bigboy should appear to be coming from my-site.com, if not, based on our settings in the /etc/hosts file, it will appear to come from mail.my-site.com. This isn't terrible, but you may not want your website site to be remembered with the word "mail" in front of it. In other words you may want your mail server to handle all email by assigning a consistent return address to all outgoing mail, no matter which server originated the email.

This can be solved by editing your sendmail.mc configuration file and adding some masquerading commands and directives. These are explained below:

FEATURE(always_add_domain)dnl

FEATURE(`masquerade_entire_domain')dnl

FEATURE(`masquerade_envelope')dnl

FEATURE(`allmasquerade')dnl

MASQUERADE_AS(`my-site.com.')dnl

MASQUERADE_DOMAIN(`my-site.com.')dnl

MASQUERADE_AS(my-site.com)dnl

· The MASQUERADE_AS directive will make all mail originating on bigboy appear to come from a server within the domain my-site.com by rewriting the email header.

· The MASQUERADE_DOMAIN directive will make mail relayed via bigboy from all machines in the my-other-site.com domain appear to come from the MASQUERADE_AS domain of my-site.com.

· Feature "masquerade_entire_domain" makes sendmail masquerade servers named *my-site.com, and *my-other-site.com as my-site.com. In other words, mail from sales.my-site.com would be masqueraded too. If this wasn't selected, then only servers named my-site.com and my-othersite.com would be masqueraded. Use this with caution, only when you are sure you have the authority to do this.

· Feature "allmasquerade" will make sendmail rewrite both recipient addresses and sender addresses relative to the local machine. If you cc: yourself on an outgoing mail, the other recipient will see a cc: to an address he knows instead of one on localhost.localdomain.

· Feature "always_add_domain" will always masquerade email addresses, even if the mail is sent from a user on the mail server to another user on the same mail server.

· Feature "masquerade_envelope" will rewrite the email envelope just as "MASQUERADE_AS" rewrote the header.

The email header is what email clients, such as Outlook Express, say the "to:" and "from:" should be. The "to:" and "from:" in the header is what is used when you use Outlook Express to do a "reply" or "reply all". It is easy to fake the header, as Spammers often do, it is detrimental to email delivery to fake the envelope.

The email envelope contains the "to:" and "from:" used by mailservers for protocol negotiation. It is the envelope's "from:" which is used when email rejection messages are sent between mail servers.

Testing Masquerading

The best way of testing masquerading from the Linux command line is to use the "mail -v username" command. I have noticed that "sendmail -v username" ignores masquerading altogether. You should also tail the /var/log/maillog file to verify that the masquerading is operating correctly and check the envelope and header of test email received by test email accounts.

Other Masquerading Notes

By default, user "root" will not be masqueraded. This is achieved with the:

EXPOSED_USER(`root')dnl

command in /etc/mail/sendmail.mc. You can comment this out if you like with a "dnl" at the beginning of the line and recompiling / restarting sendmail

A Simple PERL Script To Help Stop SPAM

It is possible to limit the amount of unsolicited commercial email (UCE or SPAM) SPAM you receive by writing a small script to intercept your mail before it is written to your mailbox.

This is fairly simple to do as sendmail always checks the “.forward” file in your home directory for the name of this script. Sendmail then looks for the filename in the directory /etc/smrsh and executes it.

By default, PERL doesn’t come with modules that are able to check email headers and envelopes so you will have to download them from CPAN (www.cpan.org). The most important modules are:

o MailTools

o IO-Stringy

o MIME-tools

o Mail-Audit

I have written a script called mail-filter.pl that effectively filters out SPAM email for my home system. There are a few steps required to make the script work:

o Install PERL and the PERL modules listed above.

o Place an executable version of the script in your home directory and modify the script’s $FILEPATH variable point to your home directory

o Update the two configuration files:

v mail-filter.accept, which specifies the subjects and email addresses to accept,

v mail-filter.reject that specifies those that you should reject.

o Update your “.forward” file and place an entry in /etc/smrsh

Mail-filter will first reject all email based on the “reject” file and will then accept all mail found in the “accept” file. It will then deny everything else.

I have included a simple script with instructions on how to install the PERL modules in the Appendix.

Configuring Your POP Mail Server

Sendmail will just handle mail sent to your "my-site.com" domain. Each user on your Linux box will get mail sent to their account's mail folder. If you want to retrieve this mail from your Linux box's user account, using a mail client such as Microsoft Outlook or Outlook Express, then you have a few more steps. You'll also have to make your Linux box a POP mail server.

Installing Your POP Mail Server

Most RedHat Linux software products are available in the RPM format. Downloading and installing RPMs isn’t hard. If you need a refresher, the chapter on RPMs covers how to do this in detail.

o The IMAP/POP mail suite comes standard with the RedHat installation CDs. You can install the RPM with this command:

[root@bigboy tmp]# rpm -Uvh imap-2001a-15.i386.rpm

o POP mail is started by xinetd. Therefore to get POP mail configured to start at boot you have to use the chkconfig command to make sure xinetd starts up on booting.

[root@bigboy tmp]# chkconfig --level 35 xinetd on

o To start/stop/restart POP mail after booting you can use the xinetd init script located in the directory /etc/init.d like this:

[root@bigboy tmp]# /etc/init.d/xinetd start

[root@bigboy tmp]# /etc/init.d/xinetd stop

[root@bigboy tmp]# /etc/init.d/xinetd restart

Remember to restart the POP mail process every time you make a change to the configuration files for the changes to take effect on the running process

Configuring Your POP Mail Server

The starting and stopping of POP Mail is controlled by xinetd via the /etc/xinetd.d/ipop3 file. POP Mail is deactivated by default, so you’ll have to edit this file to start the program. Make sure the contents look like this. The disable feature must be set to "no" to accept connections.

Follow the steps below and set the "disable" parameter to "no".

[root@bigboy tmp]# cd /etc/xinetd.d
[root@bigboy xinetd.d]# vi ipop3

# default: off
# description: The POP3 service allows remote users

# to access their mail \
# using an POP3 client such as Netscape Communicator, mutt, \
# or fetchmail.
service pop3
{

socket_type = stream
wait = no
user = root
server = /usr/sbin/ipop3d
log_on_success += HOST DURATION
log_on_failure += HOST
disable = no

}

You will then have to restart xinetd for these changes to take effect using the startup script in the /etc/init.d directory.

Naturally, to disable POP Mail once again, you’ll have to edit the /etc/xinetd.d/ipop3 file, set “disable” to “yes” and restart xinetd.

How To Configure Your Windows Mail Programs

All your POP email accounts are really only regular Linux user accounts in which Sendmail has deposited mail. You can now configure your email client such as Outlook Express to use your use your new POP / SMTP Mail Server quite easily. Here’s how:

POP Mail

Set your POP mail server to be the IP address of your Linux mail server. Use your Linux user username and password when prompted.

SMTP

Set your SMTP mail server to be the IP address / domain name of your Linux mail server.

How to handle overlapping email addresses.

If you have a user overlap, eg. John Smith (john@my-site.com) and John Brown
(john@my-other-site.com), by default, both users will get sent to the Linux user account
"john". You have two choices:

o Make the user part of the email address is different. For example: john1@my-site.com and
john2@my-other-site.com. Create Linux accounts "john1" and "john2". If the
users insist on overlapping names then you may need to modify your virtusertable file.

o Create the user accounts "john1" and "john2". Have a virtusertable entries for john@my-site.com pointing to account "john1" and john@my-other-site.com pointing to account "john2". The POP configuration in Outlook Express for each user should POP using "john1" and "john2" respectively.