Postfix

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.

The default MTA in Debian is EXIM. In the default install the log rotation is already configured in /etc/cron.daily for EXIM, so remove the script

rm /etc/cron.daily/exim4-base

Do the "Firewall" procedure first, if not already done, since you need several ports open for testing mail.

Install the package:

apt-get install postfix

This will install one postfix package, and remove four exim (the default Debian MTA) packages.

You will (probably) be presented with some warnings and instructions in text menus. Hit OK after reading the instructions, then select No configuration, as we'll be configuring manually. You will need to use cursor and tab keys to maneuver in the menus.

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. The list of domains in the example below is only for the main mail server. For other systems, see the next example. You will probably have to unwrap the following command to be one line.

postconf -e 'mydestination=$mydomain, $myhostname, \
localhost, woodlandchows.com, \
buchek.com, craigbuchek.com, boochtek.com, \
www.sluug.org, mail.sluug.org'

For secondary (not the main mail server) systems, don't list all those domains shown above. Only list "localhost" and specific domains this system will accept mail for. This might include "$myhostname,", but never "$mydomain,". For example, use this instead:

postconf -e 'mydestination=localhost.$mydomain, localhost, budlight-mailtest1.sluug.org'

Set the domain name to add for any addresses that are not specified:

postconf -e 'myorigin=$mydomain'

For secondary (not the main mail server) systems, you might want to set myorigin to "$myhostname" instead of "$mydomain", but at the time of this writing, that is not what we did on budlight. Setting to "$mydomain" means that local mail, such as output from batch jobs, will be forwarded to the main mail server instead of being kept local, including mail for root, unless addresses to an address listed in mydestination. Setting to "$myhostname" will impact all the return addresses on mail, which can be a problem for users of mailing lists.

For secondary (not the main mail server) systems, we want all outgoing to be sent from this system to be routed through the main mail server. So we tell this system to use a smarthost with:

postconf -e 'relayhost=mail.sluug.org'

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'

Assuming /etc/postfix/mynetworks doesn't already exist, create it, add any desired adddresses to it, and generate the binary hash file from it:

cat >> /etc/postfix/mynetworks << 'EOD'
# These IPs are allowed to relay through our SMTP servers.
# This list was originally taken from Dark.
#   We do not have documentation on who needs these, and if they are still in use.
# NOTE: The 2nd field is not used, but you'll get warnings from postmap if you leave it out.
EOD 
vi      /etc/postfix/mynetworks
postmap /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'

By default, Postfix will keep trying to send an email for 5 days, before it gives up and tells you that it had a problem. That seems rather long, so we reduce it to 1 day:

postconf -e 'maximal_queue_lifetime=1d'
postconf -e 'bounce_queue_lifetime=1d'

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'

Turn off the VRFY command, so spammers cannot verify whether an address is valid or not.

postconf -e 'disable_vrfy_command=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.

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

Update the configuration file to use the database, and other desired options.

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"

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.

Create the access database source file, /etc/postfix/sender_access using your favorite text editor. Add in comments and desired entries in the form below. Check any existing systems for what entries we are currently using, or just copy from another of our Debian systems.

#*******************************************************************************
#
# Database to give you the ability to allow or refuse to accept mail
# based on the MAIL FROM command.
#
# This is used with the smtpd_sender_restrictions option.
#
# Rebuild the database with:  postmap /etc/postfix/sender_access
#
#*******************************************************************************

# We were spammed by zorpia on 19 Oct 2007
zorpia.com      550 "Disallowed due to prior spam history"

Generate the database from the source file:

postmap /etc/postfix/sender_access

Update the configuration file to use the database, and other desired options.

postconf -e "smtpd_sender_restrictions=hash:/etc/postfix/sender_access, \
  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/'

Now we need some additional configuration because the $MAIL environment variable is still set to /var/spool/mail when each user logs on, so mail clients like mutt will look in the wrong place. The difficult to find change is made in two configurations files in the /etc/pam.d directory.

Edit the "login" file to change the "pam_mail.so" line to add " noenv dir=~/Maildir" to the end so it looks like:

session    optional   pam_mail.so standard noenv dir=~/Maildir

Edit the "ssh" file to change the "pam_mail.so" line to replace "noenv" with "dir=~/Maildir" so it looks like:

session    optional     pam_mail.so standard dir=~/Maildir # [1]

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:

• maildrop
• procmail (not updated since 2001)
• deliver (by Chip Salzenberg – last modified in 2000, no online docs)
• deliver (from dovecot – quota, indexes, sieve support)
• GNU mailutils' sieve (poorly documented)
• mailagent (not updated since 2001)
• Mail::Audit

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}

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.

1. Make sure Postfix' SMTP daemon is listening:

   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.

2. Test connecting to port 25 on the loopback interface:

   telnet localhost 25

   Make sure the banner looks OK, then type quit to close the connection.

3. Test connecting to port 25 on the loopback interface:

   telnet localhost 25 <<EOF
   helo hostname
   mail from: <xyz@x.y>
   rcpt to: root@sluug.org
   data
   Subject: Test outgoing mail
   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.)

4. Test that you can send an email from an outside address to a local address. Caution, if you have already enabled Greylisting, the message should be delayed.
5. Test that you can send email out to the Internet:

   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

