arun_About This Site – Network Diagram - Links

Chapter 21

Configuring Linux Mail

===========================================
In This Chapter
Chapter 21
Configuring Linux Mail
Configuring Sendmail
Configuring Your POP Mail Server

© Peter Harrison, www.linuxhomenetworking.com

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

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. This mail can then be
read a number of ways:
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.
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.
If the mail isn't destined for the mailbox of a local user, then sendmail will attempt to relay it
to the appropriate 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 user "A" PC can off load the SMTP processing to the mail server.
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.
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

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

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

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

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 then 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. sendmail.cf 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 to not 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.
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:
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.
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:

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.
A fully functional and commented /etc/mail/sendmail.mc with masquerading statements
can be found in the Appendix.

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.
Tail the /var/log/maillog file to verify that the masquerading is operating correctly
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:
 mail-filter.accept, which specifies the subjects and email addresses to accept,
 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.
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

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

 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 "disable" 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:

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.

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.