From: Wietse Venema Date: Wed, 3 Feb 2010 05:00:00 +0000 (-0500) Subject: postfix-2.8-20100203 X-Git-Tag: v2.8.0-RC1~42 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=49524057e95c4fc3f98d45b68189c322e15509d2;p=thirdparty%2Fpostfix.git postfix-2.8-20100203 --- 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 delivery - messages status - v | - - Postfix Postfix - queue -> delivery - agents + + probe Postfix + message -> mail + queue + Postfix Postfix -> + Internet -> SMTP <-> verify + server server | + v + + <- Postfix + probe <- delivery -> Local + status agents -> Remote + ^ + | + v + + + 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. - - qmgr(8) Delivery - Network -> smtpd(8) <-> verify(8) -> cleanup(8) -> Postfix -> agents - queue - - \ | / - v - \ / - <- <- + 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. + + + probe Postfix + message -> mail + queue + Network -> smtpd(8) <-> verify(8) -> + + | + 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,368 +2,884 @@ 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. - -HHooww PPoossttffiixx uusseess SSAASSLL aauutthheennttiiccaattiioonn iinnffoorrmmaattiioonn - -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 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. - -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. - -This document covers 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 +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 + +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. + +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. + +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. + +You can read more about the following topics: + + * 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 -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. + o Cyrus SASL configuration file name + o Cyrus SASL configuration file location + o Postfix to Cyrus SASL communication -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. + * Enabling SASL authentication and authorization in the Postfix SMTP server -To generate the necessary Makefiles, execute the following in the Postfix top- -level directory: + 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 - % make makefiles CCARGS='-DUSE_SASL_AUTH - - DDEF_SERVER_SASL_TYPE=\"dovecot\"' + * Testing SASL authentication in the Postfix SMTP server -After this, proceed with "make" as described in the INSTALL document. +WWhhiicchh SSAASSLL IImmpplleemmeennttaattiioonnss aarree ssuuppppoorrtteedd?? -Notes: +Currently the Postfix SMTP server supports the Cyrus SASL and Dovecot SASL +implementations. - * 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. + NNoottee - * If you also want support for LDAP or TLS, you will have to merge their - CCARGS and AUXLIBS into the above command line. + 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. -BBuuiillddiinngg tthhee CCyyrruuss SSAASSLL lliibbrraarryy +To find out what SASL implementations are compiled into Postfix, use the +following commands: -Postfix appears to work with cyrus-sasl-1.5.x or cyrus-sasl-2.1.x, which are -available from: + % ppoossttccoonnff --aa (SASL support in the SMTP server) + % ppoossttccoonnff --AA (SASL support in the SMTP+LMTP client) - ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/ +These commands are available only with Postfix version 2.3 and later. -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. +CCoonnffiigguurriinngg DDoovveeccoott SSAASSLL -Reportedly, Microsoft Outlook (Express) requires the non-standard LOGIN -authentication method. To enable this authentication method, specify ``./ -configure --enable-login''. +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. -BBuuiillddiinngg PPoossttffiixx wwiitthh CCyyrruuss SSAASSLL ssuuppppoorrtt +PPoossttffiixx ttoo DDoovveeccoott SSAASSLL ccoommmmuunniiccaattiioonn -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. +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 assumes that the Cyrus SASL include files are in /usr/local/ -include, and that the Cyrus SASL libraries are in /usr/local/lib. +The following example assumes that the Postfix queue is under /var/spool/ +postfix/. -On some systems this generates the necessary Makefile definitions: + 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 } -(for Cyrus SASL version 1.5.x): +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. - % 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" +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. -(for Cyrus SASL version 2.1.x): +CCoonnffiigguurriinngg CCyyrruuss SSAASSLL - % 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" +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. -On Solaris 2.x you need to specify run-time link information, otherwise ld.so -will not find the SASL shared library: +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. -(for Cyrus SASL version 1.5.x): +CCyyrruuss SSAASSLL ccoonnffiigguurraattiioonn ffiillee nnaammee - % 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" +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. -(for Cyrus SASL version 2.1.x): +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: - % 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" + /etc/postfix/main.cf: + # Postfix 2.3 and later + smtpd_sasl_path = smtpd -EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr + # 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 -In order to enable SASL support in the Postfix SMTP server: + 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_auth_enable = yes + smtpd_sasl_type = dovecot -In order to allow mail relaying by authenticated remote SMTP clients: +Additionally set the path where the Postfix SMTP server can find the Dovecot +SASL socket: /etc/postfix/main.cf: - smtpd_recipient_restrictions = - permit_mynetworks - permit_sasl_authenticated - reject_unauth_destination + smtpd_sasl_path = private/auth -To report SASL login names in Received: message headers (Postfix version 2.3 -and later): + 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_authenticated_header = yes + 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 + ... -Note: the SASL login names will be shared with the entire world. +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. -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: /etc/postfix/main.cf: broken_sasl_auth_clients = yes -DDoovveeccoott SSAASSLL ccoonnffiigguurraattiioonn ffoorr tthhee PPoossttffiixx SSMMTTPP sseerrvveerr + NNoottee -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: + 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. - /etc/postfix/main.cf: - smtpd_sasl_type = dovecot - smtpd_sasl_path = private/auth +After "postfix reload", the Postfix SMTP server will propagate the AUTH +capability twice - once for compliant and once for broken clients: -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: + % 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: - # Postfix 2.3 and later - smtpd_sasl_path = smtpd - # Postfix < 2.3 - smtpd_sasl_application_name = smtpd + # 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. -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). + noplaintext + Don't use mechanisms that transmit unencrypted username and password + information. -Note: some Postfix distributions are modified and look for the smtpd.conf file -in /etc/postfix/sasl. + nodictionary + Don't use mechanisms that are vulnerable to dictionary attacks. -Note: some Cyrus SASL distributions look for the smtpd.conf file in /etc/sasl2. + 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 - * To authenticate against the UNIX password database, use: +A more sophisticated policy allows plaintext mechanisms, but only over a TLS- +encrypted connection: - (Cyrus SASL version 1.5.x) + /etc/postfix/main.cf: + smtpd_sasl_security_options = noanonymous, noplaintext + smtpd_sasl_tls_security_options = noanonymous - /usr/local/lib/sasl/smtpd.conf: - pwcheck_method: pwcheck +To offer SASL authentication only after a TLS-encrypted session has been +established specify this: - 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. + /etc/postfix/main.cf: + smtpd_tls_auth_only = yes - The pwcheck daemon is contained in the cyrus-sasl source tarball. +EEnnaabblliinngg SSAASSLL aauutthhoorriizzaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr - (Cyrus SASL version 1.5.26) +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: - /usr/local/lib/sasl/smtpd.conf: - pwcheck_method: saslauthd + * Send a message to a remote recipient. - (Cyrus SASL version 2.1.x) + * Use a specific envelope sender in the MAIL FROM command. - /usr/local/lib/sasl2/smtpd.conf: - pwcheck_method: saslauthd - mech_list: PLAIN LOGIN +These permissions are not enabled by default. - 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". +MMaaiill rreellaayy aauutthhoorriizzaattiioonn - 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. +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: - Note: The directory where saslauthd puts the socket is configurable. See - the command-line option "-m /path/to/socket" in the saslauthd --help - listing. + /etc/postfix/main.cf: + smtpd_recipient_restrictions = + ... + permit_mynetworks + ppeerrmmiitt__ssaassll__aauutthheennttiiccaatteedd + reject_unauth_destination + ... - * To authenticate against Cyrus SASL's own password database: +EEnnvveellooppee sseennddeerr aaddddrreessss aauutthhoorriizzaattiioonn - (Cyrus SASL version 1.5.x) +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. - /usr/local/lib/sasl/smtpd.conf: - pwcheck_method: sasldb +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: - (Cyrus SASL version 2.1.x) + /etc/postfix/main.cf: + ssmmttppdd__sseennddeerr__llooggiinn__mmaappss == hhaasshh:://eettcc//ppoossttffiixx//ccoonnttrroolllleedd__eennvveellooppee__sseennddeerrss - /usr/local/lib/sasl2/smtpd.conf: - pwcheck_method: auxprop - auxprop_plugin: sasldb - mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 + smtpd_recipient_restrictions = + ... + rreejjeecctt__sseennddeerr__llooggiinn__mmiissmmaattcchh + permit_sasl_authenticated + permit_mynetworks + reject_unauth_destination + ... - 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). +The controlled_envelope_senders table specifies the binding between the sender +envelope addresses and its their SASL login names: - IMPORTANT: To get sasldb running, make sure that you set the SASL domain - (realm) to a fully qualified domain name. + /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 - EXAMPLE: +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. - (Cyrus SASL version 1.5.x) +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. - % saslpasswd -c -u `postconf -h myhostname` exampleuser +AAddddiittiioonnaall SSMMTTPP SSeerrvveerr SSAASSLL ooppttiioonnss - (Cyrus SASL version 2.1.x) +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. - % saslpasswd2 -c -u `postconf -h myhostname` exampleuser +DDeeffaauulltt aauutthheennttiiccaattiioonn ddoommaaiinn - 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). +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": - 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 = example.com - /etc/postfix/main.cf: - smtpd_sasl_local_domain = $myhostname +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. -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. +HHiiddiinngg SSAASSLL aauutthheennttiiccaattiioonn ffrroomm cclliieennttss oorr nneettwwoorrkkss - * With older Cyrus SASL versions you remove the corresponding library files - from the SASL plug-in directory (and again whenever the system is updated). +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. - * 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: +Postfix can hide the AUTH capability from these clients/networks: - /usr/local/lib/sasl2/smtpd.conf: - mech_list: plain login + /etc/postfix/main.cf: + smtpd_sasl_exceptions_networks = !192.0.2.171/32, 192.0.2.0/24 -For the same reasons you might want to limit the list of plugins used for -authentication. +AAddddiinngg tthhee SSAASSLL llooggiinn nnaammee ttoo mmaaiill hheeaaddeerrss - * With Cyrus SASL version 1.5.x your only choice is to delete the - corresponding library files from the SASL plug-in directory. +To report SASL login names in Received: message headers (Postfix version 2.3 +and later): - * With SASL version 2.1.x: + /etc/postfix/main.cf: + smtpd_sasl_authenticated_header = yes - /usr/local/lib/sasl2/smtpd.conf: - pwcheck_method: auxprop - auxprop_plugin: sql + NNoottee -To run software chrooted with SASL support is an interesting exercise. It -probably is not worth the trouble. + The SASL login names will be shared with the entire world. -TTeessttiinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr +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 - . . . + % tteellnneett sseerrvveerr..eexxaammppllee..ccoomm 2255 + ... 220 server.example.com ESMTP Postfix EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm 250-server.example.com @@ -375,181 +891,421 @@ Information sent by the client (that is, you) is shown in bold font. AAUUTTHH PPLLAAIINN AAHHRRllcc33QQAAddGGVVzzddHHBBhhcc33MM== 235 Authentication successful -Instead of AHRlc3QAdGVzdHBhc3M=, specify the base64 encoded form of +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: + 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: - % printf '\0username\0password' | mmencode + % ggeenn--aauutthh ppllaaiinn + username: uusseerrnnaammee + password: - % perl -MMIME::Base64 -e \ - 'print encode_base64("\0username\0password");' +The ggeenn--aauutthh Perl script was written by John Jetmore and can be found at http:/ +/jetmore.org/john/code/gen-auth. -The mmencode command is part of the metamail software. MIME::Base64 is -available from http://www.cpan.org/. + % pprriinnttff ''\\00uusseerrnnaammee\\00ppaasssswwoorrdd'' || mmmmeennccooddee -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. +The mmmmeennccooddee command is part of the metamail software. -TTrroouubbllee sshhoooottiinngg tthhee SSAASSLL iinntteerrnnaallss + % ppeerrll --MMMMIIMMEE::::BBaassee6644 --ee \\ + ''pprriinntt eennccooddee__bbaassee6644((""\\00uusseerrnnaammee\\00ppaasssswwoorrdd""));;'' -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): +MIME::Base64 is available from http://www.cpan.org/. - % su postfix +CCoonnffiigguurriinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt -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 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. -EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP cclliieenntt + NNoottee -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 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 - 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 "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. + * 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. - * Postfix does not deliver mail via TCP port 465 (the obsolete "wrappermode" - protocol). See TLS_README for a solution that uses the "stunnel" command. + * In the relayhost setting, the "[" and "]" prevent the Postfix SMTP client + from looking up MX (mail exchanger) records for the enclosed name. - * 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 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 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. + * 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. - * 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". + * 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. - * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change - the sasl_passwd table. + * 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. -Workarounds: + /etc/postfix/sasl_passwd: + # destination credentials + [mail.isp.example] username:password + # Alternative form: + # [mail.isp.example]:submission username:password - * 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: + IImmppoorrttaanntt - /etc/postfix/main.cf: - smtp_sasl_security_options = noanonymous + 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. - * 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: + * Use the postmap command whenever you change the /etc/postfix/sasl_passwd + file. - /etc/postfix/main.cf: - smtp_sasl_mechanism_filter = !gssapi, !external, static:all + * If you specify the "[" and "]" in the relayhost destination, then you must + use the same form in the smtp_sasl_password_maps file. - In the above example, the Postfix SMTP client will decline to use - mechanisms that require special infrastructure such as Kerberos or TLS. + * 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 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. +CCoonnffiigguurriinngg SSeennddeerr--DDeeppeennddeenntt SSAASSLL aauutthheennttiiccaattiioonn -SSuuppppoorrttiinngg mmuullttiippllee IISSPP aaccccoouunnttss iinn tthhee PPoossttffiixx SSMMTTPP cclliieenntt +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. -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. +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 +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: + + % 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. + +NNoottee + + * 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. + + % 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 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/. + + IImmppoorrttaanntt + + 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: + + % ..//ccoonnffiigguurree ----eennaabbllee--llooggiinn ----eennaabbllee--nnttllmm + +BBuuiillddiinngg PPoossttffiixx wwiitthh CCyyrruuss 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 +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 + + % 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"" + +Cyrus SASL version 1.5.x + + % 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 the +ld.so run-time linker will not find the SASL shared library: + +Cyrus SASL version 2.1.x + + % 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"" + +Cyrus SASL version 1.5.x + + % 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"" + +UUssiinngg CCyyrruuss SSAASSLL vveerrssiioonn 11..55..xx + +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). + CCrreeddiittss * Postfix SASL support was originally implemented by Till Franke 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. + 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 - - /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 "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. + * 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. - * Postfix does not deliver mail via TCP port 465 (the obsolete "wrappermode" - protocol). See TLS_README for a solution that uses the "stunnel" command. + * In the relayhost setting, the "[" and "]" prevent the Postfix SMTP client + from looking up MX (mail exchanger) records for the enclosed name. - * 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 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 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. + * 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. - * 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". + * 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. - * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change - the sasl_passwd table. + * 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. -Workarounds: + /etc/postfix/sasl_passwd: + # destination credentials + [mail.isp.example] username:password + # Alternative form: + # [mail.isp.example]:submission username:password - * 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: + IImmppoorrttaanntt - /etc/postfix/main.cf: - smtp_sasl_security_options = noanonymous + 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. - * 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: + * Use the postmap command whenever you change the /etc/postfix/sasl_passwd + file. - /etc/postfix/main.cf: - smtp_sasl_mechanism_filter = !gssapi, !external, static:all + * If you specify the "[" and "]" in the relayhost destination, then you must + use the same form in the smtp_sasl_password_maps file. - In the above example, the Postfix SMTP client will decline to use - mechanisms that require special infrastructure such as Kerberos or TLS. + * 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 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. +CCoonnffiigguurriinngg SSeennddeerr--DDeeppeennddeenntt SSAASSLL aauutthheennttiiccaattiioonn -SSuuppppoorrttiinngg mmuullttiippllee IISSPP aaccccoouunnttss iinn tthhee PPoossttffiixx SSMMTTPP cclliieenntt +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. -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     		- Postfix
    verify
    server     -
    Internet -> + + Postfix
    SMTP
    server         		<-> + <-> Address
    - verification
    database     		+ Postfix
    verify
    server     +
        |
    + v     		|
    - probe
    messages
    v
    ^
    delivery
    - status
    |     		<- + probe
    + status     		<- + + Postfix
    delivery
    agents     		-> + 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,803 +15,2116 @@
    -

    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

    + +

    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.

    + +

    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.

    + +

    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.

    + +

    You can read more about the following topics:

    -

    How Postfix uses SASL authentication information

    +
    • -

    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: -

    +
  • Enabling SASL authentication and +authorization in the Postfix SMTP server -
    -
    -% postconf -a (SASL support in the SMTP server)
