6.7. Postfix

Given the dissatisfaction with Sendmail's complexity, code bloat, and track record, it was only a matter of time before people started developing alternatives. One of these is a drop-in replacement for Sendmail and is called Postfix. Weitse Venema wrote a program called VMailer in 1997, and in early 2001, this software was released as Postfix Version 1.0. Postfix was designed from the ground up to be safe and robust, modular, to perform well, and to be compatible with Sendmail to make it easy for those familiar but unhappy with Sendmail to switch.

One significant difference between Postfix and Sendmail is its carefully crafted architecture. Postfix consists of a small suite of service binaries that each performs a simple task. The master binary, appropriately named master(8), runs as root and listens for incoming connections. When a connection is made, master spawns smtpd(8), which can run chrooted and handles SMTP transactions. When a message has been completely received by smtpd, it is passed on to the cleanup(8) daemon and eventually ends up in the incoming queue directory on the filesystem. This is just the beginning of how Postfix handles mail but should give you an idea of how Postfix was designed. Small programs handle simple tasks and handle them well in the best Unix tradition.

While understanding what all of the Postfix programs do is no easy task, configuring Postfix generally is. As mentioned earlier, Postfix was designed as a drop-in replacement for Sendmail. Most administrators familiar with Sendmail will be able to understand the terminology and architecture of Postfix without a great deal of effort. This makes configuring Postfix simple. Assisting with this endeavor are the comprehensive manpages and easy-to-read documentation and tutorials available at http://www.postfix.org/. For more information, consider the O'Reilly book Postfix by Kyle D. Dent.

6.7.1. Installation and Configuration: FreeBSD

To replace the base Sendmail installation on your FreeBSD system, change into ports/mail/postfix and run make install. You are provided a configuration menu similar to the one in Figure 6-4. You probably recognize some of these items as we briefly touched on them earlier in this chapter.

Figure 6-4. Postfix install options

Most of these options are self-explanatory, but as a reminder, we present this brief summary.

SASL2

Install SASL2 if you need to provide SMTP authentication, that is, you require that users authenticate before they are allowed to send mail through your servers. This is useful when your users will connect to your mail server from untrusted networks in order to send mail. If you select SASL2, you will have another set of options to choose from that determines how SASL authenticates users. In many cases, the SASLAUTHD option will be appropriate; see the SASL resources at the end of this chapter for links to more information about this topic.

SPF

Install SPF support if you plan to implement the Sender Policy Framework as described earlier in this chapter. To jog your memory, SPF provides a means to verify that a given message was sent from an approved mail server by querying the responsible nameserver from the message originator's domain.

TLS

This installs Transport Layer Security and provides for encrypted SMTP sessions. This is vital if you plan to use SASL. Otherwise, you probably don't need it.

DBx/MySQL/PgSQL/OpenLDAP

Postfix is capable of querying several kinds of databases for map files such as aliases, virtuals, transport maps, and so on. If you have a need for this in your environment, select the appropriate option. We do not cover database-backed map lookups in this chapter.

Once you have selected the options appropriate for you environment, Postfix will install itself. At the end of the install process, you will be prompted to create one user (postfix) and two groups (postfix and maildrop). Do so. As mentioned earlier, the Postfix suite is composed of several daemons and many of them run as nonprivileged users. It is these users that are created at the end of the install process.

You are then prompted to activate Postfix in /etc/mail/mailer.conf. Doing so will effectively replace Sendmail on your system. Although, binaries will not be overwritten, the mailwrapper(8) program, which acts as an intermediary between MUA software on the system, and the installed MTA will be told which binaries to execute for key MTA functionality.

Finally, additional steps may be required to complete your Postfix installation. These steps will be clearly stated in the output caused by your make install command. At the time of this writing, the port prompts you to modify /etc/rc.conf and /etc/periodic.conf to complete the Sendmail replacement. We will not go over these details as they are known to change from time to time and are clearly stated during the install process.

