By Kurt Seifried email@example.com
Simple Mail Transfer Protocol (SMTP) is one of the more important services provided by the Internet. Almost all companies now have or rely upon email, and by extensions SMTP servers. There are many SMTP server packages available, the oldest and most tested is Sendmail (now commercially supported, etc.), and there are two new contenders, Postfix and Qmail, both of which were written from scratch with security in mind. Firewalling SMTP is straightforward, it runs on port 25, TCP:
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 25 ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 25 ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 25
ipchains -A input -p tcp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 25 ipchains -A input -p tcp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 25 ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 25
iptables -A INPUT -p tcp -m tcp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 --dport 25 iptables -A INPUT -p tcp -m tcp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 --dport 25 iptables -A INPUT -p tcp -m tcp -j REJECT -s 10.0.0.0/8 -d 0.0.0.0/0 --dport 25
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). As soon as an exploitable 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 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 largely runs as root, rather debatable as to the effectiveness of this (since root can break out of a chroot'ed jail). Newer releases of Sendmail from some vendors run less processes as root, and make it easier to chroot the daemon, however the last hole in Sendmail on Linux was locally exploitable and no amount of chroot or non root would have helped.
Keeping Sendmail up to date is relatively simple, I would recommend minimally version 8.12.x. More information on 8.12.x is available at: http://www.sendmail.org/8.12.1.html. Most distributions ship 8.11.x or 8.12.x, and some vendors also include SMTP auth support, although configuring it can be difficult (it is poorly documented in most cases). You can also get the source from but compiling Sendmail is not for the faint of heart or those that do not have a chunk of time to devote to it (although building a more up to date version via dpkg or rpm is possible without to much black magic). The latest version of sendmail is available from: ftp://ftp.sendmail.org/.
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. Indeed this is the default with Red Hat, Sendmail only listens on localhost, allowing you to receive mail sent locally, and send mail to other systems (however changing this default can be rather annoying).
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
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):
Primary config file, also tells where other config files are.
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 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 file, allows you to control delivery of mail local to the system, useful for backing up incoming users 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.
domain table (adding domains) that you handle, useful for virtual hosting.
configuration file for majordomo, I would personally recommend SmartList over Majordomo.
file containing names of hosts for which we receive email, useful if you host more then one domain.
location of help file (telnet to port 25 and type in "HELP")
Virtual user table, maps incoming users, i.e. maps firstname.lastname@example.org to email@example.com.
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/IPs, 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.:
firstname.lastname@example.org alias-seifried email@example.com 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 firstname.lastname@example.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.
Dynamic Relay Authorization Control
Dynamic Relay Authorization Control (DRAC) ties into your POP/IMAP server to temporarily grant SMTP relay access to hosts that successfully authenticate and pick up mail (the assumption being these hosts will send mail, and not abuse this privilege. You can get it from: http://mail.cc.umanitoba.ca/drac/index.html.
Postfix is a mail transfer agent (MTA) aimed at security, speed, ease of configuration, generally things Sendmail fails miserably at. I would highly recommend replacing Sendmail with Postfix. The only portion of Postfix that runs as root is a master control program, aptly called master, it calls several other programs to process mail to the queue (pickup), a program to manage the queue, wait for incoming connections, deferred mail delivers and so on (qmgr), a program to actually send and receive the mail (smtpd) and so on. Each part of Postfix is very well thought out, and usually does one or two tasks, very well. For example instead of the sendmail model where queued mail simply gets dumped into /var/spool/mqueue, in Postfix there is a world accessible directory called maildrop which is checked by pickup, which feeds the data to cleanup which moves the mail (if its properly formatted and so on) to a secure queue directory for actual processing.
The primary configuration files are held in /etc/postfix, and there are several primary configuration files you must have:
Controls the behavior of the various helper programs, are they chrooted, maximum number of processes they may run and so forth. Its probably best to leave the defaults on most mail servers unless you need to do some tuning for high loads or securing the server (i.e. chrooting it).
This file is as close to sendmail.cf as you will get (for purpose, as for layout its quite different). It is well commented and sets all the major variables, and the locations and format of various files containing information such as virtual user mappings and related information.
Here is a list of variables and file locations you will typically have to set, the /etc/postfix/main.cf file is usually heavily commented. Please note the following examples of main.cf entries are not a complete main.cf.
# what is the machines hostname? myhostname = mail.example.org
# what is the domain name? mydomain = example.org
# what do I label mail as from? myorigin = $mydomain
# which interfaces do I run on? All of them usually. inet_interfaces = all
# a file containing a list of host names and fully qualified domains names I # receive mail for, usually they are listed like: # mydestination = localhost, $myhostname, etc # but I much prefer to keep them listed in a file. mydestination = /etc/postfix/mydestination
# map of incoming usernames. man 5 virtual virtual_maps = hash:/etc/postfix/virtual
# alias mappings (like /etc/aliases in sendmail), man 5 aliases alias_maps = hash:/etc/postfix/aliases
# alias database, you might have different settings. man 5 aliases alias_database = hash:/etc/postfix/aliases
# where to deliver email, Mailbox format or Maildir (traditional /var/spool/mail). home_mailbox = Maildir/
# where to keep mail, usually /var/spool/mail/ but you can easily change it mail_spool_directory = /var/spool/mail
# what command do we use to deliver email? /usr/bin/procmail is the default but if # you want to use scanmail which is the AMaViS anti-virus tie in software simply put: mailbox_command = /usr/sbin/scanmails
# who do I relay email for, again you can list them, or keep them in a file (one # per line). relay_domains = /etc/postfix/relaydomains
# list of local networks (by default we relay mail for these hosts). mynetworks = 10.0.0.0/24, 127.0.0.0/8
# what do we display to people connecting to port 25? By default it displays the # version number which I do not. smtpd_banner = $myhostname ESMTP $mail_name
Generally speaking any files that simply list one item per line (like /etc/postfix/mydestination or /etc/postfix/relaydomains) are usually just stored as a flat text file. Files that contain mappings (i.e. aliases, where you have entries like root: someuser) should be turned into hashed database files for speed (you can specify the type of file as hash, dbm, etc.).
Like most IBM products, Postfix has a very funky license, but appears to be mostly open source and free. Postfix is available at: http://www.postfix.org/. You can get binary postfix packages from a numer of sources including most Linux vendors.
Sendmail Pro is a commercial version of Sendmail with support, and is available at: http://www.sendmail.com/. I havent been able to get a demo or find anyone using it so Im not 100% sure as to how close it is to the original Sendmail, although the company has told me it uses the same code base.
Qmail (like postfix) was created as a direct response to perceived flaws in Sendmail. Qmail is not under an OpenSource approved license, and there is no binary distribution clause meaning you must install it from source code. OpenBSD has removed Qmail from ports due to numerous conflicts with the license, and I do not reccomend using Qmail as vendor support is non-existant. Very little code in Qmail runs as root, and it is very modular compared to Sendmail (which is a pretty monolithic piece of code). You can download it from: http://www.qmail.org/. An excellent book is available for free at: http://www.lifewithqmail.org/.
Zmailer is a GPL mailer available at: http://www.zmailer.org/. It has crypto hooks and generally looks like it is well built.
DMail is a commercial mail server, and is not open source. You can download a trial version from: http://netwinsite.com/dmail_first.htm.
nullmailer sends mail to smart hosts (relays) so that the local machine doesn't have to run any mail server software. It's at: http://em.ca/~bruceg/nullmailer/.
POP (post Office Protocol) is a relatively simple protocol that allows you to retrieve email from a server and delete it. The basic commands are USER, PASS (used to login), LIST (to list emails and sizes), RETR (to retrieve and email) and DELE (to delete an email).
POP and IMAP are fundamentally related but very different, so I have split them apart. POP stands for Post Office Protocol and simply allows you to list messages, retrieve them, and delete them. There are many POP servers for Linux available, the stock one that ships with most distributions is ok for the majority of users. The main problems with POP are similar to many other protocols; usernames and passwords are transmitted in the clear, making it a very good target for packet sniffing. POP can be SSLified, however not all mail clients support SSL secured POP. Most POP servers come configured to use TCP_WRAPPERS, which is an excellent method for restricting access. Please see the earlier section on TCP_WRAPPERS for more information. POP runs as root (since it must access user mailboxes) and there have been a number of nasty root hacks in various POP servers in the past. POP runs on ports 109 and 110 (109 is basically obsolete though), using the tcp protocol. The Washington University IMAPD server also comes with a pop server and is generally the stock pop server that ships with most Linux distributions. You can get it from: http://www.washington.edu/imap/.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 110 ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 110 ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 110
ipchains -A input -p tcp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 110 ipchains -A input -p tcp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 110 ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 110
Cyrus is an imap (it also supports pop and kpop) server aimed at closed environments. That is to say that the users will not have any access to the mail server other then by imap or pop protocols. This allows Cyrus to store the mail in a much more secure manner and allows for easier management of larger installations. Cyrus is not GNU licensed but is relatively free, and available from: http://asg.web.cmu.edu/cyrus/imapd/.
IDS (It Doesnt Suck) POP is a lighter popd replacement aimed at smaller installations. It is GPL and available from: http://www.nodomainname.net/software/ids-pop/.
Qpopper is freeware produced by Qualcomm (the makers of Eudora). I would not recommend it (the source code is available at: ftp://ftp.qualcomm.com/eudora/servers/unix/popper/). You can get it from: http://eudora.qualcomm.com/freeware/qpop.html.
IMAP is a much more advanced mail protocol, allowing you to retrieve email from the server, and manage it on the server (you can create folders to store messages on the server). This protocol is much more useful then POP since multiple email boxes are a bit more graceful, multiple people using one email box is workable, and for travelling users, since you download the headers first (subject, etc) and can more selectively retrieve email.
IMAP is POP on steroids. It allows you to easily maintain multiple accounts, have multiple people access one account, leave mail on the server, just download the headers, or bodies and no attachments, and so on. IMAP is ideal for anyone on the go or with serious email needs. The default POP and IMAP servers that most distributions ship (bundled together into a single package named imapd oddly enough) fulfill most needs.
IMAP also starts out as root, although imapd typically drops to the privilege of the user accessing it, and cannot be easily set to run as a non-root user since they have to open mailboxes (and in IMAPs case create folders, files, etc. in the users home directory), so they cannot drop privileges as soon as one would like. Nor can they easily be chroot'ed (IMAP needs access to /var/spool/mail, and IMAP needs access to the users home directory). The best policy is to keep the software up to date. And if at all possible, firewall pop and imap from the outside world, this works well if no-one is on the road and needs to collect their email via the Internet. University Washington (UW) IMAPD is available from: http://www.washington.edu/imap/.
IMAP runs on port 143 and most IMAPD servers support TCP_WRAPPERS, making it relatively easy to lock down.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 143 ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 143 ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 143
ipchains -A input -p tcp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 143 ipchains -A input -p tcp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 143 ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 143
Cyrus is an imap (it also supports pop and kpop) server aimed at closed environments. That is to say that the users will not have any access to the mail server other then by imap or pop protocols. This allows Cyrus to store the mail in a much more secure manner and allows for easier management of larger installations, and I highly recommend it. Cyrus is not GNU licensed but is relatively free, and available from: http://asg.web.cmu.edu/cyrus/imapd/. There is also a set of add on tools for Cyrus available from: ftp://ftp.hr.vc-graz.ac.at/cyrus-tools/.
Courier-IMAP is a lightweight IMAP server specifically for use with Maildir style mailboxes (not /var/spool/mail). You can get it from: http://www.inter7.com/courierimap/.
While Linux is not terribly suspectible to viruses, Windows clients are.
http://protector.sourceforge.net/ blocks all attachments except those listed (i.e.a white list).
AMaViS uses third party scanning software (such as McAfee) to scan incoming email for viruses. You can get AMaViS at: http://www.amavis.org/. Make sure you get the latest version, previous ones have a root compromise.
Using AMaViS with Sendmail is relatively simple, it has a program called scanmail that acts as a replacement for procmail (typically the program that handles local delivery of email). When an email comes in instead of using procmail to deliver it, Sendmail calls scanmail which decompresses and decodes any attachments/etc. and then uses a virus scanner (of your choice) to scan the attachments. If no virus is found mail delivery goes ahead as usual. If a virus is found however, an email is sent to the sender informing them that they have sent a virus, and an email is sent to the intended recipient informing them about the person that sent them a virus. The instructions for this are at: http://www.amavis.org/
Since Postfix can make use of procmail to do local mail delivery it should work in theory without any trouble. In practice it takes a few minor tweaks to work correctly. To enable it replace the line in main.cf:
mailbox_command = /usr/bin/procmail
with the line:
mailbox_command = /usr/sbin/scanmails
and restart postfix. For the local warning to work (a warning is sent to the intended recipient of the message) the hostname of the machine (sundog, mailserver01, etc.) must be listed in the mydestination in main.cf, otherwise the warning does not get delivered. You should (and most sites generally do) redirect roots email to a user account using the aliases file, otherwise warnings will not be delivered to root properly. By default as well mail to virusalert is directed to root, you should also redirect this mail to a normal user account.
procmail (the default local delivery agent typically) has a wide variety of features that can be used to help "sanitize" email. More information on this is available at: ftp://ftp.rubyriver.com/pub/jhardin/antispam/procmail-security.html.
simap stream tcp nowait root /usr/sbin/stunnel imapd -l imapd
RANDFILE = stunnel.rnd [ req ] default_bits = 1024 encrypt_key = no distinguished_name = req_dn x509_extensions = cert_type [ req_dn ] countryName = Country Name (2 letter code) organizationName = Organization Name (eg, company) 0.commonName = Common Name (FQDN of your server) [ cert_type ] nsCertType = server
openssl req -new -x509 -days 365 -config /etc/stunnel.cnf -out /etc/stunnel.pem -keyout stunnel.pem openssl x509 -subject -dates -fingerprint -noout -in stunnel.pem
Note on Outlook express, you cannot view certificates, and as long as it is for the right site and the date is correct it will be accepted (it can be signed by anyone).
Netscape walks you through the traditional certificate dialog and self signed certs will generate a warning.
for links to download all the patches and the source tarball. If you
decide to install the patches, please do read the release notes first:
Currently the SourceForge and www.list.org sites are up-to-date, and I
expect the gnu.org site to be updated soon.
I've also included links on the FAQ page to the Mailman FAQ wizard.
Thanks everybody for contributing good entries! (I may do some reorg
when I get a chance.) See the FAQ wizard at
Last updated on 1/9/2001
Copyright Kurt Seifried 2001 email@example.com