From: Wietse Venema and
in examples;
+ instead of emphasizing new Postfix 2.5 behavior in reference
+ documentation, describe the new behavior as "current", with
+ historical behavior as a supplemental note.
+
+20080107
+
+ Feature: new "pass" service type (in addition to "inet",
+ "unix" and "fifo"). The "pass" service type supports
+ front-end daemons that accept all inbound connections and
+ that permit only well-behaved clients to talk to the MTA.
+ This service type had been sitting in the master daemon for
+ years but was disabled by default. Actual applications for
+ this will have to be developed later. Files: util/upass_connect.c,
+ util/upass_trigger.c.
+
+20080108
+
+ Cleanup: where possible, store data structures in read-only
+ memory. Besides the security advantage of no write access,
+ this also gives slightly better memory utilization when
+ many processes execute the same file. Files: pretty much
+ everything that has a static table, except for a few tables
+ in the benchmark tools with flags that are controlled by
+ command-line information.
+
+20080109
- Feature (experimental release only): new "pass" service
- type (in addition to "inet", "unix" and "fifo"). The "pass"
- service type supports front-end daemons that accept all
- inbound connections and that permit only well-behaved clients
- to talk to the MTA. This service type had been sitting in
- the master daemon for years but was disabled by default.
- Files: util/upass_connect.c, util/upass_trigger.c.
+ Cleanup: more read-only data. Files: everything that passes
+ around a HEADER_OPTS pointer.
diff --git a/postfix/README_FILES/STRESS_README b/postfix/README_FILES/STRESS_README
index bcd5ffc83..dbdd3171f 100644
--- a/postfix/README_FILES/STRESS_README
+++ b/postfix/README_FILES/STRESS_README
@@ -8,8 +8,8 @@ This document describes the symptoms of Postfix SMTP server overload, and how
to avoid the condition under normal conditions. When the condition is caused by
botnets or other malware, the document suggests configuration settings that
help to minimize the impact on legitimate mail. Finally, the document
-introduces Postfix stress-adaptive behavior, and how it can be used to
-automatically switch configuration settings under overload.
+introduces stress-adaptive behavior, introduced with Postfix 2.5, and how it
+can be used to automatically switch configuration settings under overload.
Topics covered in this document:
@@ -26,27 +26,17 @@ Topics covered in this document:
SSyymmppttoommss ooff PPoossttffiixx SSMMTTPP sseerrvveerr oovveerrllooaadd
Under normal conditions, Postfix responds immediately when a remote SMTP client
-connects. The time needed to deliver mail to Postfix may depend on how busy the
-CPU or disk are, but that should be noticeable only with very large messages.
-Performance degrades more dramatically when the number of remote SMTP clients
-exceeds the number of Postfix SMTP server processes. When a client connects
-while all server processes are busy, the client must wait until a server
-process becomes available.
+connects. The time needed to deliver mail should be noticeable only with very
+large messages. Performance degrades more dramatically when the number of
+remote SMTP clients exceeds the number of Postfix SMTP server processes. When a
+client connects while all server processes are busy, the client must wait until
+a server process becomes available.
Overload may be caused by a legitimate mail (example: a DNS registrar opens a
new zone for registrations), by mistake (mail explosion caused by a forwarding
loop) or by illegitimate mail (worm outbreak, botnet, or other malware
activity). Symptoms of Postfix SMTP mail server overload are:
- * Postfix logs a warning that all server ports are busy:
-
- Oct 3 20:39:27 spike postfix/master[28905]: warning: service "smtp"
- (25) has reached its process limit "30": new clients may experience
- noticeable delays
- Oct 3 20:39:27 spike postfix/master[28905]: warning: to avoid this
- condition, increase the process count in master.cf or reduce the
- service time per client
-
* Remote SMTP clients experience a long delay before Postfix sends the "220
hostname.example.com ESMTP Postfix" greeting. If this affects end-user mail
clients, enable the "submission" service entry in master.cf (present since
@@ -57,7 +47,16 @@ activity). Symptoms of Postfix SMTP mail server overload are:
CONNECT" events. This happens because remote SMTP clients disconnect before
Postfix answers the connection.
-NOTE: The last two symptoms also happen without overload.
+ * Postfix 2.3 and later logs a warning that all server ports are busy:
+
+ Oct 3 20:39:27 spike postfix/master[28905]: warning: service "smtp"
+ (25) has reached its process limit "30": new clients may experience
+ noticeable delays
+ Oct 3 20:39:27 spike postfix/master[28905]: warning: to avoid this
+ condition, increase the process count in master.cf or reduce the
+ service time per client
+
+NOTE: The first two symptoms may also happen without overload, for example:
* Broken DNS also causes lengthy delays before "220 hostname.example.com ..."
while the Postfix SMTP server tries to look up the client's hostname.
diff --git a/postfix/README_FILES/TLS_README b/postfix/README_FILES/TLS_README
index 7c5011927..e11a09668 100644
--- a/postfix/README_FILES/TLS_README
+++ b/postfix/README_FILES/TLS_README
@@ -5,10 +5,10 @@ PPoossttffiixx TTLLSS SSuuppppoorrtt
WWAARRNNIINNGG
By turning on TLS support in Postfix, you not only get the ability to encrypt
-mail and to authenticate clients or servers. You also turn on thousands and
-thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as
-carefully as Wietse's own code, every 1000 lines introduce one additional bug
-into Postfix.
+mail and to authenticate remote SMTP clients or servers. You also turn on
+thousands and thousands of lines of OpenSSL library code. Assuming that OpenSSL
+is written as carefully as Wietse's own code, every 1000 lines introduce one
+additional bug into Postfix.
WWhhaatt PPoossttffiixx TTLLSS ssuuppppoorrtt ddooeess ffoorr yyoouu
@@ -126,7 +126,7 @@ SSeerrvveerr--ssiiddee cceerrttiiffiiccaattee aanndd p
In order to use TLS, the Postfix SMTP server generally needs a certificate and
a private key. Both must be in "PEM" format. The private key must not be
-encrypted, meaning: the key must be accessible without password. Both
+encrypted, meaning: the key must be accessible without a password. The
certificate and private key may be in the same file, in which case the
certificate file should be owned by "root" and not be readable by any other
user. If the key is stored separately, this applies to the key file only, and
@@ -134,19 +134,20 @@ the certificate file may be "world-readable".
Public Internet MX hosts without certificates signed by a "reputable" CA must
generate, and be prepared to present to most clients, a self-signed or private-
-CA signed certificate. The client will not be able to authenticate the server,
-but unless it is running Postfix 2.3 or similar software, it will still insist
-on a server certificate.
+CA signed certificate. The remote SMTP client will generally not be able to
+authenticate the self-signed certificate, but unless the client is running
+Postfix 2.3 or similar software, it will still insist on a server certificate.
-For servers that are nnoott public Internet MX hosts, Postfix 2.3 supports
+For servers that are nnoott public Internet MX hosts, Postfix supports
configurations with no certificates. This entails the use of just the anonymous
TLS ciphers, which are not supported by typical SMTP clients. Since such
clients will not, as a rule, fall back to plain text after a TLS handshake
-failure, the server will be unable to receive email from most TLS enabled
-clients. To avoid accidental configurations with no certificates, Postfix 2.3
-enables certificate-less operation only when the administrator explicitly sets
-"smtpd_tls_cert_file = none". This ensures that new Postfix configurations will
-not accidentally run with no certificates.
+failure, a certificate-less Postfix SMTP server will be unable to receive email
+from most TLS enabled clients. To avoid accidental configurations with no
+certificates, Postfix enables certificate-less operation only when the
+administrator explicitly sets "smtpd_tls_cert_file = none". This ensures that
+new Postfix SMTP server configurations will not accidentally run with no
+certificates.
Both RSA and DSA certificates are supported. Typically you will only have RSA
certificates issued by a commercial CA. In addition, the tools supplied with
@@ -160,9 +161,9 @@ the CA certificate (in case of a certificate chain, all CA certificates) must
be available. You should add any intermediate CA certificates to the server
certificate: the server certificate first, then the intermediate CA(s).
-Example: the certificate for "server.dom.ain" was issued by "intermediate CA"
-which itself has a certificate issued by "root CA". Create the server.pem file
-with:
+Example: the certificate for "server.example.com" was issued by "intermediate
+CA" which itself has a certificate issued by "root CA". Create the server.pem
+file with:
% ccaatt sseerrvveerr__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> sseerrvveerr..ppeemm
@@ -175,14 +176,7 @@ of the "server.pem" file reduces the overhead of the TLS exchange.
If you want the Postfix SMTP server to accept remote SMTP client certificates
issued by these CAs, append the root certificate to $smtpd_tls_CAfile or
-install it in the $smtpd_tls_CApath directory. When you configure trust in a
-root CA, it is not necessary to explicitly trust intermediary CAs signed by the
-root CA, unless $smtpd_tls_ccert_verifydepth is less than the number of CAs in
-the certificate chain for the clients of interest. With a verify depth of 1 you
-can only verify certificates directly signed by a trusted CA, and all trusted
-intermediary CAs need to be configured explicitly. With a verify depth of 2 you
-can verify clients signed by a root CA or a direct intermediary CA (so long as
-the client is correctly configured to supply its intermediate CA certificate).
+install it in the $smtpd_tls_CApath directory.
RSA key and certificate examples:
@@ -220,14 +214,14 @@ files in the directory when the information is needed. Thus, the
$smtpd_tls_CApath directory needs to be accessible inside the optional chroot
jail.
-When you configure Postfix to request client certificates, any CA certificates
-in $smtpd_tls_CAfile are sent to the client, in order to allow it to choose an
-identity signed by a CA you trust. If no $smtpd_tls_CAfile is specified, no
-preferred CA list is sent, and the client is free to choose an identity signed
-by any CA. Many clients use a fixed identity regardless of the preferred CA
-list and you may be able to reduce TLS negotiation overhead by installing
-client CA certificates mostly or only in $smtpd_tls_CApath. In the latter case
-you need not specify a $smtpd_tls_CAfile.
+When you configure the Postfix SMTP server to request client certificates, any
+CA certificates in $smtpd_tls_CAfile are sent to the client, in order to allow
+it to choose an identity signed by a CA you trust. If no $smtpd_tls_CAfile is
+specified, no preferred CA list is sent, and the client is free to choose an
+identity signed by any CA. Many clients use a fixed identity regardless of the
+preferred CA list and you may be able to reduce TLS negotiation overhead by
+installing client CA certificates mostly or only in $smtpd_tls_CApath. In the
+latter case you need not specify a $smtpd_tls_CAfile.
Note, that unless client certificates are used to allow greater access to TLS
authenticated clients, it is best to not ask for client certificates at all, as
@@ -292,12 +286,12 @@ Example:
# Obsolete, but still supported
smtpd_use_tls = yes
-With this, Postfix SMTP server announces STARTTLS support to SMTP clients, but
-does not require that clients use TLS encryption.
+With this, the Postfix SMTP server announces STARTTLS support to remote SMTP
+clients, but does not require that clients use TLS encryption.
Note: when an unprivileged user invokes "sendmail -bs", STARTTLS is never
-offered due to insufficient privileges to access the server private key. This
-is intended behavior.
+offered due to insufficient privileges to access the Postfix SMTP server
+private key. This is intended behavior.
You can ENFORCE the use of TLS, so that the Postfix SMTP server announces
STARTTLS and accepts no mail without TLS encryption, by setting
@@ -315,10 +309,10 @@ Example:
smtpd_enforce_tls = yes
TLS is sometimes used in the non-standard "wrapper" mode where a server always
-uses TLS, instead of announcing STARTTLS support and waiting for clients to
-request TLS service. Some clients, namely Outlook [Express] prefer the
-"wrapper" mode. This is true for OE (Win32 < 5.0 and Win32 >=5.0 when run on a
-port<>25 and OE (5.01 Mac on all ports).
+uses TLS, instead of announcing STARTTLS support and waiting for remote SMTP
+clients to request TLS service. Some clients, namely Outlook [Express] prefer
+the "wrapper" mode. This is true for OE (Win32 < 5.0 and Win32 >=5.0 when run
+on a port<>25 and OE (5.01 Mac on all ports).
It is strictly discouraged to use this mode from main.cf. If you want to
support this service, enable a special port in master.cf and specify "-
@@ -344,8 +338,8 @@ session. So this option is "off" by default. You will however need the
certificate if you want to use certificate based relaying with, for example,
the permit_tls_clientcerts feature. A server that wants client certificates
must first present its own certificate. While Postfix 2.3 by default offers
-anonymous ciphers to clients, these are automatically suppressed when the
-server is configured to ask for client certificates.
+anonymous ciphers to remote SMTP clients, these are automatically suppressed
+when the Postfix SMTP server is configured to ask for client certificates.
Example:
@@ -370,15 +364,22 @@ Example:
# Obsolete, but still supported
smtpd_enforce_tls = yes
-A client certificate verification depth of 1 is sufficient if the certificate
-is directly issued by a CA listed in the CA file. The default value (5) should
-also suffice for longer chains (root CA issues special CA which then issues the
-actual certificate...)
+The client certificate verification depth is specified with the main.cf
+smtpd_tls_ccert_verifydepth parameter. The default verification depth is 9 (the
+OpenSSL default), for compatibility with Postfix versions before 2.5 where
+smtpd_tls_ccert_verifydepth was ignored. When you configure trust in a root CA,
+it is not necessary to explicitly trust intermediary CAs signed by the root CA,
+unless $smtpd_tls_ccert_verifydepth is less than the number of CAs in the
+certificate chain for the clients of interest. With a verify depth of 1 you can
+only verify certificates directly signed by a trusted CA, and all trusted
+intermediary CAs need to be configured explicitly. With a verify depth of 2 you
+can verify clients signed by a root CA or a direct intermediary CA (so long as
+the client is correctly configured to supply its intermediate CA certificate).
Example:
/etc/postfix/main.cf:
- smtpd_tls_ccert_verifydepth = 5
+ smtpd_tls_ccert_verifydepth = 2
SSuuppppoorrttiinngg AAUUTTHH oovveerr TTLLSS oonnllyy
@@ -448,17 +449,22 @@ Postfix TLS support introduces three additional features for Postfix SMTP
server access control:
permit_tls_clientcerts
- Allow the remote SMTP client SMTP request if the client certificate
- passes verification, and if its fingerprint is listed in the list of
- client certificates (see relay_clientcerts discussion below).
+ Allow the remote SMTP client request if the client certificate
+ fingerprint is listed in the client certificate table (see
+ relay_clientcerts discussion below).
permit_tls_all_clientcerts
- Allow the remote client SMTP request if the client certificate passes
- verification.
+ Allow the remote SMTP client request if the client certificate passes
+ trust chain verification. Useful with private-label CAs that only issue
+ certificates to trusted clients (and not otherwise).
check_ccert_access type:table
- If the client certificate passes verification, use its fingerprint as a
- key for the specified access(5) table.
+ Use the remote SMTP client certificate fingerprint as the lookup key
+ for the specified access(5) table.
+
+The digest algorithm used to construct the client certificate fingerprints is
+specified with the main.cf smtpd_tls_fingerprint_digest parameter. The default
+is "md5", for compatibility with Postfix versions < 2.5.
The permit_tls_all_clientcerts feature must be used with caution, because it
can result in too many access permissions. Use this feature only if a special
@@ -481,14 +487,9 @@ Example:
reject_unauth_destination
...
-The Postfix list manipulation routines give special treatment to whitespace and
-some other characters, making the use of certificate names impractical. Instead
-we use the certificate fingerprints as they are difficult to fake but easy to
-use for lookup. Postfix lookup tables are in the form of (key, value) pairs.
-Since we only need the key, the value can be chosen freely, e.g. the name of
-the user or host.
-
-Example:
+Example: Postfix lookup tables are in the form of (key, value) pairs. Since we
+only need the key, the value can be chosen freely, e.g. the name of the user or
+host:
/etc/postfix/main.cf:
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
@@ -532,23 +533,24 @@ Example: (MSA that requires TLS with high grade ciphers)
smtpd_tls_key_file = /etc/postfix/key.pem
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
- # Postfix 2.3 and later
smtpd_tls_security_level = encrypt
- # Obsolete, but still supported
- smtpd_enforce_tls = yes
-
-If you want to take advantage of ciphers with EDH, DH parameters are needed.
-Instead of using the built-in DH parameters for both 1024bit and 512bit, it is
-better to generate your own parameters, since otherwise it would "pay" for a
-possible attacker to start a brute force attack against parameters that are
-used by everybody. For this reason, the default parameters chosen by OpenSSL
-are already different from those distributed with other TLS packages.
+ smtpd_tls_mandatory_protocols = TLSv1
+ # Also available with Postfix >= 2.5:
+ smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
+
+If you want to take advantage of ciphers with ephemeral Diffie-Hellman (EDH)
+key exchange (this offers "forward-secrecy"), DH parameters are needed. Instead
+of using the built-in DH parameters for both 1024-bit (non-export ciphers) and
+512-bit (export ciphers), it is better to generate your own parameters, since
+otherwise it would "pay" for a possible attacker to start a brute force attack
+against parameters that are used by everybody. Postfix defaults to compiled-in
+parameters that are shared by all Postfix users who don't generate their own
+settings.
To generate your own set of DH parameters, use:
- % ooppeennssssll ggeennddhh --oouutt //eettcc//ppoossttffiixx//ddhh__11002244..ppeemm --22 --rraanndd //vvaarr//rruunn//eeggdd--ppooooll
- 11002244
- % ooppeennssssll ggeennddhh --oouutt //eettcc//ppoossttffiixx//ddhh__551122..ppeemm --22 --rraanndd //vvaarr//rruunn//eeggdd--ppooooll 551122
+ % ooppeennssssll ggeennddhh --oouutt //eettcc//ppoossttffiixx//ddhh__551122..ppeemm --22 551122
+ % ooppeennssssll ggeennddhh --oouutt //eettcc//ppoossttffiixx//ddhh__11002244..ppeemm --22 11002244
Examples:
@@ -579,6 +581,7 @@ Topics covered in this section:
* Disabling TLS in the SMTP/LMTP client
* Enabling TLS in the SMTP/LMTP client
* Mandating TLS encryption
+ * Certificate fingerprint verification
* Mandating server certificate verification
* Secure server certificate verification
* Per-destination TLS policy
@@ -592,29 +595,27 @@ Topics covered in this section:
TTLLSS ssuuppppoorrtt iinn tthhee LLMMTTPP ddeelliivveerryy aaggeenntt
-In Postfix 2.3, the smtp(8) and lmtp(8) delivery agents have been merged into a
-single dual-purpose program. As a result the lmtp(8) delivery agent is no
-longer the poor cousin of the more extensively used smtp(8). Specifically, as
-of Postfix 2.3, all the TLS features described below apply equally to SMTP and
-LMTP, after replacing the "smtp_" prefix of the each parameter name with
-"lmtp_".
-
-The LMTP delivery agent can communicate with LMTP servers listening on UNIX-
-domain sockets. When server certificate verification is enabled and the server
-is listening on a UNIX-domain socket, the $myhostname parameter is used to set
-the TLS verification nexthop and hostname. Note, opportunistic encryption of
-LMTP traffic over UNIX-domain sockets is futile. TLS is only useful in this
-context when it is mandatory, typically to allow at least one of the server or
-the client to authenticate the other. The "null" cipher grade may be
-appropriate in this context, when available on both client and server. The
+The smtp(8) and lmtp(8) delivery agents are implemented by a single dual-
+purpose program. Specifically, all the TLS features described below apply
+equally to SMTP and LMTP, after replacing the "smtp_" prefix of the each
+parameter name with "lmtp_".
+
+The Postfix LMTP delivery agent can communicate with LMTP servers listening on
+UNIX-domain sockets. When server certificate verification is enabled and the
+server is listening on a UNIX-domain socket, the $myhostname parameter is used
+to set the TLS verification nexthop and hostname. Note, opportunistic
+encryption of LMTP traffic over UNIX-domain sockets is futile. TLS is only
+useful in this context when it is mandatory, typically to allow at least one of
+the server or the client to authenticate the other. The "null" cipher grade may
+be appropriate in this context, when available on both client and server. The
"null" ciphers provide authentication without encryption.
CClliieenntt--ssiiddee cceerrttiiffiiccaattee aanndd pprriivvaattee kkeeyy ccoonnffiigguurraattiioonn
-Do not configure client certificates unless you mmuusstt present client TLS
-certificates to one or more servers. Client certificates are not usually
-needed, and can cause problems in configurations that work well without them.
-The recommended setting is to let the defaults stand:
+Do not configure Postfix SMTP client certificates unless you mmuusstt present
+client TLS certificates to one or more servers. Client certificates are not
+usually needed, and can cause problems in configurations that work well without
+them. The recommended setting is to let the defaults stand:
smtp_tls_cert_file =
smtp_tls_dcert_file =
@@ -661,14 +662,7 @@ of the "client.pem" file reduces the overhead of the TLS exchange.
If you want the Postfix SMTP client to accept remote SMTP server certificates
issued by these CAs, append the root certificate to $smtp_tls_CAfile or install
-it in the $smtp_tls_CApath directory. When you configure trust in a root CA, it
-is not necessary to explicitly trust intermediary CAs signed by the root CA,
-unless $smtp_tls_scert_verifydepth is less than the number of CAs in the
-certificate chain for the servers of interest. With a verify depth of 1 you can
-only verify certificates directly signed by a trusted CA, and all trusted
-intermediary CAs need to be configured explicitly. With a verify depth of 2 you
-can verify servers signed by a root CA or a direct intermediary CA (so long as
-the server is correctly configured to supply its intermediate CA certificate).
+it in the $smtp_tls_CApath directory.
RSA key and certificate examples:
@@ -860,6 +854,8 @@ mmaayy
Opportunistic TLS.
eennccrryypptt
Mandatory TLS encryption.
+ffiinnggeerrpprriinntt
+ Certificate fingerprint verification.
vveerriiffyy
Mandatory server certificate verification.
sseeccuurree
@@ -941,11 +937,11 @@ MMaannddaattoorryy TTLLSS eennccrryyppttiioonn
At the "encrypt" TLS security level, messages are sent only over TLS encrypted
sessions. The SMTP transaction is aborted unless the STARTTLS ESMTP feature is
-supported by the server. If no suitable servers are found, the message will be
-deferred. With Postfix 2.3 and later, mandatory TLS encryption can be
-configured by setting "smtp_tls_security_level = encrypt". Even though TLS
-encryption is always used, mail delivery continues if the server certificate is
-untrusted or bears the wrong name.
+supported by the remote SMTP server. If no suitable servers are found, the
+message will be deferred. With Postfix 2.3 and later, mandatory TLS encryption
+can be configured by setting "smtp_tls_security_level = encrypt". Even though
+TLS encryption is always used, mail delivery continues even if the server
+certificate is untrusted or bears the wrong name.
At this security level and higher, the smtp_tls_mandatory_protocols and
smtp_tls_mandatory_ciphers configuration parameters determine the list of
@@ -1039,16 +1035,68 @@ table; use the new policy table instead.
/etc/postfix/tls_per_site:
[example.net]:587 MUST_NOPEERMATCH
+CCeerrttiiffiiccaattee ffiinnggeerrpprriinntt vveerriiffiiccaattiioonn
+
+Certificate fingerprint verification is available with Postfix 2.5 and later.
+At this security level ("smtp_tls_security_level = fingerprint"), no trusted
+certificate authorities are used or required. The certificate trust chain,
+expiration date, ... are not checked. Instead, the
+smtp_tls_fingerprint_cert_match parameter or the "match" attribute in the
+policy table lists the valid "fingerprints" of the remote SMTP server
+certificate.
+
+If certificate fingerprints are exchanged securely, this is the strongest, and
+least scalable security level. The administrator needs to securely collect the
+fingerprints of the X.509 certificates of each peer server, store them into a
+local file, and update this local file whenever the peer server's public
+certificate changes. This may be feasible for an SMTP "VPN" connecting a small
+number of branch offices over the Internet, or for secure connections to a
+central mail hub. It works poorly if the remote SMTP server is managed by a
+third party, and its public certificate changes periodically without prior
+coordination with the verifying site.
+
+The digest algorithm used to calculate the fingerprint is selected by the
+ssmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt parameter. In the policy table multiple
+fingerprints can be combined with a "|" delimiter in a single match attribute,
+or multiple match attributes can be employed. The ":" character is not used as
+a delimiter as it occurs between each pair of fingerprint (hexadecimal) digits.
+
+Example: fingerprint TLS security with an internal mailhub. Two matching
+fingerprints are listed. The relayhost may be multiple physical hosts behind a
+load-balancer, each with its own private/public key and self-signed
+certificate. Alternatively, a single relayhost may be in the process of
+switching from one set of private/public keys to another, and both keys are
+trusted just prior to the transition.
+
+ relayhost = [mailhub.example.com]
+ smtp_tls_security_level = fingerprint
+ smtp_tls_fingerprint_digest = md5
+ smtp_tls_fingerprint_cert_match =
+ 3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+ EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+
+Example: Certificate fingerprint verification with selected destinations. As in
+the example above, we show two matching fingerprints:
+
+ /etc/postfix/main.cf:
+ smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+ smtp_tls_fingerprint_digest = md5
+
+ /etc/postfix/tls_policy:
+ example.com fingerprint
+ match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+ match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+
MMaannddaattoorryy sseerrvveerr cceerrttiiffiiccaattee vveerriiffiiccaattiioonn
At the "verify" TLS security level, messages are sent only over TLS encrypted
-sessions if the server certificate is valid (not expired or revoked, and signed
-by a trusted certificate authority) and if the server certificate name matches
-a known pattern. Mandatory server certificate verification can be configured by
-setting "smtp_tls_security_level = verify". The smtp_tls_verify_cert_match
-parameter can override the default "hostname" certificate name matching
-strategy. Fine-tuning the matching strategy is generally only appropriate for
-secure-channel destinations.
+sessions if the remote SMTP server certificate is valid (not expired or
+revoked, and signed by a trusted certificate authority) and where the server
+certificate name matches a known pattern. Mandatory server certificate
+verification can be configured by setting "smtp_tls_security_level = verify".
+The smtp_tls_verify_cert_match parameter can override the default "hostname"
+certificate name matching strategy. Fine-tuning the matching strategy is
+generally only appropriate for secure-channel destinations.
With Postfix 2.2 and earlier, or when smtp_tls_security_level is set to its
default (backwards compatible) empty value, the appropriate configuration
@@ -1057,9 +1105,9 @@ For LMTP use the corresponding "lmtp_" parameters.
If the server certificate chain is trusted (see smtp_tls_CAfile and
smtp_tls_CApath), any DNS names in the SubjectAlternativeName certificate
-extension are used to verify the server name. If no DNS names are specified,
-the certificate CommonName is checked. If you want mandatory encryption without
-server certificate verification, see above.
+extension are used to verify the remote SMTP server name. If no DNS names are
+specified, the certificate CommonName is checked. If you want mandatory
+encryption without server certificate verification, see above.
Despite the potential for eliminating "man-in-the-middle" and other attacks,
mandatory certificate trust chain and subject name verification is not viable
@@ -1085,9 +1133,10 @@ policy settings.
Example:
-In this example, the client encrypts all traffic to the example.com domain. The
-peer hostname is verified, but verification is vulnerable to DNS response
-forgery. Mail transmission to example.com recipients uses "high" grade ciphers.
+In this example, the Postfix SMTP client encrypts all traffic to the
+example.com domain. The peer hostname is verified, but verification is
+vulnerable to DNS response forgery. Mail transmission to example.com recipients
+uses "high" grade ciphers.
/etc/postfix/main.cf:
indexed = ${default_database_type}:${config_directory}/
@@ -1124,9 +1173,9 @@ DNS data. For LMTP, use the corresponding "lmtp_" parameters.
If the server certificate chain is trusted (see smtp_tls_CAfile and
smtp_tls_CApath), any DNS names in the SubjectAlternativeName certificate
-extension are used to verify the server name. If no DNS names are specified,
-the CommonName is checked. If you want mandatory encryption without server
-certificate verification, see above.
+extension are used to verify the remote SMTP server name. If no DNS names are
+specified, the CommonName is checked. If you want mandatory encryption without
+server certificate verification, see above.
Despite the potential for eliminating "man-in-the-middle" and other attacks,
mandatory secure server certificate verification is not viable as a default
@@ -1153,12 +1202,13 @@ Examples:
Secure-channel TLS without transport(5) table overrides:
-The client will encrypt all traffic and verify the destination name immune from
-forged DNS responses. MX lookups are still used to find the SMTP servers for
-example.com, but these are not used when checking the names in the server
-certificate(s). Rather, the requirement is that the MX hosts for example.com
-have trusted certificates with a subject name of example.com or a sub-domain,
-see the documentation for the smtp_tls_secure_cert_match parameter.
+The Postfix SMTP client will encrypt all traffic and verify the destination
+name immune from forged DNS responses. MX lookups are still used to find the
+hostnames of the SMTP servers for example.com, but these hostnames are not used
+when checking the names in the server certificate(s). Rather, the requirement
+is that the MX hosts for example.com have trusted certificates with a subject
+name of example.com or a sub-domain, see the documentation for the
+smtp_tls_secure_cert_match parameter.
The related domains example.co.uk and example.co.jp are hosted on the same MX
hosts as the primary example.com domain, and traffic to these is secured by
@@ -1279,25 +1329,37 @@ nnoonnee
mmaayy
Opportunistic TLS. No additional attributes are supported at this level.
eennccrryypptt
- Mandatory TLS encryption. Mail is delivered only if remote SMTP server
+ Mandatory encryption. Mail is delivered only if the remote SMTP server
offers STARTTLS and the TLS handshake succeeds. At this level and higher
the optional "ciphers" attribute overrides the main.cf
- smtp_tls_mandatory_ciphers parameter and the optional "protocols" keyword
- overrides the main.cf smtp_tls_mandatory_protocols parameter.
+ smtp_tls_mandatory_ciphers parameter, and the optional "protocols"
+ attribute overrides the main.cf smtp_tls_mandatory_protocols parameter.
+ffiinnggeerrpprriinntt
+ Certificate fingerprint verification. Available with Postfix 2.5 and later.
+ At this security level, there are no trusted certificate authorities. The
+ certificate trust chain, expiration date, ... are not checked. Instead, the
+ optional mmaattcchh attribute, or else the main.cf
+ ssmmttpp__ttllss__ffiinnggeerrpprriinntt__cceerrtt__mmaattcchh parameter, lists the valid fingerprints of
+ the server certificate. The digest algorithm used to calculate fingerprints
+ is selected by the ssmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt parameter. Multiple
+ fingerprints can be combined with a "|" delimiter in a single match
+ attribute, or multiple match attributes can be employed. The ":" character
+ is not used as a delimiter as it occurs between each pair of fingerprint
+ (hexadecimal) digits.
vveerriiffyy
Mandatory server certificate verification. Mail is delivered only if the
- TLS handshake succeeds, if the server certificate can be validated (not
- expired or revoked, and signed by a trusted certificate authority), and if
- the server certificate name matches the optional "match" attribute (or the
- main.cf smtp_tls_verify_cert_match parameter value when no optional "match"
- attribute is specified).
+ TLS handshake succeeds, if the remote SMTP server certificate can be
+ validated (not expired or revoked, and signed by a trusted certificate
+ authority), and if the server certificate name matches the optional "match"
+ attribute (or the main.cf smtp_tls_verify_cert_match parameter value when
+ no optional "match" attribute is specified).
sseeccuurree
- Secure-channel TLS. Mail is delivered only if the TLS handshake succeeds,
- if the server certificate can be validated (not expired or revoked, and
- signed by a trusted certificate authority), and if the server certificate
- name matches the optional "match" attribute (or the main.cf
- smtp_tls_secure_cert_match parameter value when no optional "match"
- attribute is specified).
+ Secure certificate verification. Mail is delivered only if the TLS
+ handshake succeeds, if the remote SMTP server certificate can be validated
+ (not expired or revoked, and signed by a trusted certificate authority),
+ and if the server certificate name matches the optional "match" attribute
+ (or the main.cf smtp_tls_secure_cert_match parameter value when no optional
+ "match" attribute is specified).
Notes:
* The "match" attribute is especially useful to verify TLS certificates for
@@ -1316,6 +1378,8 @@ Example:
/etc/postfix/main.cf:
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+ # Postfix 2.5 and later
+ smtp_tls_fingerprint_digest = md5
/etc/postfix/tls_policy:
example.edu none
example.mil may
@@ -1325,6 +1389,10 @@ Example:
example.net secure
.example.net secure match=.example.net:example.net
[mail.example.org]:587 secure match=nexthop
+ # Postfix 2.5 and later
+ [thumb.example.org] fingerprint
+ match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+ match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
NNoottee:: The "hostname" strategy if listed in a non-default setting of
smtp_tls_secure_cert_match or in the "match" attribute in the policy table can
@@ -1509,16 +1577,22 @@ Example:
SSeerrvveerr cceerrttiiffiiccaattee vveerriiffiiccaattiioonn ddeepptthh
-When verifying a remote SMTP server certificate, a verification depth of 1 is
-sufficient if the certificate is directly issued by a CA specified with
-smtp_tls_CAfile or smtp_tls_CApath. The default value of 5 should also suffice
-for longer chains (where the root CA issues a special CA certificate which then
-issues the actual certificate).
+The server certificate verification depth is specified with the main.cf
+smtp_tls_scert_verifydepth parameter. The default verification depth is 9 (the
+OpenSSL default), for compatibility with Postfix versions before 2.5 where
+smtp_tls_scert_verifydepth was ignored. When you configure trust in a root CA,
+it is not necessary to explicitly trust intermediary CAs signed by the root CA,
+unless $smtp_tls_scert_verifydepth is less than the number of CAs in the
+certificate chain for the servers of interest. With a verify depth of 1 you can
+only verify certificates directly signed by a trusted CA, and all trusted
+intermediary CAs need to be configured explicitly. With a verify depth of 2 you
+can verify servers signed by a root CA or a direct intermediary CA (so long as
+the server is correctly configured to supply its intermediate CA certificate).
Example:
/etc/postfix/main.cf:
- smtp_tls_scert_verifydepth = 5
+ smtp_tls_scert_verifydepth = 2
CClliieenntt--ssiiddee cciipphheerr ccoonnttrroollss
@@ -1531,12 +1605,13 @@ today's crypt-analytic 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
-server certificates are verified. If you want to disable anonymous ciphers even
-at the "encrypt" security level, set "smtp_tls_mandatory_exclude_ciphers =
-aNULL"; and to disable anonymous ciphers even with opportunistic TLS, set
-"smtp_tls_exclude_ciphers = aNULL". There is generally no need to take these
-measures. Anonymous ciphers save bandwidth and TLS session cache space, if
-certificates are ignored, there is little point in requesting them.
+remote SMTP server certificates are verified. If you want to disable anonymous
+ciphers even at the "encrypt" security level, set
+"smtp_tls_mandatory_exclude_ciphers = aNULL"; and to disable anonymous ciphers
+even with opportunistic TLS, set "smtp_tls_exclude_ciphers = aNULL". There is
+generally no need to take these measures. Anonymous ciphers save bandwidth and
+TLS session cache space, if certificates are ignored, there is little point in
+requesting them.
Example:
@@ -1544,6 +1619,9 @@ Example:
smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers = RC4, MD5
smtp_tls_exclude_ciphers = aNULL
+ smtp_tls_mandatory_protocols = SSLv3, TLSv1
+ # Also available with Postfix >= 2.5:
+ smtp_tls_mandatory_protocols = !SSLv2
CClliieenntt--ssiiddee SSMMTTPPSS ssuuppppoorrtt
@@ -1793,7 +1871,7 @@ indicates a super-user shell.
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_session_cache_database =
btree:/var/lib/postfix/smtp_tls_session_cache
- smtp_use_tls = yes
+ smtp_tls_security_level = may
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_cert_file = /etc/postfix/FOO-cert.pem
smtpd_tls_key_file = /etc/postfix/FOO-key.pem
@@ -1822,4 +1900,8 @@ CCrreeddiittss
* Victor Duchovni was instrumental with the re-implementation of the
smtp_tls_per_site code in terms of enforcement levels, which simplified the
implementation greatly.
+ * Victor Duchovni implemented the fingerprint security level, added more
+ sanity checks, and separated TLS connection management from security policy
+ enforcement. The latter change simplified the code that verifies
+ certificate signatures, certificate names, and certificate fingerprints.
diff --git a/postfix/RELEASE_NOTES b/postfix/RELEASE_NOTES
index cc1d9e95d..a1b9ec374 100644
--- a/postfix/RELEASE_NOTES
+++ b/postfix/RELEASE_NOTES
@@ -11,15 +11,75 @@ 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.
+Incompatibility with Postfix snapshot 20080109
+==============================================
+
+TLS logging output has changed to make it more useful. Existing
+logfile parser regular expressions may need adjustment.
+
+- More log entries include the "hostnamename[ipaddress]" of the
+ remote SMTP peer.
+
+- Certificate trust chain error reports show only the first
+ error certificate (closest to the trust chain root), and the
+ reporting is more human-readable for the most likely errors.
+
+- After the completion of the TLS handshake, the session is logged
+ with TLS loglevel >= 1 as either "Untrusted", "Trusted" or
+ "Verified" (SMTP client only).
+ - "Untrusted" means that the certificate trust chain is invalid,
+ or that the root CA is not trusted.
+ - "Trusted" means that the certificate trust chain is valid, and
+ that the root CA is trusted.
+ - "Verified" means that the certificate meets the SMTP client's
+ matching criteria for the destination:
+ - In the case of a destination name match, "Verified" also
+ implies "Trusted".
+ - In the case of a fingerprint match, CA trust is not applicable.
+
+- The logging of protocol states with TLS loglevel >= 2 no longer
+ reports bogus error conditions when OpenSSL asks Postfix to refill
+ (or flush) network I/O buffers. This loglevel is for debugging
+ only; use 0 or 1 in production configurations.
+
+Major changes with Postfix snapshot 20080109
+============================================
+
+The Postfix SMTP client has a new "fingerprint" security level.
+This avoids dependencies on CAs, and relies entirely on bi-lateral
+exchange of public keys (really self-signed or private CA signed
+X.509 public key certificates). Scalability is clearly limited. For
+details, see the fingerprint discussion in TLS_README.
+
+The Postfix SMTP server can now use SHA1 instead of MD5 to compute
+remote SMTP client certificate fingerprints. For backwards
+compatibility, the default algorithm is MD5. For details, see the
+"smtpd_tls_fingerprint_digest" parameter in the postconf(5) manual.
+
+The maximum certificate trust chain depth (verifydepth) is finally
+implemented in the Postfix TLS library. Previously, the parameter
+had no effect. The default depth was changed to 9 (the OpenSSL
+default) for backwards compatibility.
+
+If you have explicity limited the verification depth in main.cf,
+check that the configured limit meets your needs. See the
+"lmtp_tls_scert_verifydepth", "smtp_tls_scert_verifydepth" and
+"smtpd_tls_ccert_verifydepth" parameters in the postconf(5) manual.
+
+The selection of SSL/TLS protocols for mandatory TLS can now use
+exclusion rather than inclusion. Either form is acceptable; see the
+"lmtp_tls_mandatory_protocols", "smtp_tls_mandatory_protocols" and
+"smtpd_tls_mandatory_protocols" parameters in the postconf(5) manual.
+
Major changes with Postfix snapshot 20080107
============================================
New "pass" service type in master.cf. Written years ago, this
-allows a front-end daemon to accept all connections from the network,
-and forward only those from well-behaved clients to Postfix. Since
-this uses file descriptor passing, it imposes no overhead once a
-connection is handed over to Postfix. This is available in the
-experimental release only. See master(5) for a few details.
+allows a future front-end daemon to accept all connections from the
+network, and forward only those from well-behaved clients to Postfix.
+Since this uses file descriptor passing, it imposes no overhead
+once a connection is handed over to Postfix. See master(5) for a
+few details.
Incompatibility with Postfix snapshot 20071224
==============================================
diff --git a/postfix/TLS_TODO b/postfix/TLS_TODO
index 575c25ff3..05590100c 100644
--- a/postfix/TLS_TODO
+++ b/postfix/TLS_TODO
@@ -1,5 +1,19 @@
This list does not really follow priority.
+* Code cleanup: split smtp_session.c into generic SMTP, legacy TLS,
+ and current TLS. The amount of TLS code now dominates the file.
+ Do this after all other code revisions stabilize, to avoid
+ complicating code reviews.
+
+* Code cleanup: TLS_LEV_NOTFOUND no longer belongs in the TLS
+ library. It is an SMTP-client only feature. To fix, change the
+ policy lookup API and use a different method to indicate if a
+ policy was found. At the same time, fix policy lookup to initialize
+ session->tls_level.
+
+* Code cleanup: see if multiple consecutive switches can be aggregated
+ (set_cipher_grade() and session_tls_init()).
+
* Implement support of CRL checking. OpenSSL 0.9.7 finally supports CRLs,
so Postfix/TLS should support loading CRLs.
diff --git a/postfix/WISHLIST b/postfix/WISHLIST
index 179fbcba1..de66e9fe9 100644
--- a/postfix/WISHLIST
+++ b/postfix/WISHLIST
@@ -1,5 +1,7 @@
Wish list:
+ Consolidate duplicated code *_server_accept_{pass,inet}().
+
Consolidate duplicated code in {inet,unix,upass}_trigger.c.
In the SMTP client, handle 421 replies in smtp_loop() by
diff --git a/postfix/html/STRESS_README.html b/postfix/html/STRESS_README.html
index 61a0e7032..1ea44d77b 100644
--- a/postfix/html/STRESS_README.html
+++ b/postfix/html/STRESS_README.html
@@ -24,9 +24,10 @@ Stress-Dependent Configuration
overload, and how to avoid the condition under normal conditions.
When the condition is caused by botnets or other malware, the
document suggests configuration settings that help to minimize the
-impact on legitimate mail. Finally, the document introduces Postfix
-stress-adaptive behavior, and how it can be used to automatically
-switch configuration settings under overload.
Topics covered in this document:
@@ -55,8 +56,7 @@ switch configuration settings under overload.Under normal conditions, Postfix responds immediately when a -remote SMTP client connects. The time needed to deliver mail to -Postfix may depend on how busy the CPU or disk are, but that should +remote SMTP client connects. The time needed to deliver mail should be noticeable only with very large messages. Performance degrades more dramatically when the number of remote SMTP clients exceeds the number of Postfix SMTP server processes. When a client connects @@ -71,17 +71,6 @@ SMTP mail server overload are:
Postfix logs a warning that all server ports are busy:
- --Oct 3 20:39:27 spike postfix/master[28905]: warning: service "smtp" - (25) has reached its process limit "30": new clients may experience - noticeable delays -Oct 3 20:39:27 spike postfix/master[28905]: warning: to avoid this - condition, increase the process count in master.cf or reduce the - service time per client --
Remote SMTP clients experience a long delay before Postfix sends the "220 hostname.example.com ESMTP Postfix" greeting. If this affects end-user mail clients, enable the "submission" service @@ -92,9 +81,22 @@ connect to this instead of the public SMTP service.
connection after CONNECT" events. This happens because remote SMTP clients disconnect before Postfix answers the connection. +Postfix 2.3 and later logs a warning that all server ports +are busy:
+ ++Oct 3 20:39:27 spike postfix/master[28905]: warning: service "smtp" + (25) has reached its process limit "30": new clients may experience + noticeable delays +Oct 3 20:39:27 spike postfix/master[28905]: warning: to avoid this + condition, increase the process count in master.cf or reduce the + service time per client ++
NOTE: The last two symptoms also happen without overload.
+NOTE: The first two symptoms may also happen without overload, +for example:
By turning on TLS support in Postfix, you not only get the -ability to encrypt mail and to authenticate clients or servers. +ability to encrypt mail and to authenticate remote SMTP clients or servers. You also turn on thousands and thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000 lines introduce one additional bug into @@ -225,7 +225,7 @@ key configuration
In order to use TLS, the Postfix SMTP server generally needs a certificate and a private key. Both must be in "PEM" format. The private key must not be encrypted, meaning: the key must be accessible -without password. Both certificate and private key may be in the same +without a password. The certificate and private key may be in the same file, in which case the certificate file should be owned by "root" and not be readable by any other user. If the key is stored separately, this applies to the key file only, and the certificate file may be @@ -233,20 +233,24 @@ this applies to the key file only, and the certificate file may be
Public Internet MX hosts without certificates signed by a "reputable" CA must generate, and be prepared to present to most clients, a -self-signed or private-CA signed certificate. The client will not be -able to authenticate the server, but unless it is running Postfix 2.3 or +self-signed or private-CA signed certificate. The remote SMTP client +will generally not be +able to authenticate the self-signed certificate, but unless the +client is running Postfix 2.3 or similar software, it will still insist on a server certificate.
For servers that are not public Internet MX hosts, Postfix -2.3 supports configurations with no certificates. This entails the +supports configurations with no certificates. This entails the use of just the anonymous TLS ciphers, which are not supported by typical SMTP clients. Since such clients will not, as a rule, fall -back to plain text after a TLS handshake failure, the server will +back to plain text after a TLS handshake failure, a certificate-less +Postfix SMTP server will be unable to receive email from most TLS enabled clients. To avoid -accidental configurations with no certificates, Postfix 2.3 enables +accidental configurations with no certificates, Postfix enables certificate-less operation only when the administrator explicitly sets "smtpd_tls_cert_file = none". This ensures that new Postfix -configurations will not accidentally run with no certificates.
+SMTP server configurations will not accidentally run with no +certificates.Both RSA and DSA certificates are supported. Typically you will only have RSA certificates issued by a commercial CA. In addition, @@ -262,7 +266,7 @@ chain, all CA certificates) must be available. You should add any intermediate CA certificates to the server certificate: the server certificate first, then the intermediate CA(s).
-Example: the certificate for "server.dom.ain" was issued by +
Example: the certificate for "server.example.com" was issued by "intermediate CA" which itself has a certificate issued by "root CA". Create the server.pem file with:
@@ -283,15 +287,7 @@ the overhead of the TLS exchange.If you want the Postfix SMTP server to accept remote SMTP client certificates issued by these CAs, append the root certificate to -$smtpd_tls_CAfile or install it in the $smtpd_tls_CApath directory. When -you configure trust in a root CA, it is not necessary to explicitly trust -intermediary CAs signed by the root CA, unless $smtpd_tls_ccert_verifydepth -is less than the number of CAs in the certificate chain for the clients -of interest. With a verify depth of 1 you can only verify certificates -directly signed by a trusted CA, and all trusted intermediary CAs need to -be configured explicitly. With a verify depth of 2 you can verify clients -signed by a root CA or a direct intermediary CA (so long as the client -is correctly configured to supply its intermediate CA certificate).
+$smtpd_tls_CAfile or install it in the $smtpd_tls_CApath directory.RSA key and certificate examples:
@@ -347,7 +343,7 @@ privileges) from the files in the directory when the information is needed. Thus, the $smtpd_tls_CApath directory needs to be accessible inside the optional chroot jail. -When you configure Postfix to request When you configure the Postfix SMTP server to request client certificates, any CA certificates in $smtpd_tls_CAfile are sent to the client, in order to allow it to choose an identity signed by a CA you trust. If no $smtpd_tls_CAfile @@ -450,12 +446,13 @@ supported).
-With this, Postfix SMTP server announces STARTTLS support to -SMTP clients, but does not require that clients use TLS encryption. +
With this, the Postfix SMTP server announces STARTTLS support to +remote SMTP clients, but does not require that clients use TLS encryption.
Note: when an unprivileged user invokes "sendmail -bs", STARTTLS -is never offered due to insufficient privileges to access the server +is never offered due to insufficient privileges to access the Postfix +SMTP server private key. This is intended behavior.
You can ENFORCE the use of TLS, @@ -481,7 +478,8 @@ by default and should only seldom be used.
TLS is sometimes used in the non-standard "wrapper" mode where a server always uses TLS, instead of announcing STARTTLS support -and waiting for clients to request TLS service. Some clients, namely +and waiting for remote SMTP clients to request TLS service. Some +clients, namely Outlook [Express] prefer the "wrapper" mode. This is true for OE (Win32 < 5.0 and Win32 >=5.0 when run on a port<>25 and OE (5.01 Mac on all ports).
@@ -517,8 +515,10 @@ this option is "off" by default. You will however need the certificate if you want to use certificate based relaying with, for example, the permit_tls_clientcerts feature. A server that wants client certificates must first present its own certificate. While Postfix 2.3 by default -offers anonymous ciphers to clients, these are automatically suppressed -when the server is configured to ask for client certificates. +offers anonymous ciphers to remote SMTP clients, these are automatically +suppressed +when the Postfix SMTP server is configured to ask for client +certificates.Example:
@@ -553,18 +553,26 @@ logged. -A client certificate verification depth of 1 is sufficient if -the certificate is directly issued by a CA listed in the CA file. -The default value (5) should also suffice for longer chains (root -CA issues special CA which then issues the actual certificate...) -
+The client certificate verification depth is specified with the +main.cf smtpd_tls_ccert_verifydepth parameter. The default verification +depth is 9 (the OpenSSL default), for compatibility with Postfix +versions before 2.5 where smtpd_tls_ccert_verifydepth was ignored. +When you configure trust in a +root CA, it is not necessary to explicitly trust intermediary CAs signed +by the root CA, unless $smtpd_tls_ccert_verifydepth is less than the +number of CAs in the certificate chain for the clients of interest. With +a verify depth of 1 you can only verify certificates directly signed +by a trusted CA, and all trusted intermediary CAs need to be configured +explicitly. With a verify depth of 2 you can verify clients signed by a +root CA or a direct intermediary CA (so long as the client is correctly +configured to supply its intermediate CA certificate).
Example:
@@ -661,23 +669,30 @@ Postfix SMTP server access control:/etc/postfix/main.cf: - smtpd_tls_ccert_verifydepth = 5 + smtpd_tls_ccert_verifydepth = 2
Allow the remote SMTP -client SMTP request if the client certificate passes verification, -and if its fingerprint is listed in the list of client certificates -(see relay_clientcerts discussion below).
Allow the remote SMTP client +request if the client certificate fingerprint is listed in the +client certificate table (see relay_clientcerts discussion below).
+Allow the remote -client SMTP request if the client certificate passes verification. -
Allow the remote SMTP +client request if the client certificate passes trust chain verification. +Useful with private-label CAs that only issue certificates to trusted +clients (and not otherwise).
If the client certificate passes verification, use its fingerprint -as a key for the specified access(5) table.
Use the remote SMTP +client +certificate fingerprint as the lookup key for the specified access(5) +table.
The digest algorithm used to construct the client certificate +fingerprints is specified with the main.cf smtpd_tls_fingerprint_digest +parameter. The default is "md5", for compatibility with Postfix +versions < 2.5.
+The permit_tls_all_clientcerts feature must be used with caution, because it can result in too many access permissions. Use this feature only if a special CA issues the client certificates, and @@ -704,16 +719,10 @@ certificate must no longer be used (e.g. an employee leaving).
-The Postfix list manipulation routines give special treatment -to whitespace and some other characters, making the use of certificate -names impractical. Instead we use the certificate fingerprints as -they are difficult to fake but easy to use for lookup. Postfix -lookup tables are in the form of (key, value) pairs. Since we only -need the key, the value can be chosen freely, e.g. the name of -the user or host.
+Example: Postfix lookup tables are in the form of (key, value) +pairs. Since we only need the key, the value can be chosen freely, e.g. +the name of the user or host:
-Example:
-
/etc/postfix/main.cf:
@@ -766,27 +775,29 @@ and not specifying an smtpd_tls_d
smtpd_tls_key_file = /etc/postfix/key.pem
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
- # Postfix 2.3 and later
smtpd_tls_security_level = encrypt
- # Obsolete, but still supported
- smtpd_enforce_tls = yes
+ smtpd_tls_mandatory_protocols = TLSv1
+ # Also available with Postfix ≥ 2.5:
+ smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
-If you want to take advantage of ciphers with EDH, DH parameters -are needed. Instead of using the built-in DH parameters for both -1024bit and 512bit, it is better to generate your own parameters, -since otherwise it would "pay" for a possible attacker to start a -brute force attack against parameters that are used by everybody. -For this reason, the default parameters chosen by OpenSSL are already -different from those distributed with other TLS packages.
+If you want to take advantage of ciphers with ephemeral Diffie-Hellman +(EDH) key exchange (this offers "forward-secrecy"), DH parameters are +needed. Instead of using the built-in DH parameters for both 1024-bit +(non-export ciphers) and 512-bit (export ciphers), it is better to +generate your own parameters, since otherwise it would "pay" for a +possible attacker to start a brute force attack against parameters that +are used by everybody. Postfix defaults to compiled-in parameters +that are shared by all Postfix users who don't generate their own +settings.
To generate your own set of DH parameters, use:
@@ -841,6 +852,8 @@ key configuration-% openssl gendh -out /etc/postfix/dh_1024.pem -2 -rand /var/run/egd-pool 1024 -% openssl gendh -out /etc/postfix/dh_512.pem -2 -rand /var/run/egd-pool 512 +% openssl gendh -out /etc/postfix/dh_512.pem -2 512 +% openssl gendh -out /etc/postfix/dh_1024.pem -2 1024
In Postfix 2.3, the smtp(8) and lmtp(8) delivery agents have been -merged into a single dual-purpose program. As a result the lmtp(8) -delivery agent is no longer the poor cousin of the more extensively used -smtp(8). Specifically, as of Postfix 2.3, all the TLS features described -below apply equally to SMTP and LMTP, after replacing the "smtp_" -prefix of the each parameter name with "lmtp_". +
The smtp(8) and lmtp(8) delivery agents are implemented by a +single dual-purpose program. Specifically, all the TLS features +described below apply +equally to SMTP and LMTP, after replacing the "smtp_" prefix of the each +parameter name with "lmtp_". -
The LMTP delivery agent can communicate with LMTP servers listening +
The Postfix LMTP delivery agent can communicate with LMTP servers +listening on UNIX-domain sockets. When server certificate verification is enabled and the server is listening on a UNIX-domain socket, the $myhostname parameter is used to set the TLS verification nexthop and @@ -887,7 +900,8 @@ The "null" ciphers provide authentication without encryption.
Do not configure client certificates unless you must present +
Do not configure Postfix SMTP client certificates unless you must +present client TLS certificates to one or more servers. Client certificates are not usually needed, and can cause problems in configurations that work well without them. The recommended setting is to let the defaults stand:
@@ -951,15 +965,7 @@ the overhead of the TLS exchange.If you want the Postfix SMTP client to accept remote SMTP server certificates issued by these CAs, append the root certificate to -$smtp_tls_CAfile or install it in the $smtp_tls_CApath directory. When -you configure trust in a root CA, it is not necessary to explicitly trust -intermediary CAs signed by the root CA, unless $smtp_tls_scert_verifydepth -is less than the number of CAs in the certificate chain for the servers -of interest. With a verify depth of 1 you can only verify certificates -directly signed by a trusted CA, and all trusted intermediary CAs need to -be configured explicitly. With a verify depth of 2 you can verify servers -signed by a root CA or a direct intermediary CA (so long as the server -is correctly configured to supply its intermediate CA certificate).
+$smtp_tls_CAfile or install it in the $smtp_tls_CApath directory.RSA key and certificate examples:
@@ -1212,6 +1218,8 @@ in the sections that follow.At the "encrypt" TLS security level, messages are sent only over TLS encrypted sessions. The SMTP transaction is aborted unless -the STARTTLS ESMTP feature is supported by the server. If no suitable +the STARTTLS ESMTP feature is supported by the remote SMTP server. +If no suitable servers are found, the message will be deferred. With Postfix 2.3 and later, mandatory TLS encryption can be configured by setting "smtp_tls_security_level = encrypt". Even though TLS -encryption is always used, mail delivery continues if the server +encryption is always used, mail delivery continues even if the server certificate is untrusted or bears the wrong name.
At this security level and higher, the smtp_tls_mandatory_protocols @@ -1437,13 +1446,82 @@ use the new policy table instead.
+Certificate fingerprint verification is available with Postfix 2.5 and +later. At this security level ("smtp_tls_security_level = fingerprint"), +no trusted certificate authorities are used or required. The certificate +trust chain, expiration date, ... are not checked. Instead, the +smtp_tls_fingerprint_cert_match parameter or the "match" attribute +in the policy table lists the valid +"fingerprints" of the remote SMTP server certificate.
+ +If certificate fingerprints are exchanged securely, this is the +strongest, and least scalable security level. The administrator needs to +securely collect the fingerprints of the X.509 certificates of each peer +server, store them into a local file, and update this local file +whenever the peer server's public certificate +changes. This may be feasible for an SMTP "VPN" connecting a small +number of branch offices over the Internet, or for secure connections +to a central mail hub. It works poorly if the remote SMTP server is +managed by a +third party, and its public certificate changes periodically without +prior coordination with the verifying site.
+ +The digest algorithm used to calculate the fingerprint is +selected by the smtp_tls_fingerprint_digest parameter. In the policy table multiple fingerprints can be +combined with a "|" delimiter in a single match attribute, or multiple +match attributes can be employed. The ":" character is not used as a +delimiter as it occurs between each pair of fingerprint (hexadecimal) +digits.
+ +Example: fingerprint TLS security with an internal mailhub. +Two matching fingerprints are listed. The relayhost may be multiple +physical hosts behind a load-balancer, each with its own private/public +key and self-signed certificate. Alternatively, a single relayhost may +be in the process of switching from one set of private/public keys to +another, and both keys are trusted just prior to the transition.
+ +++ ++ relayhost = [mailhub.example.com] + smtp_tls_security_level = fingerprint + smtp_tls_fingerprint_digest = md5 + smtp_tls_fingerprint_cert_match = + 3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1 + EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35 ++
Example: Certificate fingerprint verification with selected destinations. +As in the example above, we show two matching fingerprints:
++++/etc/postfix/main.cf: + smtp_tls_policy_maps = hash:/etc/postfix/tls_policy + smtp_tls_fingerprint_digest = md5 ++
+++/etc/postfix/tls_policy: + example.com fingerprint + match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1 + match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35 ++
At the "verify" TLS security level, messages are sent only over -TLS encrypted sessions if the server certificate is valid (not +TLS encrypted sessions if the remote SMTP server certificate is +valid (not expired or revoked, and signed by a trusted certificate authority) -and if the server certificate name matches a known pattern. Mandatory +and where the server certificate name matches a known pattern. +Mandatory server certificate verification can be configured by setting "smtp_tls_security_level = verify". The smtp_tls_verify_cert_match parameter can override the default @@ -1459,7 +1537,8 @@ appropriate configuration settings are "smtp_tls_CAfile and smtp_tls_CApath), any DNS names in the SubjectAlternativeName -certificate extension are used to verify the server name. If no +certificate extension are used to verify the remote SMTP server name. +If no DNS names are specified, the certificate CommonName is checked. If you want mandatory encryption without server certificate verification, see above.
@@ -1492,7 +1571,7 @@ Postfix 2.3 and later should use the new TLS policy settings.Example:
-In this example, the client encrypts all traffic to the +
In this example, the Postfix SMTP client encrypts all traffic to the example.com domain. The peer hostname is verified, but verification is vulnerable to DNS response forgery. Mail transmission to example.com recipients uses "high" grade ciphers.
@@ -1543,7 +1622,8 @@ parameters.If the server certificate chain is trusted (see smtp_tls_CAfile and smtp_tls_CApath), any DNS names in the SubjectAlternativeName certificate -extension are used to verify the server name. If no DNS names are +extension are used to verify the remote SMTP server name. If no DNS names +are specified, the CommonName is checked. If you want mandatory encryption without server certificate verification, see above.
@@ -1578,9 +1658,11 @@ should use the new TLS policy settings.Secure-channel TLS without transport(5) table overrides:
-The client will encrypt all traffic and verify the destination name +
The Postfix SMTP client will encrypt all traffic and verify the +destination name immune from forged DNS responses. MX lookups are still used to find -the SMTP servers for example.com, but these are not used when +the hostnames of the SMTP servers for example.com, but these +hostnames are not used when checking the names in the server certificate(s). Rather, the requirement is that the MX hosts for example.com have trusted certificates with a subject name of example.com or a sub-domain, see the @@ -1729,35 +1811,50 @@ describe the corresponding table syntax:
/etc/postfix/main.cf: smtp_tls_policy_maps = hash:/etc/postfix/tls_policy + # Postfix 2.5 and later + smtp_tls_fingerprint_digest = md5 /etc/postfix/tls_policy: example.edu none example.mil may @@ -1798,6 +1897,10 @@ Example: example.net secure .example.net secure match=.example.net:example.net [mail.example.org]:587 secure match=nexthop + # Postfix 2.5 and later + [thumb.example.org] fingerprint + match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35 + match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1@@ -2040,18 +2143,26 @@ postfix/smtp[pid]: Host offered STARTTLS: [hostname.example.com]
When verifying a remote SMTP server certificate, a verification -depth of 1 is sufficient if the certificate is directly issued by -a CA specified with smtp_tls_CAfile or smtp_tls_CApath. The default -value of 5 should also suffice for longer chains (where the root CA issues -a special CA certificate which then issues the actual certificate).
- -Example:
+The server certificate verification depth is specified with the +main.cf smtp_tls_scert_verifydepth parameter. The default verification +depth is 9 (the OpenSSL default), for compatibility with Postfix +versions before 2.5 where smtp_tls_scert_verifydepth was ignored. +When you configure trust +in a root CA, it is not necessary to explicitly trust intermediary CAs +signed by the root CA, unless $smtp_tls_scert_verifydepth is less than the +number of CAs in the certificate chain for the servers of interest. With +a verify depth of 1 you can only verify certificates directly signed +by a trusted CA, and all trusted intermediary CAs need to be configured +explicitly. With a verify depth of 2 you can verify servers signed by a +root CA or a direct intermediary CA (so long as the server is correctly +configured to supply its intermediate CA certificate).
+Example:
+@@ -2067,7 +2178,8 @@ methods. See smtp_tls_policy_maps ciphers on a per-destination basis./etc/postfix/main.cf: - smtp_tls_scert_verifydepth = 5 + smtp_tls_scert_verifydepth = 2
By default anonymous ciphers are allowed, and automatically -disabled when server certificates are verified. If you want to +disabled when remote SMTP server certificates are verified. If you +want to disable anonymous ciphers even at the "encrypt" security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL"; and to disable anonymous ciphers even with opportunistic TLS, set @@ -2084,6 +2196,9 @@ little point in requesting them.
smtp_tls_mandatory_ciphers = medium smtp_tls_mandatory_exclude_ciphers = RC4, MD5 smtp_tls_exclude_ciphers = aNULL + smtp_tls_mandatory_protocols = SSLv3, TLSv1 + # Also available with Postfix ≥ 2.5: + smtp_tls_mandatory_protocols = !SSLv2 @@ -2405,7 +2520,7 @@ but don't require them from all clients. smtp_tls_CAfile = /etc/postfix/cacert.pem smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache - smtp_use_tls = yes + smtp_tls_security_level = may smtpd_tls_CAfile = /etc/postfix/cacert.pem smtpd_tls_cert_file = /etc/postfix/FOO-cert.pem smtpd_tls_key_file = /etc/postfix/FOO-key.pem @@ -2444,6 +2559,12 @@ compiled this part of the documentation from Lutz's documents. of the smtp_tls_per_site code in terms of enforcement levels, which simplified the implementation greatly. +