10924
11080
mandatory encrypted sessions. This security level is not an appropriate
10925
11081
default for systems delivering mail to the Internet. </dd>
10927
<dt><b>fingerprint</b></dt> <dd>Certificate fingerprint
10928
verification. Available with Postfix 2.5 and later. At this security
10929
level, there are no trusted certificate authorities. The certificate
10930
trust chain, expiration date, ... are not checked. Instead, the
10931
<b>smtp_tls_fingerprint_cert_match</b> parameter lists the certificate
10932
fingerprint or public key fingerprint (Postfix 2.9 and later) of
10933
the valid server certificate. The digest
11083
<dt><b><a href="TLS_README.html#client_tls_dane">dane</a></b></dt>
11084
<dd>Opportunistic DANE TLS. At this security level, the TLS policy
11085
for the destination is obtained via DNSSEC. For TLSA policy to be
11086
in effect, the destination domain's containing DNS zone must be
11087
signed and the Postfix SMTP client's operating system must be
11088
configured to send its DNS queries to a recursive DNS nameserver
11089
that is able to validate the signed records. Each MX host's DNS
11090
zone should also be signed, and should publish DANE TLSA (RFC 6698)
11091
records that specify how that MX host's TLS certificate is to be
11092
verified. TLSA records do not preempt the normal SMTP MX host
11093
selection algorithm, if some MX hosts support TLSA and others do
11094
not, TLS security will vary from delivery to delivery. It is up
11095
to the domain owner to configure their MX hosts and their DNS
11096
sensibly. To configure the Postfix SMTP client for DNSSEC lookups
11097
see the documentation for the smtp_dns_support_level main.cf
11098
parameter. When DNSSEC-validated TLSA records are not found the
11099
effective tls security level is "may". When TLSA records are found,
11100
but are all unusable the effective security level is "encrypt". For
11101
purposes of protocol and cipher selection, the "dane" security level
11102
is treated like a "mandatory" TLS security level, and weak ciphers
11103
and protocols are disabled. Since DANE authenticates server
11104
certificates the "aNULL" cipher-suites are transparently excluded
11105
at this level, no need to configure this manually. RFC 6698 (DANE)
11106
TLS authentication is available with Postfix 2.11 and later. </dd>
11108
<dt><b><a href="TLS_README.html#client_tls_dane">dane-only</a></b></dt>
11109
<dd>Mandatory DANE TLS. This is just like "dane" above, but DANE
11110
TLSA authentication is required. There is no fallback to "may" or
11111
"encrypt" when TLSA records are missing or unusable. RFC 6698
11112
(DANE) TLS authentication is available with Postfix 2.11 and later.
11115
<dt><b><a href="TLS_README.html#client_tls_fingerprint">fingerprint</a></b></dt>
11116
<dd>Certificate fingerprint verification.
11117
At this security level, there are no trusted certificate authorities.
11118
The certificate trust chain, expiration date, etc., are
11119
not checked. Instead, the <b>smtp_tls_fingerprint_cert_match</b>
11120
parameter lists the certificate fingerprint or public key fingerprint
11121
(Postfix 2.9 and later) of the valid server certificate. The digest
10934
11122
algorithm used to calculate the fingerprint is selected by the
10935
<b>smtp_tls_fingerprint_digest</b> parameter. </dd>
11123
<b>smtp_tls_fingerprint_digest</b> parameter. Available with Postfix
11124
2.5 and later. </dd>
10937
<dt><b>verify</b></dt> <dd>Mandatory TLS verification. At this security
11126
<dt><b><a href="TLS_README.html#client_tls_verify">verify</a></b></dt>
11127
<dd>Mandatory TLS verification. At this security
10938
11128
level, DNS MX lookups are trusted to be secure enough, and the name
10939
11129
verified in the server certificate is usually obtained indirectly
10940
11130
via unauthenticated DNS MX lookups. The smtp_tls_verify_cert_match
14937
15194
<p> This feature is available in Postfix 2.10 and later. </p>
15196
%PARAM smtp_dns_support_level
15198
<p> Level of DNS support in the Postfix SMTP client. With
15199
"smtp_dns_support_level" left at its empty default value, the legacy
15200
"disable_dns_lookups" parameter controls whether DNS is enabled in
15201
the Postfix SMTP client, otherwise the legacy parameter is ignored.
15204
<p> Specify one of the following: </p>
15208
<dt><b>disabled</b></dt>
15210
<dd>Disable DNS lookups. No MX lookups are performed and hostname
15211
to address lookups are unconditionally "native". This setting is
15212
not appropriate for hosts that deliver mail to the public Internet.
15213
Some obsolete how-to documents recommend disabling DNS lookups in
15214
some configurations with content_filters. This is no longer required
15215
and strongly discouraged. </dd>
15217
<dt><b>enabled</b></dt>
15219
<dd>Enable DNS lookups. Nexthop destination domains not enclosed
15220
in "[]" will be subject to MX lookups. If "dns" and "native" are
15221
included in the "smtp_host_lookup" parameter value, DNS will be
15222
queried first to resolve MX-host A records, followed by "native"
15223
lookups if no answer is found in DNS. </dd>
15225
<dt><b>dnssec</b></dt>
15227
<dd>Enable <a href="https://tools.ietf.org/html/rfc4033">DNSSEC</a>
15228
lookups. The "dnssec" setting differs from the "enabled" setting
15229
above in the following ways: <ul> <li>Any MX lookups will set
15230
RES_USE_DNSSEC and RES_USE_EDNS0 to request DNSSEC-validated
15231
responses. If the MX response is DNSSEC-validated the corresponding
15232
hostnames are considered validated. <li> The address lookups of
15233
validated hostnames are also validated, (provided of course
15234
"smtp_host_lookup" includes "dns", see below). <li>Temporary
15235
failures in DNSSEC-enabled hostname-to-address resolution block any
15236
"native" lookups. Additional "native" lookups only happen when
15237
DNSSEC lookups hard-fail (NODATA or NXDOMAIN). </ul> </dd>
15241
<p> The Postfix SMTP client considers non-MX "[nexthop]" and
15242
"[nexthop]:port" destinations equivalent to statically-validated
15243
MX records of the form "nexthop. IN MX 0 nexthop." Therefore,
15244
with "dnssec" support turned on, validated hostname-to-address
15245
lookups apply to the nexthop domain of any "[nexthop]" or
15246
"[nexthop]:port" destination. This is also true for LMTP "inet:host"
15247
and "inet:host:port" destinations, as LMTP hostnames are never
15248
subject to MX lookups. </p>
15250
<p>The "dnssec" setting is recommended only if you plan to use the
15251
<a href="TLS_README.html#client_tls_dane">dane</a> or <a
15252
href="TLS_README.html#client_tls_dane">dane-only</a> TLS security
15253
level, otherwise enabling DNSSEC support in Postfix offers no
15254
additional security. Postfix DNSSEC support relies on an upstream
15255
recursive nameserver that validates DNSSEC signatures. Such a DNS
15256
server will always filter out forged DNS responses, even when Postfix
15257
itself is not configured to use DNSSEC. </p>
15259
<p> When using Postfix DANE support the "smtp_host_lookup" parameter
15260
should include "dns", as <a
15261
href="https://tools.ietf.org/html/rfc6698">DANE</a> is not applicable
15262
to hosts resolved via "native" lookups. </p>
15264
<p> As mentioned above, Postfix is not a validating <a
15265
href="https://tools.ietf.org/html/rfc4035#section-4.9">stub
15266
resolver</a>; it relies on the system's configured DNSSEC-validating
15267
<a href="https://tools.ietf.org/html/rfc4035#section-3.2">recursive
15268
nameserver</a> to perform all DNSSEC validation. Since this
15269
nameserver's DNSSEC-validated responses will be fully trusted, it
15270
is strongly recommended that the MTA host have a local DNSSEC-validating
15271
recursive caching nameserver listening on a loopback address, and
15272
be configured to use only this nameserver for all lookups. Otherwise,
15273
Postfix may remain subject to man-in-the-middle attacks that forge
15274
responses from the recursive nameserver</p>
15276
<p>DNSSEC support requires a version of Postfix compiled against a
15277
reasonably-modern DNS resolver(3) library that implements the
15278
RES_USE_DNSSEC and RES_USE_EDNS0 resolver options. </p>
15280
<p> This feature is available in Postfix 2.11 and later. </p>
15282
%PARAM lmtp_dns_support_level
15284
<p> The LMTP-specific version of the smtp_dns_support_level
15285
configuration parameter. See there for details. </p>
15287
<p> This feature is available in Postfix 2.11 and later. </p>
15289
%PARAM smtp_tls_trust_anchor_file
15291
<p> Zero or more PEM-format files with trust-anchor certificates
15292
and/or public keys. If the parameter is not empty the root CAs in
15293
CAfile and CApath are no longer trusted. Rather, the Postfix SMTP
15294
client will only trust certificate-chains signed by one of the
15295
trust-anchors contained in the chosen files. The specified
15296
trust-anchor certificates and public keys are not subject to
15297
expiration, and need not be (self-signed) root CAs. They may, if
15298
desired, be intermediate certificates. Therefore, these certificates
15299
also may be found "in the middle" of the trust chain presented by
15300
the remote SMTP server, and any untrusted issuing parent certificates
15301
will be ignored. Specify a list of pathnames separated by comma
15302
or whitespace. </p>
15304
<p> Whether specified in main.cf, or on a per-destination basis,
15305
the trust-anchor PEM file must be accessible to the Postfix SMTP
15306
client in the chroot jail if applicable. The trust-anchor file
15307
should contain only certificates and public keys, no private key
15308
material, and must be readable by the non-privileged $mail_owner
15309
user. This allows destinations to be bound to a set of specific
15310
CAs or public keys without trusting the same CAs for all destinations.
15313
<p> The main.cf parameter supports single-purpose Postfix installations
15314
that send mail to a fixed set of SMTP peers. At most sites, if
15315
trust-anchor files are used at all, they will be specified on a
15316
per-destination basis via the "tafile" attribute of the "verify"
15317
and "secure" levels in smtp_tls_policy_maps. </p>
15319
<p> The underlying mechanism is in support of RFC 6698 (DANE TLSA),
15320
which defines mechanisms for a client to securely determine server
15321
TLS certificates via DNS. </p>
15323
<p> If you want your trust anchors to be public keys, with OpenSSL
15324
you can extract a single PEM public key from a PEM X.509 file
15325
containing a single certificate, as follows: </p>
15329
$ openssl x509 -in cert.pem -out ta-key.pem -noout -pubkey
15333
<p> This feature is available in Postfix 2.11 and later. </p>
15335
%PARAM lmtp_tls_trust_anchor_file
15337
<p> The LMTP-specific version of the smtp_tls_trust_anchor_file
15338
configuration parameter. See there for details. </p>
15340
<p> This feature is available in Postfix 2.11 and later. </p>
15342
%PARAM tls_dane_trust_anchor_digest_enable yes
15344
<p> RFC 6698 trust-anchor digest support in the Postfix TLS library.
15345
Enable support for RFC 6698 (DANE TLSA) DNS records that contain
15346
digests of trust-anchors with certificate usage "2". In this case
15347
the certificate usage logically requires the server administrator
15348
to configure the server to include the trust-anchor certificate in
15349
the server's SSL certificate chain. If enough domains mess this
15350
up, you can disable support for these TLSA records, but you'll no
15351
longer have secure connections that get it right and only publish
15352
trust anchor records. </p>
15354
<p> At the <a href="TLS_README.html#client_tls_dane">dane</a>
15355
security level, when a TLSA RRset includes only unusable associations,
15356
the Postfix SMTP client will automatically switch the connection
15357
to the <a href="TLS_README.html#client_tls_encrypt">encrypt</a>
15358
security level. At the <a
15359
href="TLS_README.html#client_tls_dane">dane-only</a> security level,
15360
the server in question is skipped and delivery is deferred if no
15361
secure servers are found. </p>
15363
<p> The tls_dane_digests parameter controls the list of digest
15364
algorithms that are supported in TLSA records. The tls_dane_digest_agility
15365
parameter controls digest algorithm downgrade attack resistance.
15368
<p> This feature is available in Postfix 2.11 and later. </p>
15370
%PARAM tls_wildcard_matches_multiple_labels yes
15372
<p> Match multiple DNS labels with "*" in wildcard certificates.
15375
<p> Some mail service providers prepend the customer domain name
15376
to a base domain for which they have a wildcard TLS certificate.
15377
For example, the MX records for example.com hosted by example.net
15382
example.com. IN MX 0 example.com.mx1.example.net.
15383
example.com. IN MX 0 example.com.mx2.example.net.
15387
<p> and the TLS certificate may be for "*.example.net". The "*"
15388
then corresponds with multiple labels in the mail server domain
15389
name. While multi-label wildcards are not widely supported, and
15390
are not blessed by any standard, there is little to be gained by
15391
disallowing their use in this context. </p>
15397
<li> <p> In a certificate name, the "*" is special only when it is
15398
used as the first label. </p>
15400
<li> <p> While Postfix (2.11 or later) can match "*" with multiple
15401
domain name labels, other implementations likely will not. </p>
15403
<li> <p> Earlier Postfix implementations behave as if
15404
"tls_wildcard_matches_multiple_labels = no". </p>
15408
<p> This feature is available in Postfix 2.11 and later. </p>
15410
%PARAM tls_ssl_options
15412
<p> List or bit-mask of OpenSSL options to enable. </p>
15414
<p> The OpenSSL toolkit provides a set of options that applications
15415
can enable to tune the OpenSSL behavior. Some of these work around
15416
bugs in other implementations and are on by default. You can use
15417
the tls_disable_workarounds parameter to selectively disable some
15418
or all of the bug work-arounds, making OpenSSL more strict at the
15419
cost of non-interoperability with SSL clients or servers that exhibit
15422
<p> Other options are off by default, and typically enable or disable
15423
features rather than bug work-arounds. These may be turned on (with
15424
care) via the tls_ssl_options parameter. The value is a white-space
15425
or comma separated list of named options chosen from the list below.
15426
The names are not case-sensitive, you can use lower-case if you
15427
prefer. The upper case values below match the corresponding macro
15428
name in the ssl.h header file with the SSL_OP_ prefix removed. It
15429
is possible that your OpenSSL version includes new options added
15430
after your Postfix source code was last updated, in that case you
15431
can only enable one of these via the hexadecimal syntax below. </p>
15433
<p> You should only enable features via the hexadecimal mask when
15434
the need to control the feature is critical (to deal with a new
15435
vulnerability or a serious interoperability problem). Postfix DOES
15436
NOT promise backwards compatible behavior with respect to the mask
15437
bits. A feature enabled via the mask in one release may be enabled
15438
by other means in a later release, and the mask bit will then be
15439
ignored. Therefore, use of the hexadecimal mask is only a temporary
15440
measure until a new Postfix or OpenSSL release provides a better
15443
<p> If the value of the parameter is a hexadecimal long integer
15444
starting with "0x", the options corresponding to the bits specified
15445
in its value are enabled (see openssl/ssl.h and SSL_CTX_set_options(3)).
15446
You can only enable options not already controlled by other Postfix
15447
settings. For example, you cannot disable protocols or enable
15448
server cipher preference. Do not attempt to turn all features by
15449
specifying 0xFFFFFFFF, this is unlikely to be a good idea. </p>
15453
<dt><b>LEGACY_SERVER_CONNECT</b></dt> <dd>See SSL_CTX_set_options(3).</dd>
15455
<dt><b>NO_TICKET</b></dt> <dd>See SSL_CTX_set_options(3).</dd>
15457
<dt><b>NO_COMPRESSION</b></dt> <dd>Disable SSL compression even if
15458
supported by the OpenSSL library. Compression is CPU-intensive,
15459
and compression before encryption does not always improve security. </dd>
15463
<p> This feature is available in Postfix 2.11 and later. </p>
15465
%PARAM tlsmgr_service_name tlsmgr
15467
<p> The name of the tlsmgr(8) service entry in master.cf. This
15468
service maintains TLS session caches and other information in support
15471
<p> This feature is available in Postfix 2.11 and later. </p>
15473
%PARAM lmtp_connection_reuse_count_limit 0
15475
<p> The LMTP-specific version of the smtp_connection_reuse_count_limit
15476
configuration parameter. See there for details. </p>
15478
<p> This feature is available in Postfix 2.11 and later. </p>
15480
%PARAM smtp_connection_reuse_count_limit 0
15482
<p> When SMTP connection caching is enabled, the number of times
15483
that an SMTP session may be reused before it is closed, or zero (no
15484
limit). With a reuse count limit of N, a connection is used up to
15487
<p> NOTE: This feature is unsafe. When a high-volume destination
15488
has multiple inbound MTAs, then the slowest inbound MTA will attract
15489
the most connections to that destination. This limitation does not
15490
exist with the smtp_connection_reuse_time_limit feature. </p>
15492
<p> This feature is available in Postfix 2.11. </p>
15494
%PARAM lmtp_tls_force_insecure_host_tlsa_lookup no
15496
<p> The LMTP-specific version of the smtp_tls_force_insecure_host_tlsa_lookup
15497
configuration parameter. See there for details. </p>
15499
<p> This feature is available in Postfix 2.11 and later. </p>
15501
%PARAM smtp_tls_force_insecure_host_tlsa_lookup no
15503
<p> Lookup the associated DANE TLSA RRset even when a hostname is
15504
not an alias and its address records lie in an unsigned zone. This
15505
is unlikely to ever yield DNSSEC validated results, since child
15506
zones of unsigned zones are also unsigned in the absence of DLV or
15507
locally configured non-root trust-anchors. We anticipate that such
15508
mechanisms will not be used for just the "_tcp" subdomain of a host.
15509
Suppressing the TLSA RRset lookup reduces latency and avoids potential
15510
interoperability problems with nameservers for unsigned zones that
15511
are not prepared to handle the new TLSA RRset. </p>
15513
<p> This feature is available in Postfix 2.11. </p>
15515
%PARAM tls_dane_digest_agility on
15517
<p> Configure DANE TLSA digest algorithm agility. When digest
15518
algorithm agility is enabled, and the server and client support a
15519
common strong digest algorithm, TLSA records with weaker digest
15520
algorithms are ignored. </p>
15522
<p> Specify one of the following: </p>
15526
<dt><b>off</b></dt>
15527
<dd> DANE verification examines each well-formed record in the TLSA
15528
RRset whose matching type is either "0" (no hash used) or is one of
15529
the digest algorithms listed in $tls_dane_digests. This setting
15530
is not recommended. </dd>
15533
<dd> From each group of well-formed TLSA RRs a non-zero digest
15534
matching type with the same certificate usage and selector, DANE
15535
verification examines only those records whose matching type has
15536
the highest precedence (appear earliest in $tls_dane_digests).
15539
<dt><b>maybe</b></dt>
15540
<dd> For compatibility with digest algorithm agility, each certificate
15541
or public key whose digest is included in a DANE TLSA RRset, SHOULD
15542
be published with the same set of digest matching type values as
15543
any other with the same usage and selector. Therefore, compatible
15544
TLSA RRsets will contain an identical count of well-formed RRs with
15545
each non-zero digest matching type for any fixed combination of
15546
usage and selector. When this constraint is violated, or any of
15547
the digest records are malformed, digest algorithm agility will
15548
disabled. Otherwise, digest algorithm agility is enabled. </dd>
15552
<p> Digest algorithm agility ensures that the strongest digest
15553
supported by both the Postfix SMTP client and the remote server is
15554
used, and weaker digests are ignored. This supports non-disruptive
15555
deprecation of outdated digest algorithms. </p>
15557
<p> To ensure compatibility with digest algorithm agility during
15558
key rotation, when a certificate or public key is being replaced
15559
with another, and both are published during the transition, both
15560
the old and the new certificate MUST be specified with the same set
15561
of digests. One can change the list of digest algorithms later,
15562
once old keys are retired. At any given time, change either the
15563
list of digests without changing the list of certificates or public
15564
keys or the list of certificates or public keys without changing
15565
the list of digests. Full value matching type "0" records are not
15566
subject to this constraint, but are discouraged due to the size of
15567
the resulting DNS records. </p>
15569
<p> It is expected that this algorithm agility mechanism will be
15570
published in a standards track RFC for SMTP with DANE, and also in
15571
an eventual update to RFC 6698. </p>
15573
<p> This feature is available in Postfix 2.11 and later. </p>
15575
%PARAM tls_dane_digests sha512 sha256
15577
<p> RFC 6698 TLSA resource-record "matching type" digest algorithms
15578
in descending preference order. All the specified algorithms must
15579
be supported by the underlying OpenSSL library, otherwise the Postfix
15580
SMTP client will not support DANE TLSA security. </p>
15582
<p> Specify a list of digest names separated by commas and/or
15583
whitespace. Each digest name may be followed by an optional
15584
"=<number>" suffix. For example, "sha512" may instead be specified
15585
as "sha512=2" and "sha256" may instead be specified as "sha256=1".
15586
The optional number must match the <a
15587
href="https://www.iana.org/assignments/dane-parameters/dane-parameters.xhtml#matching-types"
15588
>IANA</a> assigned TLSA matching type number the algorithm in question.
15589
Postfix will check this constraint for the algorithms it knows about.
15590
Additional matching type algorithms registered with IANA can be added
15591
with explicit numbers provided they are supported by OpenSSL. </p>
15593
<p> Invalid list elements are logged with a warning and disable DANE
15594
support. TLSA RRs that specify digests not included in the list are
15595
ignored with a warning. </p>
15597
<p> Note: It is unwise to omit sha256 from the digest list. This
15598
digest algorithm is the only mandatory to implement digest algorithm
15599
in RFC 6698, and many servers are expected publish TLSA records
15600
with just sha256 digests. Unless one of the standard digests is
15601
seriously compromised and servers have had ample time to update their
15602
TLSA records you should not omit any standard digests, just arrange
15603
them in order from strongest to weakest. </p>
15605
<p> When for a particular combination of "certificate usage" and
15606
"selector" the TLSA RRset contains records with more than one digest
15607
matching type, the tls_dane_digest_agility parameter determines
15608
whether all the RRs are used, or only those with the most preferred
15609
digest matching type. </p>
15611
<p> The tls_dane_trust_anchor_digest_enable parameter controls
15612
whether any digest TLSA records are acceptable in usage "2" (trust
15613
anchor assertion) TLSA records. </p>
15615
<p> This feature is available in Postfix 2.11 and later. </p>