====== 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. ===== Installation ===== 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|"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. ===== Configuration before adding other support packages ===== All Postfix configuration options are detailed in the [[http://www.postfix.org/postconf.5.html|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 ==== Basic Configuration ==== 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 [[http://www.list.org/mailman-install/node12.html|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' ==== Spam Avoidance ==== 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. === Initial options === 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' === Tests to the value of the SMTP HELO command === 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" === Tests to the value of the SMTP MAIL FROM command === 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" === Greylisting === NOTE: See also the [[#greylisting|Greylisting section]] below. It does even more thorough spam avoidance, but it's in a separate section because it requires a separate program. ==== Delivery ==== Whatever we do, we need to make sure that our [[IMAP|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] === 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: * [[http://www.courier-mta.org/maildrop/|maildrop]] * [[http://www.procmail.org/|procmail]] (not updated since 2001) * [[http://deliver.sourceforge.net/|deliver]] (by Chip Salzenberg -- last modified in 2000, no online docs) * [[http://wiki.dovecot.org/moin.cgi/LDA|deliver]] (from dovecot -- quota, indexes, sieve support) * [[http://www.gnu.org/software/mailutils/|GNU mailutils]]' sieve (poorly documented) * [[http://www.cpan.org/authors/id/R/RA/RAM/mailagent-3.0.73.readme|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} ===== Startup Postfix ===== 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 ===== Testing before adding other support packages ===== 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 < 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|Greylisting]], the message should be delayed.
  5. Test that you can send email out to the Internet: sendmail your_email@address.com < Make sure it's delivered. Check ''/var/log/mail.log''
- Test that Postfix' SMTP daemon understands the STARTTLS and AUTH extensions. - Test that the SMTP banner is correct. (Meets RFC requirements, but doesn't tell too much about us.) - Test that the MX records point to the correct system. - Test that you can send an email locally. - Test all the domains we handle email for. ===== Relaying ===== 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. ==== SMTP Security Extensions (STARTTLS and SASL) ==== Do the [[security|"Security" procedure]] first, if not already done, since you need [[http://www.openssl.org/|OpenSSL]] and the postfix certificate for testing. Most of this was stolen from [[http://www.jimmy.co.at/weblog/?p=52|Jimmys Weblog - Postfix and SASL]] and [[http://www.nervous.it/txt/Postfix-SMTP-AUTH-4-DUMMIES.html|Postfix SMTP-AUTH 4 DUMMIES]]. I admit to blatant cut 'n paste. === Required Packages === 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 === saslauthd === Edit ''/etc/default/saslauthd'' to enable SASL and ensure we're using PAM: START=yes MECHANISMS="pam" === smtpd.conf === Create ''/etc/postfix/sasl/smtpd.conf'' and tell it to use ''saslauthd'' for SMTP authentication: pwcheck_method: saslauthd mech_list: PLAIN LOGIN === main.cf === 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' ===master.cf=== 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 ===shorewall=== 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|"Firewall" procedure]] for more information. ===chroot=== 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 ===groups=== 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 ===restart and test=== 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 ==== POP-before-SMTP authorization ==== TODO. The [[http://www.postfix.org/faq.html#mobile|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. ===== Virtual Domains ===== 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 [[http://www.postfix.org/VIRTUAL_README.html|/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" ==== Virtual Mailboxes ==== 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|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 ===== 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" ===== And Much More ===== Additional mail configuration is in pages for [[spam|SpamAssassin]], [[imap|IMAP]], and [[lists|Mailing Lists]]. ===== Notes ===== 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 [[http://www.postfix.org/|Postfix web site]] has a lot of [[http://www.postfix.org/documentation.html|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. ===== TODO ===== * 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. ===== Credits ===== 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 [[http://www.falkotimme.com/howtos/postfix_smtp_auth_tls/index.php|Postfix-SMTP-AUTH-TLS-Howto]] * Back-end configuration (OLD delivery to Cyrus) based on the [[http://www.faqs.org/docs/Linux-HOWTO/Postfix-Cyrus-Web-cyradm-HOWTO.html#POSTFIX-CONFIG|Postfix-Cyrus-Web-cyradm-HOWTO]] Configured Postgrey per documentation at HowtoForge: * [[http://www.howtoforge.com/greylisting_postfix_postgrey|Killing That Spam With Postgrey And Postfix]] ===== Comments ===== ==== Debugging ==== 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. {{build:tbird_sluug_ssl_465.png|Text after picture?}} 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. ==== SSL Key Generation ==== **This section is obsolete, and should be deleted once others confirm it no longer has value. It duplicates the security page, and the [[security|"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