6.7.2. Installation and Configuration: OpenBSD

Installing Postfix on your OpenBSD system is fairly straightforward. However, before diving in, you have to make a few decisions in order to set the install flavor properly. Specifically, if you need to authenticate users before sending mail, you need SASL. If you're accepting usernames and passwords during the SMTP session, it makes sense to encrypt. For this, you need TLS. In other cases, it will not be necessary to set a flavor. Example 6-6 outlines the basic steps for installing Postfix and replacing Sendmail on your OpenBSD system.

Example 6-6. Installing Postfix on OpenBSD with SASL/TLS

% setenv FLAVOR "sasl2 tls pcre" % make && sudo make install % unsetenv FLAVOR % sudo /usr/local/sbin/postfix-enable

If you don't need SASL or TLS support, merely remove them from your flavor. The pcre entry provides Perl compatible regular expressions support, which is helpful should you need to perform arbitrary content filtering later.

Running /usr/local/sbin/postfix-enable activates Postfix in /etc/mailer.conf. This causes MUA software on the system to use Postfix binaries instead of Sendmail ones without deleting or overwriting any Sendmail software. You may switch back to Sendmail at any time by running /usr/local/sbin/postfix-disable. The enable script will also inform you of a few additional steps required to wrap up your Postfix installation. We will not cover these steps here as they have been known to change and are clearly stated during the execution of this script.

Postfix is now installed, and configuration files are stored in /etc/postfix. Postfix is configured to run most of its processes from a chroot, including smtpd(8): the master daemon process that listens on port 25 for incoming connections and accepts mail. Thus, as with any chrooted daemon, you need to create a logging socket within the chroot so that the process can send messages to syslogd. To do this, add the following line to /etc/rc.conf.local:

syslogd_flags="-a /var/spool/postfix/dev/log"

If you already have a syslogd_flags configuration entry, merely append this argument pair to it.

6.7.3. Postfix Security Foundation

We have casually mentioned several times in this chapter that Postfix gains much if its security by design. Let's take a look at why and how this is so.

6.7.3.1 Do one thing, do it well

Doug McIlroy, the inventor of Unix pipes, had a vision for building Unix software. He believed programs should be built to do one thing, and to do it well. Programs should be written to accomplish discrete tasks and with interoperability in mind. Postfix is built with this philosophy in mind. The Postfix suite of programs "do mail." Postfix can act as a daemon, accept mail, check the content of mail, rewrite messages, deliver messages to other hosts, to the local filesystem, and so on.

As you might have guessed, "doing mail" is far more than one discrete task. Instead of trying to do everything in one program, Postfix employs several binaries, which handle each of these responsibilities. Communication is either handled directly through pipes, or by merely leaving files on the filesystem for another program to deal with. This has several consequences:

• Each program is easier to write, less complicated, and the program writer is less likely to overlook problems in the code.

• Most programs may run in a nonprivileged context but the smtpd daemon that listens on privileged port 25 must run as root.

• Programs not needed in a given environment may be easily disabled making exploitation of that program impossible.

Moreover, each program is able to perform operations on mail messages and leave the resultant message behind for another program to deal with. This lack of direct inter-process communication helps alleviate some security risks.

6.7.3.2 Understanding logging

As is often the case, increased security can bring with it a decrease in convenience. The programs that make up Postfix are unable to pass data directly to others, so as messages move through a series of these programs, logging is handled independently.

If you have data showing up in your Postfix logs, but some logs you expected to see are conspicuously missing, ensure you are getting logs from all Postfix programs. Chrooted programs need special provisions if syslogd is to be expected to capture relevant messages.

In a simple case, you might see a series of logs as follows:

