From: Wietse Venema
Date: Wed, 15 Jan 2014 05:00:00 +0000 (-0500)
Subject: postfix-2.12-20140115
X-Git-Tag: v3.0.0-RC1~68
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e1251bb5e71fff3d2a113373be04376961044555;p=thirdparty%2Fpostfix.git
postfix-2.12-20140115
---
diff --git a/postfix/.indent.pro b/postfix/.indent.pro
index 7c1140ce0..78e0a16ef 100644
--- a/postfix/.indent.pro
+++ b/postfix/.indent.pro
@@ -382,7 +382,6 @@
-Tssize_t
-Tssl_cipher_stack_t
-Tssl_comp_stack_t
--Tstat
-Ttime_t
-Ttlsa_filter
-Tx509_extension_stack_t
diff --git a/postfix/HISTORY b/postfix/HISTORY
index c67bceb16..8482b6195 100644
--- a/postfix/HISTORY
+++ b/postfix/HISTORY
@@ -19524,3 +19524,7 @@ Apologies for any names omitted.
Cleanup: Unify/simplify reporting of configuration or other
conditions that prevent DANE security. Viktor Dukhovni.
Files: global/dsn_buf.[hc], tls/tls_dane.c, smtp/smtp_tls_policy.c.
+
+20140110-15
+
+ Miscellaneous documentation cleanups.
diff --git a/postfix/README_FILES/FORWARD_SECRECY_README b/postfix/README_FILES/FORWARD_SECRECY_README
index 15751b71b..b81bfcbea 100644
--- a/postfix/README_FILES/FORWARD_SECRECY_README
+++ b/postfix/README_FILES/FORWARD_SECRECY_README
@@ -7,11 +7,11 @@ WWaarrnniinngg
Forward secrecy does not protect against active attacks such as forged DNS
replies or forged TLS server certificates. If such attacks are a concern, then
the SMTP client will need to authenticate the remote SMTP server in a
-sufficiently-secure manner. For example, by the fingerprint of the public key
-or certificate. Conventional PKI relies on many trusted parties and is easily
-subverted by a state-funded adversary.
+sufficiently-secure manner. For example, by the fingerprint of a (CA or leaf)
+public key or certificate. Conventional PKI relies on many trusted parties and
+is easily subverted by a state-funded adversary.
-BBaacckkggrroouunndd
+OOvveerrvviieeww
Postfix supports forward secrecy of TLS network communication since version
2.2. This support was adopted from Lutz Jänicke's "Postfix TLS patch" for
@@ -19,6 +19,24 @@ earlier Postfix versions. This document will focus on TLS Forward Secrecy in
the Postfix SMTP client and server. See TLS_README for a general description of
Postfix TLS support.
+Topics covered in this document:
+
+ * Give me some background on forward secrecy in Postfix
+
+ o What is Forward Secrecy
+ o Forward Secrecy in TLS
+ o Forward Secrecy in the Postfix SMTP Server
+ o Forward Secrecy in the Postfix SMTP Client
+
+ * Never mind, just show me what it takes to get forward secrecy
+
+ o Getting started, quick and dirty
+ o How can I see that a connection has forward secrecy?
+ o What ciphers provide forward secrecy?
+ o What do "Anonymous", "Untrusted", etc. in Postfix logging mean?
+
+ * Credits
+
WWhhaatt iiss FFoorrwwaarrdd SSeeccrreeccyy
The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy") is used to
@@ -43,21 +61,6 @@ cost constraints on the efficacy of bulk surveillance, recovering all past
traffic is generally infeasible, and even recovery of individual sessions may
be infeasible given a sufficiently-strong key agreement method.
-Topics covered in this document:
-
- * Forward Secrecy in TLS
- * Forward Secrecy in the Postfix SMTP Server
- * Forward Secrecy in the Postfix SMTP Client
- * Getting started, quick and dirty
- * How can I see that a connection has forward secrecy?
- * What ciphers provide forward secrecy?
- * What do "Anonymous", "Untrusted", etc. in Postfix logging mean?
- * Credits
-
-And last but not least, for the impatient:
-
- * Configuring forward secrecy, quick and dirty
-
FFoorrwwaarrdd SSeeccrreeccyy iinn TTLLSS
Early implementations of the SSL protocol do not provide forward secrecy (some
@@ -208,11 +211,11 @@ RedHat Linux.
# Postfix 2.6 or 2.7 only. This is default with Postfix 2.8 and later.
smtpd_tls_eecdh_grade = strong
-EEDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 22..22))
+EEDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss))
This works "out of the box" without additional configuration.
-EEDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..22))
+EEDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss))
Optionally generate non-default Postfix SMTP server EDH parameters for improved
security against pre-computation attacks and for compatibility with Debian-
@@ -334,9 +337,9 @@ WWhhaatt ddoo ""AAnnoonnyymmoouuss"",, ""UUnnttrruusst
The verification levels below are subject to man-in-the-middle attacks to
different degrees. If such attacks are a concern, then the SMTP client will
need to authenticate the remote SMTP server in a sufficiently-secure manner.
-For example, by the fingerprint of the public key or certificate. Remember that
-conventional PKI relies on many trusted parties and is easily subverted by a
-state-funded adversary.
+For example, by the fingerprint of a (CA or leaf) public key or certificate.
+Remember that conventional PKI relies on many trusted parties and is easily
+subverted by a state-funded adversary.
AAnnoonnyymmoouuss (no peer certificate)
PPoossttffiixx SSMMTTPP cclliieenntt:: With opportunistic TLS (the "may" security level) the
@@ -379,20 +382,28 @@ TTrruusstteedd (peer certificate signed by trusted CA, unverified peer na
PPoossttffiixx SSMMTTPP sseerrvveerr:: The remote SMTP client certificate was signed by a CA
that the Postfix SMTP server trusts. The Postfix SMTP server never verifies
- the remote SMTP client name against the names in the certificate. Since the
- client chooses to connect to the server, the Postfix SMTP server has no
- expectation of a particular client hostname.
+ the remote SMTP client name against the names in the client certificate.
+ Since the client chooses to connect to the server, the Postfix SMTP server
+ has no expectation of a particular client hostname.
-VVeerriiffiieedd (peer certificate signed by trusted CA, verified peer name)
+VVeerriiffiieedd (peer certificate signed by trusted CA and verified peer name; or:
+peer certificate with expected public-key or certificate fingerprint)
PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server's certificate was signed by a
- CA that the Postfix SMTP client trusts, and it matches one of the expected
- server names. This implies that the Postfix SMTP client enforced
- verification for the destination server name, otherwise the verification
- status would have been just "Trusted".
-
- PPoossttffiixx SSMMTTPP sseerrvveerr:: The status is never "Verified", as the Postfix SMTP
- server never verifies the remote SMTP client name against the names in the
- certificate.
+ CA that the Postfix SMTP client trusts, and the certificate name matches
+ the destination or server name(s). The Postfix SMTP client was configured
+ to require a verified name, otherwise the verification status would have
+ been just "Trusted".
+
+ PPoossttffiixx SSMMTTPP cclliieenntt:: The "Verified" status may also mean that the Postfix
+ SMTP client successfully matched the expected fingerprint against the
+ remote SMTP server public key or certificate. The expected fingerprint may
+ come from smtp_tls_policy_maps or from TLSA (secure) DNS records. The
+ Postfix SMTP client ignores the CA signature.
+
+ PPoossttffiixx SSMMTTPP sseerrvveerr:: The status is never "Verified", because the Postfix
+ SMTP server never verifies the remote SMTP client name against the names in
+ the client certificate, and because the Postfix SMTP does not expect a
+ specific fingerprint in the client public key or certificate.
CCrreeddiittss
diff --git a/postfix/README_FILES/LMDB_README b/postfix/README_FILES/LMDB_README
index 3fcfd9ab3..12c3767f9 100644
--- a/postfix/README_FILES/LMDB_README
+++ b/postfix/README_FILES/LMDB_README
@@ -16,7 +16,11 @@ This document describes:
* Configuring LMDB settings.
- * Supported minimum LMDB patchlevel.
+ * Using LMDB maps with non-Postfix programs.
+
+ * Required minimum LMDB patchlevel.
+
+ * Credits.
BBuuiillddiinngg PPoossttffiixx wwiitthh LLMMDDBB ssuuppppoorrtt
@@ -51,34 +55,59 @@ Postfix provides one configuration parameter that controls LMDB database
behavior.
* lmdb_map_size (default: 16777216). This setting specifies the initial LMDB
- database size limit in bytes. Each time a database becomes full, its size
+ database size limit in bytes. Each time a database becomes "full", its size
limit is doubled. The maximum size is the largest signed integer value of
"long".
-SSuuppppoorrtteedd mmiinniimmuumm LLMMDDBB ppaattcchhlleevveell
+UUssiinngg LLMMDDBB mmaappss wwiitthh nnoonn--PPoossttffiixx pprrooggrraammss
+
+Programs that use LMDB's built-in locking protocol will corrupt a Postfix LMDB
+database or will read garbage.
+
+Postfix does not use LMDB's built-in locking protocol, because that would
+require world-writable lockfiles, and would violate Postfix security policy.
+Instead, Postfix uses external locks based on fcntl(2) to prevent writers from
+corrupting the database, and to prevent readers from receiving garbage.
+
+See lmdb_table(5) for a detailed description of the locking protocol that all
+programs must use when they access a Postfix LMDB database.
-Currently, Postfix supports LMDB 0.9.11 or later. The supported minimum LMDB
-patchlevel has evolved over time, as the result of deployment experience with
-Postfix.
+RReeqquuiirreedd mmiinniimmuumm LLMMDDBB ppaattcchhlleevveell
+
+Currently, Postfix requires LMDB 0.9.11 or later. The required minimum LMDB
+patchlevel has evolved over time, as the result of Postfix deployment
+experience:
* LMDB 0.9.11 allows Postfix daemons to log an LMDB error message, instead of
falling out of the sky without any notification.
- * LMDB 0.9.10 closes an information leak where LMDB was writing up to 4kbyte-
- chunks of uninitialized heap memory to the database, persisting information
- that was not meant to be persisted, or sharing information that was not
- meant to be shared.
+ * LMDB 0.9.10 closes an information leak where LMDB was writing up to 4-kbyte
+ chunks of uninitialized heap memory to the database. This would persist
+ information that was not meant to be persisted, or share information that
+ was not meant to be shared.
+
+ * LMDB 0.9.9 allows Postfix to use external (fcntl()-based) locks, instead of
+ having to use world-writable LMDB lock files, violating the Postfix
+ security model in multiple ways.
+
+ * LMDB 0.9.8 allows Postfix to recover from a "database full" error without
+ having to close the database. This version adds support to update the
+ database size limit on-the-fly. This is necessary because Postfix database
+ sizes vary with mail server load.
+
+ * LMDB 0.9.7 allows the postmap(1) and postalias(1) commands to use a bulk-
+ mode transaction larger than the amount of physical memory. This is
+ necessary because LMDB supports databases larger than physical memory.
+
+CCrreeddiittss
- * LMDB 0.9.8 allows Postfix to use external (fcntl()-based) locks, instead of
- having to use world-writable LMDB lock files.
+ * Howard Chu contributed the initial Postfix dict_lmdb driver.
- * LMDB 0.9.8 allows an application to recover from a "database full" error
- without having to close the database, by adding support to update the
- database size limit on-the-fly; and it adds support for an application to
- adopt someone elses change to the database size limit, without having to
- close the database.
+ * Wietse Venema wrote an abstraction layer (slmdb) that behaves more like
+ Berkeley DB, NDBM, etc. This layer automatically retries an LMDB request
+ when a database needs to be resized, or after a database was resized by a
+ different process.
- * LMDB 0.9.7 allows the postmap and postalias commands to use a bulk-mode
- transaction larger than the amount of physical memory. This is necessary
- because LMDB supports databases larger than physical memory.
+ * Howard and Wietse went through many iterations with changes to both LMDB
+ and Postfix, with input from Viktor Dukhovni.
diff --git a/postfix/README_FILES/POSTSCREEN_README b/postfix/README_FILES/POSTSCREEN_README
index 1ca03a5c9..c6f527488 100644
--- a/postfix/README_FILES/POSTSCREEN_README
+++ b/postfix/README_FILES/POSTSCREEN_README
@@ -331,29 +331,39 @@ In this phase of the protocol, postscreen(8) implements a number of "deep
protocol" tests. These tests use an SMTP protocol engine that is built into the
postscreen(8) server.
-Important note: deep protocol tests are disabled by default. They are more
+Important note: these protocol tests are disabled by default. They are more
intrusive than the pregreet and DNSBL tests, and they have limitations as
discussed next.
- * When a good client passes the deep protocol tests, postscreen(8) adds the
- client to the temporary whitelist but it cannot hand off the "live"
- connection to a Postfix SMTP server process in the middle of the session.
- Instead, postscreen(8) defers mail delivery attempts with a 4XX status,
- logs the helo/sender/recipient information, and waits for the client to
- disconnect.
+ * The main limitation of "after 220 greeting" tests is that a new client must
+ disconnect after passing these tests (reason: postscreen is not a proxy).
+ Then the client must reconnect from the same IP address before it can
+ deliver mail. The following measures may help to avoid email delays:
+
+ o Allow "good" clients to skip tests with the
+ postscreen_dnsbl_whitelist_threshold feature (Postfix 2.11 and later).
+ This is especially effective for sites such as Google that never retry
+ immediately from the same IP address.
- The next time the client connects it will be allowed to talk to a Postfix
- SMTP server process to deliver its mail. To minimize the impact of this
- limitation, postscreen(8) gives deep protocol tests a relatively long
- expiration time.
+ o Small sites: Configure postscreen(8) to listen on multiple IP
+ addresses, published in DNS as different IP addresses for the same MX
+ hostname or for different MX hostnames. This avoids mail delivery
+ delays with clients that reconnect immediately from the same IP
+ address.
+
+ o Large sites: Share the postscreen(8) cache between different Postfix
+ MTAs with a large-enough memcache_table(5). Again, this avoids mail
+ delivery delays with clients that reconnect immediately from the same
+ IP address.
* postscreen(8)'s built-in SMTP engine does not implement the AUTH, XCLIENT,
- and XFORWARD features. AUTH support may be added in a future version. In
- the mean time, if you need to make these services available on port 25,
- then do not enable the tests after the 220 server greeting.
+ and XFORWARD features. If you need to make these services available on port
+ 25, then do not enable the tests after the 220 server greeting.
+
+ * End-user clients should connect directly to the submission service, so that
+ they never have to deal with postscreen(8)'s tests.
-End-user clients should connect directly to the submission service, so that
-they never have to deal with postscreen(8)'s tests.
+The following "after 220 greeting" tests are available:
* Command pipelining test
* Non-SMTP command test
diff --git a/postfix/RELEASE_NOTES-2.11 b/postfix/RELEASE_NOTES-2.11
index be893f3ec..2cf39396c 100644
--- a/postfix/RELEASE_NOTES-2.11
+++ b/postfix/RELEASE_NOTES-2.11
@@ -27,51 +27,58 @@ with forward secrecy.
verification, where the CA public key or the server certificate is
identified via DNSSEC lookup.
-This feature introduces a new TLS security level called "dane"
-(DNS-based Authentication of Named Entities) that uses DNSSEC to
-look up CA information for a server TLS certificate. The details
+This feature introduces new TLS security levels called "dane" and
+"dane-only" (DNS-based Authentication of Named Entities) that use
+DNSSEC to look up CA or server certificate information. The details
of DANE core protocols are still evolving, as are the details of
how DANE should be used in the context of SMTP. Postfix implements
-what appears to be a "rational" subset of the DANE profiles.
-
-The problem with PKI is that there are literally hundreds of
-organizations world-wide that can provide a certificate in anyone's
-name. There have been widely-published incidents in recent history
-where a certificate authority gave out an inappropriate certificate
-(e.g., a certificate in the name of Microsoft to someone who did
-not represent Microsoft), where a CA was compromised (e.g., DigiNotar,
-Comodo), or where a CA made operational mistakes (e.g., TURKTRUST).
-Another concern is that a legitimate CA might be coerced to provide
-a certificate that allows its government to play man-in-the-middle
-on TLS traffic and observe the plaintext.
+what appears to be a "rational" subset of the DANE profiles that
+is suitable for SMTP.
+
+The problem with conventional PKI is that there are literally
+hundreds of organizations world-wide that can provide a certificate
+in anyone's name. There have been widely-published incidents in
+recent history where a certificate authority gave out an inappropriate
+certificate (e.g., a certificate in the name of Microsoft to someone
+who did not represent Microsoft), where a CA was compromised (e.g.,
+DigiNotar, Comodo), or where a CA made operational mistakes (e.g.,
+TURKTRUST). Another concern is that a legitimate CA might be coerced
+to provide a certificate that allows its government to play
+man-in-the-middle on TLS traffic and observe the plaintext.
Major changes - LMDB database support
-------------------------------------
LMDB is a memory-mapped database that was originally developed as
-part of OpenLDAP. The Postfix LMDB driver was originally written
-by Howard Chu, LMDB's creator. Support for LMDB has evolved throughout
-the Postfix 2.11 development cycle.
+part of OpenLDAP. The Postfix LMDB driver was originally contributed
+by Howard Chu, LMDB's creator.
-LMDB can be used for all Postfix lookup table and cache storage.
-It is the first persistent Postfix database that can be shared among
+LMDB can be used for all Postfix lookup tables and caches. It is
+the first persistent Postfix database that can be shared among
multiple writers such as postscreen daemons (Postfix already supported
-non-persistent memcached caches). See lmdb_table(5) and LMDB_README
-for further information.
+shared non-persistent memcached caches). See lmdb_table(5) and
+LMDB_README for further information, including how to access Postfix
+LMDB databases with non-Postfix programs.
-Postfix currently supports LMDB version 0.9.11 and later. The minimum
+Postfix currently requires LMDB version 0.9.11 or later. The minimum
version may change over time in the light of deployment experience.
Major changes - postscreen whitelisting
---------------------------------------
-[Feature 20130512] Allow an SMTP client to skip postscreen(8) tests
-based on its postscreen_dnsbl_sites score.
+[Feature 20130512] Allow a remote SMTP client to skip postscreen(8)
+tests based on its postscreen_dnsbl_sites score.
-Specify a negative "postscreen_dnsbl_whitelist_threshold" to enable
-this feature. When a client passes the threshold value without
-having failed other tests, all pending or disabled tests are flagged
-as completed.
+Specify a negative "postscreen_dnsbl_whitelist_threshold" value to
+enable this feature. When a client passes the threshold value
+without having failed other tests, all pending or disabled tests
+are flagged as completed.
+
+This feature can mitigate the email delays due to "after 220 greeting"
+protocol tests, which otherwise require that a client reconnects
+before it can deliver mail. Some providers such as Google don't
+retry from the same IP address. This can result in large email
+delivery delays.
Major changes - recipient_delimiter
-----------------------------------
@@ -119,9 +126,9 @@ configurations.
Major changes - milter
----------------------
-[Feature 20131126] Support for ESMTP parameters NOTIFY and ORCPT
-in the SMFIR_ADDRCPT_PAR (add recipient) request. Credits: Andrew
-Ayer.
+[Feature 20131126] Support for ESMTP parameters "NOTIFY" and "ORCPT"
+in the SMFIR_ADDRCPT_PAR (add recipient with parameters) request.
+Credits: Andrew Ayer.
Major changes - mysql
---------------------
diff --git a/postfix/html/FORWARD_SECRECY_README.html b/postfix/html/FORWARD_SECRECY_README.html
index 7ce054d6d..af0f53d15 100644
--- a/postfix/html/FORWARD_SECRECY_README.html
+++ b/postfix/html/FORWARD_SECRECY_README.html
@@ -25,11 +25,11 @@ TLS Forward Secrecy in Postfix
as forged DNS replies or forged TLS server certificates. If such
attacks are a concern, then the SMTP client will need to authenticate
the remote SMTP server in a sufficiently-secure manner. For example,
-by the fingerprint of the public key or certificate. Conventional
-PKI relies on many trusted parties and is easily subverted by a
-state-funded adversary.
+by the fingerprint of a (CA or leaf) public key or certificate.
+Conventional PKI relies on many trusted parties and is easily
+subverted by a state-funded adversary.
- Background
+ Overview
Postfix supports forward secrecy of TLS network communication
since version 2.2. This support was adopted from Lutz Jänicke's
@@ -38,36 +38,15 @@ will focus on TLS Forward Secrecy in the Postfix SMTP client and
server. See TLS_README for a general
description of Postfix TLS support.
-
+ Topics covered in this document:
- The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy")
-is used to describe security protocols in which the confidentiality
-of past traffic is not compromised when long-term keys used by either
-or both sides are later disclosed.
+
- Forward secrecy is accomplished by negotiating session keys
-using per-session cryptographically-strong random numbers that are
-not saved, and signing the exchange with long-term authentication
-keys. Later disclosure of the long-term keys allows impersonation
-of the key holder from that point on, but not recovery of prior
-traffic, since with forward secrecy, the discarded random key
-agreement inputs are not available to the attacker.
+-
Give me some background on forward secrecy in Postfix
- Forward secrecy is only "perfect" when brute-force attacks on
-the key agreement algorithm are impractical even for the best-funded
-adversary and the random-number generators used by both parties are
-sufficiently strong. Otherwise, forward secrecy leaves the attacker
-with the challenge of cracking the key-agreement protocol, which
-is likely quite computationally intensive, but may be feasible for
-sessions of sufficiently high value. Thus forward secrecy places
-cost constraints on the efficacy of bulk surveillance, recovering
-all past traffic is generally infeasible, and even recovery of
-individual sessions may be infeasible given a sufficiently-strong
-key agreement method.
-
- Topics covered in this document:
+
- And last but not least, for the impatient:
+
-
+ The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy")
+is used to describe security protocols in which the confidentiality
+of past traffic is not compromised when long-term keys used by either
+or both sides are later disclosed.
-- Configuring forward secrecy, quick and dirty
+
Forward secrecy is accomplished by negotiating session keys
+using per-session cryptographically-strong random numbers that are
+not saved, and signing the exchange with long-term authentication
+keys. Later disclosure of the long-term keys allows impersonation
+of the key holder from that point on, but not recovery of prior
+traffic, since with forward secrecy, the discarded random key
+agreement inputs are not available to the attacker.
-
+ Forward secrecy is only "perfect" when brute-force attacks on
+the key agreement algorithm are impractical even for the best-funded
+adversary and the random-number generators used by both parties are
+sufficiently strong. Otherwise, forward secrecy leaves the attacker
+with the challenge of cracking the key-agreement protocol, which
+is likely quite computationally intensive, but may be feasible for
+sessions of sufficiently high value. Thus forward secrecy places
+cost constraints on the efficacy of bulk surveillance, recovering
+all past traffic is generally infeasible, and even recovery of
+individual sessions may be infeasible given a sufficiently-strong
+key agreement method.
@@ -286,11 +293,13 @@ by the vendor, as in some versions of RedHat Linux.
- EDH Client support (Postfix ≥ 2.2)
+ EDH Client support (Postfix ≥ 2.2, all supported OpenSSL
+versions)
This works "out of the box" without additional configuration.
- EDH Server support (Postfix ≥ 2.2)
+ EDH Server support (Postfix ≥ 2.2, all supported OpenSSL
+versions)
Optionally generate non-default Postfix SMTP server EDH parameters
for improved security against pre-computation attacks and for
@@ -448,9 +457,9 @@ Postfix logging mean?
attacks to different degrees. If such attacks are a concern, then
the SMTP client will need to authenticate the remote SMTP server
in a sufficiently-secure manner. For example, by the fingerprint
-of the public key or certificate. Remember that conventional PKI
-relies on many trusted parties and is easily subverted by a
-state-funded adversary.
+of a (CA or leaf) public key or certificate. Remember that
+conventional PKI relies on many trusted parties and is easily
+subverted by a state-funded adversary.
@@ -509,27 +518,37 @@ name.
Postfix SMTP server: The remote SMTP client certificate
was signed by a CA that the Postfix SMTP server trusts. The Postfix
SMTP server never verifies the remote SMTP client name against the
-names in the certificate. Since the client chooses to connect to
-the server, the Postfix SMTP server has no expectation of a particular
-client hostname.
+names in the client certificate. Since the client chooses to connect
+to the server, the Postfix SMTP server has no expectation of a
+particular client hostname.
-- Verified (peer certificate signed by trusted CA, verified
-peer name)
+- Verified (peer certificate signed by trusted CA and
+verified peer name; or: peer certificate with expected public-key
+or certificate fingerprint)
-
Postfix SMTP client: The remote SMTP server's certificate
-was signed by a CA that the Postfix SMTP client trusts, and it
-matches one of the expected server names. This implies that the
-Postfix SMTP client enforced verification for the destination server
-name, otherwise the verification status would have been just
-"Trusted".
+was signed by a CA that the Postfix SMTP client trusts, and the
+certificate name matches the destination or server name(s). The
+Postfix SMTP client was configured to require a verified name,
+otherwise the verification status would have been just "Trusted".
+
+
+ Postfix SMTP client: The "Verified" status may also
+mean that the Postfix SMTP client successfully matched the expected
+fingerprint against the remote SMTP server public key or certificate.
+The expected fingerprint may come from smtp_tls_policy_maps or from
+TLSA (secure) DNS records. The Postfix SMTP client ignores the CA
+signature.
Postfix SMTP server: The status is never "Verified",
-as the Postfix SMTP server never verifies the remote SMTP client
-name against the names in the certificate.
+because the Postfix SMTP server never verifies the remote SMTP
+client name against the names in the client certificate, and because
+the Postfix SMTP does not expect a specific fingerprint in the
+client public key or certificate.
diff --git a/postfix/html/LMDB_README.html b/postfix/html/LMDB_README.html
index 554320332..35e486f54 100644
--- a/postfix/html/LMDB_README.html
+++ b/postfix/html/LMDB_README.html
@@ -34,7 +34,11 @@ the database file without the ".lmdb" suffix.
-
Configuring LMDB settings.
- -
Supported minimum LMDB patchlevel.
+ -
Using LMDB maps with non-Postfix programs.
+
+ -
Required minimum LMDB patchlevel.
+
+ -
Credits.
@@ -89,17 +93,32 @@ LMDB database behavior.
-
+
+
+ Programs that use LMDB's built-in locking protocol will corrupt
+a Postfix LMDB database or will read garbage.
+
+ Postfix does not use LMDB's built-in locking protocol, because
+that would require world-writable lockfiles, and would violate
+Postfix security policy. Instead, Postfix uses external locks based
+on fcntl(2) to prevent writers from corrupting the database, and
+to prevent readers from receiving garbage.
+
+ See lmdb_table(5) for a detailed description of the locking
+protocol that all programs must use when they access a Postfix LMDB
+database.
- Currently, Postfix supports LMDB 0.9.11 or later. The supported
+
+
+ Currently, Postfix requires LMDB 0.9.11 or later. The required
minimum LMDB patchlevel has evolved over time, as the result of
-deployment experience with Postfix.
+Postfix deployment experience:
@@ -108,27 +127,44 @@ message, instead of falling out of the sky without any notification.
-
LMDB 0.9.10 closes an information leak where LMDB was
-writing up to 4kbyte-chunks of uninitialized heap memory to the
-database, persisting information that was not meant to be persisted,
-or sharing information that was not meant to be shared.
-
- -
LMDB 0.9.8 allows Postfix to use external (fcntl()-based)
-locks, instead of having to use world-writable LMDB lock files.
+writing up to 4-kbyte chunks of uninitialized heap memory to the
+database. This would persist information that was not meant to be
+persisted, or share information that was not meant to be shared.
- -
LMDB 0.9.8 allows an application to recover from a "database
-full" error without having to close the database, by adding support
-to update the database size limit on-the-fly; and it adds support
-for an application to adopt someone elses change to the database
-size limit, without having to close the database.
+ -
LMDB 0.9.9 allows Postfix to use external (fcntl()-based)
+locks, instead of having to use world-writable LMDB lock files,
+violating the Postfix security model in multiple ways.
- -
LMDB 0.9.7 allows the postmap and postalias commands to
-use a bulk-mode transaction larger than the amount of physical
+
-
LMDB 0.9.8 allows Postfix to recover from a "database full"
+error without having to close the database. This version adds support
+to update the database size limit on-the-fly. This is necessary
+because Postfix database sizes vary with mail server load.
+
+ -
LMDB 0.9.7 allows the postmap(1) and postalias(1) commands
+to use a bulk-mode transaction larger than the amount of physical
memory. This is necessary because LMDB supports databases larger
than physical memory.
+
+
+
+
+-
Howard Chu contributed the initial Postfix dict_lmdb driver.
+
+
+ -
Wietse Venema wrote an abstraction layer (slmdb) that
+behaves more like Berkeley DB, NDBM, etc. This layer automatically
+retries an LMDB request when a database needs to be resized, or
+after a database was resized by a different process.
+
+ -
Howard and Wietse went through many iterations with changes
+to both LMDB and Postfix, with input from Viktor Dukhovni.
+
+
+