1. Test that Postfix' SMTP daemon understands the STARTTLS and AUTH extensions.
2. Test that the SMTP banner is correct. (Meets RFC requirements, but doesn't tell too much about us.)
3. Test that the MX records point to the correct system.
4. Test that you can send an email locally.
5. Test all the domains we handle email for.

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:

• Use the SASL and LOGIN extensions to SMTP.
• Record the IP address of authenticated POP users, have Postfix use that list.
• Allow any sluug.org email address to send emails out.

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.

Do the "Security" procedure first, if not already done, since you need OpenSSL and the postfix certificate for testing.

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 some prerequisites that are required to get TLS/SSL and SASL working with Postfix.

apt-get install openssl ssl-cert ca-certificates
apt-get install sasl2-bin libsasl2 libsasl2-modules
apt-get install postfix-tls

Next, you'll need to create the SSL certificates. We've not documented this part well, but this might do the trick:

openssl -gencert postfix

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 the Postfix configuration:

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:

postconf -e 'smtpd_use_tls=yes'
postconf -e 'smtpd_tls_auth_only=yes'
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 uncomment 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

See the "Firewall" procedure for more information.

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

And move the SASL database to the etc directory of the chrooted environment. See the "unable to open Berkeley db /etc/sasldb2" section below for more details. The rest of the etc directory is filled in when postfix is started using the /etc/init.d/postfix script.

cd /var/spool/postfix/etc
cp -p /etc/sasldb2 .
mv /etc/sasldb2 /etc/sasldb2.`date +%F`
ln -s /var/spool/postfix/etc/sasldb2 /etc/sasldb2

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

Start saslauthd if not done already.

/etc/init.d/saslauthd start

Check postfix configuration

postfix check

If all is well restart postfix and watch the log

postfix reload ; tail -f /var/log/mail.log

If the reload command, if it fails with "the Postfix mail system is not running", then it was never started in the first place. Don't start with "postfix start" since this doesn't create the files needed in the chrotted environment.

/etc/init.d/postfix start

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

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.

For secondary (not the main mail server) systems, you probably don't have any virtual domains to define, so you should just skip this section. It can be done later if the need arises.

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. This will install extra packages if not already installed: libberkeleydb-perl, libdigest-hmac-perl, libio-multiplex-perl, libnet-cidr-perl, libnet-dns-perl, libnet-ip-perl, and libnet-server-perl.

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 create and/or add lines to /etc/postgrey/whitelist_clients.local and /etc/postgrey/whitelist_recipients.local if necessary. Check the non-local versions for syntax.

cat >> /etc/postgrey/whitelist_clients.local << 'EOD'
# Client (sender) addresses for which no greylisting should be done.
# The following can be specified for client addresses:
#   domain.addr  "domain.addr" domain and subdomains.
#   IP1.IP2.IP3.IP4
#       IP address IP1.IP2.IP3.IP4. You can also leave off one number,
#       in which case only the first specified numbers will be checked.
#   /regexp/     anything that matches "regexp" (the full address is matched).
 
# SLUUG servers:
128.252.19.8   # michelob
128.252.19.9   # dark
128.252.19.27  # webdev
206.196.99.162 # bud
206.196.99.163 # budlight
206.196.99.164 # ultra
206.196.99.165 # busch
 
# Others per request or as needed:
EOD

cat >> /etc/postgrey/whitelist_recipients.local << 'EOD'
# Recipient addresses for which no greylisting should be done.
# The following can be specified for recipient addresses:
#      domain.addr        "domain.addr" domain and subdomains.
#      name@              "name@.*" and extended addresses "name+blabla@.*".
#      name@domain.addr   "name@domain.addr" and extended addresses.
 
# Others per request or as needed:
EOD

The installation of postgrey should have started it, but want to retart the postgrey daemon to pick up the changes:

/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"

Additional mail configuration is in pages for SpamAssassin, IMAP, and Mailing Lists.

The mynetworks setting is specific to our IP addresses assigned by Primary Networks and Washington University.

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 virtual 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.

• Once we flip the switch and have the sluug.org MX record point to Bud, we can remove the test.sluug.org from mydomains and from DNS.
• Run through all the tests. (And develop more/better tests.)
• Add virtual mailboxes. (Mail accounts that don't require a real user account.)
• Allow per-user filtering. Procmail at the very least. Perhaps also maildrop.
• After a few months of production use, check the logs to see which IPs in /etc/postfix/mynetworks are still being used, and delete the rest.
  • Try to convert the remaining users to authenticate via SASL/TLS instead of hard-coding their IPs.
• Add POP-before-SMTP authentication. This may (or MAY NOT) be required to remove the remaining IPs from /etc/postfix/mynetworks.
• Find a good value for message_size_limit.
• What does recipient_delimiter do for us?
• Take a look at setting debug_peer_list.
• Set aliases for postmaster, root, logcheck, www-data, etc.

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:

• http://workaround.org/articles/ispmail-sarge
• Front-end TLS/SMTP-AUTH configuration based on the Postfix-SMTP-AUTH-TLS-Howto
• Back-end configuration (OLD delivery to Cyrus) based on the Postfix-Cyrus-Web-cyradm-HOWTO

Configured Postgrey per documentation at HowtoForge:

• Killing That Spam With Postgrey And Postfix

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 /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.

This section is obsolete, and should be deleted once others confirm it no longer has value. It duplicates the security page, and the "Security" procedure is better.

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