Oct  5 00:04:50 woot postfix/smtpd[3199]:  connect from dreadnaught.home.korff.org[172.16.0.2] Oct  5 00:04:56 woot postfix/smtpd[3199]:  AA22369: client=dreadnaught.home.korff.org[172.16.0.2] Oct  5 00:05:02 woot postfix/cleanup[14647]:  AA22369: message-id=<[e-mail]> Oct  5 00:05:02 woot postfix/qmgr[11900]:  AA22369: from=<[e-mail]>, size=431, nrcpt=1  (queue active) Oct  5 00:05:02 woot postfix/local[29887]:  AA22369: to=<[e-mail]>, relay=local, delay=6,  status=sent (mailbox) Oct  5 00:05:03 woot postfix/smtpd[3199]:   disconnect from dreadnaught.home.korff.org[172.16.0.2]

Six log entries for local delivery, and this is a simple case! On a busy mail server, it is not uncommon for log entries to be interspersed with one another: connections mixed with mail delays and errant spam rejections in the mix. Mail forwarding through virtual maps or aliases are even more complicated as the incoming and outgoing message are assigned separate queue IDs (AA22369 is the queue ID above). It gets worse. With content filtering programs like SpamAssassin and amavisd-new, messages leave the Postfix system and are subsequently re-injected and assigned a new queue ID.

Deciphering Postfix logs can be challenging, but if you follow these guidelines, you should be able to avoid getting lost:

• The queue ID assigned by Postfix will describe any given message entering and leaving the Postfix system.

• In some cases, a message that leaves returns as a result of a forwarding map or an external content filter. In this case, qmgr will see the message twice and assign a new queue ID the second time. You can determine the newly assigned queue ID by looking at the second qmgr log entry containing the message ID (i.e., New queue ID, same message ID).

This should get you through the intricacies of Postfix logging.

6.7.3.3 Chroot

Postfix is able to chroot easily. OpenBSD administrators gain an advantage as the installation of Postfix through ports results in a chrooted configuration by default.

FreeBSD users should adjust the chroot column in the master.cf Postfix configuration file and change the n to a y for every process that should run chrooted. All Postfix processes may be chrooted with the exception of the pipe, virtual, local, and proxymap services. In almost all cases, it will be necessary to copy /etc/localtime, /etc/resolv.conf, and /etc/services into /var/spool/postfix/etc. Finally, create a log socket in Postfix's queue directory per the following:

syslogd_flags="-l /var/spool/postfix/var/run/log"

Of course, you must create /var/spool/postfix/var/run before this will work.

If you are using SASL authentication, your dependence on configuration files, password databases, and libraries increases exponentially. Running a chrooted smtpd daemon with SASL is likely more trouble than it's worth.

6.7.3.4 Configuration files

Postfix requires only two main configuration files: main.cf and master.cf. Both are located in the Postfix configuration directory: /usr/local/etc/postfix on FreeBSD and /etc/postfix on OpenBSD.

The master.cf file controls the behavior of the various Postfix programs. You will likely make small modifications to this file (perhaps to chroot certain services) and then forget it exists, except in some border cases.

The main.cf file controls the behavior of Postfix and you will likely spend a fair bit of time working with this file. Fortunately, the main.cf file is easy to read and understand following a simple parameter = value syntax. This makes configuration easy, and mistakes less likely.

Whenever you make a change to either of these files, you must restart Postfix by running postfix reload.

6.7.4. Security-Related Configuration Options

As you configure your Postfix installation, remember that the fewer configuration changes you make, the more likely you are to have a reliable and secure installation. One of the most common mistakes made by administrators used to administering Sendmail is overconfiguration. Nevertheless, there are a few things to keep in mind.

6.7.4.1 Arbitrary program restriction

One of the dangers inherent in mail delivery is the power to pass mail to arbitrary programs. This can be done through aliases, .forward files, and :include: mailing lists. It may be worth your while to restrict exactly which programs may be executed through these facilities. One of the helper programs installed by default on your system was designed to do exactly this. It's called smrsh(8) and it only allows programs to execute if they are listed in /usr/libexec/sm.bin (by default).

