Title: Sendmail mail server

KBTAG: kben10000144
URL: http://www.securityportal.com/lskb/10000100/kben10000144.html
Date created: 08/08/2000
Date modified:
Date removed:
Authors(s): Kurt Seifried seifried@securityportal.com
Topic: Sendmail mail server
Keywords: Network/Email

Summary:

Sendmail is another one of those services most of us have a love/hate relationship with. We hate to admin it and we'd love to replace it (actually I have started removing Sendmail from machines I admin and replacing it with Postfix). 

More information:

Sendmail has earned itself a very bad reputation for security, however I find it hard to blame software when I find systems running ancient versions of Sendmail. The root of the problem (if you'll pardon a bad pun) is that almost everyone runs Sendmail as root (and something like %70 of Internet email is handled by Sendmail machines, so there are a lot of them), so as soon as a bug is found, finding a system to exploit it on is not all that hard. The last few releases of Sendmail have been quite good, no root hacks, etc, and with the new anti spam features Sendmail is finally to come of age. More information on Sendmail and source code is available from: http://www.sendmail.org/.

Chroot'ing Sendmail is a good option, but a lot of work, and since it runs as root, rather debatable as to the effectiveness of this (since root can break out of a chrooted jail). I personally think switching to Postfix or Qmail is a better expenditure of effort. 

Keeping Sendmail up to date is relatively simple, I would recommend minimally version 8.9.3 (the 8.9 series has more anti-spam features, 8.8.x has most of these features as well assuming you have a properly setup sendmail.cf). Most distributions ship 8.8.x, although the newer releases are generally shipping the 8.9.x. You can also get the source from ftp://ftp.sendmail.org/, but compiling Sendmail is not for the faint of heart or those that do not have a chunk of time to devote to it.

Sendmail only needs to be accessible from the outside world if you are actually using it to receive mail from other machines and deliver the mail locally. If you only want to run Sendmail so that local mail delivery works (i.e. a stand alone workstation, test server or other) and so mail can easily be sent to other machines, simply firewall off Sendmail, or better, do not run it in daemon mode (where it listens for connections). Sendmail can be run in a queue flushing node, where it simply 'wakes' up once in a while and processes local mail, either delivering it locally, or sending it off on its way across the 'net. To set Sendmail to run in queue mode:

edit your Sendmail startup script
and change the line that has:

sendmail -bd -q1h

to:

sendmail -q1h

Please note: if you use your system to send lots of email you may wish to set the queue flush time lower, perhaps “-q15m” (flush the queue every 15 minutes) now outbound and system internal mail will behave just fine, which unless you run a mail server, is perfect.

Now for all those wonderful anti-spam features in sendmail. Sendmail's configuration files consist of (this applies to Sendmail 8.9.x):

/etc/sendmail.cf 
Primary config file, also tells where other config files are.

/etc/mail/
You can define the location of configuration files in sendmail.cf, typically people place them in /etc/ or /etc/mail/ (which makes it a little less cluttered).

access
Access list database, allows you to reject email from certain sources (IP or domain), and control relaying easily. My access file looks like this:

10.0.0 RELAY
spam.com REJECT

which means 10.0.0.* (hosts on my internal network) are allowed to use the email server to send email to wherever they want, and that all email to or from *.spam.com is rejected. There are lists online of known spammers, typically they are 5-10,000 entries long, this can seriously impede sendmail performance (as each connection is checked against this list), on the other hand having your sendmail machine used to send spam is even worse.

aliases 
aliases file, allows you to control delivery of mail local to the system, useful for backing up incoming user’s email to a separate spool. Most list serve software uses this file to get mail sent to lists delivered to the programs that actually process them. Remember to run the command “newaliases” after editing this file, and to then restart sendmail.

domaintable 
domain table (adding domains) that you handle, useful for virtual hosting.

majordomo
configuration file for majordomo, I would personally recommend SmartList over Majordomo.

sendmail.cw
file containing names of hosts for which we receive email, useful if you host more then one domain.

sendmail.hf
location of help file (telnet to port 25 and type in "HELP")

virtusertable 
Virtual user table, maps incoming users, i.e. maps sales@example.org to john@example.org.

Sendmail 8.9.x (and previous versions) do not really support logging of all email very nicely (something required in today's world for legal reasons by many companies). This is one feature being worked on for the release of Sendmail 8.10.x. Until then there are 2 ways of logging email, the first is somewhat graceful and logs email coming IN to users on a per user basis. The second method is not graceful and involves a simple raw log of all SMTP transactions into a file, you would have to write some sort of processor (probably in Perl) to make the log useful.

Mail (incoming SMTP connections to be more precise) is first filtered by the access file, in here we can REJECT mail from certain domains/IP’s, and RELAY mail from certain hosts (i.e. your internal network of windows machines). Any local domains you actually host mail for will need to go into sendmail.cw. Assuming mail has met the rules and is queued for local delivery the next file that gets checked is virtusertable, this is a listing of email addresses mapped to the account name/other email address. i.e.:

seifried@seifried.org alias-seifried
listuser@seifried.org listuser
@seifried.org mangled-emails

The last rule is a catch all so mangled email addresses do not get bounced, and instead sent to a mailbox. Then the aliases file is checked, if an entry is found it does what it says to, otherwise it attempts to deliver the mail to a local users mailbox, my aliases file entry for seifried is:
alias-seifried: seifried, "/var/backup-spool/seifried"

This way my email gets delivered to my normal mailbox, and to a backup mailbox (in case I delete an email I really didn't mean to), or as a worst case scenario, Microsoft Outlook decides to puke someday and hose my mailboxes. This would also be useful for corporations, as you now have a backup of all incoming email on a per user basis, and can allow them (or not) to access the file containing the backed-up mail.

One caveat, when using a catch-all rule for a domain (i.e. @seifried.org) you must create an alias for EACH account, and for mailing lists. Otherwise when it looks through the list and doesn't find a specific entry (for say mailing-list@seifried.org) it will send it to the mailbox specified by the catch all rule. For this reason alone you might not wish to use a catch all rule.

The second method is very simple, you simply start sendmail with the -X option and specify a file to log all transactions to. This file will grow very large very quickly, I would NOT recommend using this method to log email unless you absolutely must.

References:

http://www.sendmail.net/