b) when the Postfix SMTP client initiates a TLS handshake
with a remote SMTP server. See RELEASE_NOTES for details.
Viktor Dukhovni. Files: mantools/postlink, proto/TLS_README.html,
- proto/postconf.proto, global/mail_params.h,
+ proto/postconf.proto, RELEASE_NOTES, global/mail_params.h,
posttls-finger/posttls-finger.c, smtp/lmtp_params.c,
smtp/smtp.c, smtp/smtp.h, smtp/smtp_params.c, smtp/smtp_proto.c,
smtp/smtp_tls_policy.c, smtpd/smtpd.c, smtpd/smtpd_check.c,
tls/tls_proxy_client_scan.c, tls/tls_proxy_context_print.c,
tls/tls_proxy_context_scan.c, tls/tls_server.c, tls/tls_verify.c,
tlsproxy/tlsproxy.c.
+
+20230808
+
+ Documentation loose ends. Files: proto/postconf.proto,
+ RELEASE_NOTES.
certificate. The Postfix SMTP client will still accept a server
public key certificate instead of a public key.
-- At the "dane" security level, the Postfix SMTP client will ignore
- smtp_tls_enable_rpk or enable_rpk settings, and will request that
- a remote SMTP server sends an RFC7250 raw public key instead of
- an X.509 certificate when all valid TLSA records specify only
- server public keys (no certificates). The Postfix SMTP client
- will still accept a server public key certificate.
+- At the "secure" and "verify" security level, the Postfix SMTP
+ client will ignore smtp_tls_enable_rpk or enable_rpk settings,
+ because these levels require a server certificate.
+
+- At the "dane" and "dane-only" security levels, the Postfix SMTP
+ client will ignore smtp_tls_enable_rpk or enable_rpk settings,
+ and will request that a remote SMTP server sends an RFC7250 raw
+ public key instead of an X.509 certificate when all valid TLSA
+ records specify only server public keys (no certificates). The
+ Postfix SMTP client will still accept a server public key
+ certificate.
- The Postfix SMTP client and server always send a raw public key
instead of a certificate, if solicited by the remote SMTP peer
Caution: enabling Postfix raw key support will break authentication
based on certificate fingerprints in check_ccert_access or
-smtp_policy_maps, when a remote peer's TLS implementation starts
+smtp_tls_policy_maps, when a remote peer's TLS implementation starts
to send a raw public key instead of a certificate. The solution is
-to always use public key fingerprint patterns; these will match
-not only a "raw" public key, but also the public key in a certificate.
-
-To detect such problems before they happen, the Postfix SMTP client
-and server will log a warning when they request an RFC7250 raw
-public key instead of an X.509 certificate, the remote peer sends
-a certificate instead of a public key, and check_ccert_access or
-smtp_policy_maps has a matching fingerprint for the certificate but
-not for the public key in that certificate.
+to always use public key fingerprint patterns; these will match not
+only a "raw" public key, but also the public key in a certificate.
+
+To detect such problems before they happen, the Postfix SMTP server
+will log a warning when it requests an RFC7250 raw public key instead
+of an X.509 certificate, the remote peer sends a certificate instead
+of a public key, and check_ccert_access has a matching fingerprint
+for the certificate but not for the public key in that certificate.
+There is no corresponding warning from the Postfix SMTP client.
For instructions to generate public-key fingerprints, see the
postconf(5) man pages for smtp_tls_enable_rpk and smtpd_tls_enable_rpk.
key, but it will still accept a server public key certificate. </p>
<li> <p> At the "fingerprint" security level, with parameter setting
-"<a href="postconf.5.html#smtp_tls_enable_rpk">smtp_tls_enable_rpk</a> = yes" or with "enable_rpk = yes" in a policy entry,
-server authentication based on certificate fingerprints becomes more
-fragile. Even if the server private key and certificate remain
-unchanged, the remote SMTP server will fail fingerprint authentication
-(won't match the configured list of fingerprints) when it starts sending
-a raw public key instead of a certificate, after its TLS implementation
-is updated with raw public key support. Therefore, <b>DO NOT</b>
-enable raw public keys to remote destinations authenticated by server
-<b>certificate</b> fingerprints. You should enable raw public keys
-only for servers matched via their public key fingerprint. </p>
-
-<li> <p> At the "dane" security level, the Postfix SMTP client
-always ignores the parameter setting <a href="postconf.5.html#smtp_tls_enable_rpk">smtp_tls_enable_rpk</a> or the
-enable_rpk policy attribute. When all valid TLSA records specify
-only server public keys (no certificates) and the local TLS
+"<a href="postconf.5.html#smtp_tls_enable_rpk">smtp_tls_enable_rpk</a> = yes" or with "enable_rpk = yes" in a policy
+entry, server authentication based on certificate fingerprints
+becomes more fragile. Even if the server private key and certificate
+remain unchanged, the remote SMTP server will fail fingerprint
+authentication (won't match the configured list of fingerprints)
+when it starts sending a raw public key instead of a certificate,
+after its TLS implementation is updated with raw public key support.
+Therefore, <b>DO NOT</b> enable raw public keys to remote destinations
+authenticated by server <b>certificate</b> fingerprints. You should
+enable raw public keys only for servers matched via their public
+key fingerprint. </p>
+
+<li> <p> At the "verify" and "secure" security levels, the Postfix
+SMTP client always ignores the parameter setting <a href="postconf.5.html#smtp_tls_enable_rpk">smtp_tls_enable_rpk</a>
+or the enable_rpk policy attribute. </p>
+
+<li> <p> At the opportunistic "dane" security level, the Postfix
+SMTP client ignores the parameter setting <a href="postconf.5.html#smtp_tls_enable_rpk">smtp_tls_enable_rpk</a> or
+the enable_rpk policy attribute (but it will respect them when it
+falls back to the "may" or "encrypt" level). When all valid TLSA
+records specify only server public keys (no certificates) and the
+local TLS implementation supports raw public keys, the client will
+indicate in the TLS handshake that it prefers to receive a raw
+public key, but it will still accept a public key certificate. </p>
+
+<li> <p> At the mandatory "dane-only" security level, the Postfix
+SMTP client always ignores the parameter setting <a href="postconf.5.html#smtp_tls_enable_rpk">smtp_tls_enable_rpk</a>
+or the enable_rpk policy attribute. When all valid TLSA records
+specify only server public keys (no certificates) and the local TLS
implementation supports raw public keys, the client will indicate
in the TLS handshake that it prefers to receive a raw public key,
but it will still accept a public key certificate. </p>
key, but it will still accept a server public key certificate.
.IP \(bu
At the "fingerprint" security level, with parameter setting
-"smtp_tls_enable_rpk = yes" or with "enable_rpk = yes" in a policy entry,
-server authentication based on certificate fingerprints becomes more
-fragile. Even if the server private key and certificate remain
-unchanged, the remote SMTP server will fail fingerprint authentication
-(won't match the configured list of fingerprints) when it starts sending
-a raw public key instead of a certificate, after its TLS implementation
-is updated with raw public key support. Therefore, \fBDO NOT\fR
-enable raw public keys to remote destinations authenticated by server
-\fBcertificate\fR fingerprints. You should enable raw public keys
-only for servers matched via their public key fingerprint.
-.IP \(bu
-At the "dane" security level, the Postfix SMTP client
-always ignores the parameter setting smtp_tls_enable_rpk or the
-enable_rpk policy attribute. When all valid TLSA records specify
-only server public keys (no certificates) and the local TLS
+"smtp_tls_enable_rpk = yes" or with "enable_rpk = yes" in a policy
+entry, server authentication based on certificate fingerprints
+becomes more fragile. Even if the server private key and certificate
+remain unchanged, the remote SMTP server will fail fingerprint
+authentication (won't match the configured list of fingerprints)
+when it starts sending a raw public key instead of a certificate,
+after its TLS implementation is updated with raw public key support.
+Therefore, \fBDO NOT\fR enable raw public keys to remote destinations
+authenticated by server \fBcertificate\fR fingerprints. You should
+enable raw public keys only for servers matched via their public
+key fingerprint.
+.IP \(bu
+At the "verify" and "secure" security levels, the Postfix
+SMTP client always ignores the parameter setting smtp_tls_enable_rpk
+or the enable_rpk policy attribute.
+.IP \(bu
+At the opportunistic "dane" security level, the Postfix
+SMTP client ignores the parameter setting smtp_tls_enable_rpk or
+the enable_rpk policy attribute (but it will respect them when it
+falls back to the "may" or "encrypt" level). When all valid TLSA
+records specify only server public keys (no certificates) and the
+local TLS implementation supports raw public keys, the client will
+indicate in the TLS handshake that it prefers to receive a raw
+public key, but it will still accept a public key certificate.
+.IP \(bu
+At the mandatory "dane\-only" security level, the Postfix
+SMTP client always ignores the parameter setting smtp_tls_enable_rpk
+or the enable_rpk policy attribute. When all valid TLSA records
+specify only server public keys (no certificates) and the local TLS
implementation supports raw public keys, the client will indicate
in the TLS handshake that it prefers to receive a raw public key,
but it will still accept a public key certificate.
key, but it will still accept a server public key certificate. </p>
<li> <p> At the "fingerprint" security level, with parameter setting
-"smtp_tls_enable_rpk = yes" or with "enable_rpk = yes" in a policy entry,
-server authentication based on certificate fingerprints becomes more
-fragile. Even if the server private key and certificate remain
-unchanged, the remote SMTP server will fail fingerprint authentication
-(won't match the configured list of fingerprints) when it starts sending
-a raw public key instead of a certificate, after its TLS implementation
-is updated with raw public key support. Therefore, <b>DO NOT</b>
-enable raw public keys to remote destinations authenticated by server
-<b>certificate</b> fingerprints. You should enable raw public keys
-only for servers matched via their public key fingerprint. </p>
-
-<li> <p> At the "dane" security level, the Postfix SMTP client
-always ignores the parameter setting smtp_tls_enable_rpk or the
-enable_rpk policy attribute. When all valid TLSA records specify
-only server public keys (no certificates) and the local TLS
+"smtp_tls_enable_rpk = yes" or with "enable_rpk = yes" in a policy
+entry, server authentication based on certificate fingerprints
+becomes more fragile. Even if the server private key and certificate
+remain unchanged, the remote SMTP server will fail fingerprint
+authentication (won't match the configured list of fingerprints)
+when it starts sending a raw public key instead of a certificate,
+after its TLS implementation is updated with raw public key support.
+Therefore, <b>DO NOT</b> enable raw public keys to remote destinations
+authenticated by server <b>certificate</b> fingerprints. You should
+enable raw public keys only for servers matched via their public
+key fingerprint. </p>
+
+<li> <p> At the "verify" and "secure" security levels, the Postfix
+SMTP client always ignores the parameter setting smtp_tls_enable_rpk
+or the enable_rpk policy attribute. </p>
+
+<li> <p> At the opportunistic "dane" security level, the Postfix
+SMTP client ignores the parameter setting smtp_tls_enable_rpk or
+the enable_rpk policy attribute (but it will respect them when it
+falls back to the "may" or "encrypt" level). When all valid TLSA
+records specify only server public keys (no certificates) and the
+local TLS implementation supports raw public keys, the client will
+indicate in the TLS handshake that it prefers to receive a raw
+public key, but it will still accept a public key certificate. </p>
+
+<li> <p> At the mandatory "dane-only" security level, the Postfix
+SMTP client always ignores the parameter setting smtp_tls_enable_rpk
+or the enable_rpk policy attribute. When all valid TLSA records
+specify only server public keys (no certificates) and the local TLS
implementation supports raw public keys, the client will indicate
in the TLS handshake that it prefers to receive a raw public key,
but it will still accept a public key certificate. </p>
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20230807"
+#define MAIL_RELEASE_DATE "20230808"
#define MAIL_VERSION_NUMBER "3.9"
#ifdef SNAPSHOT
projects / thirdparty / postfix.git / commitdiff