-% postconf -A (SASL support in the SMTP+LMTP client)
-
    -
    +
    • -
    -
    -% make makefiles CCARGS='-DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\"'
-
    -
    +
  • Testing SASL authentication in the Postfix +SMTP server
    • + + -

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

    -

    Notes:

    +

    Which SASL Implementations are supported?

    - +

    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.

    -

    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:

    +

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

    -ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/
+% postconf -a (SASL support in the SMTP server)
+% postconf -A (SASL support in the SMTP+LMTP client)
    -

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

    +

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

    -

    Building Postfix with Cyrus SASL support

    +

    Configuring Dovecot SASL

    -

    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.

    +

    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.

    -

    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.

    +

    Postfix to Dovecot SASL communication

    -

    On some systems this generates the necessary Makefile definitions: +

    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.

    -
    - -
    (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"
-
    +

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

    -
    (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"
+ 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.

    -

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

    +

    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

    -
    (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"
-
    +

    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.

    -
    (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"
-
    +

    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

    -

    Enabling SASL authentication in the Postfix -SMTP server

    +

    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.

    -

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

    +

    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:
-    smtpd_sasl_auth_enable = yes
-
    -
    - -

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

    + # Postfix 2.3 and later + smtpd_sasl_path = smtpd -
    -
    -/etc/postfix/main.cf:
-    smtpd_recipient_restrictions = 
-        permit_mynetworks 
-        permit_sasl_authenticated 
-        reject_unauth_destination
+    # Postfix < 2.3
+    smtpd_sasl_application_name = smtpd
    -

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

    +

    Cyrus SASL configuration file +location

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

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

    -

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

    +

    You can read more about the following topics:

    -

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

    +Note + +

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

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

    +

    Postfix to Cyrus SASL communication

    -

    Cyrus SASL configuration for the Postfix -SMTP server

    +

    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.

    -

    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 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 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:

    +

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

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

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

    saslauthd - Cyrus SASL password verification service

    -

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

    +

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

    - +
    -

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

    +Important -

    Testing SASL authentication in the Postfix -SMTP server

    +

    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.

    -

    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
-250-server.example.com
-250-PIPELINING
-250-SIZE 10240000
-250-ETRN
-250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
-250 8BITMIME
-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'. -

    +Important -

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

    +

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

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

    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.

    +
    -
    -% perl -MMIME::Base64 -e \
-    'print encode_base64("\0username\0password");'
-
    + +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.

    +
    -

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

    +

    Using saslauthd with /etc/shadow

    -

    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.

    +

    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.

    -

    Trouble shooting the SASL internals

    +

    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.

    -

    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):

    +

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

    -% su postfix
+% saslauthd -a shadow
    -

    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.

    +

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

    -

    Enabling SASL authentication in the -Postfix SMTP client

    +

    Using saslauthd with PAM

    -

    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.

    +

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

    -/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
+% saslauthd -a pam
    -

    Notes:

    - - + -

    Workarounds:

    +

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

    - +

    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.

    -

    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.

    +

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

    -
    -
    -/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
+
    Testing saslauthd authentication
    
 
-/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
+
     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: 
    
 
-/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]
+
    
+
    +% testsaslauthd -u username -p password
+0: OK "Success."
 
    
 
    
 
-
     Notes: 
    
+
    
 
-
      
+Note
 
-
    •  
       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. 
      
+
       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 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. 
    
+
     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. 
    
 
-
  •  
     Execute the command "postmap /etc/postfix/sender_relay"
-whenever you change the sender_relay table. 
    
+
     If authentication succeeds, proceed with the section "Enabling SASL authentication and authorization
+in the Postfix SMTP server". 
    
 
-
+
    Cyrus SASL Plugins - auxiliary property
+plugins
    
 
-
    Credits
    
+
     Cyrus SASL uses a plugin infrastructure (called auxprop)
+to expand libsasl's capabilities.  Currently Cyrus
+SASL sources provide three authentication plugins. 
    
 
-
      
+
      
 
-
    •  Postfix SASL support was originally implemented by Till Franke
-of SuSE Rhein/Main AG.
+
      
 
-
    •  Wietse trimmed down the code to only the bare necessities.
+
      sasldb
      
 
-
    •  Support for Cyrus SASL version 2 was contributed by Jason Hoos.
+
       
       Accounts are stored stored in a Cyrus SASL Berkeley DB
+database 
       
      
 
-
    •  Liviu Daia added smtpd_sasl_application_name, split
-reject_sender_login_mismatch into
-reject_authenticated_sender_login_mismatch and
-reject_unauthenticated_sender_login_mismatch, and revised the docs.
+
      sql
      
 
-
    •  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.
+
       
       Accounts are stored in a SQL database 
       
      
 
-
    •  The Dovecot SMTP server-only plug-in was originally implemented by
-Timo Sirainen of Procontrol, Finland.
+
      ldapdb
      
 
-
    •  Patrick Ben Koetter revised this document for Postfix 2.4 and
-made much needed updates.
+
       
       Accounts are stored stored in an LDAP database 
       
      
 
-
    
+
 
-
+
    • + +
    + +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:

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

    + +
    + +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!

    + +
    + +
    + +
    + +
    + +

    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:

    + +
    +
    +/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:

    + +
    +
    +% 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
+...
+
    +
    + +

    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
+
    +
    + +
    + +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:
+    # Specify a list of properties separated by comma or whitespace
+    smtpd_sasl_security_options = noanonymous
+
    +
    + +
    + +Important + +

    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.

    + +
    + +
    + +

    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:
+    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
+
    +
    + +

    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:

    + + + +

    These permissions are not enabled by default.

    + +

    Mail relay authorization

    + +

    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
+    permit_sasl_authenticated
+    reject_unauth_destination
+    ...
+
    +
    + +

    Envelope sender address authorization

    + +

    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:
+    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
+        ...
+
    +
    + +

    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.

    + +

    Additional SMTP Server SASL options

    + +

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

    + +
    +
    +/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
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-ETRN
+250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+250 8BITMIME
+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'.

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

    + +
    + +

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

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

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

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

    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
+    relayhost = [mail.isp.example]
+    # Alternative form:
+    # relayhost = [mail.isp.example]:submission
+    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+
    +
    + + + +
    +
    +/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.

    + +
    + + + +

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

    + +

    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]
+
    +
    + + + +

    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:

    - -

    Workarounds:

    - - 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,803 +15,2116 @@
    -

    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

    + +

    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.

    + +

    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.

    + +

    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.

    + +

    You can read more about the following topics:

    -

    How Postfix uses SASL authentication information

    + -

    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: -

    +
  • Enabling SASL authentication and +authorization in the Postfix SMTP server -
    -
    -% postconf -a (SASL support in the SMTP server)
-% postconf -A (SASL support in the SMTP+LMTP client)
-
    -
    +
    • -
    -
    -% make makefiles CCARGS='-DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\"'
-
    -
    +
  • Testing SASL authentication in the Postfix +SMTP server
    • + + -

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

    -

    Notes:

    +

    Which SASL Implementations are supported?

    - +

    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.

    -

    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:

    +

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

    -ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/
+% postconf -a (SASL support in the SMTP server)
+% postconf -A (SASL support in the SMTP+LMTP client)
    -

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

    +

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

    -

    Building Postfix with Cyrus SASL support

    +

    Configuring Dovecot SASL

    -

    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.

    +

    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.

    -

    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.

    +

    Postfix to Dovecot SASL communication

    -

    On some systems this generates the necessary Makefile definitions: +

    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.

    -
    - -
    (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"
-
    +

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

    -
    (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"
+ 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.

    -

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

    +

    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

    -
    (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"
-
    +

    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.

    -
    (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"
-
    +

    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

    -

    Enabling SASL authentication in the Postfix -SMTP server

    +

    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.

    -

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

    +

    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:
-    smtpd_sasl_auth_enable = yes
-
    -
    - -

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

    + # Postfix 2.3 and later + smtpd_sasl_path = smtpd -
    -
    -/etc/postfix/main.cf:
-    smtpd_recipient_restrictions = 
-        permit_mynetworks 
-        permit_sasl_authenticated 
-        reject_unauth_destination
+    # Postfix < 2.3
+    smtpd_sasl_application_name = smtpd
    -

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

    +

    Cyrus SASL configuration file +location

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

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

    -

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

    +

    You can read more about the following topics:

    -

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

    +Note + +

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

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

    +

    Postfix to Cyrus SASL communication

    -

    Cyrus SASL configuration for the Postfix -SMTP server

    +

    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.

    -

    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 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 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:

    +

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

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

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

    saslauthd - Cyrus SASL password verification service

    -

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

    +

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

    - +
    -

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

    +Important -

    Testing SASL authentication in the Postfix -SMTP server

    +

    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.

    -

    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
-250-server.example.com
-250-PIPELINING
-250-SIZE 10240000
-250-ETRN
-250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
-250 8BITMIME
-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'. -

    +Important -

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

    +

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

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

    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.

    +
    -
    -% perl -MMIME::Base64 -e \
-    'print encode_base64("\0username\0password");'
-
    + +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.

    +
    -

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

    +

    Using saslauthd with /etc/shadow

    -

    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.

    +

    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.

    -

    Trouble shooting the SASL internals

    +

    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.

    -

    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):

    +

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

    -% su postfix
+% saslauthd -a shadow
    -

    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.

    +

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

    -

    Enabling SASL authentication in the -Postfix SMTP client

    +

    Using saslauthd with PAM

    -

    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.

    +

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

    -/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
+% saslauthd -a pam
    -

    Notes:

    - - + -

    Workarounds:

    +

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

    - +

    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.

    -

    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.

    +

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

    -
    -
    -/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
+
    Testing saslauthd authentication
    
 
-/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
+
     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: 
    
 
-/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]
+
    
+
    +% testsaslauthd -u username -p password
+0: OK "Success."
 
    
 
    
 
-
     Notes: 
    
+
    
 
-
      
+Note
 
-
    •  
       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. 
      
+
       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 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. 
    
+
     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. 
    
 
-
  •  
     Execute the command "postmap /etc/postfix/sender_relay"
-whenever you change the sender_relay table. 
    
+
     If authentication succeeds, proceed with the section "Enabling SASL authentication and authorization
+in the Postfix SMTP server". 
    
 
-
+
    Cyrus SASL Plugins - auxiliary property
+plugins
    
 
-
    Credits
    
+
     Cyrus SASL uses a plugin infrastructure (called auxprop)
+to expand libsasl's capabilities.  Currently Cyrus
+SASL sources provide three authentication plugins. 
    
 
-
      
+
      
 
-
    •  Postfix SASL support was originally implemented by Till Franke
-of SuSE Rhein/Main AG.
+
      
 
-
    •  Wietse trimmed down the code to only the bare necessities.
+
      sasldb
      
 
-
    •  Support for Cyrus SASL version 2 was contributed by Jason Hoos.
+
       
       Accounts are stored stored in a Cyrus SASL Berkeley DB
+database 
       
      
 
-
    •  Liviu Daia added smtpd_sasl_application_name, split
-reject_sender_login_mismatch into
-reject_authenticated_sender_login_mismatch and
-reject_unauthenticated_sender_login_mismatch, and revised the docs.
+
      sql
      
 
-
    •  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.
+
       
       Accounts are stored in a SQL database 
       
      
 
-
    •  The Dovecot SMTP server-only plug-in was originally implemented by
-Timo Sirainen of Procontrol, Finland.
+
      ldapdb
      
 
-
    •  Patrick Ben Koetter revised this document for Postfix 2.4 and
-made much needed updates.
+
       
       Accounts are stored stored in an LDAP database 
       
      
 
-
    
+
+
+
    • + +
    + +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:

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

    + +
    + +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!

    + +
    + +
    + +
    + +
    + +

    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:

    + +
    +
    +/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:

    + +
    +
    +% 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
+...
+
    +
    + +

    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
+
    +
    + +
    + +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:
+    # Specify a list of properties separated by comma or whitespace
+    smtpd_sasl_security_options = noanonymous
+
    +
    + +
    + +Important + +

    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.

    + +
    + +
    + +

    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:
+    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
+
    +
    + +

    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:

    + + + +

    These permissions are not enabled by default.

    + +

    Mail relay authorization

    + +

    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
+    permit_sasl_authenticated
+    reject_unauth_destination
+    ...
+
    +
    + +

    Envelope sender address authorization

    + +

    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:
+    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
+        ...
+
    +
    + +

    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.

    + +

    Additional SMTP Server SASL options

    + +

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

    + +
    +
    +/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
+250-server.example.com
+250-PIPELINING
+250-SIZE 10240000
+250-ETRN
+250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+250 8BITMIME
+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'.

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

    + +
    + +

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

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

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

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

    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
+    relayhost = [mail.isp.example]
+    # Alternative form:
+    # relayhost = [mail.isp.example]:submission
+    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+
    +
    + + + +
    +
    +/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.

    + +
    + + + +

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

    + +

    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]
+
    +
    + + + +

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