This is an old revision of the document!
We chose Postfix due to its modern design and security record. It also has a license that we can live with more easily than qmail.
The SLUUG sysadmins were divided on whether to use Postfix or Sendmail. Most of the admins more familiar with Linux prefer Postfix; most of the admins used to older UNIX systems would have preferred to use Sendmail. The 2 factors that slightly tipped the scales toward Postfix were the available documentation on setting up many of the features we want, and the preference of the people who installed it.
Install the package:
apt-get install postfix
You will (probably) be presented with some instructions. Hit OK
after reading the instructions, then select No configuration
, as we'll be configuring manually.
All Postfix configuration options are detailed in the postconf(5) man page.
The postconf utility won't create a config file if it doesn't exist, so create it manually:
touch /etc/postfix/main.cf
Set the host and domain names:
postconf -e "myhostname=`hostname -f`" postconf -e "mydomain=`hostname -d`"
Tell the SMTP server what domains to accept email for. Do NOT list any VIRTUAL domains here. The distinguishing feature of non-virtual domains (the ones listed here) is that any real user ID that exists on the box (or is listed in the aliases file) is a valid address in the domain. The valid addresses in a virtual domain have to be explicitly listed in the virtual alias map.
postconf -e 'mydestination=test.sluug.org, $mydomain, $myhostname, localhost, woodlandchows.com, \ cab3.dyndns.org, buchek.com, craigbuchek.com, boochtek.com'
Set the domain name to add for any addresses that are not specified:
postconf -e 'myorigin=$mydomain'
Denote which systems can send outbound email (without having to authenticate). We're including the subnets of all SLUUG systems – at Primary and at Wash U. We also include a separate file to list any additional IPs that are allowed to relay through us. See the Relay section below.
postconf -e 'mynetworks=127.0.0.0/8, 206.196.99.160/28, 128.252.19.0/27, hash:/etc/postfix/mynetworks'
Set what the SMTP server should say when a client connects:
postconf -e 'smtpd_banner=$myhostname ESMTP $mail_name'
Set the mail aliases file. (Note that the aliases file is special in 3 ways: it exists outside the /etc/postfix
directory for historical reasons; it uses a colon (':') to separate the left side from the right; and you use the newaliases
command after updating it, instead of the postmap
command.)
postconf -e 'alias_maps=hash:/etc/aliases' postconf -e 'alias_database=hash:/etc/aliases'
Set maximum sizes for messages (50 MB) and mailboxes (1 GB):
postconf -e 'message_size_limit=50000000' postconf -e 'mailbox_size_limit=1000000000'
Allow email addressed to 'username+foo', so the user can have multiple virtual sub-addresses:
postconf -e 'recipient_delimiter=+'
Have the SMTP server listen on all interfaces:
postconf -e 'inet_interfaces=all'
The Mailman documentation recommends the following setting. It ensures that emails to unknown local addresses will generate a permanent error, not a transient error in which the client will keep re-trying.
postconf -e 'unknown_local_recipient_reject_code=550'
This section configures some settings that will help reject spam due to the behavior of the spam programs. This does not include spam filtering, which rejects spam due to the content (and headers) of the spam messages. That will be covered by a separate program, and the configuration to connect to that program will be covered in a separate section.
First, don't tell the SMTP clients that we're rejecting their message until they've specified the sender and the recipient. This is required by some broken clients, but has several other advantages. First, it wastes more of the spammer's time and resources. Second, it allows us to log the sender and recipient info of all attempted messages.
postconf -e 'smtpd_delay_reject=yes'
Have the SMTP server require a HELO or EHLO command. This is pretty standard.
postconf -e 'smtpd_require_helo=yes'
The next thing we want to do is check the contents of the HELO string. If the connection is from one of our trusted networks, we don't need to perform the check. Next we look at the /etc/postfix/helo_access
file, and perform the action specified in that file for any host names that match a host name in the file. If the host name provided in the HELO command is not a valid FQDN, we reject the connection. If the client tries to use SMTP command pipelining without asking, we reject the connection. Otherwise we permit the connection.
postconf -e "smtpd_helo_restrictions=permit_mynetworks, \ check_helo_access hash:/etc/postfix/helo_access, \ reject_non_fqdn_hostname, reject_invalid_hostname, \ reject_unauth_pipelining, permit"
Now we need to create the /etc/postfix/helo_access
file. We want to reject anyone who sends us our own IP address or host name in the HELO string. Add all your possible IP addresses and host names, so the file looks something like this:
# We want to reject anyone who pretends that they have our address. sluug.org REJECT Attempting to spoof my address! mail.sluug.org REJECT Attempting to spoof my address! bud.sluug.org REJECT Attempting to spoof my address! www.sluug.org REJECT Attempting to spoof my address! 206.196.99.162 REJECT Attempting to spoof my address! 127.0.0.1 REJECT Attempting to spoof my address!
Then create the binary hash file from the text file:
postmap /etc/postfix/helo_access
Next, we want to take a look at the sender's address, unless the sender is on the local network, or they've authenticated themselves via SASL. We want to reject any sender address that's not using a FQDN. (I.e. we reject things like bill@nonfqdnhostname
and bill
.) And we'll also reject the message if the sender's domain does not have an A or MX record in DNS.
postconf -e "smtpd_sender_restrictions=permit_mynetworks, \ permit_sasl_authenticated, reject_non_fqdn_sender, \ reject_unknown_sender_domain, permit"
NOTE: See also the Greylisting section below. It does even more thorough spam avoidance, but it's in a separate section because it requires a separate program.
Whatever we do, we need to make sure that our IMAP server knows where to find the files. By default, Courier IMAP looks in Maildir
in the user's home directory. The Postfix default is to store incoming messages in mbox format in /var/spool/mail, with a file for each addressee.
We start out with the simplest delivery method, storing email messages in maildir format in the user's home directory:
postconf -e 'home_mailbox=Maildir/'
TODO. Consider more featureful delivery.
Email delivery involves passing a message out of Postfix's queues and to a user's inbox. There are 3 ways to configure email delivery: home_mailbox
, mail_spool_directory
, mailbox_command
, or mailbox_transport
.
The first tells Postfix to deliver to an mbox file or maildir in the user's home directory. The second tells Postfix to deliver to an mbox file or a maildir in a shared directory. To use maildir, end the path with a '/'. The third runs an external command, piping the message to the command. The fourth sends the message (via a socket) to a daemon configured in master.cf
.
There are quite a few local delivery agent programs we could choose from:
We could also implement per-user local delivery agents, via .forward
files:
"|/path/to/maildrop -d ${USER}"
or via mailbox_command_maps
:
/etc/postfix/main.cf: mailbox_command_maps = /etc/postfix/mailbox_commands /etc/postfix/mailbox_commands: you /path/to/maildrop -d ${USER}
We need to allow our users to relay through our SMTP server. If all the users had static IP addresses, we could just list them in mynetworks
. Unfortunately, we have some users who have dynamic IP addresses. There are 3 ways to allow these users to send emails out through our server:
The first option is the "Right Thing" to do, but is hard to set up on the client and the server. The second option is moderately easy to set up on the server, and is simple for the client to do. The third option opens us up to spammers, so it's out of the question.
We also have a list of static IPs that we allow to replay through us. These are located in /etc/postfix/mynetworks
. This list of IPs was taken from Dark; we do not have any documentation on who was using them. After a few months of production use, we'll check the logs to see which are still being used, and delete the rest. We'll also try to convert all the users to authenticate via SASL/TLS instead of hard-coding their IPs.
Most of this was stolen from Jimmys Weblog - Postfix and SASL and Postfix SMTP-AUTH 4 DUMMIES. I admit to blatant cut 'n paste.
First install postfix-tls and sasl librarys required for postfix
apt-get install postfix-tls sasl2-bin libsasl2 libsasl2-modules
Edit /etc/default/saslauthd
to enable SASL and ensure we're using PAM:
START=yes MECHANISMS="pam"
Create /etc/postfix/sasl/smtpd.conf
and tell it to use saslauthd
for SMTP authentication:
pwcheck_method: saslauthd mech_list: PLAIN LOGIN
Add SASL configuration directives to /etc/postfix/main.cf
by using postconf -e
postconf -e 'smtpd_sasl_auth_enable=yes' postconf -e 'smtpd_sasl_security_options=noanonymous' postconf -e 'smtpd_sasl_local_domain=$myhostname' postconf -e 'broken_sasl_auth_clients=yes'
To enable TLS SMTP authentication, add these options to /etc/postfix/main.cf
:
postconf -e 'smtpd_use_tls=yes' postconf -e 'smtpd_tls_auth_only=yes'[[Internal Link]] postconf -e 'smtp_tls_cert_file=/etc/ssl/postfix.crt' postconf -e 'smtp_tls_key_file=/etc/ssl/private/postfix.key' postconf -e 'smtpd_tls_cert_file=/etc/ssl/postfix.crt' postconf -e 'smtpd_tls_key_file=/etc/ssl/private/postfix.key'
Add or open the following lines in /etc/postfix/master.cf to allow smtps via port 465.
# Turn smtps on for port 465 smtps inet n - - - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject
Add the following line to /etc/shorewall/rules to open the smtps port in shorewall
ACCEPT net $FW tcp 465
Then restart shorewall
/etc/init.d/shorewall restart
We need to add postfix
to the sasl
group so the Postfix programs can read the SASL files.
chgrp sasl /var/spool/postfix/var/run/saslauthd adduser postfix sasl
We need to set up the Postfix chrooted environment to have access to the /var/run/saslauthd
directory.
rm -rf /var/run/saslauthd mkdir -p /var/spool/postfix/var/run/saslauthd ln -s /var/spool/postfix/var/run/saslauthd /var/run
Check postfix configuration
postfix check
If all is well restart postfix and watch the log
postfix reload ; tail -f /var/log/mail.log
Test the connection and check for TLS reply
telnet bud.sluug.org 25 Trying 206.196.99.162... Connected to bud.sluug.org. Escape character is '^]'. 220 bud.sluug.org ESMTP Postfix helo example.com 250 bud.sluug.org starttls 220 2.0.0 Ready to start TLS exit
After the above instructions and restarting postfix with "postfix reload" added bud.sluug.org as an "Outgoing Server (SMTP)" in Thunderbird. I set it use Authentication.
This gave me these errors:
Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication failure: no secret in database Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: unknown[206.197.251.70]: SASL CRAM-MD5 authentication failed: authentication failure Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication failure: no secret in database Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: unknown[206.197.251.70]: SASL NTLM authentication failed: authentication failure Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication failure: Password verification failed Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: unknown[206.197.251.70]: SASL PLAIN authentication failed: generic failure Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory Jul 25 13:46:11 bud postfix/smtpd[6842]: warning: unknown[206.197.251.70]: SASL LOGIN authentication failed: generic failure Jul 25 13:46:14 bud postfix/smtpd[6842]: lost connection after AUTH from unknown[206.197.251.70]
Seeing "unable to open Berkeley db /etc/sasldb2" shows that it is unable to reach the database at /etc/sasldb from the chroot jail.
cd /var/spool/postfix/etc cp -p /etc/sasldb2 . mv /etc/sasldb2 /etc/sasldb2.`date +%F` ln -s /var/spool/postfix/etc/sasldb2 .
This removed that error. Retrying brougt the errors down to:
Jul 25 13:50:40 bud postfix/smtpd[6845]: warning: SASL authentication failure: no secret in database Jul 25 13:50:40 bud postfix/smtpd[6845]: warning: unknown[206.197.251.70]: SASL CRAM-MD5 authentication failed: authentication failure Jul 25 13:50:40 bud postfix/smtpd[6845]: warning: SASL authentication failure: no secret in database Jul 25 13:50:40 bud postfix/smtpd[6845]: warning: unknown[206.197.251.70]: SASL NTLM authentication failed: authentication failure Jul 25 13:50:40 bud postfix/smtpd[6845]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory Jul 25 13:50:40 bud postfix/smtpd[6845]: warning: SASL authentication failure: Password verification failed Jul 25 13:50:40 bud postfix/smtpd[6845]: warning: unknown[206.197.251.70]: SASL PLAIN authentication failed: generic failure Jul 25 13:50:40 bud postfix/smtpd[6845]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory Jul 25 13:50:40 bud postfix/smtpd[6845]: warning: unknown[206.197.251.70]: SASL LOGIN authentication failed: generic failure
Found this while googling. It said to look for state_dir and make sure either Postfix or saslauthd can access the directory to meet at the place where saslauthd wants to create the socket. :
bud:/var/spool/postfix# saslauthd -d -a shadow saslauthd[7579] :main : num_procs : 5 saslauthd[7579] :main : mech_option: NULL saslauthd[7579] :main : run_path : /var/run/saslauthd saslauthd[7579] :main : auth_mech : shadow saslauthd[7579] :ipc_init : using accept lock file: /var/run/saslauthd/mux.accept saslauthd[7579] :detach_tty : master pid is: 0 saslauthd[7579] :ipc_init : listening on socket: /var/run/saslauthd/mux saslauthd[7579] :main : using process model saslauthd[7580] :get_accept_lock : acquired accept lock saslauthd[7579] :have_baby : forked child: 7580 saslauthd[7579] :have_baby : forked child: 7581 saslauthd[7579] :have_baby : forked child: 7582 saslauthd[7579] :have_baby : forked child: 7583
Since there was no stat_dir I looked for the socket at /var/run/saslauthd/mux and it was there until the CLI run process was killed. So I thought I should check to see if saslauthd was still running. Running ps ax | grep "sasl" came up empty. I restarted sasl with
/etc/init.d/saslauthd start"
And all was fine with the world.
TODO. The Postfix FAQ has some info on how to accomplish this, at least what needs to be configured on the Postfix side. Check Google for more info.
We have several domains, with some forwarded to external addresses and some to local users. We decided to go with virtual alias maps, since all the local recipients currently have local system accounts. The other option would be virtual mailbox maps. This is best for situations where you don't have a UNIX system account for each recipient. Instead of mapping to a user name, recipients are mapped to mailbox files on the filesystem. Large ISPs tend to use this. The 2 methods can also be used at the same time, with some recipients mapping to a local user and some to a local file.
You should probably read and understand /usr/share/doc/postfix/VIRTUAL_README.gz before messing with virtual domains.
postconf -e "virtual_alias_domains=archrivals.org, archrivals.net, gatewayflyball.org, \ mail.archrivals.org, mail.archrivals.net" postconf -e "virtual_alias_maps=hash:/etc/postfix/virtual, hash:/etc/postfix/virtual-buchek, \ hash:/etc/postfix/virtual-craigbuchek"
Edit /etc/postfix/virtual to look something like the following. (I've masked the full email addresses to prevent spammers from spidering the real addresses.) Any domain listed on the left must be listed in the virtual_alias_domains
setting.
# Forward emails to these addresses to another (external) email address. #info@example.com info@real.email.address # Forward emails to these addresses to a local user. flyball@archrivals.org flyball flyball@archrivals.net flyball flyball@gatewayflyball.org flyball flyball@mail.archrivals.net flyball flyball@mail.archrivals.org flyball # Send all email for these domains to a local user. # NOTE: This is a bad idea, since spammers will send you stuff to random addresses. #@flyball.com flyball
Compile the virtual
file into binary format.
postmap /etc/postfix/virtual postmap /etc/postfix/virtual-buchek postmap /etc/postfix/virtual-craigbuchek
TODO.
Ed Wehner requested that we allow accounts that are not associated with UNIX accounts. This is primarily to allow multiple email accounts for a family, where the family members each have their own private mailbox. Recipients are mapped to mailbox files on the filesystem; all the virtual mailboxes are owned by a single user. Large ISPs tend to use this.
We could even go as far as to dissociate all email accounts from UNIX accounts. However, we have a lot of UNIX users who like to read their email directly, so it's not clear that this would make sense.
Note that virtual mailboxes also make it trickier to specify the location of the maildir in the IMAP configuration file.
Using virtual mailboxes might make it easier to put users on a separate system from the email server. I.e. we would not have any user accounts on the email server.
Greylisting is a method for preventing spam, by initially rejecting email from a server on the first try. RFC-compliant SMTP servers will retry sending a few minutes later, but most spammers do not. Stopping spam this early in the delivery chain saves a lot of CPU time that SpamAssassin would have to spend looking at the messages.
Postgrey is a greylisting program built with Perl that works well with Postfix.
First, install the Postgrey package and its prerequisites.
apt-get install -y postgrey
Edit /etc/default/postgrey
to tune some parameters in POSTGREY_OPTS
:
POSTGREY_OPTS="–inet=127.0.0.1:60000 –delay=90 –auto-whitelist-clients=3 –max-age=60"
You can add lines to /etc/postgrey/whitelist_clients.local
and /etc/postgrey/whitelist_recipients.local
if necessary. Check the non-local versions for syntax.
Start the postgrey daemon:
/etc/init.d/postgrey restart
Next, configure Postfix to use Postgrey:
postconf -e "smtpd_recipient_restrictions=permit_mynetworks, \ permit_sasl_authenticated, \ check_policy_service inet:127.0.0.1:60000, \ reject_unauth_destination"
First check to ensure that the configuration files are valid. (If it returns without printing anything, then the configuration is valid.)
postfix check
Make sure that there's an /etc/aliases.db
file:
newaliases
Start the Postfix daemons:
/etc/init.d/postfix start
To make sure the daemons are running, you can check the process table:
ps auxw | grep postfix
This should show the 3 daemon processes. It should look something like this:
root 14126 0.0 0.2 3656 1328 ? Ss 22:04 0:00 /usr/lib/postfix/master postfix 14129 0.0 0.2 2964 1096 ? S 22:04 0:00 pickup -l -t fifo -u -c postfix 14130 0.0 0.2 2996 1116 ? S 22:04 0:00 qmgr -l -t fifo -u -c
There are several things to test in the email system architecture.
netstat -nlp | grep -E ':25|Recv-Q'
This should show the Postfix master
process listening on port 25. In our configuration, it's listening on local address 0.0.0.0, which means all interfaces.
telnet localhost 25
Make sure the banner looks OK, then type quit
to close the connection.
telnet localhost 25 <<EOF helo hostname mail from: xyz@x.y rcpt to: root@sluug.org data Hello. . quit EOF
Make sure it's delivered. Check /var/log/mail.log
and /root/Maildir/new/
. (Also check /etc/aliases to see if mail for root gets delivered somewhere else.) Each message will be in a separate file. Since this is the first message, there should only be one file in the directory. Look at the content of the file to check that the headers and content look right. (If we weren't using Maildir, the default delivery would be a file in /var/spool/mail
.)
sendmail your_email@address.com <<EOF Subject: Testing outbound email. This is a test. EOF
Make sure it's delivered. Check /var/log/mail.log
The mynetworks
setting is specific to our IP addresses assigned by Primary Networks and Washington University.
We may need to set relayhost, if our ISP doesn't allow outbound email, except through their SMTP server. (I.e. if they block port 25 outbound.)
To completely wipe away the installation and configuration:
dpkg --force-depends --purge postfix
Note that this does not remove the dependencies, and leaves APT dependency tree invalid. So you really should re-install the package as soon as possible.
The Postfix web site has a lot of good documentation.
The Debian install is chrooted by default.
When using mailbox_command
, aliases and .forward
files are processed. When using a transport, they are not processed. But transports are faster, since they don't have to start up a new process for each message.
To get a list of all the default configuration options, run postconf -d
.
The woodlandchows.com and cab3.dyndns.org domains are currently NOT virutal domains, as we're not sure how they should be set up. So their email will go to the user that is specified in the address. I.e. xyz@woodlandchows.com would go to the same recipient as xyz@sluug.org.
Ed Wehner says that we don't need to keep the stlk9info.net
or westinnkennels.com
domains.
mail.sluug.org
to mydestination
./etc/postfix/mynetworks
are still being used, and delete the rest./etc/postfix/mynetworks
.message_size_limit
.recipient_delimiter
do for us?debug_peer_list
.postmaster
, root
, logcheck
, www-data
, etc.The following is from the Omnitec Wiki:
Postfix and Apache both use the SSL certificates in /etc/ssl/ for secure communications and TLS authenication.
The guide for creating the keys is at openssl.htm (http://www.nomoa.com/bsd/openssl.htm)
I copied /etc/ssl/openssl.cnf to /etc/ssl/openssl.cnf.original and changed/added the defaults to be specific to SLUUG.
The commands, in order, to produce the certificate is :
Generate the private "sluug" server key with sluug passphrase.
sudo `which openssl` genrsa -des3 -out /etc/ssl/private/server.key 1024
Generate the certificate request with defaults in a modified openssl.cnf. For the "Common Name" enter the servers fqdn ie mx1.omnitec.net
sudo `which openssl` req -new -key /etc/ssl/private/server.key -out /etc/ssl/private/server.csr -config ./openssl.cnf
Self sign the certificate request to produce the servers certificate.
sudo `which openssl` x509 -req -days 3650 -in /etc/ssl/private/server.csr -signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt
Next copy the key and cert created to /etc/ssl/private/postfix.key and /etc/ssl/postfix.crt and change group so postfix can read it.
cp /etc/ssl/private/server.key /etc/ssl/private/postfix.key cp /etc/ssl/postfix.crt /etc/ssl/postfix.crt chown :postfix /etc/ssl/private/postfix.key chown :postfix /etc/ssl/postfix.crt
Installed and configured primarily by Jeff Muse and Craig Buchek. SASL/TLS configuration by Carl Fitch.
We used documentation from the following locations to help us configure our installation:
Configured Postgrey per documentation at HowtoForge: