Configuring Linux Mail Servers
= = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = =
In This Chapter
Chapter 9
Configuring Linux Mail Servers
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. Once the mail arrives on the mail server it can be read
in 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.
The process is different when sending mail via the mail
server:
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.
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.
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.8-9.90. Install all
the packages in this order:
[root@bigboy tmp]# rpm -Uvh
sendmail-cf-8.12.8-9.90.i386.rpm
[root@bigboy tmp]# rpm -Uvh sendmail-8.12.8-9.90.i386.rpm
You’ll also need to make sure the M4 macro package is
also installed.
[root@bigboy tmp]# rpm -Uvh m4-1.4.1-13.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 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:
[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]#
[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]#
[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.
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]#
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.
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
[root@bigboy tmp]# /etc/init.d/sendmail restart
Shutting down sendmail: [ OK ]
Starting sendmail: [ OK ]
[root@bigboy tmp]#
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]#
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:
The system name
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.
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.
The first lists the destination to which the original
sender intended to send the mail.
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.
If the mailing list member doesn't have an "@" in the
name, then sendmail assumes the recipient is on the local box.
It will then search the first column of the aliases
file to see if the recipient isn't on yet another mailing list.
If it doesn't find a duplicate, it assumes the
recipient is a local user.
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:
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".
"sales" at my-site.com will go to the sales
department at my-othersite.com.
"paul" and "finance" at my-site.com goes to local
user (or mailing list) "paul"
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 /home/mailings/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.
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_DOMAIN(localhost)dnl
MASQUERADE_DOMAIN(localhost.localdomain)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 and
localdomain domains appear to come from the MASQUERADE_AS domain of
my-site.com. Sendmail uses DNS to check the domain name associated with
the IP address of the mail relay client sending the mail to help it
determine whether it should do masquerading or not.
·
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 as my-site.com. If this wasn't selected, then only servers
named my-site.com and my-othersite.com would be masqueraded. Use this with
caution 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.
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.
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
Sometimes masquerading isn’t enough. There are times
when you may need to change not only the domain of the sender but also the
username portion of the sender’s email address.
For example, the need to do this could occur after
buying a program for your SOHO office that sends out notifications to your
staff, but the sender’s address inserted by the program is its own, and
not that of the IT person.
Sendmail allows you to change both the domain and
username on a case by case basis using the genericstable feature.
To do this you need to:
Add these statements to your /etc/mail/sendmail.mc
file to activate the feature:
FEATURE(`genericstable',`hash -o /etc/mail/genericstable.db')dnl
GENERICS_DOMAIN_FILE(`/etc/mail/generics-domains')dnl
Create a /etc/mail/generics-domains file that
is just a list of all the domains that should be inspected. This should
include your server’s canonical domain name which can be obtained by using
the command:
sendmail -bt -d0.1 </dev/null
Here is a sample /etc/mail/generics-domains
file:
my-site.com
my-other-site.com
bigboy.my-site.com
Create your /etc/mail/genericstable file.
First sendmail searches the /etc/mail/generics-domains file
mentioned in the previous step for a list of domains to reverse map. It
then looks at the /etc/mail/genericstable file for an individual
email address from a matching domain. The format of the file is
linux-username username@new-domain.com
Here is an example:
alert security-alert@my-site.com
peter urgent-message@my-site.com
Run the sendmail restart script I mentioned at the
beginning of the chapter and then test.
There are many publicly available lists of known open
mail relay servers and spam generating mail servers on the Internet. Some
are maintained by volunteers, others are managed by public companies, but
in all cases they rely heavily on complaints from spam victims. Some spam
blacklists simply try to determine whether the email is coming from a
legitimate IP address.
The IP addresses of offenders usually remain on the list
for six months to two years. In some cases, to provide additional pressure
on the spammers, the blacklists will include not only the offending IP
address but also the entire subnet or network block to which it belongs.
This prevents the spammers from easily switching their server’s IP address
to the next available one on their network. Also, if the spammer uses a
public datacenter, it is possible that their activities would also cause
the IP addresses of legitimate emailers to be black listed too. It is
hoped that these legitimate users will pressure the datacenter’s
management to evict the spamming customer.
You can configure sendmail to use its `dnsbl'
feature to both query these lists and reject the mail if a match is found.
Here are some sample entries you can add to your /etc/sendmail.mc
file, they should all be on one line. You can visit the URLs listed to
learn more about the individual services.
Valid IP address checker.
FEATURE(`dnsbl', `ipwhois.rfc-ignorant.org',`"550 Mail
from " $&{client_addr} " refused. Rejected for bad WHOIS info on IP of
your SMTP server - see http://www.rfc-ignorant.org/"')
Open proxy list.
FEATURE(`dnsbl', `proxies.blackholes.easynet.nl', `"550
5.7.1 ACCESS DENIED to OPEN PROXY SERVER "$&{client_name}" by easynet.nl
DNSBL (http://proxies.blackholes.easynet.nl/errors.html)"', `')dnl
Open mail relay list.
FEATURE(`dnsbl', `relays.ordb.org', `"550 Email
rejected due to sending server misconfiguration - see
http://www.ordb.org/faq/\#why_rejected"')dnl
Spammer blacklist.
FEATURE(`dnsbl', `bl.spamcop.net', `"450 Mail from "
$`'&{client_addr} " refused - see http://spamcop.net/bl.shtml"')
Spammer blacklist.
FEATURE(`dnsbl',`sbl.spamhaus.org',`Rejected - see
http://spamhaus.org/')dnl
Blacklists won’t stop everything.
It is possible to limit the amount of unsolicited
commercial email (UCE or 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:
MailTools
IO-Stringy
MIME-tools
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:
Install PERL and the PERL modules listed above.
Place an executable version of the script in your
home directory and modify the script’s $FILEPATH variable point to your
home directory
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.
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 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.
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
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.
|
