From: Wietse Venema Once the trivial-rewrite(8) daemon has determined a default
delivery method it searches the optional transport(5) table for
information that overrides the message destination and/or delivery
-method. Typical use of the transport(5) is to send mail to a system
+method. Typical use of the transport(5) table is to send mail to
+a system
that is not connected to the Internet, or to use a special SMTP
client configuration for destinations that have special requirements.
See, for example, the STANDARD_CONFIGURATION_README and UUCP_README
diff --git a/postfix/html/INSTALL.html b/postfix/html/INSTALL.html
index 0c08aa00a..916d82f8f 100644
--- a/postfix/html/INSTALL.html
+++ b/postfix/html/INSTALL.html
@@ -257,13 +257,16 @@ Postfix 2.0
Note: support for TLS (encrypted SMTP sessions and certificate
-based authentication) and for IP version 6 is still separate from
-Postfix but is expected to be merged soon. Note: IP version 6 support is compiled into Postfix on operating
+systems that have IPv6 support. See the IPV6_README file for details.
+ By turning on TLS support in Postfix, you not only get the
+ability to encrypt mail and to authenticate clients or servers.
+You also turn on thousands and thousands of lines of OpenSSL library
+code. Assuming that OpenSSL is written as carefully as Wietse's
+own code, every 1000 lines introduce one additional bug into
+Postfix. This document describes how to build Postfix with Transport
+Layer Security (TLS) support in the Postfix SMTP client and Postfix
+SMTP server, and how to configure the TLS manager daemon that
+maintains the Pseudo Random Number Generator (PRNG) pool and the
+TLS session cache information. Topics covered in this document: And last but not least, for the impatient: To build Postfix with TLS support, first we need to generate
+the make(1) files with the necessary definitions. This is
+done by invoking the command "make makefiles in the Postfix
+top-level directory and with arguments as shown next. If the OpenSSL include files (such as ssl.h) are
+in directory /usr/include/openssl, and the OpenSSL libraries
+(such as libssl.so and libcrypto.so) are in
+directory /usr/lib: If the OpenSSL include files (such as ssl.h) are
+in directory /usr/local/include/openssl, and the OpenSSL
+libraries (such as libssl.so and libcrypto.so)
+are in directory /usr/local/lib: If you need to apply other customizations (such as Berkeley DB
+databases, MySQL, PosgreSQL, LDAP or SASL), see the respective
+Postfix README documents, and combine their "make makefiles"
+instructions with the instructions above: To complete the build process, see the Postfix INSTALL
+instructions. Postfix has TLS support turned off by default, so
+you can start using Postfix as soon as it is installed. Topics covered in this section: In order to use TLS, the Postfix SMTP server needs a certificate
+and a private key. Both must be in "pem" format. The private key
+must not be encrypted, meaning: the key must be accessible without
+password. Both certificate and private key may be in the same
+file. Both RSA and DSA certificates are supported. Typically you will
+only have RSA certificates issued by a commercial CA. In addition,
+the tools supplied with OpenSSL will by default issue RSA certificates.
+You can have both at the same time, in which case the cipher used
+determines which certificate is presented. For Netscape and OpenSSL
+clients without special cipher choices, the RSA certificate is
+preferred. In order for remote SMTP clients to check the Postfix SMTP
+server certificates, the CA certificate (in case of a certificate
+chain, all CA certificates) must be available. You should add
+these certificates to the server certificate, the server certificate
+first, then the issuing CA(s). Example: the certificate for "server.dom.ain" was issued by
+"intermediate CA" which itself has a certificate issued by "root
+CA". Create the server.pem file with: A Postfix SMTP server certificate supplied here must be usable
+as SSL server certificate and hence pass the "openssl verify -purpose
+sslserver ..." test. A client that trusts the root CA has a local copy of the root
+CA certificate, so it is not necessary to include the root CA
+certificate here. Leaving it out of the "server.pem" file reduces
+the overhead of the TLS exchange. If you want the Postfix SMTP server to accept remote SMTP client
+certificates issued by these CAs, append the root certificate to
+$smtpd_tls_CAfile or install it in the $smtpd_tls_CApath directory. When
+you configure trust in a root CA, it is not necessary to explicitly trust
+intermediary CAs signed by the root CA, unless $smtpd_tls_verify_depth
+is less than the number of CAs in the certificate chain for the clients
+of interest. With a verify depth of 1 you can only verify certificates
+directly signed by a trusted CA, and all trusted intermediary CAs need to
+be configured explicitly. With a verify depth of 2 you can verify clients
+signed by a root CA or a direct intermediary CA (so long as the client
+is correctly configured to supply its intermediate CA certificate). RSA key and certificate examples: Their DSA counterparts: To verify a remote SMTP client certificate, the Postfix SMTP
+server needs to trust the certificates of the issuing certification
+authorities. These certificates in "pem" format can be stored in a
+single $smtpd_tls_CAfile or in multiple files, one CA per file in
+the $smtpd_tls_CApath directory. If you use a directory, don't forget
+to create the necessary "hash" links with: The $smtpd_tls_CAfile contains the CA certificates of one or
+more trusted CAs. The file is opened (with root privileges) before
+Postfix enters the optional chroot jail and so need not be accessible
+from inside the chroot jail. Additional trusted CAs can be specified via the $smtpd_tls_CApath
+directory, in which case the certificates are read (with $mail_owner
+privileges) from the files in the directory when the information
+is needed. Thus, the $smtpd_tls_CApath directory needs to be
+accessible inside the optional chroot jail. When you configure Postfix to request client certificates (by
+setting $smtpd_tls_asck_ccert = yes), any certificates in
+$smtpd_tls_CAfile are sent to the client, in order to allow it to
+choose an identity signed by a CA you trust. If no $smtpd_tls_CAfile
+is specified, no preferred CA list is sent, and the client is free
+to choose an identity signed by any CA. Many clients use a fixed
+identity regardless of the preferred CA list and you may be able
+to reduce TLS negotiation overhead by installing client CA certificates
+mostly or only in $smtpd_tls_CApath. In the latter case you need
+not specify a $smtpd_tls_CAfile. Note, that unless client certificates are used to allow greater
+access to TLS authenticated clients, it is best to not ask for
+client certificates at all, as in addition to increased overhead
+some clients (notably in some cases qmail) are unable to complete
+the TLS handshake when client certificates are requested. Example: To get additional information about Postfix SMTP server TLS
+activity you can increase the loglevel from 0..4. Each logging
+level also includes the information that is logged at a lower
+logging level. Use loglevel 3 only in case of problems. Use of loglevel 4 is
+strongly discouraged. Example: To include information about the protocol and cipher used as
+well as the client and issuer CommonName into the "Received:"
+message header, set the smtpd_tls_received_header variable to true.
+The default is no, as the information is not necessarily authentic.
+Only information recorded at the final destination is reliable,
+since the headers may be changed by intermediate servers. Example: By default, TLS is disabled in the Postfix SMTP server, so no
+difference to plain Postfix is visible. Explicitly switch it on
+using "smtpd_use_tls = yes". Example: With this, Postfix SMTP server announces STARTTLS support to
+SMTP clients, but does not require that clients use TLS encryption.
+ Note: when an unprivileged user invokes "sendmail -bs", STARTTLS
+is never offered due to insufficient privileges to access the server
+private key. This is intended behavior. You can ENFORCE the use of TLS, so that the Postfix SMTP server
+announces STARTTLS and accepts no mail without TLS encryption, by
+setting "smtpd_enforce_tls = yes". According to RFC 2487 this MUST
+NOT be applied in case of a publicly-referenced Postfix SMTP server.
+This option is off by default and should only seldom be used. Example: TLS is sometimes used in the non-standard "wrapper" mode where
+a server always uses TLS, instead of announcing STARTTLS support
+and waiting for clients to request TLS service. Some clients, namely
+Outlook [Express] prefer the "wrapper" mode. This is true for OE
+(Win32 < 5.0 and Win32 >=5.0 when run on a port<>25
+and OE (5.01 Mac on all ports). It is strictly discouraged to use this mode from main.cf. If
+you want to support this service, enable a special port in master.cf
+and specify "-o smtpd_tls_wrappermode = yes" as an smtpd(8) command
+line option. Port 465 (smtps) was once chosen for this feature.
+ Example: To receive a remote SMTP client certificate, the Postfix SMTP
+server must explicitly ask for one (any contents of $smtpd_tls_CAfile
+are also sent to the client as a hint for choosing a certificate
+from a suitable CA). Unfortunately, Netscape clients will either
+complain if no matching client certificate is available or will
+offer the user client a list of certificates to choose from.
+Additionally some MTAs (notably some versions of qmail) are unable
+to complete TLS negotiation when client certificates are requested,
+and abort the SMTP session. So this option is "off" by default.
+You will however need the certificate if you want to use certificate
+based relaying with, for example, the permit_tls_clientcerts
+feature. Example: You may also decide to REQUIRE a remote SMTP client certificate
+before allowing TLS connections. This feature is included for
+completeness, and implies "smtpd_tls_ask_ccert = yes". Please be aware, that this will inhibit TLS connections without
+a proper client certificate and that it makes sense only when
+non-TLS submission is disabled (smtpd_enforce_tls = yes). Otherwise,
+clients could bypass the restriction by simply not using STARTTLS
+at all. When TLS is not enforced, the connection will be handled as
+if only "smtpd_tls_ask_ccert = yes" is specified, and a warning is
+logged. Example: A client certificate verification depth of 1 is sufficient if
+the certificate is directly issued by a CA listed in the CA file.
+The default value (5) should also suffice for longer chains (root
+CA issues special CA which then issues the actual certificate...)
+ Example: Sending AUTH data over an unencrypted channel poses a security
+risk. When TLS layer encryption is required (smtpd_enforce_tls =
+yes), the Postfix SMTP server will announce and accept AUTH only
+after the TLS layer has been activated with STARTTLS. When TLS
+layer encryption is optional (smtpd_enforce_tls = no), it may
+however still be useful to only offer AUTH when TLS is active. To
+maintain compatibility with non-TLS clients, the default is to
+accept AUTH without encryption. In order to change this behavior,
+set "smtpd_tls_auth_only = yes". Example: The Postfix SMTP server and the remote SMTP client negotiate
+a session, which takes some computer time and network bandwidth.
+By default, this session information is cached only in the smtpd(8)
+process actually using this session and is lost when the process
+terminates. To share the session information between multiple
+smtpd(8) processes, a persistent session cache can be used. You
+can specify any database type that can store objects of several
+kbytes and that supports the sequence operator. DBM databases are
+not suitable because they can only store small objects. The cache
+is maintained by the tlsmgr(8) process, so there is no problem with
+concurrent access. Example: Cached Postfix SMTP server session information expires after
+a certain amount of time. Postfix/TLS does not use the OpenSSL
+default of 300s, but a longer time of 3600sec (=1 hour). RFC 2246
+recommends a maximum of 24 hours. Example: Postfix TLS support introduces two additional features for
+Postfix SMTP server access control: Allow the remote SMTP
+client SMTP request if the client certificate passes verification,
+and if its fingerprint is listed in the list of client certificates
+(see relay_clientcerts discussion below). Allow the remote
+client SMTP request if the client certificate passes verification.
+ The permit_tls_all_clientcerts feature must be used with caution,
+because it can result in too many access permissions. Use this
+feature only if a special CA issues the client certificates, and
+only if this CA is listed as trusted CA. If other CAs are trusted,
+any owner of a valid client certificate would be authorized.
+The permit_tls_all_clientcerts feature can be practical for a
+specially created email relay server. It is however recommended to stay with the permit_tls_clientcerts
+feature and list all certificates via $relay_clientcerts, as
+permit_tls_all_clientcerts does not permit any control when a
+certificate must no longer be used (e.g. an employee leaving). Example: The Postfix list manipulation routines give special treatment
+to whitespace and some other characters, making the use of certificate
+names unpractical. Instead we use the certificate fingerprints as
+they are difficult to fake but easy to use for lookup. Postfix
+lookup tables are in the form of (key, value) pairs. Since we only
+need the key, the value can be chosen freely, e.g. the name of
+the user or host. Example: To influence the Postfix SMTP server cipher selection scheme,
+you can give cipherlist string. A detailed description would go
+to far here; please refer to the OpenSSL documentation. If you
+don't know what to do with it, simply don't touch it and leave the
+(openssl-)compiled in default! DO NOT USE " to enclose the string, specify just the string!!! Example: If you want to take advantage of ciphers with EDH, DH parameters
+are needed. Instead of using the built-in DH parameters for both
+1024bit and 512bit, it is better to generate "own" parameters,
+since otherwise it would "pay" for a possible attacker to start a
+brute force attack against parameters that are used by everybody.
+For this reason, the parameters chosen are already different from
+those distributed with other TLS packages. To generate your own set of DH parameters, use: Examples: The smtpd_starttls_timeout parameter limits the time of Postfix
+SMTP server write and read operations during TLS startup and shutdown
+handshake procedures. Example: Topics covered in this section: During TLS startup negotiation the Postfix SMTP client may present
+a certificate to the remote SMTP server. The Netscape client is
+rather clever here and lets the user select between only those
+certificates that match CA certificates offered by the remote SMTP
+server. As the Postfix SMTP client uses the "SSL_connect()" function
+from the OpenSSL package, this is not possible and we have to choose
+just one certificate. So for now the default is to use _no_
+certificate and key unless one is explicitly specified here. Both RSA and DSA certificates are supported. You can have both
+at the same time, in which case the cipher used determines which
+certificate is presented. It is possible for the Postfix SMTP client to use the same
+key/certificate pair as the Postfix SMTP server. If a certificate
+is to be presented, it must be in "pem" format. The private key
+must not be encrypted, meaning: it must be accessible without
+password. Both parts (certificate and private key) may be in the
+same file. In order for remote SMTP servers to verify the Postfix SMTP
+client certificates, the CA certificate (in case of a certificate
+chain, all CA certificates) must be available. You should add
+these certificates to the client certificate, the client certificate
+first, then the issuing CA(s). Example: the certificate for "client.example.com" was issued by
+"intermediate CA" which itself has a certificate of "root CA".
+Create the client.pem file with: A Postfix SMTP client certificate supplied here must be usable
+as SSL client certificate and hence pass the "openssl verify -purpose
+sslclient ..." test. A server that trusts the root CA has a local copy of the root
+CA certificate, so it is not necessary to include the root CA
+certificate here. Leaving it out of the "client.pem" file reduces
+the overhead of the TLS exchange. If you want the Postfix SMTP client to accept remote SMTP server
+certificates issued by these CAs, append the root certificate to
+$smtp_tls_CAfile or install it in the $smtp_tls_CApath directory. When
+you configure trust in a root CA, it is not necessary to explicitly trust
+intermediary CAs signed by the root CA, unless $smtp_tls_verify_depth
+is less than the number of CAs in the certificate chain for the servers
+of interest. With a verify depth of 1 you can only verify certificates
+directly signed by a trusted CA, and all trusted intermediary CAs need to
+be configured explicitly. With a verify depth of 2 you can verify servers
+signed by a root CA or a direct intermediary CA (so long as the server
+is correctly configured to supply its intermediate CA certificate). RSA key and certificate examples: Their DSA counterparts: To verify a remote SMTP server certificate, the Postfix SMTP
+client needs to trust the certificates of the issuing certification
+authorities. These certificates in "pem" format can be stored in a
+single $smtp_tls_CAfile or in multiple files, one CA per file in
+the $smtp_tls_CApath directory. If you use a directory, don't forget
+to create the necessary "hash" links with: The $smtp_tls_CAfile contains the CA certificates of one or more
+trusted CAs. The file is opened (with root privileges) before Postfix
+enters the optional chroot jail and so need not be accessible from inside the
+chroot jail. Additional trusted CAs can be specified via the $smtp_tls_CApath
+directory, in which case the certificates are read (with $mail_owner
+privileges) from the files in the directory when the information
+is needed. Thus, the $smtp_tls_CApath directory needs to be accessible
+inside the optional chroot jail. The choice between $smtp_tls_CAfile and $smtpd_tls_CApath is
+a space/time tradeoff. If there are many trusted CAs, the cost of
+preloading them all into memory may not pay off in reduced access time
+when the certificate is needed. Example: To get additional information about Postfix SMTP client TLS
+activity you can increase the loglevel from 0..4. Each logging
+level also includes the information that is logged at a lower
+logging level. Example: The remote SMTP server and the Postfix SMTP client negotiate a
+session, which takes some computer time and network bandwidth. By
+default, this session information is cached only in the smtp(8)
+process actually using this session and is lost when the process
+terminates. To share the session information between multiple
+smtp(8) processes, a persistent session cache can be used. You
+can specify any database type that can store objects of several
+kbytes and that supports the sequence operator. DBM databases are
+not suitable because they can only store small objects. The cache
+is maintained by the tlsmgr(8) process, so there is no problem with
+concurrent access. Example: Cached Postfix SMTP client session information expires after
+a certain amount of time. Postfix/TLS does not use the OpenSSL
+default of 300s, but a longer time of 3600s (=1 hour). RFC 2246
+recommends a maximum of 24 hours. Example: By default, TLS is disabled in the Postfix SMTP client, so no
+difference to plain Postfix is visible. If you enable TLS, the
+Postfix SMTP client will send STARTTLS when TLS support is announced
+by the remote SMTP server. WARNING: MS Exchange servers will announce STARTTLS support
+even when the service is not configured, so that the TLS handshake
+will fail. It may be wise to not use this option on your central
+mail hub, as you don't know in advance whether you are going to
+connect to such a host. Instead, use the smtp_tls_per_site
+recipient/site specific options that are described below. When the TLS handshake fails and no other server is available,
+the Postfix SMTP client defers the delivery attempt, and the mail
+stays in the queue. Example: You can ENFORCE the use of TLS, so that the Postfix SMTP client
+will not deliver mail over unencrypted connections. In this mode,
+the remote SMTP server hostname must match the information in the
+remote server certificate, and the server certificate must be issued
+by a CA that is trusted by the Postfix SMTP client. If the remote
+server certificate doesn't verify or the remote SMTP server hostname
+doesn't match, and no other server is available, the delivery
+attempt is deferred and the mail stays in the queue. The remote SMTP server hostname used in the check is beyond
+question, as it must be the principal hostname (no CNAME allowed
+here). Checks are performed against all names provided as dNSNames
+in the SubjectAlternativeName. If no dNSNames are specified, the
+CommonName is checked. The behavior may be changed with the
+smtp_tls_enforce_peername option which is discussed below. This option is useful only if you know that you will only
+connect to servers that support RFC 2487 _and_ that present server
+certificates that meet the above requirements. An example would
+be a client only sends email to one specific mailhub that offers
+the necessary STARTTLS support. Example: As of RFC 2487 the requirements for hostname checking for MTA
+clients are not set. When TLS is required (smtp_enforce_tls = yes),
+the option smtp_tls_enforce_peername can be set to "no" to disable
+strict remote SMTP server hostname checking. In this case, the mail
+delivery will proceed regardless of the CommonName etc. listed in
+the certificate. Note: the smtp_tls_enforce_peername setting has no effect on
+sessions that are controlled via the smtp_tls_per_site table. Disabling the remote SMTP server hostname verification can
+make sense in closed environment where special CAs are created.
+If not used carefully, this option opens the danger of a
+"man-in-the-middle" attack (the CommonName of this possible attacker
+is logged). Example: Generally, trying TLS can be a bad idea, as some servers offer
+STARTTLS but the negotiation will fail leading to unexplainable
+failures. Instead, it may be a good idea to choose the TLS usage
+policy based on the recipient or the mailhub to which you are
+connecting. Deciding the TLS usage policy per recipient may be difficult,
+since a single email delivery attempt can involve several recipients.
+Instead, use of TLS is controlled by the Postfix next-hop destination
+domain name and by the remote SMTP server hostname. If either of these
+matches an entry in the smtp_tls_per_site table, appropriate action
+is taken. The remote SMTP server hostname is simply the DNS name of the
+server that the Postfix SMTP client connects to. The next-hop
+destination is Postfix specific. By default, this is the domain
+name in the recipient address, but this information can be overruled
+by the transport(5) table or by the relayhost parameter setting.
+In these cases the relayhost etc. must be listed in the smtp_tls_per_site
+table, instead of the recipient domain name. Format of the table: domain or host names are specified on the
+left-hand side; no wildcards are allowed. On the right hand side
+specify one of the following keywords: The actual TLS usage policy depends not only on whether the
+next-hop destination or remote SMTP server hostname are found in
+the smtp_tls_per_site table, but also on the smtp_enforce_tls
+setting: If no match was found, the policy is applied as specified
+with smtp_enforce_tls. If a match was found, and the smtp_enforce_tls policy is
+"enforce", NONE explicitly switches it off; otherwise the "enforce"
+mode is used even for entries that specify MAY. Special hint for TLS enforcement mode: since no secure DNS
+lookup mechanism is available, mail can be delivered to the wrong
+remote SMTP server. This is not prevented by specifying MUST for
+the next-hop domain name. The recommended setup is: specify local
+transport(5) table entries for sensitive domains with explicit
+smtp:[mailhost] destinations (since you can assure security of this
+table unlike DNS), then specify MUST for these mail hosts in the
+smtp_tls_per_site table. Example: As we decide on a "per site" basis whether or not to use TLS,
+it would be good to have a list of sites that offered "STARTTLS".
+We can collect it ourselves with this option. If the smtp_tls_note_starttls_offer feature is enabled and a
+server offers STARTTLS while TLS is not already enabled for that
+server, the Postfix SMTP client logs a line as follows: Example: When verifying a remote SMTP server certificate, a verification
+depth of 1 is sufficient if the certificate is directly issued by
+a CA specified with smtp_tls_CAfile or smtp_tls_CApath. The default
+value of 5 should also suffice for longer chains (root CA issues
+special CA which then issues the actual certificate...) Example: To influence the Postfix SMTP client cipher selection scheme,
+you can give cipherlist string. A detailed description would go
+to far here; please refer to the OpenSSL documentation. If you
+don't know what to do with it, simply don't touch it and leave the
+(openssl-)compiled in default! DO NOT USE " to enclose the string, specify just the string!!! Example: The smtp_starttls_timeout parameter limits the time of Postfix
+SMTP client write and read operations during TLS startup and shutdown
+handshake procedures. In case of problems the Postfix SMTP client
+tries the next network address on the mail exchanger list, and
+defers delivery if no alternative server is available. Example: The security of cryptographic software such as TLS depends
+critically on the ability to generate unpredictable numbers for
+keys and other information. To this end, the tlsmgr(8) process
+maintains a Pseudo Random Number Generator (PRNG) pool. This is
+queried by the smtp(8) and smtpd(8) processes when they initialize.
+By default, these daemons request 32 bytes, the equivalent to 256
+bits. This is more than sufficient to generate a 128bit (or 168bit)
+session key. Example: In order to feed its in-memory PRNG pool, the tlsmgr(8) reads
+entropy from an external source, both at startup and during run-time.
+Specify a good entropy source, like EGD or /dev/urandom; be sure
+to only use non-blocking sources. If the entropy source is not a
+regular file, you must prepend the source type to the source name:
+"dev:" for a device special file, or "egd:" for a source with EGD
+compatible socket interface. Examples (specify only one in main.cf): By default, tlsmgr(8) reads 32 bytes from the external entropy
+source at each seeding event. This amount (256bits) is more than
+sufficient for generating a 128bit symmetric key. With EGD and
+device entropy sources, the tlsmgr(8) limits the amount of data
+read at each step to 255 bytes. If you specify a regular file as
+entropy source, a larger amount of data can be read. Example: In order to update its in-memory PRNG pool, the tlsmgr(8)
+queries the external entropy source again after a pseudo-random
+amount of time. The time is calculated using the PRNG, and is
+between 0 and the maximal time specified with tls_random_reseed_period.
+The default maximal time interval is 1 hour. Example: The tlsmgr(8) process saves the PRNG state to a persistent
+exchange file at regular times and when the process terminates, so
+that it can recover the PRNG state the next time it starts up.
+This file is created when it does not exist. Its default location
+is under the Postfix configuration directory, which is not the
+proper place for information that is modified by Postfix. Instead,
+the file location should probably be on the /var partition (but
+not inside the chroot jail). Examples: The following steps will get you started quickly. Because you
+sign your own Postfix public key certificate, you get TLS encryption
+but no TLS authentication. This is sufficient for testing, and
+for exchanging email with sites that you have no trust relationship
+with. For real authentication, your Postfix public key certificate
+needs to be signed by a recognized Certificate Authority, and
+Postfix needs to be configured with a list of public key certificates
+of Certificate Authorities, so that Postfix can verify the public key
+certificates of remote hosts. In the examples below, user input is shown in bold
+font, and a "#" prompt indicates a super-user shell. Become your own Certificate Authority, so that you can
+sign your own public keys. This example uses the CA.pl script that
+ships with OpenSSL. By default, OpenSSL installs this as
+/usr/local/ssl/misc/CA.pl, but your mileage may vary.
+The script creates a private key in ./demoCA/private/cakey.pem
+and a public key in ./demoCA/cacert.pem. Create an unpassworded private key for host FOO and create
+an unsigned public key certificate. Sign the public key certificate for host FOO with the
+Certification Authority private key that we created a few
+steps ago. Install the host private key, the host public key certificate,
+and the Certification Authority certificate files. This requires
+super-user privileges. Configure Postfix, by adding the following to
+/etc/postfix/main.cf. When reporting a problem, please be thorough in the report.
+Patches, when possible, are greatly appreciated too. Please differentiate when possible between: Postfix version 2.2 TLS support is based on the Postfix/TLS
+patch by Lutz Jänicke, but differs in a few minor ways. main.cf: Use btree instead of sdbm for TLS
+session cache databases. TLS session cache databases are now accessed only by the
+tlsmgr(8) process, so there are no more concurrency issues. Although
+Postfix has an sdbm client, the sdbm library (1000
+lines of code) is not included with Postfix. TLS session caches can use any database that can store objects
+of several kbytes or more, and that implements the sequence operation.
+In most cases, btree databases should be adequate. NOTE: You cannot use dbm databases. TLS session objects
+are too large. master.cf: Specify unix instead of fifo as
+the tlsmgr service type. The smtp(8) and smtpd(8) processes now use a client-server
+protocol in order to access the tlsmgr(8) pseudo-random number
+generation (PRNG) pool, and in order to access the TLS session
+cache databases. Such a protocol cannot be run across fifos. When inet_interfaces specifies just one IPv4 and/or IPv6 address
that is not a loopback address, the Postfix SMTP client will use
-this address as the IP source address for outbound mail. Availability
+ SASL authentication SASL_README
Postfix 1.0
+
- STARTTLS session encryption TLS_README
+Postfix 2.2 4.4 - Overriding built-in parameter default settings
diff --git a/postfix/html/Makefile.in b/postfix/html/Makefile.in
index 514370806..e573cb5a4 100644
--- a/postfix/html/Makefile.in
+++ b/postfix/html/Makefile.in
@@ -7,7 +7,7 @@ DAEMONS = bounce.8.html cleanup.8.html defer.8.html error.8.html local.8.html \
showq.8.html smtp.8.html smtpd.8.html trivial-rewrite.8.html \
oqmgr.8.html spawn.8.html flush.8.html virtual.8.html qmqpd.8.html \
trace.8.html verify.8.html proxymap.8.html anvil.8.html \
- scache.8.html discard.8.html
+ scache.8.html discard.8.html tlsmgr.8.html
COMMANDS= mailq.1.html newaliases.1.html postalias.1.html postcat.1.html \
postconf.1.html postfix.1.html postkick.1.html postlock.1.html \
postlog.1.html postdrop.1.html postmap.1.html sendmail.1.html \
@@ -127,6 +127,10 @@ virtual.8.html: ../src/virtual/virtual.c
PATH=../mantools:$$PATH; \
srctoman $? | $(AWK) | nroff -man | uniq | $(MAN2HTML) | postlink >$@
+tlsmgr.8.html: ../src/tlsmgr/tlsmgr.c
+ PATH=../mantools:$$PATH; \
+ srctoman $? | $(AWK) | nroff -man | uniq | $(MAN2HTML) | postlink >$@
+
trace.8.html: bounce.8.html
rm -f $@
ln -s $? $@
diff --git a/postfix/html/TLS_README.html b/postfix/html/TLS_README.html
new file mode 100644
index 000000000..6826d9f67
--- /dev/null
+++ b/postfix/html/TLS_README.html
@@ -0,0 +1,1389 @@
+
+
+
+
+
+
+
+
+
Postfix TLS Support
+
+
+ WARNING
+
+ Purpose of this document
+
+
+
+
+
+Building Postfix with TLS support
+
+
+
+
+
+
+
+
+
+% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_TLS" AUXLIBS="-lssl -lcrypto"
+
+
+
+
+
+% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_TLS -I/usr/local/include" \
+ AUXLIBS="-L/usr/local/lib -lssl -lcrypto"
+
+
+
+
+
+% make tidy # if you have left-over files from a previous build
+% make makefiles CCARGS="-DUSE_TLS \
+ (other -D or -I options)" \
+ AUXLIBS="-lssl -lcrypto \
+ (other -l options for libraries in /usr/lib) \
+ (-L/path/name + -l options for other libraries)"
+
+SMTP Server specific settings
+
+
+
+
+
+Server-side certificate and private
+key configuration
+
+
+
+
+
+% cat server_cert.pem intermediate_CA.pem > server.pem
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_cert_file = /etc/postfix/server.pem
+ smtpd_tls_key_file = $smtpd_tls_cert_file
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem
+ smtpd_tls_dkey_file = $smtpd_tls_dcert_file
+
+
+
+
+
+# $OPENSSL_HOME/bin/c_rehash /path/to/directory
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_CAfile = /etc/postfix/CAcert.pem
+ smtpd_tls_CApath = /etc/postfix/certs
+
+ Server-side TLS activity logging
+
+
+
+
+
+
+
+
+
+
+
+ 0 Disable logging of TLS activity.
+
+ 1 Log TLS handshake and certificate information.
+
+
+ 2 Log levels during TLS negotiation.
+
+
+ 3 Log hexadecimal and ASCII dump of TLS
+negotiation process
+
+ 4 Log hexadecimal and ASCII dump of complete
+transmission after STARTTLS
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_loglevel = 0
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_received_header = yes
+
+Enabling TLS in the Postfix SMTP server
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_use_tls = yes
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_enforce_tls = yes
+
+
+
+
+
+/etc/postfix/master.cf:
+ smtps inet n - n - - smtpd
+ -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
+
+Client certificate verification
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_ask_ccert = no
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_req_ccert = no
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_ccert_verifydepth = 5
+
+Supporting AUTH over TLS only
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_auth_only = no
+
+Server-side TLS session cache
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_scache
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_session_cache_timeout = 3600s
+
+Server access control
+
+
+
+
+
+
+
+
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_recipient_restrictions =
+ ...
+ permit_tls_clientcerts
+ reject_unauth_destination
+ ...
+
+
+
+
+
+/etc/postfix/main.cf:
+ relay_clientcerts = hash:/etc/postfix/relay_clientcerts
+
+/etc/postfix/relay_clientcerts:
+ D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80 lutzpc.at.home
+
+Server-side cipher controls
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_cipherlist = DEFAULT
+
+
+
+
+
+% openssl gendh -out /etc/postfix/dh_1024.pem -2 -rand /var/run/egd-pool 1024
+% openssl gendh -out /etc/postfix/dh_512.pem -2 -rand /var/run/egd-pool 512
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
+ smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
+
+ Miscellaneous server controls
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtpd_starttls_timeout = 300s
+
+ SMTP Client specific settings
+
+
+
+
+
+Client-side certificate and private
+key configuration
+
+
+
+
+
+% cat client_cert.pem intermediate_CA.pem > client.pem
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_cert_file = /etc/postfix/client.pem
+ smtp_tls_key_file = $smtp_tls_cert_file
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_dcert_file = /etc/postfix/client-dsa.pem
+ smtp_tls_dkey_file = $smtpd_tls_cert_file
+
+
+
+
+
+# $OPENSSL_HOME/bin/c_rehash /path/to/directory
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_CAfile = /etc/postfix/CAcert.pem
+ smtp_tls_CApath = /etc/postfix/certs
+
+ Client-side TLS activity logging
+
+
+
+
+
+
+
+
+
+
+
+ 0 Disable logging of TLS activity.
+
+ 1 Log TLS handshake and certificate information.
+
+
+ 2 Log levels during TLS negotiation.
+
+
+ 3 Log hexadecimal and ASCII dump of TLS
+negotiation process
+
+ 4 Log hexadecimal and ASCII dump of complete
+transmission after STARTTLS
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_loglevel = 0
+
+Client-side TLS session cache
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_session_cache_timeout = 3600s
+
+ Enabling TLS in the Postfix SMTP client
+
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_use_tls = yes
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_enforce_tls = no
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_enforce_peername = yes
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_per_site = hash:/etc/postfix/tls_per_site
+
+
+
+
+
+postfix/smtp[pid]: Host offered STARTTLS: [hostname.example.com]
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_note_starttls_offer = yes
+
+Server certificate verification
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_scert_verifydepth = 5
+
+ Client-side cipher controls
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_tls_cipherlist = DEFAULT
+
+ Miscellaneous client controls
+
+
+
+
+
+/etc/postfix/main.cf:
+ smtp_starttls_timeout = 300s
+
+ TLS manager specific settings
+
+
+
+
+
+/etc/postfix/main.cf:
+ tls_daemon_random_bytes = 32
+
+
+
+
+
+/etc/postfix/main.cf:
+ tls_random_source = dev:/dev/urandom
+ tls_random_source = egd:/var/run/egd-pool
+
+
+
+
+
+/etc/postfix/main.cf:
+ tls_random_bytes = 32
+
+
+
+
+
+/etc/postfix/main.cf:
+ tls_random_reseed_period = 3600s
+
+
+
+
+
+/etc/postfix/main.cf:
+ tls_random_exchange_name = /etc/postfix/prng_exch
+ tls_random_prng_update_period = 3600s
+
+Getting started, quick and dirty
+
+
+
+
+
+
+
+
+
+
+% /usr/local/ssl/misc/CA.pl -newca
+CA certificate filename (or enter to create)
+
+Making CA certificate ...
+Using configuration from /etc/ssl/openssl.cnf
+Generating a 1024 bit RSA private key
+....................++++++
+.....++++++
+writing new private key to './demoCA/private/cakey.pem'
+Enter PEM pass phrase:whatever
+
+
+
+
+
+% openssl req -new -nodes -keyout FOO-key.pem -out FOO-req.pem -days 365
+Using configuration from /etc/ssl/openssl.cnf
+Generating a 1024 bit RSA private key
+........................................++++++
+....++++++
+writing new private key to 'FOO-key.pem'
+-----
+You are about to be asked to enter information that will be incorporated
+into your certificate request.
+What you are about to enter is what is called a Distinguished Name or a DN.
+There are quite a few fields but you can leave some blank
+For some fields there will be a default value,
+If you enter '.', the field will be left blank.
+-----
+Country Name (2 letter code) [AU]:US
+State or Province Name (full name) [Some-State]:New York
+Locality Name (eg, city) []:Westchester
+Organization Name (eg, company) [Internet Widgits Pty Ltd]:Porcupine
+Organizational Unit Name (eg, section) []:
+Common Name (eg, YOUR name) []:FOO
+Email Address []:wietse@porcupine.org
+
+Please enter the following 'extra' attributes
+to be sent with your certificate request
+A challenge password []:whatever
+An optional company name []:
+
+
+
+
+
+% openssl ca -out FOO-cert.pem -infiles FOO-req.pem
+Uing configuration from /etc/ssl/openssl.cnf
+Enter PEM pass phrase:whatever
+Check that the request matches the signature
+Signature ok
+The Subjects Distinguished Name is as follows
+countryName :PRINTABLE:'US'
+stateOrProvinceName :PRINTABLE:'New York'
+localityName :PRINTABLE:'Westchester'
+organizationName :PRINTABLE:'Porcupine'
+commonName :PRINTABLE:'FOO'
+emailAddress :IA5STRING:'wietse@porcupine.org'
+Certificate is to be certified until Nov 21 19:40:56 2005 GMT (365 days)
+Sign the certificate? [y/n]:y
+
+
+1 out of 1 certificate requests certified, commit? [y/n]y
+Write out database with 1 new entries
+Data Base Updated
+
+
+
+
+
+# cp demoCA/cacert.pem FOO-key.pem FOO-cert.pem /etc/postfix
+# chmod 644 /etc/postfix/FOO-cert.pem /etc/postfix/cacert.pem
+# chmod 400 /etc/postfix/FOO-key.pem
+
+
+
+
+
+smtp_tls_CAfile = /etc/postfix/cacert.pem
+smtp_tls_cert_file = /etc/postfix/FOO-cert.pem
+smtp_tls_key_file = /etc/postfix/FOO-key.pem
+smtp_tls_session_cache_database = btree:/var/run/smtp_tls_session_cache
+smtp_use_tls = yes
+smtpd_tls_CAfile = /etc/postfix/cacert.pem
+smtpd_tls_cert_file = /etc/postfix/FOO-cert.pem
+smtpd_tls_key_file = /etc/postfix/FOO-key.pem
+smtpd_tls_received_header = yes
+smtpd_tls_session_cache_database = btree:/var/run/smtpd_tls_session_cache
+smtpd_use_tls = yes
+tls_random_source = dev:/dev/urandom
+
+ Reporting problems
+
+
+
+
+
+Compatibility with Postfix <2.2 TLS support
+
+
+
+
+
+Credits
+
+
+
+
+
+
+
+
diff --git a/postfix/html/index.html b/postfix/html/index.html
index 520e3bed6..56a61526a 100644
--- a/postfix/html/index.html
+++ b/postfix/html/index.html
@@ -38,6 +38,8 @@ configuration examples
On a multi-homed firewall with separate Postfix instances listening on the @@ -2590,6 +2591,8 @@ or accepting connections. Specify one or more of "ipv4" or "ipv6", separated by whitespace or commas. The form "all" is equivalent to "ipv4, ipv6".
+This feature is available in Postfix version 2.2 and later.
+Note: you MUST stop and start Postfix after changing this parameter.
@@ -2613,8 +2616,6 @@ Postfix will do DNS type AAAA record lookups. client will attempt to connect via IPv6 before attempting to use IPv4. -This feature is available in Postfix version 2.2 and later.
-Examples:
@@ -3172,8 +3173,8 @@ protocol. This is enabled by default.The list of remote SMTP client certificates for which the +Postfix SMTP server will allow access with the permit_tls_clientcerts +feature. This feature does not use certificate names, because +Postfix list manipulation routines treat whitespace and some other +characters as special. Instead we use certificate fingerprints as +they are difficult to fake but easy to use for lookup.
+ +Postfix lookup tables are in the form of (key, value) pairs. +Since we only need the key, the value can be chosen freely, e.g. +the name of the user or host: +D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80 lutzpc.at.home
+ +Example:
+ ++relay_clientcerts = hash:/etc/postfix/relay_clientcerts ++ +
This feature is available in Postfix version 2.2 and later.
+This can be specified in the main.cf file for all SMTP clients, or it can be specified in the master.cf file for a specific client, @@ -5583,8 +5610,6 @@ IP hosting, but can be a problem on multi-homed firewalls. See the
Note 2: address information may be enclosed inside [], but this form is not recommended.
-This feature is available in Postfix version 2.2 and later.
- @@ -5813,6 +5838,30 @@ from a remote SMTP server. Use the smtp_enforce_tls +(default: no)Enforcement mode: require that remote SMTP servers use TLS +encryption, and never send mail in the clear. This also requires +that the remote SMTP server hostname matches the information in +the remote server certificate, and that the remote SMTP server +certificate was issued by a CA that is trusted by the Postfix SMTP +client. If the certificate doesn't verify or the hostname doesn't +match, delivery is deferred and mail stays in the queue.
+ +The server hostname is matched against all names provided as +dNSNames in the SubjectAlternativeName. If no dNSNames are specified, +the CommonName is checked. The behavior may be changed with the +smtp_tls_enforce_peername option.
+ +This option is useful only if you are definitely sure that you +will only connect to servers that support RFC 2487 _and_ that +provide valid server certificates. Typical use is for clients that +send all their email to a dedicated mailhub.
+ +The SASL authentication security options that the Postfix SMTP +client uses for TLS encrypted SMTP sessions.
+ +Time limit for Postfix SMTP client write and read operations +during TLS startup and shutdown handshake procedures.
+ + +The file with the certificate of the certification authority +(CA) that issued the Postfix SMTP client certificate. This is +needed only when the CA certificate is not already present in the +client certificate file.
+ +Example:
+ ++smtp_tls_CAfile = /etc/postfix/CAcert.pem ++ + +
Directory with PEM format certificate authority certificates +that the Postfix SMTP client uses to verify a remote SMTP server +certificate. Don't forget to create the necessary "hash" links +with, for example, "$OPENSSL_HOME/bin/c_rehash /etc/postfix/certs". +
+ +To use this option in chroot mode, this directory (or a copy) +must be inside the chroot jail.
+ +Example:
+ ++smtp_tls_CApath = /etc/postfix/certs ++ + +
File with the Postfix SMTP client RSA certificate in PEM format. +This file may also contain the client private key, and these may +be the same as the server certificate and key file.
+ +In order to verify certificates, the CA certificate (in case +of a certificate chain, all CA certificates) must be available. +You should add these certificates to the server certificate, the +server certificate first, then the issuing CA(s).
+ +Example: the certificate for "client.dom.ain" was issued by +"intermediate CA" which itself has a certificate of "root CA". +Create the client.pem file with "cat client_cert.pem intermediate_CA.pem +root_CA.pem > client.pem".
+ +If you want to accept remote SMTP server certificates issued +by these CAs yourself, you can also add the CA certificates to the +smtp_tls_CAfile, in which case it is not necessary to have them in +the smtp_tls_cert_file or smtp_tls_dcert_file.
+ +A certificate supplied here must be usable as SSL client certificate and +hence pass the "openssl verify -purpose sslclient ..." test.
+ +Example:
+ ++smtp_tls_cert_file = /etc/postfix/client.pem ++ + +
Controls the Postfix SMTP client TLS cipher selection scheme. +For details, see the OpenSSL documentation. Note: do not use "" +quotes around the parameter value.
+ + +File with the Postfix SMTP client DSA certificate in PEM format. +This file may also contain the server private key.
+ +See the discussion under smtp_tls_cert_file for more details. +
+ +Example:
+ ++smtp_tls_dcert_file = /etc/postfix/client-dsa.pem ++ + +
File with the Postfix SMTP client DSA private key in PEM format. +The private key must not be encrypted. In other words, the key must +be accessible without password.
+ +This file may be combined with the server certificate file +specified with $smtp_tls_cert_file.
+ + +When TLS encryption is enforced, require that the remote SMTP +server hostname matches the information in the remote SMTP server +certificate. As of RFC 2487 the requirements for hostname checking +for MTA clients are not specified.
+ +This option can be set to "no" to disable strict peer name +checking. This setting has no effect on sessions that are controlled +via the smtp_tls_per_site table.
+ +Disabling the hostname verification can make sense in closed +environment where special CAs are created. If not used carefully, +this option opens the danger of a "man-in-the-middle" attack (the +CommonName of this attacker will be logged).
+ + +File with the Postfix SMTP client RSA private key in PEM format. +This file may be combined with the client certificate file specified +with $smtp_tls_cert_file.
+ +The private key must not be encrypted. In other words, the key +must be accessible without password.
+ +Example:
+ ++smtp_tls_key_file = $smtp_tls_cert_file ++ + +
Enable additional Postfix SMTP client logging of TLS activity. +Each logging level also includes the information that is logged at +a lower logging level.
+ +Use "smtp_tls_loglevel = 3" only in case of problems. Use of +loglevel 4 is strongly discouraged.
+ + +Log the hostname of a remote SMTP server that offers STARTTLS, +when TLS is not already enabled for that server.
+ +The logfile record looks like:
+ ++postfix/smtp[pid]: Host offered STARTTLS: [name.of.host] ++ + +
Optional lookup tables with the Postfix SMTP client TLS usage +policy by next-hop domain name and by remote SMTP server hostname. +
+ +Table format: domain names or server hostnames are specified +on the left-hand side; no wildcards are allowed. On the right hand +side specify one of the following keywords:
+ +Special hint for enforcement mode: since no secure DNS lookup +mechanism is available, the recommended setup is: specify local +transport(5) table entries for sensitive domains with explicit +smtp:[mailhost] destinations (since you can assure security of this +table unlike DNS), then specify MUST for these mail hosts in the +smtp_tls_per_site table.
+ + +The verification depth for remote SMTP server certificates. A +depth of 1 is sufficient, if the certificate is directly issued by +a CA listed in the CA files. The default value (5) should suffice +for longer chains (the root CA issues special CA which then issues +the actual certificate...).
+ + +Name of the file containing the optional Postfix SMTP client +TLS session cache. Specify a database type that supports enumeration, +such as btree or sdbm; there is no need to support +concurrent access. The file is created if it does not exist.
+ +NOTE: dbm databases are not suitable. TLS +session objects are too large.
+ +Example:
+ ++smtp_tls_session_cache_database = btree:/var/postfix/smtp_scache ++ + +
The expiration time of Postfix SMTP client TLS session cache +information. A cache cleanup is performed periodically every +$smtp_tls_session_cache_timeout seconds.
+ + +Opportunistic mode: use TLS when a remote SMTP server announces +STARTTLS support, otherwise send the mail in the clear. Beware: +some SMTP servers offer STARTTLS even if it is not configured. If +the TLS handshake fails, and no other server is available, delivery +is deferred and mail stays in the queue. If this is a concern for +you, use the smtp_tls_per_site feature instead.
+ +See smtpd_data_restrictions for syntax details.
+Enforcement mode: announce STARTTLS support to SMTP clients, +and require that clients use TLS encryption. According to RFC 2487 +this MUST NOT be applied in case of a publicly-referenced SMTP +server. This option is off by default and should be used only on +dedicated servers.
+ +Note 1: this mode implies "smtpd_tls_auth_only = yes".
+ +Note 2: when invoked via "sendmail -bs", Postfix will never offer +STARTTLS due to insufficient privileges to access the server private +key. This is intended behavior.
+ +The SASL authentication security options that the Postfix SMTP +server uses for TLS encrypted SMTP sessions.
+ +The time limit for Postfix SMTP server write and read operations +during TLS startup and shutdown handshake procedures.
+ +The file with the certificate of the certification authority +(CA) that issued the Postfix SMTP server certificate. This is +needed only when the CA certificate is not already present in the +server certificate file. This file may also contain the CA +certificates of other trusted CAs. You must use this file for the +list of trusted CAs if you want to use chroot-mode.
+ +Example:
+ ++smtpd_tls_CAfile = /etc/postfix/CAcert.pem ++ + +
Directory with PEM format certificate authority certificates +that the Postfix SMTP server offers to remote SMTP clients for the +purpose of client certificate verification. Do not forget to create +the necessary "hash" links with, for example, "$OPENSSL_HOME/bin/c_rehash +/etc/postfix/certs".
+ +To use this option in chroot mode, this directory (or a copy) +must be inside the chroot jail. Please note that in this case the +CA certificates are not offered to the client, so that e.g. Netscape +clients might not offer certificates issued by them. Use of this +feature is therefore not recommended.
+ +Example:
+ ++smtpd_tls_CApath = /etc/postfix/certs ++ + +
Ask a remote SMTP client for a client certificate. This +information is needed for certificate based mail relaying with, +for example, the permit_tls_clientcerts feature.
+ +Some clients such as Netscape will either complain if no +certificate is available (for the list of CAs in /etc/postfix/certs) +or will offer multiple client certificates to choose from. This +may be annoying, so this option is "off" by default.
+ + +When TLS encryption is optional in the Postfix SMTP server, do +not announce or accept SASL authentication over unencrypted +connections.
+ + +The verification depth for remote SMTP client certificates. A +depth of 1 is sufficient if the issuing CA is listed in a local CA +file. The default value should also suffice for longer chains (the +root CA issues special CA which then issues the actual certificate...). +
+ + +File with the Postfix SMTP server RSA certificate in PEM format. +This file may also contain the server private key.
+ +Both RSA and DSA certificates are supported. When both types +are present, the cipher used determines which certificate will be +presented to the client. For Netscape and OpenSSL clients without +special cipher choices the RSA certificate is preferred.
+ +In order to verify a certificate, the CA certificate (in case +of a certificate chain, all CA certificates) must be available. +You should add these certificates to the server certificate, the +server certificate first, then the issuing CA(s).
+ +Example: the certificate for "server.dom.ain" was issued by +"intermediate CA" which itself has a certificate of "root CA". +Create the server.pem file with "cat server_cert.pem intermediate_CA.pem +root_CA.pem > server.pem".
+ +If you want to accept certificates issued by these CAs yourself, +you can also add the CA certificates to the smtpd_tls_CAfile, in +which case it is not necessary to have them in the smtpd_tls_dcert_file +or smtpd_tls_cert_file.
+ +A certificate supplied here must be usable as SSL server +certificate and hence pass the "openssl verify -purpose sslserver +..." test.
+ +Example:
+ ++smtpd_tls_cert_file = /etc/postfix/server.pem ++ + +
Controls the Postfix SMTP server TLS cipher selection scheme. +For details, see the OpenSSL documentation. Note: do not use "" +quotes around the parameter value.
+ + +File with the Postfix SMTP server DSA certificate in PEM format. +This file may also contain the server private key.
+ +
See the discussion under smtpd_tls_cert_file for more details. +
+ +Example:
+ ++smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem ++ + +
File with DH parameters that the Postfix SMTP server should +use with EDH ciphers.
+ +Instead of using the exact same parameter sets as distributed +with other TLS packages, it is more secure to generate your own +set of parameters with something like the following command:
+ ++openssl gendh -out /etc/postfix/dh_1024.pem -2 -rand /var/run/egd-pool 1024 ++ +
Your actual source for entropy may differ. Some systems have +/dev/random; on other system you may consider using the "Entropy +Gathering Daemon EGD", available at http://www.lothar.com/tech/crypto/. +
+ +Example:
+ ++smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem ++ + +
File with DH parameters that the Postfix SMTP server should +use with EDH ciphers.
+ +See also the discussion under the smtpd_tls_dh1024_param_file +configuration parameter.
+ +Example:
+ ++smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem ++ + +
File with the Postfix SMTP server DSA private key in PEM format. +This file may be combined with the server certificate file specified +with $smtpd_tls_dcert_file.
+ +The private key must not be encrypted. In other words, the key +must be accessible without password.
+ + +File with the Postfix SMTP server RSA private key in PEM format. +This file may be combined with the server certificate file specified +with $smtpd_tls_cert_file.
+ +The private key must not be encrypted. In other words, the key +must be accessible without password.
+ + +Enable additional Postfix SMTP server logging of TLS activity. +Each logging level also includes the information that is logged at +a lower logging level.
+ +Use "smtpd_tls_loglevel = 3" only in case of problems. Use of +loglevel 4 is strongly discouraged.
+ + +Request that the Postfix SMTP server produces Received: message +headers that include information about the protocol and cipher used, +as well as the client CommonName and client certificate issuer +CommonName. This is disabled by default, as the information may +be modified in transit through other mail servers. Only information +that was recorded by the final destination can be trusted.
+ + +When TLS encryption is enforced, require a remote SMTP client +certificate in order to allow TLS connections to proceed. This +option implies "smtpd_tls_ask_ccert = yes".
+ +When TLS encryption is optional, remote SMTP clients can bypass +the restriction by simply not using STARTTLS at all. For this reason +a TLS connection will be handled as if only "smtpd_tls_ask_ccert += yes" is specified.
+ + +Name of the file containing the optional Postfix SMTP server +TLS session cache. Specify a database type that supports enumeration, +such as btree or sdbm; there is no need to support +concurrent access. The file is created if it does not exist.
+ +NOTE: dbm databases are not suitable. TLS +session objects are too large.
+ +Example:
+ ++smtpd_tls_session_cache_database = btree:/var/postfix/smtpd_scache ++ + +
The expiration time of Postfix SMTP server TLS session cache +information. A cache cleanup is performed periodically every +$smtpd_tls_session_cache_timeout seconds.
+ + +Run the Postfix SMTP server in the non-standard "wrapper" mode, +instead of using the STARTTLS command.
+ +If you want to support this service, enable a special port in +master.cf, and specify "-o smtpd_tls_wrappermode=yes" on the SMTP +server's command line. Port 465 (smtps) was once chosen for this +purpose.
+ + +Opportunistic mode: announce STARTTLS support to SMTP clients, +but do not require that clients use TLS encryption.
+ +Note: when invoked via "sendmail -bs", Postfix will never offer +STARTTLS due to insufficient privileges to access the server private +key. This is intended behavior.
+ +The number of pseudo-random bytes that an smtp(8) or smtpd(8) +process requests from the tlsmgr(8) server in order to seed its +internal pseudo random number generator (PRNG). The default of 32 +bytes (equivalent to 256 bits) is sufficient to generate a 128bit +(or 168bit) session key.
+ + +The number of bytes that tlsmgr(8) reads from $tls_random_source +when (re)seeding the in-memory pseudo random number generator (PRNG) +pool. The default of 32 bytes (256 bits) is good enough for 128bit +symmetric keys. If using EGD or a device file, a maximum of 255 +bytes is read.
+ + +Name of the pseudo random number generator (PRNG) state file +that is maintained by tlsmgr(8). The file is created when it does +not exist, and its length is fixed at 1024 bytes.
+ +Since this file is modified by Postfix, it should probably be +kept in the /var file system, instead of under $config_directory. +The location should not be inside the chroot jail.
+ + +The time between attempts by tlsmgr(8) to save the state of +the pseudo random number generator (PRNG) to the file specified +with $tls_random_exchange_name.
+ + +The maximal time between attempts by tlsmgr(8) to re-seed the +in-memory pseudo random number generator (PRNG) pool from external +sources. The actual time between re-seeding attempts is calculated +using the PRNG, and is between 0 and the time specified.
+ + +The external entropy source for the in-memory tlsmgr(8) pseudo +random number generator (PRNG) pool. Be sure to specify a non-blocking +source. If this source is not a regular file, the entropy source +type must be prepended: egd:/path/to/egd_socket for a source with +EGD compatible socket interface, or dev:/path/to/device for a +device file.
+ +