From 49524057e95c4fc3f98d45b68189c322e15509d2 Mon Sep 17 00:00:00 2001 From: Wietse Venema Date: Wed, 3 Feb 2010 00:00:00 -0500 Subject: [PATCH] postfix-2.8-20100203 --- postfix/HISTORY | 34 + .../README_FILES/ADDRESS_VERIFICATION_README | 95 +- postfix/README_FILES/OVERVIEW | 63 +- postfix/README_FILES/SASL_README | 1688 ++++++++---- postfix/README_FILES/SOHO_README | 170 +- postfix/README_FILES/TLS_README | 2 +- postfix/RELEASE_NOTES | 111 +- postfix/RELEASE_NOTES-2.7 | 175 ++ postfix/WISHLIST | 43 +- postfix/html/ADDRESS_VERIFICATION_README.html | 138 +- postfix/html/OVERVIEW.html | 125 +- postfix/html/SASL_README.html | 2419 +++++++++++++---- postfix/html/SOHO_README.html | 252 +- postfix/html/TLS_README.html | 2 +- postfix/html/pcre_table.5.html | 8 +- postfix/html/postconf.5.html | 175 +- postfix/html/postqueue.1.html | 6 +- postfix/html/regexp_table.5.html | 8 +- postfix/html/smtpd.8.html | 36 +- postfix/html/verify.8.html | 22 +- postfix/man/man1/postqueue.1 | 3 +- postfix/man/man5/pcre_table.5 | 3 +- postfix/man/man5/postconf.5 | 160 +- postfix/man/man5/regexp_table.5 | 3 +- postfix/man/man8/smtpd.8 | 6 +- postfix/man/man8/verify.8 | 20 +- postfix/mantools/make_soho_readme | 11 +- postfix/mantools/postlink | 1 + .../proto/ADDRESS_VERIFICATION_README.html | 138 +- postfix/proto/OVERVIEW.html | 125 +- postfix/proto/SASL_README.html | 2419 +++++++++++++---- postfix/proto/TLS_README.html | 2 +- postfix/proto/pcre_table | 3 +- postfix/proto/postconf.proto | 173 +- postfix/proto/regexp_table | 3 +- postfix/src/global/mail_version.h | 4 +- postfix/src/postqueue/postqueue.c | 3 +- postfix/src/proxymap/proxymap.c | 6 - postfix/src/smtpd/smtpd.c | 10 +- postfix/src/smtpd/smtpd_proxy.c | 21 +- postfix/src/trivial-rewrite/trivial-rewrite.c | 6 - postfix/src/verify/verify.c | 20 +- 42 files changed, 6248 insertions(+), 2464 deletions(-) create mode 100644 postfix/RELEASE_NOTES-2.7 diff --git a/postfix/HISTORY b/postfix/HISTORY index 4c0e83677..9522f47f1 100644 --- a/postfix/HISTORY +++ b/postfix/HISTORY @@ -15675,3 +15675,37 @@ Apologies for any names omitted. with Postfix 2.6 and earlier, or specify a non-empty next-hop filter destination. Files: *qmgr/qmgr_message.c proto/access, proto/header_checks, proto/postconf.proto, proto/FILTER_README. + +20100120 + + Cleanup: detect illegal pipelining after HELO, EHLO. File: + smtpd/smtpd.c. + +20100128 + + Documentation: streamlined the decriptions of protocol and + cipher tweaks. Victor Duchovni. Files: proto/TLS_README, + proto/postconf.proto. + +20100131 + + Documentation: the address verification database is now + persistent by default. This, combined with the now default + stress-dependent configuration, improves the performance + limits and simplifies database maintenance. Files: + proto/ADDRESS_VERIFICATION_README, verify/verify.c. + + Cleanup: undo the proxymap and trivial-rewrite max_idle=1s + override that was introduced with Postfix 2.3. It did not + help to retire long-lived proxymap or trivial-rewrite + processes on busy servers, and worsened performance on + low-traffic servers. The reduced ipc_ttl value (introduced + with Postfix 2.4) already solves the problem of retiring + long-lived proxymap or trivial-rewrite processes. Files: + proxymap/proxymap.c, trivial-rewrite/trivial-rewrite.c. + +20100202 + + Documentation: major revision of SASL_README with many + details on how to configure Cyrus SASL internals. Patrick + Koetter. File: proto/SASL_README.html diff --git a/postfix/README_FILES/ADDRESS_VERIFICATION_README b/postfix/README_FILES/ADDRESS_VERIFICATION_README index 4baf27a46..97dd381c3 100644 --- a/postfix/README_FILES/ADDRESS_VERIFICATION_README +++ b/postfix/README_FILES/ADDRESS_VERIFICATION_README @@ -4,10 +4,10 @@ PPoossttffiixx AAddddrreessss VVeerriiffiiccaattiioonn WWAARRNNIINNGG -The sender/recipient address verification feature described in this document is -suitable only for low-traffic sites. It performs poorly under high load; -excessive sender address verification activity may even cause your site to be -blacklisted by some providers. See the "Limitations" section below for details. +Recipient address verification may cause an increased load on down-stream +servers in the case of a dictionary attack or a flood of backscatter bounces. +Sender address verification may cause your site to be blacklisted by some +providers. See also the "Limitations" section below for more. WWhhaatt PPoossttffiixx aaddddrreessss vveerriiffiiccaattiioonn ccaann ddoo ffoorr yyoouu @@ -18,8 +18,8 @@ verified to be deliverable. The technique has obvious uses to reject junk mail with an unreplyable sender address. -The technique may also be useful to block mail for undeliverable recipients, -for example on a mail relay host that does not have a list of all the valid +The technique is also useful to block mail for undeliverable recipients, for +example on a mail relay host that does not have a list of all the valid recipient addresses. This prevents undeliverable junk mail from entering the queue, so that Postfix doesn't have to waste resources trying to send MAILER- DAEMON messages back. @@ -47,18 +47,26 @@ the Postfix MTA itself, or it could be a remote MTA (SMTP interruptus). Probe messages are like normal mail, except that they are never delivered, deferred or bounced; probe messages are always discarded. - Postfix Postfix Address - Internet -> SMTP <-> verify <-> verification - server server database + + probe Postfix + message -> mail + queue + Postfix Postfix -> + Internet -> SMTP <-> verify + server server | + v - | ^ - probe delivery - messages status - v | + <- Postfix + probe <- delivery -> Local + status agents -> Remote + ^ + | + v + - Postfix Postfix - queue -> delivery - agents + Address + verification + database With Postfix address verification turned on, normal mail will suffer only a short delay of up to 6 seconds while an address is being verified for the first @@ -77,7 +85,8 @@ LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffi address, without actually delivering mail to it. If the nearest MTA accepts the address, then Postfix assumes that the address is deliverable. In reality, mail for a remote address can bounce AFTER the nearest MTA accepts - the recipient address. + the recipient address, or AFTER the nearest MTA accepts the message + content. * Some sites may blacklist you when you are probing them too often (a probe is an SMTP session that does not deliver mail), or when you are probing @@ -95,30 +104,31 @@ LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffi * Postfix assumes that an address is undeliverable when the nearest MTA for the address rejects the probe, regardless of the reason for rejection (client rejected, HELO rejected, MAIL FROM rejected, etc.). Thus, Postfix - rejects mail when the sender's MTA rejects mail from your machine. This is - a good thing. + rejects an address when the nearest MTA for that address rejects mail from + your machine for any reason. This is not a limitation, but it is mentioned + here just in case people believe that it is a limitation. - * Unfortunately, some major sites such as YAHOO do not reject unknown - addresses in reply to the RCPT TO command, but report a delivery failure in - response to end of DATA after a message is transferred. Postfix address - verification does not work with such sites. + * Unfortunately, some sites do not reject unknown addresses in reply to the + RCPT TO command, but report a delivery failure in response to end of DATA + after a message is transferred. Postfix address verification does not work + with such sites. - * By default, Postfix probe messages have "double-bounce@$myorigin" as the - sender address (with Postfix versions before 2.5, the default is + * By default, Postfix probe messages have a sender address "double- + bounce@$myorigin" (with Postfix versions before 2.5, the default is "postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does not reject mail for this address. - You can change this into the null address ("address_verify_sender ="). This - is UNSAFE because address probes will fail with mis-configured sites that - reject MAIL FROM: <>, while probes from "postmaster@$myorigin" would - succeed. + You can change the probe sender address into the null address + ("address_verify_sender ="). This is UNSAFE because address probes will + fail with mis-configured sites that reject MAIL FROM: <>, while probes from + "postmaster@$myorigin" would succeed. RReecciippiieenntt aaddddrreessss vveerriiffiiccaattiioonn -As mentioned earlier, recipient address verification may be useful to block -mail for undeliverable recipients on a mail relay host that does not have a -list of all valid recipient addresses. This can help to prevent the mail queue -from filling up with MAILER-DAEMON messages. +As mentioned earlier, recipient address verification is useful to block mail +for undeliverable recipients on a mail relay host that does not have a list of +all valid recipient addresses. This can help to prevent the mail queue from +filling up with MAILER-DAEMON messages. Recipient address verification is relatively straightforward and there are no surprises. If a recipient probe fails, then Postfix rejects mail for the @@ -127,9 +137,10 @@ the recipient address. However, recipient address verification probes can increase the load on down-stream MTAs when you're being flooded by backscatter bounces, or when some spammer is mounting a dictionary attack. -By default, address verification results are not saved. To avoid probing the -same address repeatedly, you can store the result in a persistent database as -described later. +By default, address verification results are saved in a persistent database +(Postfix version 2.7 and later; with earlier versions, specify the database in +main.cf as described later). The persistent database helps to avoid probing the +same address repeatedly. /etc/postfix/main.cf: smtpd_recipient_restrictions = @@ -177,11 +188,13 @@ verification for specific domains that often appear in forged email. # Postfix 2.6 and later. # unverified_sender_defer_code = 250 + # Default setting for Postfix 2.7 and later. # Note 1: Be sure to read the "Caching" section below! # Note 2: Avoid hash files here. Use btree instead. address_verify_map = btree:/var/lib/postfix/verify /etc/postfix/sender_access: + # Don't do this when you handle lots of email. aol.com reject_unverified_sender hotmail.com reject_unverified_sender bigfoot.com reject_unverified_sender @@ -216,6 +229,7 @@ be blocked: # Postfix 2.6 and later. # unverified_sender_reject_reason = Address verification failed + # Default setting for Postfix 2.7 and later. # Note 1: Be sure to read the "Caching" section below! # Note 2: Avoid hash files here. Use btree instead. address_verify_map = btree:/var/lib/postfix/verify @@ -262,10 +276,11 @@ probe fails with some temporary error. AAddddrreessss vveerriiffiiccaattiioonn ddaattaabbaassee To improve performance, the Postfix verify(8) daemon can save address -verification results to a persistent database. The address_verify_map (NOTE: -singular) configuration parameter specifies persistent storage for sender or -recipient address verification results. If you specify an empty value, all -address verification results are lost after "postfix reload" or "postfix stop". +verification results to a persistent database. This is enabled by default with +Postfix 2.7 and later. The address_verify_map (NOTE: singular) configuration +parameter specifies persistent storage for sender or recipient address +verification results. If you specify an empty value, all address verification +results are lost after "postfix reload" or "postfix stop". /etc/postfix/main.cf: # Default setting for Postfix 2.7 and later. diff --git a/postfix/README_FILES/OVERVIEW b/postfix/README_FILES/OVERVIEW index 9b01a8439..95a3056b9 100644 --- a/postfix/README_FILES/OVERVIEW +++ b/postfix/README_FILES/OVERVIEW @@ -336,19 +336,60 @@ queues. * The verify(8) server verifies that a sender or recipient address is deliverable before the smtpd(8) server accepts it. The verify(8) server - injects probe messages into the Postfix queue and processes status updates - from delivery agents and/or queue manager. This process is described in the - ADDRESS_VERIFICATION_README document. The verify(8) service is available - with Postfix version 2.1 and later. + queries a cache with address verification results. If a result is not + found, the verify(8) server injects a probe message into the Postfix queue + and processes the status update from a delivery agent or queue manager. + This process is described in the ADDRESS_VERIFICATION_README document. The + verify(8) service is available with Postfix version 2.1 and later. - qmgr(8) Delivery - Network -> smtpd(8) <-> verify(8) -> cleanup(8) -> Postfix -> agents - queue + + probe Postfix + message -> mail + queue + Network -> smtpd(8) <-> verify(8) -> - \ | / - v - \ / - <- <- + | + v + + <- probe Postfix -> Local + status <- delivery -> Network + ^ agents + | + v + + + Address + verification + cache + + * The postscreen(8) server can be put "in front" of Postfix smtpd(8) + processes. Its purpose is to accept connections from the network and to + decide what SMTP clients are allowed to talk to Postfix. According to the + 2008 MessageLabs annual report, 81% of all email was spam, and 90% of that + was sent by botnets. While postscreen(8) keeps the zombies away, more smtpd + (8) processes remain available for legitimate clients. + + The postscreen(8) server is still evolving, and is likely to undergo + changes that break compatibility with earlier versions. For this reason the + postscreen(8) server is not installed with the stable Postfix release. + + zombie + + \ + + zombie - - smtpd(8) + + \ / + + other --- postscreen(8) + + / \ + + other - - smtpd(8) + + / + + zombie PPoossttffiixx ssuuppppoorrtt ccoommmmaannddss diff --git a/postfix/README_FILES/SASL_README b/postfix/README_FILES/SASL_README index bc57d5025..9f7c4289d 100644 --- a/postfix/README_FILES/SASL_README +++ b/postfix/README_FILES/SASL_README @@ -2,66 +2,1164 @@ PPoossttffiixx SSAASSLL HHoowwttoo ------------------------------------------------------------------------------- -WWAARRNNIINNGG +WWaarrnniinngg People who go to the trouble of installing Postfix may have the expectation -that Postfix is more secure than some other mailers. The Cyrus SASL library is -a lot of code. With this, Postfix becomes as secure as other mail systems that -use the Cyrus SASL library. Dovecot provides an alternative that may be worth -considering. +that Postfix is more secure than some other mailers. The Cyrus SASL library +contains a lot of code. With this, Postfix becomes as secure as other mail +systems that use the Cyrus SASL library. Dovecot provides an alternative that +may be worth considering. -HHooww PPoossttffiixx uusseess SSAASSLL aauutthheennttiiccaattiioonn iinnffoorrmmaattiioonn +HHooww PPoossttffiixx uusseess SSAASSLL aauutthheennttiiccaattiioonn -Postfix SASL support (RFC 4954, formerly RFC 2554) can be used to authenticate -remote SMTP clients to the Postfix SMTP server, and to authenticate the Postfix -SMTP client to a remote SMTP server. +When an SMTP client connects to an SMTP server, the server needs to decide +whether that client is authorized to send mail to remote destinations, or +whether the client can send mail only to the destinations that the server +itself is responsible for. Usually, the SMTP server will allow mail to remote +destinations only if the client's IP address is in the "same network" as the +server's IP address. -When receiving mail, the Postfix SMTP server logs the client-provided username, -authentication method, and sender address to the maillog file, and optionally -grants mail access via the permit_sasl_authenticated UCE restriction. +Sometimes the SMTP client and server are in different networks, but the client +still needs "same network" privileges. To address this problem, Postfix +supports SASL authentication (RFC 4954, formerly RFC 2554). With this a remote +SMTP client can authenticate to the Postfix SMTP server, and the Postfix SMTP +client can authenticate to a remote SMTP server. Once the client is +authenticated the server can give it "same network" privileges. -When sending mail, the Postfix SMTP client can look up the remote SMTP server -hostname or destination domain (the address right-hand part) in a SASL password -table, and if a username/password is found, it will use that username and -password to authenticate to the remote SMTP server. And as of version 2.3, -Postfix can be configured to search its SASL password table by the sender email -address. +Postfix does not implement SASL itself, but instead uses existing +implementations as building blocks. This means that some SASL-related +configuration will involve files that belong to Postfix, while other +configuration will involve files that belong to the specific SASL +implementation that Postfix will use. This document covers both the Postfix and +non-Postfix configuration. -This document covers the following topics: +You can read more about the following topics: - * What SASL implementations are supported - * Building Postfix with Dovecot SASL support - * Building the Cyrus SASL library - * Building Postfix with Cyrus SASL support - * Enabling SASL authentication in the Postfix SMTP server - * Dovecot SASL configuration for the Postfix SMTP server - * Cyrus SASL configuration for the Postfix SMTP server - * Testing SASL authentication in the Postfix SMTP server - * Trouble shooting the SASL internals - * Enabling SASL authentication in the Postfix SMTP client - * Supporting multiple ISP accounts in the Postfix SMTP client + * Configuring SASL authentication in the Postfix SMTP server + * Configuring SASL authentication in the Postfix SMTP/LMTP client + * Building Postfix with SASL support + * Using Cyrus SASL version 1.5.x * Credits -WWhhaatt SSAASSLL iimmpplleemmeennttaattiioonnss aarree ssuuppppoorrtteedd +CCoonnffiigguurriinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr -This document describes Postfix with the following SASL implementations: +As mentioned earlier, SASL is implemented separately from Postfix. For this +reason, configuring SASL authentication in the Postfix SMTP server involves two +different steps: - * Cyrus SASL version 1 (client and server). + * Configuring the SASL implementation to offer a list of mechanisms that are + suitable for SASL authentication and, depending on the SASL implementation + used, configuring authentication backends that verify the remote SMTP + client's authentication data against the system password file or some other + database. - * Cyrus SASL version 2 (client and server). + * Configuring the Postfix SMTP server to enable SASL authentication, and to + authorize clients to relay mail or to control what envelope sender + addresses the client may use. - * Dovecot protocol version 1 (server only, Postfix version 2.3 and later) +Successful authentication in the Postfix SMTP server requires a functional SASL +framework. Configuring SASL should therefore always be the first step. -Postfix version 2.3 introduces a plug-in mechanism that provides support for -multiple SASL implementations. To find out what implementations are built into -Postfix, use the following commands: +You can read more about the following topics: - % postconf -a (SASL support in the SMTP server) - % postconf -A (SASL support in the SMTP+LMTP client) + * Which SASL Implementations are supported? + * Configuring Dovecot SASL -Needless to say, these commands are not available in earlier Postfix versions. + o Postfix to Dovecot SASL communication -BBuuiillddiinngg PPoossttffiixx wwiitthh DDoovveeccoott SSAASSLL ssuuppppoorrtt + * Configuring Cyrus SASL + + o Cyrus SASL configuration file name + o Cyrus SASL configuration file location + o Postfix to Cyrus SASL communication + + * Enabling SASL authentication and authorization in the Postfix SMTP server + + o Enabling SASL authentication in the Postfix SMTP server + o Postfix SMTP Server Authentication Policy + o Enabling SASL authorization in the Postfix SMTP server + o Additional SMTP Server SASL options + + * Testing SASL authentication in the Postfix SMTP server + +WWhhiicchh SSAASSLL IImmpplleemmeennttaattiioonnss aarree ssuuppppoorrtteedd?? + +Currently the Postfix SMTP server supports the Cyrus SASL and Dovecot SASL +implementations. + + NNoottee + + Before Postfix version 2.3, Postfix had support only for Cyrus SASL. + Current Postfix versions have a plug-in architecture that can support + multiple SASL implementations. + +To find out what SASL implementations are compiled into Postfix, use the +following commands: + + % ppoossttccoonnff --aa (SASL support in the SMTP server) + % ppoossttccoonnff --AA (SASL support in the SMTP+LMTP client) + +These commands are available only with Postfix version 2.3 and later. + +CCoonnffiigguurriinngg DDoovveeccoott SSAASSLL + +Dovecot is a POP/IMAP server that must be configured to authenticate POP/IMAP +clients. When the Postfix SMTP server uses Dovecot SASL, it also reuses this +configuration. Consult the Dovecot documentation for how to configure and +operate the Dovecot authentication server. + +PPoossttffiixx ttoo DDoovveeccoott SSAASSLL ccoommmmuunniiccaattiioonn + +Communication between the Postfix SMTP server and Dovecot SASL happens via a +UNIX-domain socket. The socket pathname and the list of mechanisms offered to +Postfix need to be specified on the Dovecot server side in dovecot.conf. + +The following example assumes that the Postfix queue is under /var/spool/ +postfix/. + + 1 /etc/dovecot.conf: + 2 auth default { + 3 mechanisms = plain login + 4 passdb pam { + 5 } + 6 userdb passwd { + 7 } + 8 socket listen { + 9 client { + 10 path = /var/spool/postfix/private/auth + 11 mode = 0660 + 12 user = postfix + 13 group = postfix + 14 } + 15 } + 16 } + +Line 3 provides plain and login as mechanisms for the Postfix SMTP server, line +10 places the Dovecot SASL socket in /var/spool/postfix/private/auth, and lines +11-13 limit read+write permissions to user and group postfix only. + +Proceed with the section "Enabling SASL authentication and authorization in the +Postfix SMTP server" to turn on and use SASL in the Postfix SMTP server. + +CCoonnffiigguurriinngg CCyyrruuss SSAASSLL + +The Cyrus SASL framework was supports a wide variety of applications. Different +applications may require different configurations. As a consequence each +application may have its own configuration file. + +The first step configuring Cyrus SASL is to determine name and location of a +configuration file that describes how the Postfix SMTP server will use the SASL +framework. + +CCyyrruuss SSAASSLL ccoonnffiigguurraattiioonn ffiillee nnaammee + +The name of the configuration file (default: smtpd.conf) is configurable. It is +a concatenation from a value that the Postfix SMTP server sends to the Cyrus +SASL library, and the suffix .conf, added by Cyrus SASL. + +The value sent by Postfix is the name of the server component that will use +Cyrus SASL. It defaults to smtpd and is configured with one of the following +variables: + + /etc/postfix/main.cf: + # Postfix 2.3 and later + smtpd_sasl_path = smtpd + + # Postfix < 2.3 + smtpd_sasl_application_name = smtpd + +CCyyrruuss SSAASSLL ccoonnffiigguurraattiioonn ffiillee llooccaattiioonn + +The location where Cyrus SASL searches for the named file depends on the Cyrus +SASL version and the OS/distribution used. + +You can read more about the following topics: + + * Cyrus SASL version 2.x searches for the configuration file in /usr/lib/ + sasl2/. + + * Cyrus SASL version 2.1.22 and newer additionally search in /etc/sasl2/. + + * Some Postfix distributions are modified and look for the Cyrus SASL + configuration file in /etc/postfix/sasl/, /var/lib/sasl2/ etc. See the + distribution-specific documentation to determine the expected location. + + NNoottee + + Cyrus SASL searches /usr/lib/sasl2/ first. If it finds the specified + configuration file there, it will not examine other locations. + +PPoossttffiixx ttoo CCyyrruuss SSAASSLL ccoommmmuunniiccaattiioonn + +As the Postfix SMTP server is linked with the Cyrus SASL library libsasl, +communication between Postfix and Cyrus SASL takes place by calling functions +in the SASL library. + +The SASL library may use an external password verification service, or an +internal plugin to connect to authentication backends and verify the SMTP +client's authentication data against the system password file or other +databases. + +The following table shows typical combinations discussed in this document: + + _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + | aauutthheennttiiccaattiioonn bbaacckkeenndd |ppaasssswwoorrdd vveerriiffiiccaattiioonn sseerrvviiccee // pplluuggiinn| + |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | + |/etc/shadow |saslauthd | + |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | + |PAM |saslauthd | + |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | + |IMAP server |saslauthd | + |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | + |sasldb |sasldb | + |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | + |MySQL, PostgreSQL, SQLite|sql | + |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | + |LDAP |ldapdb | + |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | + + NNoottee + + Read the Cyrus SASL documentation for other backends it can use. + +ssaassllaauutthhdd -- CCyyrruuss SSAASSLL ppaasssswwoorrdd vveerriiffiiccaattiioonn sseerrvviiccee + +Communication between the Postfix SMTP server (read: Cyrus SASL's libsasl) and +the saslauthd server takes place over a UNIX-domain socket. + +saslauthd usually establishes the UNIX domain socket in /var/run/saslauthd/ and +waits for authentication requests. The Postfix SMTP server must have +read+execute permission to this directory or authentication attempts will fail. + + IImmppoorrttaanntt + + Some distributions require the user postfix to be member of a special group + e.g. sasl, otherwise it will not be able to access the saslauthd socket + directory. + +The following example configures the Cyrus SASL library to contact saslauthd as +its password verification service: + + /etc/sasl2/smtpd.conf: + pwcheck_method: saslauthd + mech_list: PLAIN LOGIN + + IImmppoorrttaanntt + + Do not specify any other mechanisms in mech_list than PLAIN or LOGIN when + using saslauthd! It can only handle these two mechanisms, and + authentication will fail if clients are allowed to choose other mechanisms. + + IImmppoorrttaanntt + + Plaintext mechanisms (PLAIN, LOGIN) send credentials unencrypted. This + information should be protected by an additional security layer such as a + TLS-encrypted SMTP session (see: TLS_README). + +Additionally the saslauthd server itself must be configured. It must be told +which authentication backend to turn to for password verification. The backend +is choosen as a command line option when saslauthd is started and will be shown +in the following examples. + + NNoottee + + Some distributions use a configuration file to provide saslauthd command + line options to set e.g. the authentication backend. Typical locations are + /etc/sysconfig/saslauthd or /etc/default/saslauthd. + +UUssiinngg ssaassllaauutthhdd wwiitthh //eettcc//sshhaaddooww + +Access to the /etc/shadow system password file requires root privileges. The +Postfix SMTP server (and in consequence libsasl linked to the server) runs with +the least privilege possible. Direct access to /etc/shadow would not be +possible without breaking the Postfix security architecture. + +The saslauthd socket builds a safe bridge. Postfix, running as limited user +postfix, can access the UNIX-domain socket that saslauthd receives commands on; +saslauthd, running as privileged user root, has the privileges required to +access the shadow file. + +The saslauthd server verifies passwords against the authentication backend / +etc/shadow if started like this: + + % ssaassllaauutthhdd --aa sshhaaddooww + +See section "Testing saslauthd authentication" for test instructions. + +UUssiinngg ssaassllaauutthhdd wwiitthh PPAAMM + +Cyrus SASL can use the PAM framework to authenticate credentials. saslauthd +uses the PAM framework when started like this: + + % ssaassllaauutthhdd --aa ppaamm + + NNoottee + + PAM configuration for the Postfix SMTP server is usually given in /etc/ + pam.d/smtp and is beyond the scope of this document. + +See section "Testing saslauthd authentication" for test instructions. + +UUssiinngg ssaassllaauutthhdd wwiitthh aann IIMMAAPP sseerrvveerr + +saslauthd can verify the SMTP client credentials by using them to log into an +IMAP server. If the login succeeds, SASL authentication also succeeds. +saslauthd contacts an IMAP server when started like this: + + % ssaassllaauutthhdd --aa rriimmaapp --OO iimmaapp..eexxaammppllee..ccoomm + + NNoottee + + The option "-O imap.example.com" specifies the IMAP server saslauthd should + contact when it verifies credentials. + + IImmppoorrttaanntt + + saslauthd sends IMAP login information unencrypted. Any IMAP session + leaving the local host should be protected by an additional security layer + such as an SSL tunnel. + +See section "Testing saslauthd authentication" for test instructions. + +TTeessttiinngg ssaassllaauutthhdd aauutthheennttiiccaattiioonn + +Cyrus SASL provides the testsaslauthd utility to test saslauthd authentication. +The username and password are given as command line arguments. The example +shows the response when authentication is successful: + + % tteessttssaassllaauutthhdd --uu uusseerrnnaammee --pp ppaasssswwoorrdd + 0: OK "Success." + + NNoottee + + Sometimes the testsaslauthd program is not distributed with a the Cyrus + SASL main package. In that case, it may be distributed with -devel, -dev or + -debug packages. + +Specify an additional "-s smtp" if saslauthd was configured to contact the PAM +authentication framework and an additional "-f //ppaatthh//ttoo//ssoocckkeettddiirr//mmuuxx" if +saslauthd establishes the UNIX-domain socket in a non-default location. + +If authentication succeeds, proceed with the section "Enabling SASL +authentication and authorization in the Postfix SMTP server". + +CCyyrruuss SSAASSLL PPlluuggiinnss -- aauuxxiilliiaarryy pprrooppeerrttyy pplluuggiinnss + +Cyrus SASL uses a plugin infrastructure (called auxprop) to expand libsasl's +capabilities. Currently Cyrus SASL sources provide three authentication +plugins. + + sasldb + Accounts are stored stored in a Cyrus SASL Berkeley DB database + + sql + Accounts are stored in a SQL database + + ldapdb + Accounts are stored stored in an LDAP database + + IImmppoorrttaanntt + + These three plugins support shared-secret mechanisms i.e. CRAM-MD5, DIGEST- + MD5 and NTLM. These mechanisms send credentials encrypted but their + verification process requires the password to be available in plaintext. + Consequently passwords cannot (!) be stored in encrypted form. + +TThhee ssaassllddbb pplluuggiinn + +The sasldb auxprop plugin authenticates credentials stored in a Berkeley DB +database. The database schema is specific to Cyrus SASL. The database is +usually located at /etc/sasldb2. + + NNoottee + + The sasldb2 file contains passwords in plaintext, and should have + read+write access only to user postfix or a group that postfix is member + of. + +The saslpasswd2 command-line utility creates and maintains the database: + + % ssaassllppaasssswwdd22 --cc --uu eexxaammppllee..ccoomm uusseerrnnaammee + Password: + Again (for verification): + +This command creates an account uusseerrnnaammee@@eexxaammppllee..ccoomm. + + IImmppoorrttaanntt + + users must specify uusseerrnnaammee@@eexxaammppllee..ccoomm as login name, not uusseerrnnaammee. + +Run the following command to reuse the Postfix mydomain parameter value as the +login domain: + + % ssaassllppaasssswwdd22 --cc --uu ``ppoossttccoonnff --hh mmyyddoommaaiinn`` uusseerrnnaammee + Password: + Again (for verification): + + NNoottee + + Run saslpasswd2 without any options for further help on how to use the + command. + +The sasldblistusers2 command lists all existing users in the sasldb database: + + % ssaassllddbblliissttuusseerrss22 + username1@example.com: password1 + username2@example.com: password2 + +Configure libsasl to use sasldb with the following instructions: + + /etc/sasl2/smtpd.conf: + pwcheck_method: auxprop + auxprop_plugin: sasldb + mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM + + NNoottee + + In the above example adjust mech_list to the mechanisms that are applicable + for your environment. + +TThhee ssqqll pplluuggiinn + +The sql auxprop plugin is a generic SQL plugin. It provides access to +credentials stored in a MySQL, a PostgreSQL or a SQLite database. + + NNoottee + + The shared-secret mechanisms (CRAM-MD5, etc.) require that the SASL client + passwords are stored as plaintext. + + TTiipp + + Use "saslauthd > pam > (pam database module)" to verify encrypted passwords + in an SQL database. + +The following example configures libsasl to use the sql plugin and connects it +to a PostgreSQL server: + + /etc/sasl2/smtpd.conf: + pwcheck_method: auxprop + auxprop_plugin: sql + mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM + sql_engine: pgsql + sql_hostnames: 127.0.0.1, 192.0.2.1 sql_user: username + sql_passwd: secret + sql_database: dbname + sql_select: SELECT password FROM users WHERE user = '%u'@'%r' + + NNoottee + + Set appropriate permissions if smtpd.conf contains a password. The file + should be readable by the postfix user. + + NNoottee + + In the above example, adjust mech_list to the mechanisms that are + applicable for your environment. + +The sql plugin has the following configuration options: + + sql_engine + Specify mysql to connect to a MySQL server, pgsql for a PostgreSQL + server or sqlite for an SQLite database + + sql_hostnames + Specify one or more servers (hostname or hostname:port) separated by + commas. + + NNoottee + + With MySQL servers, specify localhost to connect over a UNIX-domain + socket, and specify 127.0.0.1 to connect over a TCP socket. + + sql_user + The login name to gain access to the database. + + sql_passwd + The password to gain access to the database. + + sql_database + The name of the database to connect to. + + sql_select + The SELECT statement that should retrieve the plaintext password from a + database table. + + IImmppoorrttaanntt + + Do not enclose the statement in quotes! Use single quotes to escape + macros! + +The sql plugin provides macros to build sql_select statements. They will be +replaced with arguments sent from the client. The following macros are +available: + + %u + The name of the user whose properties are being selected. + + %p + The name of the property being selected. While this could technically + be anything, Cyrus SASL will try userPassword and cmusaslsecretMECHNAME + (where MECHNAME is the name of a SASL mechanism). + + %r + The name of the realm to which the user belongs. This could be the + KERBEROS realm, the fully-qualified domain name of the computer the + SASL application is running on, or the domain after the "@" in a + username. + +TThhee llddaappddbb pplluuggiinn + +The ldapdb auxprop plugin provides access to credentials stored in an OpenLDAP +LDAP server. It is the only plugin that implements proxy authorization. + +Proxy authorization in this context means: The ldapdb plugin must SASL +authenticate with the OpenLDAP server. The server then decides if the ldapdb +plugin should be authorized to read the authenticating user's password. Once +the ldapdb plugin has gone through proxy authorization it may proceed and +authenticate the remote SMTP client's credentials. + +In a nutshell: Configuring ldapdb means authentication and authorization must +be configured twice - once in the Postfix SMTP server to authenticate and +authorize the remote SMTP client, and once in the OpenLDAP slapd server to +authenticate and authorize the ldapdb plugin. + +This example configures libsasl to use the ldapdb plugin and the plugin to +connect to an OpenLDAP server: + + /etc/sasl2/smtpd.conf: + pwcheck_method: auxprop + auxprop_plugin: ldapdb + mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5 + ldapdb_uri: ldap://localhost + ldapdb_id: proxyuser + ldapdb_pw: password + ldapdb_mech: DIGEST-MD5 + + IImmppoorrttaanntt + + Set appropriate permissions if smtpd.conf contains a password. The file + should be readable by the postfix user. + + NNoottee + + The shared-secret mechanisms (CRAM-MD5, etc.) require that the SASL client + passwords are stored as plaintext. + +The following is a summary of applicable smtpd.conf file entries: + + auxprop_plugin + Specify ldapdb to enable the plugin. + + ldapdb_uri + Specify either ldapi:// for to connect over a UNIX-domain socket, ldap: + // for an unencrypted TCP connection or ldaps:// for an encrypted TCP + connection. + + ldapdb_id + The login name to authenticate the ldapdb plugin to the LDAP server + (proxy authorization). + + ldapdb_pw + The password (in plaintext) to authenticate the ldapdb plugin to the + LDAP server (proxy authorization). + + ldapdb_mech + The mechanism to authenticate the ldapdb plugin to the OpenLDAP slapd + server. + + NNoottee + + Specify a mechanism here that is supported by the OpenLDAP slapd + server. + + ldapdb_rc (optional) + The path to a file containing individual configuration options for the + ldapdb LDAP client (libldap). This allows to specify a TLS client + certificate which in turn can be used to use the SASL EXTERNAL + mechanism. + + NNoottee + + This mechanism supports authentication over an encrypted transport + layer, which is recommended if the plugin must connect to an + OpenLDAP server on a remote machine. + + ldapdb_starttls (optional) + The TLS policy for connecting to the LDAP server. Specify either try or + demand. If the option is try the plugin will attempt to establish a + TLS-encrypted connection with the LDAP server, and will fallback to an + unencrypted connection if TLS fails. If the policy is demand and a TLS- + encrypted connection cannot be established, the connection fails + immediately. + +When the ldapdb plugin connects to the OpenLDAP server and successfully +authenticates, the OpenLDAP server decides if the plugin user is authorized to +read SASL account information. + +The following configuration gives an example of authorization configuration in +the OpenLDAP slapd server: + + /etc/openldap/slapd.conf: + authz-regexp + uid=(.*),cn=.*,cn=auth + ldap:///dc=example,dc=com??sub?cn=$1 + authz-policy to + +Here, the authz-regexp option serves for authentication of the ldapdb user. It +maps its login name to a DN in the LDAP directory tree where slapd can look up +the SASL account information. The authz-policy options defines the +authentication policy. In this case it grants authentication privileges "to" +the ldapdb plugin. + +The last configuration step is to tell the OpenLDAP slapd server where ldapdb +may search for usernames matching the one given by the mail client. The example +below adds an additional attribute ldapdb user object (here: authzTo because +the authz-policy is "to") and configures the scope where the login name +"proxyuser" may search: + + dn: cn=proxyuser,dc=example,dc=com + changetype: modify + add: authzTo + authzTo: dn.regex:uniqueIdentifier=(.*),ou=people,dc=example,dc=com + +Use the ldapmodify or ldapadd command to add the above attribute. + + NNoottee + + Read the chapter "Using SASL" in the OpenLDAP Admin Guide for more detailed + instructions to set up SASL authentication in OpenLDAP. + +EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn aanndd aauutthhoorriizzaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr + +By default the Postfix SMTP server uses the Cyrus SASL implementation. If the +Dovecot SASL implementation should be used, specify an smtpd_sasl_type value of +dovecot instead of cyrus: + + /etc/postfix/main.cf: + smtpd_sasl_type = dovecot + +Additionally set the path where the Postfix SMTP server can find the Dovecot +SASL socket: + + /etc/postfix/main.cf: + smtpd_sasl_path = private/auth + + NNoottee + + This example uses a pathname relative to the Postfix queue directory, so + that it will work whether or not the Postfix SMTP server runs chrooted. + +EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr + +Regardless of the SASL implementation type, enabling SMTP authentication in the +Postfix SMTP server always requires seting the smtpd_sasl_auth_enable option: + + /etc/postfix/main.cf: + smtpd_sasl_auth_enable = yes + +After a "postfix reload", SMTP clients will see the additional capability AUTH +in an SMTP session, followed by a list of authentication mechanisms the server +supports: + + % tteellnneett sseerrvveerr..eexxaammppllee..ccoomm 2255 + ... + 220 server.example.com ESMTP Postfix + EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm + 250-server.example.com + 250-PIPELINING + 250-SIZE 10240000 + 250-AUTH DIGEST-MD5 PLAIN CRAM-MD5 + ... + +However not all clients recognize the AUTH capability as defined by the SASL +authentication RFC. Some historical implementations expect the server to send +an "=" as separator between the AUTH verb and the list of mechanisms that +follows it. + +The broken_sasl_auth_clients configuration option lets Postfix repeat the AUTH +statement in a form that these broken clients understand: + + /etc/postfix/main.cf: + broken_sasl_auth_clients = yes + + NNoottee + + Enable this option for Outlook up to and including version 2003 and Outlook + Express up to version 6. This option does not hurt other clients. + +After "postfix reload", the Postfix SMTP server will propagate the AUTH +capability twice - once for compliant and once for broken clients: + + % tteellnneett sseerrvveerr..eexxaammppllee..ccoomm 2255 + ... + EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm + 250-server.example.com + 250-PIPELINING + 250-SIZE 10240000 + 250-AUTH DIGEST-MD5 PLAIN CRAM-MD5 + 250-AUTH=DIGEST-MD5 PLAIN CRAM-MD5 + ... + +PPoossttffiixx SSMMTTPP SSeerrvveerr AAuutthheennttiiccaattiioonn PPoolliiccyy + +The Postfix SMTP server provides a way to specify the properties of SASL +mechanisms that can be made available to the remote SMTP client. + +UUnneennccrryypptteedd SSMMTTPP sseessssiioonn + +The default policy is to allow any mechanism in the Postfix SMTP server except +for those based on anonymous authentication: + + /etc/postfix/main.cf: + # Specify a list of properties separated by comma or whitespace + smtpd_sasl_security_options = noanonymous + + IImmppoorrttaanntt + + Always set at least the noanonymous option. Otherwise, the Postfix SMTP + server can give strangers the same authorization as a properly- + authenticated client. + +Postfix can enforce the following policies on SASL authentication mechanisms: + + noanonymous + Don't use mechanisms that permit anonymous authentication. + + noplaintext + Don't use mechanisms that transmit unencrypted username and password + information. + + nodictionary + Don't use mechanisms that are vulnerable to dictionary attacks. + + forward_secrecy + Use only mechanisms that support forward secrecy (Dovecot SASL only). + + mutual_auth + Use only mechanisms that authenticate both the client and the server to + each other. + +EEnnccrryypptteedd SSMMTTPP sseessssiioonn ((TTLLSS)) + +A separate parameter controls Postfix SASL mechanism policy during a TLS- +encrypted SMTP session. The default is to copy the settings from the +unencrypted session: + + /etc/postfix/main.cf: + smtpd_sasl_tls_security_options = $smtpd_sasl_security_options + +A more sophisticated policy allows plaintext mechanisms, but only over a TLS- +encrypted connection: + + /etc/postfix/main.cf: + smtpd_sasl_security_options = noanonymous, noplaintext + smtpd_sasl_tls_security_options = noanonymous + +To offer SASL authentication only after a TLS-encrypted session has been +established specify this: + + /etc/postfix/main.cf: + smtpd_tls_auth_only = yes + +EEnnaabblliinngg SSAASSLL aauutthhoorriizzaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr + +After the client has authenticated with SASL, the Postfix SMTP server decides +what the remote SMTP client will be authorized for. Examples of possible SMTP +clients authorizations are: + + * Send a message to a remote recipient. + + * Use a specific envelope sender in the MAIL FROM command. + +These permissions are not enabled by default. + +MMaaiill rreellaayy aauutthhoorriizzaattiioonn + +The permit_sasl_authenticated restriction allows SASL-authenticated SMTP +clients to send mail to remote destinations. Add it to the list of +smtpd_recipient_restrictions as follows: + + /etc/postfix/main.cf: + smtpd_recipient_restrictions = + ... + permit_mynetworks + ppeerrmmiitt__ssaassll__aauutthheennttiiccaatteedd + reject_unauth_destination + ... + +EEnnvveellooppee sseennddeerr aaddddrreessss aauutthhoorriizzaattiioonn + +By default an SMTP client may specify any envelope sender address in the MAIL +FROM command. That is because the Postfix SMTP server only knows the remte SMTP +client hostname and IP address, but not the user who controls the remote SMTP +client. + +This changes the moment an SMTP client uses SASL authentication. Now, the +Postfix SMTP server knows who the sender is. Given a table of envelope sender +addresses and SASL login names, the Postfix SMTP server can decide if the SASL +authenticated client is allowed to use a particular envelope sender address: + + /etc/postfix/main.cf: + ssmmttppdd__sseennddeerr__llooggiinn__mmaappss == hhaasshh:://eettcc//ppoossttffiixx//ccoonnttrroolllleedd__eennvveellooppee__sseennddeerrss + + smtpd_recipient_restrictions = + ... + rreejjeecctt__sseennddeerr__llooggiinn__mmiissmmaattcchh + permit_sasl_authenticated + permit_mynetworks + reject_unauth_destination + ... + +The controlled_envelope_senders table specifies the binding between the sender +envelope addresses and its their SASL login names: + + /etc/postfix/controlled_envelope_senders + # envelope sender owners (SASL login names) + john@example.com john@example.com + helpdesk@example.com john@example.com, mary@example.com + postmaster admin@example.com + @example.net barney, fred, john@example.com, + mary@example.com + +With this, the reject_sender_login_mismatch restriction above will reject the +sender address in the MAIL FROM command if smtpd_sender_login_maps does not +specify the SMTP client's login name as an owner of that address. + +See also reject_authenticated_sender_login_mismatch and +reject_unauthenticated_sender_login_mismatch for additional control over the +SASL login name and the envelope sender. + +AAddddiittiioonnaall SSMMTTPP SSeerrvveerr SSAASSLL ooppttiioonnss + +Postfix provides a wide range of SASL authentication configuration options. The +next section lists a few that are discussed frequently. See postconf(5) for a +complete list. + +DDeeffaauulltt aauutthheennttiiccaattiioonn ddoommaaiinn + +Postfix can append a domain name (or any other string) to a SASL login name +that does not have a domain part, e.g. "john" instead of "john@example.com": + + /etc/postfix/main.cf: + smtpd_sasl_local_domain = example.com + +This is useful as a default setting and safety net for misconfigured clients, +or during a migration to an authentication method/backend that requires an +authentication REALM or domain name, before all SMTP clients are configured to +send such information. + +HHiiddiinngg SSAASSLL aauutthheennttiiccaattiioonn ffrroomm cclliieennttss oorr nneettwwoorrkkss + +Some clients insist on using SASL authentication if it is offered, even when +they are not configured to send credentials - and therefore they will always +fail and disconnect. + +Postfix can hide the AUTH capability from these clients/networks: + + /etc/postfix/main.cf: + smtpd_sasl_exceptions_networks = !192.0.2.171/32, 192.0.2.0/24 + +AAddddiinngg tthhee SSAASSLL llooggiinn nnaammee ttoo mmaaiill hheeaaddeerrss + +To report SASL login names in Received: message headers (Postfix version 2.3 +and later): + + /etc/postfix/main.cf: + smtpd_sasl_authenticated_header = yes + + NNoottee + + The SASL login names will be shared with the entire world. + +TTeessttiinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP SSeerrvveerr + +To test the server side, connect (for example, with telnet) to the Postfix SMTP +server port and you should be able to have a conversation as shown below. +Information sent by the client (that is, you) is shown in bold font. + + % tteellnneett sseerrvveerr..eexxaammppllee..ccoomm 2255 + ... + 220 server.example.com ESMTP Postfix + EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm + 250-server.example.com + 250-PIPELINING + 250-SIZE 10240000 + 250-ETRN + 250-AUTH DIGEST-MD5 PLAIN CRAM-MD5 + 250 8BITMIME + AAUUTTHH PPLLAAIINN AAHHRRllcc33QQAAddGGVVzzddHHBBhhcc33MM== + 235 Authentication successful + +Instead of AHRlc3QAdGVzdHBhc3M=, specify the base64-encoded form of +\0username\0password (the \0 is a null byte). The example above is for a user +named `test' with password `testpass'. + + CCaauuttiioonn + + When posting logs of the SASL negotiations to public lists, please keep in + mind that username/password information is trivial to recover from the + base64-encoded form. + +You can use one of the following commands to generate base64 encoded +authentication information: + + % ggeenn--aauutthh ppllaaiinn + username: uusseerrnnaammee + password: + +The ggeenn--aauutthh Perl script was written by John Jetmore and can be found at http:/ +/jetmore.org/john/code/gen-auth. + + % pprriinnttff ''\\00uusseerrnnaammee\\00ppaasssswwoorrdd'' || mmmmeennccooddee + +The mmmmeennccooddee command is part of the metamail software. + + % ppeerrll --MMMMIIMMEE::::BBaassee6644 --ee \\ + ''pprriinntt eennccooddee__bbaassee6644((""\\00uusseerrnnaammee\\00ppaasssswwoorrdd""));;'' + +MIME::Base64 is available from http://www.cpan.org/. + +CCoonnffiigguurriinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt + +The Postfix SMTP and the LMTP client can authenticate with a remote SMTP server +via the Cyrus SASL framework. At this time, the Dovecot SASL implementation +does not provide client functionality. + + NNoottee + + The examples in this section discuss only the SMTP client. Replace smtp_ + with lmtp_ to get the corresponding LMTP client configuration. + +You can read more about the following topics: + + * Enabling SASL authentication in the Postfix SMTP/LMTP client + * Configuring sender-dependent SASL authentication + * Postfix SMTP/LMTP client authentication policy + * Filtering server mechanism names in the Postfix SMTP/LMTP client + +EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt + +This section shows a typical scenario where the Postfix SMTP client sends all +messages via a mail gateway server that requires SASL authentication. To make +the example more readable we introduce it in two parts. + + /etc/postfix/main.cf: + smtp_sasl_auth_enable = yes + relayhost = [mail.isp.example] + # Alternative form: + # relayhost = [mail.isp.example]:submission + smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd + + * The smtp_sasl_auth_enable setting enables client-side authentication. We + will configure the client's username and password information in the second + part of the example. + + * The relayhost setting forces the Postfix SMTP to send all remote messages + to the specified mail server instead of trying to deliver them directly to + their destination. + + * In the relayhost setting, the "[" and "]" prevent the Postfix SMTP client + from looking up MX (mail exchanger) records for the enclosed name. + + * The relayhost destination may also specify a non-default TCP port. For + example, the alternative form [mail.isp.example]:submission tells Postfix + to connect to TCP network port 587, which is reserved for email client + applications. + + * The Postfix SMTP client is compatible with SMTP servers that use the non- + standard "AUTH=mmeetthhoodd....." syntax in response to the EHLO command; this + requires no additional Postfix client configuration. + + * The Postfix SMTP client does not support the obsolete "wrappermode" + protocol, which uses TCP port 465 on the SMTP server. See TLS_README for a + solution that uses the stunnel command. + + * With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP + client to send username and password information to the mail gateway + server. As discussed in the next section, the Postfix SMTP client supports + multiple ISP accounts. For this reason the username and password are stored + in a table that contains one username/password combination for each mail + gateway server. + + /etc/postfix/sasl_passwd: + # destination credentials + [mail.isp.example] username:password + # Alternative form: + # [mail.isp.example]:submission username:password + + IImmppoorrttaanntt + + Keep the SASL client password file in /etc/postfix, and make the file + read+write only for root to protect the username/password combinations + against other users. The Postfix SMTP client will still be able to read the + SASL client passwords. It opens the file as user root before it drops + privileges, and before entering an optional chroot jail. + + * Use the postmap command whenever you change the /etc/postfix/sasl_passwd + file. + + * If you specify the "[" and "]" in the relayhost destination, then you must + use the same form in the smtp_sasl_password_maps file. + + * If you specify a non-default TCP Port (such as ":submission" or ":587") in + the relayhost destination, then you must use the same form in the + smtp_sasl_password_maps file. + +CCoonnffiigguurriinngg SSeennddeerr--DDeeppeennddeenntt SSAASSLL aauutthheennttiiccaattiioonn + +Postfix supports different ISP accounts for different sender addresses (version +2.3 and later). This can be useful when one person uses the same machine for +work and for personal use, or when people with different ISP accounts share the +same Postfix server. + +To make this possible, Postfix supports per-sender SASL passwords and per- +sender relay hosts. In the example below, the Postfix SMTP client will search +the SASL password file by sender address before it searches that same file by +destination. Likewise, the Postfix trivial-rewrite(8) daemon will search the +per-sender relayhost file, and use the default relayhost setting only as a +final resort. + + /etc/postfix/main.cf: + smtp_sender_dependent_authentication = yes + sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay + smtp_sasl_auth_enable = yes + smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd + relayhost = [mail.isp.example] + # Alternative form: + # relayhost = [mail.isp.example]:submission + + /etc/postfix/sasl_passwd: + # Per-sender authentication; see also /etc/postfix/sender_relay. + user1@example.com username2:password2 + user2@example.net username2:password2 + # Login information for the default relayhost. + [mail.isp.example] username:password + # Alternative form: + # [mail.isp.example]:submission username:password + + /etc/postfix/sender_relay: + # Per-sender provider; see also /etc/postfix/sasl_passwd. + user1@example.com [mail.example.com]:submission + user2@example.net [mail.example.net] + + * If you are creative, then you can try to combine the two tables into one + single MySQL database, and configure different Postfix queries to extract + the appropriate information. + + * Specify dbm instead of hash if your system uses dbm files instead of db + files. To find out what lookup tables Postfix supports, use the command + "postconf -m". + + * Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change + the sasl_passwd table. + + * Execute the command "postmap /etc/postfix/sender_relay" whenever you change + the sender_relay table. + +PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt aauutthheennttiiccaattiioonn ppoolliiccyy + +Just like the Postfix SMTP server, the SMTP client has a policy that determines +which SASL mechanisms are acceptable and which are not. + +UUnneennccrryypptteedd SSMMTTPP sseessssiioonn + +The default policy is stricter than that of the Postfix SMTP server - plaintext +mechanisms are not allowed (nor is any anonymous mechanism): + + /etc/postfix/main.cf: + smtp_sasl_security_options = noplaintext, noanonymous + +Postfix can enforce the following policies on SASL authentication mechanisms: + + noanonymous + Don't use mechanisms that permit anonymous authentication. + + noplaintext + Don't use mechanisms that transmit unencrypted username and password + information. + + nodictionary + Don't use mechanisms that are vulnerable to dictionary attacks. + + mutual_auth + Use only mechanisms that authenticate both the client and the server to + each other. + +With the default policy shown above, the Postfix SMTP client will not send its +password over an unencrypted connection. This sometimes leads to authentication +failures if the remote server only offers plaintext authentication mechanisms. +In such cases the SMTP client will log the following error message: + + SASL authentication failure: No worthy mechs found + +The less secure approach to deal with this is to lower the security standards +and permit plaintext authentication mechanisms: + + /etc/postfix/main.cf: + smtp_sasl_security_options = noanonymous + +Needless to say, sending a username and password over an insecure channel is +undesirable. + +If the remote server supports TLS, you can protect the plaintext username and +password by turning on TLS in the Postfix SMTP client (see: TLS_README), and +configuring the client as discussed next. + +EEnnccrryypptteedd SSMMTTPP sseessssiioonn ((TTLLSS)) + +A separate parameter controls Postfix SASL mechanism policy during a TLS- +encrypted SMTP session. The default is to copy the settings from the +unencrypted session: + + /etc/postfix/main.cf: + smtp_sasl_tls_security_options = $smtp_sasl_security_options + +A more sophisticated policy allows plaintext mechanisms, but only over a TLS- +encrypted connection: + + /etc/postfix/main.cf: + smtpd_sasl_security_options = noanonymous, noplaintext + smtpd_sasl_tls_security_options = noanonymous + +FFiilltteerriinngg sseerrvveerr mmeecchhaanniissmm nnaammeess iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt + +Cyrus SASL always attempts to use the most secure authentication mechanism that +the remote SMTP server offers - even if the client side was not configured to +handle it! In such cases authentication will definitely fail. + +To prevent this, the Postfix SMTP client can filter the list of authentication +mechanism names from the remote SMTP server. Used correctly, the filter hides +unwanted mechanisms from the Cyrus SASL library, forcing the library to choose +from the mechanisms the Postfix filter passes through. + +The following example filters out everything but the mechanisms PLAIN and +LOGIN: + + /etc/postfix/main.cf: + smtp_sasl_mechanism_filter = plain, login + + NNoottee + + If the remote server does not offer any of the mechanisms on the filter + list, authentication will fail. + +We close this section with an example that passes every mechanism except for +GSSAPI and LOGIN: + + /etc/postfix/main.cf: + smtp_sasl_mechanism_filter = !gssapi, !login, static:all + +BBuuiillddiinngg PPoossttffiixx wwiitthh SSAASSLL ssuuppppoorrtt + +As mentioned elsewhere, Postfix supports two SASL implementations: Cyrus SASL +(SMTP client and server) and Dovecot SASL (SMTP server only). Both +implementations can be built into Postfix simultaneously. + + * Building Dovecot SASL support + * Building Cyrus SASL support + +BBuuiillddiinngg DDoovveeccoott SSAASSLL ssuuppppoorrtt These instructions assume that you build Postfix from source code as described in the INSTALL document. Some modification may be required if you build Postfix @@ -69,41 +1167,58 @@ from a vendor-specific source package. Support for the Dovecot version 1 SASL protocol is available in Postfix 2.3 and later. At the time of writing, only server-side SASL support is available, so -you can't use it to authenticate to your network provider's server. Dovecot -uses its own daemon process for authentication. This keeps the Postfix build -process simple, because there is no need to link extra libraries into Postfix. +you can't use it to authenticate the Postfix SMTP client to your network +provider's server. + +Dovecot uses its own daemon process for authentication. This keeps the Postfix +build process simple, because there is no need to link extra libraries into +Postfix. To generate the necessary Makefiles, execute the following in the Postfix top- level directory: - % make makefiles CCARGS='-DUSE_SASL_AUTH - - DDEF_SERVER_SASL_TYPE=\"dovecot\"' + % mmaakkee ttiiddyy # if you have left-over files from a previous build + % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==''--DDUUSSEE__SSAASSLL__AAUUTTHH \\ + --DDDDEEFF__SSEERRVVEERR__SSAASSLL__TTYYPPEE==\\""ddoovveeccoott\\""'' After this, proceed with "make" as described in the INSTALL document. -Notes: +NNoottee - * The "-DDEF_SERVER_SASL_TYPE" stuff is not necessary; it just makes Postfix - configuration a little more convenient because you don't have to specify - the SASL plug-in type in the Postfix main.cf file. + * The -DDEF_SERVER_SASL_TYPE=\"dovecot\" is not necessary; it just makes + Postfix configuration a little more convenient because you don't have to + specify the SASL plug-in type in the Postfix main.cf file (but this may + cause surprises when you switch to a later Postfix version that is built + with the default SASL type of sasl). - * If you also want support for LDAP or TLS, you will have to merge their - CCARGS and AUXLIBS into the above command line. + * If you also want support for LDAP or TLS (or for Cyrus SASL), you need to + merge their CCARGS and AUXLIBS options into the above command line; see the + LDAP_README and TLS_README for details. + + % mmaakkee ttiiddyy # if you have left-over files from a previous build + % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==''--DDUUSSEE__SSAASSLL__AAUUTTHH \\ + --DDDDEEFF__SSEERRVVEERR__SSAASSLL__TTYYPPEE==\\""ddoovveeccoott\\"" \\ + ......CCCCAARRGGSS ooppttiioonnss ffoorr LLDDAAPP oorr TTLLSS eettcc........'' \\ + AAUUXXLLIIBBSS==''......AAUUXXLLIIBBSS ooppttiioonnss ffoorr LLDDAAPP oorr TTLLSS eettcc........'' + +BBuuiillddiinngg CCyyrruuss SSAASSLL ssuuppppoorrtt BBuuiillddiinngg tthhee CCyyrruuss SSAASSLL lliibbrraarryy -Postfix appears to work with cyrus-sasl-1.5.x or cyrus-sasl-2.1.x, which are -available from: +Postfix works with cyrus-sasl-1.5.x or cyrus-sasl-2.1.x, which are available +from ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/. - ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/ + IImmppoorrttaanntt -IMPORTANT: if you install the Cyrus SASL libraries as per the default, you will -have to symlink /usr/lib/sasl -> /usr/local/lib/sasl for version 1.5.x or /usr/ -lib/sasl2 -> /usr/local/lib/sasl2 for version 2.1.x. + If you install the Cyrus SASL libraries as per the default, you will have + to create a symlink /usr/lib/sasl -> /usr/local/lib/sasl for version 1.5.x + or /usr/lib/sasl2 -> /usr/local/lib/sasl2 for version 2.1.x. -Reportedly, Microsoft Outlook (Express) requires the non-standard LOGIN -authentication method. To enable this authentication method, specify ``./ -configure --enable-login''. +Reportedly, Microsoft Outlook (Express) requires the non-standard LOGIN and/or +NTLM authentication mechanism. To enable these authentication mechanisms, build +the Cyrus SASL libraries with: + + % ..//ccoonnffiigguurree ----eennaabbllee--llooggiinn ----eennaabbllee--nnttllmm BBuuiillddiinngg PPoossttffiixx wwiitthh CCyyrruuss SSAASSLL ssuuppppoorrtt @@ -116,424 +1231,63 @@ include, and that the Cyrus SASL libraries are in /usr/local/lib. On some systems this generates the necessary Makefile definitions: -(for Cyrus SASL version 1.5.x): +Cyrus SASL version 2.1.x - % make tidy # if you have left-over files from a previous build - % make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \ - -I/usr/local/include" AUXLIBS="-L/usr/local/lib -lsasl" + % mmaakkee ttiiddyy # if you have left-over files from a previous build + % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH --DDUUSSEE__CCYYRRUUSS__SSAASSLL \\ + --II//uussrr//llooccaall//iinncclluuddee//ssaassll"" AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb --llssaassll22"" -(for Cyrus SASL version 2.1.x): +Cyrus SASL version 1.5.x - % make tidy # if you have left-over files from a previous build - % make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \ - -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib -lsasl2" + % mmaakkee ttiiddyy # if you have left-over files from a previous build + % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH --DDUUSSEE__CCYYRRUUSS__SSAASSLL \\ + --II//uussrr//llooccaall//iinncclluuddee"" AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb --llssaassll"" -On Solaris 2.x you need to specify run-time link information, otherwise ld.so -will not find the SASL shared library: +On Solaris 2.x you need to specify run-time link information, otherwise the +ld.so run-time linker will not find the SASL shared library: -(for Cyrus SASL version 1.5.x): +Cyrus SASL version 2.1.x - % make tidy # if you have left-over files from a previous build - % make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \ - -I/usr/local/include" AUXLIBS="-L/usr/local/lib \ - -R/usr/local/lib -lsasl" + % mmaakkee ttiiddyy # remove left-over files from a previous build + % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH --DDUUSSEE__CCYYRRUUSS__SSAASSLL \\ + --II//uussrr//llooccaall//iinncclluuddee//ssaassll"" AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb \\ + --RR//uussrr//llooccaall//lliibb --llssaassll22"" -(for Cyrus SASL version 2.1.x): +Cyrus SASL version 1.5.x - % make tidy # if you have left-over files from a previous build - % make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \ - -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib \ - -R/usr/local/lib -lsasl2" + % mmaakkee ttiiddyy # if you have left-over files from a previous build + % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH --DDUUSSEE__CCYYRRUUSS__SSAASSLL \\ + --II//uussrr//llooccaall//iinncclluuddee"" AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb \\ + --RR//uussrr//llooccaall//lliibb --llssaassll"" -EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr +UUssiinngg CCyyrruuss SSAASSLL vveerrssiioonn 11..55..xx -In order to enable SASL support in the Postfix SMTP server: +Postfix supports Cyrus SASL version 1.x, but you shouldn't use it unless you +are forced to. The makers of Cyrus SASL write: - /etc/postfix/main.cf: - smtpd_sasl_auth_enable = yes + This library is being deprecated and applications should transition to + using the SASLv2 library (source: Project Cyrus: Downloads). -In order to allow mail relaying by authenticated remote SMTP clients: +If you still need to set it up, here's a quick rundown: - /etc/postfix/main.cf: - smtpd_recipient_restrictions = - permit_mynetworks - permit_sasl_authenticated - reject_unauth_destination +Read the regular section on SMTP server configurations for the Cyrus SASL +framework. The differences are: -To report SASL login names in Received: message headers (Postfix version 2.3 -and later): + * Cyrus SASL version 1.5.x searches for configuration (smtpd.conf) in /usr/ + lib/sasl/ only. You must place the configuration in that directory. Some + systems may have modified Cyrus SASL and put the files into e.g. /var/lib/ + sasl/. - /etc/postfix/main.cf: - smtpd_sasl_authenticated_header = yes + * Use the saslpasswd command instead of saslpasswd2 to create users in + sasldb. -Note: the SASL login names will be shared with the entire world. + * Use the sasldblistusers command instead of sasldblistusers2 to find users + in sasldb. -Older Microsoft SMTP client software implements a non-standard version of the -AUTH protocol syntax, and expects that the SMTP server replies to EHLO with -"250 AUTH=mechanism-list" instead of "250 AUTH mechanism-list". To accommodate -such clients (in addition to conformant clients) use the following: - - /etc/postfix/main.cf: - broken_sasl_auth_clients = yes - -DDoovveeccoott SSAASSLL ccoonnffiigguurraattiioonn ffoorr tthhee PPoossttffiixx SSMMTTPP sseerrvveerr - -Dovecot SASL support is available in Postfix 2.3 and later. On the Postfix side -you need to specify the location of the Dovecot authentication daemon socket. -We use a pathname relative to the Postfix queue directory, so that it will work -whether or not the Postfix SMTP server runs chrooted: - - /etc/postfix/main.cf: - smtpd_sasl_type = dovecot - smtpd_sasl_path = private/auth - -On the Dovecot side you also need to specify the Dovecot authentication daemon -socket. In this case we specify an absolute pathname. In the example we assume -that the Postfix queue is under /var/spool/postfix/. - - /some/where/dovecot.conf: - auth default { - mechanisms = plain login - passdb pam { - } - userdb passwd { - } - socket listen { - client { - path = /var/spool/postfix/private/auth - mode = 0660 - user = postfix - group = postfix - } - } - } - -See the Dovecot documentation for how to configure and operate the Dovecot -authentication server. - -CCyyrruuss SSAASSLL ccoonnffiigguurraattiioonn ffoorr tthhee PPoossttffiixx SSMMTTPP sseerrvveerr - -You need to configure how the Cyrus SASL library should authenticate a remote -SMTP client's username and password. These settings must be stored in a -separate configuration file. - -The name of the configuration file (default: smtpd.conf) will be constructed -from a value that the Postfix SMTP server sends to the Cyrus SASL library, -which adds the suffix .conf. The value is configured using one of the following -variables: - - /etc/postfix/main.cf: - # Postfix 2.3 and later - smtpd_sasl_path = smtpd - # Postfix < 2.3 - smtpd_sasl_application_name = smtpd - -Cyrus SASL searches for the configuration file in /usr/local/lib/sasl/ (Cyrus -SASL version 1.5.5) or /usr/local/lib/sasl2/ (Cyrus SASL version 2.1.x). - -Note: some Postfix distributions are modified and look for the smtpd.conf file -in /etc/postfix/sasl. - -Note: some Cyrus SASL distributions look for the smtpd.conf file in /etc/sasl2. - - * To authenticate against the UNIX password database, use: - - (Cyrus SASL version 1.5.x) - - /usr/local/lib/sasl/smtpd.conf: - pwcheck_method: pwcheck - - IMPORTANT: pwcheck establishes a UNIX domain socket in /var/pwcheck and - waits for authentication requests. The Postfix SMTP server must have - read+execute permission to this directory or authentication attempts - will fail. - - The pwcheck daemon is contained in the cyrus-sasl source tarball. - - (Cyrus SASL version 1.5.26) - - /usr/local/lib/sasl/smtpd.conf: - pwcheck_method: saslauthd - - (Cyrus SASL version 2.1.x) - - /usr/local/lib/sasl2/smtpd.conf: - pwcheck_method: saslauthd - mech_list: PLAIN LOGIN - - The saslauthd daemon is also contained in the cyrus-sasl source tarball. It - is more flexible than the pwcheck daemon, in that it can authenticate - against PAM and various other sources. To use PAM, start saslauthd with "- - a pam". - - IMPORTANT: saslauthd usually establishes a UNIX domain socket in /var/run/ - saslauthd and waits for authentication requests. The Postfix SMTP server - must have read+execute permission to this directory or authentication - attempts will fail. - - Note: The directory where saslauthd puts the socket is configurable. See - the command-line option "-m /path/to/socket" in the saslauthd --help - listing. - - * To authenticate against Cyrus SASL's own password database: - - (Cyrus SASL version 1.5.x) - - /usr/local/lib/sasl/smtpd.conf: - pwcheck_method: sasldb - - (Cyrus SASL version 2.1.x) - - /usr/local/lib/sasl2/smtpd.conf: - pwcheck_method: auxprop - auxprop_plugin: sasldb - mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 - - This will use the Cyrus SASL password file (default: /etc/sasldb in version - 1.5.x, or /etc/sasldb2 in version 2.1.x), which is maintained with the - saslpasswd or saslpasswd2 command (part of the Cyrus SASL software). On - some poorly-supported systems the saslpasswd command needs to be run - multiple times before it stops complaining. The Postfix SMTP server needs - read access to the sasldb file - you may have to play games with group - access permissions. With the OTP authentication mechanism, the Postfix SMTP - server also needs WRITE access to /etc/sasldb2 or /etc/sasldb (or the back - end SQL database, if used). - - IMPORTANT: To get sasldb running, make sure that you set the SASL domain - (realm) to a fully qualified domain name. - - EXAMPLE: - - (Cyrus SASL version 1.5.x) - - % saslpasswd -c -u `postconf -h myhostname` exampleuser - - (Cyrus SASL version 2.1.x) - - % saslpasswd2 -c -u `postconf -h myhostname` exampleuser - - You can find out SASL's idea about the realms of the users in sasldb with - sasldblistusers (Cyrus SASL version 1.5.x) or sasldblistusers2 (Cyrus SASL - version 2.1.x). - - On the Postfix side, you can have only one realm per smtpd(8) instance, and - only the users belonging to that realm would be able to authenticate. The - Postfix variable smtpd_sasl_local_domain controls the realm used by smtpd - (8): - - /etc/postfix/main.cf: - smtpd_sasl_local_domain = $myhostname - -IMPORTANT: The Cyrus SASL password verification services pwcheck and saslauthd -can only support the plaintext mechanisms PLAIN or LOGIN. However, the Cyrus -SASL library doesn't know this, and will happily advertise other authentication -mechanisms that the SASL library implements, such as DIGEST-MD5. As a result, -if a remote SMTP client chooses any mechanism other than PLAIN or LOGIN while -pwcheck or saslauthd are used, authentication will fail. Thus you may need to -limit the list of mechanisms advertised by the Postfix SMTP server. - - * With older Cyrus SASL versions you remove the corresponding library files - from the SASL plug-in directory (and again whenever the system is updated). - - * With Cyrus SASL version 2.1.x or later the mech_list variable can specify a - list of authentication mechanisms that Cyrus SASL may offer: - - /usr/local/lib/sasl2/smtpd.conf: - mech_list: plain login - -For the same reasons you might want to limit the list of plugins used for -authentication. - - * With Cyrus SASL version 1.5.x your only choice is to delete the - corresponding library files from the SASL plug-in directory. - - * With SASL version 2.1.x: - - /usr/local/lib/sasl2/smtpd.conf: - pwcheck_method: auxprop - auxprop_plugin: sql - -To run software chrooted with SASL support is an interesting exercise. It -probably is not worth the trouble. - -TTeessttiinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr - -To test the server side, connect (for example, with telnet) to the Postfix SMTP -server port and you should be able to have a conversation as shown below. -Information sent by the client (that is, you) is shown in bold font. - - $ tteellnneett sseerrvveerr..eexxaammppllee..ccoomm 2255 - . . . - 220 server.example.com ESMTP Postfix - EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm - 250-server.example.com - 250-PIPELINING - 250-SIZE 10240000 - 250-ETRN - 250-AUTH DIGEST-MD5 PLAIN CRAM-MD5 - 250 8BITMIME - AAUUTTHH PPLLAAIINN AAHHRRllcc33QQAAddGGVVzzddHHBBhhcc33MM== - 235 Authentication successful - -Instead of AHRlc3QAdGVzdHBhc3M=, specify the base64 encoded form of -\0username\0password (the \0 is a null byte). The example above is for a user -named `test' with password `testpass'. - -In order to generate base64 encoded authentication information you can use one -of the following commands: - - % printf '\0username\0password' | mmencode - - % perl -MMIME::Base64 -e \ - 'print encode_base64("\0username\0password");' - -The mmencode command is part of the metamail software. MIME::Base64 is -available from http://www.cpan.org/. - -Caution: when posting logs of the SASL negotiations to public lists, please -keep in mind that username/password information is trivial to recover from the -base64-encoded form. - -TTrroouubbllee sshhoooottiinngg tthhee SSAASSLL iinntteerrnnaallss - -In the Cyrus SASL sources you'll find a subdirectory named "sample". Run make -there, then create a symbolic link from sample.conf to smtpd.conf in your Cyrus -SASL library directory /usr/local/lib/sasl2. "su" to the user postfix (or -whatever your mail_owner directive is set to): - - % su postfix - -then run the resulting sample Cyrus SASL server and client in separate -terminals. The sample applications send log messages to the syslog facility -auth. Check the log to fix the problem or run strace / ktrace / truss on the -server to see what makes it unhappy. Repeat the previous step until you can -successfully authenticate with the sample Cyrus SASL client. Only then get back -to Postfix. - -EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP cclliieenntt - -Turn on client-side SASL authentication, and specify a table with per-host or -per-destination username and password information. The Postfix SMTP client -first searches the table for an entry with the remote SMTP server hostname; if -no entry is found, then the Postfix SMTP client searches the table for an entry -with the next-hop destination. Usually, that is the right-hand part of an email -address, but it can also be the information that is specified with the -relayhost parameter or with a transport(5) table. - - /etc/postfix/main.cf: - smtp_sasl_auth_enable = yes - smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd - smtp_sasl_type = cyrus - relayhost = [mail.myisp.net] - # Alternative form: - # relayhost = [mail.myisp.net]:submission - - /etc/postfix/sasl_passwd: - [mail.myisp.net] username:password - [mail.myisp.net]:submission username:password - -Notes: - - * The "submission" destination port tells Postfix to send mail via TCP - network port 587, which is normally reserved for email clients. The default - is to send mail to the "smtp" destination port (TCP port 25), which is used - for receiving mail across the internet. If you use an explicit destination - port in main.cf, then you must use the same form also in the - smtp_sasl_password_maps file. - - * Postfix does not deliver mail via TCP port 465 (the obsolete "wrappermode" - protocol). See TLS_README for a solution that uses the "stunnel" command. - - * The "[" and "]" prevent Postfix from looking up the MX (mail exchanger) - records for the enclosed name. If you use this form in main.cf, then you - must use the same form also in the smtp_sasl_password_maps file. - - * The Postfix SMTP client opens the SASL client password file before entering - the optional chroot jail, so you can keep the file in /etc/postfix and set - permissions read / write only for root to keep the username:password - combinations away from other system users. - - * Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb - files. To find out what lookup tables Postfix supports, use the command - "ppoossttccoonnff --mm". - - * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change - the sasl_passwd table. - -Workarounds: - - * Some remote SMTP servers support PLAIN or LOGIN authentication only. By - default, the Postfix SMTP client does not use authentication methods that - send plaintext passwords, and defers delivery with the following error - message: "Authentication failed: cannot SASL authenticate to server". To - enable plaintext authentication specify, for example: - - /etc/postfix/main.cf: - smtp_sasl_security_options = noanonymous - - * Some remote SMTP servers announce authentication mechanisms that don't - actually work. It is possible via the smtp_sasl_mechanism_filter parameter - to restrict the list of server mechanisms that the Postfix SMTP client will - take into consideration: - - /etc/postfix/main.cf: - smtp_sasl_mechanism_filter = !gssapi, !external, static:all - - In the above example, the Postfix SMTP client will decline to use - mechanisms that require special infrastructure such as Kerberos or TLS. - - * The Postfix SMTP client is backwards compatible with SMTP servers that use - the non-standard "AUTH=method..." syntax in response to the EHLO command; - there is no Postfix client configuration needed to work around it. - -SSuuppppoorrttiinngg mmuullttiippllee IISSPP aaccccoouunnttss iinn tthhee PPoossttffiixx SSMMTTPP cclliieenntt - -Postfix version 2.3 supports multiple ISP accounts. This can be useful when one -person uses the same machine for work and for personal use, or when people with -different ISP accounts share the same Postfix server. To make this possible, -Postfix 2.3 supports per-sender SASL passwords and per-sender relay hosts. In -the example below, Postfix will search the SASL password file by sender before -it searches that same file by destination. Likewise, Postfix will search the -per-sender relayhost file, and use the default relayhost only as a final -resort. - - /etc/postfix/main.cf: - smtp_sender_dependent_authentication = yes - sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay - smtp_sasl_auth_enable = yes - smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd - relayhost = [mail.myisp.net] - # Alternative form: - # relayhost = [mail.myisp.net]:submission - - /etc/postfix/sasl_passwd: - # Per-sender authentication; see also /etc/postfix/sender_relay. - user1@example.com username2:password2 - user2@example.net username2:password2 - # Login information for the default relayhost. - [mail.myisp.net] username:password - [mail.myisp.net]:submission username:password - - /etc/postfix/sender_relay: - # Per-sender provider; see also /etc/postfix/sasl_passwd. - user1@example.com [mail.example.com]:submission - user2@example.net [mail.example.net] - -Notes: - - * If you are creative, then you can try to combine the two tables into one - single MySQL database, and configure different Postfix queries to extract - the appropriate information. - - * Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb - files. To find out what lookup tables Postfix supports, use the command - "ppoossttccoonnff --mm". - - * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change - the sasl_passwd table. - - * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//sseennddeerr__rreellaayy" whenever you change - the sender_relay table. + * In the smtpd.conf file you can't use mech_list to limit the range of + mechanisms offered. Instead, remove their libraries from /usr/lib/sasl/ + (and remember remove those files again when a system update re-installs new + versions). CCrreeddiittss @@ -541,15 +1295,17 @@ CCrreeddiittss Rhein/Main AG. * Wietse trimmed down the code to only the bare necessities. * Support for Cyrus SASL version 2 was contributed by Jason Hoos. - * Liviu Daia added smtpd_sasl_application_name, split + * Liviu Daia added smtpd_sasl_application_name, separated reject_sender_login_mismatch into reject_authenticated_sender_login_mismatch and reject_unauthenticated_sender_login_mismatch, and revised the docs. * Wietse made another iteration through the code to add plug-in support for - multiple SASL implementations, and changed smtpd_sasl_application_name into - smtpd_sasl_path. + multiple SASL implementations, and for reasons that have been lost, also + changed smtpd_sasl_application_name into smtpd_sasl_path. * The Dovecot SMTP server-only plug-in was originally implemented by Timo Sirainen of Procontrol, Finland. * Patrick Ben Koetter revised this document for Postfix 2.4 and made much needed updates. + * Patrick Ben Koetter revised this document again for Postfix 2.7 and made + much needed updates. diff --git a/postfix/README_FILES/SOHO_README b/postfix/README_FILES/SOHO_README index 191cffb53..3c40eb560 100644 --- a/postfix/README_FILES/SOHO_README +++ b/postfix/README_FILES/SOHO_README @@ -19,7 +19,7 @@ outside the scope of the Postfix documentation. Selected topics from the SASL_README document: o Enabling SASL authentication in the Postfix SMTP client - o Supporting multiple ISP accounts in the Postfix SMTP client + o Configuring Sender-Dependent SASL authentication See the SASL_README and STANDARD_CONFIGURATION_README documents for further information on these topics. @@ -149,128 +149,122 @@ canonical table. Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" whenever you change the virtual table. -EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP cclliieenntt +EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt -Turn on client-side SASL authentication, and specify a table with per-host or -per-destination username and password information. The Postfix SMTP client -first searches the table for an entry with the remote SMTP server hostname; if -no entry is found, then the Postfix SMTP client searches the table for an entry -with the next-hop destination. Usually, that is the right-hand part of an email -address, but it can also be the information that is specified with the -relayhost parameter or with a transport(5) table. +This section shows a typical scenario where the Postfix SMTP client sends all +messages via a mail gateway server that requires SASL authentication. To make +the example more readable we introduce it in two parts. /etc/postfix/main.cf: smtp_sasl_auth_enable = yes - smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd - smtp_sasl_type = cyrus - relayhost = [mail.myisp.net] + relayhost = [mail.isp.example] # Alternative form: - # relayhost = [mail.myisp.net]:submission + # relayhost = [mail.isp.example]:submission + smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd + + * The smtp_sasl_auth_enable setting enables client-side authentication. We + will configure the client's username and password information in the second + part of the example. + + * The relayhost setting forces the Postfix SMTP to send all remote messages + to the specified mail server instead of trying to deliver them directly to + their destination. + + * In the relayhost setting, the "[" and "]" prevent the Postfix SMTP client + from looking up MX (mail exchanger) records for the enclosed name. + + * The relayhost destination may also specify a non-default TCP port. For + example, the alternative form [mail.isp.example]:submission tells Postfix + to connect to TCP network port 587, which is reserved for email client + applications. + + * The Postfix SMTP client is compatible with SMTP servers that use the non- + standard "AUTH=mmeetthhoodd....." syntax in response to the EHLO command; this + requires no additional Postfix client configuration. + + * The Postfix SMTP client does not support the obsolete "wrappermode" + protocol, which uses TCP port 465 on the SMTP server. See TLS_README for a + solution that uses the stunnel command. + + * With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP + client to send username and password information to the mail gateway + server. As discussed in the next section, the Postfix SMTP client supports + multiple ISP accounts. For this reason the username and password are stored + in a table that contains one username/password combination for each mail + gateway server. /etc/postfix/sasl_passwd: - [mail.myisp.net] username:password - [mail.myisp.net]:submission username:password + # destination credentials + [mail.isp.example] username:password + # Alternative form: + # [mail.isp.example]:submission username:password -Notes: + IImmppoorrttaanntt - * The "submission" destination port tells Postfix to send mail via TCP - network port 587, which is normally reserved for email clients. The default - is to send mail to the "smtp" destination port (TCP port 25), which is used - for receiving mail across the internet. If you use an explicit destination - port in main.cf, then you must use the same form also in the + Keep the SASL client password file in /etc/postfix, and make the file + read+write only for root to protect the username/password combinations + against other users. The Postfix SMTP client will still be able to read the + SASL client passwords. It opens the file as user root before it drops + privileges, and before entering an optional chroot jail. + + * Use the postmap command whenever you change the /etc/postfix/sasl_passwd + file. + + * If you specify the "[" and "]" in the relayhost destination, then you must + use the same form in the smtp_sasl_password_maps file. + + * If you specify a non-default TCP Port (such as ":submission" or ":587") in + the relayhost destination, then you must use the same form in the smtp_sasl_password_maps file. - * Postfix does not deliver mail via TCP port 465 (the obsolete "wrappermode" - protocol). See TLS_README for a solution that uses the "stunnel" command. +CCoonnffiigguurriinngg SSeennddeerr--DDeeppeennddeenntt SSAASSLL aauutthheennttiiccaattiioonn - * The "[" and "]" prevent Postfix from looking up the MX (mail exchanger) - records for the enclosed name. If you use this form in main.cf, then you - must use the same form also in the smtp_sasl_password_maps file. +Postfix supports different ISP accounts for different sender addresses (version +2.3 and later). This can be useful when one person uses the same machine for +work and for personal use, or when people with different ISP accounts share the +same Postfix server. - * The Postfix SMTP client opens the SASL client password file before entering - the optional chroot jail, so you can keep the file in /etc/postfix and set - permissions read / write only for root to keep the username:password - combinations away from other system users. - - * Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb - files. To find out what lookup tables Postfix supports, use the command - "ppoossttccoonnff --mm". - - * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change - the sasl_passwd table. - -Workarounds: - - * Some remote SMTP servers support PLAIN or LOGIN authentication only. By - default, the Postfix SMTP client does not use authentication methods that - send plaintext passwords, and defers delivery with the following error - message: "Authentication failed: cannot SASL authenticate to server". To - enable plaintext authentication specify, for example: - - /etc/postfix/main.cf: - smtp_sasl_security_options = noanonymous - - * Some remote SMTP servers announce authentication mechanisms that don't - actually work. It is possible via the smtp_sasl_mechanism_filter parameter - to restrict the list of server mechanisms that the Postfix SMTP client will - take into consideration: - - /etc/postfix/main.cf: - smtp_sasl_mechanism_filter = !gssapi, !external, static:all - - In the above example, the Postfix SMTP client will decline to use - mechanisms that require special infrastructure such as Kerberos or TLS. - - * The Postfix SMTP client is backwards compatible with SMTP servers that use - the non-standard "AUTH=method..." syntax in response to the EHLO command; - there is no Postfix client configuration needed to work around it. - -SSuuppppoorrttiinngg mmuullttiippllee IISSPP aaccccoouunnttss iinn tthhee PPoossttffiixx SSMMTTPP cclliieenntt - -Postfix version 2.3 supports multiple ISP accounts. This can be useful when one -person uses the same machine for work and for personal use, or when people with -different ISP accounts share the same Postfix server. To make this possible, -Postfix 2.3 supports per-sender SASL passwords and per-sender relay hosts. In -the example below, Postfix will search the SASL password file by sender before -it searches that same file by destination. Likewise, Postfix will search the -per-sender relayhost file, and use the default relayhost only as a final -resort. +To make this possible, Postfix supports per-sender SASL passwords and per- +sender relay hosts. In the example below, the Postfix SMTP client will search +the SASL password file by sender address before it searches that same file by +destination. Likewise, the Postfix trivial-rewrite(8) daemon will search the +per-sender relayhost file, and use the default relayhost setting only as a +final resort. /etc/postfix/main.cf: smtp_sender_dependent_authentication = yes sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd - relayhost = [mail.myisp.net] + relayhost = [mail.isp.example] # Alternative form: - # relayhost = [mail.myisp.net]:submission + # relayhost = [mail.isp.example]:submission /etc/postfix/sasl_passwd: # Per-sender authentication; see also /etc/postfix/sender_relay. - user1@example.com username2:password2 - user2@example.net username2:password2 + user1@example.com username2:password2 + user2@example.net username2:password2 # Login information for the default relayhost. - [mail.myisp.net] username:password - [mail.myisp.net]:submission username:password + [mail.isp.example] username:password + # Alternative form: + # [mail.isp.example]:submission username:password /etc/postfix/sender_relay: # Per-sender provider; see also /etc/postfix/sasl_passwd. - user1@example.com [mail.example.com]:submission - user2@example.net [mail.example.net] - -Notes: + user1@example.com [mail.example.com]:submission + user2@example.net [mail.example.net] * If you are creative, then you can try to combine the two tables into one single MySQL database, and configure different Postfix queries to extract the appropriate information. - * Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb + * Specify dbm instead of hash if your system uses dbm files instead of db files. To find out what lookup tables Postfix supports, use the command - "ppoossttccoonnff --mm". + "postconf -m". - * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change + * Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change the sasl_passwd table. - * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//sseennddeerr__rreellaayy" whenever you change + * Execute the command "postmap /etc/postfix/sender_relay" whenever you change the sender_relay table. diff --git a/postfix/README_FILES/TLS_README b/postfix/README_FILES/TLS_README index 9102c6a48..241e08990 100644 --- a/postfix/README_FILES/TLS_README +++ b/postfix/README_FILES/TLS_README @@ -1659,7 +1659,7 @@ by the smtp_tls_mandatory_ciphers configuration parameter. This setting controls the minimum acceptable SMTP client TLS cipher grade for use with mandatory TLS encryption. The default value "medium" is suitable for most destinations with which you may want to enforce TLS, and is beyond the reach of -today's crypt-analytic methods. See smtp_tls_policy_maps for information on how +today's cryptanalytic methods. See smtp_tls_policy_maps for information on how to configure ciphers on a per-destination basis. By default anonymous ciphers are allowed, and automatically disabled when diff --git a/postfix/RELEASE_NOTES b/postfix/RELEASE_NOTES index db765d560..b9715478f 100644 --- a/postfix/RELEASE_NOTES +++ b/postfix/RELEASE_NOTES @@ -1,60 +1,33 @@ -The stable Postfix release is called postfix-2.6.x where 2=major -release number, 6=minor release number, x=patchlevel. The stable +The stable Postfix release is called postfix-2.7.x where 2=major +release number, 7=minor release number, x=patchlevel. The stable release never changes except for patches that address bugs or emergencies. Patches change the patchlevel and the release date. New features are developed in snapshot releases. These are called -postfix-2.7-yyyymmdd where yyyymmdd is the release date (yyyy=year, +postfix-2.8-yyyymmdd where yyyymmdd is the release date (yyyy=year, mm=month, dd=day). Patches are never issued for snapshot releases; instead, a new snapshot is released. The mail_release_date configuration parameter (format: yyyymmdd) specifies the release date of a stable release or snapshot release. -If you upgrade from Postfix 2.5 or earlier, read RELEASE_NOTES-2.6 +If you upgrade from Postfix 2.6 or earlier, read RELEASE_NOTES-2.7 before proceeding. -Incompatibility with snapshot 20100117 -====================================== - -The meaning of an empty content filter next-hop destination has -changed. Postfix now uses the recipient domain, instead of using -$myhostname as in Postfix 2.6 and earlier. To get the old behavior -use "default_filter_nexthop = $myhostname", or specify a non-empty -next-hop content filter destination. - -Major changes with snapshot 20100117 -==================================== - -The FILTER action in access maps or header/body_checks now supports -sender reputation schemes that dynamically choose the SMTP source -IP address. - -This is implemented by specifying FILTER actions with empty next-hop -destinations in access maps or header/body_checks, and by configuring -in master.cf one Postfix SMTP client for each SMTP source IP address, -where each client has its own "-o myhostname" and "-o smtp_bind_address" -settings. - Incompatibility with snapshot 20100101 ====================================== -The verify(8) service now uses a persistent cache by default -(address_verify_map = btree:$data_directory/verify_cache). To -disable, specify "address_verify_map =" in main.cf. - When periodic cache cleanup is enabled (the default), the postscreen(8) -and verify(8) servers now require that their cache databases support -the "delete" and "sequence" operations. To disable periodic cache -cleanup specify a zero xxx_cache_cleanup_interval value. +server now requires that the cache database supports the "delete" +and "sequence" operations. To disable periodic cache cleanup specify +a zero postscreen_cache_cleanup_interval value. Major changes with snapshot 20100101 ==================================== -Periodic cache cleanup for the postscreen(8) and verify(8) cache -databases. The time between cache cleanup runs is controlled with -the address_verify_cache_cleanup_interval (default: 12h) and -postscreen_cache_cleanup_interval (default: 12h) parameters. Cache +Periodic cache cleanup for the postscreen(8) cache database. The +time between cache cleanup runs is controlled with the +postscreen_cache_cleanup_interval (default: 12h) parameter. Cache cleanup increases the database access latency, so this should not be run more often than necessary. @@ -70,52 +43,6 @@ The postscreen daemon now checks the permanent whitelist before the permanent blacklist. This makes the whitelist easier to use for its intended purpose, which is to receive mail. -Major changes with snapshot 20091209 -==================================== - -sender_dependent_default_transport_maps, a per-sender override for -default_transport. It's original motivation is to use different -output channels (with different source IP addresses) for different -sender addresses, in order to keep their IP-based reputations -separate from each other. - -The result value syntax is that of default_transport, not transport_maps. -Thus, sender_dependent_default_transport_maps does not support the -special transport_maps result value syntax for null transport, null -nexthop, or null email address. - -This feature makes sender_dependent_relayhost_maps pretty much -redundant (though sender_dependent_relayhost_maps will often be -easier to use because that is the only thing people want to override). - -Major changes with snapshot 20091109 -==================================== - -Improved before-queue filter performance. With "smtpd_proxy_options -= speed_adjust", the Postfix SMTP server receives the entire message -before it connects to a before-queue content filter. This means you -can run more SMTP server processes with the same number of running -content filter processes, and thus, handle more mail. This feature -is off by default until it is proven to create no new problems. - -This addresses a concern of people in Europe who want to reject all -bad mail with a before-queue filter. The alternative, an after-queue -filter, means they would have to discard bad mail (which is illegal) -or bounce bad mail (which violates good network citizenship). - -NOTE 1: When this feature is turned on, a filter cannot selectively -reject recipients of a multi-recipient message. It is OK to reject -all recipients of the same multi-recipient message, as is deferring -or accepting all recipients of the same multi-recipient message. - -NOTE 2: This feature increases the minimum amount of free queue -space by $message_size_limit. The extra space is needed to save the -message to a temporary file. - -To keep the performance overhead low, the same temporary file is -reused with successive mail transactions (the file is of course -truncated before reuse, so there is no information leakage). - Incompatibility with snapshot 20091008 ====================================== @@ -202,21 +129,3 @@ without reporting sender and recipient information. In a future implementation, the connection may instead be passed to a dummy SMTP protocol engine that logs sender and recipient information before dropping the connection. - -Incompatibility with snapshot 20090606 -====================================== - -The "postmulti -e destroy" command no longer attempts to remove -files that are created AFTER "postmulti -e create". It still works -as expected immediately after creating an instance by mistake. -Trying to automatically remove other files is too risky because -Postfix-owned directories are by design not trusted. - -Major changes with snapshot 20090606 -==================================== - -Support for header checks on Milter-generated message headers. This -can be used, for example, to control mail flow with Milter-generated -headers with indicators for badness or goodness. For details, see -the postconf(5) section for "milter_header_checks". Currently, all -header_checks features are implemented except PREPEND. diff --git a/postfix/RELEASE_NOTES-2.7 b/postfix/RELEASE_NOTES-2.7 new file mode 100644 index 000000000..8632638f7 --- /dev/null +++ b/postfix/RELEASE_NOTES-2.7 @@ -0,0 +1,175 @@ +The stable Postfix release is called postfix-2.7.x where 2=major +release number, 7=minor release number, x=patchlevel. The stable +release never changes except for patches that address bugs or +emergencies. Patches change the patchlevel and the release date. + +New features are developed in snapshot releases. These are called +postfix-2.8-yyyymmdd where yyyymmdd is the release date (yyyy=year, +mm=month, dd=day). Patches are never issued for snapshot releases; +instead, a new snapshot is released. + +The mail_release_date configuration parameter (format: yyyymmdd) +specifies the release date of a stable release or snapshot release. + +If you upgrade from Postfix 2.5 or earlier, read RELEASE_NOTES-2.6 +before proceeding. + +Major changes - performance +--------------------------- + +[Feature 20100101] Periodic cache cleanup for the verify(8) cache +database. The time between cache cleanup runs is controlled with +the address_verify_cache_cleanup_interval (default: 12h) parameter. +Cache cleanup increases the database access latency, so this should +not be run more often than necessary. + +[Feature 20091109] Improved before-queue filter performance. With +"smtpd_proxy_options = speed_adjust", the Postfix SMTP server +receives the entire message before it connects to a before-queue +content filter. This means you can run more SMTP server processes +with the same number of running content filter processes, and thus, +handle more mail. This feature is off by default until it is proven +to create no new problems. + +This addresses a concern of people in Europe who want to reject all +bad mail with a before-queue filter. The alternative, an after-queue +filter, means they would have to discard bad mail (which is illegal) +or bounce bad mail (which violates good network citizenship). + +NOTE 1: When this feature is turned on, a filter cannot selectively +reject recipients of a multi-recipient message. It is OK to reject +all recipients of the same multi-recipient message, as is deferring +or accepting all recipients of the same multi-recipient message. + +NOTE 2: This feature increases the minimum amount of free queue +space by $message_size_limit. The extra space is needed to save the +message to a temporary file. + +To keep the performance overhead low, the same temporary file is +reused with successive mail transactions (the file is of course +truncated before reuse, so there is no information leakage). + +Major changes - sender reputation +--------------------------------- + +[Feature 20100117] The FILTER action in access maps or header/body_checks +now supports sender reputation schemes that dynamically choose the +SMTP source IP address. Typically, mail is split into classes, and +all mail in class X is sent out from an SMTP client IP address that +is reserved for class X. + +This is implemented by specifying FILTER actions with empty next-hop +destinations in access maps or header/body_checks, and by configuring +in master.cf one Postfix SMTP client for each SMTP source IP address, +where each client has its own "-o myhostname" and "-o smtp_bind_address" +settings. + +[Feature 20091209] sender_dependent_default_transport_maps, a +per-sender override for default_transport. The original motivation +is to use different output channels (with different source IP +addresses) for different sender addresses, in order to keep their +IP-based reputations separate from each other. + +The result value syntax is that of default_transport, not transport_maps. +Thus, sender_dependent_default_transport_maps does not support the +special transport_maps result value syntax for null transport, null +nexthop, or null email address. + +This feature makes sender_dependent_relayhost_maps pretty much +redundant (though sender_dependent_relayhost_maps will often be +easier to use because that is the only thing people want to override). + +Major changes - address verification +------------------------------------ + +[Incompat 20100101] The verify(8) service now uses a persistent +cache by default (address_verify_map = btree:$data_directory/verify_cache). +To disable, specify "address_verify_map =" in main.cf. + +When periodic cache cleanup is enabled (the default), the verify(8) +server now requires that the cache database supports the "delete" +and "sequence" operations. To disable periodic cache cleanup specify +a zero address_verify_cache_cleanup_interval value. + +[Feature 20100101] Periodic cache cleanup for the verify(8) cache +database. The time between cache cleanup runs is controlled with +the address_verify_cache_cleanup_interval (default: 12h) parameter. +Cache cleanup increases the database access latency, so this should +not be run more often than necessary. + +Major changes - content filter +------------------------------ + +[Incompat 20100117] The meaning of an empty filter next-hop destination +has changed (for example, "content_filter = foo:" or "FILTER foo:"). +Postfix now uses the recipient domain, instead of using $myhostname +as in Postfix 2.6 and earlier. To restore the old behavior specify +"default_filter_nexthop = $myhostname", or specify a non-empty +next-hop content filter destination. + +This compatibility option is not needed with SMTP-based content +filters, because these always have an explicit next-hop destination. + +With pipe-based filters that specify no next-hop destination, the +compatibility option restores the FIFO order of deliveries. Without +the compatibility option, the delivery order for filters without +next-hop destination changes to round-robin domain selection. + +[Feature 20100117] The FILTER action in access maps or header/body_checks +now supports sender reputation schemes that dynamically choose the +SMTP source IP address. Typically, mail is split into classes, and +all mail in class X is sent out from an SMTP client IP address that +is reserved for class X. + +This is implemented by specifying FILTER actions with empty next-hop +destinations in access maps or header/body_checks, and by configuring +in master.cf one Postfix SMTP client for each SMTP source IP address, +where each client has its own "-o myhostname" and "-o smtp_bind_address" +settings. + +[Feature 20091109] Improved before-queue filter performance. With +"smtpd_proxy_options = speed_adjust", the Postfix SMTP server +receives the entire message before it connects to a before-queue +content filter. This means you can run more SMTP server processes +with the same number of running content filter processes, and thus, +handle more mail. This feature is off by default until it is proven +to create no new problems. + +This addresses a concern of people in Europe who want to reject all +bad mail with a before-queue filter. The alternative, an after-queue +filter, means they would have to discard bad mail (which is illegal) +or bounce bad mail (which violates good network citizenship). + +NOTE 1: When this feature is turned on, a filter cannot selectively +reject recipients of a multi-recipient message. It is OK to reject +all recipients of the same multi-recipient message, as is deferring +or accepting all recipients of the same multi-recipient message. + +NOTE 2: This feature increases the minimum amount of free queue +space by $message_size_limit. The extra space is needed to save the +message to a temporary file. + +To keep the performance overhead low, the same temporary file is +reused with successive mail transactions (the file is of course +truncated before reuse, so there is no information leakage). + +Major changes - milter +---------------------- + +[Feature 20090606] Support for header checks on Milter-generated +message headers. This can be used, for example, to control mail +flow with Milter-generated headers that carry indicators for badness +or goodness. For details, see the postconf(5) section for +"milter_header_checks". Currently, all header_checks features are +implemented except PREPEND. + +Major changes - multi-instance support +-------------------------------------- + +[Incompat 20090606] The "postmulti -e destroy" command no longer +attempts to remove files that are created AFTER "postmulti -e +create". It still works as expected immediately after creating an +instance by mistake. Trying to automatically remove other files +is too risky because Postfix-owned directories are by design not +trusted. + diff --git a/postfix/WISHLIST b/postfix/WISHLIST index 89d05f77f..a1ac0ca55 100644 --- a/postfix/WISHLIST +++ b/postfix/WISHLIST @@ -2,20 +2,35 @@ Wish list: Remove this file from the stable release. - Should the postscreen temporary cache remember hosts that - are listed in the permanent white/black lists, and be queried - first? Skipping white/black list lookups will speed up the - handling of "good" clients without a permanent whitelist - entry. Of course, this means that updates to the white/black - lists do not immediately take effect. Workarounds: 1) ignore - cached white/black list lookup results after "postfix - reload"; 2) use a short temporary cache TTL for clients on - the permanent black/white lists; 3) adjust the logging, for - example "WHITELISTED address (cached)" and "BLACKLISTED - address (cached)" to eliminate surprises. Comparing the - cache entry time with the white/blacklist file modification - time is not foolproof: for example, pcre or CIDR tables are - read only once. + The cleanup virtual alias expansion limit does not really + deliver on its promises. 1) It promises to truncate the + result without aborting delivery, which would be undesirable + anyway, but that is not what it does, so that is good. 2) + It keeps all the recipients from multi-recipient database + lookup, then terminates further recursion when the result + exceeds the expansion limit. This behavior achieves the + original goal that all things shall have a finite size (even + though but we don'really care how large they are) but may + result in surprises when recipients are listed in virtual + alias domains or need expansion for other reasons. In a + phone call with Victor, a reasonable way out is to set the + limit to some large number (100000) and abort delivery when + the result exceeds the limit. + + Should the postscreen save permanent white/black list lookup + results int the temporary cache, and query the temporary + cache first? Skipping white/black list lookups will speed + up the handling of "good" clients without a permanent + whitelist entry. Of course, this means that updates to the + white/black lists do not immediately take effect. Workarounds: + 1) use a shorter temporary cache TTL for clients on the + permanent black/white lists; 2) ignore cached white/black + list lookup results after "postfix reload"; 2) adjust the + logging, for example "WHITELISTED address (cached)" and + "BLACKLISTED address (cached)" to eliminate surprises. + Comparing the cache entry time with the white/blacklist + file modification time is not foolproof: for example, pcre + or CIDR tables are read only once. It would be nice if the generic dict_cache(3) cache manager could postpone process suicide until cache cleanup is diff --git a/postfix/html/ADDRESS_VERIFICATION_README.html b/postfix/html/ADDRESS_VERIFICATION_README.html index 34e069dde..6ea0ab636 100644 --- a/postfix/html/ADDRESS_VERIFICATION_README.html +++ b/postfix/html/ADDRESS_VERIFICATION_README.html @@ -19,12 +19,11 @@

WARNING

-

The sender/recipient address verification feature described in this -document is suitable only for low-traffic sites. It performs poorly -under high load; excessive sender address verification activity may -even cause your site to be blacklisted by some -providers. See the "Limitations" section -below for details.

+

Recipient address verification may cause an increased load on +down-stream servers in the case of a dictionary attack or a flood +of backscatter bounces. Sender address verification may cause your +site to be blacklisted by some providers. See also the "Limitations" section below for more.

What Postfix address verification can do for you

@@ -35,7 +34,7 @@ until the address has been verified to be deliverable.

The technique has obvious uses to reject junk mail with an unreplyable sender address.

-

The technique may also be useful to block mail for undeliverable +

The technique is also useful to block mail for undeliverable recipients, for example on a mail relay host that does not have a list of all the valid recipient addresses. This prevents undeliverable junk mail from entering the queue, so that Postfix doesn't have to @@ -86,74 +85,96 @@ always discarded.

- +
- + + - + - + - + + + + + + + + + + + + + + - - + - + + + + + - + - + - + - + - - - - - + - + - + - + - + - + - + - + - - - + @@ -181,7 +202,8 @@ details.

MTA for that address, without actually delivering mail to it. If the nearest MTA accepts the address, then Postfix assumes that the address is deliverable. In reality, mail for a remote address can -bounce AFTER the nearest MTA accepts the recipient address.

+bounce AFTER the nearest MTA accepts the recipient address, or AFTER +the nearest MTA accepts the message content.

  • Some sites may blacklist you when you are probing them too often (a probe is an SMTP session that does not deliver mail), @@ -200,21 +222,25 @@ mail routing and for possible limitations when you have to do this.

  • Postfix assumes that an address is undeliverable when the nearest MTA for the address rejects the probe, regardless of the reason for rejection (client rejected, HELO rejected, MAIL FROM -rejected, etc.). Thus, Postfix rejects mail when the sender's MTA -rejects mail from your machine. This is a good thing.

    +rejected, etc.). Thus, Postfix rejects an address when the nearest +MTA for that address rejects mail from your machine for any reason. +This is not a limitation, but it is mentioned here just in case +people believe that it is a limitation.

    -

  • Unfortunately, some major sites such as YAHOO do not reject +

  • Unfortunately, some sites do not reject unknown addresses in reply to the RCPT TO command, but report a delivery failure in response to end of DATA after a message is transferred. Postfix address verification does not work with such sites.

    -

  • By default, Postfix probe messages have "double-bounce@$myorigin" -as the sender address (with Postfix versions before 2.5, the default +

  • By default, Postfix probe messages have a sender address +"double-bounce@$myorigin" (with Postfix versions before 2.5, the +default is "postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does not reject mail for this address.

    -

    You can change this into the null address ("address_verify_sender +

    You can change the probe sender address into the null address +("address_verify_sender ="). This is UNSAFE because address probes will fail with mis-configured sites that reject MAIL FROM: <>, while probes from "postmaster@$myorigin" would succeed.

    @@ -223,7 +249,7 @@ probes from "postmaster@$myorigin" would

    Recipient address verification

    -

    As mentioned earlier, recipient address verification may be +

    As mentioned earlier, recipient address verification is useful to block mail for undeliverable recipients on a mail relay host that does not have a list of all valid recipient addresses. This can help to prevent the mail queue from filling up with @@ -237,9 +263,11 @@ However, recipient address verification probes can increase the load on down-stream MTAs when you're being flooded by backscatter bounces, or when some spammer is mounting a dictionary attack.

    -

    By default, address verification results are not saved. To avoid -probing the same address repeatedly, you can store the result in a -persistent database as described later.

    +

    By default, address verification results are saved in a persistent database (Postfix version 2.7 and +later; with earlier versions, specify the database in main.cf as +described later). The persistent database helps to avoid probing +the same address repeatedly. 

    @@ -299,11 +327,13 @@ in forged email.  
    
     # Postfix 2.6 and later.
     # unverified_sender_defer_code = 250
 
+    # Default setting for Postfix 2.7 and later.
     # Note 1: Be sure to read the "Caching" section below!
     # Note 2: Avoid hash files here. Use btree instead.
     address_verify_map = btree:/var/lib/postfix/verify
  
 /etc/postfix/sender_access:
+    # Don't do this when you handle lots of email.
     aol.com     reject_unverified_sender
     hotmail.com reject_unverified_sender
     bigfoot.com reject_unverified_sender
@@ -344,6 +374,7 @@ you can see what mail would be blocked: 
    
     # Postfix 2.6 and later.
     # unverified_sender_reject_reason = Address verification failed
 
+    # Default setting for Postfix 2.7 and later.
     # Note 1: Be sure to read the "Caching" section below!
     # Note 2: Avoid hash files here. Use btree instead.
     address_verify_map = btree:/var/lib/postfix/verify
@@ -403,7 +434,8 @@ sender address verification probe fails with some temporary error.
 
    Address verification database
    
 
 
     To improve performance, the Postfix verify(8) daemon can save
-address verification results to a persistent database.  The
+address verification results to a persistent database. This is
+enabled by default with Postfix 2.7 and later.  The
 address_verify_map (NOTE: singular) configuration parameter specifies
 persistent storage for sender or recipient address verification
 results.  If you specify an empty value, all address verification
diff --git a/postfix/html/OVERVIEW.html b/postfix/html/OVERVIEW.html
index 7a332d9c1..689b340fb 100644
--- a/postfix/html/OVERVIEW.html
+++ b/postfix/html/OVERVIEW.html
@@ -651,31 +651,126 @@ align="center" bgcolor="#f0f0ff"> smtp
     session
     cache 
 
 
  •  
     The verify(8) server verifies that a sender or recipient
 address is deliverable before the smtpd(8) server accepts it.  The
-verify(8) server injects probe messages into the Postfix queue and
-processes status updates from delivery agents and/or queue manager.
+verify(8) server queries a cache with address verification results.
+If a result is not found, the verify(8) server injects a probe
+message into the Postfix queue and processes the status update from
+a delivery agent or queue manager.
 This process is described in the ADDRESS_VERIFICATION_README
 document.  The verify(8) service is available with Postfix version
 2.1 and later.
    • Internet + +   -> -> probe
    + message     		Postfix
    SMTP
    server         		-> + <-> + + Postfix
    mail
    queue
    Internet -> + + Postfix
    SMTP
    server         		<-> + Postfix
    verify
    server         		<-> -
    Address
    - verification
    database
    |
    + v
    <- +     probe
    + status     		|
    - probe
    messages
    v     		<- + + Postfix
    delivery
    agents     		^
    delivery
    - status
    |     		-> + Local
    -> Remote
    +   + ^
    |
    v
    - Postfix
    queue
     
    ->
    - Postfix
    delivery
    agents     		  + Address
    verification
    database
    - - - + + + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Network -> smtpd(8) <-> verify(8) --> cleanup(8) - -> -qmgr(8)
    Postfix
    queue     		-> Delivery
    agents
    +   + -> probe
    message     		-> + Postfix
    mail
    queue
    -\
    \
    -    		 <- <- - |
    v
    - /
    /
    +
    Network -> + smtpd(8) <-> verify(8) +
    |
    v
    <- + probe
    + status     		+ <- Postfix
    delivery
    agents +     		-> + Local
    -> Network
    +   + ^
    |
    v
     
      Address
    + verification
    cache
    + +

  • The postscreen(8) server can be put "in front" of Postfix +smtpd(8) processes. Its purpose is to accept connections from the +network and to decide what SMTP clients are allowed to talk to +Postfix. According to the 2008 MessageLabs annual report, 81% of +all email was spam, and 90% of that was sent by botnets. While +postscreen(8) keeps the zombies away, more smtpd(8) processes remain +available for legitimate clients.

    + +

    The postscreen(8) server is still evolving, and is likely to +undergo changes that break compatibility with earlier versions. +For this reason the postscreen(8) server is not installed with the +stable Postfix release.

    + + + + + + + + + + + + + + + + + + + + + + + +
    zombie
    \
    zombie - + - smtpd(8)
    \ /
    other +--- +postscreen(8)
    / \
    other + - + - smtpd(8)
    /
    zombie
    diff --git a/postfix/html/SASL_README.html b/postfix/html/SASL_README.html index 7d314e901..b475ab3d7 100644 --- a/postfix/html/SASL_README.html +++ b/postfix/html/SASL_README.html @@ -1,8 +1,6 @@ - - Postfix SASL Howto @@ -17,231 +15,1107 @@
    -

    WARNING

    +

    Warning

    People who go to the trouble of installing Postfix may have the expectation that Postfix is more secure than some other mailers. -The Cyrus SASL library is a lot of code. With this, Postfix becomes -as secure as other mail systems that use the Cyrus SASL library. -Dovecot provides an alternative that may be worth considering. -

    +The Cyrus SASL library contains a lot of code. With this, Postfix +becomes as secure as other mail systems that use the Cyrus SASL +library. Dovecot provides an alternative that may be worth +considering.

    -

    How Postfix uses SASL authentication information

    +

    How Postfix uses SASL authentication

    -

    Postfix SASL support (RFC 4954, formerly RFC 2554) can be used -to authenticate -remote SMTP clients to the Postfix SMTP server, and to authenticate -the Postfix SMTP client to a remote SMTP server.

    +

    When an SMTP client connects to an SMTP server, the server needs +to decide whether that client is authorized to send mail to remote +destinations, or whether the client can send mail only to the +destinations that the server itself is responsible for. Usually, +the SMTP server will allow mail to remote destinations only if the +client's IP address is in the "same network" as the server's IP +address.

    -

    When receiving mail, the Postfix SMTP server logs the client-provided -username, -authentication method, and sender address to the maillog file, and -optionally grants mail access via the permit_sasl_authenticated -UCE restriction.

    +

    Sometimes the SMTP client and server are in different networks, +but the client still needs "same network" privileges. To address +this problem, Postfix supports SASL authentication (RFC 4954, +formerly RFC 2554). With this a remote SMTP client can authenticate +to the Postfix SMTP server, and the Postfix SMTP client can +authenticate to a remote SMTP server. Once the client is authenticated +the server can give it "same network" privileges.

    -

    When sending mail, the Postfix SMTP client can look up the -remote SMTP server hostname or -destination domain (the address right-hand part) in a SASL password -table, and if a username/password is found, it will use that username -and password to authenticate to the remote SMTP server. And as of -version 2.3, -Postfix can be configured to search its SASL password table by the -sender email address.

    +

    Postfix does not implement SASL itself, but instead uses existing +implementations as building blocks. This means that some SASL-related +configuration will involve files that belong to Postfix, while other +configuration will involve files that belong to the specific SASL +implementation that Postfix will use. This document covers both the +Postfix and non-Postfix configuration.

    -

    This document covers the following topics:

    +

    You can read more about the following topics:

    -

    What SASL implementations are supported

    +

    Configuring SASL authentication in the +Postfix SMTP server

    -

    This document describes Postfix with the following SASL -implementations:

    +

    As mentioned earlier, SASL is implemented separately from +Postfix. For this reason, configuring SASL authentication in the +Postfix SMTP server involves two different steps:

      -

    • Cyrus SASL version 1 (client and server).

      +

    • Configuring the SASL implementation to offer a list of +mechanisms that are suitable for SASL authentication and, depending +on the SASL implementation used, configuring authentication backends +that verify the remote SMTP client's authentication data against +the system password file or some other database.

      • -

    • Cyrus SASL version 2 (client and server).

      - -

    • Dovecot protocol version 1 (server only, Postfix version -2.3 and later)

      +

    • Configuring the Postfix SMTP server to enable SASL +authentication, and to authorize clients to relay mail or to control +what envelope sender addresses the client may use.

    -

    Postfix version 2.3 introduces a plug-in mechanism that provides -support for multiple SASL implementations. To find out what -implementations are built into Postfix, use the following commands: +

    Successful authentication in the Postfix SMTP server requires +a functional SASL framework. Configuring SASL should therefore +always be the first step.

    + +

    You can read more about the following topics:

    + + + + +

    Which SASL Implementations are supported?

    + +

    Currently the Postfix SMTP server supports the Cyrus SASL and +Dovecot SASL implementations.

    + +
    + +Note + +

    Before Postfix version 2.3, Postfix had support only for Cyrus +SASL. Current Postfix versions have a plug-in architecture that +can support multiple SASL implementations.

    + +
    + +

    To find out what SASL implementations are compiled into Postfix, +use the following commands:

    + +
    +
    +% postconf -a (SASL support in the SMTP server)
+% postconf -A (SASL support in the SMTP+LMTP client)
+
    +
    + +

    These commands are available only with Postfix version 2.3 and +later.

    + +

    Configuring Dovecot SASL

    + +

    Dovecot is a POP/IMAP server that must be configured to +authenticate POP/IMAP clients. When the Postfix SMTP server uses +Dovecot SASL, it also reuses this configuration. Consult the Dovecot documentation for how +to configure and operate the Dovecot authentication server.

    + +

    Postfix to Dovecot SASL communication

    + +

    Communication between the Postfix SMTP server +and Dovecot SASL happens via a UNIX-domain socket. The socket +pathname and the list of mechanisms offered to Postfix need to be +specified on the Dovecot server side in dovecot.conf. +

    + +

    The following example assumes that the Postfix queue is under +/var/spool/postfix/.

    + +
    +
    + 1 /etc/dovecot.conf:
+ 2     auth default {
+ 3       mechanisms = plain login
+ 4         passdb pam {
+ 5         }
+ 6         userdb passwd {
+ 7         }
+ 8         socket listen {
+ 9         client {
+10           path = /var/spool/postfix/private/auth
+11           mode = 0660
+12           user = postfix
+13           group = postfix
+14         }
+15       }
+16     }
+
    +
    + +

    Line 3 provides plain and login as +mechanisms for the Postfix SMTP server, line 10 places the Dovecot +SASL socket in /var/spool/postfix/private/auth, and +lines 11-13 limit read+write permissions to user and group +postfix only.

    + +

    Proceed with the section "Enabling SASL authentication and +authorization in the Postfix SMTP server" to turn on and use +SASL in the Postfix SMTP server.

    + +

    Configuring Cyrus SASL

    + +

    The Cyrus SASL framework was supports a wide variety of +applications. Different applications may require different +configurations. As a consequence each application may have its own +configuration file.

    + +

    The first step configuring Cyrus SASL is to determine name and +location of a configuration file that describes how the Postfix +SMTP server will use the SASL framework.

    + +

    Cyrus SASL configuration file name

    + +

    The name of the configuration file (default: smtpd.conf) +is configurable. It is a concatenation from a value that the Postfix +SMTP server sends to the Cyrus SASL library, and the suffix +.conf, added by Cyrus SASL.

    + +

    The value sent by Postfix is the name of the server component +that will use Cyrus SASL. It defaults to smtpd and +is configured with one of the following variables:

    + +
    +
    +/etc/postfix/main.cf:
+    # Postfix 2.3 and later
+    smtpd_sasl_path = smtpd
+
+    # Postfix < 2.3
+    smtpd_sasl_application_name = smtpd
+
    +
    + +

    Cyrus SASL configuration file +location

    + +

    The location where Cyrus SASL searches for the named file depends +on the Cyrus SASL version and the OS/distribution used.

    + +

    You can read more about the following topics:

    + +
      + +

    • Cyrus SASL version 2.x searches for the configuration file +in /usr/lib/sasl2/.

      • + +

    • Cyrus SASL version 2.1.22 and newer additionally search +in /etc/sasl2/.

      • + +

    • Some Postfix distributions are modified and look for the +Cyrus SASL configuration file in /etc/postfix/sasl/, +/var/lib/sasl2/ etc. See the distribution-specific +documentation to determine the expected location.

      • + +
    + +
    + +Note + +

    Cyrus SASL searches /usr/lib/sasl2/ first. If it +finds the specified configuration file there, it will not examine +other locations.

    + +
    + +

    Postfix to Cyrus SASL communication

    + +

    As the Postfix SMTP server is linked with the Cyrus SASL library +libsasl, communication between Postfix and Cyrus SASL +takes place by calling functions in the SASL library.

    + +

    The SASL library may use an external password verification +service, or an internal plugin to connect to authentication backends +and verify the SMTP client's authentication data against the system +password file or other databases.

    + +

    The following table shows typical combinations discussed in +this document:

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    authentication backendpassword verification service / plugin
    /etc/shadowsaslauthd
    PAMsaslauthd
    IMAP serversaslauthd
    sasldbsasldb
    MySQL, PostgreSQL, SQLitesql
    LDAPldapdb
    + +
    + +
    + +Note + +

    Read the Cyrus SASL documentation for other backends it can +use.

    + +
    + +

    saslauthd - Cyrus SASL password verification service

    + +

    Communication between the Postfix SMTP server (read: Cyrus SASL's +libsasl) and the saslauthd server takes +place over a UNIX-domain socket.

    + +

    saslauthd usually establishes the UNIX domain +socket in /var/run/saslauthd/ and waits for authentication +requests. The Postfix SMTP server must have read+execute permission +to this directory or authentication attempts will fail.

    + +
    + +Important + +

    Some distributions require the user postfix to be +member of a special group e.g. sasl, otherwise it +will not be able to access the saslauthd socket +directory.

    + +
    + +

    The following example configures the Cyrus SASL library to +contact saslauthd as its password verification service: 

    -% postconf -a (SASL support in the SMTP server)
-% postconf -A (SASL support in the SMTP+LMTP client)
+/etc/sasl2/smtpd.conf:
+    pwcheck_method: saslauthd
+    mech_list: PLAIN LOGIN
    -

    Needless to say, these commands are not available in earlier -Postfix versions.

    +
    -

    Building Postfix with Dovecot SASL -support

    +Important -

    These instructions assume that you build Postfix from source -code as described in the INSTALL document. Some modification may -be required if you build Postfix from a vendor-specific source -package.

    +

    Do not specify any other mechanisms in mech_list +than PLAIN or LOGIN when using +saslauthd! It can only handle these two mechanisms, +and authentication will fail if clients are allowed to choose other +mechanisms.

    -

    Support for the Dovecot version 1 SASL protocol is available -in Postfix 2.3 and later. At the time -of writing, only server-side SASL support is available, so you can't -use it to authenticate to your network provider's server. Dovecot -uses its own daemon process for authentication. This keeps the -Postfix build process simple, because there is no need to link extra -libraries into Postfix.

    +
    -

    To generate the necessary Makefiles, execute the following -in the Postfix top-level directory:

    +
    + +Important + +

    Plaintext mechanisms (PLAIN, LOGIN) +send credentials unencrypted. This information should be protected +by an additional security layer such as a TLS-encrypted SMTP session +(see: TLS_README).

    + +
    + +

    Additionally the saslauthd server itself must be +configured. It must be told which authentication backend to turn +to for password verification. The backend is choosen as a command +line option when saslauthd is started and will be shown +in the following examples.

    + +
    + +Note + +

    Some distributions use a configuration file to provide saslauthd +command line options to set e.g. the authentication backend. Typical +locations are /etc/sysconfig/saslauthd or +/etc/default/saslauthd.

    + +
    + +

    Using saslauthd with /etc/shadow

    + +

    Access to the /etc/shadow system password file +requires root privileges. The Postfix SMTP server +(and in consequence libsasl linked to the server) runs +with the least privilege possible. Direct access to +/etc/shadow would not be possible without breaking the +Postfix security architecture.

    + +

    The saslauthd socket builds a safe bridge. Postfix, +running as limited user postfix, can access the +UNIX-domain socket that saslauthd receives commands +on; saslauthd, running as privileged user root, +has the privileges required to access the shadow file.

    + +

    The saslauthd server verifies passwords against the +authentication backend /etc/shadow if started like this: 

    -% make makefiles CCARGS='-DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\"'
+% saslauthd -a shadow
    -

    After this, proceed with "make" as described in the -INSTALL document.

    +

    See section "Testing saslauthd +authentication" for test instructions.

    -

    Notes:

    +

    Using saslauthd with PAM

    -
      - -

    • The "-DDEF_SERVER_SASL_TYPE" stuff is not necessary; it just -makes Postfix configuration a little more convenient because you -don't have to specify the SASL plug-in type in the Postfix main.cf -file.

      - -

    • If you also want support for LDAP or TLS, you will have to merge -their CCARGS and AUXLIBS into the above command line.

      - -
    - -

    Building the Cyrus SASL library

    - -

    Postfix appears to work with cyrus-sasl-1.5.x or cyrus-sasl-2.1.x, -which are available from:

    +

    Cyrus SASL can use the PAM framework to authenticate credentials. +saslauthd uses the PAM framework when started like +this: 

    -ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/
+% saslauthd -a pam
    -

    IMPORTANT: if you install the Cyrus SASL libraries as per the -default, you will have to symlink /usr/lib/sasl -> /usr/local/lib/sasl -for version 1.5.x or /usr/lib/sasl2 -> /usr/local/lib/sasl2 for -version 2.1.x.

    +
    -

    Reportedly, Microsoft Outlook (Express) requires the -non-standard LOGIN authentication method. To enable this -authentication method, specify ``./configure --enable-login''.

    +Note -

    Building Postfix with Cyrus SASL support

    +

    PAM configuration for the Postfix SMTP server is usually given +in /etc/pam.d/smtp and is beyond the scope of this +document.

    -

    These instructions assume that you build Postfix from source -code as described in the INSTALL document. Some modification may -be required if you build Postfix from a vendor-specific source -package.

    +
    -

    The following -assumes that the Cyrus SASL include files are in /usr/local/include, -and that the Cyrus SASL libraries are in /usr/local/lib.

    +

    See section "Testing saslauthd +authentication" for test instructions.

    -

    On some systems this generates the necessary Makefile definitions: -

    +

    Using saslauthd with an IMAP server

    + +

    saslauthd can verify the SMTP client credentials +by using them to log into an IMAP server. If the login succeeds, +SASL authentication also succeeds. saslauthd contacts +an IMAP server when started like this:

    + +
    +
    +% saslauthd -a rimap -O imap.example.com
+
    +
    + +
    + +Note + +

    The option "-O imap.example.com" specifies the +IMAP server saslauthd should contact when it verifies +credentials.

    + +
    + +
    + +Important + +

    saslauthd sends IMAP login information unencrypted. +Any IMAP session leaving the local host should be protected by an +additional security layer such as an SSL tunnel.

    + +
    + +

    See section "Testing saslauthd +authentication" for test instructions.

    + +

    Testing saslauthd authentication

    + +

    Cyrus SASL provides the testsaslauthd utility to +test saslauthd authentication. The username and password +are given as command line arguments. The example shows the response +when authentication is successful:

    + +
    +
    +% testsaslauthd -u username -p password
+0: OK "Success."
+
    +
    + +
    + +Note + +

    Sometimes the testsaslauthd program is not distributed +with a the Cyrus SASL main package. In that case, it may be +distributed with -devel, -dev or -debug packages.

    + +
    + +

    Specify an additional "-s smtp" if saslauthd +was configured to contact the PAM authentication framework and an +additional "-f /path/to/socketdir/mux" if +saslauthd establishes the UNIX-domain socket in a +non-default location.

    + +

    If authentication succeeds, proceed with the section "Enabling SASL authentication and authorization +in the Postfix SMTP server".

    + +

    Cyrus SASL Plugins - auxiliary property +plugins

    + +

    Cyrus SASL uses a plugin infrastructure (called auxprop) +to expand libsasl's capabilities. Currently Cyrus +SASL sources provide three authentication plugins.

    + +
    -
    (for Cyrus SASL version 1.5.x): -
    -
    -% make tidy # if you have left-over files from a previous build
-% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
-    -I/usr/local/include" AUXLIBS="-L/usr/local/lib -lsasl"
-
    +
    sasldb
    -
    (for Cyrus SASL version 2.1.x): -
    -
    -% make tidy # if you have left-over files from a previous build
-% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
-    -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib -lsasl2"
-
    +

    Accounts are stored stored in a Cyrus SASL Berkeley DB +database

    + +
    sql
    + +

    Accounts are stored in a SQL database

    + +
    ldapdb
    + +

    Accounts are stored stored in an LDAP database

    -

    On Solaris 2.x you need to specify run-time link information, -otherwise ld.so will not find the SASL shared library:

    +
    + +
    + +Important + +

    These three plugins support shared-secret mechanisms i.e. +CRAM-MD5, DIGEST-MD5 and NTLM. These mechanisms send credentials +encrypted but their verification process requires the password to +be available in plaintext. Consequently passwords cannot (!) be +stored in encrypted form.

    + +
    + +

    The sasldb plugin

    + +

    The sasldb auxprop plugin authenticates credentials stored in a Berkeley +DB database. The database schema is specific to Cyrus SASL. The +database is usually located at /etc/sasldb2.

    + +
    + +Note + +

    The sasldb2 file contains passwords in +plaintext, and should have read+write access only to user +postfix or a group that postfix is member +of.

    + +
    + +

    The saslpasswd2 command-line utility creates +and maintains the database:

    + +
    +
    +% saslpasswd2 -c -u example.com username
+Password:
+Again (for verification):
+
    +
    + +

    This command creates an account +username@example.com.

    + +
    + +Important + +

    users must specify username@example.com +as login name, not username.

    + +
    + +

    Run the following command to reuse the Postfix mydomain +parameter value as the login domain:

    + +
    +
    +% saslpasswd2 -c -u `postconf -h mydomain` username
+Password:
+Again (for verification):
+
    +
    + +
    + +Note + +

    Run saslpasswd2 without any options for further +help on how to use the command.

    + +
    + +

    The sasldblistusers2 command lists all existing +users in the sasldb database:

    + +
    +
    +% sasldblistusers2
+username1@example.com: password1
+username2@example.com: password2
+
    +
    + +

    Configure libsasl to use sasldb with the following instructions:

    + +
    +
    +/etc/sasl2/smtpd.conf:
+    pwcheck_method: auxprop
+    auxprop_plugin: sasldb
+    mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
+
    +
    + +
    + +Note + +

    In the above example adjust mech_list to the +mechanisms that are applicable for your environment.

    + +
    + +

    The sql plugin

    + +

    The sql auxprop plugin is a generic SQL plugin. It provides +access to credentials stored in a MySQL, a PostgreSQL or a SQLite +database.

    + +
    + +Note + +

    The shared-secret mechanisms (CRAM-MD5, etc.) require that the +SASL client passwords are stored as plaintext.

    + +
    + +
    + +Tip + + + +

    Use "saslauthd > pam > (pam database module)" to +verify encrypted passwords in an SQL database.

    + +
    + +

    The following example configures libsasl to use the sql plugin and connects +it to a PostgreSQL server:

    + +
    +
    +/etc/sasl2/smtpd.conf:
+    pwcheck_method: auxprop
+    auxprop_plugin: sql
+    mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
+    sql_engine: pgsql
+    sql_hostnames: 127.0.0.1, 192.0.2.1 sql_user: username
+    sql_passwd: secret
+    sql_database: dbname
+    sql_select: SELECT password FROM users WHERE user = '%u'@'%r'
+
    +
    + +
    + +Note + +

    Set appropriate permissions if smtpd.conf contains +a password. The file should be readable by the postfix +user.

    + +
    + +
    + +Note + +

    In the above example, adjust mech_list to the +mechanisms that are applicable for your environment.

    + +
    + +

    The sql plugin has the following configuration options:

    + +
    -
    (for Cyrus SASL version 1.5.x): -
    -
    -% make tidy # if you have left-over files from a previous build
-% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
-    -I/usr/local/include" AUXLIBS="-L/usr/local/lib \
-    -R/usr/local/lib -lsasl"
-
    +
    sql_engine
    -
    (for Cyrus SASL version 2.1.x):
    -
    -% make tidy # if you have left-over files from a previous build
-% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
-    -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib \
-    -R/usr/local/lib -lsasl2"
-
    + +

    Specify mysql to connect to a MySQL server, +pgsql for a PostgreSQL server or sqlite +for an SQLite database

    + +
    + +
    sql_hostnames
    + +
    + +

    Specify one or more servers (hostname or hostname:port) separated +by commas.

    + +
    + +Note + +

    With MySQL servers, specify localhost to connect +over a UNIX-domain socket, and specify 127.0.0.1 to +connect over a TCP socket.

    + +
    + +
    + +
    sql_user
    + +
    + +

    The login name to gain access to the database.

    + +
    + +
    sql_passwd
    + +
    + +

    The password to gain access to the database.

    + +
    + +
    sql_database
    + +
    + +

    The name of the database to connect to.

    + +
    + +
    sql_select
    + +
    + +

    The SELECT statement that should retrieve the plaintext password +from a database table.

    + +
    + +Important + +

    Do not enclose the statement in quotes! Use single quotes to +escape macros!

    + +
    + +
    -

    Enabling SASL authentication in the Postfix -SMTP server

    +
    -

    In order to enable SASL support in the Postfix SMTP server:

    +

    The sql plugin provides macros to build sql_select +statements. They will be replaced with arguments sent from the client. The +following macros are available:

    + +
    + +
    + +
    %u
    + +
    + +

    The name of the user whose properties are being selected.

    + +
    + +
    %p
    + +
    + +

    The name of the property being selected. While this could technically be +anything, Cyrus SASL will try userPassword and cmusaslsecretMECHNAME (where +MECHNAME is the name of a SASL mechanism).

    + +
    + +
    %r
    + +
    + +

    The name of the realm to which the user belongs. This could be +the KERBEROS realm, the fully-qualified domain name of the computer +the SASL application is running on, or the domain after the "@" in a +username.

    + +
    + +
    + +
    + +

    The ldapdb plugin

    + +

    The ldapdb auxprop plugin provides access to credentials stored +in an OpenLDAP LDAP server. It is the only plugin that implements +proxy authorization.

    + +

    Proxy authorization in this context means: The ldapdb plugin +must SASL authenticate with the OpenLDAP server. The server then +decides if the ldapdb plugin should be authorized to read the +authenticating user's password. Once the ldapdb plugin has gone +through proxy authorization it may proceed and authenticate the +remote SMTP client's credentials.

    + +

    In a nutshell: Configuring ldapdb means authentication and +authorization must be configured twice - once in the Postfix SMTP +server to authenticate and authorize the remote SMTP client, and +once in the OpenLDAP slapd server to authenticate and +authorize the ldapdb plugin.

    + +

    This example configures libsasl to use the ldapdb plugin and +the plugin to connect to an OpenLDAP server:

    + +
    +
    +/etc/sasl2/smtpd.conf:
+    pwcheck_method: auxprop
+    auxprop_plugin: ldapdb
+    mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5
+    ldapdb_uri: ldap://localhost
+    ldapdb_id: proxyuser
+    ldapdb_pw: password
+    ldapdb_mech: DIGEST-MD5
+
    +
    + +
    + +Important + +

    Set appropriate permissions if smtpd.conf contains a +password. The file should be readable by the postfix +user.

    + +
    + +
    + +Note + +

    The shared-secret mechanisms (CRAM-MD5, etc.) require that the +SASL client passwords are stored as plaintext.

    + +
    + +

    The following is a summary of applicable smtpd.conf +file entries:

    + +
    + +
    + +
    auxprop_plugin
    + +

    Specify ldapdb to enable the plugin.

    + +
    ldapdb_uri
    + +

    Specify either ldapi:// for to connect over +a UNIX-domain socket, ldap:// for an unencrypted TCP +connection or ldaps:// for an encrypted TCP connection. +

    + +
    ldapdb_id
    + +

    The login name to authenticate the ldapdb plugin to the +LDAP server (proxy authorization).

    + +
    ldapdb_pw
    + +

    The password (in plaintext) to authenticate the ldapdb +plugin to the LDAP server (proxy authorization).

    + +
    ldapdb_mech
    + +

    The mechanism to authenticate the ldapdb plugin to the +OpenLDAP slapd server.

    + +
    + +Note + +

    Specify a mechanism here that is supported by the OpenLDAP slapd +server.

    + +
    + +
    + +
    ldapdb_rc (optional)
    + +

    The path to a file containing individual configuration +options for the ldapdb LDAP client (libldap). This allows to specify +a TLS client certificate which in turn can be used to use the SASL +EXTERNAL mechanism.

    + +
    + +Note + +

    This mechanism supports authentication over an encrypted transport +layer, which is recommended if the plugin must connect to an OpenLDAP +server on a remote machine.

    + +
    + +
    + +
    ldapdb_starttls (optional)
    + +

    The TLS policy for connecting to the LDAP server. Specify +either try or demand. If the option is +try the plugin will attempt to establish a TLS-encrypted +connection with the LDAP server, and will fallback to an unencrypted +connection if TLS fails. If the policy is demand and +a TLS-encrypted connection cannot be established, the connection +fails immediately.

    + +
    + +
    + +

    When the ldapdb plugin connects to the OpenLDAP server and +successfully authenticates, the OpenLDAP server decides if the +plugin user is authorized to read SASL account information.

    + +

    The following configuration gives an example of authorization configuration +in the OpenLDAP slapd server:

    + +
    +
    +/etc/openldap/slapd.conf:
+    authz-regexp
+    uid=(.*),cn=.*,cn=auth
+    ldap:///dc=example,dc=com??sub?cn=$1
+    authz-policy to
+
    +
    + +

    Here, the authz-regexp option serves for authentication +of the ldapdb user. It maps its login name to a DN in the LDAP +directory tree where slapd can look up the SASL account +information. The authz-policy options defines the +authentication policy. In this case it grants authentication +privileges "to" the ldapdb plugin.

    + +

    The last configuration step is to tell the OpenLDAP slapd +server where ldapdb may search for usernames matching the one given +by the mail client. The example below adds an additional attribute +ldapdb user object (here: authzTo because the authz-policy +is "to") and configures the scope where the login name +"proxyuser" may search:

    + +
    +
    +dn: cn=proxyuser,dc=example,dc=com
+changetype: modify
+add: authzTo
+authzTo: dn.regex:uniqueIdentifier=(.*),ou=people,dc=example,dc=com
+
    +
    + +

    Use the ldapmodify or ldapadd command +to add the above attribute.

    + +
    + +Note + +

    Read the chapter "Using SASL" in the OpenLDAP Admin Guide +for more detailed instructions to set up SASL authentication in +OpenLDAP.

    + +
    + +

    Enabling SASL authentication and +authorization in the Postfix SMTP server

    + +

    By default the Postfix SMTP server uses the Cyrus SASL +implementation. If the Dovecot SASL implementation should be used, +specify an smtpd_sasl_type value of dovecot +instead of cyrus:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_type = dovecot
+
    +
    + +

    Additionally set the path where the Postfix SMTP server can +find the Dovecot SASL socket:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_path = private/auth
+
    +
    + +
    + +Note + +

    This example uses a pathname relative to the Postfix queue +directory, so that it will work whether or not the Postfix SMTP +server runs chrooted.

    + +
    + +

    Enabling SASL authentication +in the Postfix SMTP server

    + +

    Regardless of the SASL implementation type, enabling SMTP +authentication in the Postfix SMTP server always requires seting +the smtpd_sasl_auth_enable option: 

    @@ -250,38 +1124,32 @@ SMTP server
    -

    In order to allow mail relaying by authenticated remote SMTP -clients:

    +

    After a "postfix reload", SMTP clients will see the additional +capability AUTH in an SMTP session, followed by a list of +authentication mechanisms the server supports: 

    -/etc/postfix/main.cf:
-    smtpd_recipient_restrictions = 
-        permit_mynetworks 
-        permit_sasl_authenticated 
-        reject_unauth_destination
+% telnet server.example.com 25
+...
+220 server.example.com ESMTP Postfix
+EHLO client.example.com
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+...
    -

    To report SASL login names in Received: message headers -(Postfix version 2.3 and later):

    +

    However not all clients recognize the AUTH capability as defined +by the SASL authentication RFC. Some historical implementations expect the +server to send an "=" as separator between the AUTH +verb and the list of mechanisms that follows it.

    -
    -
    -/etc/postfix/main.cf:
-    smtpd_sasl_authenticated_header = yes
-
    -
    - -

    Note: the SASL login names will be shared with the entire world. -

    - -

    Older Microsoft SMTP client software implements a non-standard -version of the AUTH protocol syntax, and expects that the SMTP -server replies to EHLO with "250 AUTH=mechanism-list" instead of -"250 AUTH mechanism-list". To accommodate such clients (in addition -to conformant -clients) use the following:

    +

    The broken_sasl_auth_clients configuration option +lets Postfix repeat the AUTH statement in a form that these broken +clients understand: 

    @@ -290,454 +1158,507 @@ clients) use the following:
    -

    Dovecot SASL configuration for the -Postfix SMTP server

    +
    -

    Dovecot SASL support is available in Postfix 2.3 and later. On -the Postfix side you need to specify the location of the -Dovecot authentication daemon socket. We use a pathname relative -to the Postfix queue directory, so that it will work whether or not -the Postfix SMTP server runs chrooted:

    +Note + +

    Enable this option for Outlook up to and including version 2003 +and Outlook Express up to version 6. This option does not hurt other +clients.

    + +
    + +

    After "postfix reload", the Postfix SMTP server will propagate +the AUTH capability twice - once for compliant and once for broken +clients:

    + +
    +
    +% telnet server.example.com 25
+...
+EHLO client.example.com
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+250-AUTH=DIGEST-MD5 PLAIN CRAM-MD5
+...
+
    +
    + +

    Postfix SMTP Server +Authentication Policy

    + +

    The Postfix SMTP server provides a way to specify the properties +of SASL mechanisms that can be made available to the remote SMTP +client.

    + +

    Unencrypted SMTP session

    + +

    The default policy is to allow any mechanism in the Postfix SMTP server +except for those based on anonymous authentication: 

     /etc/postfix/main.cf:
-    smtpd_sasl_type = dovecot
-    smtpd_sasl_path = private/auth
+    # Specify a list of properties separated by comma or whitespace
+    smtpd_sasl_security_options = noanonymous
    -

    On the Dovecot side you also need to specify the Dovecot -authentication daemon socket. In this case we specify an -absolute pathname. In the example we assume that the -Postfix queue is under /var/spool/postfix/.

    -
    -
    -/some/where/dovecot.conf:
-    auth default {
-      mechanisms = plain login
-      passdb pam {
-      }
-      userdb passwd {
-      }
-      socket listen {
-        client {
-          path = /var/spool/postfix/private/auth
-          mode = 0660
-          user = postfix
-          group = postfix
-        }
-      }
-    }
-
    + +Important + +

    Always set at least the noanonymous option. +Otherwise, the Postfix SMTP server can give strangers the same +authorization as a properly-authenticated client.

    +
    -

    See the Dovecot documentation for how to configure and operate -the Dovecot authentication server.

    +

    Postfix can enforce the following policies on SASL authentication +mechanisms:

    -

    Cyrus SASL configuration for the Postfix -SMTP server

    +
    -

    You need to configure how the Cyrus SASL library should -authenticate a remote SMTP client's username and password. These -settings must -be stored in a separate configuration file.

    +
    -

    The name of the configuration file (default: smtpd.conf) will -be constructed from a value that the Postfix SMTP server sends to -the Cyrus SASL -library, which adds the suffix .conf. The value is configured using -one of the following variables:

    +
    noanonymous
    + +

    Don't use mechanisms that permit anonymous authentication. +

    + +
    noplaintext
    + +

    Don't use mechanisms that transmit unencrypted username +and password information.

    + +
    nodictionary
    + +

    Don't use mechanisms that are vulnerable to dictionary +attacks.

    + +
    + +
    forward_secrecy
    + +

    Use only mechanisms that support forward secrecy (Dovecot +SASL only).

    + +
    + +
    mutual_auth
    + +

    Use only mechanisms that authenticate both the client and +the server to each other.

    + +
    + +
    + +

    Encrypted SMTP session (TLS)

    + +

    A separate parameter controls Postfix SASL mechanism policy +during a TLS-encrypted SMTP session. The default is to copy the +settings from the unencrypted session: 

     /etc/postfix/main.cf:
-    # Postfix 2.3 and later
-    smtpd_sasl_path = smtpd
-    # Postfix < 2.3
-    smtpd_sasl_application_name = smtpd
+    smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
    -

    Cyrus SASL searches for the configuration file in /usr/local/lib/sasl/ -(Cyrus SASL version 1.5.5) or /usr/local/lib/sasl2/ (Cyrus SASL -version 2.1.x).

    +

    A more sophisticated policy allows plaintext mechanisms, but +only over a TLS-encrypted connection:

    -

    Note: some Postfix distributions are modified and look for -the smtpd.conf file in /etc/postfix/sasl.

    +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_security_options = noanonymous, noplaintext
+    smtpd_sasl_tls_security_options = noanonymous
+
    +
    -

    Note: some Cyrus SASL distributions look for the smtpd.conf -file in /etc/sasl2.

    +

    To offer SASL authentication only after a TLS-encrypted session has been +established specify this:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_tls_auth_only = yes
+
    +
    + +

    Enabling SASL authorization in the Postfix +SMTP server

    + +

    After the client has authenticated with SASL, the Postfix SMTP +server decides what the remote SMTP client will be authorized +for. Examples of possible SMTP clients authorizations are:

      -

    • To authenticate against the UNIX password database, use:

      +

    • Send a message to a remote recipient.

      • -
      -
      (Cyrus SASL version 1.5.x) -
      -
      -/usr/local/lib/sasl/smtpd.conf:
-    pwcheck_method: pwcheck
+
    •  
       Use a specific envelope sender in the MAIL FROM command. 
       
      • 
 
-
      +
    -

    IMPORTANT: pwcheck establishes a UNIX domain socket in /var/pwcheck -and waits for authentication requests. The Postfix SMTP server must have -read+execute permission to this directory or authentication attempts -will fail.

    +

    These permissions are not enabled by default.

    -

    The pwcheck daemon is contained in the cyrus-sasl source tarball.

    +

    Mail relay authorization

    -
    (Cyrus SASL version 1.5.26) -
    -
    -/usr/local/lib/sasl/smtpd.conf:
-    pwcheck_method: saslauthd
-
    - -
    (Cyrus SASL version 2.1.x) -
    -
    -/usr/local/lib/sasl2/smtpd.conf:
-    pwcheck_method: saslauthd
-    mech_list: PLAIN LOGIN
-
    - - - -

    The saslauthd daemon is also contained in the cyrus-sasl source -tarball. It is more flexible than the pwcheck daemon, in that it -can authenticate against PAM and various other sources. To use PAM, -start saslauthd with "-a pam".

    - -

    IMPORTANT: saslauthd usually establishes a UNIX domain socket -in /var/run/saslauthd and waits for authentication requests. The Postfix -SMTP server must have read+execute permission to this directory or -authentication attempts will fail.

    - -

    Note: The directory where saslauthd puts the socket is configurable. -See the command-line option "-m /path/to/socket" in the saslauthd ---help listing.

    - -

  • To authenticate against Cyrus SASL's own password database:

    - -
    -
    (Cyrus SASL version 1.5.x) -
    -
    -/usr/local/lib/sasl/smtpd.conf:
-    pwcheck_method: sasldb
-
    - -
    (Cyrus SASL version 2.1.x) -
    -
    -/usr/local/lib/sasl2/smtpd.conf:
-    pwcheck_method: auxprop
-    auxprop_plugin: sasldb
-    mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5
-
    - -
    - -

    This will use the Cyrus SASL password file (default: /etc/sasldb in -version 1.5.x, or /etc/sasldb2 in version 2.1.x), which is maintained -with the saslpasswd or saslpasswd2 command (part of the Cyrus SASL -software). On some poorly-supported systems the saslpasswd command needs -to be run multiple times before it stops complaining. The Postfix SMTP -server needs read access to the sasldb file - you may have to play games -with group access permissions. With the OTP authentication mechanism, -the Postfix SMTP server also needs WRITE access to /etc/sasldb2 or -/etc/sasldb -(or the back end SQL database, if used).

    - -

    IMPORTANT: To get sasldb running, make sure that you set the SASL -domain (realm) to a fully qualified domain name.

    - -

    EXAMPLE:

    - -
    -
    (Cyrus SASL version 1.5.x) -
    -
    -% saslpasswd -c -u `postconf -h myhostname` exampleuser
-
    - -
    (Cyrus SASL version 2.1.x) -
    -
    -% saslpasswd2 -c -u `postconf -h myhostname` exampleuser
-
    - -
    - -

    You can find out SASL's idea about the realms of the users -in sasldb with sasldblistusers (Cyrus SASL version 1.5.x) or -sasldblistusers2 (Cyrus SASL version 2.1.x).

    - -

    On the Postfix side, you can have only one realm per smtpd(8) -instance, and only the users belonging to that realm would be able to -authenticate. The Postfix variable smtpd_sasl_local_domain controls the -realm used by smtpd(8):

    +

    The permit_sasl_authenticated restriction allows +SASL-authenticated SMTP clients to send mail to remote destinations. +Add it to the list of smtpd_recipient_restrictions as +follows: 

     /etc/postfix/main.cf:
-    smtpd_sasl_local_domain = $myhostname
+    smtpd_recipient_restrictions =
+    ...
+    permit_mynetworks
+    permit_sasl_authenticated
+    reject_unauth_destination
+    ...
    - +

    Envelope sender address authorization

    -

    IMPORTANT: The Cyrus SASL password verification services pwcheck -and saslauthd can only support the plaintext mechanisms PLAIN or -LOGIN. However, the Cyrus SASL library doesn't know this, and will -happily advertise other authentication mechanisms that the SASL -library implements, such as DIGEST-MD5. As a result, if a remote SMTP -client chooses any mechanism other than PLAIN or LOGIN while pwcheck -or saslauthd are used, authentication will fail. Thus you may need -to limit the list of mechanisms advertised by the Postfix SMTP -server.

    +

    By default an SMTP client may specify any envelope sender address +in the MAIL FROM command. That is because the Postfix SMTP server +only knows the remte SMTP client hostname and IP address, but not +the user who controls the remote SMTP client.

    -
      - -

    • With older Cyrus SASL versions you remove the corresponding -library files from the SASL plug-in directory (and again whenever -the system is updated).

      - -

    • With Cyrus SASL version 2.1.x or later the mech_list variable -can specify a list of authentication mechanisms that Cyrus SASL may -offer:

      +

      This changes the moment an SMTP client uses SASL authentication. +Now, the Postfix SMTP server knows who the sender is. Given a table +of envelope sender addresses and SASL login names, the Postfix SMTP +server can decide if the SASL authenticated client is allowed to +use a particular envelope sender address: 

      -/usr/local/lib/sasl2/smtpd.conf:
-    mech_list: plain login
+/etc/postfix/main.cf:
+    smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders
+
+    smtpd_recipient_restrictions =
+        ...
+        reject_sender_login_mismatch
+        permit_sasl_authenticated
+        permit_mynetworks
+        reject_unauth_destination
+        ...
      -
    - -

    For the same reasons you might want to limit the list of plugins -used for authentication.

    - -
      - -

    • With Cyrus SASL version 1.5.x your only choice is to -delete the corresponding library files from the SASL plug-in -directory.

      - -

    • With SASL version 2.1.x:

      +

      The controlled_envelope_senders table specifies +the binding between the sender envelope addresses and its their +SASL login names: 

      -/usr/local/lib/sasl2/smtpd.conf:
-    pwcheck_method: auxprop
-    auxprop_plugin: sql
+/etc/postfix/controlled_envelope_senders
+    # envelope sender           owners (SASL login names)
+    john@example.com            john@example.com
+    helpdesk@example.com        john@example.com, mary@example.com
+    postmaster                  admin@example.com
+    @example.net                barney, fred, john@example.com, mary@example.com
      -
    +

    With this, the reject_sender_login_mismatch +restriction above will reject the sender address in the MAIL FROM +command if smtpd_sender_login_maps does not specify +the SMTP client's login name as an owner of that address.

    -

    To run software chrooted with SASL support is an interesting -exercise. It probably is not worth the trouble.

    +

    See also reject_authenticated_sender_login_mismatch and +reject_unauthenticated_sender_login_mismatch for additional +control over the SASL login name and the envelope sender.

    -

    Testing SASL authentication in the Postfix -SMTP server

    +

    Additional SMTP Server SASL options

    -

    To test the server side, connect (for example, with telnet) to the -Postfix SMTP server port and you should -be able to have a conversation as shown below. Information sent by the -client (that is, you) is shown in bold font.

    +

    Postfix provides a wide range of SASL authentication configuration +options. The next section lists a few that are discussed frequently. +See postconf(5) for a complete list.

    + +

    Default authentication domain

    + +

    Postfix can append a domain name (or any other string) to a +SASL login name that does not have a domain part, e.g. "john" +instead of "john@example.com": 

    -$ telnet server.example.com 25
-. . .
+/etc/postfix/main.cf:
+    smtpd_sasl_local_domain = example.com
+
    +
    + +

    This is useful as a default setting and safety net for misconfigured +clients, or during a migration to an authentication method/backend +that requires an authentication REALM or domain name, before all +SMTP clients are configured to send such information.

    + +

    Hiding SASL authentication from clients or +networks

    + +

    Some clients insist on using SASL authentication if it is offered, even +when they are not configured to send credentials - and therefore +they will always fail and disconnect.

    + +

    Postfix can hide the AUTH capability from these clients/networks:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_exceptions_networks = !192.0.2.171/32, 192.0.2.0/24
+
    +
    + +

    Adding the SASL login name to mail headers

    + +

    To report SASL login names in Received: message headers (Postfix +version 2.3 and later):

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_authenticated_header = yes
+
    +
    + +
    + +Note + +

    The SASL login names will be shared with the entire world.

    + +
    + +

    Testing SASL authentication in the Postfix SMTP Server

    + +

    To test the server side, connect (for example, with +telnet) to the Postfix SMTP server port and you should +be able to have a conversation as shown below. Information sent by +the client (that is, you) is shown in bold font.

    + +
    +
    +% telnet server.example.com 25
+...
 220 server.example.com ESMTP Postfix
-EHLO client.example.com
+EHLO client.example.com
 250-server.example.com
 250-PIPELINING
 250-SIZE 10240000
 250-ETRN
 250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
 250 8BITMIME
-AUTH PLAIN AHRlc3QAdGVzdHBhc3M=
+AUTH PLAIN AHRlc3QAdGVzdHBhc3M=
 235 Authentication successful
    -

    Instead of AHRlc3QAdGVzdHBhc3M=, specify the base64 encoded -form of \0username\0password (the \0 is a null byte). The -example above is for a user named `test' with password `testpass'. -

    - -

    In order to generate base64 encoded authentication information -you can use one of the following commands:

    - +

    Instead of AHRlc3QAdGVzdHBhc3M=, specify the +base64-encoded form of \0username\0password (the \0 +is a null byte). The example above is for a user named `test' +with password `testpass'.

    -
    -% printf '\0username\0password' | mmencode 
-
    -
    -
    -
    -% perl -MMIME::Base64 -e \
-    'print encode_base64("\0username\0password");'
-
    -
    +Caution -

    The mmencode command is part of the metamail software. -MIME::Base64 is available from http://www.cpan.org/.

    - -

    Caution: when posting logs of the SASL negotiations to public -lists, +

    When posting logs of the SASL negotiations to public lists, please keep in mind that username/password information is trivial to recover from the base64-encoded form.

    -

    Trouble shooting the SASL internals

    +
    • -

    In the Cyrus SASL sources you'll find a subdirectory named -"sample". Run make there, then create a symbolic link from sample.conf -to smtpd.conf in your Cyrus SASL library directory /usr/local/lib/sasl2. -"su" to the user postfix (or whatever your mail_owner -directive is set to):

    +

    You can use one of the following commands to generate base64 +encoded authentication information: 

    -% su postfix
+% gen-auth plain
+username: username
+password:
    -

    then run the resulting sample Cyrus SASL server and client in -separate terminals. The sample applications send log messages to -the syslog -facility auth. Check the log to fix the problem or run strace / -ktrace / truss on the server to see what makes it unhappy. Repeat -the previous step until you can successfully authenticate with the -sample Cyrus SASL client. Only then get back to Postfix.

    +

    The gen-auth Perl script was written by John +Jetmore and can be found at http://jetmore.org/john/code/gen-auth.

    -

    Enabling SASL authentication in the -Postfix SMTP client

    +
    +
    +% printf '\0username\0password' | mmencode
+
    +
    -

    Turn on client-side SASL authentication, and specify a table -with per-host or per-destination username and password information. -The Postfix SMTP client first searches the table for an entry with -the remote SMTP server hostname; if no entry is found, then the -Postfix SMTP client searches the table for -an entry with the next-hop destination. Usually, that is the -right-hand part of an email address, but it can also be the information -that is specified with the relayhost parameter or with a transport(5) -table.

    +

    The mmencode command is part of the metamail +software.

    + +
    +
    +% perl -MMIME::Base64 -e \
+    'print encode_base64("\0username\0password");'
+
    +
    + +

    MIME::Base64 is available from http://www.cpan.org/.

    + +

    Configuring SASL authentication in the Postfix SMTP/LMTP client

    + +

    The Postfix SMTP and the LMTP client can authenticate with a +remote SMTP server via the Cyrus SASL framework. At this time, the +Dovecot SASL implementation does not provide client functionality. +

    + +
    + +Note + +

    The examples in this section discuss only the SMTP client. +Replace smtp_ with lmtp_ to get the +corresponding LMTP client configuration.

    + +
    + +

    You can read more about the following topics:

    + + + +

    Enabling SASL authentication in the +Postfix SMTP/LMTP client

    + +

    This section shows a typical scenario where the Postfix SMTP +client sends all messages via a mail gateway server that requires +SASL authentication. To make the example more readable we introduce +it in two parts. 

     /etc/postfix/main.cf:
     smtp_sasl_auth_enable = yes
-    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
-    smtp_sasl_type = cyrus
-    relayhost = [mail.myisp.net]
+    relayhost = [mail.isp.example]
     # Alternative form:
-    # relayhost = [mail.myisp.net]:submission
-
-/etc/postfix/sasl_passwd:
-    [mail.myisp.net]            username:password
-    [mail.myisp.net]:submission username:password
+    # relayhost = [mail.isp.example]:submission
+    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    -

    Notes:

    + + +
    +
    +/etc/postfix/sasl_passwd:
+    # destination                   credentials
+    [mail.isp.example]              username:password
+    # Alternative form:
+    # [mail.isp.example]:submission username:password
+
    +
    + +
    + +Important + +

    Keep the SASL client password file in /etc/postfix, +and make the file read+write only for root to protect +the username/password combinations against other users. The Postfix +SMTP client will still be able to read the SASL client passwords. +It opens the file as user root before it drops privileges, +and before entering an optional chroot jail.

    + +
    -

  • Specify dbm instead of hash if your system -uses dbm files instead of db files. To find out what -lookup tables Postfix supports, use the command "postconf -m". +

    Configuring Sender-Dependent SASL +authentication

    + +

    Postfix supports different ISP accounts for different sender +addresses (version 2.3 and later). This can be useful when one +person uses the same machine for work and for personal use, or when +people with different ISP accounts share the same Postfix server.

    -

  • Execute the command "postmap /etc/postfix/sasl_passwd" -whenever you change the sasl_passwd table.

    - - - -

    Workarounds:

    - - - -

    Supporting multiple ISP accounts -in the Postfix SMTP client

    - -

    Postfix version 2.3 supports multiple ISP accounts. This can -be useful when one person uses the same machine for work and for -personal use, or when people with different ISP accounts share the -same Postfix server. To make this possible, Postfix 2.3 supports -per-sender SASL passwords and per-sender relay hosts. In the example -below, Postfix will search the SASL password file by sender before -it searches that same file by destination. Likewise, Postfix will -search the per-sender relayhost file, and use the default relayhost -only as a final resort.

    +

    To make this possible, Postfix supports per-sender SASL passwords +and per-sender relay hosts. In the example below, the Postfix SMTP +client will search the SASL password file by sender address before +it searches that same file by destination. Likewise, the Postfix +trivial-rewrite(8) daemon will search the per-sender relayhost file, +and use the default relayhost setting only as a final +resort. 

    @@ -746,26 +1667,33 @@ only as a final resort.  
    
     sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
     smtp_sasl_auth_enable = yes
     smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
-    relayhost = [mail.myisp.net]
+    relayhost = [mail.isp.example]
     # Alternative form:
-    # relayhost = [mail.myisp.net]:submission
-
-/etc/postfix/sasl_passwd:
-    # Per-sender authentication; see also /etc/postfix/sender_relay.
-    user1@example.com           username2:password2
-    user2@example.net           username2:password2
-    # Login information for the default relayhost.
-    [mail.myisp.net]            username:password
-    [mail.myisp.net]:submission username:password
-
-/etc/postfix/sender_relay:
-    # Per-sender provider; see also /etc/postfix/sasl_passwd.
-    user1@example.com           [mail.example.com]:submission
-    user2@example.net           [mail.example.net]
+    # relayhost = [mail.isp.example]:submission
    -

    Notes:

    +
    +
    +/etc/postfix/sasl_passwd:
+    # Per-sender authentication; see also /etc/postfix/sender_relay.
+    user1@example.com               username2:password2
+    user2@example.net               username2:password2
+    # Login information for the default relayhost.
+    [mail.isp.example]              username:password
+    # Alternative form:
+    # [mail.isp.example]:submission username:password
+
    +
    + +
    +
    +/etc/postfix/sender_relay:
+    # Per-sender provider; see also /etc/postfix/sasl_passwd.
+    user1@example.com               [mail.example.com]:submission
+    user2@example.net               [mail.example.net]
+
    +
    +

    Postfix SMTP/LMTP client authentication +policy

    + +

    Just like the Postfix SMTP server, the SMTP client has a policy +that determines which SASL mechanisms are acceptable and which are +not.

    + +

    Unencrypted SMTP session

    + +

    The default policy is stricter than that of the Postfix SMTP +server - plaintext mechanisms are not allowed (nor is any anonymous +mechanism):

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_sasl_security_options = noplaintext, noanonymous
+
    +
    + +

    Postfix can enforce the following policies on SASL authentication +mechanisms:

    + +
    + +
    + +
    noanonymous
    + +

    Don't use mechanisms that permit anonymous authentication. +

    + +
    noplaintext
    + +

    Don't use mechanisms that transmit unencrypted username +and password information.

    + +
    nodictionary
    + +

    Don't use mechanisms that are vulnerable to dictionary +attacks.

    + +
    + +
    +
    mutual_auth
    + +

    Use only mechanisms that authenticate both the client and +the server to each other.

    + +
    + +
    + +

    With the default policy shown above, the Postfix SMTP client +will not send its password over an unencrypted connection. This +sometimes leads to authentication failures if the remote server +only offers plaintext authentication mechanisms. In such cases the +SMTP client will log the following error message:

    + +
    +
    +SASL authentication failure: No worthy mechs found
+
    +
    + +

    The less secure approach to deal with this is to lower the +security standards and permit plaintext authentication mechanisms: +

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_sasl_security_options = noanonymous
+
    +
    + +

    Needless to say, sending a username and password over an insecure +channel is undesirable.

    + +

    If the remote server supports TLS, you can protect the plaintext +username and password by turning on TLS in the Postfix SMTP client +(see: TLS_README), and configuring the client as discussed next. + +

    Encrypted SMTP session (TLS)

    + +

    A separate parameter controls Postfix SASL mechanism policy +during a TLS-encrypted SMTP session. The default is to copy the +settings from the unencrypted session:

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_sasl_tls_security_options = $smtp_sasl_security_options
+
    +
    + +

    A more sophisticated policy allows plaintext mechanisms, but +only over a TLS-encrypted connection:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_security_options = noanonymous, noplaintext
+    smtpd_sasl_tls_security_options = noanonymous
+
    +
    + +

    Filtering server mechanism names in +the Postfix SMTP/LMTP client

    + +

    Cyrus SASL always attempts to use the most secure authentication +mechanism that the remote SMTP server offers - even if the client +side was not configured to handle it! In such cases authentication +will definitely fail.

    + +

    To prevent this, the Postfix SMTP client can filter the list +of authentication mechanism names from the remote SMTP server. Used +correctly, the filter hides unwanted mechanisms from the Cyrus SASL +library, forcing the library to choose from the mechanisms the +Postfix filter passes through.

    + +

    The following example filters out everything but the mechanisms +PLAIN and LOGIN:

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_sasl_mechanism_filter = plain, login
+
    +
    + +
    + +Note + +

    If the remote server does not offer any of the mechanisms on +the filter list, authentication will fail.

    + +
    + +

    We close this section with an example that passes every mechanism +except for GSSAPI and LOGIN:

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_sasl_mechanism_filter = !gssapi, !login, static:all
+
    +
    + +

    Building Postfix with SASL support

    + +

    As mentioned elsewhere, Postfix supports two SASL implementations: +Cyrus SASL (SMTP client and server) and Dovecot SASL (SMTP server +only). Both implementations can be built into Postfix simultaneously. +

    + + + +

    Building Dovecot SASL support

    + +

    These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

    + +

    Support for the Dovecot version 1 SASL protocol is available +in Postfix 2.3 and later. At the time of writing, only server-side +SASL support is available, so you can't use it to authenticate the +Postfix SMTP client to your network provider's server.

    + +

    Dovecot uses its own daemon process for authentication. This +keeps the Postfix build process simple, because there is no need +to link extra libraries into Postfix.

    + +

    To generate the necessary Makefiles, execute the following in +the Postfix top-level directory:

    + +
    +
    +% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS='-DUSE_SASL_AUTH \
+    -DDEF_SERVER_SASL_TYPE=\"dovecot\"'
+
    +
    + +

    After this, proceed with "make" as described in +the INSTALL document.

    + +Note + + + +

    Building Cyrus SASL support

    + +

    Building the Cyrus SASL library

    + +

    Postfix works with cyrus-sasl-1.5.x or cyrus-sasl-2.1.x, which are +available from ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/.

    + +
    + +Important + +

    If you install the Cyrus SASL libraries as per the default, you will have +to create a symlink /usr/lib/sasl -> +/usr/local/lib/sasl for version 1.5.x or +/usr/lib/sasl2 -> /usr/local/lib/sasl2 +for version 2.1.x.

    + +
    + +

    Reportedly, Microsoft Outlook (Express) requires the non-standard LOGIN +and/or NTLM authentication mechanism. To enable these authentication +mechanisms, build the Cyrus SASL libraries with:

    + +
    +
    +% ./configure --enable-login --enable-ntlm
+
    +
    + +

    Building Postfix with Cyrus SASL support

    + +

    These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

    + +

    The following assumes that the Cyrus SASL include files are in +/usr/local/include, and that the Cyrus SASL libraries are in +/usr/local/lib.

    + +

    On some systems this generates the necessary Makefile +definitions:

    + +
    + +
    Cyrus SASL version 2.1.x
    + +
    + +
    +% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib -lsasl2"
+
    + +
    + +
    Cyrus SASL version 1.5.x
    + +
    + +
    +% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include" AUXLIBS="-L/usr/local/lib -lsasl"
+
    + +
    + +
    + +

    On Solaris 2.x you need to specify run-time link information, +otherwise the ld.so run-time linker will not find the SASL shared +library:

    + +
    + +
    Cyrus SASL version 2.1.x
    + +
    + +
    +% make tidy # remove left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib \
+    -R/usr/local/lib -lsasl2"
+
    + +
    + +
    Cyrus SASL version 1.5.x
    + +
    + +
    +% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include" AUXLIBS="-L/usr/local/lib \
+    -R/usr/local/lib -lsasl"
+
    + +
    + +
    + +

    Using Cyrus SASL version 1.5.x

    + +

    Postfix supports Cyrus SASL version 1.x, but you shouldn't use +it unless you are forced to. The makers of Cyrus SASL write:

    + +
    This library is being deprecated and applications +should transition to using the SASLv2 library (source: Project Cyrus: +Downloads).
    + +

    If you still need to set it up, here's a quick rundown:

    + +

    Read the regular section on SMTP server configurations for the +Cyrus SASL framework. The differences are:

    + + +

    Credits

    + diff --git a/postfix/html/SOHO_README.html b/postfix/html/SOHO_README.html index 6d59437bc..d4458aeeb 100644 --- a/postfix/html/SOHO_README.html +++ b/postfix/html/SOHO_README.html @@ -44,11 +44,11 @@ Internet hostname @@ -214,124 +214,122 @@ whenever you change the canonical table.

    Execute the command "postmap /etc/postfix/virtual" whenever you change the virtual table.

    -

    Enabling SASL authentication in the -Postfix SMTP client

    +

    Enabling SASL authentication in the +Postfix SMTP/LMTP client

    -

    Turn on client-side SASL authentication, and specify a table -with per-host or per-destination username and password information. -The Postfix SMTP client first searches the table for an entry with -the remote SMTP server hostname; if no entry is found, then the -Postfix SMTP client searches the table for -an entry with the next-hop destination. Usually, that is the -right-hand part of an email address, but it can also be the information -that is specified with the relayhost parameter or with a transport(5) -table.

    +

    This section shows a typical scenario where the Postfix SMTP +client sends all messages via a mail gateway server that requires +SASL authentication. To make the example more readable we introduce +it in two parts. 

     /etc/postfix/main.cf:
     smtp_sasl_auth_enable = yes
-    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
-    smtp_sasl_type = cyrus
-    relayhost = [mail.myisp.net]
+    relayhost = [mail.isp.example]
     # Alternative form:
-    # relayhost = [mail.myisp.net]:submission
-
-/etc/postfix/sasl_passwd:
-    [mail.myisp.net]            username:password
-    [mail.myisp.net]:submission username:password
+    # relayhost = [mail.isp.example]:submission
+    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    -

    Notes:

    + + +
    +
    +/etc/postfix/sasl_passwd:
+    # destination                   credentials
+    [mail.isp.example]              username:password
+    # Alternative form:
+    # [mail.isp.example]:submission username:password
+
    +
    + +
    + +Important + +

    Keep the SASL client password file in /etc/postfix, +and make the file read+write only for root to protect +the username/password combinations against other users. The Postfix +SMTP client will still be able to read the SASL client passwords. +It opens the file as user root before it drops privileges, +and before entering an optional chroot jail.

    + +
    -

  • Specify dbm instead of hash if your system -uses dbm files instead of db files. To find out what -lookup tables Postfix supports, use the command "postconf -m". +

    Configuring Sender-Dependent SASL +authentication

    + +

    Postfix supports different ISP accounts for different sender +addresses (version 2.3 and later). This can be useful when one +person uses the same machine for work and for personal use, or when +people with different ISP accounts share the same Postfix server.

    -

  • Execute the command "postmap /etc/postfix/sasl_passwd" -whenever you change the sasl_passwd table.

    - - - -

    Workarounds:

    - - - -

    Supporting multiple ISP accounts -in the Postfix SMTP client

    - -

    Postfix version 2.3 supports multiple ISP accounts. This can -be useful when one person uses the same machine for work and for -personal use, or when people with different ISP accounts share the -same Postfix server. To make this possible, Postfix 2.3 supports -per-sender SASL passwords and per-sender relay hosts. In the example -below, Postfix will search the SASL password file by sender before -it searches that same file by destination. Likewise, Postfix will -search the per-sender relayhost file, and use the default relayhost -only as a final resort.

    +

    To make this possible, Postfix supports per-sender SASL passwords +and per-sender relay hosts. In the example below, the Postfix SMTP +client will search the SASL password file by sender address before +it searches that same file by destination. Likewise, the Postfix +trivial-rewrite(8) daemon will search the per-sender relayhost file, +and use the default relayhost setting only as a final +resort. 

    @@ -340,26 +338,33 @@ only as a final resort.  
    
     sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
     smtp_sasl_auth_enable = yes
     smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
-    relayhost = [mail.myisp.net]
+    relayhost = [mail.isp.example]
     # Alternative form:
-    # relayhost = [mail.myisp.net]:submission
-
-/etc/postfix/sasl_passwd:
-    # Per-sender authentication; see also /etc/postfix/sender_relay.
-    user1@example.com           username2:password2
-    user2@example.net           username2:password2
-    # Login information for the default relayhost.
-    [mail.myisp.net]            username:password
-    [mail.myisp.net]:submission username:password
-
-/etc/postfix/sender_relay:
-    # Per-sender provider; see also /etc/postfix/sasl_passwd.
-    user1@example.com           [mail.example.com]:submission
-    user2@example.net           [mail.example.net]
+    # relayhost = [mail.isp.example]:submission
    -

    Notes:

    +
    +
    +/etc/postfix/sasl_passwd:
+    # Per-sender authentication; see also /etc/postfix/sender_relay.
+    user1@example.com               username2:password2
+    user2@example.net               username2:password2
+    # Login information for the default relayhost.
+    [mail.isp.example]              username:password
+    # Alternative form:
+    # [mail.isp.example]:submission username:password
+
    +
    + +
    +
    +/etc/postfix/sender_relay:
+    # Per-sender provider; see also /etc/postfix/sasl_passwd.
+    user1@example.com               [mail.example.com]:submission
+    user2@example.net               [mail.example.net]
+
    +
    diff --git a/postfix/html/TLS_README.html b/postfix/html/TLS_README.html index fa6571940..edf38f78b 100644 --- a/postfix/html/TLS_README.html +++ b/postfix/html/TLS_README.html @@ -2237,7 +2237,7 @@ as specified by the smtp_tl parameter. This setting controls the minimum acceptable SMTP client TLS cipher grade for use with mandatory TLS encryption. The default value "medium" is suitable for most destinations with which you may -want to enforce TLS, and is beyond the reach of today's crypt-analytic +want to enforce TLS, and is beyond the reach of today's cryptanalytic methods. See smtp_tls_policy_maps for information on how to configure ciphers on a per-destination basis.

    diff --git a/postfix/html/pcre_table.5.html b/postfix/html/pcre_table.5.html index a15207d0b..004b0a152 100644 --- a/postfix/html/pcre_table.5.html +++ b/postfix/html/pcre_table.5.html @@ -80,10 +80,10 @@ PCRE_TABLE(5) PCRE_TABLE(5) cal line. Each pattern is a perl-like regular expression. The - expression delimiter can be any character, except white- - space or characters that have special meaning (tradition- - ally the forward slash is used). The regular expression - can contain whitespace. + expression delimiter can be any non-alphanumerical charac- + ter, except whitespace or characters that have special + meaning (traditionally the forward slash is used). The + regular expression can contain whitespace. By default, matching is case-insensitive, and newlines are not treated as special characters. The behavior is con- diff --git a/postfix/html/postconf.5.html b/postfix/html/postconf.5.html index db5c78f15..bcc7eca5d 100644 --- a/postfix/html/postconf.5.html +++ b/postfix/html/postconf.5.html @@ -2291,8 +2291,8 @@ domain.

    Specify a string of the form transport:nexthop, where transport is the name of a mail delivery transport defined in master.cf. -The :nexthop part is optional. For more details see the -transport(5) manual page. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent.

    @@ -2615,7 +2615,7 @@ for showq(8) queue displays.

    empty_address_default_transport_maps_lookup_key -(default: <>)
    +(default: <>)

    The sender_dependent_default_transport_maps search string that will be used instead of the null sender address.

    @@ -4930,8 +4930,8 @@ which is just the name of a service that is defined the

    Specify a string of the form transport:nexthop, where transport is the name of a mail delivery transport defined in master.cf. -The :nexthop part is optional. For more details see the -transport(5) manual page. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent.

    @@ -6592,7 +6592,7 @@ elapsed, and report whether the client triggers a PREGREET or HANGUP error, or whether the client is listed at the DNSBL sites specified with the postscreen_dnsbl_sites parameter. Take the corresponding action, or forward the connection to a real SMTP server process. -

    +
    drop
    @@ -6698,7 +6698,7 @@ parameter. Specify one of the following:

    continue
    -
    Forward the connection to a real SMTP server process.

    +
    Forward the connection to a real SMTP server process.
    drop
    @@ -6737,7 +6737,7 @@ parameter. Specify one of the following:

    elapsed. If the client is listed at the DNS blocklist domains specified with the postscreen_dnsbl_sites parameter, execute the action specified with the postscreen_dnsbl_action parameter, otherwise -forward the connection to a real SMTP server process.

    +forward the connection to a real SMTP server process.
    drop
    @@ -6802,7 +6802,7 @@ without sending data, within the time specified with the
    Continue waiting until the postscreen_greet_wait time has elapsed, and report whether the client is listed at the DNSBL sites specified with the postscreen_dnsbl_sites parameter. Do not -forward the broken connection to a real SMTP server process.

    +forward the broken connection to a real SMTP server process.
    drop
    @@ -7690,8 +7690,8 @@ the transport(5) table.

    Specify a string of the form transport:nexthop, where transport is the name of a mail delivery transport defined in master.cf. -The :nexthop part is optional. For more details see the -transport(5) manual page. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent.

    @@ -7812,10 +7812,10 @@ clients at all.

    (default: no)

    -Whether or not a local(8) recipient's home directory must exist +Require that a local(8) recipient's home directory exists before mail delivery is attempted. By default this test is disabled. It can be useful for environments that import home directories to -the mail server (NOT RECOMMENDED). +the mail server (IMPORTING HOME DIRECTORIES IS NOT RECOMMENDED).

    @@ -9886,7 +9886,7 @@ loglevel 4 is strongly discouraged.

    use with mandatory TLS encryption. The default value "medium" is suitable for most destinations with which you may want to enforce TLS, and -is beyond the reach of today's crypt-analytic methods. See +is beyond the reach of today's cryptanalytic methods. See smtp_tls_policy_maps for information on how to configure ciphers on a per-destination basis.

    @@ -9894,47 +9894,32 @@ on a per-destination basis.

    export
    -
    Enable the mainstream "EXPORT" grade or better OpenSSL -ciphers. This is always used for opportunistic encryption. It is +
    Enable "EXPORT" grade or better OpenSSL +ciphers. This is the default for opportunistic encryption. It is not recommended for mandatory encryption unless you must enforce TLS with "crippled" peers. The underlying cipherlist is specified via the tls_export_cipherlist configuration parameter, which you are strongly -encouraged to not change. The default value of tls_export_cipherlist -includes anonymous ciphers, but these are automatically filtered out if -the client is configured to verify server certificates. If you must -exclude anonymous ciphers also at the "encrypt" security level, set -"smtp_tls_mandatory_exclude_ciphers = aNULL".
    +encouraged to not change.
    low
    -
    Enable the mainstream "LOW" grade or better OpenSSL ciphers. This +
    Enable "LOW" grade or better OpenSSL ciphers. This setting is only appropriate for internal mail servers. The underlying cipherlist is specified via the tls_low_cipherlist configuration -parameter, which you are strongly encouraged to not change. The default -value of tls_low_cipherlist includes anonymous ciphers, but these are -automatically filtered out if the client is configured to verify server -certificates. If you must exclude anonymous ciphers also at the "encrypt" -security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL".
    +parameter, which you are strongly encouraged to not change.
    medium
    -
    Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers. +
    Enable "MEDIUM" grade or better OpenSSL ciphers. The underlying cipherlist is specified via the tls_medium_cipherlist configuration parameter, which you are strongly encouraged to not change. -The default value of tls_medium_cipherlist includes anonymous ciphers, -but these are automatically filtered out if the client is configured to -verify server certificates. If you must exclude anonymous ciphers also -at the "encrypt" security level, set "smtp_tls_mandatory_exclude_ciphers -= aNULL".
    +
    high
    -
    Enable only the mainstream "HIGH" grade OpenSSL ciphers. This -setting is appropriate when all mandatory TLS destinations support -some of "HIGH" grade ciphers, this is not uncommon. The underlying -cipherlist is specified via the tls_high_cipherlist configuration -parameter, which you are strongly encouraged to not change. The default -value of tls_high_cipherlist includes anonymous ciphers, but these are -automatically filtered out if the client is configured to verify server -certificates. If you must exclude anonymous ciphers also at the "encrypt" -security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL".
    +
    Enable only "HIGH" grade OpenSSL ciphers. This setting may +be appropriate when all mandatory TLS destinations (e.g. when all +mail is routed to a suitably capable relayhost) support at least one +"HIGH" grade cipher. The underlying cipherlist is specified via the +tls_high_cipherlist configuration parameter, which you are strongly +encouraged to not change.
    null
    Enable only the "NULL" OpenSSL ciphers, these provide authentication @@ -9944,12 +9929,20 @@ in TLS servers). A plausible use-case is an LMTP server listening on a UNIX-domain socket that is configured to support "NULL" ciphers. The underlying cipherlist is specified via the tls_null_cipherlist configuration parameter, which you are strongly encouraged to not -change. The default value of tls_null_cipherlist excludes anonymous -ciphers (OpenSSL 0.9.8 has NULL ciphers that offer data integrity without -encryption or authentication).
    +change. +

    The underlying cipherlists for grades other than "null" include +anonymous ciphers, but these are automatically filtered out if the +Postfix SMTP client is configured to verify server certificates. +You are very unlikely to need to take any steps to exclude anonymous +ciphers, they are excluded automatically as necessary. If you must +exclude anonymous ciphers at the "may" or "encrypt" security levels, +when the Postfix SMTP client does not need or use peer certificates, set +"smtp_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only when +TLS is enforced, set "smtp_tls_mandatory_exclude_ciphers = aNULL".

    +

    This feature is available in Postfix 2.3 and later.

    @@ -10424,7 +10417,7 @@ Examples: # Opportunistic TLS. smtp_tls_security_level = may # Postfix ≥ 2.6: -# Do not tweak opportunistic ciphers unless it is essential +# Do not tweak opportunistic ciphers or protocol unless it is essential # to do so (if a security vulnerability is found in the SSL library that # can be mitigated by disabling a particular protocol or raising the # cipher grade from "export" to "low" or "medium"). @@ -11978,7 +11971,7 @@ more of the following, separated by comma or whitespace.

    speed_adjust
    -
    Do not connect to a before-queue content filter until an entire +

    Do not connect to a before-queue content filter until an entire message has been received. This reduces the number of simultaneous before-queue content filter processes.

    @@ -12505,7 +12498,7 @@ the SASL plug-in implementation that is selected with configuration file or rendezvous point.

    This feature is available in Postfix 2.3 and later. In earlier -releases it was called smtpd_sasl_application_name.

    +releases it was called smtpd_sasl_application_name.

    @@ -13435,65 +13428,46 @@ loglevel 4 is strongly discouraged.

    smtpd_tls_mandatory_ciphers (default: medium)
    -

    The minimum TLS cipher grade that the Postfix SMTP server -will use with mandatory TLS encryption. Cipher types listed in -smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are -excluded from the base definition of the selected cipher grade. See -smtpd_tls_ciphers for cipher controls that apply to opportunistic -TLS.

    +

    The minimum TLS cipher grade that the Postfix SMTP server will +use with mandatory TLS encryption. The default grade ("medium") is +sufficiently strong that any benefit from globally restricting TLS +sessions to a more stringent grade is likely negligible, especially +given the fact that many implementations still do not offer any stronger +("high" grade) ciphers, while those that do, will always use "high" +grade ciphers. So insisting on "high" grade ciphers is generally +counter-productive. Allowing "export" or "low" ciphers is typically +not a good idea, as systems limited to just these are limited to +obsolete browsers. No known SMTP clients fail to support at least +one "medium" or "high" grade cipher.

    The following cipher grades are supported:

    export
    -
    Enable the mainstream "EXPORT" grade or better OpenSSL ciphers. +
    Enable "EXPORT" grade or stronger OpenSSL ciphers. This is the most appropriate setting for public MX hosts, and is always used with opportunistic TLS encryption. The underlying cipherlist is specified via the tls_export_cipherlist configuration parameter, -which you are strongly encouraged to not change. The default value -of tls_export_cipherlist includes anonymous ciphers, but these are -automatically filtered out if the server is configured to ask for -client certificates. If you must always exclude anonymous ciphers, -set "smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers -only when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers = -aNULL".
    +which you are strongly encouraged to not change.
    low
    -
    Enable the mainstream "LOW" grade or better OpenSSL ciphers. The +
    Enable "LOW" grade or stronger OpenSSL ciphers. The underlying cipherlist is specified via the tls_low_cipherlist configuration parameter, which you are strongly encouraged to -not change. The default value of tls_low_cipherlist includes -anonymous ciphers, but these are automatically filtered out if the -server is configured to ask for client certificates. If you must -always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers = -aNULL". To exclude anonymous ciphers only when TLS is enforced, set -"smtpd_tls_mandatory_exclude_ciphers = aNULL".
    +not change.
    medium
    -
    Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers. These -are essentially the 128-bit or stronger ciphers. This is the default -minimum strength for mandatory TLS encryption. MSAs that enforce -TLS and have clients that do not support any "MEDIUM" or "HIGH" -grade ciphers, may need to configure a weaker ("low" or "export") -minimum cipher grade. The underlying cipherlist is specified via the -tls_medium_cipherlist configuration parameter, which you are strongly -encouraged to not change. The default value of tls_medium_cipherlist -includes anonymous ciphers, but these are automatically filtered out if -the server is configured to ask for client certificates. If you must -always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers = -aNULL". To exclude anonymous ciphers only when TLS is enforced, set -"smtpd_tls_mandatory_exclude_ciphers = aNULL".
    +
    Enable "MEDIUM" grade or stronger OpenSSL ciphers. These use 128-bit +or longer symmetric bulk-encryption keys. This is the default minimum +strength for mandatory TLS encryption. The underlying cipherlist is +specified via the tls_medium_cipherlist configuration parameter, which +you are strongly encouraged to not change.
    high
    -
    Enable only the mainstream "HIGH" grade OpenSSL ciphers. The +
    Enable only "HIGH" grade OpenSSL ciphers. The underlying cipherlist is specified via the tls_high_cipherlist configuration parameter, which you are strongly encouraged to -not change. The default value of tls_high_cipherlist includes -anonymous ciphers, but these are automatically filtered out if the -server is configured to ask for client certificates. If you must -always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers = -aNULL". To exclude anonymous ciphers only when TLS is enforced, set -"smtpd_tls_mandatory_exclude_ciphers = aNULL".
    +not change.
    null
    Enable only the "NULL" OpenSSL ciphers, these provide authentication @@ -13501,12 +13475,25 @@ without encryption. This setting is only appropriate in the rare case that all clients are prepared to use NULL ciphers (not normally enabled in TLS clients). The underlying cipherlist is specified via the tls_null_cipherlist configuration parameter, which you are strongly -encouraged to not change. The default value of tls_null_cipherlist -excludes anonymous ciphers (OpenSSL 0.9.8 has NULL ciphers that offer -data integrity without encryption or authentication).
    +encouraged to not change. +

    Cipher types listed in +smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are +excluded from the base definition of the selected cipher grade. See +smtpd_tls_ciphers for cipher controls that apply to opportunistic +TLS.

    + +

    The underlying cipherlists for grades other than "null" include +anonymous ciphers, but these are automatically filtered out if the +server is configured to ask for client certificates. You are very +unlikely to need to take any steps to exclude anonymous ciphers, they +are excluded automatically as required. If you must exclude anonymous +ciphers even when Postfix does not need or use peer certificates, set +"smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only +when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers = aNULL".

    +

    This feature is available in Postfix 2.3 and later.

    @@ -15203,8 +15190,8 @@ This information can be overruled with the transport(

    Specify a string of the form transport:nexthop, where transport is the name of a mail delivery transport defined in master.cf. -The :nexthop part is optional. For more details see the -transport(5) manual page. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent.

    diff --git a/postfix/html/postqueue.1.html b/postfix/html/postqueue.1.html index fe9cbd131..a49832868 100644 --- a/postfix/html/postqueue.1.html +++ b/postfix/html/postqueue.1.html @@ -60,10 +60,8 @@ POSTQUEUE(1) POSTQUEUE(1) size, arrival time, sender, and the recipients that still need to be delivered. If mail could not be delivered upon the last attempt, the reason for - failure is shown. This mode of operation is imple- - mented by executing the postqueue(1) command. The - queue ID string is followed by an optional status - character: + failure is shown. The queue ID string is followed + by an optional status character: * The message is in the active queue, i.e. the message is selected for delivery. diff --git a/postfix/html/regexp_table.5.html b/postfix/html/regexp_table.5.html index 3261a4b90..cff60ba8a 100644 --- a/postfix/html/regexp_table.5.html +++ b/postfix/html/regexp_table.5.html @@ -85,10 +85,10 @@ REGEXP_TABLE(5) REGEXP_TABLE(5) Solaris, and in regex(7) with Linux. Other systems may use other document names. - The expression delimiter can be any character, except - whitespace or characters that have special meaning (tradi- - tionally the forward slash is used). The regular expres- - sion can contain whitespace. + The expression delimiter can be any non-alphanumerical + character, except whitespace or characters that have spe- + cial meaning (traditionally the forward slash is used). + The regular expression can contain whitespace. By default, matching is case-insensitive, and newlines are not treated as special characters. The behavior is con- diff --git a/postfix/html/smtpd.8.html b/postfix/html/smtpd.8.html index b47f92c0d..746389669 100644 --- a/postfix/html/smtpd.8.html +++ b/postfix/html/smtpd.8.html @@ -105,52 +105,54 @@ SMTPD(8) SMTPD(8) as if the local hostname were specified, instead of rejecting the address as invalid. - smtpd_command_filter (empty) - A mechanism to transform commands from remote SMTP - clients. - smtpd_reject_unlisted_sender (no) - Request that the Postfix SMTP server rejects mail - from unknown sender addresses, even when no - explicit reject_unlisted_sender access restriction + Request that the Postfix SMTP server rejects mail + from unknown sender addresses, even when no + explicit reject_unlisted_sender access restriction is specified. smtpd_sasl_exceptions_networks (empty) - What remote SMTP clients the Postfix SMTP server + What remote SMTP clients the Postfix SMTP server will not offer AUTH support to. Available in Postfix version 2.2 and later: smtpd_discard_ehlo_keyword_address_maps (empty) - Lookup tables, indexed by the remote SMTP client - address, with case insensitive lists of EHLO key- - words (pipelining, starttls, auth, etc.) that the + Lookup tables, indexed by the remote SMTP client + address, with case insensitive lists of EHLO key- + words (pipelining, starttls, auth, etc.) that the SMTP server will not send in the EHLO response to a remote SMTP client. smtpd_discard_ehlo_keywords (empty) - A case insensitive list of EHLO keywords (pipelin- - ing, starttls, auth, etc.) that the SMTP server + A case insensitive list of EHLO keywords (pipelin- + ing, starttls, auth, etc.) that the SMTP server will not send in the EHLO response to a remote SMTP client. smtpd_delay_open_until_valid_rcpt (yes) - Postpone the start of an SMTP mail transaction + Postpone the start of an SMTP mail transaction until a valid RCPT TO command is received. Available in Postfix version 2.3 and later: smtpd_tls_always_issue_session_ids (yes) - Force the Postfix SMTP server to issue a TLS ses- - sion id, even when TLS session caching is turned + Force the Postfix SMTP server to issue a TLS ses- + sion id, even when TLS session caching is turned off (smtpd_tls_session_cache_database is empty). Available in Postfix version 2.6 and later: tcp_windowsize (0) - An optional workaround for routers that break TCP + An optional workaround for routers that break TCP window scaling. + Available in Postfix version 2.7 and later: + + smtpd_command_filter (empty) + A mechanism to transform commands from remote SMTP + clients. + ADDRESS REWRITING CONTROLS See the ADDRESS_REWRITING_README document for a detailed discussion of Postfix address rewriting. diff --git a/postfix/html/verify.8.html b/postfix/html/verify.8.html index 7fa70cdf2..3b6396dfc 100644 --- a/postfix/html/verify.8.html +++ b/postfix/html/verify.8.html @@ -40,7 +40,7 @@ VERIFY(8) VERIFY(8) query address Look up the status and text for the specified - address. If the status is unknown, a probe is sent + address. If the status is unknown, a probe is sent and an "in progress" status is returned. SECURITY @@ -50,9 +50,9 @@ VERIFY(8) VERIFY(8) low privilege. The address verification server can be coerced to store - unlimited amounts of garbage. Limiting the cache size - trades one problem (disk space exhaustion) for another one - (poor response time to client requests). + unlimited amounts of garbage. Limiting the cache expiry + time trades one problem (disk space exhaustion) for + another one (poor response time to client requests). With Postfix version 2.5 and later, the verify(8) server no longer uses root privileges when opening the @@ -66,12 +66,12 @@ VERIFY(8) VERIFY(8) Problems and transactions are logged to syslogd(8). BUGS - The address verification service is suitable only for - sites that handle a low mail volume. Verification probes - add additional traffic to the mail queue and perform - poorly under high load. Servers may blacklist sites that - probe excessively, or that probe excessively for non-exis- - tent recipient addresses. + Address verification probe messages add additional traffic + to the mail queue. Recipient verification may cause an + increased load on down-stream servers in the case of a + dictionary attack or a flood of backscatter bounces. + Sender address verification may cause your site to be + blacklisted by some providers. If the persistent database ever gets corrupted then the world comes to an end and human intervention is needed. @@ -79,7 +79,7 @@ VERIFY(8) VERIFY(8) CONFIGURATION PARAMETERS Changes to main.cf are not picked up automatically, as - verify(8) processes are persistent. Use the command "post- + verify(8) processes are long-lived. Use the command "post- fix reload" after a configuration change. The text below provides only a parameter summary. See diff --git a/postfix/man/man1/postqueue.1 b/postfix/man/man1/postqueue.1 index 83df565c5..c0db9145f 100644 --- a/postfix/man/man1/postqueue.1 +++ b/postfix/man/man1/postqueue.1 @@ -54,8 +54,7 @@ by contacting the Postfix \fBshowq\fR(8) daemon. Each queue entry shows the queue file ID, message size, arrival time, sender, and the recipients that still need to be delivered. If mail could not be delivered upon the last attempt, -the reason for failure is shown. This mode of operation is implemented -by executing the \fBpostqueue\fR(1) command. The queue ID string +the reason for failure is shown. The queue ID string is followed by an optional status character: .RS .IP \fB*\fR diff --git a/postfix/man/man5/pcre_table.5 b/postfix/man/man5/pcre_table.5 index 71bc0ad27..9399450be 100644 --- a/postfix/man/man5/pcre_table.5 +++ b/postfix/man/man5/pcre_table.5 @@ -76,7 +76,8 @@ A logical line starts with non-whitespace text. A line that starts with whitespace continues a logical line. .PP Each pattern is a perl-like regular expression. The expression -delimiter can be any character, except whitespace or characters +delimiter can be any non-alphanumerical character, except +whitespace or characters that have special meaning (traditionally the forward slash is used). The regular expression can contain whitespace. diff --git a/postfix/man/man5/postconf.5 b/postfix/man/man5/postconf.5 index 3ffbf62d8..d43365561 100644 --- a/postfix/man/man5/postconf.5 +++ b/postfix/man/man5/postconf.5 @@ -1315,8 +1315,8 @@ domain. .PP Specify a string of the form \fItransport:nexthop\fR, where \fItransport\fR is the name of a mail delivery transport defined in master.cf. -The \fI:nexthop\fR part is optional. For more details see the -\fBtransport\fR(5) manual page. +The \fI:nexthop\fR destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent. .PP Example: .PP @@ -2718,8 +2718,8 @@ which is just the name of a service that is defined the master.cf file. .PP Specify a string of the form \fItransport:nexthop\fR, where \fItransport\fR is the name of a mail delivery transport defined in master.cf. -The \fI:nexthop\fR part is optional. For more details see the -\fBtransport\fR(5) manual page. +The \fI:nexthop\fR destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent. .PP Beware: if you override the default local delivery agent then you need to review the LOCAL_RECIPIENT_README document, otherwise the @@ -4331,8 +4331,8 @@ the \fBtransport\fR(5) table. .PP Specify a string of the form \fItransport:nexthop\fR, where \fItransport\fR is the name of a mail delivery transport defined in master.cf. -The \fI:nexthop\fR part is optional. For more details see the -\fBtransport\fR(5) manual page. +The \fI:nexthop\fR destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent. .PP See also the relay domains address class in the ADDRESS_CLASS_README file. @@ -4423,10 +4423,10 @@ remote_header_rewrite_domain = .ft R .in -4 .SH require_home_directory (default: no) -Whether or not a \fBlocal\fR(8) recipient's home directory must exist +Require that a \fBlocal\fR(8) recipient's home directory exists before mail delivery is attempted. By default this test is disabled. It can be useful for environments that import home directories to -the mail server (NOT RECOMMENDED). +the mail server (IMPORTING HOME DIRECTORIES IS NOT RECOMMENDED). .SH resolve_dequoted_address (default: yes) Resolve a recipient address safely instead of correctly, by looking inside quotes. @@ -5800,50 +5800,34 @@ The minimum TLS cipher grade that the Postfix SMTP client will use with mandatory TLS encryption. The default value "medium" is suitable for most destinations with which you may want to enforce TLS, and -is beyond the reach of today's crypt-analytic methods. See +is beyond the reach of today's cryptanalytic methods. See smtp_tls_policy_maps for information on how to configure ciphers on a per-destination basis. .PP The following cipher grades are supported: .IP "\fBexport\fR" -Enable the mainstream "EXPORT" grade or better OpenSSL -ciphers. This is always used for opportunistic encryption. It is +Enable "EXPORT" grade or better OpenSSL +ciphers. This is the default for opportunistic encryption. It is not recommended for mandatory encryption unless you must enforce TLS with "crippled" peers. The underlying cipherlist is specified via the tls_export_cipherlist configuration parameter, which you are strongly -encouraged to not change. The default value of tls_export_cipherlist -includes anonymous ciphers, but these are automatically filtered out if -the client is configured to verify server certificates. If you must -exclude anonymous ciphers also at the "encrypt" security level, set -"smtp_tls_mandatory_exclude_ciphers = aNULL". +encouraged to not change. .IP "\fBlow\fR" -Enable the mainstream "LOW" grade or better OpenSSL ciphers. This +Enable "LOW" grade or better OpenSSL ciphers. This setting is only appropriate for internal mail servers. The underlying cipherlist is specified via the tls_low_cipherlist configuration -parameter, which you are strongly encouraged to not change. The default -value of tls_low_cipherlist includes anonymous ciphers, but these are -automatically filtered out if the client is configured to verify server -certificates. If you must exclude anonymous ciphers also at the "encrypt" -security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL". +parameter, which you are strongly encouraged to not change. .IP "\fBmedium\fR" -Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers. +Enable "MEDIUM" grade or better OpenSSL ciphers. The underlying cipherlist is specified via the tls_medium_cipherlist configuration parameter, which you are strongly encouraged to not change. -The default value of tls_medium_cipherlist includes anonymous ciphers, -but these are automatically filtered out if the client is configured to -verify server certificates. If you must exclude anonymous ciphers also -at the "encrypt" security level, set "smtp_tls_mandatory_exclude_ciphers -= aNULL". .IP "\fBhigh\fR" -Enable only the mainstream "HIGH" grade OpenSSL ciphers. This -setting is appropriate when all mandatory TLS destinations support -some of "HIGH" grade ciphers, this is not uncommon. The underlying -cipherlist is specified via the tls_high_cipherlist configuration -parameter, which you are strongly encouraged to not change. The default -value of tls_high_cipherlist includes anonymous ciphers, but these are -automatically filtered out if the client is configured to verify server -certificates. If you must exclude anonymous ciphers also at the "encrypt" -security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL". +Enable only "HIGH" grade OpenSSL ciphers. This setting may +be appropriate when all mandatory TLS destinations (e.g. when all +mail is routed to a suitably capable relayhost) support at least one +"HIGH" grade cipher. The underlying cipherlist is specified via the +tls_high_cipherlist configuration parameter, which you are strongly +encouraged to not change. .IP "\fBnull\fR" Enable only the "NULL" OpenSSL ciphers, these provide authentication without encryption. This setting is only appropriate in the rare case @@ -5852,9 +5836,17 @@ in TLS servers). A plausible use-case is an LMTP server listening on a UNIX-domain socket that is configured to support "NULL" ciphers. The underlying cipherlist is specified via the tls_null_cipherlist configuration parameter, which you are strongly encouraged to not -change. The default value of tls_null_cipherlist excludes anonymous -ciphers (OpenSSL 0.9.8 has NULL ciphers that offer data integrity without -encryption or authentication). +change. +.PP +The underlying cipherlists for grades other than "null" include +anonymous ciphers, but these are automatically filtered out if the +Postfix SMTP client is configured to verify server certificates. +You are very unlikely to need to take any steps to exclude anonymous +ciphers, they are excluded automatically as necessary. If you must +exclude anonymous ciphers at the "may" or "encrypt" security levels, +when the Postfix SMTP client does not need or use peer certificates, set +"smtp_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only when +TLS is enforced, set "smtp_tls_mandatory_exclude_ciphers = aNULL". .PP This feature is available in Postfix 2.3 and later. .SH smtp_tls_mandatory_exclude_ciphers (default: empty) @@ -6285,7 +6277,7 @@ smtp_tls_security_level = none # Opportunistic TLS. smtp_tls_security_level = may # Postfix >= 2.6: -# Do not tweak opportunistic ciphers unless it is essential +# Do not tweak opportunistic ciphers or protocol unless it is essential # to do so (if a security vulnerability is found in the SSL library that # can be mitigated by disabling a particular protocol or raising the # cipher grade from "export" to "low" or "medium"). @@ -8465,69 +8457,63 @@ loglevel 4 is strongly discouraged. .PP This feature is available in Postfix 2.2 and later. .SH smtpd_tls_mandatory_ciphers (default: medium) -The minimum TLS cipher grade that the Postfix SMTP server -will use with mandatory TLS encryption. Cipher types listed in -smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are -excluded from the base definition of the selected cipher grade. See -smtpd_tls_ciphers for cipher controls that apply to opportunistic -TLS. +The minimum TLS cipher grade that the Postfix SMTP server will +use with mandatory TLS encryption. The default grade ("medium") is +sufficiently strong that any benefit from globally restricting TLS +sessions to a more stringent grade is likely negligible, especially +given the fact that many implementations still do not offer any stronger +("high" grade) ciphers, while those that do, will always use "high" +grade ciphers. So insisting on "high" grade ciphers is generally +counter-productive. Allowing "export" or "low" ciphers is typically +not a good idea, as systems limited to just these are limited to +obsolete browsers. No known SMTP clients fail to support at least +one "medium" or "high" grade cipher. .PP The following cipher grades are supported: .IP "\fBexport\fR" -Enable the mainstream "EXPORT" grade or better OpenSSL ciphers. +Enable "EXPORT" grade or stronger OpenSSL ciphers. This is the most appropriate setting for public MX hosts, and is always used with opportunistic TLS encryption. The underlying cipherlist is specified via the tls_export_cipherlist configuration parameter, -which you are strongly encouraged to not change. The default value -of tls_export_cipherlist includes anonymous ciphers, but these are -automatically filtered out if the server is configured to ask for -client certificates. If you must always exclude anonymous ciphers, -set "smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers -only when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers = -aNULL". +which you are strongly encouraged to not change. .IP "\fBlow\fR" -Enable the mainstream "LOW" grade or better OpenSSL ciphers. The +Enable "LOW" grade or stronger OpenSSL ciphers. The underlying cipherlist is specified via the tls_low_cipherlist configuration parameter, which you are strongly encouraged to -not change. The default value of tls_low_cipherlist includes -anonymous ciphers, but these are automatically filtered out if the -server is configured to ask for client certificates. If you must -always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers = -aNULL". To exclude anonymous ciphers only when TLS is enforced, set -"smtpd_tls_mandatory_exclude_ciphers = aNULL". +not change. .IP "\fBmedium\fR" -Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers. These -are essentially the 128-bit or stronger ciphers. This is the default -minimum strength for mandatory TLS encryption. MSAs that enforce -TLS and have clients that do not support any "MEDIUM" or "HIGH" -grade ciphers, may need to configure a weaker ("low" or "export") -minimum cipher grade. The underlying cipherlist is specified via the -tls_medium_cipherlist configuration parameter, which you are strongly -encouraged to not change. The default value of tls_medium_cipherlist -includes anonymous ciphers, but these are automatically filtered out if -the server is configured to ask for client certificates. If you must -always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers = -aNULL". To exclude anonymous ciphers only when TLS is enforced, set -"smtpd_tls_mandatory_exclude_ciphers = aNULL". +Enable "MEDIUM" grade or stronger OpenSSL ciphers. These use 128-bit +or longer symmetric bulk-encryption keys. This is the default minimum +strength for mandatory TLS encryption. The underlying cipherlist is +specified via the tls_medium_cipherlist configuration parameter, which +you are strongly encouraged to not change. .IP "\fBhigh\fR" -Enable only the mainstream "HIGH" grade OpenSSL ciphers. The +Enable only "HIGH" grade OpenSSL ciphers. The underlying cipherlist is specified via the tls_high_cipherlist configuration parameter, which you are strongly encouraged to -not change. The default value of tls_high_cipherlist includes -anonymous ciphers, but these are automatically filtered out if the -server is configured to ask for client certificates. If you must -always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers = -aNULL". To exclude anonymous ciphers only when TLS is enforced, set -"smtpd_tls_mandatory_exclude_ciphers = aNULL". +not change. .IP "\fBnull\fR" Enable only the "NULL" OpenSSL ciphers, these provide authentication without encryption. This setting is only appropriate in the rare case that all clients are prepared to use NULL ciphers (not normally enabled in TLS clients). The underlying cipherlist is specified via the tls_null_cipherlist configuration parameter, which you are strongly -encouraged to not change. The default value of tls_null_cipherlist -excludes anonymous ciphers (OpenSSL 0.9.8 has NULL ciphers that offer -data integrity without encryption or authentication). +encouraged to not change. +.PP +Cipher types listed in +smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are +excluded from the base definition of the selected cipher grade. See +smtpd_tls_ciphers for cipher controls that apply to opportunistic +TLS. +.PP +The underlying cipherlists for grades other than "null" include +anonymous ciphers, but these are automatically filtered out if the +server is configured to ask for client certificates. You are very +unlikely to need to take any steps to exclude anonymous ciphers, they +are excluded automatically as required. If you must exclude anonymous +ciphers even when Postfix does not need or use peer certificates, set +"smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only +when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers = aNULL". .PP This feature is available in Postfix 2.3 and later. .SH smtpd_tls_mandatory_exclude_ciphers (default: empty) @@ -9521,8 +9507,8 @@ This information can be overruled with the \fBtransport\fR(5) table. .PP Specify a string of the form \fItransport:nexthop\fR, where \fItransport\fR is the name of a mail delivery transport defined in master.cf. -The \fI:nexthop\fR part is optional. For more details see the -\fBtransport\fR(5) manual page. +The \fI:nexthop\fR destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent. .PP This feature is available in Postfix 2.0 and later. .SH virtual_uid_maps (default: empty) diff --git a/postfix/man/man5/regexp_table.5 b/postfix/man/man5/regexp_table.5 index d67d710a8..991088d33 100644 --- a/postfix/man/man5/regexp_table.5 +++ b/postfix/man/man5/regexp_table.5 @@ -80,7 +80,8 @@ delimiters. The regular expression syntax is documented in \fBre_format\fR(7) with 4.4BSD, in \fBregex\fR(5) with Solaris, and in \fBregex\fR(7) with Linux. Other systems may use other document names. -The expression delimiter can be any character, except whitespace +The expression delimiter can be any non-alphanumerical +character, except whitespace or characters that have special meaning (traditionally the forward slash is used). The regular expression can contain whitespace. diff --git a/postfix/man/man8/smtpd.8 b/postfix/man/man8/smtpd.8 index e8970b1f9..9c812e944 100644 --- a/postfix/man/man8/smtpd.8 +++ b/postfix/man/man8/smtpd.8 @@ -108,8 +108,6 @@ Available in Postfix version 2.1 and later: Resolve an address that ends in the "@" null domain as if the local hostname were specified, instead of rejecting the address as invalid. -.IP "\fBsmtpd_command_filter (empty)\fR" -A mechanism to transform commands from remote SMTP clients. .IP "\fBsmtpd_reject_unlisted_sender (no)\fR" Request that the Postfix SMTP server rejects mail from unknown sender addresses, even when no explicit reject_unlisted_sender @@ -141,6 +139,10 @@ is empty). Available in Postfix version 2.6 and later: .IP "\fBtcp_windowsize (0)\fR" An optional workaround for routers that break TCP window scaling. +.PP +Available in Postfix version 2.7 and later: +.IP "\fBsmtpd_command_filter (empty)\fR" +A mechanism to transform commands from remote SMTP clients. .SH "ADDRESS REWRITING CONTROLS" .na .nf diff --git a/postfix/man/man8/verify.8 b/postfix/man/man8/verify.8 index f6646a7c3..8806b5911 100644 --- a/postfix/man/man8/verify.8 +++ b/postfix/man/man8/verify.8 @@ -36,7 +36,8 @@ The \fBverify\fR(8) server implements the following requests: .IP "\fBupdate\fI address status text\fR" Update the status and text of the specified address. .IP "\fBquery\fI address\fR" -Look up the \fIstatus\fR and \fItext\fR for the specified address. +Look up the \fIstatus\fR and \fItext\fR for the specified +\fIaddress\fR. If the status is unknown, a probe is sent and an "in progress" status is returned. .SH "SECURITY" @@ -49,7 +50,8 @@ not talk to the network, and it does not talk to local users. The verify server can run chrooted at fixed low privilege. The address verification server can be coerced to store -unlimited amounts of garbage. Limiting the cache size +unlimited amounts of garbage. Limiting the cache expiry +time trades one problem (disk space exhaustion) for another one (poor response time to client requests). @@ -67,11 +69,13 @@ Problems and transactions are logged to \fBsyslogd\fR(8). .SH BUGS .ad .fi -The address verification service is suitable only for sites that -handle a low mail volume. Verification probes add additional -traffic to the mail queue and perform poorly under high load. -Servers may blacklist sites that probe excessively, or that -probe excessively for non-existent recipient addresses. +Address verification probe messages add additional traffic +to the mail queue. +Recipient verification may cause an increased load on +down-stream servers in the case of a dictionary attack or +a flood of backscatter bounces. +Sender address verification may cause your site to be +blacklisted by some providers. If the persistent database ever gets corrupted then the world comes to an end and human intervention is needed. This violates @@ -83,7 +87,7 @@ a basic Postfix principle. .fi Changes to \fBmain.cf\fR are not picked up automatically, as \fBverify\fR(8) -processes are persistent. Use the command "\fBpostfix reload\fR" after +processes are long-lived. Use the command "\fBpostfix reload\fR" after a configuration change. The text below provides only a parameter summary. See diff --git a/postfix/mantools/make_soho_readme b/postfix/mantools/make_soho_readme index 3d018dbb2..abeddde74 100755 --- a/postfix/mantools/make_soho_readme +++ b/postfix/mantools/make_soho_readme @@ -47,11 +47,11 @@ Internet hostname

    @@ -72,8 +72,9 @@ sed -n '/^

    /,${ p }' STANDARD_CONFIGURATION_README.html -sed -n '/^

    /,${ - /^

    /h2>/g p }' SASL_README.html diff --git a/postfix/mantools/postlink b/postfix/mantools/postlink index 583a66cb8..de775e6e1 100755 --- a/postfix/mantools/postlink +++ b/postfix/mantools/postlink @@ -523,6 +523,7 @@ while (<>) { s;\bsmtpd_reject_unlisted_recip[-]*\n* *[]*ient\b;$&;g; s;\bsmtpd_reject_unlisted_sender\b;$&;g; s;\bsmtpd_restriction_classes\b;$&;g; + s;\bsmtpd_sasl_application_name\b;$&;g; s;\bsmtpd_sasl_path\b;$&;g; s;\bcyrus_sasl_config_path\b;$&;g; s;\bsmtpd_sasl_auth_enable\b;$&;g; diff --git a/postfix/proto/ADDRESS_VERIFICATION_README.html b/postfix/proto/ADDRESS_VERIFICATION_README.html index e8f50df60..4507b8bce 100644 --- a/postfix/proto/ADDRESS_VERIFICATION_README.html +++ b/postfix/proto/ADDRESS_VERIFICATION_README.html @@ -19,12 +19,11 @@

    WARNING

    -

    The sender/recipient address verification feature described in this -document is suitable only for low-traffic sites. It performs poorly -under high load; excessive sender address verification activity may -even cause your site to be blacklisted by some -providers. See the "Limitations" section -below for details.

    +

    Recipient address verification may cause an increased load on +down-stream servers in the case of a dictionary attack or a flood +of backscatter bounces. Sender address verification may cause your +site to be blacklisted by some providers. See also the "Limitations" section below for more.

    What Postfix address verification can do for you

    @@ -35,7 +34,7 @@ until the address has been verified to be deliverable.

    The technique has obvious uses to reject junk mail with an unreplyable sender address.

    -

    The technique may also be useful to block mail for undeliverable +

    The technique is also useful to block mail for undeliverable recipients, for example on a mail relay host that does not have a list of all the valid recipient addresses. This prevents undeliverable junk mail from entering the queue, so that Postfix doesn't have to @@ -86,74 +85,96 @@ always discarded.

    - +
    - + + - + - + - + + + + + + + + + + + + + + - - + - + + + + + - + - + - + - + - - - - - + - + - + - + - + - + - + - + - - - + @@ -181,7 +202,8 @@ details.

    MTA for that address, without actually delivering mail to it. If the nearest MTA accepts the address, then Postfix assumes that the address is deliverable. In reality, mail for a remote address can -bounce AFTER the nearest MTA accepts the recipient address.

    +bounce AFTER the nearest MTA accepts the recipient address, or AFTER +the nearest MTA accepts the message content.

  • Some sites may blacklist you when you are probing them too often (a probe is an SMTP session that does not deliver mail), @@ -200,21 +222,25 @@ mail routing and for possible limitations when you have to do this.

  • Postfix assumes that an address is undeliverable when the nearest MTA for the address rejects the probe, regardless of the reason for rejection (client rejected, HELO rejected, MAIL FROM -rejected, etc.). Thus, Postfix rejects mail when the sender's MTA -rejects mail from your machine. This is a good thing.

    +rejected, etc.). Thus, Postfix rejects an address when the nearest +MTA for that address rejects mail from your machine for any reason. +This is not a limitation, but it is mentioned here just in case +people believe that it is a limitation.

    -

  • Unfortunately, some major sites such as YAHOO do not reject +

  • Unfortunately, some sites do not reject unknown addresses in reply to the RCPT TO command, but report a delivery failure in response to end of DATA after a message is transferred. Postfix address verification does not work with such sites.

    -

  • By default, Postfix probe messages have "double-bounce@$myorigin" -as the sender address (with Postfix versions before 2.5, the default +

  • By default, Postfix probe messages have a sender address +"double-bounce@$myorigin" (with Postfix versions before 2.5, the +default is "postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does not reject mail for this address.

    -

    You can change this into the null address ("address_verify_sender +

    You can change the probe sender address into the null address +("address_verify_sender ="). This is UNSAFE because address probes will fail with mis-configured sites that reject MAIL FROM: <>, while probes from "postmaster@$myorigin" would succeed.

    @@ -223,7 +249,7 @@ probes from "postmaster@$myorigin" would succeed.

    Recipient address verification

    -

    As mentioned earlier, recipient address verification may be +

    As mentioned earlier, recipient address verification is useful to block mail for undeliverable recipients on a mail relay host that does not have a list of all valid recipient addresses. This can help to prevent the mail queue from filling up with @@ -237,9 +263,11 @@ However, recipient address verification probes can increase the load on down-stream MTAs when you're being flooded by backscatter bounces, or when some spammer is mounting a dictionary attack.

    -

    By default, address verification results are not saved. To avoid -probing the same address repeatedly, you can store the result in a -persistent database as described later.

    +

    By default, address verification results are saved in a persistent database (Postfix version 2.7 and +later; with earlier versions, specify the database in main.cf as +described later). The persistent database helps to avoid probing +the same address repeatedly. 

    @@ -299,11 +327,13 @@ in forged email.  
    
     # Postfix 2.6 and later.
     # unverified_sender_defer_code = 250
 
+    # Default setting for Postfix 2.7 and later.
     # Note 1: Be sure to read the "Caching" section below!
     # Note 2: Avoid hash files here. Use btree instead.
     address_verify_map = btree:/var/lib/postfix/verify
  
 /etc/postfix/sender_access:
+    # Don't do this when you handle lots of email.
     aol.com     reject_unverified_sender
     hotmail.com reject_unverified_sender
     bigfoot.com reject_unverified_sender
@@ -344,6 +374,7 @@ you can see what mail would be blocked: 
    
     # Postfix 2.6 and later.
     # unverified_sender_reject_reason = Address verification failed
 
+    # Default setting for Postfix 2.7 and later.
     # Note 1: Be sure to read the "Caching" section below!
     # Note 2: Avoid hash files here. Use btree instead.
     address_verify_map = btree:/var/lib/postfix/verify
@@ -403,7 +434,8 @@ sender address verification probe fails with some temporary error.
 
    Address verification database
    
 
 
     To improve performance, the Postfix verify(8) daemon can save
-address verification results to a persistent database.  The
+address verification results to a persistent database. This is
+enabled by default with Postfix 2.7 and later.  The
 address_verify_map (NOTE: singular) configuration parameter specifies
 persistent storage for sender or recipient address verification
 results.  If you specify an empty value, all address verification
diff --git a/postfix/proto/OVERVIEW.html b/postfix/proto/OVERVIEW.html
index ac8bbd476..062d460ab 100644
--- a/postfix/proto/OVERVIEW.html
+++ b/postfix/proto/OVERVIEW.html
@@ -651,31 +651,126 @@ align="center" bgcolor="#f0f0ff"> smtp
     session
     cache 
 
 
  •  
     The verify(8) server verifies that a sender or recipient
 address is deliverable before the smtpd(8) server accepts it.  The
-verify(8) server injects probe messages into the Postfix queue and
-processes status updates from delivery agents and/or queue manager.
+verify(8) server queries a cache with address verification results.
+If a result is not found, the verify(8) server injects a probe
+message into the Postfix queue and processes the status update from
+a delivery agent or queue manager.
 This process is described in the ADDRESS_VERIFICATION_README
 document.  The verify(8) service is available with Postfix version
 2.1 and later.
    • Internet + +   -> -> probe
    + message     		Postfix
    SMTP
    server         		-> + <-> + + Postfix
    mail
    queue
    Internet -> + + Postfix
    SMTP
    server         		<-> + Postfix
    verify
    server         		<-> -
    Address
    - verification
    database
    |
    + v
    <- +     probe
    + status     		|
    - probe
    messages
    v     		<- + + Postfix
    delivery
    agents     		^
    delivery
    - status
    |     		-> + Local
    -> Remote
    +   + ^
    |
    v
    - Postfix
    queue
     
    ->
    - Postfix
    delivery
    agents     		  + Address
    verification
    database
    - - - + + + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Network -> smtpd(8) <-> verify(8) --> cleanup(8) - -> -qmgr(8)
    Postfix
    queue     		-> Delivery
    agents
    +   + -> probe
    message     		-> + Postfix
    mail
    queue
    -\
    \
    -    		 <- <- - |
    v
    - /
    /
    +
    Network -> + smtpd(8) <-> verify(8) +
    |
    v
    <- + probe
    + status     		+ <- Postfix
    delivery
    agents +     		-> + Local
    -> Network
    +   + ^
    |
    v
     
      Address
    + verification
    cache
    + +

  • The postscreen(8) server can be put "in front" of Postfix +smtpd(8) processes. Its purpose is to accept connections from the +network and to decide what SMTP clients are allowed to talk to +Postfix. According to the 2008 MessageLabs annual report, 81% of +all email was spam, and 90% of that was sent by botnets. While +postscreen(8) keeps the zombies away, more smtpd(8) processes remain +available for legitimate clients.

    + +

    The postscreen(8) server is still evolving, and is likely to +undergo changes that break compatibility with earlier versions. +For this reason the postscreen(8) server is not installed with the +stable Postfix release.

    + + + + + + + + + + + + + + + + + + + + + + + +
    zombie
    \
    zombie - + - smtpd(8)
    \ /
    other +--- +postscreen(8)
    / \
    other + - + - smtpd(8)
    /
    zombie
    diff --git a/postfix/proto/SASL_README.html b/postfix/proto/SASL_README.html index f62692288..3c6e558e9 100644 --- a/postfix/proto/SASL_README.html +++ b/postfix/proto/SASL_README.html @@ -1,8 +1,6 @@ - - Postfix SASL Howto @@ -17,231 +15,1107 @@
    -

    WARNING

    +

    Warning

    People who go to the trouble of installing Postfix may have the expectation that Postfix is more secure than some other mailers. -The Cyrus SASL library is a lot of code. With this, Postfix becomes -as secure as other mail systems that use the Cyrus SASL library. -Dovecot provides an alternative that may be worth considering. -

    +The Cyrus SASL library contains a lot of code. With this, Postfix +becomes as secure as other mail systems that use the Cyrus SASL +library. Dovecot provides an alternative that may be worth +considering.

    -

    How Postfix uses SASL authentication information

    +

    How Postfix uses SASL authentication

    -

    Postfix SASL support (RFC 4954, formerly RFC 2554) can be used -to authenticate -remote SMTP clients to the Postfix SMTP server, and to authenticate -the Postfix SMTP client to a remote SMTP server.

    +

    When an SMTP client connects to an SMTP server, the server needs +to decide whether that client is authorized to send mail to remote +destinations, or whether the client can send mail only to the +destinations that the server itself is responsible for. Usually, +the SMTP server will allow mail to remote destinations only if the +client's IP address is in the "same network" as the server's IP +address.

    -

    When receiving mail, the Postfix SMTP server logs the client-provided -username, -authentication method, and sender address to the maillog file, and -optionally grants mail access via the permit_sasl_authenticated -UCE restriction.

    +

    Sometimes the SMTP client and server are in different networks, +but the client still needs "same network" privileges. To address +this problem, Postfix supports SASL authentication (RFC 4954, +formerly RFC 2554). With this a remote SMTP client can authenticate +to the Postfix SMTP server, and the Postfix SMTP client can +authenticate to a remote SMTP server. Once the client is authenticated +the server can give it "same network" privileges.

    -

    When sending mail, the Postfix SMTP client can look up the -remote SMTP server hostname or -destination domain (the address right-hand part) in a SASL password -table, and if a username/password is found, it will use that username -and password to authenticate to the remote SMTP server. And as of -version 2.3, -Postfix can be configured to search its SASL password table by the -sender email address.

    +

    Postfix does not implement SASL itself, but instead uses existing +implementations as building blocks. This means that some SASL-related +configuration will involve files that belong to Postfix, while other +configuration will involve files that belong to the specific SASL +implementation that Postfix will use. This document covers both the +Postfix and non-Postfix configuration.

    -

    This document covers the following topics:

    +

    You can read more about the following topics:

    -

    What SASL implementations are supported

    +

    Configuring SASL authentication in the +Postfix SMTP server

    -

    This document describes Postfix with the following SASL -implementations:

    +

    As mentioned earlier, SASL is implemented separately from +Postfix. For this reason, configuring SASL authentication in the +Postfix SMTP server involves two different steps:

      -

    • Cyrus SASL version 1 (client and server).

      +

    • Configuring the SASL implementation to offer a list of +mechanisms that are suitable for SASL authentication and, depending +on the SASL implementation used, configuring authentication backends +that verify the remote SMTP client's authentication data against +the system password file or some other database.

      • -

    • Cyrus SASL version 2 (client and server).

      - -

    • Dovecot protocol version 1 (server only, Postfix version -2.3 and later)

      +

    • Configuring the Postfix SMTP server to enable SASL +authentication, and to authorize clients to relay mail or to control +what envelope sender addresses the client may use.

    -

    Postfix version 2.3 introduces a plug-in mechanism that provides -support for multiple SASL implementations. To find out what -implementations are built into Postfix, use the following commands: +

    Successful authentication in the Postfix SMTP server requires +a functional SASL framework. Configuring SASL should therefore +always be the first step.

    + +

    You can read more about the following topics:

    + + + + +

    Which SASL Implementations are supported?

    + +

    Currently the Postfix SMTP server supports the Cyrus SASL and +Dovecot SASL implementations.

    + +
    + +Note + +

    Before Postfix version 2.3, Postfix had support only for Cyrus +SASL. Current Postfix versions have a plug-in architecture that +can support multiple SASL implementations.

    + +
    + +

    To find out what SASL implementations are compiled into Postfix, +use the following commands:

    + +
    +
    +% postconf -a (SASL support in the SMTP server)
+% postconf -A (SASL support in the SMTP+LMTP client)
+
    +
    + +

    These commands are available only with Postfix version 2.3 and +later.

    + +

    Configuring Dovecot SASL

    + +

    Dovecot is a POP/IMAP server that must be configured to +authenticate POP/IMAP clients. When the Postfix SMTP server uses +Dovecot SASL, it also reuses this configuration. Consult the Dovecot documentation for how +to configure and operate the Dovecot authentication server.

    + +

    Postfix to Dovecot SASL communication

    + +

    Communication between the Postfix SMTP server +and Dovecot SASL happens via a UNIX-domain socket. The socket +pathname and the list of mechanisms offered to Postfix need to be +specified on the Dovecot server side in dovecot.conf. +

    + +

    The following example assumes that the Postfix queue is under +/var/spool/postfix/.

    + +
    +
    + 1 /etc/dovecot.conf:
+ 2     auth default {
+ 3       mechanisms = plain login
+ 4         passdb pam {
+ 5         }
+ 6         userdb passwd {
+ 7         }
+ 8         socket listen {
+ 9         client {
+10           path = /var/spool/postfix/private/auth
+11           mode = 0660
+12           user = postfix
+13           group = postfix
+14         }
+15       }
+16     }
+
    +
    + +

    Line 3 provides plain and login as +mechanisms for the Postfix SMTP server, line 10 places the Dovecot +SASL socket in /var/spool/postfix/private/auth, and +lines 11-13 limit read+write permissions to user and group +postfix only.

    + +

    Proceed with the section "Enabling SASL authentication and +authorization in the Postfix SMTP server" to turn on and use +SASL in the Postfix SMTP server.

    + +

    Configuring Cyrus SASL

    + +

    The Cyrus SASL framework was supports a wide variety of +applications. Different applications may require different +configurations. As a consequence each application may have its own +configuration file.

    + +

    The first step configuring Cyrus SASL is to determine name and +location of a configuration file that describes how the Postfix +SMTP server will use the SASL framework.

    + +

    Cyrus SASL configuration file name

    + +

    The name of the configuration file (default: smtpd.conf) +is configurable. It is a concatenation from a value that the Postfix +SMTP server sends to the Cyrus SASL library, and the suffix +.conf, added by Cyrus SASL.

    + +

    The value sent by Postfix is the name of the server component +that will use Cyrus SASL. It defaults to smtpd and +is configured with one of the following variables:

    + +
    +
    +/etc/postfix/main.cf:
+    # Postfix 2.3 and later
+    smtpd_sasl_path = smtpd
+
+    # Postfix < 2.3
+    smtpd_sasl_application_name = smtpd
+
    +
    + +

    Cyrus SASL configuration file +location

    + +

    The location where Cyrus SASL searches for the named file depends +on the Cyrus SASL version and the OS/distribution used.

    + +

    You can read more about the following topics:

    + +
      + +

    • Cyrus SASL version 2.x searches for the configuration file +in /usr/lib/sasl2/.

      • + +

    • Cyrus SASL version 2.1.22 and newer additionally search +in /etc/sasl2/.

      • + +

    • Some Postfix distributions are modified and look for the +Cyrus SASL configuration file in /etc/postfix/sasl/, +/var/lib/sasl2/ etc. See the distribution-specific +documentation to determine the expected location.

      • + +
    + +
    + +Note + +

    Cyrus SASL searches /usr/lib/sasl2/ first. If it +finds the specified configuration file there, it will not examine +other locations.

    + +
    + +

    Postfix to Cyrus SASL communication

    + +

    As the Postfix SMTP server is linked with the Cyrus SASL library +libsasl, communication between Postfix and Cyrus SASL +takes place by calling functions in the SASL library.

    + +

    The SASL library may use an external password verification +service, or an internal plugin to connect to authentication backends +and verify the SMTP client's authentication data against the system +password file or other databases.

    + +

    The following table shows typical combinations discussed in +this document:

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    authentication backendpassword verification service / plugin
    /etc/shadowsaslauthd
    PAMsaslauthd
    IMAP serversaslauthd
    sasldbsasldb
    MySQL, PostgreSQL, SQLitesql
    LDAPldapdb
    + +
    + +
    + +Note + +

    Read the Cyrus SASL documentation for other backends it can +use.

    + +
    + +

    saslauthd - Cyrus SASL password verification service

    + +

    Communication between the Postfix SMTP server (read: Cyrus SASL's +libsasl) and the saslauthd server takes +place over a UNIX-domain socket.

    + +

    saslauthd usually establishes the UNIX domain +socket in /var/run/saslauthd/ and waits for authentication +requests. The Postfix SMTP server must have read+execute permission +to this directory or authentication attempts will fail.

    + +
    + +Important + +

    Some distributions require the user postfix to be +member of a special group e.g. sasl, otherwise it +will not be able to access the saslauthd socket +directory.

    + +
    + +

    The following example configures the Cyrus SASL library to +contact saslauthd as its password verification service: 

    -% postconf -a (SASL support in the SMTP server)
-% postconf -A (SASL support in the SMTP+LMTP client)
+/etc/sasl2/smtpd.conf:
+    pwcheck_method: saslauthd
+    mech_list: PLAIN LOGIN
    -

    Needless to say, these commands are not available in earlier -Postfix versions.

    +
    -

    Building Postfix with Dovecot SASL -support

    +Important -

    These instructions assume that you build Postfix from source -code as described in the INSTALL document. Some modification may -be required if you build Postfix from a vendor-specific source -package.

    +

    Do not specify any other mechanisms in mech_list +than PLAIN or LOGIN when using +saslauthd! It can only handle these two mechanisms, +and authentication will fail if clients are allowed to choose other +mechanisms.

    -

    Support for the Dovecot version 1 SASL protocol is available -in Postfix 2.3 and later. At the time -of writing, only server-side SASL support is available, so you can't -use it to authenticate to your network provider's server. Dovecot -uses its own daemon process for authentication. This keeps the -Postfix build process simple, because there is no need to link extra -libraries into Postfix.

    +
    -

    To generate the necessary Makefiles, execute the following -in the Postfix top-level directory:

    +
    + +Important + +

    Plaintext mechanisms (PLAIN, LOGIN) +send credentials unencrypted. This information should be protected +by an additional security layer such as a TLS-encrypted SMTP session +(see: TLS_README).

    + +
    + +

    Additionally the saslauthd server itself must be +configured. It must be told which authentication backend to turn +to for password verification. The backend is choosen as a command +line option when saslauthd is started and will be shown +in the following examples.

    + +
    + +Note + +

    Some distributions use a configuration file to provide saslauthd +command line options to set e.g. the authentication backend. Typical +locations are /etc/sysconfig/saslauthd or +/etc/default/saslauthd.

    + +
    + +

    Using saslauthd with /etc/shadow

    + +

    Access to the /etc/shadow system password file +requires root privileges. The Postfix SMTP server +(and in consequence libsasl linked to the server) runs +with the least privilege possible. Direct access to +/etc/shadow would not be possible without breaking the +Postfix security architecture.

    + +

    The saslauthd socket builds a safe bridge. Postfix, +running as limited user postfix, can access the +UNIX-domain socket that saslauthd receives commands +on; saslauthd, running as privileged user root, +has the privileges required to access the shadow file.

    + +

    The saslauthd server verifies passwords against the +authentication backend /etc/shadow if started like this: 

    -% make makefiles CCARGS='-DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\"'
+% saslauthd -a shadow
    -

    After this, proceed with "make" as described in the -INSTALL document.

    +

    See section "Testing saslauthd +authentication" for test instructions.

    -

    Notes:

    +

    Using saslauthd with PAM

    -
      - -

    • The "-DDEF_SERVER_SASL_TYPE" stuff is not necessary; it just -makes Postfix configuration a little more convenient because you -don't have to specify the SASL plug-in type in the Postfix main.cf -file.

      - -

    • If you also want support for LDAP or TLS, you will have to merge -their CCARGS and AUXLIBS into the above command line.

      - -
    - -

    Building the Cyrus SASL library

    - -

    Postfix appears to work with cyrus-sasl-1.5.x or cyrus-sasl-2.1.x, -which are available from:

    +

    Cyrus SASL can use the PAM framework to authenticate credentials. +saslauthd uses the PAM framework when started like +this: 

    -ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/
+% saslauthd -a pam
    -

    IMPORTANT: if you install the Cyrus SASL libraries as per the -default, you will have to symlink /usr/lib/sasl -> /usr/local/lib/sasl -for version 1.5.x or /usr/lib/sasl2 -> /usr/local/lib/sasl2 for -version 2.1.x.

    +
    -

    Reportedly, Microsoft Outlook (Express) requires the -non-standard LOGIN authentication method. To enable this -authentication method, specify ``./configure --enable-login''.

    +Note -

    Building Postfix with Cyrus SASL support

    +

    PAM configuration for the Postfix SMTP server is usually given +in /etc/pam.d/smtp and is beyond the scope of this +document.

    -

    These instructions assume that you build Postfix from source -code as described in the INSTALL document. Some modification may -be required if you build Postfix from a vendor-specific source -package.

    +
    -

    The following -assumes that the Cyrus SASL include files are in /usr/local/include, -and that the Cyrus SASL libraries are in /usr/local/lib.

    +

    See section "Testing saslauthd +authentication" for test instructions.

    -

    On some systems this generates the necessary Makefile definitions: -

    +

    Using saslauthd with an IMAP server

    + +

    saslauthd can verify the SMTP client credentials +by using them to log into an IMAP server. If the login succeeds, +SASL authentication also succeeds. saslauthd contacts +an IMAP server when started like this:

    + +
    +
    +% saslauthd -a rimap -O imap.example.com
+
    +
    + +
    + +Note + +

    The option "-O imap.example.com" specifies the +IMAP server saslauthd should contact when it verifies +credentials.

    + +
    + +
    + +Important + +

    saslauthd sends IMAP login information unencrypted. +Any IMAP session leaving the local host should be protected by an +additional security layer such as an SSL tunnel.

    + +
    + +

    See section "Testing saslauthd +authentication" for test instructions.

    + +

    Testing saslauthd authentication

    + +

    Cyrus SASL provides the testsaslauthd utility to +test saslauthd authentication. The username and password +are given as command line arguments. The example shows the response +when authentication is successful:

    + +
    +
    +% testsaslauthd -u username -p password
+0: OK "Success."
+
    +
    + +
    + +Note + +

    Sometimes the testsaslauthd program is not distributed +with a the Cyrus SASL main package. In that case, it may be +distributed with -devel, -dev or -debug packages.

    + +
    + +

    Specify an additional "-s smtp" if saslauthd +was configured to contact the PAM authentication framework and an +additional "-f /path/to/socketdir/mux" if +saslauthd establishes the UNIX-domain socket in a +non-default location.

    + +

    If authentication succeeds, proceed with the section "Enabling SASL authentication and authorization +in the Postfix SMTP server".

    + +

    Cyrus SASL Plugins - auxiliary property +plugins

    + +

    Cyrus SASL uses a plugin infrastructure (called auxprop) +to expand libsasl's capabilities. Currently Cyrus +SASL sources provide three authentication plugins.

    + +
    -
    (for Cyrus SASL version 1.5.x): -
    -
    -% make tidy # if you have left-over files from a previous build
-% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
-    -I/usr/local/include" AUXLIBS="-L/usr/local/lib -lsasl"
-
    +
    sasldb
    -
    (for Cyrus SASL version 2.1.x): -
    -
    -% make tidy # if you have left-over files from a previous build
-% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
-    -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib -lsasl2"
-
    +

    Accounts are stored stored in a Cyrus SASL Berkeley DB +database

    + +
    sql
    + +

    Accounts are stored in a SQL database

    + +
    ldapdb
    + +

    Accounts are stored stored in an LDAP database

    -

    On Solaris 2.x you need to specify run-time link information, -otherwise ld.so will not find the SASL shared library:

    +
    + +
    + +Important + +

    These three plugins support shared-secret mechanisms i.e. +CRAM-MD5, DIGEST-MD5 and NTLM. These mechanisms send credentials +encrypted but their verification process requires the password to +be available in plaintext. Consequently passwords cannot (!) be +stored in encrypted form.

    + +
    + +

    The sasldb plugin

    + +

    The sasldb auxprop plugin authenticates credentials stored in a Berkeley +DB database. The database schema is specific to Cyrus SASL. The +database is usually located at /etc/sasldb2.

    + +
    + +Note + +

    The sasldb2 file contains passwords in +plaintext, and should have read+write access only to user +postfix or a group that postfix is member +of.

    + +
    + +

    The saslpasswd2 command-line utility creates +and maintains the database:

    + +
    +
    +% saslpasswd2 -c -u example.com username
+Password:
+Again (for verification):
+
    +
    + +

    This command creates an account +username@example.com.

    + +
    + +Important + +

    users must specify username@example.com +as login name, not username.

    + +
    + +

    Run the following command to reuse the Postfix mydomain +parameter value as the login domain:

    + +
    +
    +% saslpasswd2 -c -u `postconf -h mydomain` username
+Password:
+Again (for verification):
+
    +
    + +
    + +Note + +

    Run saslpasswd2 without any options for further +help on how to use the command.

    + +
    + +

    The sasldblistusers2 command lists all existing +users in the sasldb database:

    + +
    +
    +% sasldblistusers2
+username1@example.com: password1
+username2@example.com: password2
+
    +
    + +

    Configure libsasl to use sasldb with the following instructions:

    + +
    +
    +/etc/sasl2/smtpd.conf:
+    pwcheck_method: auxprop
+    auxprop_plugin: sasldb
+    mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
+
    +
    + +
    + +Note + +

    In the above example adjust mech_list to the +mechanisms that are applicable for your environment.

    + +
    + +

    The sql plugin

    + +

    The sql auxprop plugin is a generic SQL plugin. It provides +access to credentials stored in a MySQL, a PostgreSQL or a SQLite +database.

    + +
    + +Note + +

    The shared-secret mechanisms (CRAM-MD5, etc.) require that the +SASL client passwords are stored as plaintext.

    + +
    + +
    + +Tip + + + +

    Use "saslauthd > pam > (pam database module)" to +verify encrypted passwords in an SQL database.

    + +
    + +

    The following example configures libsasl to use the sql plugin and connects +it to a PostgreSQL server:

    + +
    +
    +/etc/sasl2/smtpd.conf:
+    pwcheck_method: auxprop
+    auxprop_plugin: sql
+    mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
+    sql_engine: pgsql
+    sql_hostnames: 127.0.0.1, 192.0.2.1 sql_user: username
+    sql_passwd: secret
+    sql_database: dbname
+    sql_select: SELECT password FROM users WHERE user = '%u'@'%r'
+
    +
    + +
    + +Note + +

    Set appropriate permissions if smtpd.conf contains +a password. The file should be readable by the postfix +user.

    + +
    + +
    + +Note + +

    In the above example, adjust mech_list to the +mechanisms that are applicable for your environment.

    + +
    + +

    The sql plugin has the following configuration options:

    + +
    -
    (for Cyrus SASL version 1.5.x): -
    -
    -% make tidy # if you have left-over files from a previous build
-% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
-    -I/usr/local/include" AUXLIBS="-L/usr/local/lib \
-    -R/usr/local/lib -lsasl"
-
    +
    sql_engine
    -
    (for Cyrus SASL version 2.1.x):
    -
    -% make tidy # if you have left-over files from a previous build
-% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
-    -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib \
-    -R/usr/local/lib -lsasl2"
-
    + +

    Specify mysql to connect to a MySQL server, +pgsql for a PostgreSQL server or sqlite +for an SQLite database

    + +
    + +
    sql_hostnames
    + +
    + +

    Specify one or more servers (hostname or hostname:port) separated +by commas.

    + +
    + +Note + +

    With MySQL servers, specify localhost to connect +over a UNIX-domain socket, and specify 127.0.0.1 to +connect over a TCP socket.

    + +
    + +
    + +
    sql_user
    + +
    + +

    The login name to gain access to the database.

    + +
    + +
    sql_passwd
    + +
    + +

    The password to gain access to the database.

    + +
    + +
    sql_database
    + +
    + +

    The name of the database to connect to.

    + +
    + +
    sql_select
    + +
    + +

    The SELECT statement that should retrieve the plaintext password +from a database table.

    + +
    + +Important + +

    Do not enclose the statement in quotes! Use single quotes to +escape macros!

    + +
    + +
    -

    Enabling SASL authentication in the Postfix -SMTP server

    +
    -

    In order to enable SASL support in the Postfix SMTP server:

    +

    The sql plugin provides macros to build sql_select +statements. They will be replaced with arguments sent from the client. The +following macros are available:

    + +
    + +
    + +
    %u
    + +
    + +

    The name of the user whose properties are being selected.

    + +
    + +
    %p
    + +
    + +

    The name of the property being selected. While this could technically be +anything, Cyrus SASL will try userPassword and cmusaslsecretMECHNAME (where +MECHNAME is the name of a SASL mechanism).

    + +
    + +
    %r
    + +
    + +

    The name of the realm to which the user belongs. This could be +the KERBEROS realm, the fully-qualified domain name of the computer +the SASL application is running on, or the domain after the "@" in a +username.

    + +
    + +
    + +
    + +

    The ldapdb plugin

    + +

    The ldapdb auxprop plugin provides access to credentials stored +in an OpenLDAP LDAP server. It is the only plugin that implements +proxy authorization.

    + +

    Proxy authorization in this context means: The ldapdb plugin +must SASL authenticate with the OpenLDAP server. The server then +decides if the ldapdb plugin should be authorized to read the +authenticating user's password. Once the ldapdb plugin has gone +through proxy authorization it may proceed and authenticate the +remote SMTP client's credentials.

    + +

    In a nutshell: Configuring ldapdb means authentication and +authorization must be configured twice - once in the Postfix SMTP +server to authenticate and authorize the remote SMTP client, and +once in the OpenLDAP slapd server to authenticate and +authorize the ldapdb plugin.

    + +

    This example configures libsasl to use the ldapdb plugin and +the plugin to connect to an OpenLDAP server:

    + +
    +
    +/etc/sasl2/smtpd.conf:
+    pwcheck_method: auxprop
+    auxprop_plugin: ldapdb
+    mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5
+    ldapdb_uri: ldap://localhost
+    ldapdb_id: proxyuser
+    ldapdb_pw: password
+    ldapdb_mech: DIGEST-MD5
+
    +
    + +
    + +Important + +

    Set appropriate permissions if smtpd.conf contains a +password. The file should be readable by the postfix +user.

    + +
    + +
    + +Note + +

    The shared-secret mechanisms (CRAM-MD5, etc.) require that the +SASL client passwords are stored as plaintext.

    + +
    + +

    The following is a summary of applicable smtpd.conf +file entries:

    + +
    + +
    + +
    auxprop_plugin
    + +

    Specify ldapdb to enable the plugin.

    + +
    ldapdb_uri
    + +

    Specify either ldapi:// for to connect over +a UNIX-domain socket, ldap:// for an unencrypted TCP +connection or ldaps:// for an encrypted TCP connection. +

    + +
    ldapdb_id
    + +

    The login name to authenticate the ldapdb plugin to the +LDAP server (proxy authorization).

    + +
    ldapdb_pw
    + +

    The password (in plaintext) to authenticate the ldapdb +plugin to the LDAP server (proxy authorization).

    + +
    ldapdb_mech
    + +

    The mechanism to authenticate the ldapdb plugin to the +OpenLDAP slapd server.

    + +
    + +Note + +

    Specify a mechanism here that is supported by the OpenLDAP slapd +server.

    + +
    + +
    + +
    ldapdb_rc (optional)
    + +

    The path to a file containing individual configuration +options for the ldapdb LDAP client (libldap). This allows to specify +a TLS client certificate which in turn can be used to use the SASL +EXTERNAL mechanism.

    + +
    + +Note + +

    This mechanism supports authentication over an encrypted transport +layer, which is recommended if the plugin must connect to an OpenLDAP +server on a remote machine.

    + +
    + +
    + +
    ldapdb_starttls (optional)
    + +

    The TLS policy for connecting to the LDAP server. Specify +either try or demand. If the option is +try the plugin will attempt to establish a TLS-encrypted +connection with the LDAP server, and will fallback to an unencrypted +connection if TLS fails. If the policy is demand and +a TLS-encrypted connection cannot be established, the connection +fails immediately.

    + +
    + +
    + +

    When the ldapdb plugin connects to the OpenLDAP server and +successfully authenticates, the OpenLDAP server decides if the +plugin user is authorized to read SASL account information.

    + +

    The following configuration gives an example of authorization configuration +in the OpenLDAP slapd server:

    + +
    +
    +/etc/openldap/slapd.conf:
+    authz-regexp
+    uid=(.*),cn=.*,cn=auth
+    ldap:///dc=example,dc=com??sub?cn=$1
+    authz-policy to
+
    +
    + +

    Here, the authz-regexp option serves for authentication +of the ldapdb user. It maps its login name to a DN in the LDAP +directory tree where slapd can look up the SASL account +information. The authz-policy options defines the +authentication policy. In this case it grants authentication +privileges "to" the ldapdb plugin.

    + +

    The last configuration step is to tell the OpenLDAP slapd +server where ldapdb may search for usernames matching the one given +by the mail client. The example below adds an additional attribute +ldapdb user object (here: authzTo because the authz-policy +is "to") and configures the scope where the login name +"proxyuser" may search:

    + +
    +
    +dn: cn=proxyuser,dc=example,dc=com
+changetype: modify
+add: authzTo
+authzTo: dn.regex:uniqueIdentifier=(.*),ou=people,dc=example,dc=com
+
    +
    + +

    Use the ldapmodify or ldapadd command +to add the above attribute.

    + +
    + +Note + +

    Read the chapter "Using SASL" in the OpenLDAP Admin Guide +for more detailed instructions to set up SASL authentication in +OpenLDAP.

    + +
    + +

    Enabling SASL authentication and +authorization in the Postfix SMTP server

    + +

    By default the Postfix SMTP server uses the Cyrus SASL +implementation. If the Dovecot SASL implementation should be used, +specify an smtpd_sasl_type value of dovecot +instead of cyrus:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_type = dovecot
+
    +
    + +

    Additionally set the path where the Postfix SMTP server can +find the Dovecot SASL socket:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_path = private/auth
+
    +
    + +
    + +Note + +

    This example uses a pathname relative to the Postfix queue +directory, so that it will work whether or not the Postfix SMTP +server runs chrooted.

    + +
    + +

    Enabling SASL authentication +in the Postfix SMTP server

    + +

    Regardless of the SASL implementation type, enabling SMTP +authentication in the Postfix SMTP server always requires seting +the smtpd_sasl_auth_enable option: 

    @@ -250,38 +1124,32 @@ SMTP server

    • -

    In order to allow mail relaying by authenticated remote SMTP -clients:

    +

    After a "postfix reload", SMTP clients will see the additional +capability AUTH in an SMTP session, followed by a list of +authentication mechanisms the server supports: 

    -/etc/postfix/main.cf:
-    smtpd_recipient_restrictions = 
-        permit_mynetworks 
-        permit_sasl_authenticated 
-        reject_unauth_destination
+% telnet server.example.com 25
+...
+220 server.example.com ESMTP Postfix
+EHLO client.example.com
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+...
    -

    To report SASL login names in Received: message headers -(Postfix version 2.3 and later):

    +

    However not all clients recognize the AUTH capability as defined +by the SASL authentication RFC. Some historical implementations expect the +server to send an "=" as separator between the AUTH +verb and the list of mechanisms that follows it.

    -
    -
    -/etc/postfix/main.cf:
-    smtpd_sasl_authenticated_header = yes
-
    -
    - -

    Note: the SASL login names will be shared with the entire world. -

    - -

    Older Microsoft SMTP client software implements a non-standard -version of the AUTH protocol syntax, and expects that the SMTP -server replies to EHLO with "250 AUTH=mechanism-list" instead of -"250 AUTH mechanism-list". To accommodate such clients (in addition -to conformant -clients) use the following:

    +

    The broken_sasl_auth_clients configuration option +lets Postfix repeat the AUTH statement in a form that these broken +clients understand: 

    @@ -290,454 +1158,507 @@ clients) use the following:
    -

    Dovecot SASL configuration for the -Postfix SMTP server

    +
    -

    Dovecot SASL support is available in Postfix 2.3 and later. On -the Postfix side you need to specify the location of the -Dovecot authentication daemon socket. We use a pathname relative -to the Postfix queue directory, so that it will work whether or not -the Postfix SMTP server runs chrooted:

    +Note + +

    Enable this option for Outlook up to and including version 2003 +and Outlook Express up to version 6. This option does not hurt other +clients.

    + +
    + +

    After "postfix reload", the Postfix SMTP server will propagate +the AUTH capability twice - once for compliant and once for broken +clients:

    + +
    +
    +% telnet server.example.com 25
+...
+EHLO client.example.com
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+250-AUTH=DIGEST-MD5 PLAIN CRAM-MD5
+...
+
    +
    + +

    Postfix SMTP Server +Authentication Policy

    + +

    The Postfix SMTP server provides a way to specify the properties +of SASL mechanisms that can be made available to the remote SMTP +client.

    + +

    Unencrypted SMTP session

    + +

    The default policy is to allow any mechanism in the Postfix SMTP server +except for those based on anonymous authentication: 

     /etc/postfix/main.cf:
-    smtpd_sasl_type = dovecot
-    smtpd_sasl_path = private/auth
+    # Specify a list of properties separated by comma or whitespace
+    smtpd_sasl_security_options = noanonymous
    -

    On the Dovecot side you also need to specify the Dovecot -authentication daemon socket. In this case we specify an -absolute pathname. In the example we assume that the -Postfix queue is under /var/spool/postfix/.

    -
    -
    -/some/where/dovecot.conf:
-    auth default {
-      mechanisms = plain login
-      passdb pam {
-      }
-      userdb passwd {
-      }
-      socket listen {
-        client {
-          path = /var/spool/postfix/private/auth
-          mode = 0660
-          user = postfix
-          group = postfix
-        }
-      }
-    }
-
    + +Important + +

    Always set at least the noanonymous option. +Otherwise, the Postfix SMTP server can give strangers the same +authorization as a properly-authenticated client.

    +
    -

    See the Dovecot documentation for how to configure and operate -the Dovecot authentication server.

    +

    Postfix can enforce the following policies on SASL authentication +mechanisms:

    -

    Cyrus SASL configuration for the Postfix -SMTP server

    +
    -

    You need to configure how the Cyrus SASL library should -authenticate a remote SMTP client's username and password. These -settings must -be stored in a separate configuration file.

    +
    -

    The name of the configuration file (default: smtpd.conf) will -be constructed from a value that the Postfix SMTP server sends to -the Cyrus SASL -library, which adds the suffix .conf. The value is configured using -one of the following variables:

    +
    noanonymous
    + +

    Don't use mechanisms that permit anonymous authentication. +

    + +
    noplaintext
    + +

    Don't use mechanisms that transmit unencrypted username +and password information.

    + +
    nodictionary
    + +

    Don't use mechanisms that are vulnerable to dictionary +attacks.

    + +
    + +
    forward_secrecy
    + +

    Use only mechanisms that support forward secrecy (Dovecot +SASL only).

    + +
    + +
    mutual_auth
    + +

    Use only mechanisms that authenticate both the client and +the server to each other.

    + +
    + +
    + +

    Encrypted SMTP session (TLS)

    + +

    A separate parameter controls Postfix SASL mechanism policy +during a TLS-encrypted SMTP session. The default is to copy the +settings from the unencrypted session: 

     /etc/postfix/main.cf:
-    # Postfix 2.3 and later
-    smtpd_sasl_path = smtpd
-    # Postfix < 2.3
-    smtpd_sasl_application_name = smtpd
+    smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
    -

    Cyrus SASL searches for the configuration file in /usr/local/lib/sasl/ -(Cyrus SASL version 1.5.5) or /usr/local/lib/sasl2/ (Cyrus SASL -version 2.1.x).

    +

    A more sophisticated policy allows plaintext mechanisms, but +only over a TLS-encrypted connection:

    -

    Note: some Postfix distributions are modified and look for -the smtpd.conf file in /etc/postfix/sasl.

    +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_security_options = noanonymous, noplaintext
+    smtpd_sasl_tls_security_options = noanonymous
+
    +
    -

    Note: some Cyrus SASL distributions look for the smtpd.conf -file in /etc/sasl2.

    +

    To offer SASL authentication only after a TLS-encrypted session has been +established specify this:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_tls_auth_only = yes
+
    +
    + +

    Enabling SASL authorization in the Postfix +SMTP server

    + +

    After the client has authenticated with SASL, the Postfix SMTP +server decides what the remote SMTP client will be authorized +for. Examples of possible SMTP clients authorizations are:

    -

    IMPORTANT: pwcheck establishes a UNIX domain socket in /var/pwcheck -and waits for authentication requests. The Postfix SMTP server must have -read+execute permission to this directory or authentication attempts -will fail.

    +

    These permissions are not enabled by default.

    -

    The pwcheck daemon is contained in the cyrus-sasl source tarball.

    +

    Mail relay authorization

    -
    (Cyrus SASL version 1.5.26) -
    -
    -/usr/local/lib/sasl/smtpd.conf:
-    pwcheck_method: saslauthd
-
    - -
    (Cyrus SASL version 2.1.x) -
    -
    -/usr/local/lib/sasl2/smtpd.conf:
-    pwcheck_method: saslauthd
-    mech_list: PLAIN LOGIN
-
    - - - -

    The saslauthd daemon is also contained in the cyrus-sasl source -tarball. It is more flexible than the pwcheck daemon, in that it -can authenticate against PAM and various other sources. To use PAM, -start saslauthd with "-a pam".

    - -

    IMPORTANT: saslauthd usually establishes a UNIX domain socket -in /var/run/saslauthd and waits for authentication requests. The Postfix -SMTP server must have read+execute permission to this directory or -authentication attempts will fail.

    - -

    Note: The directory where saslauthd puts the socket is configurable. -See the command-line option "-m /path/to/socket" in the saslauthd ---help listing.

    - -

  • To authenticate against Cyrus SASL's own password database:

    - -
    -
    (Cyrus SASL version 1.5.x) -
    -
    -/usr/local/lib/sasl/smtpd.conf:
-    pwcheck_method: sasldb
-
    - -
    (Cyrus SASL version 2.1.x) -
    -
    -/usr/local/lib/sasl2/smtpd.conf:
-    pwcheck_method: auxprop
-    auxprop_plugin: sasldb
-    mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5
-
    - -
    - -

    This will use the Cyrus SASL password file (default: /etc/sasldb in -version 1.5.x, or /etc/sasldb2 in version 2.1.x), which is maintained -with the saslpasswd or saslpasswd2 command (part of the Cyrus SASL -software). On some poorly-supported systems the saslpasswd command needs -to be run multiple times before it stops complaining. The Postfix SMTP -server needs read access to the sasldb file - you may have to play games -with group access permissions. With the OTP authentication mechanism, -the Postfix SMTP server also needs WRITE access to /etc/sasldb2 or -/etc/sasldb -(or the back end SQL database, if used).

    - -

    IMPORTANT: To get sasldb running, make sure that you set the SASL -domain (realm) to a fully qualified domain name.

    - -

    EXAMPLE:

    - -
    -
    (Cyrus SASL version 1.5.x) -
    -
    -% saslpasswd -c -u `postconf -h myhostname` exampleuser
-
    - -
    (Cyrus SASL version 2.1.x) -
    -
    -% saslpasswd2 -c -u `postconf -h myhostname` exampleuser
-
    - -
    - -

    You can find out SASL's idea about the realms of the users -in sasldb with sasldblistusers (Cyrus SASL version 1.5.x) or -sasldblistusers2 (Cyrus SASL version 2.1.x).

    - -

    On the Postfix side, you can have only one realm per smtpd(8) -instance, and only the users belonging to that realm would be able to -authenticate. The Postfix variable smtpd_sasl_local_domain controls the -realm used by smtpd(8):

    +

    The permit_sasl_authenticated restriction allows +SASL-authenticated SMTP clients to send mail to remote destinations. +Add it to the list of smtpd_recipient_restrictions as +follows: 

     /etc/postfix/main.cf:
-    smtpd_sasl_local_domain = $myhostname
+    smtpd_recipient_restrictions =
+    ...
+    permit_mynetworks
+    permit_sasl_authenticated
+    reject_unauth_destination
+    ...
    - +

    Envelope sender address authorization

    -

    IMPORTANT: The Cyrus SASL password verification services pwcheck -and saslauthd can only support the plaintext mechanisms PLAIN or -LOGIN. However, the Cyrus SASL library doesn't know this, and will -happily advertise other authentication mechanisms that the SASL -library implements, such as DIGEST-MD5. As a result, if a remote SMTP -client chooses any mechanism other than PLAIN or LOGIN while pwcheck -or saslauthd are used, authentication will fail. Thus you may need -to limit the list of mechanisms advertised by the Postfix SMTP -server.

    +

    By default an SMTP client may specify any envelope sender address +in the MAIL FROM command. That is because the Postfix SMTP server +only knows the remte SMTP client hostname and IP address, but not +the user who controls the remote SMTP client.

    -
      - -

    • With older Cyrus SASL versions you remove the corresponding -library files from the SASL plug-in directory (and again whenever -the system is updated).

      - -

    • With Cyrus SASL version 2.1.x or later the mech_list variable -can specify a list of authentication mechanisms that Cyrus SASL may -offer:

      +

      This changes the moment an SMTP client uses SASL authentication. +Now, the Postfix SMTP server knows who the sender is. Given a table +of envelope sender addresses and SASL login names, the Postfix SMTP +server can decide if the SASL authenticated client is allowed to +use a particular envelope sender address: 

      -/usr/local/lib/sasl2/smtpd.conf:
-    mech_list: plain login
+/etc/postfix/main.cf:
+    smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders
+
+    smtpd_recipient_restrictions =
+        ...
+        reject_sender_login_mismatch
+        permit_sasl_authenticated
+        permit_mynetworks
+        reject_unauth_destination
+        ...
      -
    - -

    For the same reasons you might want to limit the list of plugins -used for authentication.

    - -
      - -

    • With Cyrus SASL version 1.5.x your only choice is to -delete the corresponding library files from the SASL plug-in -directory.

      - -

    • With SASL version 2.1.x:

      +

      The controlled_envelope_senders table specifies +the binding between the sender envelope addresses and its their +SASL login names: 

      -/usr/local/lib/sasl2/smtpd.conf:
-    pwcheck_method: auxprop
-    auxprop_plugin: sql
+/etc/postfix/controlled_envelope_senders
+    # envelope sender           owners (SASL login names)
+    john@example.com            john@example.com
+    helpdesk@example.com        john@example.com, mary@example.com
+    postmaster                  admin@example.com
+    @example.net                barney, fred, john@example.com, mary@example.com
      -
    +

    With this, the reject_sender_login_mismatch +restriction above will reject the sender address in the MAIL FROM +command if smtpd_sender_login_maps does not specify +the SMTP client's login name as an owner of that address.

    -

    To run software chrooted with SASL support is an interesting -exercise. It probably is not worth the trouble.

    +

    See also reject_authenticated_sender_login_mismatch and +reject_unauthenticated_sender_login_mismatch for additional +control over the SASL login name and the envelope sender.

    -

    Testing SASL authentication in the Postfix -SMTP server

    +

    Additional SMTP Server SASL options

    -

    To test the server side, connect (for example, with telnet) to the -Postfix SMTP server port and you should -be able to have a conversation as shown below. Information sent by the -client (that is, you) is shown in bold font.

    +

    Postfix provides a wide range of SASL authentication configuration +options. The next section lists a few that are discussed frequently. +See postconf(5) for a complete list.

    + +

    Default authentication domain

    + +

    Postfix can append a domain name (or any other string) to a +SASL login name that does not have a domain part, e.g. "john" +instead of "john@example.com": 

    -$ telnet server.example.com 25
-. . .
+/etc/postfix/main.cf:
+    smtpd_sasl_local_domain = example.com
+
    +
    + +

    This is useful as a default setting and safety net for misconfigured +clients, or during a migration to an authentication method/backend +that requires an authentication REALM or domain name, before all +SMTP clients are configured to send such information.

    + +

    Hiding SASL authentication from clients or +networks

    + +

    Some clients insist on using SASL authentication if it is offered, even +when they are not configured to send credentials - and therefore +they will always fail and disconnect.

    + +

    Postfix can hide the AUTH capability from these clients/networks:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_exceptions_networks = !192.0.2.171/32, 192.0.2.0/24
+
    +
    + +

    Adding the SASL login name to mail headers

    + +

    To report SASL login names in Received: message headers (Postfix +version 2.3 and later):

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_authenticated_header = yes
+
    +
    + +
    + +Note + +

    The SASL login names will be shared with the entire world.

    + +
    + +

    Testing SASL authentication in the Postfix SMTP Server

    + +

    To test the server side, connect (for example, with +telnet) to the Postfix SMTP server port and you should +be able to have a conversation as shown below. Information sent by +the client (that is, you) is shown in bold font.

    + +
    +
    +% telnet server.example.com 25
+...
 220 server.example.com ESMTP Postfix
-EHLO client.example.com
+EHLO client.example.com
 250-server.example.com
 250-PIPELINING
 250-SIZE 10240000
 250-ETRN
 250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
 250 8BITMIME
-AUTH PLAIN AHRlc3QAdGVzdHBhc3M=
+AUTH PLAIN AHRlc3QAdGVzdHBhc3M=
 235 Authentication successful
    -

    Instead of AHRlc3QAdGVzdHBhc3M=, specify the base64 encoded -form of \0username\0password (the \0 is a null byte). The -example above is for a user named `test' with password `testpass'. -

    - -

    In order to generate base64 encoded authentication information -you can use one of the following commands:

    - +

    Instead of AHRlc3QAdGVzdHBhc3M=, specify the +base64-encoded form of \0username\0password (the \0 +is a null byte). The example above is for a user named `test' +with password `testpass'.

    -
    -% printf '\0username\0password' | mmencode 
-
    -
    -
    -
    -% perl -MMIME::Base64 -e \
-    'print encode_base64("\0username\0password");'
-
    -
    +Caution -

    The mmencode command is part of the metamail software. -MIME::Base64 is available from http://www.cpan.org/.

    - -

    Caution: when posting logs of the SASL negotiations to public -lists, +

    When posting logs of the SASL negotiations to public lists, please keep in mind that username/password information is trivial to recover from the base64-encoded form.

    -

    Trouble shooting the SASL internals

    + -

    In the Cyrus SASL sources you'll find a subdirectory named -"sample". Run make there, then create a symbolic link from sample.conf -to smtpd.conf in your Cyrus SASL library directory /usr/local/lib/sasl2. -"su" to the user postfix (or whatever your mail_owner -directive is set to):

    +

    You can use one of the following commands to generate base64 +encoded authentication information: 

    -% su postfix
+% gen-auth plain
+username: username
+password:
    -

    then run the resulting sample Cyrus SASL server and client in -separate terminals. The sample applications send log messages to -the syslog -facility auth. Check the log to fix the problem or run strace / -ktrace / truss on the server to see what makes it unhappy. Repeat -the previous step until you can successfully authenticate with the -sample Cyrus SASL client. Only then get back to Postfix.

    +

    The gen-auth Perl script was written by John +Jetmore and can be found at http://jetmore.org/john/code/gen-auth.

    -

    Enabling SASL authentication in the -Postfix SMTP client

    +
    +
    +% printf '\0username\0password' | mmencode
+
    +
    -

    Turn on client-side SASL authentication, and specify a table -with per-host or per-destination username and password information. -The Postfix SMTP client first searches the table for an entry with -the remote SMTP server hostname; if no entry is found, then the -Postfix SMTP client searches the table for -an entry with the next-hop destination. Usually, that is the -right-hand part of an email address, but it can also be the information -that is specified with the relayhost parameter or with a transport(5) -table.

    +

    The mmencode command is part of the metamail +software.

    + +
    +
    +% perl -MMIME::Base64 -e \
+    'print encode_base64("\0username\0password");'
+
    +
    + +

    MIME::Base64 is available from http://www.cpan.org/.

    + +

    Configuring SASL authentication in the Postfix SMTP/LMTP client

    + +

    The Postfix SMTP and the LMTP client can authenticate with a +remote SMTP server via the Cyrus SASL framework. At this time, the +Dovecot SASL implementation does not provide client functionality. +

    + +
    + +Note + +

    The examples in this section discuss only the SMTP client. +Replace smtp_ with lmtp_ to get the +corresponding LMTP client configuration.

    + +
    + +

    You can read more about the following topics:

    + + + +

    Enabling SASL authentication in the +Postfix SMTP/LMTP client

    + +

    This section shows a typical scenario where the Postfix SMTP +client sends all messages via a mail gateway server that requires +SASL authentication. To make the example more readable we introduce +it in two parts. 

     /etc/postfix/main.cf:
     smtp_sasl_auth_enable = yes
-    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
-    smtp_sasl_type = cyrus
-    relayhost = [mail.myisp.net]
+    relayhost = [mail.isp.example]
     # Alternative form:
-    # relayhost = [mail.myisp.net]:submission
-
-/etc/postfix/sasl_passwd:
-    [mail.myisp.net]            username:password
-    [mail.myisp.net]:submission username:password
+    # relayhost = [mail.isp.example]:submission
+    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    -

    Notes:

    +
      + +

    • The smtp_sasl_auth_enable setting enables +client-side authentication. We will configure the client's username +and password information in the second part of the example.

      +
      • + +

    • The relayhost setting forces the Postfix SMTP +to send all remote messages to the specified mail server instead +of trying to deliver them directly to their destination.

      • + +

    • In the relayhost setting, the "[" +and "]" prevent the Postfix SMTP client from looking +up MX (mail exchanger) records for the enclosed name.

      • + +

    • The relayhost destination may also specify a +non-default TCP port. For example, the alternative form +[mail.isp.example]:submission tells Postfix to connect +to TCP network port 587, which is reserved for email client +applications.

      • + +

    • The Postfix SMTP client is compatible with SMTP servers +that use the non-standard "AUTH=method...." +syntax in response to the EHLO command; this requires no additional +Postfix client configuration.

      • + +

    • The Postfix SMTP client does not support the obsolete +"wrappermode" protocol, which uses TCP port 465 on the +SMTP server. See TLS_README for a solution that uses the +stunnel command.

      • + +

    • With the smtp_sasl_password_maps parameter, +we configure the Postfix SMTP client to send username and password +information to the mail gateway server. As discussed in the next +section, the Postfix SMTP client supports multiple ISP accounts. +For this reason the username and password are stored in a table +that contains one username/password combination for each mail gateway +server.

      + +
    + +
    +
    +/etc/postfix/sasl_passwd:
+    # destination                   credentials
+    [mail.isp.example]              username:password
+    # Alternative form:
+    # [mail.isp.example]:submission username:password
+
    +
    + +
    + +Important + +

    Keep the SASL client password file in /etc/postfix, +and make the file read+write only for root to protect +the username/password combinations against other users. The Postfix +SMTP client will still be able to read the SASL client passwords. +It opens the file as user root before it drops privileges, +and before entering an optional chroot jail.

    + +
      -

    • The "submission" destination port tells Postfix to send -mail via TCP network port 587, which is normally reserved for email -clients. The default is to send mail to the "smtp" destination port -(TCP port 25), which is used for receiving mail across the internet. -If you use an explicit destination port in main.cf, then you must -use the same form also in the smtp_sasl_password_maps file.

      +

    • Use the postmap command whenever you +change the /etc/postfix/sasl_passwd file.

      • -

    • Postfix does not deliver mail via TCP port 465 (the obsolete -"wrappermode" protocol). See TLS_README for a solution that uses the -"stunnel" command.

      +

    • If you specify the "[" and "]" +in the relayhost destination, then you must use the +same form in the smtp_sasl_password_maps file.

      +
      • -

    • The "[" and "]" prevent Postfix from looking up the MX -(mail exchanger) records for the enclosed name. If you use this -form in main.cf, then you must use the same form also in the -smtp_sasl_password_maps file.

      +

    • If you specify a non-default TCP Port (such as +":submission" or ":587") in the +relayhost destination, then you must use the same form +in the smtp_sasl_password_maps file.

      • -

    • The Postfix SMTP client opens the SASL client password -file before entering the optional chroot jail, so you can keep the -file in /etc/postfix and set permissions read / write only for root -to keep the username:password combinations away from other system -users.

      +
    -

  • Specify dbm instead of hash if your system -uses dbm files instead of db files. To find out what -lookup tables Postfix supports, use the command "postconf -m". +

    Configuring Sender-Dependent SASL +authentication

    + +

    Postfix supports different ISP accounts for different sender +addresses (version 2.3 and later). This can be useful when one +person uses the same machine for work and for personal use, or when +people with different ISP accounts share the same Postfix server.

    -

  • Execute the command "postmap /etc/postfix/sasl_passwd" -whenever you change the sasl_passwd table.

    - - - -

    Workarounds:

    - -
      - -

    • Some remote SMTP servers support PLAIN or LOGIN authentication only. -By default, the Postfix SMTP client does not use authentication -methods that send plaintext passwords, and defers delivery with -the following error message: "Authentication failed: cannot SASL -authenticate to server". To enable plaintext authentication specify, -for example:

      - -
      -
      -/etc/postfix/main.cf:
-    smtp_sasl_security_options = noanonymous
-
      -
      - -

    • Some remote SMTP servers announce authentication mechanisms -that don't actually work. It is possible via the smtp_sasl_mechanism_filter -parameter to restrict the list of server mechanisms that the Postfix -SMTP client will take into consideration:

      - -
      -
      -/etc/postfix/main.cf:
-    smtp_sasl_mechanism_filter = !gssapi, !external, static:all
-
      -
      - -

      In the above example, the Postfix SMTP client will decline to -use mechanisms -that require special infrastructure such as Kerberos or TLS.

      - -

    • The Postfix SMTP client is backwards compatible with SMTP -servers that use the non-standard "AUTH=method..." syntax in response -to the EHLO command; there is no Postfix client configuration needed -to work around it.

      - -
    - -

    Supporting multiple ISP accounts -in the Postfix SMTP client

    - -

    Postfix version 2.3 supports multiple ISP accounts. This can -be useful when one person uses the same machine for work and for -personal use, or when people with different ISP accounts share the -same Postfix server. To make this possible, Postfix 2.3 supports -per-sender SASL passwords and per-sender relay hosts. In the example -below, Postfix will search the SASL password file by sender before -it searches that same file by destination. Likewise, Postfix will -search the per-sender relayhost file, and use the default relayhost -only as a final resort.

    +

    To make this possible, Postfix supports per-sender SASL passwords +and per-sender relay hosts. In the example below, the Postfix SMTP +client will search the SASL password file by sender address before +it searches that same file by destination. Likewise, the Postfix +trivial-rewrite(8) daemon will search the per-sender relayhost file, +and use the default relayhost setting only as a final +resort. 

    @@ -746,26 +1667,33 @@ only as a final resort.  
    
     sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
     smtp_sasl_auth_enable = yes
     smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
-    relayhost = [mail.myisp.net]
+    relayhost = [mail.isp.example]
     # Alternative form:
-    # relayhost = [mail.myisp.net]:submission
-
-/etc/postfix/sasl_passwd:
-    # Per-sender authentication; see also /etc/postfix/sender_relay.
-    user1@example.com           username2:password2
-    user2@example.net           username2:password2
-    # Login information for the default relayhost.
-    [mail.myisp.net]            username:password
-    [mail.myisp.net]:submission username:password
-
-/etc/postfix/sender_relay:
-    # Per-sender provider; see also /etc/postfix/sasl_passwd.
-    user1@example.com           [mail.example.com]:submission
-    user2@example.net           [mail.example.net]
+    # relayhost = [mail.isp.example]:submission
    -

    Notes:

    +
    +
    +/etc/postfix/sasl_passwd:
+    # Per-sender authentication; see also /etc/postfix/sender_relay.
+    user1@example.com               username2:password2
+    user2@example.net               username2:password2
+    # Login information for the default relayhost.
+    [mail.isp.example]              username:password
+    # Alternative form:
+    # [mail.isp.example]:submission username:password
+
    +
    + +
    +
    +/etc/postfix/sender_relay:
+    # Per-sender provider; see also /etc/postfix/sasl_passwd.
+    user1@example.com               [mail.example.com]:submission
+    user2@example.net               [mail.example.net]
+
    +
      @@ -773,47 +1701,430 @@ only as a final resort.

      tables into one single MySQL database, and configure different Postfix queries to extract the appropriate information.

      -

    • Specify dbm instead of hash if your system -uses dbm files instead of db files. To find out what -lookup tables Postfix supports, use the command "postconf -m". -

      +

    • Specify dbm instead of hash if your system uses dbm files +instead of db files. To find out what lookup tables Postfix supports, +use the command "postconf -m".

      -

    • Execute the command "postmap /etc/postfix/sasl_passwd" +

    • Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change the sasl_passwd table.

      -

    • Execute the command "postmap /etc/postfix/sender_relay" +

    • Execute the command "postmap /etc/postfix/sender_relay" whenever you change the sender_relay table.

    +

    Postfix SMTP/LMTP client authentication +policy

    + +

    Just like the Postfix SMTP server, the SMTP client has a policy +that determines which SASL mechanisms are acceptable and which are +not.

    + +

    Unencrypted SMTP session

    + +

    The default policy is stricter than that of the Postfix SMTP +server - plaintext mechanisms are not allowed (nor is any anonymous +mechanism):

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_sasl_security_options = noplaintext, noanonymous
+
    +
    + +

    Postfix can enforce the following policies on SASL authentication +mechanisms:

    + +
    + +
    + +
    noanonymous
    + +

    Don't use mechanisms that permit anonymous authentication. +

    + +
    noplaintext
    + +

    Don't use mechanisms that transmit unencrypted username +and password information.

    + +
    nodictionary
    + +

    Don't use mechanisms that are vulnerable to dictionary +attacks.

    + +
    + +
    +
    mutual_auth
    + +

    Use only mechanisms that authenticate both the client and +the server to each other.

    + +
    + +
    + +

    With the default policy shown above, the Postfix SMTP client +will not send its password over an unencrypted connection. This +sometimes leads to authentication failures if the remote server +only offers plaintext authentication mechanisms. In such cases the +SMTP client will log the following error message:

    + +
    +
    +SASL authentication failure: No worthy mechs found
+
    +
    + +

    The less secure approach to deal with this is to lower the +security standards and permit plaintext authentication mechanisms: +

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_sasl_security_options = noanonymous
+
    +
    + +

    Needless to say, sending a username and password over an insecure +channel is undesirable.

    + +

    If the remote server supports TLS, you can protect the plaintext +username and password by turning on TLS in the Postfix SMTP client +(see: TLS_README), and configuring the client as discussed next. + +

    Encrypted SMTP session (TLS)

    + +

    A separate parameter controls Postfix SASL mechanism policy +during a TLS-encrypted SMTP session. The default is to copy the +settings from the unencrypted session:

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_sasl_tls_security_options = $smtp_sasl_security_options
+
    +
    + +

    A more sophisticated policy allows plaintext mechanisms, but +only over a TLS-encrypted connection:

    + +
    +
    +/etc/postfix/main.cf:
+    smtpd_sasl_security_options = noanonymous, noplaintext
+    smtpd_sasl_tls_security_options = noanonymous
+
    +
    + +

    Filtering server mechanism names in +the Postfix SMTP/LMTP client

    + +

    Cyrus SASL always attempts to use the most secure authentication +mechanism that the remote SMTP server offers - even if the client +side was not configured to handle it! In such cases authentication +will definitely fail.

    + +

    To prevent this, the Postfix SMTP client can filter the list +of authentication mechanism names from the remote SMTP server. Used +correctly, the filter hides unwanted mechanisms from the Cyrus SASL +library, forcing the library to choose from the mechanisms the +Postfix filter passes through.

    + +

    The following example filters out everything but the mechanisms +PLAIN and LOGIN:

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_sasl_mechanism_filter = plain, login
+
    +
    + +
    + +Note + +

    If the remote server does not offer any of the mechanisms on +the filter list, authentication will fail.

    + +
    + +

    We close this section with an example that passes every mechanism +except for GSSAPI and LOGIN:

    + +
    +
    +/etc/postfix/main.cf:
+    smtp_sasl_mechanism_filter = !gssapi, !login, static:all
+
    +
    + +

    Building Postfix with SASL support

    + +

    As mentioned elsewhere, Postfix supports two SASL implementations: +Cyrus SASL (SMTP client and server) and Dovecot SASL (SMTP server +only). Both implementations can be built into Postfix simultaneously. +

    + + + +

    Building Dovecot SASL support

    + +

    These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

    + +

    Support for the Dovecot version 1 SASL protocol is available +in Postfix 2.3 and later. At the time of writing, only server-side +SASL support is available, so you can't use it to authenticate the +Postfix SMTP client to your network provider's server.

    + +

    Dovecot uses its own daemon process for authentication. This +keeps the Postfix build process simple, because there is no need +to link extra libraries into Postfix.

    + +

    To generate the necessary Makefiles, execute the following in +the Postfix top-level directory:

    + +
    +
    +% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS='-DUSE_SASL_AUTH \
+    -DDEF_SERVER_SASL_TYPE=\"dovecot\"'
+
    +
    + +

    After this, proceed with "make" as described in +the INSTALL document.

    + +Note + +
      + +
    • + +

      The -DDEF_SERVER_SASL_TYPE=\"dovecot\" is not +necessary; it just makes Postfix configuration a little more +convenient because you don't have to specify the SASL plug-in type +in the Postfix main.cf file (but this may cause surprises when you +switch to a later Postfix version that is built with the default +SASL type of sasl).

      + +
      • + +
    • + +

      If you also want support for LDAP or TLS (or for Cyrus SASL), +you need to merge their CCARGS and AUXLIBS +options into the above command line; see the LDAP_README and +TLS_README for details.

      + +
      +
      +% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS='-DUSE_SASL_AUTH \
+    -DDEF_SERVER_SASL_TYPE=\"dovecot\" \
+    ...CCARGS options for LDAP or TLS etc....' \
+   AUXLIBS='...AUXLIBS options for LDAP or TLS etc....'
+
      +
      + +
      • + +
    + +

    Building Cyrus SASL support

    + +

    Building the Cyrus SASL library

    + +

    Postfix works with cyrus-sasl-1.5.x or cyrus-sasl-2.1.x, which are +available from ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/.

    + +
    + +Important + +

    If you install the Cyrus SASL libraries as per the default, you will have +to create a symlink /usr/lib/sasl -> +/usr/local/lib/sasl for version 1.5.x or +/usr/lib/sasl2 -> /usr/local/lib/sasl2 +for version 2.1.x.

    + +
    + +

    Reportedly, Microsoft Outlook (Express) requires the non-standard LOGIN +and/or NTLM authentication mechanism. To enable these authentication +mechanisms, build the Cyrus SASL libraries with:

    + +
    +
    +% ./configure --enable-login --enable-ntlm
+
    +
    + +

    Building Postfix with Cyrus SASL support

    + +

    These instructions assume that you build Postfix from source +code as described in the INSTALL document. Some modification may +be required if you build Postfix from a vendor-specific source +package.

    + +

    The following assumes that the Cyrus SASL include files are in +/usr/local/include, and that the Cyrus SASL libraries are in +/usr/local/lib.

    + +

    On some systems this generates the necessary Makefile +definitions:

    + +
    + +
    Cyrus SASL version 2.1.x
    + +
    + +
    +% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib -lsasl2"
+
    + +
    + +
    Cyrus SASL version 1.5.x
    + +
    + +
    +% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include" AUXLIBS="-L/usr/local/lib -lsasl"
+
    + +
    + +
    + +

    On Solaris 2.x you need to specify run-time link information, +otherwise the ld.so run-time linker will not find the SASL shared +library:

    + +
    + +
    Cyrus SASL version 2.1.x
    + +
    + +
    +% make tidy # remove left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include/sasl" AUXLIBS="-L/usr/local/lib \
+    -R/usr/local/lib -lsasl2"
+
    + +
    + +
    Cyrus SASL version 1.5.x
    + +
    + +
    +% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL \
+    -I/usr/local/include" AUXLIBS="-L/usr/local/lib \
+    -R/usr/local/lib -lsasl"
+
    + +
    + +
    + +

    Using Cyrus SASL version 1.5.x

    + +

    Postfix supports Cyrus SASL version 1.x, but you shouldn't use +it unless you are forced to. The makers of Cyrus SASL write:

    + +
    This library is being deprecated and applications +should transition to using the SASLv2 library (source: Project Cyrus: +Downloads).
    + +

    If you still need to set it up, here's a quick rundown:

    + +

    Read the regular section on SMTP server configurations for the +Cyrus SASL framework. The differences are:

    + +
      + +

    • Cyrus SASL version 1.5.x searches for configuration +(smtpd.conf) in /usr/lib/sasl/ only. You +must place the configuration in that directory. Some systems may +have modified Cyrus SASL and put the files into e.g. +/var/lib/sasl/.

      • + +

    • Use the saslpasswd command instead of +saslpasswd2 to create users in sasldb. +

      • + +

    • Use the sasldblistusers command instead of +sasldblistusers2 to find users in sasldb. +

      • + +

    • In the smtpd.conf file you can't use +mech_list to limit the range of mechanisms offered. +Instead, remove their libraries from /usr/lib/sasl/ +(and remember remove those files again when a system update +re-installs new versions).

      • + +
    +

    Credits

    • Postfix SASL support was originally implemented by Till Franke -of SuSE Rhein/Main AG. +of SuSE Rhein/Main AG.
    • Wietse trimmed down the code to only the bare necessities. +
    • Support for Cyrus SASL version 2 was contributed by Jason Hoos. +
      • -
    • Liviu Daia added smtpd_sasl_application_name, split +
    • Liviu Daia added smtpd_sasl_application_name, separated reject_sender_login_mismatch into reject_authenticated_sender_login_mismatch and reject_unauthenticated_sender_login_mismatch, and revised the docs. +
    • Wietse made another iteration through the code to add plug-in -support for multiple SASL implementations, and changed -smtpd_sasl_application_name into smtpd_sasl_path. +support for multiple SASL implementations, and for reasons that +have been lost, also changed smtpd_sasl_application_name into +smtpd_sasl_path.
      • -
    • The Dovecot SMTP server-only plug-in was originally implemented by -Timo Sirainen of Procontrol, Finland. +
    • The Dovecot SMTP server-only plug-in was originally implemented +by Timo Sirainen of Procontrol, Finland.
    • Patrick Ben Koetter revised this document for Postfix 2.4 and -made much needed updates. +made much needed updates.
      • + +
    • Patrick Ben Koetter revised this document again for Postfix +2.7 and made much needed updates.
    + diff --git a/postfix/proto/TLS_README.html b/postfix/proto/TLS_README.html index f42bee9c6..b75bf9ed0 100644 --- a/postfix/proto/TLS_README.html +++ b/postfix/proto/TLS_README.html @@ -2237,7 +2237,7 @@ as specified by the smtp_tls_mandatory_ciphers configuration parameter. This setting controls the minimum acceptable SMTP client TLS cipher grade for use with mandatory TLS encryption. The default value "medium" is suitable for most destinations with which you may -want to enforce TLS, and is beyond the reach of today's crypt-analytic +want to enforce TLS, and is beyond the reach of today's cryptanalytic methods. See smtp_tls_policy_maps for information on how to configure ciphers on a per-destination basis.

    diff --git a/postfix/proto/pcre_table b/postfix/proto/pcre_table index 5ae105ba4..5b7e2b206 100644 --- a/postfix/proto/pcre_table +++ b/postfix/proto/pcre_table @@ -66,7 +66,8 @@ # starts with whitespace continues a logical line. # .PP # Each pattern is a perl-like regular expression. The expression -# delimiter can be any character, except whitespace or characters +# delimiter can be any non-alphanumerical character, except +# whitespace or characters # that have special meaning (traditionally the forward slash is used). # The regular expression can contain whitespace. # diff --git a/postfix/proto/postconf.proto b/postfix/proto/postconf.proto index f827592fb..e4fcd4853 100644 --- a/postfix/proto/postconf.proto +++ b/postfix/proto/postconf.proto @@ -1269,8 +1269,8 @@ domain.

    Specify a string of the form transport:nexthop, where transport is the name of a mail delivery transport defined in master.cf. -The :nexthop part is optional. For more details see the -transport(5) manual page. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent.

    @@ -2297,8 +2297,8 @@ which is just the name of a service that is defined the master.cf file.

    Specify a string of the form transport:nexthop, where transport is the name of a mail delivery transport defined in master.cf. -The :nexthop part is optional. For more details see the -transport(5) manual page. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent.

    @@ -3569,10 +3569,10 @@ relocated_maps = hash:/etc/postfix/relocated %PARAM require_home_directory no

    -Whether or not a local(8) recipient's home directory must exist +Require that a local(8) recipient's home directory exists before mail delivery is attempted. By default this test is disabled. It can be useful for environments that import home directories to -the mail server (NOT RECOMMENDED). +the mail server (IMPORTING HOME DIRECTORIES IS NOT RECOMMENDED).

    %PARAM resolve_dequoted_address yes @@ -5404,7 +5404,7 @@ more of the following, separated by comma or whitespace.

    speed_adjust
    -
    Do not connect to a before-queue content filter until an entire +

    Do not connect to a before-queue content filter until an entire message has been received. This reduces the number of simultaneous before-queue content filter processes.

    @@ -7609,8 +7609,8 @@ the transport(5) table.

    Specify a string of the form transport:nexthop, where transport is the name of a mail delivery transport defined in master.cf. -The :nexthop part is optional. For more details see the -transport(5) manual page. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent.

    @@ -8258,8 +8258,8 @@ This information can be overruled with the transport(5) table.

    Specify a string of the form transport:nexthop, where transport is the name of a mail delivery transport defined in master.cf. -The :nexthop part is optional. For more details see the -transport(5) manual page. +The :nexthop destination is optional; its syntax is documented +in the manual page of the corresponding delivery agent.

    @@ -10522,7 +10522,7 @@ smtp_tls_security_level = none # Opportunistic TLS. smtp_tls_security_level = may # Postfix ≥ 2.6: -# Do not tweak opportunistic ciphers unless it is essential +# Do not tweak opportunistic ciphers or protocol unless it is essential # to do so (if a security vulnerability is found in the SSL library that # can be mitigated by disabling a particular protocol or raising the # cipher grade from "export" to "low" or "medium"). @@ -10769,65 +10769,46 @@ meanings.

    %PARAM smtpd_tls_mandatory_ciphers medium -

    The minimum TLS cipher grade that the Postfix SMTP server -will use with mandatory TLS encryption. Cipher types listed in -smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are -excluded from the base definition of the selected cipher grade. See -smtpd_tls_ciphers for cipher controls that apply to opportunistic -TLS.

    +

    The minimum TLS cipher grade that the Postfix SMTP server will +use with mandatory TLS encryption. The default grade ("medium") is +sufficiently strong that any benefit from globally restricting TLS +sessions to a more stringent grade is likely negligible, especially +given the fact that many implementations still do not offer any stronger +("high" grade) ciphers, while those that do, will always use "high" +grade ciphers. So insisting on "high" grade ciphers is generally +counter-productive. Allowing "export" or "low" ciphers is typically +not a good idea, as systems limited to just these are limited to +obsolete browsers. No known SMTP clients fail to support at least +one "medium" or "high" grade cipher.

    The following cipher grades are supported:

    export
    -
    Enable the mainstream "EXPORT" grade or better OpenSSL ciphers. +
    Enable "EXPORT" grade or stronger OpenSSL ciphers. This is the most appropriate setting for public MX hosts, and is always used with opportunistic TLS encryption. The underlying cipherlist is specified via the tls_export_cipherlist configuration parameter, -which you are strongly encouraged to not change. The default value -of tls_export_cipherlist includes anonymous ciphers, but these are -automatically filtered out if the server is configured to ask for -client certificates. If you must always exclude anonymous ciphers, -set "smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers -only when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers = -aNULL".
    +which you are strongly encouraged to not change.
    low
    -
    Enable the mainstream "LOW" grade or better OpenSSL ciphers. The +
    Enable "LOW" grade or stronger OpenSSL ciphers. The underlying cipherlist is specified via the tls_low_cipherlist configuration parameter, which you are strongly encouraged to -not change. The default value of tls_low_cipherlist includes -anonymous ciphers, but these are automatically filtered out if the -server is configured to ask for client certificates. If you must -always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers = -aNULL". To exclude anonymous ciphers only when TLS is enforced, set -"smtpd_tls_mandatory_exclude_ciphers = aNULL".
    +not change.
    • medium
    -
    Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers. These -are essentially the 128-bit or stronger ciphers. This is the default -minimum strength for mandatory TLS encryption. MSAs that enforce -TLS and have clients that do not support any "MEDIUM" or "HIGH" -grade ciphers, may need to configure a weaker ("low" or "export") -minimum cipher grade. The underlying cipherlist is specified via the -tls_medium_cipherlist configuration parameter, which you are strongly -encouraged to not change. The default value of tls_medium_cipherlist -includes anonymous ciphers, but these are automatically filtered out if -the server is configured to ask for client certificates. If you must -always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers = -aNULL". To exclude anonymous ciphers only when TLS is enforced, set -"smtpd_tls_mandatory_exclude_ciphers = aNULL".
    +
    Enable "MEDIUM" grade or stronger OpenSSL ciphers. These use 128-bit +or longer symmetric bulk-encryption keys. This is the default minimum +strength for mandatory TLS encryption. The underlying cipherlist is +specified via the tls_medium_cipherlist configuration parameter, which +you are strongly encouraged to not change.
    high
    -
    Enable only the mainstream "HIGH" grade OpenSSL ciphers. The +
    Enable only "HIGH" grade OpenSSL ciphers. The underlying cipherlist is specified via the tls_high_cipherlist configuration parameter, which you are strongly encouraged to -not change. The default value of tls_high_cipherlist includes -anonymous ciphers, but these are automatically filtered out if the -server is configured to ask for client certificates. If you must -always exclude anonymous ciphers, set "smtpd_tls_exclude_ciphers = -aNULL". To exclude anonymous ciphers only when TLS is enforced, set -"smtpd_tls_mandatory_exclude_ciphers = aNULL".
    +not change.
    null
    Enable only the "NULL" OpenSSL ciphers, these provide authentication @@ -10835,12 +10816,25 @@ without encryption. This setting is only appropriate in the rare case that all clients are prepared to use NULL ciphers (not normally enabled in TLS clients). The underlying cipherlist is specified via the tls_null_cipherlist configuration parameter, which you are strongly -encouraged to not change. The default value of tls_null_cipherlist -excludes anonymous ciphers (OpenSSL 0.9.8 has NULL ciphers that offer -data integrity without encryption or authentication).
    +encouraged to not change. +

    Cipher types listed in +smtpd_tls_mandatory_exclude_ciphers or smtpd_tls_exclude_ciphers are +excluded from the base definition of the selected cipher grade. See +smtpd_tls_ciphers for cipher controls that apply to opportunistic +TLS.

    + +

    The underlying cipherlists for grades other than "null" include +anonymous ciphers, but these are automatically filtered out if the +server is configured to ask for client certificates. You are very +unlikely to need to take any steps to exclude anonymous ciphers, they +are excluded automatically as required. If you must exclude anonymous +ciphers even when Postfix does not need or use peer certificates, set +"smtpd_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only +when TLS is enforced, set "smtpd_tls_mandatory_exclude_ciphers = aNULL".

    +

    This feature is available in Postfix 2.3 and later.

    %PARAM smtpd_tls_exclude_ciphers @@ -10889,7 +10883,7 @@ works in addition to the exclusions listed with smtpd_tls_exclude_ciphers use with mandatory TLS encryption. The default value "medium" is suitable for most destinations with which you may want to enforce TLS, and -is beyond the reach of today's crypt-analytic methods. See +is beyond the reach of today's cryptanalytic methods. See smtp_tls_policy_maps for information on how to configure ciphers on a per-destination basis.

    @@ -10897,47 +10891,32 @@ on a per-destination basis.

    export
    -
    Enable the mainstream "EXPORT" grade or better OpenSSL -ciphers. This is always used for opportunistic encryption. It is +
    Enable "EXPORT" grade or better OpenSSL +ciphers. This is the default for opportunistic encryption. It is not recommended for mandatory encryption unless you must enforce TLS with "crippled" peers. The underlying cipherlist is specified via the tls_export_cipherlist configuration parameter, which you are strongly -encouraged to not change. The default value of tls_export_cipherlist -includes anonymous ciphers, but these are automatically filtered out if -the client is configured to verify server certificates. If you must -exclude anonymous ciphers also at the "encrypt" security level, set -"smtp_tls_mandatory_exclude_ciphers = aNULL".
    +encouraged to not change.
    low
    -
    Enable the mainstream "LOW" grade or better OpenSSL ciphers. This +
    Enable "LOW" grade or better OpenSSL ciphers. This setting is only appropriate for internal mail servers. The underlying cipherlist is specified via the tls_low_cipherlist configuration -parameter, which you are strongly encouraged to not change. The default -value of tls_low_cipherlist includes anonymous ciphers, but these are -automatically filtered out if the client is configured to verify server -certificates. If you must exclude anonymous ciphers also at the "encrypt" -security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL".
    +parameter, which you are strongly encouraged to not change.
    medium
    -
    Enable the mainstream "MEDIUM" grade or better OpenSSL ciphers. +
    Enable "MEDIUM" grade or better OpenSSL ciphers. The underlying cipherlist is specified via the tls_medium_cipherlist configuration parameter, which you are strongly encouraged to not change. -The default value of tls_medium_cipherlist includes anonymous ciphers, -but these are automatically filtered out if the client is configured to -verify server certificates. If you must exclude anonymous ciphers also -at the "encrypt" security level, set "smtp_tls_mandatory_exclude_ciphers -= aNULL".
    +
    high
    -
    Enable only the mainstream "HIGH" grade OpenSSL ciphers. This -setting is appropriate when all mandatory TLS destinations support -some of "HIGH" grade ciphers, this is not uncommon. The underlying -cipherlist is specified via the tls_high_cipherlist configuration -parameter, which you are strongly encouraged to not change. The default -value of tls_high_cipherlist includes anonymous ciphers, but these are -automatically filtered out if the client is configured to verify server -certificates. If you must exclude anonymous ciphers also at the "encrypt" -security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL".
    +
    Enable only "HIGH" grade OpenSSL ciphers. This setting may +be appropriate when all mandatory TLS destinations (e.g. when all +mail is routed to a suitably capable relayhost) support at least one +"HIGH" grade cipher. The underlying cipherlist is specified via the +tls_high_cipherlist configuration parameter, which you are strongly +encouraged to not change.
    null
    Enable only the "NULL" OpenSSL ciphers, these provide authentication @@ -10947,12 +10926,20 @@ in TLS servers). A plausible use-case is an LMTP server listening on a UNIX-domain socket that is configured to support "NULL" ciphers. The underlying cipherlist is specified via the tls_null_cipherlist configuration parameter, which you are strongly encouraged to not -change. The default value of tls_null_cipherlist excludes anonymous -ciphers (OpenSSL 0.9.8 has NULL ciphers that offer data integrity without -encryption or authentication).
    +change.
    +

    The underlying cipherlists for grades other than "null" include +anonymous ciphers, but these are automatically filtered out if the +Postfix SMTP client is configured to verify server certificates. +You are very unlikely to need to take any steps to exclude anonymous +ciphers, they are excluded automatically as necessary. If you must +exclude anonymous ciphers at the "may" or "encrypt" security levels, +when the Postfix SMTP client does not need or use peer certificates, set +"smtp_tls_exclude_ciphers = aNULL". To exclude anonymous ciphers only when +TLS is enforced, set "smtp_tls_mandatory_exclude_ciphers = aNULL".

    +

    This feature is available in Postfix 2.3 and later.

    %PARAM smtp_tls_exclude_ciphers @@ -12552,7 +12539,7 @@ parameter. Specify one of the following:

    continue
    -
    Forward the connection to a real SMTP server process.

    +
    Forward the connection to a real SMTP server process.
    drop
    @@ -12576,7 +12563,7 @@ parameter. Specify one of the following:

    elapsed. If the client is listed at the DNS blocklist domains specified with the postscreen_dnsbl_sites parameter, execute the action specified with the postscreen_dnsbl_action parameter, otherwise -forward the connection to a real SMTP server process.

    +forward the connection to a real SMTP server process.
    drop
    @@ -12604,7 +12591,7 @@ postscreen_greet_wait parameter. Specify one of the following:
    Continue waiting until the postscreen_greet_wait time has elapsed, and report whether the client is listed at the DNSBL sites specified with the postscreen_dnsbl_sites parameter. Do not -forward the broken connection to a real SMTP server process.

    +forward the broken connection to a real SMTP server process.
    drop
    @@ -12660,7 +12647,7 @@ elapsed, and report whether the client triggers a PREGREET or HANGUP error, or whether the client is listed at the DNSBL sites specified with the postscreen_dnsbl_sites parameter. Take the corresponding action, or forward the connection to a real SMTP server process. -

    +
    drop
    @@ -12800,7 +12787,7 @@ configuration parameter. See there for details.

    This feature is available in Postfix 2.7 and later.

    -%PARAM empty_address_default_transport_maps_lookup_key <> +%PARAM empty_address_default_transport_maps_lookup_key <>

    The sender_dependent_default_transport_maps search string that will be used instead of the null sender address.

    diff --git a/postfix/proto/regexp_table b/postfix/proto/regexp_table index 5375ad787..ae062f675 100644 --- a/postfix/proto/regexp_table +++ b/postfix/proto/regexp_table @@ -70,7 +70,8 @@ # \fBre_format\fR(7) with 4.4BSD, in \fBregex\fR(5) with Solaris, and in # \fBregex\fR(7) with Linux. Other systems may use other document names. # -# The expression delimiter can be any character, except whitespace +# The expression delimiter can be any non-alphanumerical +# character, except whitespace # or characters that have special meaning (traditionally the forward # slash is used). The regular expression can contain whitespace. # diff --git a/postfix/src/global/mail_version.h b/postfix/src/global/mail_version.h index ba98408e0..73890d837 100644 --- a/postfix/src/global/mail_version.h +++ b/postfix/src/global/mail_version.h @@ -20,8 +20,8 @@ * Patches change both the patchlevel and the release date. Snapshots have no * patchlevel; they change the release date only. */ -#define MAIL_RELEASE_DATE "20100117" -#define MAIL_VERSION_NUMBER "2.7" +#define MAIL_RELEASE_DATE "20100203" +#define MAIL_VERSION_NUMBER "2.8" #ifdef SNAPSHOT # define MAIL_VERSION_DATE "-" MAIL_RELEASE_DATE diff --git a/postfix/src/postqueue/postqueue.c b/postfix/src/postqueue/postqueue.c index 24f08d9d0..4dfedabb7 100644 --- a/postfix/src/postqueue/postqueue.c +++ b/postfix/src/postqueue/postqueue.c @@ -48,8 +48,7 @@ /* Each queue entry shows the queue file ID, message /* size, arrival time, sender, and the recipients that still need to /* be delivered. If mail could not be delivered upon the last attempt, -/* the reason for failure is shown. This mode of operation is implemented -/* by executing the \fBpostqueue\fR(1) command. The queue ID string +/* the reason for failure is shown. The queue ID string /* is followed by an optional status character: /* .RS /* .IP \fB*\fR diff --git a/postfix/src/proxymap/proxymap.c b/postfix/src/proxymap/proxymap.c index 593986978..24016ab72 100644 --- a/postfix/src/proxymap/proxymap.c +++ b/postfix/src/proxymap/proxymap.c @@ -593,12 +593,6 @@ static void post_jail_init(char *service_name, char **unused_argv) } myfree(saved_filter); - /* - * This process is called by clients that already enforce the max_idle - * time, so we don't have to do it another time. - */ - var_idle_limit = 1; - /* * Never, ever, get killed by a master signal, as that could corrupt a * persistent database when we're in the middle of an update. diff --git a/postfix/src/smtpd/smtpd.c b/postfix/src/smtpd/smtpd.c index 6ea2abcde..abec2da99 100644 --- a/postfix/src/smtpd/smtpd.c +++ b/postfix/src/smtpd/smtpd.c @@ -92,8 +92,6 @@ /* Resolve an address that ends in the "@" null domain as if the /* local hostname were specified, instead of rejecting the address as /* invalid. -/* .IP "\fBsmtpd_command_filter (empty)\fR" -/* A mechanism to transform commands from remote SMTP clients. /* .IP "\fBsmtpd_reject_unlisted_sender (no)\fR" /* Request that the Postfix SMTP server rejects mail from unknown /* sender addresses, even when no explicit reject_unlisted_sender @@ -125,6 +123,10 @@ /* Available in Postfix version 2.6 and later: /* .IP "\fBtcp_windowsize (0)\fR" /* An optional workaround for routers that break TCP window scaling. +/* .PP +/* Available in Postfix version 2.7 and later: +/* .IP "\fBsmtpd_command_filter (empty)\fR" +/* A mechanism to transform commands from remote SMTP clients. /* ADDRESS REWRITING CONTROLS /* .ad /* .fi @@ -4150,8 +4152,8 @@ typedef struct SMTPD_CMD { #define SMTPD_CMD_FLAG_LAST (1<<2) /* last in PIPELINING command group */ static SMTPD_CMD smtpd_cmd_table[] = { - SMTPD_CMD_HELO, helo_cmd, SMTPD_CMD_FLAG_LIMIT | SMTPD_CMD_FLAG_PRE_TLS, - SMTPD_CMD_EHLO, ehlo_cmd, SMTPD_CMD_FLAG_LIMIT | SMTPD_CMD_FLAG_PRE_TLS, + SMTPD_CMD_HELO, helo_cmd, SMTPD_CMD_FLAG_LIMIT | SMTPD_CMD_FLAG_PRE_TLS | SMTPD_CMD_FLAG_LAST, + SMTPD_CMD_EHLO, ehlo_cmd, SMTPD_CMD_FLAG_LIMIT | SMTPD_CMD_FLAG_PRE_TLS | SMTPD_CMD_FLAG_LAST, #ifdef USE_TLS SMTPD_CMD_STARTTLS, starttls_cmd, SMTPD_CMD_FLAG_PRE_TLS, #endif diff --git a/postfix/src/smtpd/smtpd_proxy.c b/postfix/src/smtpd/smtpd_proxy.c index 7535eaeba..0968f5b5b 100644 --- a/postfix/src/smtpd/smtpd_proxy.c +++ b/postfix/src/smtpd/smtpd_proxy.c @@ -74,9 +74,10 @@ /* 2xx or 3xx proxy server response is replaced by a generic /* error response to avoid support problems. /* In case of error, smtpd_proxy_create() updates the -/* state->error_mask and state->err fields, and leaves the the -/* proxy handle in an unconnected state. Destroy the handle -/* after reporting the error reply in the proxy->buffer field. +/* state->error_mask and state->err fields, and leaves the +/* SMTPD_PROXY handle in an unconnected state. Destroy the +/* handle after reporting the error reply in the proxy->buffer +/* field. /* /* proxy->cmd() formats and either buffers up the command and /* expected response until the entire message is received, or @@ -374,8 +375,8 @@ static int smtpd_proxy_connect(SMTPD_STATE *state) * Send our own EHLO command. If this fails then we have a problem * because the proxy should always accept our EHLO command. Make up our * own response instead of passing back a negative EHLO reply: the proxy - * open is delayed to the point that the client expects a MAIL FROM or - * RCPT TO reply. + * open is delayed to the point that the remote SMTP client expects a + * MAIL FROM or RCPT TO reply. */ if (smtpd_proxy_cmd(state, SMTPD_PROX_WANT_OK, "EHLO %s", proxy->ehlo_name)) { @@ -403,8 +404,8 @@ static int smtpd_proxy_connect(SMTPD_STATE *state) * Send XFORWARD attributes. For robustness, explicitly specify what SMTP * session attributes are known and unknown. Make up our own response * instead of passing back a negative XFORWARD reply: the proxy open is - * delayed to the point that the client expects a MAIL FROM or RCPT TO - * reply. + * delayed to the point that the remote SMTP client expects a MAIL FROM + * or RCPT TO reply. */ if (server_xforward_features) { buf = vstring_alloc(100); @@ -443,9 +444,9 @@ static int smtpd_proxy_connect(SMTPD_STATE *state) } /* - * Pass-through the client's MAIL FROM command. If this fails, then we - * have a problem because the proxy should always accept any MAIL FROM - * command that was accepted by us. + * Pass-through the remote SMTP client's MAIL FROM command. If this + * fails, then we have a problem because the proxy should always accept + * any MAIL FROM command that was accepted by us. */ if (smtpd_proxy_cmd(state, SMTPD_PROX_WANT_OK, "%s", proxy->mail_from) != 0) { diff --git a/postfix/src/trivial-rewrite/trivial-rewrite.c b/postfix/src/trivial-rewrite/trivial-rewrite.c index 22f1b79a2..b8cc438c2 100644 --- a/postfix/src/trivial-rewrite/trivial-rewrite.c +++ b/postfix/src/trivial-rewrite/trivial-rewrite.c @@ -565,12 +565,6 @@ static void post_jail_init(char *unused_name, char **unused_argv) if (resolve_verify.transport_info) transport_post_init(resolve_verify.transport_info); check_table_stats(0, (char *) 0); - - /* - * This process is called by clients that already enforce the max_idle - * time, so we don't have to do it another time. - */ - var_idle_limit = 1; } MAIL_VERSION_STAMP_DECLARE; diff --git a/postfix/src/verify/verify.c b/postfix/src/verify/verify.c index 116dd53a6..a1a1535f7 100644 --- a/postfix/src/verify/verify.c +++ b/postfix/src/verify/verify.c @@ -30,7 +30,8 @@ /* .IP "\fBupdate\fI address status text\fR" /* Update the status and text of the specified address. /* .IP "\fBquery\fI address\fR" -/* Look up the \fIstatus\fR and \fItext\fR for the specified address. +/* Look up the \fIstatus\fR and \fItext\fR for the specified +/* \fIaddress\fR. /* If the status is unknown, a probe is sent and an "in progress" /* status is returned. /* SECURITY @@ -41,7 +42,8 @@ /* The verify server can run chrooted at fixed low privilege. /* /* The address verification server can be coerced to store -/* unlimited amounts of garbage. Limiting the cache size +/* unlimited amounts of garbage. Limiting the cache expiry +/* time /* trades one problem (disk space exhaustion) for another /* one (poor response time to client requests). /* @@ -55,11 +57,13 @@ /* DIAGNOSTICS /* Problems and transactions are logged to \fBsyslogd\fR(8). /* BUGS -/* The address verification service is suitable only for sites that -/* handle a low mail volume. Verification probes add additional -/* traffic to the mail queue and perform poorly under high load. -/* Servers may blacklist sites that probe excessively, or that -/* probe excessively for non-existent recipient addresses. +/* Address verification probe messages add additional traffic +/* to the mail queue. +/* Recipient verification may cause an increased load on +/* down-stream servers in the case of a dictionary attack or +/* a flood of backscatter bounces. +/* Sender address verification may cause your site to be +/* blacklisted by some providers. /* /* If the persistent database ever gets corrupted then the world /* comes to an end and human intervention is needed. This violates @@ -69,7 +73,7 @@ /* .fi /* Changes to \fBmain.cf\fR are not picked up automatically, /* as \fBverify\fR(8) -/* processes are persistent. Use the command "\fBpostfix reload\fR" after +/* processes are long-lived. Use the command "\fBpostfix reload\fR" after /* a configuration change. /* /* The text below provides only a parameter summary. See