Adding upstream version 3.7.10.upstream/3.7.10upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 557 insertions, 0 deletions

diff --git a/README_FILES/FORWARD_SECRECY_README b/README_FILES/FORWARD_SECRECY_README
new file mode 100644
index 0000000..3eb707c
--- /dev/null
+++ b/README_FILES/FORWARD_SECRECY_README
@@ -0,0 +1,557 @@
+ TTLLSS FFoorrwwaarrdd SSeeccrreeccyy iinn PPoossttffiixx
+
+-------------------------------------------------------------------------------
+
+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 a (CA or leaf)
+public key or certificate. Conventional PKI relies on many trusted parties and
+is easily subverted by a state-funded adversary.
+
+OOvveerrvviieeww
+
+Postfix supports forward secrecy of TLS network communication since version
+2.2. This support was adopted from Lutz Ja"nicke's "Postfix TLS patch" for
+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
+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.
+
+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.
+
+FFoorrwwaarrdd SSeeccrreeccyy iinn TTLLSS
+
+Early implementations of the SSL protocol do not provide forward secrecy (some
+provide it only with artificially-weakened "export" cipher suites, but we will
+ignore those here). The client sends a random "pre-master secret" to the server
+encrypted with the server's RSA public key. The server decrypts this with its
+private key, and uses it together with other data exchanged in the clear to
+generate the session key. An attacker with access to the server's private key
+can perform the same computation at any later time. The TLS library in Windows
+XP and Windows Server 2003 only supported cipher suites of this type, and
+Exchange 2003 servers largely do not support forward secrecy.
+
+Later revisions to the TLS protocol introduced forward-secrecy cipher suites in
+which the client and server implement a key exchange protocol based on
+ephemeral secrets. Sessions encrypted with one of these newer cipher suites are
+not compromised by future disclosure of long-term authentication keys.
+
+The key-exchange algorithms used for forward secrecy require the TLS server to
+designate appropriate "parameters" consisting of a mathematical "group" and an
+element of that group called a "generator". Presently, there are two flavors of
+"groups" that work with PFS:
+
+  * PPrriimmee--ffiieelldd ggrroouuppss ((EEDDHH)):: The server needs to be configured with a
+    suitably-large prime and a corresponding "generator". The acronym for
+    forward secrecy over prime fields is EDH for Ephemeral Diffie-Hellman (also
+    abbreviated as DHE).
+
+  * EElllliippttiicc--ccuurrvvee ggrroouuppss ((EEEECCDDHH)):: The server needs to be configured with a
+    "named curve". These offer better security at lower computational cost than
+    prime field groups, but are not as widely implemented. The acronym for the
+    elliptic curve version is EECDH which is short for Ephemeral Elliptic Curve
+    Diffie-Hellman (also abbreviated as ECDHE).
+
+It is not essential to know what these are, but one does need to know that
+OpenSSL supports EECDH with version 1.0.0 or later. Thus the configuration
+parameters related to Elliptic-Curve forward secrecy are available when Postfix
+is linked with OpenSSL >= 1.0.0 (provided EC support has not been disabled by
+the vendor, as in some versions of RedHat Linux).
+
+Elliptic curves used in cryptography are typically identified by a "name" that
+stands for a set of well-known parameter values, and it is these "names" (or
+associated ASN.1 object identifiers) that are used in the TLS protocol. On the
+other hand, with TLS there are no specially designated prime field groups, so
+each server is free to select its own suitably-strong prime and generator.
+
+FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP SSeerrvveerr
+
+The Postfix >= 2.2 SMTP server supports forward secrecy in its default
+configuration. If the remote SMTP client prefers cipher suites with forward
+secrecy, then the traffic between the server and client will resist decryption
+even if the server's long-term authentication keys are later compromised.
+
+Some remote SMTP clients may support forward secrecy, but prefer cipher suites
+without forward secrecy. In that case, Postfix >= 2.8 could be configured to
+ignore the client's preference with the main.cf setting "tls_preempt_cipherlist
+= yes". However, this will likely cause interoperability issues with older
+Exchange servers and is not recommended for now.
+
+EEDDHH SSeerrvveerr ssuuppppoorrtt
+
+Postfix >= 2.2 supports 1024-bit-prime EDH out of the box, with no additional
+configuration, but you may want to override the default prime to be 2048 bits
+long, and you may want to regenerate your primes periodically. See the quick-
+start section for details. With Postfix >= 3.1 the out of the box (compiled-in)
+EDH prime size is 2048 bits.
+
+With prime-field EDH, OpenSSL wants the server to provide two explicitly-
+selected (prime, generator) combinations. One for the now long-obsolete
+"export" cipher suites, and another for non-export cipher suites. Postfix has
+two such default combinations compiled in, but also supports explicitly-
+configured overrides.
+
+  * The "export" EDH parameters are used only with the obsolete "export"
+    ciphers. To use a non-default prime, generate a 512-bit DH parameter file
+    and set smtpd_tls_dh512_param_file to the filename (see the quick-start
+    section for details). With Postfix releases after the middle of 2015 the
+    default opportunistic TLS cipher grade (smtpd_tls_ciphers) is "medium" or
+    stronger, and export ciphers are no longer used.
+
+  * The non-export EDH parameters are used for all other EDH cipher suites. To
+    use a non-default prime, generate a 1024-bit or 2048-bit DH parameter file
+    and set smtpd_tls_dh1024_param_file to the filename. Despite the name this
+    is simply the non-export parameter file and the prime need not actually be
+    1024 bits long (see the quick-start section for details).
+
+As of mid-2015, SMTP clients are starting to reject TLS handshakes with primes
+smaller than 2048 bits. Each site needs to determine which prime size works
+best for the majority of its clients. See the quick-start section for the
+recommended configuration to work around this issue.
+
+EEEECCDDHH SSeerrvveerr ssuuppppoorrtt
+
+Postfix >= 2.6 supports NIST P-256 EECDH when built with OpenSSL >= 1.0.0. When
+the remote SMTP client also supports EECDH and implements the P-256 curve,
+forward secrecy just works.
+
+    Note: With Postfix 2.6 and 2.7, enable EECDH by setting the main.cf
+    parameter smtpd_tls_eecdh_grade to "strong".
+
+The elliptic curve standards are evolving, with new curves introduced in RFC
+8031 to augment or replace the NIST curves tarnished by the Snowden
+revelations. Fortunately, TLS clients advertise their list of supported curves
+to the server so that servers can choose newer stronger curves when mutually
+supported. OpenSSL 1.0.2 released in January 2015 was the first release to
+implement negotiation of supported curves in TLS servers. In older OpenSSL
+releases, the server is limited to selecting a single widely supported curve.
+
+With Postfix prior to 3.2 or OpenSSL prior to 1.0.2, only a single server-side
+curve can be configured, by specifying a suitable EECDH "grade":
+
+        smtpd_tls_eecdh_grade = strong | ultra
+        # Underlying curves, best not changed:
+        # tls_eecdh_strong_curve = prime256v1
+        # tls_eecdh_ultra_curve = secp384r1
+
+Postfix >= 3.2 supports the curve negotiation API of OpenSSL >= 1.0.2. When
+using this software combination, the default setting of "smtpd_tls_eecdh_grade"
+changes to "auto", which selects a curve that is supported by both the server
+and client. The list of candidate curves can be configured via
+"tls_eecdh_auto_curves", which can be used to configure a prioritized list of
+supported curves (most preferred first) on both the server and client. The
+default list is suitable for most users.
+
+FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP CClliieenntt
+
+The Postfix >= 2.2 SMTP client supports forward secrecy in its default
+configuration. All supported OpenSSL releases support EDH key exchange. OpenSSL
+releases >= 1.0.0 also support EECDH key exchange (provided elliptic-curve
+support has not been disabled by the vendor as in some versions of RedHat
+Linux). If the remote SMTP server supports cipher suites with forward secrecy
+(and does not override the SMTP client's cipher preference), then the traffic
+between the server and client will resist decryption even if the server's long-
+term authentication keys are later compromised.
+
+Postfix >= 3.2 supports the curve negotiation API of OpenSSL >= 1.0.2. The list
+of candidate curves can be changed via the "tls_eecdh_auto_curves"
+configuration parameter, which can be used to select a prioritized list of
+supported curves (most preferred first) on both the Postfix SMTP server and
+SMTP client. The default list is suitable for most users.
+
+The default Postfix SMTP client cipher lists are correctly ordered to prefer
+EECDH and EDH cipher suites ahead of similar cipher suites that don't implement
+forward secrecy. Administrators are strongly discouraged from changing the
+cipher list definitions.
+
+The default minimum cipher grade for opportunistic TLS is "medium" for Postfix
+releases after the middle of 2015, "export" for older releases. Changing the
+minimum cipher grade does not change the cipher preference order. Note that
+cipher grades higher than "medium" exclude Exchange 2003 and likely other MTAs,
+thus a "high" cipher grade should be chosen only on a case-by-case basis via
+the TLS policy table.
+
+GGeettttiinngg ssttaarrtteedd,, qquuiicckk aanndd ddiirrttyy
+
+EEEECCDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 22..22 wwiitthh OOppeennSSSSLL >>== 11..00..00))
+
+This works "out of the box" with no need for additional configuration.
+
+Postfix >= 3.2 supports the curve negotiation API of OpenSSL >= 1.0.2. The list
+of candidate curves can be changed via the "tls_eecdh_auto_curves"
+configuration parameter, which can be used to select a prioritized list of
+supported curves (most preferred first) on both the Postfix SMTP server and
+SMTP client. The default list is suitable for most users.
+
+EEEECCDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..66 wwiitthh OOppeennSSSSLL >>== 11..00..00))
+
+With Postfix 2.6 and 2.7, enable elliptic-curve support in the Postfix SMTP
+server. This is the default with Postfix >= 2.8. Note, however, that elliptic-
+curve support may be disabled by the vendor, as in some versions of RedHat
+Linux.
+
+    /etc/postfix/main.cf:
+        # Postfix 2.6 & 2.7 only. EECDH is on by default with Postfix >= 2.8.
+        # The default grade is "auto" with Postfix >= 3.2.
+        smtpd_tls_eecdh_grade = strong
+
+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,, 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-
+patched Exim SMTP clients that require a >= 2048-bit length for the non-export
+prime.
+
+With Postfix >= 3.7 built against OpenSSL version is 3.0.0 or later, when the
+value of smtpd_tls_dh1024_param_file is either empty or "aauuttoo", the EDH
+parameter selection is delegated to the OpenSSL library, which selects
+appropriate parameters based on the TLS handshake. This choice is likely to be
+the most interoperable with SMTP clients using various TLS libraries, and
+custom local parameters are no longer recommended when using Postfix >= 3.7
+built against OpenSSL 3.0.0. Just leave smtpd_tls_dh1024_param_file at its
+default value (both in main.cf(5) and any master.cf(5) overrides, and let
+OpenSSL do the work.
+
+Otherwise, execute as root (prime group generation can take a few seconds to a
+few minutes):
+
+    # cd /etc/postfix
+    # umask 022
+    # openssl dhparam -out dh512.tmp 512 && mv dh512.tmp dh512.pem
+    # openssl dhparam -out dh1024.tmp 1024 && mv dh1024.tmp dh1024.pem
+    # openssl dhparam -out dh2048.tmp 2048 && mv dh2048.tmp dh2048.pem
+    # chmod 644 dh512.pem dh1024.pem dh2048.pem
+
+The Postfix SMTP server EDH parameter files are not secret, after all these
+parameters are sent to all remote SMTP clients in the clear. Mode 0644 is
+appropriate.
+
+You can improve security against pre-computation attacks further by
+regenerating the Postfix SMTP server EDH parameters periodically (an hourly or
+daily cron job running the above commands as root can automate this task).
+
+Once the parameters are in place, update main.cf as follows:
+
+    /etc/postfix/main.cf:
+        smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
+        smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
+
+If some of your MSA clients don't support 2048-bit EDH, you may need to adjust
+the submission entry in master.cf accordingly:
+
+    /etc/postfix/master.cf:
+        submission inet n       -       n       -       -       smtpd
+            # Some submission clients may not yet do 2048-bit EDH, if such
+            # clients use your MSA, configure 1024-bit EDH instead.  However,
+            # as of mid-2015, many submission clients no longer accept primes
+            # with less than 2048-bits.  Each site needs to determine which
+            # type of client is more important to support.
+            -o smtpd_tls_dh1024_param_file=${config_directory}/dh1024.pem
+            -o smtpd_tls_security_level=encrypt
+            -o smtpd_sasl_auth_enable=yes
+            ...
+
+HHooww ccaann II sseeee tthhaatt aa ccoonnnneeccttiioonn hhaass ffoorrwwaarrdd sseeccrreeccyy??
+
+Postfix can be configured to report information about the negotiated cipher,
+the corresponding key lengths, and the remote peer certificate or public-key
+verification status.
+
+  * With "smtp_tls_loglevel = 1" and "smtpd_tls_loglevel = 1", the Postfix SMTP
+    client and server will log TLS connection information to the maillog file.
+    The general logfile format is shown below. With TLS 1.3 there may be
+    additional properties logged after the cipher name and bits.
+
+        postfix/smtp[process-id]: Untrusted TLS connection established
+        to host.example.com[192.168.0.2]:25: TLSv1 with cipher cipher-name
+        (actual-key-size/raw-key-size bits)
+
+        postfix/smtpd[process-id]: Anonymous TLS connection established
+        from host.example.com[192.168.0.2]: TLSv1 with cipher cipher-name
+        (actual-key-size/raw-key-size bits)
+
+  * With "smtpd_tls_received_header = yes", the Postfix SMTP server will record
+    TLS connection information in the Received: header in the form of comments
+    (text inside parentheses). The general format depends on the
+    smtpd_tls_ask_ccert setting. With TLS 1.3 there may be additional
+    properties logged after the cipher name and bits.
+
+        Received: from host.example.com (host.example.com [192.168.0.2])
+                (using TLSv1 with cipher cipher-name
+                (actual-key-size/raw-key-size bits))
+                (Client CN "host.example.com", Issuer "John Doe" (not
+        verified))
+
+        Received: from host.example.com (host.example.com [192.168.0.2])
+                (using TLSv1 with cipher cipher-name
+                (actual-key-size/raw-key-size bits))
+                (No client certificate requested)
+
+    TLS 1.3 examples. Some of the new attributes may not appear when not
+    applicable or not available in older versions of the OpenSSL library.
+
+        Received: from localhost (localhost [127.0.0.1])
+                (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
+        bits)
+                 key-exchange X25519 server-signature RSA-PSS (2048 bits)
+        server-digest SHA256)
+                (No client certificate requested)
+
+        Received: from localhost (localhost [127.0.0.1])
+                (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
+        bits)
+                 key-exchange X25519 server-signature RSA-PSS (2048 bits)
+        server-digest SHA256
+                 client-signature ECDSA (P-256) client-digest SHA256)
+                (Client CN "example.org", Issuer "example.org" (not verified))
+
+      o The "key-exchange" attribute records the type of "Diffie-Hellman" group
+        used for key agreement. Possible values include "DHE", "ECDHE",
+        "X25519" and "X448". With "DHE", the bit size of the prime will be
+        reported in parentheses after the algorithm name, with "ECDHE", the
+        curve name.
+
+      o The "server-signature" attribute shows the public key signature
+        algorithm used by the server. With "RSA-PSS", the bit size of the
+        modulus will be reported in parentheses. With "ECDSA", the curve name.
+        If, for example, the server has both an RSA and an ECDSA private key
+        and certificate, it will be possible to track which one was used for a
+        given connection.
+
+      o The new "server-digest" attribute records the digest algorithm used by
+        the server to prepare handshake messages for signing. The Ed25519 and
+        Ed448 signature algorithms do not make use of such a digest, so no
+        "server-digest" will be shown for these signature algorithms.
+
+      o When a client certificate is requested with "smtpd_tls_ask_ccert" and
+        the client uses a TLS client-certificate, the "client-signature" and
+        "client-digest" attributes will record the corresponding properties of
+        the client's TLS handshake signature.
+
+The next sections will explain what cipher-name, key-size, and peer
+verification status information to expect.
+
+WWhhaatt cciipphheerrss pprroovviiddee ffoorrwwaarrdd sseeccrreeccyy??
+
+There are dozens of ciphers that support forward secrecy. What follows is the
+beginning of a list of 51 ciphers available with OpenSSL 1.0.1e. The list is
+sorted in the default Postfix preference order. It excludes null ciphers that
+only authenticate and don't encrypt, together with export and low-grade ciphers
+whose encryption is too weak to offer meaningful secrecy. The first column
+shows the cipher name, and the second shows the key exchange method.
+
+    $ openssl ciphers -v \
+            'aNULL:-aNULL:kEECDH:kEDH:+RC4:!eNULL:!EXPORT:!LOW:@STRENGTH' |
+        awk '{printf "%-32s %s\n", $1, $3}'
+    AECDH-AES256-SHA                 Kx=ECDH
+    ECDHE-RSA-AES256-GCM-SHA384      Kx=ECDH
+    ECDHE-ECDSA-AES256-GCM-SHA384    Kx=ECDH
+    ECDHE-RSA-AES256-SHA384          Kx=ECDH
+    ECDHE-ECDSA-AES256-SHA384        Kx=ECDH
+    ECDHE-RSA-AES256-SHA             Kx=ECDH
+    ECDHE-ECDSA-AES256-SHA           Kx=ECDH
+    ADH-AES256-GCM-SHA384            Kx=DH
+    ADH-AES256-SHA256                Kx=DH
+    ADH-AES256-SHA                   Kx=DH
+    ADH-CAMELLIA256-SHA              Kx=DH
+    DHE-DSS-AES256-GCM-SHA384        Kx=DH
+    DHE-RSA-AES256-GCM-SHA384        Kx=DH
+    DHE-RSA-AES256-SHA256            Kx=DH
+    ...
+
+To date, all ciphers that support forward secrecy have one of five values for
+the first component of their OpenSSL name: "AECDH", "ECDHE", "ADH", "EDH" or
+"DHE". Ciphers that don't implement forward secrecy have names that don't start
+with one of these prefixes. This pattern is likely to persist until some new
+key-exchange mechanism is invented that also supports forward secrecy.
+
+The actual key length and raw algorithm key length are generally the same with
+non-export ciphers, but they may differ for the legacy export ciphers where the
+actual key is artificially shortened.
+
+Starting with TLS 1.3 the cipher name no longer contains enough information to
+determine which forward-secrecy scheme was employed, but TLS 1.3 aallwwaayyss uses
+forward-secrecy. On the client side, up-to-date Postfix releases log additional
+information for TLS 1.3 connections, reporting the signature and key exchange
+algorithms. Two examples below (the long single line messages are folded across
+multiple lines for readability):
+
+    postfix/smtp[process-id]:
+      Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
+      TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+      key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
+    SHA256
+      client-signature ECDSA (P-256) client-digest SHA256
+
+    postfix/smtp[process-id]:
+      Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
+      TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+      key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest
+    SHA256
+
+In the above connections, the "key-exchange" value records the "Diffie-Hellman"
+algorithm used for key agreement. The "server-signature" value records the
+public key algorithm used by the server to sign the key exchange. The "server-
+digest" value records any hash algorithm used to prepare the data for signing.
+With "ED25519" and "ED448", no separate hash algorithm is used.
+
+Examples of Postfix SMTP server logging:
+
+    postfix/smtpd[process-id]:
+      Untrusted TLS connection established from localhost[127.0.0.1]:25:
+      TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+      key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
+    SHA256
+      client-signature ECDSA (P-256) client-digest SHA256
+
+    postfix/smtpd[process-id]:
+      Anonymous TLS connection established from localhost[127.0.0.1]:
+      TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+      server-signature RSA-PSS (2048 bits) server-digest SHA256
+
+    postfix/smtpd[process-id]:
+      Anonymous TLS connection established from localhost[127.0.0.1]:
+      TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+      server-signature ED25519
+
+Note that Postfix >= 3.4 server logging may also include a "to sni-name"
+element to record the use of an alternate server certificate chain for the
+connection in question. This happens when the client uses the TLS SNI
+extension, and the server selects a non-default certificate chain based on the
+client's SNI value:
+
+    postfix/smtpd[process-id]:
+      Untrusted TLS connection established from client.example[192.0.2.1]
+      to server.example: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
+    bits)
+      key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
+    SHA256
+      client-signature ECDSA (P-256) client-digest SHA256
+
+WWhhaatt ddoo ""AAnnoonnyymmoouuss"",, ""UUnnttrruusstteedd"",, eettcc.. iinn PPoossttffiixx llooggggiinngg mmeeaann??
+
+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 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
+    Postfix SMTP client does not verify any information in the peer
+    certificate. In this case it enables and prefers anonymous cipher suites in
+    which the remote SMTP server does not present a certificate (these ciphers
+    offer forward secrecy of necessity). When the remote SMTP server also
+    supports anonymous TLS, and agrees to such a cipher suite, the verification
+    status will be logged as "Anonymous".
+
+    PPoossttffiixx SSMMTTPP sseerrvveerr:: This is by far most common, as client certificates are
+    optional, and the Postfix SMTP server does not request client certificates
+    by default (see smtpd_tls_ask_ccert). Even when client certificates are
+    requested, the remote SMTP client might not send a certificate. Unlike the
+    Postfix SMTP client, the Postfix SMTP server "anonymous" verification
+    status does not imply that the cipher suite is anonymous, which corresponds
+    to the server not sending a certificate.
+
+UUnnttrruusstteedd (peer certificate not signed by trusted CA)
+    PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server presented a certificate, but
+    the Postfix SMTP client was unable to check the issuing CA signature. With
+    opportunistic TLS this is common with remote SMTP servers that don't
+    support anonymous cipher suites.
+
+    PPoossttffiixx SSMMTTPP sseerrvveerr:: The remote SMTP client presented a certificate, but
+    the Postfix SMTP server was unable to check the issuing CA signature. This
+    can happen when the server is configured to request client certificates
+    (see smtpd_tls_ask_ccert).
+
+TTrruusstteedd (peer certificate signed by trusted CA, unverified peer name)
+    PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server's certificate was signed by a
+    CA that the Postfix SMTP client trusts, but either the client was not
+    configured to verify the destination server name against the certificate,
+    or the server certificate did not contain any matching names. This is
+    common with opportunistic TLS (smtp_tls_security_level is "may" or else
+    "dane" with no usable TLSA DNS records) when the Postfix SMTP client's
+    trusted CAs can verify the authenticity of the remote SMTP server's
+    certificate, but the client is not configured or unable to verify the
+    server name.
+
+    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 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 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 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 server does not expect
+    a specific fingerprint in the client public key or certificate.
+
+CCrreeddiittss
+
+  * TLS support for Postfix was originally developed by Lutz Ja"nicke at
+    Cottbus Technical University.
+  * Wietse Venema adopted and restructured the code and documentation.
+  * Viktor Dukhovni implemented support for many subsequent TLS features,
+    including EECDH, and authored the initial version of this document.
+