From: Wietse Venema Date: Tue, 26 Nov 2013 05:00:00 +0000 (-0500) Subject: postfix-2.11-20131126-nonprod X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=refs%2Fheads%2F20131126-nonprod;p=thirdparty%2Fpostfix.git postfix-2.11-20131126-nonprod --- diff --git a/postfix/.indent.pro b/postfix/.indent.pro index 60bdd8d01..441e160c2 100644 --- a/postfix/.indent.pro +++ b/postfix/.indent.pro @@ -193,6 +193,7 @@ -TMKMAP_DB -TMKMAP_DBM -TMKMAP_OPEN_INFO +-TMKMAP_SDBM -TMSG_STATS -TMULTI_SERVER -TMVECT @@ -206,10 +207,14 @@ -TOPTIONS -TPC_DBMS_INFO -TPC_EVAL_CTX +-TPC_MASTER_EDIT_REQ -TPC_MASTER_ENT +-TPC_MASTER_FIELD_REQ -TPC_PARAM_CTX -TPC_PARAM_NODE +-TPC_PARAM_TABLE -TPC_SERVICE_DEF +-TPC_SERVICE_PATTERN -TPC_STRING_NV -TPEER_NAME -TPGSQL_NAME @@ -341,6 +346,7 @@ -TXSASL_CLIENT_CREATE_ARGS -TXSASL_CLIENT_IMPL -TXSASL_CLIENT_IMPL_INFO +-TXSASL_CYRUS_CB -TXSASL_CYRUS_CLIENT -TXSASL_CYRUS_ERROR_INFO -TXSASL_CYRUS_SERVER @@ -352,18 +358,24 @@ -TXSASL_SERVER_CREATE_ARGS -TXSASL_SERVER_IMPL -TXSASL_SERVER_IMPL_INFO +-Tbind_props -Tcipher_probe_t +-Tdane_digest +-Tfilter_ctx -Tgeneral_name_stack_t +-Tiana_digest -Toff_t -Tregex_t -Tregmatch_t -Tsasl_conn_t -Tsasl_secret_t -Tsfsistat +-Tsigset_t -Tsize_t -Tssize_t -Tssl_cipher_stack_t -Tssl_comp_stack_t -Ttime_t +-Ttlsa_filter -Tx509_extension_stack_t -Tx509_stack_t diff --git a/postfix/HISTORY b/postfix/HISTORY index 3e1e22249..4883ede54 100644 --- a/postfix/HISTORY +++ b/postfix/HISTORY @@ -18218,6 +18218,13 @@ Apologies for any names omitted. Factor out the master.cf line parser so that it can be reused for "postconf -Me". File: postconf/postconf_master.c. +20130113 + + Feature: master.cf attribute namespace. "postconf -F" shows + individual master.cf fields as "service/type/attribute = + value", where attribute is "service", "type", "private", + "unprivileged", "wakeup", "process_limit", or "command". + 20130121 Bugfix (introduced 20120307): the postconf -X option erased @@ -19232,9 +19239,67 @@ Apologies for any names omitted. cleanup/cleanup_milter.c, cleanup/cleanup_state.c, global/xtext.c, global/xtext.h, milter/test-milter.c. +20131122 + + Feature: "postcon -Fe service/type/attribute = value" edits + master.cf attribute values. The -e is optional. Example: + use "postconf -F "*/*/chroot = n" to turn off chroot on all + master.cf services. Files: postconf/postconf.h, + postconf/postconf.c, postconf/postcof_master.c, + postconf/postconf_edit.c. + 20131124 Cleanup: remove extra blank line from ccformat output, making it compatible with the script that Wietse actually uses (this line was part of a test to detect file truncation, but it is now obsolete). File: mantools/ccformat. + + Feature: master.cf parameter namespace. "postconf -P" shows + master.cf parameter settings as "service/type/parameter = + value". This is applicable only to parameter settings in + master.cf. Files: postconf/postconf.h, postconf/postconf.c, + postconf/postcof_master.c, postconf/postconf_print.c. + + Incompatibility: the master_service_disable syntax has + changed: use "service/type" instead of "service.type". The + new form is consistent with master.cf parameter namespaces. + The old form is still supported to avoid breaking existing + configurations. Files: global/master_service.c, + master/master_ent.c. + +20131125 + + Feature: change, add or delete "-o parameter=value" setting + in master.cf. Examples: "postconf -P smtp/inet/parameter=value" + (add or modify "-o name=value" setting) and "postconf -P + smtp/inet/parameter" (delete "-o parameter=value" setting). + Files: util/argv.[hc], postconf/postconf.h, + postconf/postconf_edit.c, postconf_master.c. + +20131126 + + Cleanup: Leave SSLv3 enabled with DANE. Viktor Dukhovni. + Files: proto/TLS_README.html proto/postconf.proto + tls/tls_client.c. + + Cleanup: DANE support: Drop support for usage 0. It SHOULD + NOT be supported in DANE with SMTP, and we already don't + support digest TLSA RRs in this case, while full content + TLSA RRs are not recommended for DNS bloat reasons. Viktor + Dukhovni. Files: proto/postconf.proto src/global/mail_params.h + src/smtp/smtp.c src/tls/tls_dane.c src/tls/tls_misc.c. + + Feature: TLS support: Support future digest algorithms + without re-compilation. Viktor Dukhovni. Files: .indent.pro + proto/postconf.proto src/tls/tls_dane.c. + + Feature: DNS support: New configurable digest agility. + Viktor Dukhovni. Files: .indent.pro proto/TLS_README.html + proto/postconf.proto src/global/mail_params.h src/tls/tls_dane.c + src/tls/tls_misc.c. + +20131127 + + Bugfix (introduced: 20090106): the postconf '-#' option + erased prior options. File: postconf/postconf.c. diff --git a/postfix/README_FILES/TLS_README b/postfix/README_FILES/TLS_README index 4728a624d..2d07f9a99 100644 --- a/postfix/README_FILES/TLS_README +++ b/postfix/README_FILES/TLS_README @@ -135,9 +135,10 @@ assume that the certificate for "server.example.com" was issued by % ccaatt sseerrvveerr__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> sseerrvveerr..ppeemm - * If you use RFC 6698 TLSA "2 0 1" or "2 1 1" records to specify root CA + * If you publish RFC 6698 TLSA "2 0 1" or "2 1 1" records to specify root CA certificate digests, you must include the corresponding root CA - certificates in the "server.pem" certificate file. + certificates in the "server.pem" certificate file. See the documentation of + the tls_dane_trust_anchor_digest_enable main.cf parameter. % ccaatt sseerrvveerr__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm rroooott..ppeemm >> sseerrvveerr..ppeemm @@ -147,20 +148,13 @@ assume that the certificate for "server.example.com" was issued by published TLSA records will typically cause the SMTP client to defer mail delivery. The foregoing also applies to "2 0 2" and "2 1 2" TLSA records or any other digest of a CA certificate, but it is expected that SHA256 will - be by far the most common digest for TLSA. You are strongly urged to - likewise include the root CA certificate in your server certificate file - even if you use "0 0 1" or "0 1 1" TLSA records. Some DANE implementations - in SMTP clients (Postfix among them) may treat RFC 6698 certificate usages - "0" and "2" interchangeably. - - By default, support for TLSA records that specify certificate usage "0" via - a digest is disabled in the Postfix SMTP client. As a best practice, - publish either "3 0 1" or "3 1 1" TLSA associations that specify the SHA256 - digest of the server certificate public key with the alias-expanded - hostname of each STARTTLS capable SMTP server. These continue to work when - a certificate is renewed with the same public/private key pair. See the - documentation of the tls_dane_trust_anchor_digest_enable main.cf parameter - for details. + be by far the most common digest for TLSA. + + As a best practice, publish either "3 0 1" or "3 1 1" TLSA associations + that specify the SHA256 digest of the server certificate public key with + the alias-expanded hostname of each STARTTLS capable SMTP server. These + continue to work when a certificate is renewed with the same public/private + key pair. For instructions on how to compute the digest of a certificate or its public key for use in TLSA records, see the documentation of the @@ -614,7 +608,8 @@ configurations with no server certificates that use oonnllyy the anonymous c This is enabled by explicitly setting "smtpd_tls_cert_file = none" and not specifying an smtpd_tls_dcert_file or smtpd_tls_eccert_file. -Example, MSA that requires TLSv1, not SSLv2 or SSLv3, with high grade ciphers: +Example, MSA that requires TLSv1 or higher, not SSLv2 or SSLv3, with high grade +ciphers: /etc/postfix/main.cf: smtpd_tls_cert_file = /etc/postfix/cert.pem @@ -622,9 +617,9 @@ Example, MSA that requires TLSv1, not SSLv2 or SSLv3, with high grade ciphers: smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 smtpd_tls_security_level = encrypt - # Preferred form with Postfix >= 2.5: + # Postfix >= 2.5: smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 - # Alternative form. + # Legacy form with Postfix prior to 2.5: smtpd_tls_mandatory_protocols = TLSv1 If you want to take advantage of ciphers with ephemeral Diffie-Hellman (EDH) @@ -656,21 +651,25 @@ Examples: smtpd_tls_eecdh_grade = strong Postfix 2.8 and later, in combination with OpenSSL 0.9.7 and later allows TLS -servers to preempt the TLS client's cipher preference list. This is possible -only with SSLv3 and later, as in SSLv2 the client chooses the cipher from a -list supplied by the server. - -By default, the OpenSSL server selects the client's most preferred cipher that -the server supports. With SSLv3 and later, the server may choose its own most -preferred cipher that is supported (offered) by the client. Setting -"tls_preempt_cipherlist = yes" enables server cipher preferences. The default -OpenSSL behavior applies with "tls_preempt_cipherlist = no". - -While server cipher selection may in some cases lead to a more secure or -performant cipher choice, there is some risk of interoperability issues. In the -past, some SSL clients have listed lower priority ciphers that they did not -implement correctly. If the server chooses a cipher that the client prefers -less, it may select a cipher whose client implementation is flawed. +servers to preempt the TLS client's cipher-suite preference list. This is +possible only with SSLv3 and later, as in SSLv2 the client chooses the cipher- +suite from a list supplied by the server. + +By default, the OpenSSL server selects the client's most preferred cipher-suite +that the server supports. With SSLv3 and later, the server may choose its own +most preferred cipher-suite that is supported (offered) by the client. Setting +"tls_preempt_cipherlist = yes" enables server cipher-suite preferences. The +default OpenSSL behavior applies with "tls_preempt_cipherlist = no". + +While server cipher-suite selection may in some cases lead to a more secure or +performant cipher-suite choice, there is some risk of interoperability issues. +In the past, some SSL clients have listed lower priority ciphers that they did +not implement correctly. If the server chooses a cipher that the client prefers +less, it may select a cipher whose client implementation is flawed. Most +notably Windows 2003 Microsoft Exchange servers have flawed implementations of +DES-CBC3-SHA, which OpenSSL considers stronger than RC4-SHA. Enabling server +cipher-suite selection may create interoperability issues with Windows 2003 +Microsoft Exchange clients. MMiisscceellllaanneeoouuss sseerrvveerr ccoonnttrroollss @@ -916,78 +915,74 @@ level. The "dane" level is a stronger form of opportunistic TLS that is resistant to man in the middle and downgrade attacks when the destination domain uses DNSSEC to publish DANE TLSA records for its MX hosts. If a remote SMTP server has -usable DANE TLSA records, these will be used to authenticate the server. If -TLSA records are published for a given remote SMTP server (implying TLS -support), but are not usable due to unsupported parameters, the Postfix SMTP -client will use mandatory unauthenticated TLS. Otherwise, the Postfix SMTP -client behavior is the same as with may. +"usable" (see RFC 6698) DANE TLSA records, the server connection will be +authenticated. When DANE authentication fails, there is no fallback to +unauthenticated or plaintext delivery. + +If TLSA records are published for a given remote SMTP server (implying TLS +support), but are all "unusable" due to unsupported parameters or malformed +data, the Postfix SMTP client will use mandatory unauthenticated TLS. +Otherwise, when no TLSA records are published, the Postfix SMTP client behavior +is the same as with may. + +TLSA records must be published in DNSSEC validated DNS zones. Any TLSA records +in DNS zones not protected via DNSSEC are ignored. The Postfix SMTP client will +not look for TLSA records associated with MX hosts whose "A" or "AAAA" records +lie in an "insecure" DNS zone. Such lookups have been observed to cause +interoperability issues with poorly implemented DNS servers, and are in any +case not expected to ever yield "secure" results, since that would require a +very unlikey DLV DNS trust anchor configured between the host record and the +associated "_25._tcp" child TLSA record. The "dane-only" level is a form of secure-channel TLS based on the DANE PKI. If -usable TLSA records are present these are used to authenticate the remote SMTP -server. Otherwise, or when server certificate verification fails, delivery via -the server in question tempfails. +"usable" TLSA records are present these are used to authenticate the remote +SMTP server. Otherwise, or when server certificate verification fails, delivery +via the server in question tempfails. At both security levels, the TLS policy for the destination is obtained via TLSA records validated with DNSSEC. For TLSA policy to be in effect, the destination domain's containing DNS zone must be signed and the Postfix SMTP client's operating system must be configured to send its DNS queries to a recursive DNS nameserver that is able to validate the signed records. Each MX -host's DNS zone should also be signed, and should publish DANE TLSA (RFC 6698) -records that specify how that MX host's TLS certificate is to be verified. TLSA -records do not preempt the normal SMTP MX host selection algorithm, if some MX -hosts support TLSA and others do not, TLS security will vary from delivery to -delivery. It is up to the domain owner to configure their MX hosts and their -DNS sensibly. To configure the Postfix SMTP client for DNSSEC lookups see the -documentation for the smtp_dns_support_level main.cf parameter. The -tls_dane_trust_anchor_digest_enable main.cf parameter controls optional support -for trust-anchor digest TLSA records. - -The Postfix SMTP client deviates from RFC 6698 in cases where strict adherence -is likely to create opportunities for delayed (or eventually bounced) email -with no substantive security gain. Most notably, it is not expected that -smtp_tls_CAfile and smtp_tls_CApath can reasonably include every public CA that -a remote SMTP server's administrator may believe to be well-known. Therefore, -certificate usages "0" and "2" from RFC 6698 which are intended to "constrain" -existing PKI trust, are instead treated as "trust assertions" and mapped to "1" -and "3" respectively. That is, with certificate usage "0" and "2", Postfix will -not require the remote SMTP server's certificate to be trusted with respect to -any locally defined public CAs, it is the domain owner's responsibility to -ensure that the certificate associations in their TLSA records are appropriate -to authenticate their SMTP servers. - -In addition, the Postfix SMTP client does not assume that the remote SMTP -server will necessarily be configured to present the certificate of any usage -"0" root CA in its TLS protocol certificate_list. Therefore, support for usage -"0" certificate and public-key digests is disabled by default, see -tls_dane_trust_anchor_digest_enable for details. While undigested trust-anchor -certificates in TLSA records are supported, publishing complete certificates in -DNS is unwise given the resulting excessively large DNS record sizes. -Therefore, in its default configuration the Postfix SMTP client essentially -supports only certificate usages "1", "2" and "3" (with "1" treated as though -it were "3"). - -Finally, the interaction of DANE with MX hostnames that are CNAMEs differs from -the draft specification in the names used to construct the associated TLSA -queries. When the MX hostname is a CNAME, the draft proposal to use the -unexpanded MX hostname in TLSA lookups is fragile and unintuitive. For this to -work, the domain owner has to either duplicate the TLSA records of the target -(host, service) pair in his own DNS or furnish the target host with an -additional certificate and private key that would be negotiated via SNI. -Neither of these are robust or easy to manage. It is far better to expand the -CNAME recursively to the underlying target hostname (keeping track of DNSSEC -validation along the way) and to use the expanded name to construct the TLSA -query and, if appropriate, in server certificate name checks. This is the -approach taken by the Postfix SMTP client, and if sanity prevails will also be -the approach taken in the final standard. +host's DNS zone needs to also be signed, and needs to publish DANE TLSA (RFC +6698) records that specify how that MX host's TLS certificate is to be +verified. + +TLSA records do not preempt the normal SMTP MX host selection algorithm, if +some MX hosts support TLSA and others do not, TLS security will vary from +delivery to delivery. It is up to the domain owner to configure their MX hosts +and their DNS sensibly. To configure the Postfix SMTP client for DNSSEC lookups +see the documentation for the smtp_dns_support_level main.cf parameter. The +tls_dane_trust_anchor_digest_enable main.cf parameter controls support for +trust-anchor digest TLSA records. The tls_dane_digests and +tls_dane_digest_agility parameters control the list of supported digests and +digest downgrade attack resistance. + +DANE for SMTP MTAs deviates in some details from the baseline DANE protocol in +RFC 6698. Most notably, it is not expected that SMTP MTAs can reasonably +include every public CA that a remote SMTP server's administrator may believe +to be well-known. Nor is there an interactive user to "click OK" when +authentication fails. + +Therefore, certificate usages "0" and "1" from RFC 6698 which are intended to +"constrain" existing PKI trust, are not supported. TLSA records with usage "0" +are treated as "unusable". TLSA records with usage "1" are instead treated as +"trust assertions" and mapped to usage "3". Specifically, with certificate +usage "1", Postfix will not require the remote SMTP server's certificate to be +trusted with respect to any locally defined public CAs, it is the domain +owner's responsibility to ensure that the certificate associations in their +TLSA records are appropriate to authenticate their SMTP servers. + +The Postfix SMTP client supports only certificate usages "2" and "3" (with "1" +treated as though it were "3"). See tls_dane_trust_anchor_digest_enable for +usage "2" usability considerations. Support for certificate usage "1" is an +experiment, it may be withdrawn in the future. Server operators SHOULD NOT +publish TLSA records with usage "1". When usable TLSA records are obtained for the remote SMTP server the Postfix -SMTP client is obligated to include the SNI TLS extension in its SSL client -hello message. This may help the remote SMTP server live up to its promise to -provide a certificate that matches its TLSA records. Since TLS extensions -require TLS 1.0 or later, the Postfix SMTP client must disable SSLv2 and SSLv3 -when SNI is required. If you use "dane" or "dane-only", do not disable TLSv1, -except perhaps via the policy table for destinations which you are sure will -support TLSv1.1 or TLSv1.2. +SMTP client sends the SNI TLS extension in its SSL client hello message. This +may help the remote SMTP server live up to its promise to provide a certificate +that matches its TLSA records. For purposes of protocol and cipher selection, the "dane" security level is treated like a "mandatory" TLS security level, and weak ciphers and protocols @@ -1010,8 +1005,8 @@ administrators should publish such EE records in preference to all other types. The pre-requisites for DANE support in the Postfix SMTP client are: - * A compile-time OpenSSL library that supports the TLS SNI extension and the - "sha256" and "sha512" message digests. + * A compile-time OpenSSL library that supports the TLS SNI extension and + "SHA-2" message digests. * A compile-time DNS resolver library that supports DNSSEC. Postfix binaries built on an older system will not support DNSSEC even if deployed on a system with an updated resolver library. @@ -1566,9 +1561,9 @@ security policy. On the SMTP client, there are further complications. When delivering mail to a given domain, in contrast to HTTPS, one rarely uses the domain name directly as the target host of the SMTP session. More typically, one uses MX lookups - -these are usually unauthenticated - to obtain the domain's SMTP server hostname -(s). When, as is current practice, the client verifies the insecurely obtained -MX hostname, it is subject to a DNS man-in-the-middle attack. +- these are usually unauthenticated -- to obtain the domain's SMTP server +hostname(s). When, as is current practice, the client verifies the insecurely +obtained MX hostname, it is subject to a DNS man-in-the-middle attack. Adoption of DNSSEC and RFC6698 (DANE) may gradually (as domains implement DNSSEC and publish TLSA records for their MX hosts) address the DNS man-in-the- @@ -1660,21 +1655,18 @@ ddaannee TLSA records in DNSSEC. If no TLSA records are found, the effective security level used is may. If TLSA records are found, but none are usable, the effective security level is encrypt. When usable TLSA records are - obtained for the remote SMTP server, SSLv2 and SSLv3 are automatically - disabled (see smtp_tls_mandatory_protocols), and the server certificate - must match the TLSA records. The tls_dane_trust_anchor_digest_enable - parameter controls optional support for trust-anchor digest TLSA records. - RFC 6698 (DANE) TLS authentication and DNSSEC support is available with - Postfix 2.11 and later. + obtained for the remote SMTP server, SSLv2 is automatically disabled (see + smtp_tls_mandatory_protocols), and the server certificate must match the + TLSA records. RFC 6698 (DANE) TLS authentication and DNSSEC support is + available with Postfix 2.11 and later. ddaannee--oonnllyy Mandatory DANE TLS. The TLS policy for the destination is obtained via TLSA records in DNSSEC. If no TLSA records are found, or none are usable, no connection is made to the server. When usable TLSA records are obtained for - the remote SMTP server, SSLv2 and SSLv3 are automatically disabled (see + the remote SMTP server, SSLv2 is automatically disabled (see smtp_tls_mandatory_protocols), and the server certificate must match the - TLSA records. The tls_dane_trust_anchor_digest_enable parameter controls - optional support for trust-anchor digest TLSA records. RFC 6698 (DANE) TLS - authentication and DNSSEC support is available with Postfix 2.11 and later. + TLSA records. RFC 6698 (DANE) TLS authentication and DNSSEC support is + available with Postfix 2.11 and later. ffiinnggeerrpprriinntt Certificate fingerprint verification. Available with Postfix 2.5 and later. At this security level, there are no trusted certificate authorities. The @@ -1745,9 +1737,8 @@ Example: /etc/postfix/tls_policy: example.edu none example.mil may - example.gov encrypt protocols=SSLv3:TLSv1 ciphers=high - example.com verify - match=hostname:dot-nexthop protocols=SSLv3:TLSv1 ciphers=high + example.gov encrypt ciphers=high + example.com verify match=hostname:dot-nexthop ciphers=high example.net secure .example.net secure match=.example.net:example.net [mail.example.org]:587 secure match=nexthop @@ -1838,7 +1829,7 @@ Example: smtp_tls_exclude_ciphers = aNULL # Preferred form with Postfix >= 2.5: smtp_tls_mandatory_protocols = !SSLv2 - # Alternative form. + # Legacy form for Postifx < 2.5: smtp_tls_mandatory_protocols = SSLv3, TLSv1 # Also available with Postfix >= 2.6: smtp_tls_ciphers = export diff --git a/postfix/RELEASE_NOTES b/postfix/RELEASE_NOTES index 0a3ded0ec..2c8619a89 100644 --- a/postfix/RELEASE_NOTES +++ b/postfix/RELEASE_NOTES @@ -14,6 +14,131 @@ specifies the release date of a stable release or snapshot release. If you upgrade from Postfix 2.9 or earlier, read RELEASE_NOTES-2.10 before proceeding. +Incompatible changes with snapshot 20131126-nonprod +=================================================== + +The master_service_disable syntax has changed: use "service/type" +instead of "service.type". The new form is consistent with master.cf +parameter namespaces. The old form is still supported to avoid +breaking existing configurations. + +Major changes with with snapshot 20131126-nonprod +================================================= + +Support for advanced master.cf query and update operations. This +was implemented primarily to support automated system management +tools. + +The idea is to make all Postfix master.cf details accessible as a +list of "name=value" pairs, where the names are organized into +structured name spaces. This allows other programs to query +information or request updates, without having to worry about the +exact layout of master.cf files. + +First, an example that shows the smtp/inet service in the traditional +form: + + $ postconf -M smtp/inet + smtp inet n - n - - smtpd + +Different variants of this command show different amounts of output. +For example, "postconf -M smtp" enumerates all services that have +a name "smtp" and any service type ("inet", "unix", etc.), and +"postconf -M" enumerates all master.cf services. + +General rule: each name component that is not present becomes a "*" +wildcard. + +Coming back to the above example, the postconf -F option can now +enumerate the smtp/inet service fields as follows: + + $ postconf -F smtp/inet + smtp/inet/service = smtp + smtp/inet/type = inet + smtp/inet/private = n + smtp/inet/unprivileged = - + smtp/inet/chroot = n + smtp/inet/wakeup = - + smtp/inet/process_limit = - + smtp/inet/command = smtpd + +This form makes it very easy to change one field in master.cf. +For example to turn on chroot on the smtp/inet service you use: + + $ postconf -F smtp/inet/chroot=y + +Moreover, with "-F" you can specify "*" for service name or service +type to get a wild-card match. For example, to turn off chroot on +all Postfix daemons, use this: + + $ postconf -F '*/*/chroot=n' + +For a second example, let's look at the submission service. This +service typically has multple "-o parameter=value" overrides. First +the traditional view: + + $ postconf -Mf submission + submission inet n - n - - smtpd + -o smtpd_tls_security_level=encrypt + -o smtpd_sasl_auth_enable=yes + ... + +The postconf -P option can now enumerate these parameters as follows: + + $ postconf -P submission + submission/inet/smtpd_sasl_auth_enable = yes + submission/inet/smtpd_tls_security_level = encrypt + ... + +Again, this form makes it very easy to modify one parameter +setting, for example to change the smtpd_tls_security_level setting for +the submission/inet service: + + $ postconf -P 'submission/inet/smtpd_tls_security_level=may' + +You can create or remove a parametername=parametervalue setting: + +Create: + $ postconf -P 'submission/inet/parametername=parametervalue' + +Remove: + $ postconf -PX submission/inet/parametername + +Finally, adding master.cf entries is possible, but currently this +does not yet have "advanced" support. It can only be done at the +level of the traditional master.cf file format. + +For example, to clone the smtp/unix service settings and create a +new delay/unix service you would enumerate the smtp/unix service +like this: + + $ postconf -M smtp/unix + smtp unix - - n - - smtp + +Then you would copy those fields (except the first field) to +update or create the delay/unix service: + + $ postconf -M delay/unix="delay unix - - n - - smtp" + +To combine the above in one command: + + $ postconf -M delay/unix="`postconf -M smtp/unix|awk '{$1 = "delay"}'`" + +This is perhaps not super-convenient for manual cloning, but it +should be sufficient for programmatic configuration management. + +The -X (delete entry) and -# (comment out entry) options already +exist for main.cf, and they now also work work for entire master.cf +entries: + +Remove main.cf or master.cf entry: + $ postconf -X parametername + $ postconf -MX delay/unix + +Comment out main.cf or master.cf entry: + $ postconf -# parametername + $ postconf -M# delay/unix + Major changes with snapshot 20131031 ==================================== diff --git a/postfix/html/TLS_README.html b/postfix/html/TLS_README.html index 34939a3b4..fd14e88b6 100644 --- a/postfix/html/TLS_README.html +++ b/postfix/html/TLS_README.html @@ -226,9 +226,11 @@ size of the server TLS handshake.

