【Mail】配置邮件服务器二

---

接上续...

Fighting SPAM

Unsolicited Commercial Email (UCE or SPAM) can be annoying, time consuming to delete and in some cases dangerous when they contain viruses and worms. Fortunately there are ways you can use your mail server to combat SPAM.

Using Public SPAM Blacklists With Sendmail

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 e-mail 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 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 servers' IP addresses to the next available ones on their networks. Also, if the spammer uses a public data center, it is possible that their activities could also cause the IP addresses of legitimate e-mailers to be black listed too. It is hoped that these legitimate users will pressure the data center'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.

• RFC-Ignorant: A 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 "')

• Easynet: An 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  ()"', `')dnl

• The Open Relay Database: An open mail relay list.

FEATURE(`dnsbl', `relays.ordb.org', `"550 Email rejected due to sending server misconfiguration - see "')dnl

• Spamcop: A spammer blacklist.

FEATURE(`dnsbl', `bl.spamcop.net', `"450 Mail from " $`'&{client_addr} " refused - see "')

• Spamhaus: A spammer blacklist.

FEATURE(`dnsbl',`sbl.spamhaus.org',`Rejected - see 

Be sure to visit the URLs listed to learn more about the individual services.

Spamassassin

Once sendmail receives an e-mail message, it hands the message over to procmail, which is the application that actually places the e-mail in user mailboxes on the mail server. You can make procmail temporarily hand over control to another program, such as a spam filter. The most commonly used filter is spamassassin.

spamassassin doesn't delete spam, it merely adds the word "spam" to the beginning of the subject line of suspected spam e-mails. You can then configure the e-mail filter rules in Outlook Express or any other mail client to either delete the suspect message or store it in a special Spam folder.

Downloading And Installing Spamassassin

Most RedHat and Fedora Linux software products are available in the RPM format. When searching for the RPMs, remember that the filename usually starts with the software package name and is followed by a version number, as in spamassassin-2.60-2.i386.rpm. 

Starting Spamassassin

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

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

To start, stop, and restart spamassassin after booting:

[root@bigboy tmp]# service spamassassin start
[root@bigboy tmp]# service spamassassin stop
[root@bigboy tmp]# service spamassassin restart

Configuring procmail for spamassassin

The /etc/procmailrc file is used by procmail to determine the procmail helper programs that should be used to filter mail. This file isn't created by default.

spamassassin has a template you can use called /etc/mail/spamassassin/spamassassin-spamc.rc. Copy the template to the /etc directory.

[root@bigboy tmp]# cp /etc/mail/spamassassin/spamassassin-spamc.rc /etc/procmailrc

Configuring Spamassassin

The spamassassin configuration file is named /etc/mail/spamassassin/local.cf. A full listing of all the options available in the local.cf file can be found in the Linux man pages using the following command:

[root@bigboy tmp]# man Mail::SpamAssassin::Conf

You can customize this fully commented sample configuration file to meet your needs.

###################################################################
# See 'perldoc Mail::SpamAssassin::Conf' for
# details of what can be adjusted.
###################################################################
 
#
# These values can be overridden by editing
# ~/.spamassassin/user_prefs.cf (see spamassassin(1) for details)
#
 
# How many hits before a message is considered spam. The lower the
# number the more sensitive it is.
 
required_hits           5.0
 
 
# Whether to change the subject of suspected spam (1=Yes, 0=No)
rewrite_subject         1
 
 
# Text to prepend to subject if rewrite_subject is used
subject_tag             *****SPAM*****
 
 
# Encapsulate spam in an attachment (1=Yes, 0=No)
report_safe             1
 
 
# Use terse version of the spam report (1=Yes, 0=No)
use_terse_report        0
 
 
# Enable the Bayes system (1=Yes, 0=No)
use_bayes               1
 
 
# Enable Bayes auto-learning (1=Yes, 0=No)
auto_learn              1
 
 
# Enable or disable network checks (1=Yes, 0=No)
skip_rbl_checks         0
use_razor2              1
use_dcc                 1
use_pyzor               1
 
 
# Mail using languages used in these country codes will not be marked
# as being possibly spam in a foreign language.
# - english
 
ok_languages            en
 
 
# Mail using locales used in these country codes will not be marked
# as being possibly spam in a foreign language.
 
ok_locales              en

Be sure to restart spamassassin for your changes to take effect.

Testing spamassassin

You can test the validity of your local.cf file by using the spamassassin command with the --lint option. This will list any syntax problems that may exist. In this example two errors were found and corrected before the command was run again.

[root@bigboy tmp]# spamassassin -d --lint
Created user preferences file: /root/.spamassassin/user_prefs
config: SpamAssassin failed to parse line, skipping: use_terse_report        0
config: SpamAssassin failed to parse line, skipping: auto_learn              1
lint: 2 issues detected.  please rerun with debug enabled for more information.
[root@bigboy tmp]# vi /etc/mail/spamassassin/local.cf
...
...
...
[root@bigboy tmp]# spamassassin -d --lint
[root@bigboy tmp]

Startup spamassassin

The final steps are to configure spamassassin to start on booting and then to start it.

[root@bigboy tmp]# chkconfig spamassassin on
[root@bigboy tmp]# service spamassassin start
Starting spamd: [  OK  ]
[root@bigboy tmp]#

Tuning spamassassin

You can tune the sensitivity of spamassassin to the type of spam you receive by adjusting the required_hits value in the local.cf file. This can be made easier by viewing the score spamassassin assigns a message in its header. In most GUI based email clients this can be done by looking at the email's properties. In this case, a Nigerian email scam spam was detected and given a score of 20.1 and marked as spam.

X-Spam-Status: Yes, score=20.1 required=2.1 tests=DEAR_FRIEND,
	DNS_FROM_RFC_POST,FROM_ENDS_IN_NUMS,MSGID_FROM_MTA_HEADER,NA_DOLLARS,
	NIGERIAN_BODY1,NIGERIAN_BODY2,NIGERIAN_BODY3,NIGERIAN_BODY4,
	RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_SBL,RISK_FREE,SARE_FRAUD_X3,
	SARE_FRAUD_X4,SARE_FRAUD_X5,US_DOLLARS_3 autolearn=failed 
	version=3.0.4
X-Spam-Report: 
	*  0.5 FROM_ENDS_IN_NUMS From: ends in numbers
	*  0.2 RISK_FREE BODY: Risk free.  Suuurreeee....
	*  0.4 US_DOLLARS_3 BODY: Mentions millions of $ ($NN,NNN,NNN.NN)
	*  0.8 DEAR_FRIEND BODY: Dear Friend? That's not very dear!
	*  2.2 NA_DOLLARS BODY: Talks about a million North American dollars
	*  1.8 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
	*      [Blocked - see <>]
	*  1.1 RCVD_IN_SBL RBL: Received via a relay in Spamhaus SBL
	*      [213.185.106.3 listed in sbl-xbl.spamhaus.org]
	*  1.4 DNS_FROM_RFC_POST RBL: Envelope sender in postmaster.rfc-ignorant.org
	*  1.9 NIGERIAN_BODY3 Message body looks like a Nigerian spam message 3+
	*  2.9 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+
	*  1.4 NIGERIAN_BODY4 Message body looks like a Nigerian spam message 4+
	*  1.7 SARE_FRAUD_X5 Matches 5+ phrases commonly used in fraud spam
	*  0.5 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+
	*  1.7 SARE_FRAUD_X3 Matches 3+ phrases commonly used in fraud spam
	*  1.7 SARE_FRAUD_X4 Matches 4+ phrases commonly used in fraud spam
	*  0.0 MSGID_FROM_MTA_HEADER Message-Id was added by a relay

Limiting your spam fighting efforts to the required_hits value isn't usually adequate. You will probably need additional spamassassin tools to be more selective and accurate in your tests. This will be covered next.

The Rules du Jour Spamassassin Tool

There are groups of open source developers that create and update customized spamassassin configuration files that make the tool even more effective. They have even made life easier for the harried systems administrator by creating a script named rules_du_jour that, on a daily basis, will automatically download the rules you select.

The rules_du_jour script can be downloaded from its website at  which has easy to understand installation instructions, but there are some caveats which need to be explained.

The /etc/rulesdujour/config Configuration File

Rules du Jour's configuration file located at /etc/rulesdujour/config has four variables that need to be defined. Each must be enclosed in quotation marks.

The first is SA_DIR, which defines the directory in which you have installed spamassassin. The second is MAIL_ADDRESS which defines the address to which Rules du Jour sends its status messages. The third, SA_RESTART, is the command to be used to restart spamassassin each time the rules_du_jour script is run.

The final parameter, TRUSTED_RULESETS, is the most complicated. It is a space delimited list of all the rules you wish to use. A full list can be found on the Rules du Jour website but there isn't much explanation about what they do and how sensitive each one is to marking email as being spam. Fortunately, you can get this information from the "Rules" section of the Rules Emporium site ().

It is important to read the notes for each rule they sometimes have sub-groupings of rules that may more suitable for your needs. For example, the SARE_HTML rule includes all the rules in SARE_HTML0, SARE_HTML1, SARE_HTML2, SARE_HTML3 and SARE_HTML_ENG, but according to Rules Emporium, only SARE_HTML0 has a low degree of false positives.

Here is a sample of a /etc/rulesdujour/config configuration file that has taken advantage of some of the more popular and reliable rules.

#
# File: /etc/rulesdujour/config
#

#
# Script information can be found at:
#
# 
#

SA_DIR="/etc/mail/spamassassin"
MAIL_ADDRESS="[e-mail]"
SA_RESTART="service spamd restart"
TRUSTED_RULESETS="TRIPWIRE SARE_ADULT SARE_OBFU SARE_URI0 SARE_URI1 ANTIDRUG SARE_SPOOF SARE_BAYES_POISON_NXM SARE_OEM SARE_RANDOM SARE_FRAUD SARE_HEADER0 SARE_HEADER2 SARE_HTML0 SARE_SPECIFIC SARE_BML SARE_GENLSUBJ0 SARE_GENLSUBJ2 SARE_WHITELIST"

Note: The Rules du Jour and Rules Emporium sites use the terms "spam" and "ham" frequently. Spam is unwanted email, while ham is the opposite.

Installing Rules du Jour

Installation is fairly simple, here is how it is done:

1) Download the rules_du_jour script with the wget command, make it executable and place it in the /usr/local/bin directory.

[root@bigboy tmp]# wget 
--10:58:27--  
           => `rules_du_jour'
Resolving sandgnat.com... 208.42.148.125
Connecting to sandgnat.com|208.42.148.125|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 63,448 (62K) [application/octet-stream]
10:58:28 (79.59 KB/s) - `rules_du_jour' saved [63448/63448]

[root@bigboy tmp]# chmod 700 rules_du_jour 
[root@bigboy tmp]# mv rules_du_jour /usr/local/bin

2) Create and edit your /etc/rulesdujour/config configuration file.

[root@bigboy tmp]# mkdir -p /etc/rulesdujour
[root@bigboy tmp]# vi /etc/rulesdujour/config

3) Run the rules_du_jour script, and then run spamassassin in lint mode to test for errors. There should be none.

[root@bigboy tmp]# /usr/local/bin/rules_du_jour 
exec: curl -w %{http_code} --compressed -O -R -s -S -z /etc/mail/spamassassin/RulesDuJour/rules_du_jour  2>&1
curl_output: 304

------ TRIPWIRE ------
RULESET_NAME=TRIPWIRE
INDEX=0
CF_URL=
...
...
...

/^\s*#.*(vers?|version|rev|revision)[:\.\s]*[0-9]/i;' | sort | tail -n 1
CF_MUNGE_SCRIPT=
[root@bigboy tmp]# spamassassin -d --lint
[root@bigboy tmp]#

4) The final step is to add /usr/local/bin/rules_du_jour to your cron table. In this case, I have just created the file /etc/cron.d/rulesdujour with the following entry:

#
# Get latest SpamAssassin rules. Runs at 12:23AM every day.
#
0 23 * * *      root    /usr/local/bin/rules_du_jour

5) You may have to restart crond to get this configuration to become active

[root@bigboy tmp]# service crond restart
Stopping crond: [  OK  ]
Starting crond: [  OK  ]
[root@bigboy tmp]#

My experience with Rules du Jour has been very good. Without it, I could only set the required_hits value in the /etc/mail/spamassassin/local.cf file to a relatively insensitive value of 4.5. Anything lower would create too many false positives and valuable mail would be marked as being suspicious. Rules du Jour selectively raises the score of specific types of spam such that I can make the required_hits setting have a very sensitive value of 2.1 with very few false positives.

Using Greylisting

To maximize the effect of their efforts, spammers try to send email as quickly as possible. They take note of the emails that bounce, so that they know which addresses to remove from their lists to make their next mailing more efficient.

When mail servers receive mail too rapidly for them to handle, they can ask the sender to try again later. Spammers often view resending emails to valid addresses as a waste of computing time that could be used to send mail to brand new addresses that belong to faster mail servers. Emails that need to be resent are usually abandoned.

Some emails need reliable delivery to be effective and the senders of these types of messages are willing to resend. These include bank statement notifications, ecommerce purchase confirmations, and subscription newsletters.

In a previous section we saw where spamassassin always rejects emails from blacklisted sources. With greylisting, sources are just asked to resend. One of the most popular greylist mail filter (milter) products is the milter-greylist package which also works seamlessly with spamassassin. It is easy to use and I’ll discuss how can be configured on your mail server.

Downloading and Installing milter-greylist

Installing milter-greylist is relatively simple, but there are a lot of steps. Here’s how to do it:

1. You will have to first install the sendmail-devel software package. Most RedHat and Fedora Linux software products are available in the RPM format. When searching for the RPMs, remember that the filename usually starts with the software package name and is followed by a version number, as in sendmail-devel-8.13.1-2.rpm. 

2. The next step is to download the milter-greylist tar file which you can download from the milter’s website at . In this case we download the version 2.0.2 file using the wget command.

[root@bigboy tmp]# wget 
--10:48:06--  
           => `milter-greylist-2.0.2.tgz'
Resolving ftp.espci.fr... 193.54.82.47
Connecting to ftp.espci.fr|193.54.82.47|:21... connected.
Logging in as anonymous ... Logged in!
=> SYST ... done.    => PWD ... done.
=> TYPE I ... done.  => CWD /pub/milter-greylist ... done.
=> PASV ... done.    => RETR milter-greylist-2.0.2.tgz ... done.
Length: 116,459 (114K) (unauthoritative)
10:48:20 (70.79 KB/s) - `milter-greylist-2.0.2.tgz' saved [116459]
[root@bigboy tmp]#

3. Now that you have the file, you’ll have to extract the contents using the tar command.

[root@bigboy tmp]# tar -xzvf milter-greylist-2.0.2.tgz 
milter-greylist-2.0.2
milter-greylist-2.0.2/ChangeLog
milter-greylist-2.0.2/Makefile
milter-greylist-2.0.2/Makefile.in
milter-greylist-2.0.2/README
…
…
…
milter-greylist-2.0.2/spf.h
milter-greylist-2.0.2/sync.c
milter-greylist-2.0.2/sync.h
[root@bigboy tmp]# 

4. Now enter the newly created milter-greylist directory and compile the package with the configure command. Take a look at the README file before doing this as there may be some additional options you require, but for most cases the defaults are sufficient.

[root@bigboy milter-greylist-2.0.2]# ./configure && make && make install
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
...
...
...
/usr/bin/install -c -d -m 755 /etc/mail
test -f /etc/mail/greylist.conf -o -f /etc/mail/greylist.except || \
     /usr/bin/install -c -m 644 greylist.conf /etc/mail
/usr/bin/install -c -d -m 755 -o root /var/milter-greylist
[root@bigboy milter-greylist-2.0.2]#

The next step is to configure the package, which will be covered next.

Configuring milter-greylist

Configuring milter-greylist requires these four quick steps:

1. Add the milter-greylist statements listed in the README file to your /etc/mail/sendmail.mc file:

INPUT_MAIL_FILTER(`greylist',`S=local:/var/milter-greylist/milter-greylist.sock')
define(`confMILTER_MACROS_CONNECT', `j, {if_addr}')
define(`confMILTER_MACROS_HELO', `{verify}, {cert_subject}')
define(`confMILTER_MACROS_ENVFROM', `i, {auth_authen}')
define(`confMILTER_MACROS_ENVRCPT', `{greylist}')

2. There will be a number of shell scripts in the milter-greylist tar directory that correspond to various versions of Linux. Copy the correct version to your /etc/init.d directory and use the chkconfig command to make sure the milter starts on the next reboot.

[root@bigboy milter-greylist-2.0.2]# cp rc-redhat.sh /etc/init.d/milter-greylist
[root@bigboy milter-greylist-2.0.2]# chmod 755 /etc/init.d/milter-greylist 
[root@bigboy milter-greylist-2.0.2]# chkconfig --add milter-greylist
[root@bigboy milter-greylist-2.0.2]# chkconfig milter-greylist on
[root@bigboy milter-greylist-2.0.2]# chkconfig --list | grep milter
milter-greylist 0:off   1:off   2:on    3:on    4:on    5:on    6:off
[root@bigboy milter-greylist-2.0.2]#

3. Edit the /etc/mail/greylist.conf configuration file. Here we set the “try again later” to five minutes and use the whitelist command to deactivate the timer for trusted networks so that mail is delivered immediately.

#
# File: /etc/mail/greylist.conf
#

# How long a client has to wait before we accept
# the messages it retries to send. Here, 1 hour.
#
greylist 5m

#
# Whitelist addresses within my own home/office network
#
acl whitelist addr 192.168.0.0/16

4. Start the milter with the service command.

[root@bigboy milter-greylist-2.0.2]# service milter-greylist start 
Starting Milter-Greylist: [  OK  ]
[root@bigboy milter-greylist-2.0.2]#

Your new spam mitigation tool should now be fully functional. Delete the mister-greylist directory in /tmp and you should be ready to go!

Configuring milter-greylist

Now that we have milter-greylist installed, we need to be able to do some basic troubleshooting. The /var/log/maillog file should be used to determine what is happening to your mail. Here are two samples of what to expect:

Dec 24 00:32:31 bigboy sendmail[28847]: jBO8WVnG028847: Milter: to=, 
reject=451 4.7.1 Greylisting in action, please come back in 00:05:00

Dec 23 20:40:21 bigboy milter-greylist: jBO4eF2m027418: addr 211.115.216.225 from 
 rcpt : autowhitelisted for 24:00:00

In the first entry, the email received is given a tag (jBO8WVnG028847) based on key characteristics in the mail header and a request is sent to the sender to resend the email in five minutes. Any email that is received with the same calculated key within the autowhite period configured in the greylist.conf file will then be automatically accepted without delay. In the second entry, the email has been resent and immediately accepted. Any other email from that source within the next 24 hours will be accepted without delay.

Note: Greylisting is very effective, but you will have to tne its operation to make sure critical emails are not delayed at all. One soluton is to set the autowhite period in /etc/mail/greylist.conf to slightly more than 24 hours especially if you get mail from certain recipients, such as newsletters, on a daily basis. This makes them arrive without interruption.

A Simple PERL Script To Help Stop SPAM

Blacklists won't stop everything, but you can limit the amount of unsolicited 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, because sendmail always checks the .forward file in your home directory for the name of this script. The sendmail program 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 e-mail headers and envelopes so you have to download them from CPAN (). 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 e-mail for my home system. A few steps are required to make the script work:

1. Install PERL and the PERL modules you downloaded from CPAN.
2. Place an executable version of the script in your home directory and modify the script's $FILEPATH variable point to your home directory.
3. Update file mail-filter.accept, which specifies the subjects and e-mail addresses to accept, and file mail-filter.reject, which specifies those to reject.
4. Update your .forward file and place an entry in /etc/smrsh.

Mail-filter first rejects all e-mail based on the reject file and then accepts all mail found in the accept file. It then denies everything else.

For a simple script with instructions on how to install the PERL modules, see Appendix II.

Configuring Your POP Mail Server

Each user on your Linux box will get mail sent to their account's mail folder, but sendmail just handles mail sent to your my-site.com domain. If you want to retrieve the mail from your Linux box's user account using a mail client such as Evolution, 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.

Fedora Linux comes with the easy to use dovecot IMAP/POP server RPM package which requires very little configuration after installation.

Installing Your POP Mail Server

Most RedHat and Fedora Linux software products are available in the RPM format. You will need to make sure that the dovecot software RPM is installed. (Chapter 6, will tell you how.) When searching for the RPMs, remember that the filename usually starts with the software package name by a version number, as in dovecot-0.99.11-1.FC3.4.i386.rpm.

Starting Your POP Mail Server

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

[root@bigboy tmp]# chkconfig dovecot on

To start, stop, and restart dovecot after booting, use

[root@bigboy tmp]# service dovecot start
[root@bigboy tmp]# service dovecot stop
[root@bigboy tmp]# service dovecot restart

Remember to restart the dovecot 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 dovecot process is running with the pgrep command:

[root@bigboy tmp]# pgrep dovecot

You should get a response of plain old process ID numbers:

The /etc/dovecot.conf File

You can define most of dovecot's configuration parameters in the /etc/dovecot.conf file. By default dovecot will act as a server for IMAP, secure IMAP (IMAPS), POP and secure POP (POPS). You can limit this list by editing the protocols line in the /etc/dovecot.conf file and then restarting dovecot for the change to take effect. In the example below dovecot is configured to serve only POP3.

#
# File /etc/dovecot.conf sample
#
 
# Protocols we want to be serving imap imaps pop3 pop3s
#protocols = imap imaps pop3 pop3s
protocols = pop3

You can then use the netstat command to do a simple preliminary test to make sure dovecot is serving POP3 only.

[root@bigboy tmp]# netstat -a | egrep -i 'pop|imap'
tcp        0      0 *:pop3                     *:*                         LISTEN      
[root@bigboy tmp]#

How To Configure Your Windows Mail Programs

All your POP e-mail accounts are really only regular Linux user accounts in which sendmail has deposited mail. You can now configure your e-mail client such as Outlook Express to use your use your new POP/SMTP mail server quite easily. To configure 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.

Next, set your SMTP mail server to be the IP address/domain name of your Linux mail server.

Configuring Secure POP Mail

If you need to access your e-mail from the mail server via the Internet or some other insecure location, you may want to configure POP to work over an encrypted data channel. For this, modify the protocols section of the /etc/dovecot.conf file to include pop3s and then restart dovecot. Encrypted POP runs on TCP port 995, so firewall rules may need to be altered as well.

Most POP clients support secure POP. For example, Windows configures it in the Advanced menu of the Outlook Express Account Configuration window.

How to handle overlapping email addresses.

If you have user overlap, such as John Smith ([e-mail]) and John Brown ([e-mail]), both users will get sent to the Linux user account john by default. You have two options for a solution:

• Make the user part of the email address different, [e-mail] and

[e-mail] for example, and 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 and point virtusertable entries for [e-mail] to account john1 and point [e-mail] entries to account john2. The POP configuration in Outlook Express for each user should retrieve their mail via POP using john1 and john2, respectively.

With this trick you'll be able to handle many users belonging to multiple domains without many address overlap problems.

Troubleshooting POP Mail

The very first troubleshooting step is to determine whether your POP server is accessible on the POP TCP port 110 or the secure POP port of 995. Lack of connectivity could be caused by a firewall with incorrect permit, NAT, or port forwarding rules to your server. Failure could also be caused by the xinetd process being stopped or the configuration files being disabled. Test this from both inside your network and from the Internet. (Troubleshooting TCP with TELNET is covered in Chapter 4,

Linux status messages are logged to the file /var/log/messages. Use it to make sure all your files are loaded when you start xinetd. Check your configuration files if it fails to do so. This example starts xinetd and makes a successful secure POP query from a remote POP client: 

Aug 11 23:20:33 bigboy xinetd[18690]: START: pop3s pid=18693 from=172.16.1.103
Aug 11 23:20:33 bigboy ipop3d[18693]: pop3s SSL service init from 172.16.1.103
Aug 11 23:20:40 bigboy ipop3d[18693]: Login user=labmanager host=172-16-1-103.my-site.com [172.16.1.103] nmsgs=0/0
Aug 11 23:20:40 bigboy ipop3d[18693]: Logout user=labmanager host=172-16-1-103.my-site.com [172.16.1.103] nmsgs=0 ndele=0
Aug 11 23:20:40 bigboy xinetd[18690]: EXIT: pop3s pid=18693 duration=7(sec)
Aug 11 23:20:52 bigboy xinetd[18690]: START: pop3s pid=18694 from=172.16.1.103
Aug 11 23:20:52 bigboy ipop3d[18694]: pop3s SSL service init from 172.16.1.103
Aug 11 23:20:52 bigboy ipop3d[18694]: Login user=labmanager host=172-16-1-103.my-site.com [172.16.1.103] nmsgs=0/0
Aug 11 23:20:52 bigboy ipop3d[18694]: Logout user=labmanager host=172-16-1-103.my-site.com [172.16.1.103] nmsgs=0 ndele=0
Aug 11 23:20:52 bigboy xinetd[18690]: EXIT: pop3s pid=18694 duration=0(sec)

Conclusion

E-mail is an important part of any Web site, and you need to plan its configuration carefully to make it a seamless part of the Web experience of your visitors. Without it, your Web site won't seem complete.

A fully functioning Web site is just the beginning. It needs to be maintained to reduce the risk of failure and monitored to help detect potential problems. Chapter 22,  discusses many Linux-based tools that you can be use to track the health of your Linux server.