To configure Postfix to use smrsh to intercept mail sent to local commands, use the following configuration in your main.cf file:

local_command_shell = /usr/libexec/smrsh

Then link to programs that should be allowed to run. For example, to grant users the ability to pass mail into vacation(1) and procmail(1), issue these commands:

% sudo ln -s /usr/bin/vacation /usr/libexec/sm.bin/vacation % sudo ln -s /usr/bin/procmail /usr/libexec/sm.bin/procmail

6.7.4.2 Masquerade your domain

Many organizations send mail internally and retain full hostnames for host-to-host mail. When the mail leaves the organization, however, these internal hostnames are no longer resolvable. In order to ensure that mail reaches the destination (because the sender's domain must resolve), it's usually a good idea to masquerade all hosts and subdomains within a domain to the top level domain.

That is, mail sent from two internal hosts taco.mexicanfood.net and salsa.condiments.mexicanfood.net, should reach its destination and appear to have come from @mexicanfood.net. This configuration option is a appropriate for a mail relay and may be configured using a pair of stanzas similar to the following in your main.cf file:

myorigin = $mydomain masquerade_domains = $mydomain

This assumes you want your mail to come from $mydomain. If your mail server's hostname is fajita.dmz.mexicanfood.net, $mydomain will be dmz.mexicanfood.net. To change this behavior, explicitly set $mydomain to something else:

mydomain = mexicanfood.net

You may run into mail routing problems by collapsing your entire user-namespace. Thus, many organizations enforce organization-wide usernames and masquerade on the internal mail server also. Finally, as you will invariably receive mail from the root account (and perhaps several other accounts) of this machine, you probably want to retain host information for system and service users so you can avoid looking at message headers to find out where the message came from. To do this, use:

masquerade_exceptions = root cron

6.7.4.3 Obfuscate smtpd banner

It is of marginal value to obfuscate the smtpd banner (for example, see the first line of Example 6-4) smtpd displays when client programs or attackers connect to port 25 on your host. Most attacks you will face come from scripts, iterating through open ports looking for daemons to exploit. These scripts rarely care about what mail server you happen to be running, they attempt the exploit regardless.

Still, some administrators prefer to give away as little information as possible. A laudable goal and if you have secured your system and Postfix in every other conceivable way and have time left over, by all means configure an alternative smtpd banner by adding a stanza similar to the following in your main.cf file:

smtpd_banner = $myhostname MexiMail Server

6.7.4.4 Disable unneeded commands

Restricting certain SMTP commands is of moderate value. Postfix's implementation of these commands is well tested and not known to cause significant problems, but you may want to consider turning them off.

etrn

If you are MX for an organization that has intermittent network capability and will only be able to receive mail at certain times, they may need a way to tell you to process your queue for them. These organizations could contact your mail server and issue, for instance, ETRN smtp.onlinesometimes.net. This will tell your server to process all messages in the queue that could not be delivered to smtp.onlinesomtimes.net due to network problems at last attempt. By default Postfix will only allow ETRN for domains to which the server is configured to relay mail. If the situation described above does not apply to you, you may disable etrn altogether by setting smtpd_etrn_restrictions to reject in your main.cf.

vrfy

By default Postfix will allow VRFY command which is supposed to let clients determine whether or not a user exists without sending mail. Postfix, however, will always return a 252 code informing the client to "go send mail and find out." VRFY may be disabled altogether by setting disable_vrfy_command to yes; there's little justification for or against.

6.7.5. Limiting Denial of Service Attacks

Postfix ships with a good default configuration for limiting the risk of being affected by a denial of service attack. This includes reasonable concurrency limits for daemons, maximum SMTP syntax errors before disconnection, minimum free disk space, and so on. Most of these variables will not need tuning unless you observe problems in the behavior of your Postfix installation.

bounce_size_limit

This limits the size of mail bounces. Messages are truncated to this size, allowing you to see the bounce, without having to deal with the entire content of the message. This may be worth lowering from the default of 50,000 to keep spam bounces from clogging your mailbox.

default_process_limit

Postfix limits the number of any given subprocesses that may be concurrently running. The default of 100 may be excessive in your environment and you might want to choose a lower number. This will affect every Postfix subprocess. To use different thresholds for different subprocesses, you may specify limits on a per-process basis in the maxproc column in your master.cf.

mailbox_size_limit

This configuration parameter controls the maximum size of a given user's mailbox. Of course this only makes sense on a system where Postfix is performing local delivery.

message_size_limit

As you might guess, this limits the size of messages. The default of 10 MB is not unreasonable, but if you can lower it, do so. Make sure you provide alternatives for transporting large files to your users.

smtpd_error_sleep_time and error_limits

Postfix has two error thresholds that control when the smtpd daemon starts delaying responses. The daemon accepts the number of errors specified in smtpd_soft_error_limit before instituting delays (of 1 second, by default) to all subsequent responses. When the error count reaches the number specified by smtpd_soft_error_limit, the connection is terminated. While this provides an effective means of slowing down spammers, setting this value too high could allow a determined attacker to initiate connections with jibberish data resulting in more and more daemon processes. Eventually the daemon limit will be reached and legitimate connections will have to wait, or be denied altogether. It is important to be aware of these configuration options so that you avoid inadvertently changing them without fully understanding the ramifications.

smtpd_recipient_limit

This parameter controls the maximum number of recipients a mail message can have. The generous default of 1000 is in place as a sanity check. You may wish to reduce this value in your environment.

Although these configuration parameters are by no means a comprehensive list of tunable limits within the Postfix system, they are some of the most important. Consider reading the TUNING_README (distributed with the Postfix source) and the manual page for postconf(5) for information about additional limits, when to use them, and when to avoid changing them.

6.7.6. Blocking Unwanted Mail

There are myriad ways of blocking unwanted mail through Postfix. We cover a few of these options and point out when they are appropriate for use.

6.7.6.1 Access table

The access(5) table allows you to configure your server to accept or reject mail based on hostnames, domain names, networks, or mail addresses. An access table will generally have entries similar to Example 6-7.

Example 6-7. A basic access file

1.2.3                  REJECT I don't like your network peruvianfood.net       REDIRECT [e-mail] joe@                   DISCARD # silently throw away, dangerous!

Many other options are possible, see the access manpage for more possibilities. The access database can be use in conjunction with a variety of checks including:

• check_client_access

• check_helo_access

• check_recipient_access

• check_sender_access

In turn, these checks are tied to specific restriction parameters. For instance, to control which clients are allowed to use your mail server, you would specify:

smtpd_client_restrictions =          check_client_access hash:.../postfix/client-access

Then, in your client-access table, you could specify networks or hostnames that should be denied access.

Likewise check_helo_access may be listed as a value to smtpd_helo_restrictions. We point out these two configuration possibilities not because they are of tremendous use, but because you could waste a lot of valuable time trying to figure out how to set them properly. Spammers use ever-changing source networks and specify different values for HELO all the time. There is little use in trying to block UCE with manual updates to these maps.

The latter two configuration options may be listed in smtpd_recipient_restrictions as they are both relevant during the same stage of an SMTP transaction. So, you might want to configure the following:

smtpd_recipient_restrictions = permit_mynetworks ...         check_sender_access hash:.../postfix/sender-access         check_recipient_access hash:.../postfix/recipient-access         ... reject_unauth_destination

Sender and recipient access maps can be more useful for configuring mail addresses to which and from whence messages should be rejected. For instance, you may want to block mail sent from offers@ or sales@ globally, depending on your organizational mail policy. Likewise, you might want to block mail being sent from the outside world to any of your internal mailing lists at the mail-relay level.

Finally, in general, access maps do not provide the kind of flexibility required to deal with spam, but they can be useful in globally rejecting or discarding certain kinds of messages or when problem accounts, networks, or domains arise.

6.7.6.2 Arbitrary content filtering

Postfix is capable of performing arbitrary content filtering through header and body checks by defining the following in your main.cf:

header_checks = pcre:.../postfix/header-checks body_checks = pcre:.../postfix/body-checks

These let you define substrings that, when found in the header or body of messages, should result in message rejection or the message being silently discarded. Header and body checks are useful in blocking mail with certain attachments, sent from certain parts of the world with which your organization traditionally has no contact, containing key phrases containing marketing buzzwords or indicating pornographic content, etc.

For example, you may want to block all mail tagged greater than 12 by SpamAssassin. For this, you would need the following entry in your header checks.

/^X-Spam-Level:\s\*\*\*\*\*\*\*\*\*\*\*\*/             REJECT

Elaborating on the diverse opportunities available in content filtering is not worthwhile here. Instead, visit the resources listed at the end of this chapter for more information on this topic.

6.7.6.3 DNS blacklists

Postfix can be easily configured to reject mail from sites listed in real-time blacklists (RBLs) using the reject_rbl_clcient directives under your smtpd_recipient_restrictions in main.cf. To configure RBLs in your Postfix installation, add stanzas similar to the following under your recipient restrictions:

reject_rbl_client relays.ordb.org

See the specific RBL provider's site to determine exactly which host to list.

6.7.6.4 Virus protection

Virus protection is essential to stop the flow of malware through your servers to more vulnerable client workstations and servers running Windows. Viruses and worms that exploit vulnerabilities in Unix software are uncommon but not unheard of. A variety of commercial and noncommercial options exist including McAffee Virus Scan, Kaspersky Anti-Virus, and Clam AntiVirus (ClamAV). Perhaps the most popular choice, and the one chosen by SourceForge, is ClamAV.

Postfix and ClamAV are generally connected through an intermediary piece of software called amavisd-new. Postfix is configured to use amavisd-new as a content filter, and amavisd-new in turn passes mail to the ClamAV (you may also want to use SpamAssassin through amavisd-new if you are using virus protection).

ClamAV and amavisd-new are available as FreeBSD ports, but OpenBSD users must download the source, compile, and install it in the traditional GNU fashion (though an unofficial ClamAV port may be retrieved from http://www.fatbsd.com/openbsd/clamav/).

After amavisd-new and ClamAV are configured, Postfix should be configured to accept mail as usual, pass it to the amavisd-new content filter listening on another port (specified in amavisd.conf), which will in turn pass mail back to Postfix on yet another port (also specified in amavisd.conf) for re-injection into the mail queue.

First, Postfix should be configured to send mail to amavisd-new by adding the following to your main.cf:

content_filter = smtp-amavis:[127.0.0.1]:amavisd_port

Then adjust your master.cf so that amavisd-new can send mail back to Postfix:

smtp-amavis unix -      -       n     -       3  smtp     -o smtp_data_done_timeout=1200     -o disable_dns_lookups=yes 127.0.0.1:reinjection_port inet n - n - - smtpd    -o content_filter=    -o smtpd_recipient_restrictions=permit_mynetworks,reject    -o mynetworks=127.0.0.0/8    -o strict_rfc821_envelopes=yes

This allows any content filters attached to amavsid-new to parse messages before they are returned to the Postfix system for delivery.

6.7.7. Authentication and Encryption

We discussed earlier that SMTP is an authentication-free protocol. By design, anyone can connect to an SMTP server and send mail, and this mail will travel over clear text to the server. Certain organizations, however, who must accept and relay mail from known users on unknown and untrusted networks need some means to verify that a user is who she says she is. One solution is the Simple Authentication and Security Layer (SASL).

Of course, authentication without encryption should send a shiver up the spine of any security-minded system administrator. Providing an encrypted channel over which authentication can occur for the SMTP exchange is handled by Transport Layer security (TLS).

6.7.7.1 Verifying Postfix+SASL+TLS installation

If you followed the directions earlier in this chapter and installed Postfix with SASL and TLS support as described, you should be ready for configuration. It's a still a good idea to verify that your Postfix installation was in fact built with the requisite support. This is easily achieved by using ldd(1):

% ldd `which postfix`  /usr/local/sbin/postfix:         Start    End      Type Ref Name         00000000 00000000 exe   1   /usr/local/sbin/postfix         05444000 25449000 rlib  1   /usr/local/lib/libpcre.so.0.1         00755000 2075b000 rlib  1   /usr/local/lib/libsasl2.so.2.13         08965000 28971000 rlib  1   /usr/lib/libssl.so.8.0         08b9c000 28bcd000 rlib  1   /usr/lib/libcrypto.so.10.3         050d0000 25109000 rlib  1   /usr/lib/libc.so.30.3         04867000 04867000 rtld  1   /usr/libexec/ld.so

This transcript is from an OpenBSD 3.5 system and your output may differ slightly. Nevertheless, if your Postfix installation supports SASL, TLS, and PCRE, you should see corresponding libraries listed in this output as libsasl2, libssl, and libpcre.

6.7.7.2 Configuring Postfix with SASL+TLS

After you have verified that your postfix binary supports the requisite functionality, you may turn your attention to configuration. Enabling SASL in Postfix is easy, merely add relevant lines from the options below to your main.cf:

smtpd_sasl_auth_enable = yes broken_sasl_auth_clients = yes smtpd_sasl_security_options = noanonymous

The first option enables SASL. The second allows some older Microsoft clients to authenticate. You may be able to omit this option depending on the MUAs you need to support. The third option looks innocuous but in fact is a deviation from the default of noplaintext, noanonymous. What this option does is to enable plain text authentication where the users' password is transmitted in clear text over the network; with TLS, these clear-text passwords will be sent over an encrypted channel. Some MUAs do not properly handle any form of authentication other than plain text. If you find yourself in this position, omit the noplaintext this configuration entry, otherwise specify it.

While the smtpd_sasl_auth_enable option tells Postfix use to use SASL, it does not specify how. Specifically, you will want your mail server to relay mail for those users who can authenticate. To do this, adjust your existing smtpd_recipient_restrictions as follows:

smtpd_recipient_restrictions = permit_mynetworks         permit_sasl_authenticated         ... reject_unauth_destination

Order is important, and the permit_sasl_authenticated directive should be listed early to ensure mail from your authenticated users is not excessively tested. Once this is done, it is time to configure TLS. This is achieved by adding lines similar to the following to your main.cf:

smtpd_use_tls = yes  smtp_use_tls = yes smtp_tls_note_starttls_offer = yes  smtpd_tls_key_file = .../postfix/ssl/smtpd.pem smtpd_tls_cert_file = .../postfix/ssl/smtpd.pem smtpd_tls_CAfile = .../postfix/ssl/smtpd.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes tls_random_source = dev:/dev/urandom

Of course, you need to have created the relevant PEM files. After these configuration changes have been made, we must configure SASL to authenticate users in some way. Users may be authenticated against the local password file, an OpenLDAP server, a MySQL or PostgreSQL database, and so on. The details of configuring SASL are beyond the scope of this document, but a number of online HOWTOs for these topics exist.

To test SASL functionality, it may be worthwhile to use saslpasswd2(8) to create a separate authentication database and configure saslauthd(8) accordingly.

# echo "pwcheck_method: saslauthd" > /usr/local/lib/sasl2/smtpd.conf % sudo /usr/local/sbin/saslpasswd2  testuser (follow prompts) % sudo /usr/local/sbin/saslauthd -a getpwent

You will then need to restart Postfix for SASL authentication over TLS. Note that in order for saslauthd to start at boot, OpenBSD administrators need to add appropriate lines to their /etc/rc.local script.