-

  • If you use RFC 6698 TLSA "2 0 1" or "2 1 1" records to +

  • If you publish RFC 6698 TLSA "2 0 1" or "2 1 1" records to specify root CA certificate digests, you must include the corresponding -root CA certificates in the "server.pem" certificate file.

    +root CA certificates in the "server.pem" certificate file. See the +documentation of the tls_dane_trust_anchor_digest_enable main.cf +parameter. 

    @@ -236,29 +238,20 @@ root CA certificates in the "server.pem" certificate file.
    -

    Remote SMTP clients will -be able to use the TLSA record you publish (which only contains the -certificate digest) only if they have access to the corresponding -certificate. Failure to verify certificates per the server's -published TLSA records will typically cause the SMTP client to defer -mail delivery. The foregoing also applies to "2 0 2" and "2 1 2" -TLSA records or any other digest of a CA certificate, but it is -expected that SHA256 will be by far the most common digest for TLSA. -You are strongly urged to likewise include the root CA -certificate in your server certificate file even if you use "0 0 -1" or "0 1 1" TLSA records. Some DANE implementations in SMTP -clients (Postfix among them) may treat RFC 6698 certificate usages -"0" and "2" interchangeably.

    - -

    By default, support for TLSA records that specify certificate -usage "0" via a digest is disabled in the Postfix SMTP client. As -a best practice, publish either "3 0 1" or "3 1 1" TLSA associations -that specify the SHA256 digest of the server certificate public key -with the alias-expanded hostname of each STARTTLS capable SMTP -server. These continue to work when a certificate is renewed with -the same public/private key pair. See the documentation of the -tls_dane_trust_anchor_digest_enable main.cf parameter for details. -

    +

    Remote SMTP clients will be able to use the TLSA record you +publish (which only contains the certificate digest) only if they +have access to the corresponding certificate. Failure to verify +certificates per the server's published TLSA records will typically +cause the SMTP client to defer mail delivery. The foregoing also +applies to "2 0 2" and "2 1 2" TLSA records or any other digest of +a CA certificate, but it is expected that SHA256 will be by far the +most common digest for TLSA.

    + +

    As a best practice, publish either "3 0 1" or "3 1 1" TLSA +associations that specify the SHA256 digest of the server certificate +public key with the alias-expanded hostname of each STARTTLS capable +SMTP server. These continue to work when a certificate is renewed +with the same public/private key pair.

    @@ -861,8 +854,8 @@ certificates that use only the anonymous ciphers. This is enabled by explicitly setting "smtpd_tls_cert_file = none" and not specifying an smtpd_tls_dcert_file or smtpd_tls_eccert_file.

    -

    Example, MSA that requires TLSv1, not SSLv2 or SSLv3, with high grade -ciphers:

    +

    Example, MSA that requires TLSv1 or higher, not SSLv2 or SSLv3, +with high grade ciphers: 

    @@ -872,9 +865,9 @@ ciphers: 
    
     smtpd_tls_mandatory_ciphers = high
     smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
     smtpd_tls_security_level = encrypt
-    # Preferred form with Postfix ≥ 2.5:
+    # Postfix ≥ 2.5:
     smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
-    # Alternative form.
+    # Legacy form with Postfix prior to 2.5:
     smtpd_tls_mandatory_protocols = TLSv1
    @@ -918,23 +911,27 @@ secure for most situations.

    Postfix 2.8 and later, in combination with OpenSSL 0.9.7 and later -allows TLS servers to preempt the TLS client's cipher preference list. +allows TLS servers to preempt the TLS client's cipher-suite preference list. This is possible only with SSLv3 and later, as in SSLv2 the client -chooses the cipher from a list supplied by the server.

    +chooses the cipher-suite from a list supplied by the server.

    By default, the OpenSSL server selects the client's most preferred -cipher that the server supports. With SSLv3 and later, the server -may choose its own most preferred cipher that is supported (offered) +cipher-suite that the server supports. With SSLv3 and later, the server +may choose its own most preferred cipher-suite that is supported (offered) by the client. Setting "tls_preempt_cipherlist = yes" enables server -cipher preferences. The default OpenSSL behavior applies with +cipher-suite preferences. The default OpenSSL behavior applies with "tls_preempt_cipherlist = no".

    -

    While server cipher selection may in some cases lead to a more secure -or performant cipher choice, there is some risk of interoperability -issues. In the past, some SSL clients have listed lower priority ciphers -that they did not implement correctly. If the server chooses a cipher -that the client prefers less, it may select a cipher whose client -implementation is flawed.

    +

    While server cipher-suite selection may in some cases lead to +a more secure or performant cipher-suite choice, there is some risk +of interoperability issues. In the past, some SSL clients have +listed lower priority ciphers that they did not implement correctly. +If the server chooses a cipher that the client prefers less, it may +select a cipher whose client implementation is flawed. Most notably +Windows 2003 Microsoft Exchange servers have flawed implementations +of DES-CBC3-SHA, which OpenSSL considers stronger than RC4-SHA. +Enabling server cipher-suite selection may create interoperability +issues with Windows 2003 Microsoft Exchange clients.

    Miscellaneous server controls

    @@ -1251,17 +1248,30 @@ the mandatory "dane-only" level.

    href="#client_tls_may">opportunistic TLS that is resistant to man in the middle and downgrade attacks when the destination domain uses DNSSEC to publish DANE TLSA records for its MX hosts. If a -remote SMTP server has usable DANE TLSA records, these will be used -to authenticate the server. If TLSA records are published for a -given remote SMTP server (implying TLS support), but are not usable -due to unsupported parameters, the Postfix SMTP client will use RFC 6698) DANE TLSA records, +the server connection will be authenticated. When DANE authentication +fails, there is no fallback to unauthenticated or plaintext delivery.

    + +

    If TLSA records are published for a given remote SMTP server +(implying TLS support), but are all "unusable" due to unsupported +parameters or malformed data, the Postfix SMTP client will use mandatory unauthenticated TLS. -Otherwise, the Postfix SMTP client behavior is the same as with may.

    +Otherwise, when no TLSA records are published, the Postfix SMTP +client behavior is the same as with may.

    + +

    TLSA records must be published in DNSSEC validated DNS zones. +Any TLSA records in DNS zones not protected via DNSSEC are ignored. +The Postfix SMTP client will not look for TLSA records associated +with MX hosts whose "A" or "AAAA" records lie in an "insecure" DNS +zone. Such lookups have been observed to cause interoperability +issues with poorly implemented DNS servers, and are in any case not +expected to ever yield "secure" results, since that would require +a very unlikey DLV DNS trust anchor configured between the host +record and the associated "_25._tcp" child TLSA record.

    The "dane-only" level is a form of secure-channel TLS based on the DANE PKI. -If usable TLSA records are present these are used to authenticate the +If "usable" TLSA records are present these are used to authenticate the remote SMTP server. Otherwise, or when server certificate verification fails, delivery via the server in question tempfails.

    @@ -1271,73 +1281,51 @@ to be in effect, the destination domain's containing DNS zone must be signed and the Postfix SMTP client's operating system must be configured to send its DNS queries to a recursive DNS nameserver that is able to validate the signed records. Each MX host's DNS -zone should also be signed, and should publish DANE TLSA (RFC 6698) +zone needs to also be signed, and needs to publish DANE TLSA (RFC 6698) records that specify how that MX host's TLS certificate is to be -verified. TLSA records do not preempt the normal SMTP MX host +verified.

    + +

    TLSA records do not preempt the normal SMTP MX host selection algorithm, if some MX hosts support TLSA and others do not, TLS security will vary from delivery to delivery. It is up to the domain owner to configure their MX hosts and their DNS sensibly. To configure the Postfix SMTP client for DNSSEC lookups see the documentation for the smtp_dns_support_level main.cf parameter. The tls_dane_trust_anchor_digest_enable main.cf parameter -controls optional support for trust-anchor digest TLSA records. +controls support for trust-anchor digest TLSA records. The +tls_dane_digests and tls_dane_digest_agility parameters control +the list of supported digests and digest downgrade attack resistance.

    -

    The Postfix SMTP client deviates from RFC 6698 in cases where -strict adherence is likely to create opportunities for delayed (or -eventually bounced) email with no substantive security gain. Most -notably, it is not expected that smtp_tls_CAfile and smtp_tls_CApath -can reasonably include every public CA that a remote SMTP server's -administrator may believe to be well-known. Therefore, certificate -usages "0" and "2" from RFC 6698 which are intended to "constrain" -existing PKI trust, are instead treated as "trust assertions" and -mapped to "1" and "3" respectively. That is, with certificate usage -"0" and "2", Postfix will not require the remote SMTP server's -certificate to be trusted with respect to any locally defined public -CAs, it is the domain owner's responsibility to ensure that the -certificate associations in their TLSA records are appropriate -to authenticate their SMTP servers.

    - -

    In addition, the Postfix SMTP client does not assume that the -remote SMTP server will necessarily be configured to present the -certificate of any usage "0" root CA in its TLS protocol certificate_list. -Therefore, support for usage "0" certificate and public-key digests -is disabled by default, see tls_dane_trust_anchor_digest_enable for -details. While undigested trust-anchor certificates in TLSA records -are supported, publishing complete certificates in DNS is unwise -given the resulting excessively large DNS record sizes. Therefore, -in its default configuration the Postfix SMTP client essentially -supports only certificate usages "1", "2" and "3" (with "1" treated as -though it were "3").

    - -

    Finally, the interaction of DANE with MX hostnames that are -CNAMEs differs from the draft specification in the names used to -construct the associated TLSA -queries. When the MX hostname is a CNAME, the draft proposal -to use the unexpanded MX hostname in TLSA lookups is fragile and -unintuitive. For this to work, the domain owner has to either -duplicate the TLSA records of the target (host, service) pair in -his own DNS or furnish the target host with an additional -certificate and private key that would be negotiated via SNI. -Neither of these are robust or easy to manage. It is far better -to expand the CNAME recursively to the underlying target hostname -(keeping track of DNSSEC validation along the way) and to use the -expanded name to construct the TLSA query and, if appropriate, in -server certificate name checks. This is the approach taken by the -Postfix SMTP client, and if sanity prevails will also be the approach -taken in the final standard.

    +

    DANE for SMTP MTAs deviates in some details from the baseline +DANE protocol in RFC 6698. Most notably, it is not expected that +SMTP MTAs can reasonably include every public CA that a remote SMTP +server's administrator may believe to be well-known. Nor is there +an interactive user to "click OK" when authentication fails.

    + +

    Therefore, certificate usages "0" and "1" from RFC 6698 which +are intended to "constrain" existing PKI trust, are not supported. +TLSA records with usage "0" are treated as "unusable". TLSA records +with usage "1" are instead treated as "trust assertions" and mapped +to usage "3". Specifically, with certificate usage "1", Postfix +will not require the remote SMTP server's certificate to be trusted +with respect to any locally defined public CAs, it is the domain +owner's responsibility to ensure that the certificate associations +in their TLSA records are appropriate to authenticate their SMTP +servers.

    + +

    The Postfix SMTP client supports only certificate usages "2" +and "3" (with "1" treated as though it were "3"). See +tls_dane_trust_anchor_digest_enable for usage "2" usability +considerations. Support for certificate usage "1" is an experiment, +it may be withdrawn in the future. Server operators SHOULD NOT +publish TLSA records with usage "1".

    When usable TLSA records are obtained for the remote SMTP server -the Postfix SMTP client is obligated to include the SNI TLS extension -in its SSL client hello message. This may help the remote SMTP -server live up to its promise to provide a certificate that matches -its TLSA records. Since TLS extensions require TLS 1.0 or later, -the Postfix SMTP client must disable SSLv2 and SSLv3 when SNI is -required. If you use "dane" or "dane-only", do not disable TLSv1, -except perhaps via the policy table for destinations which you are -sure will support TLSv1.1 or TLSv1.2.

    +the Postfix SMTP client sends the SNI TLS extension in its SSL +client hello message. This may help the remote SMTP server live +up to its promise to provide a certificate that matches its TLSA +records.

    For purposes of protocol and cipher selection, the "dane" security level is treated like a "mandatory" TLS security level, @@ -1357,14 +1345,14 @@ certificate must contain at least one of these names.

    When a DANE TLSA record specifies an end-entity (EE) certificate, (that is the actual server certificate), as with the fingerprint security level below, no name checks or certificate expiration checks -are applied. The server certificate (or its public key) either matches +are applied. The server certificate (or its public key) either matches the DANE record or not. Server administrators should publish such EE records in preference to all other types.

    The pre-requisites for DANE support in the Postfix SMTP client are:

    @@ -861,8 +854,8 @@ certificates that use only the anonymous ciphers. This is enabled by explicitly setting "smtpd_tls_cert_file = none" and not specifying an smtpd_tls_dcert_file or smtpd_tls_eccert_file.

    -

    Example, MSA that requires TLSv1, not SSLv2 or SSLv3, with high grade -ciphers:

    +

    Example, MSA that requires TLSv1 or higher, not SSLv2 or SSLv3, +with high grade ciphers: 

    @@ -872,9 +865,9 @@ ciphers: 
    
     smtpd_tls_mandatory_ciphers = high
     smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
     smtpd_tls_security_level = encrypt
-    # Preferred form with Postfix ≥ 2.5:
+    # Postfix ≥ 2.5:
     smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
-    # Alternative form.
+    # Legacy form with Postfix prior to 2.5:
     smtpd_tls_mandatory_protocols = TLSv1
    @@ -918,23 +911,27 @@ secure for most situations.

    Postfix 2.8 and later, in combination with OpenSSL 0.9.7 and later -allows TLS servers to preempt the TLS client's cipher preference list. +allows TLS servers to preempt the TLS client's cipher-suite preference list. This is possible only with SSLv3 and later, as in SSLv2 the client -chooses the cipher from a list supplied by the server.

    +chooses the cipher-suite from a list supplied by the server.

    By default, the OpenSSL server selects the client's most preferred -cipher that the server supports. With SSLv3 and later, the server -may choose its own most preferred cipher that is supported (offered) +cipher-suite that the server supports. With SSLv3 and later, the server +may choose its own most preferred cipher-suite that is supported (offered) by the client. Setting "tls_preempt_cipherlist = yes" enables server -cipher preferences. The default OpenSSL behavior applies with +cipher-suite preferences. The default OpenSSL behavior applies with "tls_preempt_cipherlist = no".

    -

    While server cipher selection may in some cases lead to a more secure -or performant cipher choice, there is some risk of interoperability -issues. In the past, some SSL clients have listed lower priority ciphers -that they did not implement correctly. If the server chooses a cipher -that the client prefers less, it may select a cipher whose client -implementation is flawed.

    +

    While server cipher-suite selection may in some cases lead to +a more secure or performant cipher-suite choice, there is some risk +of interoperability issues. In the past, some SSL clients have +listed lower priority ciphers that they did not implement correctly. +If the server chooses a cipher that the client prefers less, it may +select a cipher whose client implementation is flawed. Most notably +Windows 2003 Microsoft Exchange servers have flawed implementations +of DES-CBC3-SHA, which OpenSSL considers stronger than RC4-SHA. +Enabling server cipher-suite selection may create interoperability +issues with Windows 2003 Microsoft Exchange clients.

    Miscellaneous server controls

    @@ -1251,17 +1248,30 @@ the mandatory "dane-only" level.

    href="#client_tls_may">opportunistic TLS that is resistant to man in the middle and downgrade attacks when the destination domain uses DNSSEC to publish DANE TLSA records for its MX hosts. If a -remote SMTP server has usable DANE TLSA records, these will be used -to authenticate the server. If TLSA records are published for a -given remote SMTP server (implying TLS support), but are not usable -due to unsupported parameters, the Postfix SMTP client will use + +

    If TLSA records are published for a given remote SMTP server +(implying TLS support), but are all "unusable" due to unsupported +parameters or malformed data, the Postfix SMTP client will use mandatory unauthenticated TLS. -Otherwise, the Postfix SMTP client behavior is the same as with may.

    +Otherwise, when no TLSA records are published, the Postfix SMTP +client behavior is the same as with may.

    + +

    TLSA records must be published in DNSSEC validated DNS zones. +Any TLSA records in DNS zones not protected via DNSSEC are ignored. +The Postfix SMTP client will not look for TLSA records associated +with MX hosts whose "A" or "AAAA" records lie in an "insecure" DNS +zone. Such lookups have been observed to cause interoperability +issues with poorly implemented DNS servers, and are in any case not +expected to ever yield "secure" results, since that would require +a very unlikey DLV DNS trust anchor configured between the host +record and the associated "_25._tcp" child TLSA record.

    The "dane-only" level is a form of secure-channel TLS based on the DANE PKI. -If usable TLSA records are present these are used to authenticate the +If "usable" TLSA records are present these are used to authenticate the remote SMTP server. Otherwise, or when server certificate verification fails, delivery via the server in question tempfails.

    @@ -1271,73 +1281,51 @@ to be in effect, the destination domain's containing DNS zone must be signed and the Postfix SMTP client's operating system must be configured to send its DNS queries to a recursive DNS nameserver that is able to validate the signed records. Each MX host's DNS -zone should also be signed, and should publish DANE TLSA (RFC 6698) +zone needs to also be signed, and needs to publish DANE TLSA (RFC 6698) records that specify how that MX host's TLS certificate is to be -verified. TLSA records do not preempt the normal SMTP MX host +verified.

    + +

    TLSA records do not preempt the normal SMTP MX host selection algorithm, if some MX hosts support TLSA and others do not, TLS security will vary from delivery to delivery. It is up to the domain owner to configure their MX hosts and their DNS sensibly. To configure the Postfix SMTP client for DNSSEC lookups see the documentation for the smtp_dns_support_level main.cf parameter. The tls_dane_trust_anchor_digest_enable main.cf parameter -controls optional support for trust-anchor digest TLSA records. +controls support for trust-anchor digest TLSA records. The +tls_dane_digests and tls_dane_digest_agility parameters control +the list of supported digests and digest downgrade attack resistance.

    -

    The Postfix SMTP client deviates from RFC 6698 in cases where -strict adherence is likely to create opportunities for delayed (or -eventually bounced) email with no substantive security gain. Most -notably, it is not expected that smtp_tls_CAfile and smtp_tls_CApath -can reasonably include every public CA that a remote SMTP server's -administrator may believe to be well-known. Therefore, certificate -usages "0" and "2" from RFC 6698 which are intended to "constrain" -existing PKI trust, are instead treated as "trust assertions" and -mapped to "1" and "3" respectively. That is, with certificate usage -"0" and "2", Postfix will not require the remote SMTP server's -certificate to be trusted with respect to any locally defined public -CAs, it is the domain owner's responsibility to ensure that the -certificate associations in their TLSA records are appropriate -to authenticate their SMTP servers.

    - -

    In addition, the Postfix SMTP client does not assume that the -remote SMTP server will necessarily be configured to present the -certificate of any usage "0" root CA in its TLS protocol certificate_list. -Therefore, support for usage "0" certificate and public-key digests -is disabled by default, see tls_dane_trust_anchor_digest_enable for -details. While undigested trust-anchor certificates in TLSA records -are supported, publishing complete certificates in DNS is unwise -given the resulting excessively large DNS record sizes. Therefore, -in its default configuration the Postfix SMTP client essentially -supports only certificate usages "1", "2" and "3" (with "1" treated as -though it were "3").

    - -

    Finally, the interaction of DANE with MX hostnames that are -CNAMEs differs from the draft specification in the names used to -construct the associated TLSA -queries. When the MX hostname is a CNAME, the draft proposal -to use the unexpanded MX hostname in TLSA lookups is fragile and -unintuitive. For this to work, the domain owner has to either -duplicate the TLSA records of the target (host, service) pair in -his own DNS or furnish the target host with an additional -certificate and private key that would be negotiated via SNI. -Neither of these are robust or easy to manage. It is far better -to expand the CNAME recursively to the underlying target hostname -(keeping track of DNSSEC validation along the way) and to use the -expanded name to construct the TLSA query and, if appropriate, in -server certificate name checks. This is the approach taken by the -Postfix SMTP client, and if sanity prevails will also be the approach -taken in the final standard.

    +

    DANE for SMTP MTAs deviates in some details from the baseline +DANE protocol in RFC 6698. Most notably, it is not expected that +SMTP MTAs can reasonably include every public CA that a remote SMTP +server's administrator may believe to be well-known. Nor is there +an interactive user to "click OK" when authentication fails.

    + +

    Therefore, certificate usages "0" and "1" from RFC 6698 which +are intended to "constrain" existing PKI trust, are not supported. +TLSA records with usage "0" are treated as "unusable". TLSA records +with usage "1" are instead treated as "trust assertions" and mapped +to usage "3". Specifically, with certificate usage "1", Postfix +will not require the remote SMTP server's certificate to be trusted +with respect to any locally defined public CAs, it is the domain +owner's responsibility to ensure that the certificate associations +in their TLSA records are appropriate to authenticate their SMTP +servers.

    + +

    The Postfix SMTP client supports only certificate usages "2" +and "3" (with "1" treated as though it were "3"). See +tls_dane_trust_anchor_digest_enable for usage "2" usability +considerations. Support for certificate usage "1" is an experiment, +it may be withdrawn in the future. Server operators SHOULD NOT +publish TLSA records with usage "1".

    When usable TLSA records are obtained for the remote SMTP server -the Postfix SMTP client is obligated to include the SNI TLS extension -in its SSL client hello message. This may help the remote SMTP -server live up to its promise to provide a certificate that matches -its TLSA records. Since TLS extensions require TLS 1.0 or later, -the Postfix SMTP client must disable SSLv2 and SSLv3 when SNI is -required. If you use "dane" or "dane-only", do not disable TLSv1, -except perhaps via the policy table for destinations which you are -sure will support TLSv1.1 or TLSv1.2.

    +the Postfix SMTP client sends the SNI TLS extension in its SSL +client hello message. This may help the remote SMTP server live +up to its promise to provide a certificate that matches its TLSA +records.

    For purposes of protocol and cipher selection, the "dane" security level is treated like a "mandatory" TLS security level, @@ -1357,14 +1345,14 @@ certificate must contain at least one of these names.

    When a DANE TLSA record specifies an end-entity (EE) certificate, (that is the actual server certificate), as with the fingerprint security level below, no name checks or certificate expiration checks -are applied. The server certificate (or its public key) either matches +are applied. The server certificate (or its public key) either matches the DANE record or not. Server administrators should publish such EE records in preference to all other types.

    The pre-requisites for DANE support in the Postfix SMTP client are: