2009 Jul 12 - Sun

Debian Lenny with Sendmail, Dovecot, MailScanner, SpamAssassin: Part 1

I am in the process of migrating and updating my email server to something bigger-better-faster. Last time I built an email server was a number of years ago on a Redhat system. Things have changed since then. During my re-learning process, here are some notes I've made on getting Sendmail and related processes on to a Debian Lenny system.

Once upon a time, Sendmail was the MTA (Message Transfer Agent) of choice. Most Linux operating systems used it by default. Currently it looks as though Exim and Postfix are now the primary choices for an MTA on the Debian flavour of Linux. Well, I can't let my Sendmail books go to waste, so I'm sticking with Sendmail as my MTA. In this installment, I describe some of the bits I needed for getting the Sendmail part installed and partially configured.

For the system, I did a basic install of Debian Lenny 5.0.1. When the package list came up, I unselected everything, including the Email and Standard System choices. That keeps the basic operating system foot print small.

Only a few packages are needed for Sendmail:

apt-get install libsasl2-modules
apt-get install libsasl2-modules-ldap
apt-get install sasl2-bin
apt-get install openssl
apt-get install ca-certificates
apt-get install build-essential
apt-get install libssl-dev
apt-get install libpam-dev
apt-get install sendmail

I had problems with the amd64 version of Debian Lenny 5.0.1 and sendmail. I was able to build everything, but the only thing that didn't work were the 'enhdnsbl' FEATUREs. I'll have to perform the build from scratch to see if I can recreate the problem. For now, just to get things done, I built the server with 32 bit i386 and the enhdnsbl FEATURE is functioning fine. (Note: after having rebuilt this in 32 bit mode and testing the enhdnsbl feature through the course of the build, I find that the problem occures due to the MailScanner requested DAEMON_PARMS setting in sendmail.conf. This problem is discussed further in my installment 4 of this series.)

To enable saslauthd, edit /etc/default/saslauthd and set START=yes (warning). Run '/etc/init.d/saslauthd start'

The package sensible-mda is installed along with sendmail. Sensible-mda is called by the MTA, and will in turn call whichever of the following MDAs that it finds (in this order): procmail, maildrop, deliver, mail.local.

In a previous installation, I used Courier's mail drop program to get messages into a MailDir format directory. It didn't work so well this time (it was very hard to troubleshoot as it turns off debugging information in local delivery mode). Instead, procmail can delivery to Maildir format directories, so I used that instead. To make this work, /etc/procmailrc needs the line DEFAULT=$HOME/Maildir/ .

To get things done the fast easy way, I'm simply storing email in ~/Maildir until I can get an LDAP mechanism up and running.

Maildir folders store email as one file per email. File locking requirements are reduced. Mbox files store all messages in one, possible large, single file.

Just so that the /home directory isn't completely shallow and wide, I edited the /etc/adduser.conf file and changed LETTERHOMES to yes. "The created home directories will have an extra directory - the first letter of the user name. For example: # /home/u/user."

I'll try this out on the next user I create, but I believe that by creating the directory Maildir in /etc/skel, 'touch /etc/skel/Maildir' and doing a 'chmod 740 /etc/skel/Maildir', the directory will automatically be available in the new users directory.

Instead of setting up a bunch of aliases for a bunch of email addresses that default to my standard email address, I created a virtusertable. The first lines provide explicit email address to local user mappings, something like

john@oneunified.net	john

The remainder of the file has entries like:

@oneunified.net		ray

The sendmail.mc file requires a corresponding 'FEATURE(`virtusertable')dnl' line.

I'm getting ahead of my self here, but for testing the configuration, commands can be sent to sendmail by telnet to port 25 or by creating a small test content file and sending a message with a command similar to 'sendmail ray@example.com < test.msg'. Content of test message:

to:Ray Burkholder 
from:Example 
subject:test from tester

test message

dnsbl resource seems to think that SpamHaus is pretty good as a DNS based BlackList source. I had been using a number of different sources, and I needed to make things current as some dnsbl sources have disappeared or turned unreliable. I've ended up using two sources, and spamhaus seems to prevent a very large chunk of spam getting further into my system, ie, a large percentage doesn't make it through the opening shots of the Sendmail pathways.

A DNS based Black List source (dnsbl) works by taking an email originator's ip address a generating a dns query to specialized spam black list site. Based upon the response to the query, mail can be accepted or rejected immediately, without further processing. A return code is simply a loopback address flavour, with an implicit 127.0.0.1 (an empty response) being a sign of a problem free address, and anything with 127.0.0.2 or greater signifying some issue with the address. More info can be found at Spamhaus.

The two dnsbl entries I use are:

dnl FEATURE(`enhdnsbl', `example.com', `"Spam block is hardcoded"', `t')dnl
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"Spam blocked see: http://www.spamhaus.org/query/bl?ip="$&{client_addr}', `t')dnl
FEATURE(`enhdnsbl', `bl.spamcop.net', `"Spam blocked see: http://spamcop.net/bl.shtml?"$&{client_addr}', `t')dnl

Before using a dnsbl, be sure to read, understand, and conform to their terms of service.

To quickly test that the enhdnsbl FEATURE if functioning (assuming you have access to a dns server for example domain example.com):

• choose a machine from which you can telnet to sendmail on port 25
• determine it's ip address, say in this case, 10.23.43.5
• insert a line into the dns server similar to '5.43.23.10.example.com. IN A 127.0.0.2' (the address is backwards)
• uncomment the enhdnsbl FEATURE in the collection of 3 above, rebuild sendmail.cf, and reload sendmal
• telnet to the sendmail server, and you should see a 'ruleset=check_relay, arg1=[10.23.43.5], arg2=127.0.0.2, .... ' type line in mail.log

In the sendmail.mc file, I also disabled 'dnl FEATURE(`delay_checks', `friend', `n')dnl' (if it has been turned on by default) as it will accept a message, check the recipient, then perform the dnsbl lookup. This feature is for when you need to accept someone from a blacklisted address, but no one else. By disabling this, all users from the address are denied. In addition, with the option enabled, the mail.log file will have check_rcpt entries, with it disabled, the mail.log file will have check_relay entries.

To look at messages that have made it through Sendmail, have been locally delivered with procmail, a program called Mutt can be used to read the messages. By default Mutt, can read mbox mail files. A configuration change is required to read Maildir folders. The Mutt FAQ goes into more detail, but the basics are to put the folloing lines into ~/.muttrc:

set mbox_type=Maildir

set spoolfile="~/Maildir/"
set folder="~/Maildir/"
set mask="!^\\.[^.]"
set record="+.Sent"
set postponed="+.Drafts"

Richard Curnow has written a program to index, search, and create links to email messages stored in the Maildir folders.

During testing of my Sendmail configuration, from a email client, I was seeing a messages like the following:

sendmail dsn=5.0.0, stat=Service unavailable
554 5.3.0 rewrite: map access not found

It turned out to be an error in my sendmail.cm configuration file where I was missing a closing single quote. The file that processes a sendmail.mc file to create a sendmail.cf file is not very helpful in tracking down simple errors of syntax such as what caused this problem.

I don't know if it is legal or not, but I found online the Sendmail 3rd Edition. I don't know for how long the link will be valid.