postfix-3.11-20250825

postfix/.indent.pro

@@ -1,4 +1,4 @@
--TABOUNCE
+-TABOUNCE_STATE
 -TADDR_MATCH_LIST
 -TADDR_PATTERN
 -TALIAS_TOKEN
@@ -34,6 +34,7 @@
 -TBOUNCE_TEMPLATES
 -TBOUNCE_TIME_DIVISOR
 -TBOUNCE_TIME_PARAMETER
+-TBYTE_MASK
 -TCFG_PARSER
 -TCIDR_MATCH
 -TCLEANUP_REGION
@@ -81,11 +82,13 @@
 -TDICT_DEBUG
 -TDICT_ENV
 -TDICT_FAIL
+-TDICT_FINAL_WRAPPER
 -TDICT_HT
 -TDICT_INLINE
 -TDICT_LDAP
 -TDICT_LMDB
 -TDICT_MC
+-TDICT_MONGODB
 -TDICT_MYSQL
 -TDICT_NI
 -TDICT_NIS
@@ -119,6 +122,7 @@
 -TDICT_SOCKMAP
 -TDICT_SOCKMAP_REFC_HANDLE
 -TDICT_SQLITE
+-TDICT_STATIC
 -TDICT_SURROGATE
 -TDICT_TCP
 -TDICT_TEXT
@@ -126,6 +130,7 @@
 -TDICT_UNION
 -TDICT_UNIX
 -TDICT_UTF8_BACKUP
+-TDICT_WRAPPER
 -TDNS_FIXED
 -TDNS_REPLY
 -TDNS_RR
@@ -140,6 +145,10 @@
 -TEC_KEY
 -TEDIT_FILE
 -TEVENT_MASK
+-TEVP_CIPHER_CTX
+-TEVP_MAC_CTX
+-TEVP_MD
+-TEVP_MD_CTX
 -TEVP_PKEY
 -TEXPAND_ATTR
 -TFILE
@@ -152,10 +161,12 @@
 -THBC_TEST_CONTEXT
 -THEADER_OPTS
 -THEADER_TOKEN
+-THMAC_CTX
 -THOST
 -THTABLE
 -THTABLE_INFO
 -TINET_ADDR_LIST
+-TINET_ADDR_SIZES
 -TINET_PROTO_INFO
 -TINSTANCE
 -TINST_SELECTION
@@ -165,6 +176,7 @@
 -TJMP_BUF_WRAPPER
 -TLDAP
 -TLDAPMessage
+-TLDAPURLDesc
 -TLDAP_CONN
 -TLIB_DP
 -TLIB_FN
@@ -174,11 +186,14 @@
 -TLMTP_STATE
 -TLOCAL_EXP
 -TLOCAL_STATE
+-TLOGIN_SENDER_MATCH
+-TLOGWRITER
 -TLONG_NAME_MASK
 -TMAC_EXP_CONTEXT
 -TMAC_EXP_OP_INFO
 -TMAC_HEAD
 -TMAC_PARSE
+-TMAIL_ADDR_FORMATTER
 -TMAIL_ADDR_MAP_TEST
 -TMAIL_PRINT
 -TMAIL_SCAN
@@ -189,6 +204,7 @@
 -TMAI_SERVNAME_STR
 -TMAI_SERVPORT_STR
 -TMAPS
+-TMAP_SEARCH
 -TMASTER_INT_WATCH
 -TMASTER_PROC
 -TMASTER_SERV
@@ -230,8 +246,11 @@
 -TNAME_CODE
 -TNAME_MASK
 -TNBBIO
+-TNVTABLE_INFO
 -TOPTIONS
+-TOSSL_DGST
 -TPCF_DBMS_INFO
+-TPCF_DEPR_PARAM_INFO
 -TPCF_EVAL_CTX
 -TPCF_MASTER_EDIT_REQ
 -TPCF_MASTER_ENT
@@ -242,6 +261,10 @@
 -TPCF_SERVICE_DEF
 -TPCF_SERVICE_PATTERN
 -TPCF_STRING_NV
+-TPEER_FROM_HAPROXY_CASE
+-TPEER_FROM_NON_SOCKET_CASE
+-TPEER_FROM_PASS_ATTR_CASE
+-TPEER_FROM_UNCONN_SOCKET_CASE
 -TPEER_NAME
 -TPGSQL_NAME
 -TPICKUP_INFO
@@ -284,6 +307,7 @@
 -TRESPONSE
 -TREST_TABLE
 -TRES_CONTEXT
+-TRING
 -TRWR_CONTEXT
 -TSCACHE
 -TSCACHE_CLNT
@@ -298,6 +322,8 @@
 -TSCAN_DIR
 -TSCAN_INFO
 -TSCAN_OBJ
+-TSENDER_LOGIN_MATCH
+-TSERVER_AC
 -TSESSION
 -TSHARED_PATH
 -TSINGLE_SERVER
@@ -317,6 +343,7 @@
 -TSMTPD_TOKEN
 -TSMTPD_XFORWARD_ATTR
 -TSMTP_ADDR
+-TSMTP_CLI_ATTR
 -TSMTP_CMD
 -TSMTP_ITERATOR
 -TSMTP_RESP
@@ -336,16 +363,21 @@
 -TSTRING_LIST
 -TSTRING_TABLE
 -TSYS_EXITS_DETAIL
+-TTEST_BASE
+-TTEST_CASE
 -TTLSMGR_SCACHE
 -TTLSP_STATE
+-TTLSRPT_WRAPPER
 -TTLS_APPL_STATE
 -TTLS_CERTS
 -TTLS_CLIENT_INIT_PROPS
+-TTLS_CLIENT_PARAMS
 -TTLS_CLIENT_START_PROPS
 -TTLS_DANE
 -TTLS_PKEYS
 -TTLS_PRNG_SEED_INFO
 -TTLS_PRNG_SRC
+-TTLS_ROLE
 -TTLS_SCACHE
 -TTLS_SCACHE_ENTRY
 -TTLS_SERVER_INIT_PROPS
@@ -353,6 +385,7 @@
 -TTLS_SESS_STATE
 -TTLS_TICKET_KEY
 -TTLS_TLSA
+-TTLS_USAGE
 -TTLS_VINFO
 -TTLScontext_t
 -TTOK822
@@ -388,13 +421,17 @@
 -TXSASL_SERVER_IMPL
 -TXSASL_SERVER_IMPL_INFO
 -Tbind_props
+-Tbson_iter_t
 -Tcipher_probe_t
 -Td2i_X509_t
 -Tdane_digest
+-Tdane_mtype
+-Tdict_lookup_verify_data
 -Tfilter_ctx
 -Tgeneral_name_stack_t
 -Tiana_digest
 -Toff_t
+-Tpem_load_state_t
 -Tregex_t
 -Tregmatch_t
 -Tsasl_conn_t
@@ -403,9 +440,13 @@
 -Tsigset_t
 -Tsize_t
 -Tsockaddr
+-Tsockaddr_storage
 -Tssize_t
 -Tssl_cipher_stack_t
 -Tssl_comp_stack_t
 -Ttime_t
 -Ttlsa_filter
+-Tuint16_t
+-Tuint32_t
+-Tuint8_t
 -Tx509_stack_t

postfix/AAAREADME

@@ -42,13 +42,13 @@ On-line resources devoted to the Postfix mail system
 
 Web sites:
 
-    http://www.postfix.org/		current release information
+    https://www.postfix.org/		current release information
 
 Mail addresses (PLEASE send questions to the mailing list)
 
     postfix-users@postfix.org		Postfix users mailing list
 
-In order to subscribe to the mailing list, see http://www.postfix.org/.
+In order to subscribe to the mailing list, see https://www.postfix.org/.
 
 Acknowledgments
 ===============
@@ -89,7 +89,7 @@ The HISTORY file gives a detailed log of changes to the software.
 
 Point your browser at html/index.html for Postfix documentation
 and for hyperlinked versions of Postfix manual pages.  Expect
-to see updated versions on-line at http://www.postfix.org/
+to see updated versions on-line at https://www.postfix.org/
 
 Point your MANPATH environment variable at the `man' directory (use
 an absolute path) for UNIX-style on-line manual pages.  These pages
@@ -149,6 +149,7 @@ Postfix daemons:
     src/oqmgr/		Old queue manager
     src/pickup/		Local pickup
     src/pipe/		Pipe delivery
+    src/postlogd/	Syslog alternative, logs to file or stdout
     src/postscreen/	Zombie blocker
     src/proxymap/	Table lookup proxy agent
     src/qmgr/		Queue manager
@@ -159,7 +160,7 @@ Postfix daemons:
     src/smtpd/		SMTP server
     src/spawn/		Run non-Postfix server
     src/tlsmgr/		TLS session keys and random pool
-    src/tlsproxy/	TLS proxy for postscreen
+    src/tlsproxy/	TLS proxy for postscreen and outbound connection reuse
     src/trivial-rewrite/ Address rewriting and resolving
     src/verify/		address verification service
     src/virtual/	virtual mailbox-only delivery agent

postfix/INSTALL

@@ -331,7 +331,7 @@ install" or "make upgrade".
     # make upgrade meta_directory=/usr/libexec/postfix ...
     # make install meta_directory=/usr/libexec/postfix ...
 
-As with the command "make makefiles, the command "make install/upgrade
+As with the command "make makefiles", the command "make install/upgrade
 name=value..." will replace the string MAIL_VERSION at the end of a
 configuration parameter value with the Postfix release version. Do not try to
 specify something like $mail_version on this command line. This produces
@@ -376,27 +376,29 @@ whistles. Support for third-party databases etc. must be configured when
 Postfix is compiled. The following documents describe how to build Postfix with
 support for optional features:
 
-     _____________________________________________________________
-    |Optional feature		       |Document     |Availability|
-    |__________________________________|_____________|____________|
-    |Berkeley DB database	       |DB_README    |Postfix 1.0 |
-    |__________________________________|_____________|____________|
-    |LMDB database		       |LMDB_README  |Postfix 2.11|
-    |__________________________________|_____________|____________|
-    |LDAP database		       |LDAP_README  |Postfix 1.0 |
-    |__________________________________|_____________|____________|
-    |MySQL database		       |MYSQL_README |Postfix 1.0 |
-    |__________________________________|_____________|____________|
-    |Perl compatible regular expression|PCRE_README  |Postfix 1.0 |
-    |__________________________________|_____________|____________|
-    |PostgreSQL database	       |PGSQL_README |Postfix 2.0 |
-    |__________________________________|_____________|____________|
-    |SASL authentication	       |SASL_README  |Postfix 1.0 |
-    |__________________________________|_____________|____________|
-    |SQLite database		       |SQLITE_README|Postfix 2.8 |
-    |__________________________________|_____________|____________|
-    |STARTTLS session encryption       |TLS_README   |Postfix 2.2 |
-    |__________________________________|_____________|____________|
+     ______________________________________________________________
+    |Optional feature		       |Document      |Availability|
+    |__________________________________|______________|____________|
+    |Berkeley DB database	       |DB_README     |Postfix 1.0 |
+    |__________________________________|______________|____________|
+    |LMDB database		       |LMDB_README   |Postfix 2.11|
+    |__________________________________|______________|____________|
+    |LDAP database		       |LDAP_README   |Postfix 1.0 |
+    |__________________________________|______________|____________|
+    |MongoDB database		       |MONGODB_README|Postfix 3.9 |
+    |__________________________________|______________|____________|
+    |MySQL database		       |MYSQL_README  |Postfix 1.0 |
+    |__________________________________|______________|____________|
+    |Perl compatible regular expression|PCRE_README   |Postfix 1.0 |
+    |__________________________________|______________|____________|
+    |PostgreSQL database	       |PGSQL_README  |Postfix 2.0 |
+    |__________________________________|______________|____________|
+    |SASL authentication	       |SASL_README   |Postfix 1.0 |
+    |__________________________________|______________|____________|
+    |SQLite database		       |SQLITE_README |Postfix 2.8 |
+    |__________________________________|______________|____________|
+    |STARTTLS session encryption       |TLS_README    |Postfix 2.2 |
+    |__________________________________|______________|____________|
 
 Note: IP version 6 support is compiled into Postfix on operating systems that
 have IPv6 support. See the IPV6_README file for details.
@@ -466,7 +468,7 @@ configuration file, except for one: the parameter that specifies the location
 of Postfix configuration files. In order to build Postfix with a configuration
 directory other than /etc/postfix, use:
 
-    $ make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/some/where\"'
+    $ make makefiles CCARGS="-DDEF_CONFIG_DIR=\\\"/some/where\\\""
     $ make
 
 IMPORTANT: Be sure to get the quotes right. These details matter a lot.
@@ -567,7 +569,7 @@ The following is an extensive list of names and values.
 ||				|Do not build with IPv6 support. By default,  |
 ||				|IPv6 support is compiled in on platforms that|
 ||				|are known to have IPv6 support. Note: this   |
-||-DNO_IPV6			|directive is for debugging And testing only. |
+||-DNO_IPV6			|directive is for debugging and testing only. |
 ||				|It is not guaranteed to work on all	      |
 ||				|platforms. If you don't want IPv6 support,   |
 ||				|set "inet_protocols = ipv4" in main.cf.      |
@@ -593,6 +595,9 @@ The following is an extensive list of names and values.
 ||-DNO_POSIX_GETPW_R		|getpwuid_r. By default Postfix uses these    |
 ||				|where they are known to be available.	      |
 ||______________________________|_____________________________________________|
+||-DNO_RES_NCALLS		|Do not build with the threadsafe resolver(5) |
+||				|API (res_ninit() etc.).		      |
+||______________________________|_____________________________________________|
 ||				|Use setjmp()/longjmp() instead of sigsetjmp  |
 ||-DNO_SIGSETJMP		|()/siglongjmp(). By default, Postfix uses    |
 ||				|sigsetjmp()/siglongjmp() when they are known |
@@ -676,7 +681,7 @@ is successful, then you can proceed to install Postfix (section 6).
 If the command produces compiler error messages, it may be time to search the
 web or to ask the postfix-users@postfix.org mailing list, but be sure to search
 the mailing list archives first. Some mailing list archives are linked from
-http://www.postfix.org/.
+https://www.postfix.org/.
 
 5 - Porting Postfix to an unsupported system
 
@@ -826,7 +831,7 @@ and watch your maillog file for any error messages. The pathname is /var/log/
 maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
 pathname is defined in the /etc/syslog.conf file.
 
-    $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+    $ grep -E '(reject|warning|error|fatal|panic):' /some/log/file
 
 Note: the most important error message is logged first. Later messages are not
 as useful.
@@ -876,7 +881,7 @@ and watch your maillog file for any error messages. The pathname is /var/log/
 maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
 pathname is defined in the /etc/syslog.conf file.
 
-    $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+    $ grep -E '(reject|warning|error|fatal|panic):' /some/log/file
 
 Note: the most important error message is logged first. Later messages are not
 as useful.
@@ -916,7 +921,7 @@ and watch your maillog file for any error messages. The pathname is /var/log/
 maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
 pathname is defined in the /etc/syslog.conf file.
 
-    $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+    $ grep -E '(reject|warning|error|fatal|panic):' /some/log/file
 
 Note: the most important error message is logged first. Later messages are not
 as useful.
@@ -1085,6 +1090,7 @@ Finally, build the indexed aliases file with one of the following commands:
 
     # newaliases
     # sendmail -bi
+    # postalias /etc/aliases (pathname is system dependent!)
 
 11 - To chroot or not to chroot
 
@@ -1147,7 +1153,7 @@ Hopefully, the number of problems will be small, but it is a good idea to run
 every night before the syslog files are rotated:
 
     # postfix check
-    # egrep '(reject|warning|error|fatal|panic):' /some/log/file
+    # grep -E '(reject|warning|error|fatal|panic):' /some/log/file
 
   * The first line (postfix check) causes Postfix to report file permission/
     ownership discrepancies.

postfix/LICENSE

@@ -1,3 +1,290 @@
+LICENSE - SECURE MAILER
+
+This software is dual-licensed under both the Eclipse Public License
+version 2.0 and the IBM Public License version 1.0, for those who
+are more comfortable continuing with that license. Recipients can
+choose to take the software under the license of their choice.
+
+The remainder of this text contains a copy of each license.
+
+Eclipse Public License - v 2.0
+
+    THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE
+    PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION
+    OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
+
+1. DEFINITIONS
+
+"Contribution" means:
+
+  a) in the case of the initial Contributor, the initial content
+     Distributed under this Agreement, and
+
+  b) in the case of each subsequent Contributor:
+     i) changes to the Program, and
+     ii) additions to the Program;
+  where such changes and/or additions to the Program originate from
+  and are Distributed by that particular Contributor. A Contribution
+  "originates" from a Contributor if it was added to the Program by
+  such Contributor itself or anyone acting on such Contributor's behalf.
+  Contributions do not include changes or additions to the Program that
+  are not Modified Works.
+
+"Contributor" means any person or entity that Distributes the Program.
+
+"Licensed Patents" mean patent claims licensable by a Contributor which
+are necessarily infringed by the use or sale of its Contribution alone
+or when combined with the Program.
+
+"Program" means the Contributions Distributed in accordance with this
+Agreement.
+
+"Recipient" means anyone who receives the Program under this Agreement
+or any Secondary License (as applicable), including Contributors.
+
+"Derivative Works" shall mean any work, whether in Source Code or other
+form, that is based on (or derived from) the Program and for which the
+editorial revisions, annotations, elaborations, or other modifications
+represent, as a whole, an original work of authorship.
+
+"Modified Works" shall mean any work in Source Code or other form that
+results from an addition to, deletion from, or modification of the
+contents of the Program, including, for purposes of clarity any new file
+in Source Code form that contains any contents of the Program. Modified
+Works shall not include works that contain only declarations,
+interfaces, types, classes, structures, or files of the Program solely
+in each case in order to link to, bind by name, or subclass the Program
+or Modified Works thereof.
+
+"Distribute" means the acts of a) distributing or b) making available
+in any manner that enables the transfer of a copy.
+
+"Source Code" means the form of a Program preferred for making
+modifications, including but not limited to software source code,
+documentation source, and configuration files.
+
+"Secondary License" means either the GNU General Public License,
+Version 2.0, or any later versions of that license, including any
+exceptions or additional permissions as identified by the initial
+Contributor.
+
+2. GRANT OF RIGHTS
+
+  a) Subject to the terms of this Agreement, each Contributor hereby
+  grants Recipient a non-exclusive, worldwide, royalty-free copyright
+  license to reproduce, prepare Derivative Works of, publicly display,
+  publicly perform, Distribute and sublicense the Contribution of such
+  Contributor, if any, and such Derivative Works.
+
+  b) Subject to the terms of this Agreement, each Contributor hereby
+  grants Recipient a non-exclusive, worldwide, royalty-free patent
+  license under Licensed Patents to make, use, sell, offer to sell,
+  import and otherwise transfer the Contribution of such Contributor,
+  if any, in Source Code or other form. This patent license shall
+  apply to the combination of the Contribution and the Program if, at
+  the time the Contribution is added by the Contributor, such addition
+  of the Contribution causes such combination to be covered by the
+  Licensed Patents. The patent license shall not apply to any other
+  combinations which include the Contribution. No hardware per se is
+  licensed hereunder.
+
+  c) Recipient understands that although each Contributor grants the
+  licenses to its Contributions set forth herein, no assurances are
+  provided by any Contributor that the Program does not infringe the
+  patent or other intellectual property rights of any other entity.
+  Each Contributor disclaims any liability to Recipient for claims
+  brought by any other entity based on infringement of intellectual
+  property rights or otherwise. As a condition to exercising the
+  rights and licenses granted hereunder, each Recipient hereby
+  assumes sole responsibility to secure any other intellectual
+  property rights needed, if any. For example, if a third party
+  patent license is required to allow Recipient to Distribute the
+  Program, it is Recipient's responsibility to acquire that license
+  before distributing the Program.
+
+  d) Each Contributor represents that to its knowledge it has
+  sufficient copyright rights in its Contribution, if any, to grant
+  the copyright license set forth in this Agreement.
+
+  e) Notwithstanding the terms of any Secondary License, no
+  Contributor makes additional grants to any Recipient (other than
+  those set forth in this Agreement) as a result of such Recipient's
+  receipt of the Program under the terms of a Secondary License
+  (if permitted under the terms of Section 3).
+
+3. REQUIREMENTS
+
+3.1 If a Contributor Distributes the Program in any form, then:
+
+  a) the Program must also be made available as Source Code, in
+  accordance with section 3.2, and the Contributor must accompany
+  the Program with a statement that the Source Code for the Program
+  is available under this Agreement, and informs Recipients how to
+  obtain it in a reasonable manner on or through a medium customarily
+  used for software exchange; and
+
+  b) the Contributor may Distribute the Program under a license
+  different than this Agreement, provided that such license:
+     i) effectively disclaims on behalf of all other Contributors all
+     warranties and conditions, express and implied, including
+     warranties or conditions of title and non-infringement, and
+     implied warranties or conditions of merchantability and fitness
+     for a particular purpose;
+
+     ii) effectively excludes on behalf of all other Contributors all
+     liability for damages, including direct, indirect, special,
+     incidental and consequential damages, such as lost profits;
+
+     iii) does not attempt to limit or alter the recipients' rights
+     in the Source Code under section 3.2; and
+
+     iv) requires any subsequent distribution of the Program by any
+     party to be under a license that satisfies the requirements
+     of this section 3.
+
+3.2 When the Program is Distributed as Source Code:
+
+  a) it must be made available under this Agreement, or if the
+  Program (i) is combined with other material in a separate file or
+  files made available under a Secondary License, and (ii) the initial
+  Contributor attached to the Source Code the notice described in
+  Exhibit A of this Agreement, then the Program may be made available
+  under the terms of such Secondary Licenses, and
+
+  b) a copy of this Agreement must be included with each copy of
+  the Program.
+
+3.3 Contributors may not remove or alter any copyright, patent,
+trademark, attribution notices, disclaimers of warranty, or limitations
+of liability ("notices") contained within the Program from any copy of
+the Program which they Distribute, provided that Contributors may add
+their own appropriate notices.
+
+4. COMMERCIAL DISTRIBUTION
+
+Commercial distributors of software may accept certain responsibilities
+with respect to end users, business partners and the like. While this
+license is intended to facilitate the commercial use of the Program,
+the Contributor who includes the Program in a commercial product
+offering should do so in a manner which does not create potential
+liability for other Contributors. Therefore, if a Contributor includes
+the Program in a commercial product offering, such Contributor
+("Commercial Contributor") hereby agrees to defend and indemnify every
+other Contributor ("Indemnified Contributor") against any losses,
+damages and costs (collectively "Losses") arising from claims, lawsuits
+and other legal actions brought by a third party against the Indemnified
+Contributor to the extent caused by the acts or omissions of such
+Commercial Contributor in connection with its distribution of the Program
+in a commercial product offering. The obligations in this section do not
+apply to any claims or Losses relating to any actual or alleged
+intellectual property infringement. In order to qualify, an Indemnified
+Contributor must: a) promptly notify the Commercial Contributor in
+writing of such claim, and b) allow the Commercial Contributor to control,
+and cooperate with the Commercial Contributor in, the defense and any
+related settlement negotiations. The Indemnified Contributor may
+participate in any such claim at its own expense.
+
+For example, a Contributor might include the Program in a commercial
+product offering, Product X. That Contributor is then a Commercial
+Contributor. If that Commercial Contributor then makes performance
+claims, or offers warranties related to Product X, those performance
+claims and warranties are such Commercial Contributor's responsibility
+alone. Under this section, the Commercial Contributor would have to
+defend claims against the other Contributors related to those performance
+claims and warranties, and if a court requires any other Contributor to
+pay any damages as a result, the Commercial Contributor must pay
+those damages.
+
+5. NO WARRANTY
+
+EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, AND TO THE EXTENT
+PERMITTED BY APPLICABLE LAW, THE PROGRAM IS PROVIDED ON AN "AS IS"
+BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR
+IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF
+TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR
+PURPOSE. Each Recipient is solely responsible for determining the
+appropriateness of using and distributing the Program and assumes all
+risks associated with its exercise of rights under this Agreement,
+including but not limited to the risks and costs of program errors,
+compliance with applicable laws, damage to or loss of data, programs
+or equipment, and unavailability or interruption of operations.
+
+6. DISCLAIMER OF LIABILITY
+
+EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, AND TO THE EXTENT
+PERMITTED BY APPLICABLE LAW, NEITHER RECIPIENT NOR ANY CONTRIBUTORS
+SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST
+PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE
+EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+7. GENERAL
+
+If any provision of this Agreement is invalid or unenforceable under
+applicable law, it shall not affect the validity or enforceability of
+the remainder of the terms of this Agreement, and without further
+action by the parties hereto, such provision shall be reformed to the
+minimum extent necessary to make such provision valid and enforceable.
+
+If Recipient institutes patent litigation against any entity
+(including a cross-claim or counterclaim in a lawsuit) alleging that the
+Program itself (excluding combinations of the Program with other software
+or hardware) infringes such Recipient's patent(s), then such Recipient's
+rights granted under Section 2(b) shall terminate as of the date such
+litigation is filed.
+
+All Recipient's rights under this Agreement shall terminate if it
+fails to comply with any of the material terms or conditions of this
+Agreement and does not cure such failure in a reasonable period of
+time after becoming aware of such noncompliance. If all Recipient's
+rights under this Agreement terminate, Recipient agrees to cease use
+and distribution of the Program as soon as reasonably practicable.
+However, Recipient's obligations under this Agreement and any licenses
+granted by Recipient relating to the Program shall continue and survive.
+
+Everyone is permitted to copy and distribute copies of this Agreement,
+but in order to avoid inconsistency the Agreement is copyrighted and
+may only be modified in the following manner. The Agreement Steward
+reserves the right to publish new versions (including revisions) of
+this Agreement from time to time. No one other than the Agreement
+Steward has the right to modify this Agreement. The Eclipse Foundation
+is the initial Agreement Steward. The Eclipse Foundation may assign the
+responsibility to serve as the Agreement Steward to a suitable separate
+entity. Each new version of the Agreement will be given a distinguishing
+version number. The Program (including Contributions) may always be
+Distributed subject to the version of the Agreement under which it was
+received. In addition, after a new version of the Agreement is published,
+Contributor may elect to Distribute the Program (including its
+Contributions) under the new version.
+
+Except as expressly stated in Sections 2(a) and 2(b) above, Recipient
+receives no rights or licenses to the intellectual property of any
+Contributor under this Agreement, whether expressly, by implication,
+estoppel or otherwise. All rights in the Program not expressly granted
+under this Agreement are reserved. Nothing in this Agreement is intended
+to be enforceable by any entity that is not a Contributor or Recipient.
+No third-party beneficiary rights are created under this Agreement.
+
+Exhibit A - Form of Secondary Licenses Notice
+
+"This Source Code may also be made available under the following 
+Secondary Licenses when the conditions for such availability set forth 
+in the Eclipse Public License, v. 2.0 are satisfied: {name license(s),
+version(s), and exceptions or additional permissions here}."
+
+  Simply including a copy of this Agreement, including this Exhibit A
+  is not sufficient to license the Source Code under Secondary Licenses.
+
+  If it is not possible or desirable to put the notice in a particular
+  file, then You may include the notice in a location (such as a LICENSE
+  file in a relevant directory) where a recipient would be likely to
+  look for such a notice.
+
+  You may add additional accurate notices of copyright ownership.
+
 IBM PUBLIC LICENSE VERSION 1.0 - SECURE MAILER
 
 THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS IBM PUBLIC

postfix/Makefile.in

@@ -1,5 +1,7 @@
+# To test with valgrind:
+# make -i tests NORANDOMIZE="" VALGRIND="valgrind --tool=memcheck --log-file=/some/where.%p" 
 SHELL	= /bin/sh
-WARN    = -Wmissing-prototypes -Wformat -Wno-comment
+WARN    = -Wmissing-prototypes -Wformat -Wno-comment -fno-common
 OPTS	= 'WARN=$(WARN)'
 DIRS	= src/util src/global src/dns src/tls src/xsasl src/master src/milter \
 	src/postfix src/fsstone src/smtpstone \
@@ -10,7 +12,7 @@ DIRS	= src/util src/global src/dns src/tls src/xsasl src/master src/milter \
 	src/postsuper src/qmqpd src/spawn src/flush src/verify \
 	src/virtual src/proxymap src/anvil src/scache src/discard src/tlsmgr \
 	src/postmulti src/postscreen src/dnsblog src/tlsproxy \
-	src/posttls-finger
+	src/posttls-finger src/postlogd src/testing
 MANDIRS	= proto man html
 LIBEXEC	= libexec/post-install libexec/postfix-script libexec/postfix-wrapper \
 	libexec/postmulti-script libexec/postfix-tls-script
@@ -42,7 +44,7 @@ makefiles Makefiles conf/makedefs.out:
 	     *) cat Makefile.in;; \
 	esac) >Makefile
 
-update printfck tests root_tests:
+update tests root_tests:
 	set -e; for i in $(DIRS); do \
 	 (set -e; echo "[$$i]"; cd $$i; $(MAKE) $(OPTS) $@ MAKELEVEL=) || exit 1; \
 	done
@@ -112,7 +114,67 @@ manpages:
 	 (set -e; echo "[$$i]"; cd $$i; $(MAKE) -f Makefile.in $(OPTS) MAKELEVEL=) || exit 1; \
 	done </dev/null
 
-printfck: update
+# Some checks require a bin/postconf executable.
+pre-release-checks: update typo-check double-check \
+	missing-proxy-read-maps-check \
+	postlink-check postfix-files-check \
+	postconf-unimplemented-check postconf-undocumented-check \
+	check-table-proto check-see-postconf-d-output \
+	check-snapshot-nonprod
+
+postfix-files-check:
+	mantools/check-postfix-files | diff /dev/null -
+
+postlink-check:
+	$(SHLIB_ENV) mantools/check-postlink | diff /dev/null -
+
+postconf-undocumented-check:
+	$(SHLIB_ENV) mantools/check-postconf-undocumented | diff /dev/null -
+
+postconf-unimplemented-check:
+	$(SHLIB_ENV) mantools/check-postconf-unimplemented | diff /dev/null -
+
+missing-proxy-read-maps-check:
+	$(SHLIB_ENV) mantools/missing-proxy-read-maps | diff /dev/null -
+
+typo-check: spell-cc spell-install-proto-text spell-proto-html \
+	check-spell-history
+
+double-check: double-cc double-install-proto-text double-proto-html \
+	check-double-history 
+
+spell-cc:
+	mantools/check-spell-cc | diff /dev/null -
+
+spell-install-proto-text:
+	mantools/check-spell-install-proto-text | diff /dev/null -
+
+spell-proto-html:
+	mantools/check-spell-proto-html | diff /dev/null -
+
+double-cc:
+	mantools/check-double-cc | diff /dev/null -
+
+double-install-proto-text:
+	mantools/check-double-install-proto-text | diff /dev/null -
+
+double-proto-html:
+	mantools/check-double-proto-html | diff /dev/null -
+
+check-spell-history:
+	mantools/check-spell-history | diff /dev/null -
+
+check-double-history:
+	mantools/check-double-history | diff /dev/null -
+
+check-table-proto:
+	mantools/check-table-proto | diff /dev/null -
+
+check-see-postconf-d-output:
+	mantools/check-see-postconf-d-output | diff /dev/null -
+
+check-snapshot-nonprod:
+	mantools/check-snapshot-nonprod
 
 # The build-time shlib_directory setting must take precedence over
 # the installed main.cf settings, otherwise we can't update an
@@ -153,7 +215,7 @@ depend_update:
 
 tidy:	clean
 	rm -f Makefile */Makefile src/*/Makefile
-	cp Makefile.init Makefile
+	cp -p Makefile.init Makefile
 	rm -f README_FILES/RELEASE_NOTES
 	ln -s ../RELEASE_NOTES README_FILES
 	rm -f bin/[!CRS]* lib/[!CRS]* include/[!CRS]* libexec/[!CRS]* \

postfix/Makefile.init

@@ -12,7 +12,7 @@ SHELL	= /bin/sh
 
 default: update
 
-update depend printfck clean tidy depend_update: Makefiles
+update depend clean tidy depend_update: Makefiles
 	$(MAKE) MAKELEVEL= $@
 
 install upgrade:

postfix/README_FILES/AAAREADME

@@ -11,10 +11,12 @@ GGeenneerraall ccoonnffiigguurraattiioonn
   * SASL_README: SASL Authentication
   * TLS_README: TLS Encryption and authentication
   * FORWARD_SECRECY_README: TLS Forward Secrecy
-  * IPV6_README: IP Version 6 Support
+  * TLSRPT_README: TLSRPT Protocol Support
   * IPV6_README: IP Version 6 Support
   * SMTPUTF8_README: SMTPUTF8 Support
+  * MAILLOG_README: Postfix logging to file or stdout
   * COMPATIBILITY_README: Backwards-Compatibility Safety Net
+  * DEPRECATION_README: Deprecated features and alternatives
   * INSTALL: Installation from source code
 
 PPrroobblleemm ssoollvviinngg
@@ -52,6 +54,7 @@ LLooookkuupp ttaabblleess ((ddaattaabbaasseess))
   * LDAP_README: LDAP Howto
   * LMDB_README: LMDB Howto
   * MEMCACHE_README: Memcache Howto
+  * MONGODB_README: MongoDB Howto
   * MYSQL_README: MySQL Howto
   * PCRE_README: PCRE Howto
   * PGSQL_README: PostgreSQL Howto
@@ -78,6 +81,7 @@ OOtthheerr ttooppiiccss
   * ADDRESS_CLASS_README: Address Classes
   * CONNECTION_CACHE_README: Connection cache howto
   * DSN_README: Postfix DSN support
+  * BDAT_README: Postfix BDAT (CHUNKING) support
   * PACKAGE_README: Guidelines for Package Builders
   * SCHEDULER_README: Queue Scheduler
   * XCLIENT_README: XCLIENT Command

postfix/README_FILES/ADDRESS_CLASS_README

@@ -25,18 +25,23 @@ important for the operation of Postfix.
 
 An address class is defined by three items.
 
-  * The list of domains that are a member of the class: for example, all local
-    domains, or all relay domains.
+  * The list of domains that are a member of that address class.
 
-  * The default delivery transport. For example, the local, virtual or relay
-    delivery transport (delivery transports are defined in master.cf). This
-    helps to keep Postfix configurations simple, by avoiding the need for
-    explicit routing information in transport maps.
+    Examples: all local domains, or all relay domains.
 
-  * The list of valid recipient addresses for that address class. The Postfix
-    SMTP server rejects invalid recipients with "User unknown in <name of
-    address class here> table". This helps to keep the Postfix queue free of
-    undeliverable MAILER-DAEMON messages.
+  * The default delivery transport for domains in that address class.
+
+    Examples: local_transport or relay_transport (these point to services
+    defined in master.cf).
+
+    Benefit: this avoids the need for explicit routing information in transport
+    maps.
+
+  * The list of valid recipient addresses for that address class.
+
+    Benefit: the Postfix SMTP server rejects an invalid recipient with "User
+    unknown in <name of address class> table", and avoids sending a MAILER-
+    DAEMON message with backscatter spam.
 
 WWhhaatt aaddddrreessss ccllaasssseess ddooeess PPoossttffiixx iimmpplleemmeenntt??
 
@@ -48,19 +53,19 @@ The local domain class.
 
   * Purpose: final delivery for traditional UNIX system accounts and
     traditional Sendmail-style aliases. This is typically used for the
-    canonical domains of the machine. For a discussion of the difference
-    between canonical domains, hosted domains and other domains, see the
-    VIRTUAL_README file.
+    canonical domains of the machine (for example, $myhostname, $mydomain). For
+    a discussion of the difference between canonical domains, hosted domains
+    and other domains, see the VIRTUAL_README file.
 
   * Domain names are listed with the mydestination parameter. This domain class
     also includes mail for user@[ipaddress] when the IP address is listed with
     the inet_interfaces or proxy_interfaces parameters.
 
-  * Valid recipient addresses are listed with the local_recipient_maps
-    parameter, as described in LOCAL_RECIPIENT_README. The Postfix SMTP server
-    rejects invalid recipients with "User unknown in local recipient table". If
-    the local_recipient_maps parameter value is empty, then the Postfix SMTP
-    server accepts any address in the local domain class.
+  * Valid recipient addresses for those domains are listed with the
+    local_recipient_maps parameter, as described in LOCAL_RECIPIENT_README. The
+    Postfix SMTP server rejects invalid recipients with "User unknown in local
+    recipient table". If the local_recipient_maps parameter value is empty,
+    then the Postfix SMTP server accepts any address in the local domain class.
 
   * The mail delivery transport is specified with the local_transport
     parameter. The default value is llooccaall::$$mmyyhhoossttnnaammee for delivery with the
@@ -68,20 +73,24 @@ The local domain class.
 
 The virtual alias domain class.
 
-  * Purpose: hosted domains where each recipient address is aliased to a local
-    UNIX system account or to a remote address. A virtual alias example is
-    given in the VIRTUAL_README file.
+  * Purpose: hosted domains where each recipient address is aliased to an
+    address in a different domain class, for example, a local UNIX system
+    account or a remote address. A virtual alias example is given in the
+    VIRTUAL_README file.
 
   * Domain names are listed in virtual_alias_domains. The default value is
     $virtual_alias_maps for Postfix 1.1 compatibility.
 
-  * Valid recipient addresses are listed with the virtual_alias_maps parameter.
-    The Postfix SMTP server rejects invalid recipients with "User unknown in
-    virtual alias table". The default value is $virtual_maps for Postfix 1.1
-    compatibility.
+  * Valid recipient addresses for those domains are listed with the
+    virtual_alias_maps parameter. The Postfix SMTP server rejects invalid
+    recipients with "User unknown in virtual alias table". The default value is
+    $virtual_maps for Postfix 1.1 compatibility.
 
-  * There is no mail delivery transport parameter. Every address must be
-    aliased to some other address.
+        Note: for historical reasons, virtual_alias_maps apply to recipients in
+        all domain classes, not only the virtual alias domain class.
+
+  * There is no configurable mail delivery transport. Every address must be
+    aliased to an address in some other domain class.
 
 The virtual mailbox domain class.
 
@@ -92,11 +101,11 @@ The virtual mailbox domain class.
   * Domain names are listed with the virtual_mailbox_domains parameter. The
     default value is $virtual_mailbox_maps for Postfix 1.1 compatibility.
 
-  * Valid recipient addresses are listed with the virtual_mailbox_maps
-    parameter. The Postfix SMTP server rejects invalid recipients with "User
-    unknown in virtual mailbox table". If this parameter value is empty, the
-    Postfix SMTP server accepts all recipients for domains listed in
-    $virtual_mailbox_domains.
+  * Valid recipient addresses for those domains are listed with the
+    virtual_mailbox_maps parameter. The Postfix SMTP server rejects invalid
+    recipients with "User unknown in virtual mailbox table". If this parameter
+    value is empty, the Postfix SMTP server accepts all recipients for domains
+    listed in $virtual_mailbox_domains.
 
   * The mail delivery transport is specified with the virtual_transport
     parameter. The default value is vviirrttuuaall for delivery with the virtual(8)
@@ -112,11 +121,11 @@ The relay domain class.
 
   * Domain names are listed with the relay_domains parameter.
 
-  * Valid recipient addresses are listed with the relay_recipient_maps
-    parameter. The Postfix SMTP server rejects invalid recipients with "User
-    unknown in relay recipient table". If this parameter value is empty, the
-    Postfix SMTP server accepts all recipients for domains listed with the
-    relay_domains parameter.
+  * Valid recipient addresses for those domains are listed with the
+    relay_recipient_maps parameter. The Postfix SMTP server rejects invalid
+    recipients with "User unknown in relay recipient table". If this parameter
+    value is empty, the Postfix SMTP server accepts all recipients for domains
+    listed with the relay_domains parameter.
 
   * The mail delivery transport is specified with the relay_transport
     parameter. The default value is rreellaayy which is a clone of the smtp(8)
@@ -158,8 +167,8 @@ earlier Postfix versions:
     mail (and bounced undeliverable mail) out of the mail queue. This is
     controlled by the smtpd_reject_unlisted_recipient configuration parameter.
 
-  * As of Postfix version 2.1, the SMTP server also rejects unknown sender
-    addresses (i.e. addresses that it would reject as unknown recipient
+  * As of Postfix version 2.1, the SMTP server can also reject unknown sender
+    addresses (i.e. addresses that it would reject as an unknown recipient
     addresses). Sender "egress filtering" can help to slow down an email worm
     explosion. This is controlled by the smtpd_reject_unlisted_sender
     configuration parameter.

postfix/README_FILES/ADDRESS_REWRITING_README

@@ -51,8 +51,7 @@ Topics covered in this document:
 
   * Address rewriting when mail is delivered
 
-      o Resolve address to destination
-      o Mail transport switch
+      o Resolve address to (transport, next-hop destination)
       o Relocated users table
 
   * Address rewriting with remote delivery
@@ -131,59 +130,57 @@ this document for the first time, skip forward to "Address rewriting when mail
 is received". Once you've finished reading the remainder of this document, the
 table will help you to quickly find what you need.
 
-     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
-    |AAddddrreessss     |SSccooppee   |DDaaeemmoonn  |GGlloobbaall ttuurrnn--oonn      |SSeelleeccttiivvee ttuurrnn--ooffff ccoonnttrrooll   |
-    |mmaanniippuullaattiioonn|        |        |ccoonnttrrooll             |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Rewrite     |        |trivial-|append_at_myorigin, |                             |
-    |addresses to|all mail|rewrite |append_dot_mydomain,|local_header_rewrite_clients,|
-    |standard    |        |(8)     |swap_bangpath,      |remote_header_rewrite_domain |
-    |form        |        |        |allow_percent_hack  |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Canonical   |        |cleanup |                    |receive_override_options,    |
-    |address     |all mail|(8)     |canonical_maps      |local_header_rewrite_clients,|
-    |mapping     |        |        |                    |remote_header_rewrite_domain |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Address     |        |cleanup |                    |receive_override_options,    |
-    |masquerading|all mail|(8)     |masquerade_domains  |local_header_rewrite_clients,|
-    |            |        |        |                    |remote_header_rewrite_domain |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Automatic   |        |cleanup |always_bcc,         |                             |
-    |BCC         |new mail|(8)     |sender_bcc_maps,    |receive_override_options     |
-    |recipients  |        |        |recipient_bcc_maps  |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Virtual     |all mail|cleanup |virtual_alias_maps  |receive_override_options     |
-    |aliasing    |        |(8)     |                    |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Resolve     |        |trivial-|                    |                             |
-    |address to  |all mail|rewrite |none                |none                         |
-    |destination |        |(8)     |                    |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Mail        |        |trivial-|                    |                             |
-    |transport   |all mail|rewrite |transport_maps      |none                         |
-    |switch      |        |(8)     |                    |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Relocated   |        |trivial-|                    |                             |
-    |users table |all mail|rewrite |relocated_maps      |none                         |
-    |            |        |(8)     |                    |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Generic     |outgoing|        |                    |                             |
-    |mapping     |SMTP    |smtp(8) |smtp_generic_maps   |none                         |
-    |table       |mail    |        |                    |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Local alias |local   |        |                    |                             |
-    |database    |mail    |local(8)|alias_maps          |none                         |
-    |            |only    |        |                    |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Local per-  |local   |        |                    |                             |
-    |user        |mail    |local(8)|forward_path        |none                         |
-    |.forward    |only    |        |                    |                             |
-    |files       |        |        |                    |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
-    |Local catch-|local   |        |                    |                             |
-    |all address |mail    |local(8)|luser_relay         |none                         |
-    |            |only    |        |                    |                             |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |AAddddrreessss     |SSccooppee   |DDaaeemmoonn  |TTuurrnn--oonn ccoonnttrroollss                       |TTuurrnn--ooffff ccoonnttrroollss            |
+    |mmaanniippuullaattiioonn|        |        |                                       |                             |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Rewrite     |        |trivial-|append_at_myorigin,                    |                             |
+    |addresses to|all mail|rewrite |append_dot_mydomain, swap_bangpath,    |local_header_rewrite_clients,|
+    |standard    |        |(8)     |allow_percent_hack                     |remote_header_rewrite_domain |
+    |form        |        |        |                                       |                             |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Canonical   |        |cleanup |                                       |receive_override_options,    |
+    |address     |all mail|(8)     |canonical_maps                         |local_header_rewrite_clients,|
+    |mapping     |        |        |                                       |remote_header_rewrite_domain |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Address     |        |cleanup |                                       |receive_override_options,    |
+    |masquerading|all mail|(8)     |masquerade_domains                     |local_header_rewrite_clients,|
+    |            |        |        |                                       |remote_header_rewrite_domain |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Automatic   |        |cleanup |always_bcc, sender_bcc_maps,           |                             |
+    |BCC         |new mail|(8)     |recipient_bcc_maps                     |receive_override_options     |
+    |recipients  |        |        |                                       |                             |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Virtual     |all mail|cleanup |virtual_alias_maps                     |receive_override_options     |
+    |aliasing    |        |(8)     |                                       |                             |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Resolve     |        |        |local_transport, virtual_transport,    |                             |
+    |address to  |        |trivial-|relay_transport, default_transport,    |                             |
+    |(transport, |all mail|rewrite |relayhost,                             |content_filter               |
+    |next-hop    |        |(8)     |sender_dependent_relayhost_maps,       |                             |
+    |destination)|        |        |sender_dependent_default_transport_maps|                             |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Relocated   |        |trivial-|                                       |                             |
+    |users table |all mail|rewrite |relocated_maps                         |none                         |
+    |            |        |(8)     |                                       |                             |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Generic     |outgoing|        |                                       |                             |
+    |mapping     |SMTP    |smtp(8) |smtp_generic_maps                      |none                         |
+    |table       |mail    |        |                                       |                             |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Local alias |local   |        |                                       |                             |
+    |database    |mail    |local(8)|alias_maps                             |none                         |
+    |            |only    |        |                                       |                             |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Local per-  |local   |        |                                       |                             |
+    |user        |mail    |local(8)|forward_path                           |none                         |
+    |.forward    |only    |        |                                       |                             |
+    |files       |        |        |                                       |                             |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Local catch-|local   |        |                                       |                             |
+    |all address |mail    |local(8)|luser_relay                            |none                         |
+    |            |only    |        |                                       |                             |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
 
 AAddddrreessss rreewwrriittiinngg wwhheenn mmaaiill iiss rreecceeiivveedd
 
@@ -280,8 +277,8 @@ address manipulations:
 
     Rewrite "user@host" to "user@host.$mydomain"
         This feature is controlled by the boolean append_dot_mydomain parameter
-        (default: yes). The purpose is to get consistent treatment of different
-        forms of the same hostname.
+        (default: Postfix ≥ 3.0: no, Postfix < 3.0: yes). The purpose is to
+        get consistent treatment of different forms of the same hostname.
 
         NOTE: Postfix versions 2.2 and later rewrite message headers from
         remote SMTP clients only if the client matches the
@@ -492,6 +489,10 @@ transform " Firstname.Lastname " back into UNIX login names, although it seems
 that local aliases may be a more appropriate vehicle. See the VIRTUAL_README
 document for an overview of methods to host virtual domains with Postfix.
 
+Note: virtual aliasing (virtual_alias_maps) applies to all recipients: local
+(8), virtual, and remote.  This is unlike local aliasing (alias_maps) which
+applies only to local(8) recipients.
+
 Virtual aliasing is disabled by default. To enable, edit the virtual_alias_maps
 parameter in the main.cf file and specify one or more lookup tables, separated
 by whitespace or commas.
@@ -537,8 +538,7 @@ manipulations to the trivial-rewrite(8) server.
 
 Address manipulations at this stage are:
 
-  * Resolve address to destination
-  * Mail transport switch
+  * Resolve address to (transport, next-hop destination)
   * Relocated users table
 
 Each Postfix delivery agent tries to deliver the mail to its destination, while
@@ -560,49 +560,82 @@ Address manipulations when mail is delivered via the local(8) delivery agent:
 The remainder of this document presents each address manipulation step in more
 detail, with specific examples or with pointers to documentation with examples.
 
-RReessoollvvee aaddddrreessss ttoo ddeessttiinnaattiioonn
+RReessoollvvee aaddddrreessss ttoo ((ttrraannssppoorrtt,, nneexxtt--hhoopp ddeessttiinnaattiioonn))
 
 The Postfix qmgr(8) queue manager selects new mail from the incoming queue or
-old mail from the deferred queue, and asks the trivial-rewrite(8) address
-rewriting and resolving daemon where it should be delivered.
+old mail from the deferred queue. First it looks for overrides:
 
-As of version 2.0, Postfix distinguishes four major address classes. Each class
-has its own list of domain names, and each class has its own default delivery
+  * The REDIRECT action in access(5), header_checks(5) or body_checks(5)
+    overrides all recipients of the message, and overrides a content_filter
+    setting, and FILTER action in access(5), header_checks(5) or body_checks
+    (5). The REDIRECT action was implemented as a short-cut to retaliate for
+    abuse.
+
+  * A content_filter setting and FILTER action in access(5), header_checks(5)
+    or body_checks(5) provide their own (transport, next-hop destination)
+    information. This bypasses all the steps that are described in the
+    remainder of this section.
+
+When there is no content filter override, the qmgr(8) queue manager asks the
+trivial-rewrite(8) address rewriting and resolving daemon for each recipient
+how to deliver it (which message delivery transport) and where to deliver it
+(what next-hop destination).
+
+As of version 2.0, Postfix distinguishes four major domain classes. Each class
+has its own list of recipient domain names, and each class has its own delivery
 method, as shown in the table below. See the ADDRESS_CLASS_README document for
 the fine details. Postfix versions before 2.0 only distinguish between local
 delivery and everything else.
 
+Note that the table does not match recipients against virtual_alias_domains.
+The reason is that all valid recipients in a virtual alias domain must be
+aliased to an address in a different domain. All other recipients in a virtual
+alias domain are by definition undeliverable, and do not need to be considered
+here.
+
      _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
-    |DDeessttiinnaattiioonn ddoommaaiinn lliisstt          |DDeeffaauulltt ddeelliivveerryy mmeetthhoodd|AAvvaaiillaabbiilliittyy|
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |$mydestination, $inet_interfaces,|$local_transport       |Postfix 1.0 |
-    |$proxy_interfaces                |                       |            |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |$virtual_mailbox_domains         |$virtual_transport     |Postfix 2.0 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |$relay_domains                   |$relay_transport       |Postfix 2.0 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |none                             |$default_transport     |Postfix 1.0 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |DDoommaaiinn ccllaassss   |RReecciippiieenntt ddoommaaiinn mmaattcchh |DDeelliivveerryy mmeetthhoodd  |AAvvaaiillaabbiilliittyy|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |               |mydestination,         |                 |            |
+    |Local          |inet_interfaces,       |local_transport  |Postfix 1.0 |
+    |               |proxy_interfaces       |                 |            |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |Virtual mailbox|virtual_mailbox_domains|virtual_transport|Postfix 2.0 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |Relay          |relay_domains          |relay_transport  |Postfix 2.0 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |Default        |none                   |default_transport|Postfix 1.0 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
 
-MMaaiill ttrraannssppoorrtt sswwiittcchh
+The delivery methods in the above table may include a next-hop destination in
+addition to a delivery transport. This may override the next-hop destination
+that is by default taken from the recipient domain.
 
-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)
-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 documents, and the examples in the transport(5) manual page.
+Over time, features have been added to override the above transport and/or
+next-hop destination information. The following table lists where a transport
+or next-hop destination may be taken from, depending on the recipient domain
+class.
 
-Transport table lookups are disabled by default. To enable, edit the
-transport_maps parameter in the main.cf file and specify one or more lookup
-tables, separated by whitespace or commas.
-
-Example:
-
-    /etc/postfix/main.cf:
-        transport_maps = hash:/etc/postfix/transport
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |DDoommaaiinn |TTrraannssppoorrtt ssoouurrcceess ((iinn oorrddeerr ooff          |NNeexxtt hhoopp ssoouurrcceess ((iinn oorrddeerr ooff ddeesscceennddiinngg|
+    |ccllaassss  |ddeesscceennddiinngg pprreecceeddeennccee))                  |pprreecceeddeennccee))                             |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Local  |transport_maps, local_transport         |transport_maps, local_transport,        |
+    |       |                                        |recipient domain                        |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Virtual|transport_maps, virtual_transport       |transport_maps, virtual_transport,      |
+    |mailbox|                                        |recipient domain                        |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |       |                                        |transport_maps, relay_transport,        |
+    |Relay  |transport_maps, relay_transport         |sender_dependent_relayhost_maps,        |
+    |       |                                        |relayhost, recipient domain             |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |       |                                        |transport_maps,                         |
+    |       |transport_maps,                         |sender_dependent_default_transport_maps,|
+    |Default|sender_dependent_default_transport_maps,|default_transport,                      |
+    |       |default_transport                       |sender_dependent_relayhost_maps,        |
+    |       |                                        |relayhost, recipient domain             |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
 
 RReellooccaatteedd uusseerrss ttaabbllee
 
@@ -674,6 +707,10 @@ implement distribution lists, or to direct mail for standard aliases such as
 postmaster to real people. The table can also be used to map
 "Firstname.Lastname" addresses to login names.
 
+Note: local aliasing (alias_maps) applies only to local(8) recipients. This is
+unlike virtual aliasing (virtual_alias_maps) which applies to all recipients:
+local(8), virtual, and remote.
+
 Alias lookups are enabled by default. The default configuration depends on the
 operating system environment, but it is typically one of the following:
 

postfix/README_FILES/ADDRESS_VERIFICATION_README

@@ -6,7 +6,7 @@ WWAARRNNIINNGG
 
 Recipient address verification may cause an increased load on down-stream
 servers in the case of a dictionary attack or a flood of backscatter bounces.
-Sender address verification may cause your site to be blacklisted by some
+Sender address verification may cause your site to be denylisted by some
 providers. See also the "Limitations" section below for more.
 
 WWhhaatt PPoossttffiixx aaddddrreessss vveerriiffiiccaattiioonn ccaann ddoo ffoorr yyoouu
@@ -89,11 +89,11 @@ LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffi
     mail for a remote address can bounce AFTER a preferred MTA accepts the
     recipient address, or AFTER a preferred MTA accepts the message content.
 
-  * Some sites may blacklist you when you are probing them too often (a probe
-    is an SMTP session that does not deliver mail), or when you are probing
-    them too often for a non-existent address. This is one reason why you
-    should use sender address verification sparingly, if at all, when your site
-    receives lots of email.
+  * Some sites may denylist you when you are probing them too often (a probe is
+    an SMTP session that does not deliver mail), or when you are probing them
+    too often for a non-existent address. This is one reason why you should use
+    sender address verification sparingly, if at all, when your site receives
+    lots of email.
 
   * Normally, address verification probe messages follow the same path as
     regular mail. However, some sites send mail to the Internet via an
@@ -125,7 +125,7 @@ LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffi
     "double-bounce@$myorigin" would succeed.
 
   * The downside of using a non-empty sender address is that the address may
-    end op on spammer mailing lists. Although Postfix always discards mail to
+    end up on spammer mailing lists. Although Postfix always discards mail to
     the double-bounce address, this still results in wasted network bandwidth
     and server capacity. To defeat address harvesting, Postfix 2.9 and later
     support time-dependent sender addresses when you specify a non-zero
@@ -224,8 +224,8 @@ verification for specific domains that often appear in forged email.
         ... etcetera ...
 
 At some point in cyberspace/time, a list of frequently forged MAIL FROM domains
-could be found at http://www.monkeys.com/anti-spam/filtering/sender-domain-
-validate.in.
+was archived at https://web.archive.org/web/20080526153208/http://
+www.monkeys.com/anti-spam/filtering/sender-domain-validate.in.
 
 NOTE: One of the first things you might want to do is to turn on sender address
 verification for all your own domains.
@@ -234,7 +234,7 @@ SSeennddeerr aaddddrreessss vveerriiffiiccaattiioonn f
 
 Unfortunately, sender address verification cannot simply be turned on for all
 email - you are likely to lose legitimate mail from mis-configured systems. You
-almost certainly will have to set up white lists for specific addresses, or
+almost certainly will have to set up allow lists for specific addresses, or
 even for entire domains.
 
 To find out how sender address verification would affect your mail, specify
@@ -260,11 +260,11 @@ be blocked:
 This is also a good way to populate your cache with address verification
 results before you start to actually reject mail.
 
-The sender_access restriction is needed to whitelist domains or addresses that
+The sender_access restriction is needed to allowlist domains or addresses that
 are known to be OK. Although Postfix will not mark a known-to-be-good address
 as bad after a probe fails, it is better to be safe than sorry.
 
-NOTE: You will have to whitelist sites such as securityfocus.com and other
+NOTE: You will have to allowlist sites such as securityfocus.com and other
 sites that operate mailing lists that use a different sender address for each
 posting (VERP). Such addresses pollute the address verification cache quickly,
 and generate unnecessary sender verification probes.

postfix/README_FILES/BACKSCATTER_README

@@ -200,8 +200,8 @@ CCaavveeaattss
     email addresses as username@example.com, messages with DSN turned on will
     trigger the REJECT action in the previous section.
 
-    If you have such clients then you can to exclude their Message-ID strings
-    with the two "Message-ID:.* <!&!" patterns that are shown in the previous
+    If you have such clients then you can exclude their Message-ID strings with
+    the two "Message-ID:.* <!&!" patterns that are shown in the previous
     section. Otherwise you will not be able to use the two backscatter rules to
     stop forged Message ID strings. Of course this workaround may break the
     next time Outlook is changed.
@@ -260,8 +260,9 @@ techniques to recognize forgeries.
 Recognizing virus scanner mail is an error prone process, because there is a
 lot of variation in report formats. The following is only a small example of
 message header patterns. For a large collection of header and body patterns
-that recognize virus notification email, see http://www.dkuug.dk/keld/virus/ or
-http://www.t29.dk/antiantivirus.txt.
+that recognize virus notification email, see https://web.archive.org/web/
+20100317123907/http://std.dkuug.dk/keld/virus/ or https://www.t29.dk/
+antiantivirus.txt.
 
     /etc/postfix/header_checks:
         /^Subject: *Your email contains VIRUSES/ DISCARD virus notification

postfix/README_FILES/BASIC_CONFIGURATION_README

@@ -172,28 +172,29 @@ Postfix can also be configured to relay mail from "mobile" clients that send
 mail from outside an authorized network block. This is explained in the
 SASL_README and TLS_README documents.
 
-IMPORTANT: If your machine is connected to a wide area network then your
-default mynetworks setting may be too friendly.
+IMPORTANT: If your machine is connected to a wide area network then the
+"mynetworks_style = subnet" setting may be too friendly.
 
 Examples (specify only one of the following):
 
     /etc/postfix/main.cf:
-        mynetworks_style = subnet  (default: authorize subnetworks)
-        mynetworks_style = host    (safe: authorize local machine only)
-        mynetworks = 127.0.0.0/8   (safe: authorize local machine only)
+        mynetworks_style = subnet  (not safe on a wide area network)
+        mynetworks_style = host    (authorize local machine only)
+        mynetworks = 127.0.0.0/8   (authorize local machine only)
         mynetworks = 127.0.0.0/8 168.100.189.2/32 (authorize local machine)
+        mynetworks = 127.0.0.0/8 168.100.189.2/28 (authorize local networks)
 
 You can specify the trusted networks in the main.cf file, or you can let
 Postfix do the work for you. The default is to let Postfix do the work. The
 result depends on the mynetworks_style parameter value.
 
-  * Specify "mynetworks_style = host" when Postfix should forward mail from
-    only the local machine.
+  * Specify "mynetworks_style = host" (the default when compatibility_level >=
+    2) when Postfix should forward mail from only the local machine.
 
-  * Specify "mynetworks_style = subnet" (the default) when Postfix should
-    forward mail from SMTP clients in the same IP subnetworks as the local
-    machine. On Linux, this works correctly only with interfaces specified with
-    the "ifconfig" command.
+  * Specify "mynetworks_style = subnet" (the default when compatibility_level <
+    2) when Postfix should forward mail from SMTP clients in the same IP
+    subnetworks as the local machine. On Linux, this works correctly only with
+    interfaces specified with the "ifconfig" or "ip" command.
 
   * Specify "mynetworks_style = class" when Postfix should forward mail from
     SMTP clients in the same IP class A/B/C networks as the local machine.
@@ -368,7 +369,7 @@ Hopefully, the number of problems will be small, but it is a good idea to run
 every night before the syslog files are rotated:
 
     # postfix check
-    # egrep '(reject|warning|error|fatal|panic):' /some/log/file
+    # grep -E '(reject|warning|error|fatal|panic):' /some/log/file
 
   * The first line (postfix check) causes Postfix to report file permission/
     ownership discrepancies.

postfix/README_FILES/BDAT_README

@@ -0,0 +1,124 @@
+PPoossttffiixx BBDDAATT ((CCHHUUNNKKIINNGG)) ssuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+Postfix SMTP server supports RFC 3030 CHUNKING (the BDAT command) without
+BINARYMIME, in both smtpd(8) and postscreen(8). It is enabled by default.
+
+Topics covered in this document:
+
+  * Disabling BDAT support
+  * Impact on existing configurations
+  * Example SMTP session
+  * Benefits of CHUNKING (BDAT) support without BINARYMIME
+  * Downsides of CHUNKING (BDAT) support
+
+DDiissaabblliinngg BBDDAATT ssuuppppoorrtt
+
+BDAT support is enabled by default. To disable BDAT support globally:
+
+    /etc/postfix/main.cf:
+        # The logging alternative:
+        smtpd_discard_ehlo_keywords = chunking
+        # The non-logging alternative:
+        smtpd_discard_ehlo_keywords = chunking, silent-discard
+
+Specify '-o smtpd_discard_ehlo_keywords=' in master.cf for the submission and
+smtps services, if you have clients that benefit from CHUNKING support.
+
+IImmppaacctt oonn eexxiissttiinngg ccoonnffiigguurraattiioonnss
+
+  * There are no changes for smtpd_mumble_restrictions, smtpd_proxy_filter,
+    smtpd_milters, or for postscreen settings, except for the above mentioned
+    option to suppress the SMTP server's CHUNKING service announcement.
+
+  * There are no changes in the Postfix queue file content, no changes for
+    down-stream SMTP servers or after-queue content filters, and no changes in
+    the envelope or message content that Milters will receive.
+
+EExxaammppllee SSMMTTPP sseessssiioonn
+
+The main differences are that the Postfix SMTP server announces "CHUNKING"
+support in the EHLO response, and that instead of sending one DATA request, the
+remote SMTP client may send one or more BDAT requests. In the example below,
+"S:" indicates server responses, and "C:" indicates client requests (bold
+font).
+
+        S: 220 server.example.com
+        C: EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+        S: 250-server.example.com
+        S: 250-PIPELINING
+        S: 250-SIZE 153600000
+        S: 250-VRFY
+        S: 250-ETRN
+        S: 250-STARTTLS
+        S: 250-AUTH PLAIN LOGIN
+        S: 250-ENHANCEDSTATUSCODES
+        S: 250-8BITMIME
+        S: 250-DSN
+        S: 250-SMTPUTF8
+        S: 250 CHUNKING
+        C: MMAAIILL FFRROOMM::<<sseennddeerr@@eexxaammppllee..ccoomm>>
+        S: 250 2.1.0 Ok
+        C: RRCCPPTT TTOO::<<rreecciippiieenntt@@eexxaammppllee..ccoomm>>
+        S: 250 2.1.5 Ok
+        C: BBDDAATT 1100000000
+        C: ....ffoolllloowweedd bbyy 1100000000 bbyytteess......
+        S: 250 2.0.0 Ok: 10000 bytes
+        C: BBDDAATT 112233
+        C: ....ffoolllloowweedd bbyy 112233 bbyytteess......
+        S: 250 2.0.0 Ok: 123 bytes
+        C: BBDDAATT 00 LLAASSTT
+        S: 250 2.0.0 Ok: 10123 bytes queued as 41yYhh41qmznjbD
+        C: QQUUIITT
+        S: 221 2.0.0 Bye
+
+Internally in Postfix, there is no difference between mail that was received
+with BDAT or with DATA. Postfix smtpd_mumble_restrictions, policy delegation
+queries, smtpd_proxy_filter and Milters all behave as if Postfix received (MAIL
++ RCPT + DATA + end-of-data). However, Postfix will log BDAT-related failures
+as "xxx after BDAT" to avoid complicating troubleshooting (xxx = 'lost
+connection' or 'timeout'), and will log a warning when a client sends a
+malformed BDAT command.
+
+BBeenneeffiittss ooff CCHHUUNNKKIINNGG ((BBDDAATT)) ssuuppppoorrtt wwiitthhoouutt BBIINNAARRYYMMIIMMEE
+
+Support for CHUNKING (BDAT) was added to improve interoperability with some
+clients, a benefit that would reportedly exist even without Postfix support for
+BINARYMIME. Since June 2018, Wietse's mail server has received BDAT commands
+from a variety of systems.
+
+Postfix does not support BINARYMIME at this time because:
+
+  * BINARYMIME support would require moderately invasive changes to Postfix, to
+    support email content that is not line-oriented. With BINARYMIME, the
+    Content-Length: message header specifies the length of content that may or
+    may not have line boundaries. Without BINARYMIME support, email RFCs
+    require that binary content is base64-encoded, and formatted as lines of
+    text.
+
+  * For delivery to non-BINARYMIME systems including UNIX mbox, the available
+    options are to convert binary content into 8bit text, one of the 7bit forms
+    (base64 or quoted-printable), or to return email as undeliverable. Any
+    conversion would obviously break digital signatures, so conversion would
+    have to happen before signing.
+
+DDoowwnnssiiddeess ooff CCHHUUNNKKIINNGG ((BBDDAATT)) ssuuppppoorrtt
+
+The RFC 3030 authors did not specify any limitations on how clients may
+pipeline commands (i.e. send commands without waiting for a server response).
+If a server announces PIPELINING support, like Postfix does, then a remote SMTP
+client can pipeline all commands following EHLO, for example, MAIL/RCPT/BDAT/
+BDAT/MAIL/RCPT/BDAT, without ever having to wait for a server response. This
+means that with BDAT, the Postfix SMTP server cannot distinguish between a
+well-behaved client and a spambot, based on their command pipelining behavior.
+If you require "reject_unauth_pipelining" to block spambots, then turn off
+Postfix's CHUNKING announcement as described above.
+
+In RFC 4468, the authors write that a client may pipeline commands, and that
+after sending BURL LAST or BDAT LAST, a client must wait for the server's
+response. But as this text does not appear in RFC 3030 which defines BDAT, it
+is a useless restriction that Postfix will not enforce.
+

postfix/README_FILES/BUILTIN_FILTER_README

@@ -165,7 +165,7 @@ LLiimmiittaattiioonnss ooff PPoossttffiixx hheeaaddeer
 
 PPrreevveennttiinngg ddaaiillyy mmaaiill ssttaattuuss rreeppoorrttss ffrroomm bbeeiinngg bblloocckkeedd
 
-The following is quoted from Jim Seymour's Pflogsumm FAQ at http://
+The following is quoted from Jim Seymour's Pflogsumm FAQ at https://
 jimsun.linxnet.com/downloads/pflogsumm-faq.txt. Pflogsumm is a program that
 analyzes Postfix logs, including the logging from rejected mail. If these logs
 contain text that was rejected by Postfix body_checks patterns, then the
@@ -235,7 +235,7 @@ server IP addresses in master.cf:
             -o receive_override_options=no_header_body_checks
         127.0.0.1:smtp inet  n       -       n       -       -       smtpd
             -o receive_override_options=no_header_body_checks
-        pickup         fifo  n       -       n       60      1       pickup
+        pickup         unix  n       -       n       60      1       pickup
             -o receive_override_options=no_header_body_checks
 
   * Add some firewall rule to prevent access to 1.2.3.4:smtp from the outside
@@ -300,9 +300,9 @@ CCoonnffiigguurriinngg hheeaaddeerr//bbooddyy cchheecc
 The following information applies to Postfix 2.1. Earlier Postfix versions do
 not support the receive_override_options feature.
 
-If you are MX service provider and want to apply disable head/body checks for
-some domains, you can configure ONE Postfix instance with multiple SMTP server
-IP addresses in master.cf. Each address provides a different service.
+If you are an MX service provider and want to enable header/body checks only
+for some domains, you can configure ONE Postfix instance with multiple SMTP
+server IP addresses in master.cf. Each address provides a different service.
 
     /etc/postfix.master.cf:
         # =================================================================

postfix/README_FILES/CDB_README

@@ -17,8 +17,25 @@ temporarily while a CDB file is under construction). CDB databases are
 maintained with the postmap(1) or postalias(1) command. The DATABASE_README
 document has general information about Postfix databases.
 
-CDB support is available with Postfix 2.2 and later releases. This document
-describes how to build Postfix with CDB support.
+You can use "cdb:" tables wherever you can use read-only "hash", "btree" or
+"lmdb" tables with the following limitations:
+
+  * CDB databases cannot be larger than 4GB on LP64 and ILP32 systems, because
+    the CDB library API uses unsigned integers for file offsets.
+
+  * The "ppoossttmmaapp --ii" (incremental record insertion) and "ppoossttmmaapp --dd"
+    (incremental record deletion) command-line options are not available. For
+    the same reason the "cdb:" map type cannot be used to for persistent
+    caches, such as the address verification cache for the verify(8) service,
+    the TLS session cache for the tlsmgr(8) service, or the dynamic allowlist
+    for postscreen(8).
+
+  * The "sequence" operation ("ppoossttmmaapp --ss" or "ppoossttaalliiaass --ss") is available only
+    wen Postfix is built with tinycdb by Michael Tokarev, not with the original
+    cdb library by Daniel Bernstein.
+
+CDB support is available with Postfix 2.2 and later releases. The remainder of
+this document describes how to build Postfix with CDB support.
 
 BBuuiillddiinngg PPoossttffiixx wwiitthh CCDDBB ssuuppppoorrtt
 
@@ -28,11 +45,11 @@ from a vendor-specific source package.
 
 Postfix is compatible with two CDB implementations:
 
-  * The original cdb library from Daniel Bernstein, available from http://
+  * The original cdb library from Daniel Bernstein, available from https://
     cr.yp.to/cdb.html, and
 
-  * tinycdb (version 0.5 and later) from Michael Tokarev, available from http:/
-    /www.corpit.ru/mjt/tinycdb.html.
+  * tinycdb (version 0.5 and later) from Michael Tokarev, available from https:
+    //www.corpit.ru/mjt/tinycdb.html.
 
 Tinycdb is preferred, since it is a bit faster, has additional useful
 functionality and is much simpler to use.
@@ -64,11 +81,3 @@ building a dynamically-loaded or statically-loaded CDB database client.
     database library dependencies. And that was exactly what dynamic database
     client loading was meant to avoid.
 
-After Postfix has been built with cdb support, you can use "cdb" tables
-wherever you can use read-only "hash", "btree" or "dbm" tables. However, the
-"ppoossttmmaapp --ii" (incremental record insertion) and "ppoossttmmaapp --dd" (incremental
-record deletion) command-line options are not available. For the same reason
-the "cdb" map type cannot be used to store the persistent address verification
-cache for the verify(8) service, or to store TLS session information for the
-tlsmgr(8) service.
-

postfix/README_FILES/COMPATIBILITY_README

@@ -27,20 +27,42 @@ compatible settings need to be made permanent in main.cf or master.cf, before
 turning off the backwards-compatibility safety net as described at the end of
 this document.
 
-The following messages may be logged:
+Logged with compatibility_level < 1:
 
   * Using backwards-compatible default setting append_dot_mydomain=yes
 
   * Using backwards-compatible default setting chroot=y
 
-  * Using backwards-compatible default setting smtpd_relay_restrictions =
-    (empty)
+  * Using backwards-compatible default setting "smtpd_relay_restrictions =
+    (empty)"
+
+  * Using backwards-compatible default setting smtputf8_enable=no
+
+Logged with compatibility_level < 2:
 
   * Using backwards-compatible default setting mynetworks_style=subnet
 
   * Using backwards-compatible default setting relay_domains=$mydestination
 
-  * Using backwards-compatible default setting smtputf8_enable=no
+Logged with compatibility_level < 3.6:
+
+  * Using backwards-compatible default setting smtpd_tls_fingerprint_digest=md5
+
+  * Using backwards-compatible default setting smtp_tls_fingerprint_digest=md5
+
+  * Using backwards-compatible default setting lmtp_tls_fingerprint_digest=md5
+
+  * Using backwards-compatible default setting
+    smtpd_relay_before_recipient_restrictions=no
+
+  * Using backwards-compatible default setting respectful_logging=no
+
+Logged with compatibility_level < 3.11:
+
+  * using backwards-compatible default setting
+    smtp_tlsrpt_skip_reused_handshakes=yes
+
+  * using backwards-compatible default setting xxx_security_level=(empty)
 
 If such a message is logged in the context of a legitimate request, the system
 administrator should make the backwards-compatible setting permanent in main.cf
@@ -57,9 +79,9 @@ could result in unexpected non-delivery of email after Postfix is updated from
 an older version. The backwards-compatibility safety net is designed to prevent
 such surprises.
 
-As long as the append_dot_mydomain parameter is left at its implicit default
-value, and the compatibility_level setting is less than 1, Postfix may log one
-of the following messages:
+As long as the append_dot_mydomain parameter is left unspecified at its
+implicit default value, and the compatibility_level setting is less than 1,
+Postfix may log one of the following messages:
 
   * Messages about missing "localhost" in mydestination or other address class:
 
@@ -95,9 +117,9 @@ the chroot feature enabled after updating Postfix from an older version. The
 backwards-compatibility safety net is designed allow the administrator to
 choose if they want to keep the old behavior.
 
-As long as a master.cf chroot field is left at its implicit default value, and
-the compatibility_level setting is less than 1, Postfix may log the following
-message while it reads the master.cf file:
+As long as a master.cf chroot field is left unspecified at its implicit default
+value, and the compatibility_level setting is less than 1, Postfix may log the
+following message while it reads the master.cf file:
 
     postfix/master[27664]: /etc/postfix/master.cf: line 72: using
         backwards-compatible default setting chroot=y
@@ -122,8 +144,8 @@ denied' errors after Postfix is updated from an older Postfix version. The
 backwards-compatibility safety net is designed to prevent such surprises.
 
 When the compatibility_level less than 1, and the smtpd_relay_restrictions
-parameter is left at its implicit default setting, Postfix may log the
-following message:
+parameter is left unspecified at its implicit default setting, Postfix may log
+the following message:
 
     postfix/smtpd[38463]: using backwards-compatible default setting
         "smtpd_relay_restrictions = (empty)" to avoid "Relay access
@@ -137,17 +159,45 @@ permanent in main.cf:
     # ppoossttccoonnff ssmmttppdd__rreellaayy__rreessttrriiccttiioonnss==
     # ppoossttffiixx rreellooaadd
 
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg ssmmttppuuttff88__eennaabbllee==nnoo
+
+The smtputf8_enable default value has changed from "no" to "yes". With the new
+"yes" setting, the Postfix SMTP server rejects non-ASCII addresses from clients
+that don't request SMTPUTF8 support, after Postfix is updated from an older
+version. The backwards-compatibility safety net is designed to prevent such
+surprises.
+
+As long as the smtputf8_enable parameter is left unspecified at its implicit
+default value, and the compatibility_level setting is less than 1, Postfix logs
+a warning each time an SMTP command uses a non-ASCII address localpart without
+requesting SMTPUTF8 support:
+
+    postfix/smtpd[27560]: using backwards-compatible default setting
+        smtputf8_enable=no to accept non-ASCII sender address
+        "??@example.org" from localhost[127.0.0.1]
+
+    postfix/smtpd[27560]: using backwards-compatible default setting
+        smtputf8_enable=no to accept non-ASCII recipient address
+        "??@example.com" from localhost[127.0.0.1]
+
+If the address should not be rejected, and the client cannot be updated to use
+SMTPUTF8, then the system administrator should make the backwards-compatible
+setting "smtputf8_enable = no" permanent in main.cf:
+
+    # ppoossttccoonnff ssmmttppuuttff88__eennaabbllee==nnoo
+    # ppoossttffiixx rreellooaadd
+
 UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg mmyynneettwwoorrkkss__ssttyyllee==ssuubbnneett
 
 The mynetworks_style default value has changed from "subnet" to "host". This
 parameter is used to implement the "permit_mynetworks" feature. The change
-could in unexpected 'access denied' errors after Postfix is updated from an
+could cause unexpected 'access denied' errors after Postfix is updated from an
 older version. The backwards-compatibility safety net is designed to prevent
 such surprises.
 
-As long as the mynetworks and mynetworks_style parameters are left at their
-implicit default values, and the compatibility_level setting is less than 2,
-the Postfix SMTP server may log one of the following messages:
+As long as the mynetworks and mynetworks_style parameters are left unspecified
+at their implicit default values, and the compatibility_level setting is less
+than 2, the Postfix SMTP server may log one of the following messages:
 
     postfix/smtpd[17375]: using backwards-compatible default setting
         mynetworks_style=subnet to permit request from client
@@ -171,9 +221,9 @@ value. This could result in unexpected 'Relay access denied' errors or ETRN
 errors after Postfix is updated from an older version. The backwards-
 compatibility safety net is designed to prevent such surprises.
 
-As long as the relay_domains parameter is left at its implicit default value,
-and the compatibility_level setting is less than 2, Postfix may log one of the
-following messages.
+As long as the relay_domains parameter is left unspecified at its implicit
+default value, and the compatibility_level setting is less than 2, Postfix may
+log one of the following messages.
 
   * Messages about accepting mail for a remote domain:
 
@@ -208,34 +258,179 @@ Note: quotes are required as indicated above.
 Instead of $mydestination, it may be better to specify an explicit list of
 domain names.
 
-UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg ssmmttppuuttff88__eennaabbllee==nnoo
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg ssmmttppdd__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt==mmdd55
 
-The smtputf8_enable default value has changed from "no" to "yes. With the new
-"yes" setting, the Postfix SMTP server rejects non-ASCII addresses from clients
-that don't request SMTPUTF8 support, after Postfix is updated from an older
-version. The backwards-compatibility safety net is designed to prevent such
-surprises.
+The smtpd_tls_fingerprint_digest default value has changed from "md5" to
+"sha256". With the new "sha256" setting, the Postfix SMTP server avoids using
+the deprecated "md5" algorithm and computes a more secure digest of the client
+certificate.
 
-As long as the smtputf8_enable parameter is left at its implicit default value,
-and the compatibility_level setting is less than 1, Postfix logs a warning each
-time an SMTP command uses a non-ASCII address localpart without requesting
-SMTPUTF8 support:
+If you're using the default "md5" setting, or even an explicit "sha1" (also
+deprecated) setting, you should consider switching to "sha256". This will
+require updating any associated lookup table keys with the "sha256" digests of
+the expected client certificate or public key.
+
+As long as the smtpd_tls_fingerprint_digest parameter is left unspecified at
+its implicit default value, and the compatibility_level setting is less than
+3.6, Postfix logs a warning each time a client certificate or public key
+fingerprint is (potentially) used for access control:
 
     postfix/smtpd[27560]: using backwards-compatible default setting
-        smtputf8_enable=no to accept non-ASCII sender address
-        "??@example.org" from localhost[127.0.0.1]
+        smtpd_tls_fingerprint_digest=md5 to compute certificate fingerprints
 
-    postfix/smtpd[27560]: using backwards-compatible default setting
-        smtputf8_enable=no to accept non-ASCII recipient address
-        "??@example.com" from localhost[127.0.0.1]
+Since any client certificate fingerprints are passed in policy service lookups,
+and Postfix doesn't know whether the fingerprint will be used, the warning may
+also be logged when policy lookups are performed for connections that used a
+client certificate, even if the policy service does not in fact examine the
+client certificate. To reduce the noise somewhat, such warnings are issued at
+most once per smtpd(8) process instance.
 
-If the address should not be rejected, and the client cannot be updated to use
-SMTPUTF8, then the system administrator should make the backwards-compatible
-setting "smtputf8_enable = no" permanent in main.cf:
+If you prefer to stick with "md5", you can suppress the warnings by making that
+setting explicit. After addressing any other compatibility warnings, you can
+update your compatibility level.
 
-    # ppoossttccoonnff ssmmttppuuttff88__eennaabbllee==nnoo
+    # ppoossttccoonnff ssmmttppdd__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt==mmdd55
     # ppoossttffiixx rreellooaadd
 
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg ssmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt==mmdd55
+
+The smtp_tls_fingerprint_digest and lmtp_tls_fingerprint_digest default values
+have changed from "md5" to "sha256". With the new "sha256" setting, the Postfix
+SMTP and LMTP client avoids using the deprecated "md5" algorithm and computes a
+more secure digest of the server certificate.
+
+If you're using the default "md5" setting, or even an explicit "sha1" (also
+deprecated) setting, you should consider switching to "sha256". This will
+require updating any "fingerprint" security level policies in the TLS policy
+table to specify matching "sha256" digests of the expected server certificates
+or public keys.
+
+As long as the smtp_tls_fingerprint_digest (or LMTP equivalent) parameter is
+left unspecified at its implicit default value, and the compatibility_level
+setting is less than 3.6, Postfix logs a warning each time the "fingerprint"
+security level is used to specify matching "md5" digests of trusted server
+certificates or public keys:
+
+    postfix/smtp[27560]: using backwards-compatible default setting
+        smtp_tls_fingerprint_digest=md5 to compute certificate fingerprints
+
+If you prefer to stick with "md5", you can suppress the warnings by making that
+setting explicit. After addressing any other compatibility warnings, you can
+update your compatibility level.
+
+    # ppoossttccoonnff ''ssmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt == mmdd55'' \\
+        ''llmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt == mmdd55''
+    # ppoossttffiixx rreellooaadd
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg
+ssmmttppdd__rreellaayy__bbeeffoorree__rreecciippiieenntt__rreessttrriiccttiioonnss==nnoo
+
+The smtpd_relay_before_recipient_restrictions feature was introduced in Postfix
+version 3.6, to evaluate smtpd_relay_restrictions before
+smtpd_recipient_restrictions. Historically, smtpd_relay_restrictions was
+evaluated after smtpd_recipient_restrictions, contradicting documented
+behavior.
+
+    Background: smtpd_relay_restrictions is primarily designed to enforce a
+    mail relaying policy, while smtpd_recipient_restrictions is primarily
+    designed to enforce spam blocking policy. Both are evaluated while replying
+    to the RCPT TO command, and both support the same features.
+
+To maintain compatibility with earlier versions, Postfix will keep evaluating
+smtpd_recipient_restrictions before smtpd_relay_restrictions, as long as the
+compatibility_level is less than 3.6, and the
+smtpd_relay_before_recipient_restrictions parameter is left unspecified at its
+implicit default setting. As a reminder, Postfix may log the following message:
+
+    postfix/smtpd[54696]: using backwards-compatible default setting
+        smtpd_relay_before_recipient_restrictions=no to reject recipient
+        "user@example.com" from client "host.example.net[10.0.0.2]"
+
+If Postfix should keep evaluating smtpd_recipient_restrictions before
+smtpd_relay_restrictions, then the system administrator should make the
+backwards-compatible setting "smtpd_relay_before_recipient_restrictions=no"
+permanent in main.cf:
+
+    #  ppoossttccoonnff ssmmttppdd__rreellaayy__bbeeffoorree__rreecciippiieenntt__rreessttrriiccttiioonnss==nnoo
+    #  ppoossttffiixx rreellooaadd
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg rreessppeeccttffuull__llooggggiinngg==nnoo
+
+Postfix version 3.6 deprecates configuration parameter names and logging that
+suggest white is better than black. Instead it prefers 'allowlist, 'denylist',
+and variations of those words. While the renamed configuration parameters have
+backwards-compatible default values, the changes in logging could affect
+logfile analysis tools.
+
+To avoid breaking existing logfile analysis tools, Postfix will keep logging
+the deprecated form, as long as the respectful_logging parameter is left
+unspecified at its implicit default value, and the compatibility_level setting
+is less than 3.6. As a reminder, Postfix may log the following when a remote
+SMTP client is allowlisted or denylisted:
+
+    postfix/postscreen[22642]: Using backwards-compatible default setting
+        respectful_logging=no for client [address]:port
+
+If Postfix should keep logging the deprecated form, then the system
+administrator should make the backwards-compatible setting "respectful_logging
+= no" permanent in main.cf.
+
+    # ppoossttccoonnff ""rreessppeeccttffuull__llooggggiinngg == nnoo""
+    # ppoossttffiixx rreellooaadd
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg
+ssmmttpp__ttllssrrpptt__sskkiipp__rreeuusseedd__hhaannddsshhaakkeess==yyeess
+
+Postfix version 3.11 changes the default value for
+smtp_tlsrpt_skip_reused_handshakes from "yes" to "no". The backwards-
+compatibility safety net is designed to prevent an unexpected change in
+reporting behavior when Postfix is updated from an older version.
+
+As long as the smtp_tlsrpt_skip_reused_handshakes parameter is left unspecified
+at its implicit default value, and the compatibility_level setting is less than
+3.11, Postfix will log a reminder that it is using the backwards-compatible
+default:
+
+    postfix/smtp[388157] using backwards-compatible default setting
+        smtp_tlsrpt_skip_reused_handshakes=yes
+
+To keep the old default setting, the system administrator should make the
+backwards-compatible setting "smtp_tlsrpt_skip_reused_handshakes = yes"
+permanent in main.cf:
+
+    # ppoossttccoonnff ssmmttpp__ttllssrrpptt__sskkiipp__rreeuusseedd__hhaannddsshhaakkeess==yyeess
+    # ppoossttffiixx rreellooaadd
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg xxxxxx__sseeccuurriittyy__lleevveell==((eemmppttyy))
+
+Postfix version 3.11 changes the default value for client TLS security levels
+from "empty" to "may". The backwards-compatibility safety net is designed to
+prevent an unexpected change in mail sending behavior when Postfix is updated
+from an older version.
+
+There is no equivalent change for Postfix server TLS security levels, because
+changing the level alone is not sufficient. Server-side TLS requires that at
+least one private key and one public-key certificate chain are configured.
+
+As long as a TLS security level parameter is left unspecified at its implicit
+default value, and the compatibility_level setting is less than 3.11, Postfix
+will log one of the following reminders that it is using the backwards-
+compatible default:
+
+    postfix/smtp[...] using backwards-compatible default setting
+        smtp_tls_security_level=(empty)
+
+    postfix/tlsproxy[...] using backwards-compatible default setting
+        tlsproxy_client_security_level=(empty)
+
+To keep the old default setting, the system administrator should make the
+backwards-compatible empty setting permanent in main.cf:
+
+    # ppoossttccoonnff xxxxxx__sseeccuurriittyy__lleevveell==
+    # ppoossttffiixx rreellooaadd
+
+where xxx is taken from the above compatibility message.
+
 TTuurrnniinngg ooffff tthhee bbaacckkwwaarrddss--ccoommppaattiibbiilliittyy ssaaffeettyy nneett
 
 Backwards compatibility is turned off by updating the compatibility_level
@@ -252,3 +447,13 @@ For N specify the number that is logged in your postfix(1) warning message:
 Sites that don't care about backwards compatibility may set
 "compatibility_level = 9999" at their own risk.
 
+Starting with Postfix version 3.6, the compatibility level in the above warning
+message is the Postfix version that introduced the last incompatible change.
+The level is formatted as major.minor.patch, where patch is usually omitted and
+defaults to zero. Earlier compatibility levels are 0, 1 and 2.
+
+NOTE: Postfix 3.6 also introduces support for the "<level", "<=level", and
+other operators to compare compatibility levels. With the standard operators
+"<", "<=", etc., compatibility level "3.10" would be smaller than "3.9" which
+is undesirable.
+

postfix/README_FILES/CONNECTION_CACHE_README

@@ -19,8 +19,9 @@ Topics covered in this document:
 WWhhaatt SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg ccaann ddoo ffoorr yyoouu
 
 With SMTP connection caching, Postfix can deliver multiple messages over the
-same SMTP connection. By default, Postfix 2.2 reuses an SMTP connection
-automatically when a destination has high volume of mail in the active queue.
+same SMTP connection. By default, Postfix 2.2 reuses a plaintext SMTP
+connection automatically when a destination has high volume of mail in the
+active queue.
 
 SMTP Connection caching is a performance feature. Whether or not it actually
 improves performance depends on the conditions:
@@ -29,9 +30,15 @@ improves performance depends on the conditions:
     mail to a destination with multiple mail servers, because it can help
     Postfix to skip over a non-responding server.
 
+  * SMTP Connection caching can also help with receivers that impose rate
+    limits on new connections.
+
   * Otherwise, the benefits of SMTP connection caching are minor: it eliminates
     the latency of the TCP handshake (SYN, SYN+ACK, ACK), plus the latency of
     the SMTP initial handshake (220 greeting, EHLO command, EHLO response).
+    With TLS-encrypted connections, this can save an additional two roundtrips
+    that would otherwise be needed to send STARTTLS and to resume a TLS
+    session.
 
   * SMTP Connection caching gives no gains with respect to SMTP session tear-
     down. The Postfix smtp(8) client normally does not wait for the server's
@@ -52,27 +59,16 @@ For an overview of how Postfix delivers mail, see the Postfix architecture
 OVERVIEW document.
 
 The Postfix connection cache is shared among Postfix mail delivering processes.
-This maximizes the opportunity to reuse an open connection. Other MTAs such as
-Sendmail or exim have a non-shared connection cache. Here, a connection can be
-reused only by the mail delivering process that creates the connection. To get
-the same performance improvement as with a shared connection cache, non-shared
+This maximizes the opportunity to reuse an open connection. Some MTAs such as
+Sendmail have a non-shared connection cache. Here, a connection can be reused
+only by the mail delivering process that creates the connection. To get the
+same performance improvement as with a shared connection cache, non-shared
 connections need to be kept open for a longer time.
 
 The scache(8) server, introduced with Postfix version 2.2, maintains the shared
 connection cache. With Postfix version 2.2, only the smtp(8) client has support
 to access this cache.
 
-            /-- smtp(8) --> Internet
-
-    qmgr(8)       |  
-                  |
-            \--   | smtp(8) --> Internet
-                  |
-                  ^          
-                  |
-
-                  scache(8)
-
 When SMTP connection caching is enabled (see next section), the smtp(8) client
 does not disconnect after a mail transaction, but gives the connection to the
 scache(8) server which keeps the connection open for a limited amount of time.
@@ -82,10 +78,42 @@ client continues with some other mail delivery request. Meanwhile, any smtp(8)
 client process can ask the scache(8) server for that cached connection and
 reuse it for mail delivery.
 
+            /--  smtp(8)  --> Internet
+
+    qmgr(8)
+                |
+            \-- |    smtp(8)
+                |
+                |     ^
+                v     |
+
+                scache(8)
+
+With TLS connection reuse (Postfix 3.4 and later), the Postfix smtp(8) client
+connects to a remote SMTP server and sends plaintext EHLO and STARTTLS
+commands, then inserts a tlsproxy(8) process into the connection as shown
+below.
+
+After delivering mail, the smtp(8) client hands over the open smtp(8)-to-
+tlsproxy(8) connection to the scache(8) server, and continues with some other
+mail delivery request. Meanwhile, any smtp(8) client process can ask the scache
+(8) server for that cached connection and reuse it for mail delivery.
+
+            /--  smtp(8)  --> tlsproxy(8) --> Internet
+
+    qmgr(8)
+                |
+            \-- |    smtp(8)
+                |
+                |     ^
+                v     |
+
+                scache(8)
+
 The connection cache can be searched by destination domain name (the right-hand
 side of the recipient address) and by the IP address of the host at the other
 end of the connection. This allows Postfix to reuse a connection even when the
-remote host is mail server for domains with different names.
+remote host is a mail server for domains with different names.
 
 CCoonnnneeccttiioonn ccaacchhee ccoonnffiigguurraattiioonn
 
@@ -131,6 +159,9 @@ The Postfix smtp(8) client supports two connection caching strategies:
             smtp_connection_cache_destinations = hotmail.com, ...
             smtp_connection_cache_destinations = static:all (not recommended)
 
+    See Client-side TLS connection reuse to enable multiple deliveries over a
+    TLS-encrypted connection (Postfix version 3.4 and later).
+
 CCoonnnneeccttiioonn ccaacchhee ssaaffeettyy mmeecchhaanniissmmss
 
 Connection caching must be used wisely. It is anti-social to keep an unused
@@ -156,7 +187,6 @@ mechanisms:
     MTAs, the slowest inbound MTA will attract most connections from Postfix to
     that destination).
 
-    .
     Postfix 2.3 logs the use count of multiply-used connections, as shown in
     the following example:
 
@@ -174,12 +204,11 @@ CCoonnnneeccttiioonn ccaacchhee lliimmiittaattiioonnss
 
 Postfix SMTP connection caching conflicts with certain applications:
 
-  * The Postfix shared connection cache cannot be used with TLS, because saved
-    TLS session information can be used only when a new connection is created
-    (this limitation does not exist in connection caching implementations that
-    reuse a connection only in the process that creates it). For this reason,
-    the Postfix smtp(8) client always closes the connection after completing an
-    attempt to deliver mail over TLS.
+  * With Postfix versions < 3.4, the Postfix shared connection cache cannot be
+    used with TLS, because an open TLS connection can be reused only in the
+    process that creates it. For this reason, the Postfix smtp(8) client
+    historically always closed the connection after completing an attempt to
+    deliver mail over TLS.
 
   * Postfix connection caching currently does not support multiple SASL
     accounts per mail server. Specifically, Postfix connection caching assumes

postfix/README_FILES/CONTENT_INSPECTION_README

@@ -51,6 +51,6 @@ good reasons: writing an MTA requires different skills than writing a SPAM or
 virus killer. Postfix encourages the use of external filters and standard
 protocols because this allows you to choose the best MTA and the best content
 inspection software for your purpose. Information about external content
-inspection software can be found on the Postfix website at http://
+inspection software can be found on the Postfix website at https://
 www.postfix.org/, and on the postfix-users@postfix.org mailing list.
 

postfix/README_FILES/CYRUS_README

@@ -1,5 +0,0 @@
-PPoossttffiixx CCyyrruuss HHoowwttoo
-
--------------------------------------------------------------------------------
-This document will be made available via http://www.postfix.org/.
-

postfix/README_FILES/DATABASE_README

@@ -28,7 +28,7 @@ Examples of lookup tables that appear often in the Postfix documentation:
         alias_maps = hash:/etc/postfix/aliases            (local aliasing)
         header_checks = regexp:/etc/postfix/header_checks (content filtering)
         transport_maps = hash:/etc/postfix/transport      (routing table)
-        virtual_alias_maps = hash:/etc/postfix/virtual    (address rewriting)
+        virtual_alias_maps = hash:/etc/postfix/virtual    (virtual aliasing)
 
 All Postfix lookup tables store information as (key, value) pairs. This
 interface may seem simplistic at first, but it turns out to be very powerful.
@@ -58,7 +58,7 @@ With some tables, however, Postfix needs to know only if the lookup key exists.
 Any non-empty lookup result value may be used here: the lookup result is not
 used. Examples are the local_recipient_maps that determine what local
 recipients Postfix accepts in mail from the network, the mydestination
-parameter that specifies what domains Postfix delivers locally, or the
+parameter that specifies what domains Postfix delivers locally for, or the
 mynetworks parameter that specifies the IP addresses of trusted clients or
 client networks. Technically, these are lists, not tables. Despite the
 difference, Postfix lists are described here because they use the same
@@ -200,6 +200,15 @@ To find out what database types your Postfix system supports, use the "ppooss
         databases are maintained by Postfix daemons. The lookup table name as
         used in "dbm:table" is the database file name without the ".dir" or
         ".pag" suffix.
+    ddeebbuugg
+        An adapter for another table that causes all accesses to be logged.
+        Example usage: "debug:hash:/etc/postfix/example". The formats of the
+        log messages are unspecified and subject to change. Warning: If a query
+        or the underlying table contains sensitive information (such as a
+        password), that information might be logged.
+
+        This feature is available with Postfix 3.11 and later.
+
     eennvviirroonn
         The UNIX process environment array. The lookup key is the variable
         name. The lookup table name in "environ:table" is ignored.
@@ -215,12 +224,14 @@ To find out what database types your Postfix system supports, use the "ppooss
     iinnlliinnee (read-only)
         A non-shared, in-memory lookup table. Example: "inline:{ key=value,
         { key = text with whitespace or comma }}". Key-value pairs are
-        separated by whitespace or comma; whitespace after "{" and before "}"
-        is ignored. Inline tables eliminate the need to create a database file
-        for just a few fixed elements. See also the static: map type.
+        separated by whitespace or comma; with a key-value pair inside "{}",
+        whitespace is ignored after the opening "{", around the "=" between key
+        and value, and before the closing "}". Inline tables eliminate the need
+        to create a database file for just a few fixed elements. See also the
+        static: map type.
     iinntteerrnnaall
-        A non-shared, in-memory hash table. Its content are lost when a process
-        terminates.
+        A non-shared, in-memory hash table. Its contents are lost when a
+        process terminates.
     llmmddbb
         OpenLDAP LMDB database. This is available only on systems with support
         for LMDB databases. Public database files are created with the postmap
@@ -234,6 +245,9 @@ To find out what database types your Postfix system supports, use the "ppooss
     mmeemmccaacchhee
         Memcache database client. Configuration details are given in
         memcache_table(5).
+    mmoonnggooddbb (read-only)
+        MongoDB database client. Configuration details are given in
+        mongodb_table(5), with examples in MONGODB_README.
     mmyyssqqll (read-only)
         MySQL database client. Configuration details are given in mysql_table
         (5).
@@ -267,7 +281,8 @@ To find out what database types your Postfix system supports, use the "ppooss
         {result1. ..., resultn}". Each table query returns a random choice from
         the specified results. The first and last characters of the "randmap:
         " table name must be "{" and "}". Within these, individual maps are
-        separated with comma or whitespace.
+        separated with comma or whitespace. To give a specific result more
+        weight, specify it multiple times.
     rreeggeexxpp (read-only)
         A lookup table based on regular expressions. The file format is
         described in regexp_table(5). The lookup table name as used in "regexp:
@@ -289,8 +304,8 @@ To find out what database types your Postfix system supports, use the "ppooss
         A table that always returns its name as the lookup result. For example,
         "static:foobar" always returns the string "foobar" as lookup result.
         Specify "static:{ text with whitespace }" when the result contains
-        whitespace; this form ignores whitespace after "{" and before "}". See
-        also the inline: map type.
+        whitespace; this form ignores whitespace after the opening "{" and
+        before the closing "}". See also the inline: map type.
     ttccpp
         TCP/IP client. The protocol is described in tcp_table(5). The lookup
         table name is "tcp:host:port" where "host" specifies a symbolic

postfix/README_FILES/DB_README

@@ -45,7 +45,8 @@ BBuuiillddiinngg PPoossttffiixx oonn ssyysstteemmss tth
 Some UNIXes ship without Berkeley DB support; for historical reasons these use
 DBM files instead. A problem with DBM files is that they can store only limited
 amounts of data. To build Postfix with Berkeley DB support you need to download
-and install the source code from http://www.oracle.com/database/berkeley-db/.
+and install the source code from https://www.oracle.com/database/technologies/
+related/berkeleydb.html.
 
 Warning: some Linux system libraries use Berkeley DB, as do some third-party
 libraries such as SASL. If you compile Postfix with a different Berkeley DB
@@ -65,6 +66,9 @@ something like:
         AUXLIBS="-L/usr/local/BerkeleyDB/lib -ldb"
     % make
 
+If your Berkeley DB shared library is in a directory that the RUN-TIME linker
+does not know about, add a "-Wl,-R,/path/to/directory" option after "-ldb".
+
 Solaris needs this:
 
     % make makefiles CCARGS="-DHAS_DB -I/usr/local/BerkeleyDB/include" \
@@ -166,5 +170,6 @@ Add the "-lpthread" library to the "make makefiles" command.
 
     % make makefiles .... AUXLIBS="... -lpthread"
 
-More information is available at http://www.oracle.com/database/berkeley-db/.
+More information is available at https://www.oracle.com/database/technologies/
+related/berkeleydb.html.
 

postfix/README_FILES/DEBUG_README

@@ -33,14 +33,20 @@ follows:
 
 LLooookk ffoorr oobbvviioouuss ssiiggnnss ooff ttrroouubbllee
 
-Postfix logs all failed and successful deliveries to a logfile. The file is
-usually called /var/log/maillog or /var/log/mail; the exact pathname is defined
-in the /etc/syslog.conf file.
+Postfix logs all failed and successful deliveries to a logfile.
+
+  * When Postfix uses syslog logging (the default), the file is usually called
+    /var/log/maillog, /var/log/mail, or something similar; the exact pathname
+    is configured in a file called /etc/syslog.conf, /etc/rsyslog.conf, or
+    something similar.
+
+  * When Postfix uses its own logging system (see MAILLOG_README), the location
+    of the logfile is configured with the Postfix maillog_file parameter.
 
 When Postfix does not receive or deliver mail, the first order of business is
 to look for errors that prevent Postfix from working properly:
 
-    % eeggrreepp ''((wwaarrnniinngg||eerrrroorr||ffaattaall||ppaanniicc))::'' //ssoommee//lloogg//ffiillee || mmoorree
+    % ggrreepp --EE ''((wwaarrnniinngg||eerrrroorr||ffaattaall||ppaanniicc))::'' //ssoommee//lloogg//ffiillee || mmoorree
 
 Note: the most important message is near the BEGINNING of the output. Error
 messages that come later are less useful.
@@ -380,12 +386,12 @@ When reporting a problem, be sure to include the following information.
 
       o "ppoossttccoonnff --MMff" (Postfix 2.9 or later).
 
-  * Better, provide output from the ppoossttffiinnggeerr tool. This can be found at http:
-    //ftp.wl0.org/SOURCES/postfinger.
+  * Better, provide output from the ppoossttffiinnggeerr tool. This can be found at
+    https://github.com/ford--prefect/postfinger.
 
   * If the problem is SASL related, consider including the output from the
-    ssaassllffiinnggeerr tool. This can be found at http://postfix.state-of-mind.de/
-    patrick.koetter/saslfinger/.
+    ssaassllffiinnggeerr tool. This can be found at https://packages.debian.org/
+    search?keywords=sasl2-bin.
 
   * If the problem is about too much mail in the queue, consider including
     output from the qqsshhaappee tool, as described in the QSHAPE_README file.

postfix/README_FILES/DEPRECATION_README

@@ -0,0 +1,299 @@
+PPoossttffiixx RReeppllaacceemmeennttss ffoorr DDeepprreeccaatteedd FFeeaattuurreess
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document describes Postfix features that are deprecated (will be removed)
+or that have already been removed. It also has tips for making an existing
+Postfix configuration more future-proof.
+
+Overview:
+
+  * Why deprecate?
+  * Deprecation process
+  * Deprecated features
+
+WWhhyy ddeepprreeccaattee??
+
+Sometimes, a Postfix feature needs to be replaced with a different one. To give
+an example:
+
+  * The initial Postfix TLS implementation used multiple boolean parameters:
+    one parameter to enable opportunistic TLS (for example, "smtp_enforce_tls =
+    yes") and one parameter to enable mandatory TLS (for example,
+    "smtp_require_tls = yes").
+
+  * As we added support more features such as fingerprint, dane, and so on, we
+    decided not to add more boolean parameters. Instead we introduced one
+    configuration parameter to select from multiple deployment models (for
+    example, smtp_tls_security_level = may | encrypt | dane, etc...).
+
+Having both the "old" and "new" way to configure Postfix is convenient for
+existing Postfix installations, because their configuration does not break
+after an upgrade to a new version. Unfortunately, there are also disadvantages.
+Having multiple ways to do similar things is not only confusing for newcomers,
+it also makes Postfix harder to change.
+
+DDeepprreeccaattiioonn pprroocceessss
+
+The basic process steps are:
+
+ 1. Inform humans that a feature will be removed, and suggest replacements, in
+    logging and documentation.
+
+ 2. Remove the feature, and update logging and documentation.
+
+Disclaimer: it has taken 20 years for some features to be removed. This past is
+not a guarantee for the future.
+
+DDeepprreeccaatteedd ffeeaattuurreess
+
+The table summarizes removed or deprecated features and replacements. Click on
+the "obsolete feature" name for a more detailed description.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |                           |WWaarrnniinngg|          |                         |
+    |OObbssoolleettee ffeeaattuurree nnaammee      |aass     |RReemmoovveedd   |RReeppllaacceemmeenntt              |
+    |                           |ooff     |iinn vveerrssiioonn|                         |
+    |                           |vveerrssiioonn|          |                         |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |xxx_tls_enforce_peername   |  3.11 |      -   |xxx_tls_security_level   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |disable_dns_lookups        |   3.9 |      -   |smtp_dns_support_level   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |xxx_use_tls                |   3.9 |      -   |xxx_tls_security_level   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |xxx_enforce_tls            |   3.9 |      -   |xxx_tls_security_level   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |xxx_per_site               |   3.9 |      -   |xxx_policy_maps          |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |smtpd_tls_dh1024_param_file|   3.9 |      -   |do not specify (leave at |
+    |                           |       |          |default)                 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |smtpd_tls_eecdh_grade      |   3.9 |      -   |do not specify (leave at |
+    |                           |       |          |default)                 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |permit_mx_backup           |   3.9 |      -   |relay_domains            |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |check_relay_domains        |   2.2 |     3.9  |permit_mynetworks,       |
+    |                           |       |          |reject_unauth_destination|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |reject_maps_rbl            |   2.1 |     3.9  |reject_rbl_client        |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |permit_naked_ip_address    |   2.0 |     3.9  |permit_mynetworks,       |
+    |                           |       |          |permit_sasl_authenticated|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+OObbssoolleettee TTLLSS ppeeeerr nnaammee mmaattcchh ccoonnffiigguurraattiioonn
+
+The postconf(1) command logs one of the following:
+
+  * support for parameter "lmtp_tls_enforce_peername" will be removed; instead,
+    specify "lmtp_tls_security_level"
+  * support for parameter "smtp_tls_enforce_peername" will be removed; instead,
+    specify "smtp_tls_security_level"
+
+There are similarly-named parameters and warnings for postscreen(8) and
+tlsproxy(8), but those parameters should rarely be specified by hand.
+
+Replace obsolete configuration with its replacement:
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |GGooaall                   |OObbssoolleettee ccoonnffiigguurraattiioonn|RReeppllaacceemmeenntt ccoonnffiigguurraattiioonn|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |                       |                      |xxx_security_level =     |
+    |Enforce peer name match|xxx_enforce_peername =|verify                   |
+    |with server certificate|yes                   |xxx_security_level =     |
+    |                       |                      |secure                   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Disable peer name match|xxx_enforce_peername =|xxx_security_level = may |
+    |with server certificate|no                    |xxx_security_level =     |
+    |                       |                      |encrypt                  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+OObbssoolleettee DDNNSS oonn//ooffff ccoonnffiigguurraattiioonn
+
+The postconf(1) command logs the following:
+
+  * support for parameter "disable_dns_lookups" will be removed; instead,
+    specify "smtp_dns_support_level"
+
+Replace obsolete configuration with its replacement:
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |GGooaall                  |OObbssoolleettee ccoonnffiigguurraattiioonn  |RReeppllaacceemmeenntt             |
+    |                      |                        |ccoonnffiigguurraattiioonn           |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |To disable DNS lookups|disable_dns_lookups =   |smtp_dns_support_level =|
+    |in the Postfix SMTP/  |yes                     |disabled                |
+    |LMTP client           |                        |                        |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |                      |                        |Leave                   |
+    |                      |                        |smtp_dns_support_level  |
+    |To enable DNS lookups |                        |at the implicit default |
+    |in the Postfix SMTP/  |disable_dns_lookups = no|which is empty, unless  |
+    |LMTP client           |                        |you need a higher       |
+    |                      |                        |support level such as   |
+    |                      |                        |DNSSEC.                 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+OObbssoolleettee ooppppoorrttuunniissttiicc TTLLSS ccoonnffiigguurraattiioonn
+
+The postconf(1) command logs one of the following:
+
+  * support for parameter "lmtp_use_tls" will be removed; instead, specify
+    "lmtp_tls_security_level"
+  * support for parameter "smtp_use_tls" will be removed; instead, specify
+    "smtp_tls_security_level"
+  * support for parameter "smtpd_use_tls" will be removed; instead, specify
+    "smtpd_tls_security_level"
+
+There are similarly-named parameters and warnings for postscreen(8) and
+tlsproxy(8), but those parameters should rarely be specified by hand.
+
+Replace obsolete configuration with its replacement:
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |GGooaall                    |OObbssoolleettee ccoonnffiigguurraattiioonn|RReeppllaacceemmeenntt ccoonnffiigguurraattiioonn|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |To turn off TLS         |xxx_use_tls = no      |xxx_security_level = none|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |To turn on opportunistic|xxx_use_tls = yes     |xxx_security_level = may |
+    |TLS                     |                      |                         |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+OObbssoolleettee mmaannddaattoorryy TTLLSS ccoonnffiigguurraattiioonn
+
+The postconf(1) command logs one of the following:
+
+  * support for parameter "lmtp_enforce_tls" will be removed; instead, specify
+    "lmtp_tls_security_level"
+  * support for parameter "smtp_enforce_tls" will be removed; instead, specify
+    "smtp_tls_security_level"
+  * support for parameter "smtpd_enforce_tls" will be removed; instead, specify
+    "smtpd_tls_security_level"
+
+There are similarly-named parameters and warnings for postscreen(8) and
+tlsproxy(8), but those parameters should rarely be specified by hand.
+
+Replace obsolete configuration with its replacement:
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |GGooaall                    |OObbssoolleettee ccoonnffiigguurraattiioonn|RReeppllaacceemmeenntt ccoonnffiigguurraattiioonn|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |To turn off mandatory   |xxx_enforce_tls = no  |xxx_security_level = may |
+    |TLS                     |                      |                         |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |To turn on mandatory TLS|xxx_enforce_tls = yes |xxx_security_level =     |
+    |                        |                      |encrypt                  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+OObbssoolleettee TTLLSS ppoolliiccyy ttaabbllee ccoonnffiigguurraattiioonn
+
+The postconf(1) command logs one of the following:
+
+  * support for parameter "lmtp_tls_per_site" will be removed; instead, specify
+    "lmtp_tls_policy_maps"
+  * support for parameter "smtp_tls_per_site" will be removed; instead, specify
+    "smtp_tls_policy_maps"
+
+There is similarly-named parameter and warning for tlsproxy(8), but that
+parameter should rarely be specified by hand.
+
+Unfortunately, this is more than a name change: the table format has changed
+too, as has the table search process. There is no simple conversion of the
+obsolete form to its replacement.
+
+cchheecckk__rreellaayy__ddoommaaiinnss
+
+Depending on the Postfix version, the Postfix SMTP daemon logs following
+warning:
+
+  * support for restriction "check_relay_domains" has been removed in Postfix
+    3.9"; instead, specify "reject_unauth_destination"
+  * support for restriction "check_relay_domains" will be removed from Postfix;
+    use "reject_unauth_destination" instead
+
+This feature was removed because it would relay based on the client domain
+name, which is not robust.
+
+Recommended configuration to prevent an "open relay" problem with the SMTP
+service on port 25:
+
+    main.cf:
+        smtpd_recipient_restrictions =
+            permit_mynetworks,
+            permit_sasl_authenticated,
+            reject_unauth_destination
+            ...other restrictions...
+
+Or equivalent in smtpd_relay_restrictions.
+
+ppeerrmmiitt__mmxx__bbaacckkuupp
+
+The Postfix version 3.9 and later SMTP daemon logs the following warning:
+
+  * support for restriction "permit_mx_backup" will be removed from Postfix;
+    instead, specify "relay_domains"
+
+This feature will be removed because it is too difficult to configure recipient
+address validation, making Postfix a source of backscatter bounces.
+
+To specify the domains that Postfix will provide MX backup service for, see
+Configuring Postfix as primary or backup MX host for a remote site.
+
+rreejjeecctt__mmaappss__rrbbll
+
+Depending on the Postfix version, the SMTP daemon logs one of the following
+warnings:
+
+  * support for restriction "reject_maps_rbl" has been removed in Postfix 3.9";
+    instead, specify "reject_rbl_client domain-name"
+  * support for restriction "reject_maps_rbl" will be removed from Postfix; use
+    "reject_rbl_client domain-name" instead
+
+This feature was replaced because "MAPS RBL" is the name of a specific
+reputation service. The reject_rbl_client feature provides a superset of the
+reject_maps_rbl functionality.
+
+Recommended configuration:
+
+    main.cf:
+        smtpd_recipient_restrictions =
+            permit_mynetworks,
+            permit_sasl_authenticated,
+            reject_unauth_destination
+            reject_rbl_client domain-name
+            ...other restrictions...
+
+Where domain-name is the domain name of a DNS reputation service.
+
+ppeerrmmiitt__nnaakkeedd__iipp__aaddddrreessss
+
+Depending on the Postfix version, the SMTP daemon logs one of the following
+warnings:
+
+  * support for restriction "permit_naked_ip_address" has been removed in
+    Postfix 3.9"; instead, specify "permit_mynetworks" or
+    "permit_sasl_authenticated"
+  * restriction permit_naked_ip_address is deprecated. Use permit_mynetworks or
+    permit_sasl_authenticated instead
+
+This feature was removed because it was easy to get a false match when
+smtpd_recipient_restrictions was intended to match a remote SMTP client IP
+address.
+
+Recommended configuration:
+
+    main.cf:
+        smtpd_recipient_restrictions =
+            permit_mynetworks,
+            permit_sasl_authenticated,
+            reject_unauth_destination
+            reject_rbl_client domain-name
+            ...other restrictions...
+
+That is, no restriction on HELO or EHLO syntax. Such restrictions ar rarely
+useful nowadays.
+

postfix/README_FILES/FILTER_README

@@ -282,8 +282,8 @@ This content filter receives unfiltered mail with SMTP on localhost port 10025,
 and sends filtered mail back into Postfix with SMTP on localhost port 10026.
 
 For non-SMTP capable content filtering software, Bennett Todd's SMTP proxy
-implements a nice PERL/SMTP content filtering framework. See: http://
-bent.latency.net/smtpprox/.
+implements a nice PERL/SMTP content filtering framework. See: https://
+web.archive.org/web/20151022025756/http://bent.latency.net/smtpprox/.
 
 In the figure below, names followed by a number represent Postfix commands or
 daemon programs. See the OVERVIEW document for an introduction to the Postfix

postfix/README_FILES/FORWARD_SECRECY_README

@@ -69,9 +69,7 @@ ignore those here). The client sends a random "pre-master secret" to the server
 encrypted with the server's RSA public key. The server decrypts this with its
 private key, and uses it together with other data exchanged in the clear to
 generate the session key. An attacker with access to the server's private key
-can perform the same computation at any later time. The TLS library in Windows
-XP and Windows Server 2003 only supported cipher suites of this type, and
-Exchange 2003 servers largely do not support forward secrecy.
+can perform the same computation at any later time.
 
 Later revisions to the TLS protocol introduced forward-secrecy cipher suites in
 which the client and server implement a key exchange protocol based on
@@ -83,28 +81,22 @@ designate appropriate "parameters" consisting of a mathematical "group" and an
 element of that group called a "generator". Presently, there are two flavors of
 "groups" that work with PFS:
 
-  * PPrriimmee--ffiieelldd ggrroouuppss ((EEDDHH)):: The server needs to be configured with a
-    suitably-large prime and a corresponding "generator". The acronym for
-    forward secrecy over prime fields is EDH for Ephemeral Diffie-Hellman (also
-    abbreviated as DHE).
+  * FFFFDDHHEE:: Finite-field Diffie-Hellman ephemeral key exchange groups (also EDH
+    or DHE). The server needs to be configured with a suitably-large prime and
+    a corresponding "generator". Standard choices of the prime and generator
+    are specified in RFC7919, and can be used in the TLS 1.3 protocol with the
+    server and client negotiating a mutually supported choice. In earlier
+    versions of TLS (1.0 through 1.2), when FFDHE key exchange is performed,
+    the server chooses the prime and generator unilaterally.
 
-  * EElllliippttiicc--ccuurrvvee ggrroouuppss ((EEEECCDDHH)):: The server needs to be configured with a
-    "named curve". These offer better security at lower computational cost than
-    prime field groups, but are not as widely implemented. The acronym for the
-    elliptic curve version is EECDH which is short for Ephemeral Elliptic Curve
-    Diffie-Hellman (also abbreviated as ECDHE).
-
-It is not essential to know what these are, but one does need to know that
-OpenSSL supports EECDH with version 1.0.0 or later. Thus the configuration
-parameters related to Elliptic-Curve forward secrecy are available when Postfix
-is linked with OpenSSL >= 1.0.0 (provided EC support has not been disabled by
-the vendor, as in some versions of RedHat Linux).
-
-Elliptic curves used in cryptography are typically identified by a "name" that
-stands for a set of well-known parameter values, and it is these "names" (or
-associated ASN.1 object identifiers) that are used in the TLS protocol. On the
-other hand, with TLS there are no specially designated prime field groups, so
-each server is free to select its own suitably-strong prime and generator.
+  * EEEECCDDHH:: This is short for Ephemeral Elliptic Curve Diffie-Hellman (also
+    abbreviated as ECDHE). EECDH offers better security at lower computational
+    cost than FFDHE. Elliptic curves used in cryptography are typically
+    identified by a "name" that stands for a set of well-known parameter
+    values, and it is these "named curves" (or, in certificates, associated
+    ASN.1 object identifiers) that are used in the TLS protocol. When EECDH key
+    exchange is used, a mutually supported named curve is negotiated as part of
+    the TLS handshake.
 
 FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP SSeerrvveerr
 
@@ -113,178 +105,120 @@ configuration. If the remote SMTP client prefers cipher suites with forward
 secrecy, then the traffic between the server and client will resist decryption
 even if the server's long-term authentication keys are later compromised.
 
-Some remote SMTP clients may support forward secrecy, but prefer cipher suites
-without forward secrecy. In that case, Postfix >= 2.8 could be configured to
-ignore the client's preference with the main.cf setting "tls_preempt_cipherlist
-= yes". However, this will likely cause interoperability issues with older
-Exchange servers and is not recommended for now.
+Most remote SMTP clients now support forward secrecy (the only choice as of TLS
+1.3), but some may prefer cipher suites without forward secrecy. Postfix >= 2.8
+servers can be configured to override the client's preference by setting
+"tls_preempt_cipherlist = yes".
 
-EEDDHH SSeerrvveerr ssuuppppoorrtt
+FFFFDDHHEE SSeerrvveerr ssuuppppoorrtt
 
-Postfix >= 2.2 support 1024-bit-prime EDH out of the box, with no additional
-configuration, but you may want to override the default prime to be 2048 bits
-long, and you may want to regenerate your primes periodically. See the quick-
-start section for details. With Postfix >= 3.1 the out of the box (compiled-in)
-EDH prime size is 2048 bits.
+Postfix >= 3.1 supports 2048-bit-prime FFDHE out of the box, with no additional
+configuration. You can also generate your own FFDHE parameters, but this is not
+necessary and no longer recommended. See the quick-start section for details.
 
-With prime-field EDH, OpenSSL wants the server to provide two explicitly-
-selected (prime, generator) combinations. One for the now long-obsolete
-"export" cipher suites, and another for non-export cipher suites. Postfix has
-two such default combinations compiled in, but also supports explicitly-
-configured overrides.
-
-  * The "export" EDH parameters are used only with the obsolete "export"
-    ciphers. To use a non-default prime, generate a 512-bit DH parameter file
-    and set smtpd_tls_dh512_param_file to the filename (see the quick-start
-    section for details). With Postfix releases after the middle of 2015 the
-    default opportunistic TLS cipher grade (smtpd_tls_ciphers) is "medium" or
-    stronger, and export ciphers are no longer used.
-
-  * The non-export EDH parameters are used for all other EDH cipher suites. To
-    use a non-default prime, generate a 1024-bit or 2048-bit DH parameter file
-    and set smtpd_tls_dh1024_param_file to the filename. Despite the name this
-    is simply the non-export parameter file and the prime need not actually be
-    1024 bits long (see the quick-start section for details).
-
-As of mid-2015, SMTP clients are starting to reject TLS handshakes with primes
-smaller than 2048 bits. Each site needs to determine which prime size works
-best for the majority of its clients. See the quick-start section for the
-recommended configuration to work around this issue.
+Postfix >= 3.8 supports the finite-field Diffie-Hellman ephemeral (FFDHE) key
+exchange group negotiation API of OpenSSL >= 3.0. FFDHE groups are explicitly
+negotiated between client and server starting with TLS 1.3. In earlier TLS
+versions, the server chooses the group unilaterally. The list of candidate
+FFDHE groups can be configured via "tls_ffdhe_auto_groups", which can be used
+to select a prioritized list of supported groups (most preferred first) on both
+the server and client. The default list is suitable for most users. Either, but
+not both of "tls_eecdh_auto_curves" and "tls_ffdhe_auto_groups" may be set
+empty, disabling either EC or FFDHE key exchange in OpenSSL 3.0 with TLS 1.3.
+That said, interoperability will be poor if the EC curves are all disabled or
+don't include the most widely used curves.
 
 EEEECCDDHH SSeerrvveerr ssuuppppoorrtt
 
-Postfix >= 2.6 support NIST P-256 EECDH when built with OpenSSL >= 1.0.0. When
-the remote SMTP client also supports EECDH and implements the P-256 curve,
-forward secrecy just works.
-
-    Note: With Postfix 2.6 and 2.7, enable EECDH by setting the main.cf
-    parameter smtpd_tls_eecdh_grade to "strong".
-
-The elliptic curve standards are evolving, with new curves introduced in RFC
-8031 to augment or replace the NIST curves tarnished by the Snowden
-revelations. Fortunately, TLS clients advertise their list of supported curves
-to the server so that servers can choose newer stronger curves when mutually
-supported. OpenSSL 1.0.2 released in January 2015 was the first release to
-implement negotiation of supported curves in TLS servers. In older OpenSSL
-releases, the server is limited to selecting a single widely supported curve.
-
-With Postfix prior to 3.2 or OpenSSL prior to 1.0.2, only a single server-side
-curve can be configured, by specifying a suitable EECDH "grade":
-
-        smtpd_tls_eecdh_grade = strong | ultra
-        # Underlying curves, best not changed:
-        # tls_eecdh_strong_curve = prime256v1
-        # tls_eecdh_ultra_curve = secp384r1
-
-Postfix >= 3.2 supports the curve negotiation API of OpenSSL >= 1.0.2. When
-using this software combination, the default setting of "smtpd_tls_eecdh_grade"
-changes to "auto", which selects a curve that is supported by both the server
-and client. The list of candidate curves can be configured via
-"tls_eecdh_auto_curves", which can be used to configure a prioritized list of
-supported curves (most preferred first) on both the server and client. The
-default list is suitable for most users.
+As of Postfix 3.2 and OpenSSL 1.0.2, a range of supported EECDH curves is
+enabled in the server and client, and a suitable mutually supported curve is
+negotiated as part of the TLS handshake. The list of supported curves is
+configurable via the "tls_eecdh_auto_curves" parameter. With TLS 1.2 the server
+needs to leave its setting of "smtpd_tls_eecdh_grade" at the default value of
+"auto" (earlier choices of an explicit single curve grade are deprecated). With
+TLS 1.3, the "smtpd_tls_eecdh_grade" parameter is not used, and curve selection
+is unconditionally negotiated.
 
 FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP CClliieenntt
 
 The Postfix >= 2.2 SMTP client supports forward secrecy in its default
-configuration. All supported OpenSSL releases support EDH key exchange. OpenSSL
-releases >= 1.0.0 also support EECDH key exchange (provided elliptic-curve
-support has not been disabled by the vendor as in some versions of RedHat
-Linux). If the remote SMTP server supports cipher suites with forward secrecy
+configuration. All supported OpenSSL releases support both FFDHE and EECDH key
+exchange. If the remote SMTP server supports cipher suites with forward secrecy
 (and does not override the SMTP client's cipher preference), then the traffic
 between the server and client will resist decryption even if the server's long-
-term authentication keys are later compromised.
+term authentication keys are later compromised. Forward secrecy is always on in
+TLS 1.3.
 
-Postfix >= 3.2 supports the curve negotitation API of OpenSSL >= 1.0.2. The
-list of candidate curves can be changed via the "tls_eecdh_auto_curves"
+Postfix >= 3.2 supports the curve negotiation API of OpenSSL >= 1.0.2. The list
+of candidate curves can be changed via the "tls_eecdh_auto_curves"
 configuration parameter, which can be used to select a prioritized list of
 supported curves (most preferred first) on both the Postfix SMTP server and
 SMTP client. The default list is suitable for most users.
 
-The default Postfix SMTP client cipher lists are correctly ordered to prefer
-EECDH and EDH cipher suites ahead of similar cipher suites that don't implement
-forward secrecy. Administrators are strongly discouraged from changing the
-cipher list definitions.
+Postfix >= 3.8 supports the finite-field Diffie-Hellman ephemeral (FFDHE) key
+exchange group negotiation API of OpenSSL >= 3.0. The list of candidate FFDHE
+groups can be configured via "tls_ffdhe_auto_groups", which can be used to
+select a prioritized list of supported groups (most preferred first) on both
+the server and client. The default list is suitable for most users.
 
-The default minimum cipher grade for opportunistic TLS is "medium" for Postfix
-releases after the middle of 2015, "export" for older releases. Changing the
-minimum cipher grade does not change the cipher preference order. Note that
-cipher grades higher than "medium" exclude Exchange 2003 and likely other MTAs,
-thus a "high" cipher grade should be chosen only on a case-by-case basis via
-the TLS policy table.
+The default Postfix SMTP client cipher lists are correctly ordered to prefer
+EECDH and FFDHE cipher suites ahead of similar cipher suites that don't
+implement forward secrecy. Administrators are strongly discouraged from
+changing the cipher list definitions.
 
 GGeettttiinngg ssttaarrtteedd,, qquuiicckk aanndd ddiirrttyy
 
-EEEECCDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 22..22 wwiitthh OOppeennSSSSLL >>== 11..00..00))
+EEEECCDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 33..22 wwiitthh OOppeennSSSSLL >>== 11..11..11))
 
 This works "out of the box" with no need for additional configuration.
 
-Postfix >= 3.2 supports the curve negotitation API of OpenSSL >= 1.0.2. The
-list of candidate curves can be changed via the "tls_eecdh_auto_curves"
+Postfix >= 3.2 supports the curve negotiation API of OpenSSL >= 1.0.2. The list
+of candidate curves can be changed via the "tls_eecdh_auto_curves"
 configuration parameter, which can be used to select a prioritized list of
 supported curves (most preferred first) on both the Postfix SMTP server and
 SMTP client. The default list is suitable for most users.
 
-EEEECCDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..66 wwiitthh OOppeennSSSSLL >>== 11..00..00))
+EEEECCDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 33..22 wwiitthh OOppeennSSSSLL >>== 11..11..11))
 
-With Postfix 2.6 and 2.7, enable elliptic-curve support in the Postfix SMTP
-server. This is the default with Postfix >= 2.8. Note, however, that elliptic-
-curve support may be disabled by the vendor, as in some versions of RedHat
-Linux.
+This works "out of the box" with no need for additional configuration.
 
-    /etc/postfix/main.cf:
-        # Postfix 2.6 & 2.7 only. EECDH is on by default with Postfix >= 2.8.
-        # The default grade is "auto" with Postfix >= 3.2.
-        smtpd_tls_eecdh_grade = strong
+Postfix >= 3.2 supports the curve negotiation API of OpenSSL >= 1.0.2. The list
+of candidate curves can be changed via the "tls_eecdh_auto_curves"
+configuration parameter, which can be used to select a prioritized list of
+supported curves (most preferred first) on both the Postfix SMTP server and
+SMTP client. The default list is suitable for most users.
 
-EEDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss))
+FFFFDDHHEE CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 33..22,, OOppeennSSSSLL >>== 11..11..11))
 
-This works "out of the box" without additional configuration.
+In Postfix < 3.8, or OpenSSL prior to 3.0, FFDHE for TLS 1.2 or below works
+"out of the box", no additional configuration is necessary. The most one can do
+is (not advisable) disable all "kDHE" ciphers, which would then disable FFDHE
+key exchange in TLS 1.2 and below.
 
-EEDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss))
+With OpenSSL 1.1.1, FFDHE is not supported for TLS 1.3, which uses only EECDH
+key exchange. Support for FFDHE with TLS 1.3 was added in OpenSSL 3.0. With
+OpenSSL 3.0 and Postfix 3.8 the list of supported TLS 1.3 FFDHE groups becomes
+configurable via the "tls_ffdhe_auto_groups" parameter, which can be set empty
+to disable FFDHE in TLS 1.3, or conversely expanded to support more groups. The
+default should work well for most users.
 
-Optionally generate non-default Postfix SMTP server EDH parameters for improved
-security against pre-computation attacks and for compatibility with Debian-
-patched Exim SMTP clients that require a >= 2048-bit length for the non-export
-prime.
+FFFFDDHHEE SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss))
 
-Execute as root (prime group generation can take a few seconds to a few
-minutes):
+In Postfix < 3.8, or OpenSSL prior to 3.0, FFDHE for TLS 1.2 or below works
+"out of the box", no additional configuration is necessary. One can of course
+(not advisable) disable all "kDHE" ciphers, which would then disable FFDHE key
+exchange in TLS 1.2 and below.
 
-    # cd /etc/postfix
-    # umask 022
-    # openssl dhparam -out dh512.tmp 512 && mv dh512.tmp dh512.pem
-    # openssl dhparam -out dh1024.tmp 1024 && mv dh1024.tmp dh1024.pem
-    # openssl dhparam -out dh2048.tmp 2048 && mv dh2048.tmp dh2048.pem
-    # chmod 644 dh512.pem dh1024.pem dh2048.pem
+The built-in default Postfix FFDHE group is a 2048-bit group as of Postfix 3.1.
+You can optionally generate non-default Postfix SMTP server FFDHE parameters
+for possibly improved security against pre-computation attacks, but this is not
+necessary or recommended. Just leave "smtpd_tls_dh1024_param_file" at its
+default empty value.
 
-The Postfix SMTP server EDH parameter files are not secret, after all these
-parameters are sent to all remote SMTP clients in the clear. Mode 0644 is fine.
-
-You can improve security against pre-computation attacks further by
-regenerating the Postfix SMTP server EDH parameters periodically (an hourly or
-daily cron job running the above commands as root can automate this task).
-
-Once the parameters are in place, update main.cf as follows:
-
-    /etc/postfix/main.cf:
-        smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
-        smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
-
-If some of your MSA clients don't support 2048-bit EDH, you may need to adjust
-the submission entry in master.cf accordingly:
-
-    /etc/postfix/master.cf:
-        submission inet n       -       n       -       -       smtpd
-            # Some submission clients may not yet do 2048-bit EDH, if such
-            # clients use your MSA, configure 1024-bit EDH instead.  However,
-            # as of mid-2015, many submission clients no longer accept primes
-            # with less than 2048-bits.  Each site needs to determine which
-            # type of client is more important to support.
-            -o smtpd_tls_dh1024_param_file=${config_directory}/dh1024.pem
-            -o smtpd_tls_security_level=encrypt
-            -o smtpd_sasl_auth_enable=yes
-            ...
+The set of FFDHE groups enabled for use with TLS 1.3 becomes configurable with
+Postfix >= 3.8 and OpenSSL >= 3.0. The default setting of
+"tls_ffdhe_auto_groups" enables the RFC7919 2048 and 3072-bit groups. If you
+need more security, you should probably be using EECDH.
 
 HHooww ccaann II sseeee tthhaatt aa ccoonnnneeccttiioonn hhaass ffoorrwwaarrdd sseeccrreeccyy??
 
@@ -294,7 +228,8 @@ verification status.
 
   * With "smtp_tls_loglevel = 1" and "smtpd_tls_loglevel = 1", the Postfix SMTP
     client and server will log TLS connection information to the maillog file.
-    The general logfile format is:
+    The general logfile format is shown below. With TLS 1.3 there may be
+    additional properties logged after the cipher name and bits.
 
         postfix/smtp[process-id]: Untrusted TLS connection established
         to host.example.com[192.168.0.2]:25: TLSv1 with cipher cipher-name
@@ -307,7 +242,8 @@ verification status.
   * With "smtpd_tls_received_header = yes", the Postfix SMTP server will record
     TLS connection information in the Received: header in the form of comments
     (text inside parentheses). The general format depends on the
-    smtpd_tls_ask_ccert setting:
+    smtpd_tls_ask_ccert setting. With TLS 1.3 there may be additional
+    properties logged after the cipher name and bits.
 
         Received: from host.example.com (host.example.com [192.168.0.2])
                 (using TLSv1 with cipher cipher-name
@@ -320,6 +256,47 @@ verification status.
                 (actual-key-size/raw-key-size bits))
                 (No client certificate requested)
 
+    TLS 1.3 examples. Some of the new attributes may not appear when not
+    applicable or not available in older versions of the OpenSSL library.
+
+        Received: from localhost (localhost [127.0.0.1])
+                (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
+        bits)
+                 key-exchange X25519 server-signature RSA-PSS (2048 bits)
+        server-digest SHA256)
+                (No client certificate requested)
+
+        Received: from localhost (localhost [127.0.0.1])
+                (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
+        bits)
+                 key-exchange X25519 server-signature RSA-PSS (2048 bits)
+        server-digest SHA256
+                 client-signature ECDSA (P-256) client-digest SHA256)
+                (Client CN "example.org", Issuer "example.org" (not verified))
+
+      o The "key-exchange" attribute records the type of "Diffie-Hellman" group
+        used for key agreement. Possible values include "DHE", "ECDHE",
+        "X25519" and "X448". With "DHE", the bit size of the prime will be
+        reported in parentheses after the algorithm name, with "ECDHE", the
+        curve name.
+
+      o The "server-signature" attribute shows the public key signature
+        algorithm used by the server. With "RSA-PSS", the bit size of the
+        modulus will be reported in parentheses. With "ECDSA", the curve name.
+        If, for example, the server has both an RSA and an ECDSA private key
+        and certificate, it will be possible to track which one was used for a
+        given connection.
+
+      o The new "server-digest" attribute records the digest algorithm used by
+        the server to prepare handshake messages for signing. The Ed25519 and
+        Ed448 signature algorithms do not make use of such a digest, so no
+        "server-digest" will be shown for these signature algorithms.
+
+      o When a client certificate is requested with "smtpd_tls_ask_ccert" and
+        the client uses a TLS client-certificate, the "client-signature" and
+        "client-digest" attributes will record the corresponding properties of
+        the client's TLS handshake signature.
+
 The next sections will explain what cipher-name, key-size, and peer
 verification status information to expect.
 
@@ -358,9 +335,68 @@ with one of these prefixes. This pattern is likely to persist until some new
 key-exchange mechanism is invented that also supports forward secrecy.
 
 The actual key length and raw algorithm key length are generally the same with
-non-export ciphers, but may they differ for the legacy export ciphers where the
+non-export ciphers, but they may differ for the legacy export ciphers where the
 actual key is artificially shortened.
 
+Starting with TLS 1.3 the cipher name no longer contains enough information to
+determine which forward-secrecy scheme was employed, but TLS 1.3 aallwwaayyss uses
+forward-secrecy. On the client side, up-to-date Postfix releases log additional
+information for TLS 1.3 connections, reporting the signature and key exchange
+algorithms. Two examples below (the long single line messages are folded across
+multiple lines for readability):
+
+    postfix/smtp[process-id]:
+      Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
+      TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+      key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
+    SHA256
+      client-signature ECDSA (P-256) client-digest SHA256
+
+    postfix/smtp[process-id]:
+      Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
+      TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+      key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest
+    SHA256
+
+In the above connections, the "key-exchange" value records the "Diffie-Hellman"
+algorithm used for key agreement. The "server-signature" value records the
+public key algorithm used by the server to sign the key exchange. The "server-
+digest" value records any hash algorithm used to prepare the data for signing.
+With "ED25519" and "ED448", no separate hash algorithm is used.
+
+Examples of Postfix SMTP server logging:
+
+    postfix/smtpd[process-id]:
+      Untrusted TLS connection established from localhost[127.0.0.1]:25:
+      TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+      key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
+    SHA256
+      client-signature ECDSA (P-256) client-digest SHA256
+
+    postfix/smtpd[process-id]:
+      Anonymous TLS connection established from localhost[127.0.0.1]:
+      TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+      server-signature RSA-PSS (2048 bits) server-digest SHA256
+
+    postfix/smtpd[process-id]:
+      Anonymous TLS connection established from localhost[127.0.0.1]:
+      TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+      server-signature ED25519
+
+Note that Postfix >= 3.4 server logging may also include a "to sni-name"
+element to record the use of an alternate server certificate chain for the
+connection in question. This happens when the client uses the TLS SNI
+extension, and the server selects a non-default certificate chain based on the
+client's SNI value:
+
+    postfix/smtpd[process-id]:
+      Untrusted TLS connection established from client.example[192.0.2.1]
+      to server.example: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
+    bits)
+      key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
+    SHA256
+      client-signature ECDSA (P-256) client-digest SHA256
+
 WWhhaatt ddoo ""AAnnoonnyymmoouuss"",, ""UUnnttrruusstteedd"",, eettcc.. iinn PPoossttffiixx llooggggiinngg mmeeaann??
 
 The verification levels below are subject to man-in-the-middle attacks to

postfix/README_FILES/INSTALL

@@ -331,7 +331,7 @@ install" or "make upgrade".
     # make upgrade meta_directory=/usr/libexec/postfix ...
     # make install meta_directory=/usr/libexec/postfix ...
 
-As with the command "make makefiles, the command "make install/upgrade
+As with the command "make makefiles", the command "make install/upgrade
 name=value..." will replace the string MAIL_VERSION at the end of a
 configuration parameter value with the Postfix release version. Do not try to
 specify something like $mail_version on this command line. This produces
@@ -376,27 +376,29 @@ whistles. Support for third-party databases etc. must be configured when
 Postfix is compiled. The following documents describe how to build Postfix with
 support for optional features:
 
-     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
-    |OOppttiioonnaall ffeeaattuurree                  |DDooccuummeenntt     |AAvvaaiillaabbiilliittyy|
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |Berkeley DB database              |DB_README    |Postfix 1.0 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |LMDB database                     |LMDB_README  |Postfix 2.11|
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |LDAP database                     |LDAP_README  |Postfix 1.0 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |MySQL database                    |MYSQL_README |Postfix 1.0 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |Perl compatible regular expression|PCRE_README  |Postfix 1.0 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |PostgreSQL database               |PGSQL_README |Postfix 2.0 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |SASL authentication               |SASL_README  |Postfix 1.0 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |SQLite database                   |SQLITE_README|Postfix 2.8 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
-    |STARTTLS session encryption       |TLS_README   |Postfix 2.2 |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |OOppttiioonnaall ffeeaattuurree                  |DDooccuummeenntt      |AAvvaaiillaabbiilliittyy|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |Berkeley DB database              |DB_README     |Postfix 1.0 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |LMDB database                     |LMDB_README   |Postfix 2.11|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |LDAP database                     |LDAP_README   |Postfix 1.0 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |MongoDB database                  |MONGODB_README|Postfix 3.9 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |MySQL database                    |MYSQL_README  |Postfix 1.0 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |Perl compatible regular expression|PCRE_README   |Postfix 1.0 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |PostgreSQL database               |PGSQL_README  |Postfix 2.0 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |SASL authentication               |SASL_README   |Postfix 1.0 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |SQLite database                   |SQLITE_README |Postfix 2.8 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |STARTTLS session encryption       |TLS_README    |Postfix 2.2 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
 
 Note: IP version 6 support is compiled into Postfix on operating systems that
 have IPv6 support. See the IPV6_README file for details.
@@ -466,7 +468,7 @@ configuration file, except for one: the parameter that specifies the location
 of Postfix configuration files. In order to build Postfix with a configuration
 directory other than /etc/postfix, use:
 
-    $ make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/some/where\"'
+    $ make makefiles CCARGS="-DDEF_CONFIG_DIR=\\\"/some/where\\\""
     $ make
 
 IMPORTANT: Be sure to get the quotes right. These details matter a lot.
@@ -567,7 +569,7 @@ The following is an extensive list of names and values.
 ||                              |Do not build with IPv6 support. By default,  |
 ||                              |IPv6 support is compiled in on platforms that|
 ||                              |are known to have IPv6 support. Note: this   |
-||-DNO_IPV6                     |directive is for debugging And testing only. |
+||-DNO_IPV6                     |directive is for debugging and testing only. |
 ||                              |It is not guaranteed to work on all          |
 ||                              |platforms. If you don't want IPv6 support,   |
 ||                              |set "inet_protocols = ipv4" in main.cf.      |
@@ -593,6 +595,9 @@ The following is an extensive list of names and values.
 ||-DNO_POSIX_GETPW_R            |getpwuid_r. By default Postfix uses these    |
 ||                              |where they are known to be available.        |
 |_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+||-DNO_RES_NCALLS               |Do not build with the threadsafe resolver(5) |
+||                              |API (res_ninit() etc.).                      |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
 ||                              |Use setjmp()/longjmp() instead of sigsetjmp  |
 ||-DNO_SIGSETJMP                |()/siglongjmp(). By default, Postfix uses    |
 ||                              |sigsetjmp()/siglongjmp() when they are known |
@@ -676,7 +681,7 @@ is successful, then you can proceed to install Postfix (section 6).
 If the command produces compiler error messages, it may be time to search the
 web or to ask the postfix-users@postfix.org mailing list, but be sure to search
 the mailing list archives first. Some mailing list archives are linked from
-http://www.postfix.org/.
+https://www.postfix.org/.
 
 55 -- PPoorrttiinngg PPoossttffiixx ttoo aann uunnssuuppppoorrtteedd ssyysstteemm
 
@@ -826,7 +831,7 @@ and watch your maillog file for any error messages. The pathname is /var/log/
 maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
 pathname is defined in the /etc/syslog.conf file.
 
-    $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+    $ grep -E '(reject|warning|error|fatal|panic):' /some/log/file
 
 Note: the most important error message is logged first. Later messages are not
 as useful.
@@ -876,7 +881,7 @@ and watch your maillog file for any error messages. The pathname is /var/log/
 maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
 pathname is defined in the /etc/syslog.conf file.
 
-    $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+    $ grep -E '(reject|warning|error|fatal|panic):' /some/log/file
 
 Note: the most important error message is logged first. Later messages are not
 as useful.
@@ -916,7 +921,7 @@ and watch your maillog file for any error messages. The pathname is /var/log/
 maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
 pathname is defined in the /etc/syslog.conf file.
 
-    $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+    $ grep -E '(reject|warning|error|fatal|panic):' /some/log/file
 
 Note: the most important error message is logged first. Later messages are not
 as useful.
@@ -1085,6 +1090,7 @@ Finally, build the indexed aliases file with one of the following commands:
 
     # newaliases
     # sendmail -bi
+    # postalias /etc/aliases (pathname is system dependent!)
 
 1111 -- TToo cchhrroooott oorr nnoott ttoo cchhrroooott
 
@@ -1147,7 +1153,7 @@ Hopefully, the number of problems will be small, but it is a good idea to run
 every night before the syslog files are rotated:
 
     # postfix check
-    # egrep '(reject|warning|error|fatal|panic):' /some/log/file
+    # grep -E '(reject|warning|error|fatal|panic):' /some/log/file
 
   * The first line (postfix check) causes Postfix to report file permission/
     ownership discrepancies.

postfix/README_FILES/IPV6_README

@@ -17,7 +17,7 @@ impractical.
 
 Postfix uses the same SMTP protocol over IPv6 as it already uses over the older
 IPv4 network, and does AAAA record lookups in the DNS in addition to the older
-A records. Information about IPv6 can be found at http://www.ipv6.org/.
+A records.
 
 This document provides information on the following topics:
 
@@ -43,7 +43,8 @@ Postfix version 2.2 supports IPv4 and IPv6 on the following platforms:
 
 On other platforms Postfix will simply use IPv4 as it has always done.
 
-See below for tips how to port Postfix IPv6 support to other environments.
+See "IPv6 Support for unsupported platforms" for tips to port Postfix IPv6
+support to other environments.
 
 CCoonnffiigguurraattiioonn
 
@@ -69,38 +70,22 @@ configuration work with Postfix.
 
         /etc/postfix/main.cf:
             # You must stop/start Postfix after changing this parameter.
-            inet_protocols = ipv4       (DEFAULT: enable IPv4 only)
             inet_protocols = all        (enable IPv4, and IPv6 if supported)
+            inet_protocols = ipv4       (enable IPv4 only)
             inet_protocols = ipv4, ipv6 (enable both IPv4 and IPv6)
             inet_protocols = ipv6       (enable IPv6 only)
 
-    By default, Postfix uses IPv4 only, because most systems aren't attached to
-    an IPv6 network.
-
-      o On systems with combined IPv4/IPv6 stacks, attempts to deliver mail via
-        IPv6 would always fail with "network unreachable", and those attempts
-        would only slow down Postfix.
-
-      o Linux kernels don't even load IPv6 protocol support by default. Any
-        attempt to use it would fail immediately.
+    The default is compile-time dependent: "all" when Postfix is built on a
+    software distribution with IPv6 support, "ipv4" otherwise.
 
     Note 1: you must stop and start Postfix after changing the inet_protocols
     configuration parameter.
 
-    Note 2: if you see error messages like the following, then you're running
-    Linux and need to turn on IPv6 in the kernel: see http://www.ipv6.org/ for
-    hints and tips. Unlike other systems, Linux does not have a combined stack
-    for IPv4 and IPv6, and IPv6 protocol support is not loaded by default.
+    Note 2: on older Linux and Solaris systems, the setting "inet_protocols =
+    ipv6" will not prevent Postfix from accepting IPv4 connections.
 
-        postconf: warning: inet_protocols: IPv6 support is disabled: Address
-        family not supported by protocol
-        postconf: warning: inet_protocols: configuring for IPv4 support only
-
-    Note 3: on older Linux and Solaris systems, the setting "inet_protocols =
-    ipv6" will not prevent Postfix from accepting IPv4 connections. Postfix
-    will present the client IP addresses in IPv6 format, though. In all other
-    cases, Postfix always presents IPv4 client IP addresses in the traditional
-    dotted quad IPv4 format.
+    For an unsupported test option to build Postfix without IPv6 support, see
+    the NO_IPV6 option in the INSTALL document.
 
   * The other new parameter is smtp_bind_address6. This sets the local
     interface address for outgoing IPv6 SMTP connections, just like the
@@ -117,7 +102,7 @@ configuration work with Postfix.
         mynetworks = 127.0.0.0/8 168.100.189.0/28 [::1]/128 [fe80::]/10 [2001:
         240:587::]/64
 
-    If you did specify the mynetworks parameter value in main.cf, you need
+    If you did specify the mynetworks parameter value in main.cf, you need to
     update the mynetworks value to include the IPv6 networks the system is in.
     Be sure to specify IPv6 address information inside "[]", like this:
 
@@ -137,8 +122,8 @@ KKnnoowwnn LLiimmiittaattiioonnss
     IPv4 outgoing connection attempts is configurable with the
     smtp_address_preference parameter.
 
-  * Postfix versions before 2.6 do not support DNSBL (real-time blackhole list)
-    lookups for IPv6 client IP addresses.
+  * Postfix versions before 2.6 do not support DNSBL (DNS blocklist) lookups
+    for IPv6 client IP addresses.
 
   * IPv6 does not have class A, B, C, etc. networks. With IPv6 networks, the
     setting "mynetworks_style = class" has the same effect as the setting
@@ -165,8 +150,8 @@ Strik and others, but differs in a few minor ways.
   * main.cf: Specify "inet_interfaces = loopback-only" to listen on loopback
     network interfaces only.
 
-  * The lmtp_bind_address and lmtp_bind_address6 features were omitted. The
-    Postfix LMTP client will be absorbed into the SMTP client, so there is no
+  * The lmtp_bind_address and lmtp_bind_address6 features were omitted. Postfix
+    version 2.3 merged the LMTP client into the SMTP client, so there was no
     reason to keep adding features to the LMTP client.
 
   * The SMTP server now requires that IPv6 addresses in SMTP commands are
@@ -253,8 +238,9 @@ Dean Strik.
 
   * Dean Strik extended IPv6 support to platforms other than KAME and USAGI,
     updated the patch to keep up with Postfix development, and provided a
-    combined IPv6 + TLS patch. Information about his effort can be found on
-    Dean Strik's Postfix website at http://www.ipnet6.org/postfix/.
+    combined IPv6 + TLS patch. Information about his effort is found in an
+    archived copy of Dean Strik's Postfix website at https://web.archive.org/
+    web/20080603102834/http://www.ipnet6.org/postfix/.
 
   * Wietse Venema took Dean Strik's IPv6 patch, merged it into Postfix 2.2, and
     took the opportunity to eliminate all IPv4-specific code from Postfix that

postfix/README_FILES/LDAP_README

@@ -1,3 +1,6 @@
+s!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" "https://
+www.w3.org/TR/html4/loose.dtd">
+
 PPoossttffiixx LLDDAAPP HHoowwttoo
 
 -------------------------------------------------------------------------------
@@ -46,14 +49,16 @@ client code only), you could use the following command:
         --without-threads --disable-slapd --disable-slurpd \
         --disable-debug --disable-shared
 
-If you're using the libraries from the UM distribution (http://www.umich.edu/
-~dirsvcs/ldap/ldap.html) or OpenLDAP (http://www.openldap.org), something like
-this in the top level of your Postfix source tree should work:
+If you're using the libraries from OpenLDAP (https://www.openldap.org),
+something like this in the top level of your Postfix source tree should work:
 
     % make tidy
     % make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \
         AUXLIBS_LDAP="-L/usr/local/lib -lldap -L/usr/local/lib -llber"
 
+If your LDAP shared library is in a directory that the RUN-TIME linker does not
+know about, add a "-Wl,-R,/path/to/directory" option after "-lldap".
+
 Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_LDAP. With Postfix
 3.0 and later, the old AUXLIBS variable still supports building a statically-
 loaded LDAP database client, but only the new AUXLIBS_LDAP variable supports
@@ -391,7 +396,7 @@ NNootteess aanndd tthhiinnggss ttoo tthhiinnkk aabboouu
         query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")
         (maildrop="*:*")(maildrop="*/*"))))
 
-  * And for that matter, even for aliases, you may not want users able to
+  * And for that matter, even for aliases, you may not want users to be able to
     specify their maildrops as programs, includes, etc. This might be
     particularly pertinent on a "sealed" server where they don't have local
     UNIX accounts, but exist only in LDAP and Cyrus. You might allow the fun

postfix/README_FILES/LINUX_README

@@ -4,10 +4,10 @@ PPoossttffiixx aanndd LLiinnuuxx
 
 HHoosstt llooookkuupp iissssuueess
 
-By default Linux /etc/hosts lookups do not support multiple IP address per
+By default Linux /etc/hosts lookups do not support multiple IP addresses per
 hostname. This causes warnings from the Postfix SMTP server that "hostname XXX
 does not resolve to address YYY", and is especially a problem with hosts that
-have both IPv4 and IPv6 addresses. To fix, turn on support for multiple IP
+have both IPv4 and IPv6 addresses. To fix this, turn on support for multiple IP
 addresses:
 
     /etc/host.conf:
@@ -42,11 +42,17 @@ file for further information.
 
 PPrrooccmmaaiill iissssuueess
 
-On RedHat Linux 7.1 and later pprrooccmmaaiill no longer has permission to write the
+On RedHat Linux 7.1 and later pprrooccmmaaiill no longer has permission to write to the
 mail spool directory. Workaround:
 
     # chmod 1777 /var/spool/mail
 
+LLooggggiinngg iinn aa ccoonnttaaiinneerr
+
+When running Postfix inside a container, you can use stdout logging as
+described in MAILLOG_README. Alternatives: run syslogd inside the container, or
+mount the host's syslog socket inside the container.
+
 SSyyssllooggdd ppeerrffoorrmmaannccee
 
 LINUX ssyyssllooggdd uses synchronous writes by default. Because of this, ssyyssllooggdd can
@@ -59,3 +65,10 @@ synchronous mail logfile writes by editing /etc/syslog.conf and by prepending a
 
 Send a "kkiillll --HHUUPP" to the ssyyssllooggdd to make the change effective.
 
+OOtthheerr llooggggiinngg ppeerrffoorrmmaannccee iissssuueess
+
+LINUX ssyysstteemmdd intercepts all logging and enforces its own rate limits before
+handing off requests to a backend such as rrssyyssllooggdd or ssyysslloogg--nngg. On a busy mail
+server this can result in information loss. As a workaround, you can use
+Postfix's built-in logging as described in MAILLOG_README.
+

postfix/README_FILES/LMDB_README

@@ -31,6 +31,9 @@ support, use something like:
         AUXLIBS_LMDB="-L/usr/local/lib -llmdb"
     % make
 
+If your LMDB shared library is in a directory that the RUN-TIME linker does not
+know about, add a "-Wl,-R,/path/to/directory" option after "-llmdb".
+
 Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_LMDB. With Postfix
 3.0 and later, the old AUXLIBS variable still supports building a statically-
 loaded LMDB database client, but only the new AUXLIBS_LMDB variable supports

postfix/README_FILES/LOCAL_RECIPIENT_README

@@ -21,7 +21,7 @@ recipients correctly.
 
   * Configuring local_recipient_maps in main.cf
   * When you need to change the local_recipient_maps setting in main.cf
-  * Local recipient table format
+  * Local recipient table query format
 
 CCoonnffiigguurriinngg llooccaall__rreecciippiieenntt__mmaappss iinn mmaaiinn..ccff
 
@@ -30,11 +30,13 @@ addresses of local recipients. A recipient address is local when its domain
 matches $mydestination, $inet_interfaces or $proxy_interfaces. If a local
 username or address is not listed in $local_recipient_maps, then the Postfix
 SMTP server will reject the address with "User unknown in local recipient
-table".
+table". Other interfaces such as the Postfix sendmail(1) command may still
+accept an "unknown" recipient.
 
 The default setting, shown below, assumes that you use the default Postfix
 local(8) delivery agent for local delivery, where recipients are either UNIX
-accounts or local aliases:
+accounts (typically, in /etc/passwd) or local aliases (typically, in /etc/
+aliases):
 
     /etc/postfix/main.cf:
         local_recipient_maps = proxy:unix:passwd.byname $alias_maps
@@ -67,19 +69,19 @@ WWhheenn yyoouu nneeeedd ttoo cchhaannggee tthhee llooc
         local_transport = virtual
         local_recipient_maps = $virtual_mailbox_maps
 
-    If you use a different delivery agent for $mydestination etc. domains, see
-    the section "Local recipient table format" below for a description of how
-    the table should be populated.
+    If you don't use the local(8) or virtual(8) delivery agent for
+    $mydestination etc. domains, see the section "Local recipient table format"
+    below for a description of how the table should be populated.
 
   * Problem: you use the mailbox_transport or fallback_transport feature of the
     Postfix local(8) delivery agent in order to deliver mail to non-UNIX
-    accounts.
+    recipients.
 
-    Solution: you need to add the database that lists the non-UNIX users:
+    Solution: you need to add the database that lists the non-UNIX recipients:
 
     /etc/postfix/main.cf
         local_recipient_maps = proxy:unix:passwd.byname, $alias_maps,
-            <the database with non-UNIX accounts>
+            <the database with non-UNIX recipients>
 
     See the section "Local recipient table format" below for a description of
     how the table should be populated.
@@ -88,30 +90,49 @@ WWhheenn yyoouu nneeeedd ttoo cchhaannggee tthhee llooc
     agent.
 
     Solution: you must disable the local_recipient_maps feature completely, so
-    that Postfix accepts mail for all local addresses:
+    that the Postfix SMTP server accepts mail for all local addresses:
 
     /etc/postfix/main.cf
         local_recipient_maps =
 
-LLooccaall rreecciippiieenntt ttaabbllee ffoorrmmaatt
+LLooccaall rreecciippiieenntt ttaabbllee qquueerryy ffoorrmmaatt
 
-If you use local files in postmap(1) format, then local_recipient_maps expects
-the following table format:
+If local_recipient_maps specifies local files, such as files in postmap(1) or
+postalias(1) format, then the Postfix SMTP server generates the following
+queries:
 
-  * In the left-hand side, specify a bare username, an "@domain.tld" wild-card,
-    or specify a complete "user@domain.tld" address.
+  * The full recipient address. This query supports a non-default
+    local_transport setting with a delivery agent such as lmtp(8) or virtual
+    (8). See "Configuring local_recipient_maps in main.cf: for additional
+    guidance for what lookup tables to specify.
 
-  * You have to specify something on the right-hand side of the table, but the
-    value is ignored by local_recipient_maps.
+  * The recipient address local-part. This query supports the default
+    local_transport setting with the UNIX-compatible local(8) delivery agent;
+    the Postfix SMTP server makes this query only when the recipient domain
+    matches $mydestination, $inet_interfaces or $proxy_interfaces.
 
-If you use lookup tables based on NIS, LDAP, MYSQL, or PGSQL, then
-local_recipient_maps does the same queries as for local files in postmap(1)
-format, and expects the same results.
+  * The recipient @domain. This query supports a non-default local_transport
+    setting with a delivery agent such as virtual(8); it is a wildcard for
+    domains that do not have a valid recipient list.
 
-With regular expression tables, Postfix only queries with the full recipient
-address, and not with the bare username or the "@domain.tld" wild-card.
+NOTES:
 
-NOTE: a lookup table should always return a result when the address exists, and
-should always return "not found" when the address does not exist. In
-particular, a zero-length result does not count as a "not found" result.
+  * A lookup table should return a non-empty result when the address exists,
+    and should return "not found" when the address does not exist. In
+    particular, a zero-length (empty) result does not count as a "not found"
+    result.
+
+  * When local_recipient_maps specifies a lookup table based on ldap:,
+    memcache:, mongodb:, mysql:, pgsql:, sqlite:, or other external database,
+    then the Postfix SMTP server queries that lookup table with the same
+    queries as described at the start of this section, and expects the same
+    results.
+
+  * To suppress lookups for the local-part and the @domain wild-card, specify
+    the ddoommaaiinn setting in a Postfix ldap:, memcache:, mongodb:, mysql:, pgsql:,
+    sqlite:, etc., database client configuration file.
+
+  * When local_recipient_maps specifies a lookup table based on pcre:, regexp:,
+    socketmap: or tcp:, Postfix queries that table only with the full recipient
+    address, and not with the local-part or the @domain wild-card.
 

postfix/README_FILES/MAILLOG_README

@@ -0,0 +1,123 @@
+PPoossttffiixx llooggggiinngg ttoo ffiillee oorr ssttddoouutt
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+Postfix supports its own logging system as an alternative to syslog (which
+remains the default). This is available with Postfix version 3.4 or later.
+
+Topics covered in this document:
+
+  * Configuring logging to file
+  * Configuring logging to stdout
+  * Rotating logs
+  * Limitations
+
+CCoonnffiigguurriinngg llooggggiinngg ttoo ffiillee
+
+Logging to file solves a usability problem for MacOS, and eliminates multiple
+problems for systemd-based systems.
+
+ 1. Add the following line to master.cf if not already present (note: there
+    must be no whitespace at the start of the line):
+
+        postlog   unix-dgram n  -       n       -       1       postlogd
+
+    Note: the service type "uunniixx--ddggrraamm" was introduced with Postfix 3.4. Remove
+    the above line before backing out to an older Postfix version.
+
+ 2. Configure Postfix to write logging, to, for example, /var/log/postfix.log.
+    See also the "Logfile rotation" section below for logfile management.
+
+    In the example below, specifying maillog_file_permissions is optional
+    (Postfix 3.9 and later). The default value is 0600, i.e., only the super-
+    user can access the file; the value 0644 also adds 'group' and 'other' read
+    access.
+
+        # postfix stop
+        # postconf maillog_file=/var/log/postfix.log
+        # postconf maillog_file_permissions=0644 # (Postfix 3.9 and later)
+        # postfix start
+
+    By default, the logfile name must start with "/var" or "/dev/stdout" (the
+    list of allowed prefixes is configured with the maillog_file_prefixes
+    parameter). This safety mechanism limits the damage from a single
+    configuration mistake.
+
+CCoonnffiigguurriinngg llooggggiinngg ttoo ssttddoouutt
+
+Logging to stdout is useful when Postfix runs in a container, as it eliminates
+a syslogd dependency.
+
+ 1. Add the following line to master.cf if not already present (note: there
+    must be no whitespace at the start of the line):
+
+        postlog   unix-dgram n  -       n       -       1       postlogd
+
+    Note: the service type "uunniixx--ddggrraamm" was introduced with Postfix 3.4. Remove
+    the above line before backing out to an older Postfix version.
+
+ 2. Configure main.cf with "maillog_file = /dev/stdout".
+
+ 3. Start Postfix with "ppoossttffiixx ssttaarrtt--ffgg".
+
+RRoottaattiinngg llooggss
+
+The command "ppoossttffiixx llooggrroottaattee" may be run by hand or by a cronjob. It logs all
+errors, and reports errors to stderr if run from a terminal. This command
+implements the following steps:
+
+  * Rename the current logfile by appending a suffix that contains the date and
+    time. This suffix is configured with the maillog_file_rotate_suffix
+    parameter (default: %Y%m%d-%H%M%S).
+
+  * Reload Postfix so that postlogd(8) immediately closes the old logfile.
+
+  * After a brief pause, compress the old logfile. The compression program is
+    configured with the maillog_file_compressor parameter (default: gzip).
+
+  * The next time it logs an event, postlogd(8) will create a new logfile, with
+    permissions specified with the maillog_file_permissions parameter (default:
+    0600).
+
+Notes:
+
+  * This command will not rotate a logfile with a pathname under the /dev
+    directory, such as /dev/stdout.
+
+  * This command does not (yet) remove old logfiles.
+
+LLiimmiittaattiioonnss
+
+Background:
+
+  * Postfix consists of a number of daemon programs that run in the background,
+    as well as non-daemon programs for local mail submission or Postfix
+    management.
+
+  * Logging to the Postfix logfile or stdout requires the Postfix postlogd(8)
+    service. This ensures that simultaneous logging from different programs
+    will not get mixed up.
+
+  * All Postfix programs can log to syslog, but not all programs have
+    sufficient privileges to use the Postfix logging service, and many non-
+    daemon programs must not log to stdout as that would corrupt their output.
+
+Limitations:
+
+  * Non-daemon Postfix programs will log errors to syslogd(8) before they have
+    processed command-line options and main.cf parameters.
+
+  * If Postfix is down, the non-daemon programs postfix(1), postsuper(1),
+    postmulti(1), and postlog(1), will log directly to $maillog_file. These
+    programs expect to run with root privileges, for example during Postfix
+    start-up, reload, or shutdown.
+
+  * Other non-daemon Postfix programs will never write directly to
+    $maillog_file (also, logging to stdout would interfere with the operation
+    of some of these programs). These programs can log to postlogd(8) if they
+    are run by the super-user, or if their executable file has set-gid
+    permission. Do not set this permission on programs other than postdrop(1),
+    postqueue(1), and (Postfix >= 3.7) postlog(1).
+

postfix/README_FILES/MILTER_README

@@ -24,6 +24,7 @@ implementations.
 This document provides information on the following topics:
 
   * How Milter applications plug into Postfix
+  * When Postfix and Milters inspect an SMTP session
   * Building Milter applications
   * Running Milter applications
   * Configuring Postfix
@@ -80,12 +81,47 @@ Postfix architecture).
 
     Local   -> sendmail(1)
 
+WWhheenn PPoossttffiixx aanndd MMiilltteerrss iinnssppeecctt aann SSMMTTPP sseessssiioonn
+
+Generally, Postfix inspects information first, then the first configured
+Milter, the second configured Milter, and so on.
+
+  * With most SMTP commands: Postfix reviews one SMTP command, and if Postfix
+    does not reject it, Postfix passes the command to the first configured
+    Milter. If the first Milter does not reject the command, Postfix passes it
+    to the second configured Milter, and so on. This includes commands with an
+    envelope sender (MAIL FROM) or envelope recipient (RCPT TO). Postfix stores
+    the same envelope records in a queue file as when no Milters are
+    configured, including rewritten envelope addresses, expanded virtual
+    aliases, BCC addresses from sender/recipient_bcc_maps, and so on.
+
+  * With header/body content: Postfix may rewrite or reject header/body content
+    before it stores that content in the queue file; Postfix stores the same
+    header/body content as when no Milters are configured. If Postfix does not
+    reject the header/body content, Postfix passes it to the first configured
+    Milter which may modify or reject that content or may modify the stored
+    envelope. If the first Milter does not reject the header/body content,
+    Postfix passes it to the second configured Milter, and so on.
+
+Details:
+
+  * Postfix hides its own Postfix-prepended Received: header, for compatibility
+    with Sendmail. Postfix does not hide other headers that Postfix or Milters
+    added or modified.
+
+  * When the Postfix SMTP server receives a sequence of one or more valid BDAT
+    commands, it generates one DATA command for the Milters.
+
+  * The Milter API does not support inspection of SMTP commands such as QUIT,
+    NOOP, or VRFY; the API supports only commands that are needed for email
+    delivery.
+
 BBuuiillddiinngg MMiilltteerr aapppplliiccaattiioonnss
 
-Milter applications have been written in C, JAVA and Perl, but this document
-deals with C applications only. For these, you need an object library that
-implements the Sendmail 8 Milter protocol. Postfix currently does not provide
-such a library, but Sendmail does.
+Milter applications have been written in C, Haskell, Java, Perl, Python, Rust,
+and more, but this document covers C applications only. For these, you need an
+object library that implements the Sendmail 8 Milter protocol. Postfix
+currently does not provide such a library, but Sendmail does.
 
 Some systems install the Sendmail libmilter library by default. With other
 systems, libmilter may be provided by a package (called "sendmail-devel" on
@@ -148,9 +184,9 @@ section.
 You specify SMTP-only Milter applications (there can be more than one) with the
 smtpd_milters parameter. Each Milter application is identified by the name of
 its listening socket; other Milter configuration options will be discussed in
-later sections. Milter applications are applied in the order as specified, and
-the first Milter application that rejects a command will override the responses
-from other Milter applications.
+later sections. Postfix sends commands to each Milter application in the order
+as configured with smtpd_milters. When a Milter application rejects a command,
+that will override responses from other Milter applications.
 
     /etc/postfix/main.cf:
         # Milters for mail that arrives via the smtpd(8) server.
@@ -163,7 +199,7 @@ The general syntax for listening sockets is as follows:
         Connect to the local UNIX-domain server that is bound to the specified
         pathname. If the smtpd(8) or cleanup(8) process runs chrooted, an
         absolute pathname is interpreted relative to the Postfix queue
-        directory.
+        directory. On many systems, llooccaall is a synonym for uunniixx
 
     iinneett::host::port
         Connect to the specified TCP port on the specified local or remote
@@ -192,9 +228,9 @@ Instead, keep Postfix's own Received: message header and use the header_checks
 You specify non-SMTP Milter applications with the non_smtpd_milters parameter.
 This parameter uses the same syntax as the smtpd_milters parameter in the
 previous section. As with the SMTP-only filters, you can specify more than one
-Milter application; they are applied in the order as specified, and the first
-Milter application that rejects a command will override the responses from the
-other applications.
+Milter application. Postfix sends commands to each Milter application in the
+order as configured with non_smtpd_milters. When a Milter application rejects a
+command, that will override responses from other Milter applications.
 
     /etc/postfix/main.cf:
         # Milters for non-SMTP mail.
@@ -356,9 +392,9 @@ ccoommmmaa wwiitthhiinn aa vvaalluuee oorr aarroouunndd
 DDiiffffeerreenntt sseettttiinnggss ffoorr ddiiffffeerreenntt SSMMTTPP cclliieennttss
 
 The smtpd_milter_maps feature supports different Milter settings for different
-client IP addresses. Lookup results override the the global smtpd_milters
-setting, and have the same syntax. For example, to disable Milter settings for
-local address ranges:
+client IP addresses. Lookup results override the global smtpd_milters setting,
+and have the same syntax. For example, to disable Milter settings for local
+address ranges:
 
 /etc/postfix/main.cf:
     smtpd_milter_maps = cidr:/etc/postfix/smtpd_milter_map
@@ -470,9 +506,9 @@ Sendmail. See the workarounds section below for solutions.
 WWhhaatt mmaaccrrooss wwiillll PPoossttffiixx sseenndd ttoo MMiilltteerrss??
 
 Postfix sends specific sets of macros at different Milter protocol stages. The
-sets are configured with the parameters as shown in the table below (EOH = end
-of headers; EOM = end of message). The protocol version is a number that
-Postfix sends at the beginning of the Milter protocol handshake.
+names of these macros are configured with the parameters shown in the table
+below (EOH = end of headers; EOM = end of message). Some lists require a
+minimum Milter protocol version.
 
 As of Sendmail 8.14.0, Milter applications can specify what macros they want to
 receive at different Milter protocol stages. An application-specified list
@@ -507,7 +543,7 @@ queue ID, sender, or recipient).
 To force a macro to be sent even when its value has not been updated, you may
 specify macro default values with the milter_macro_defaults parameter. Specify
 zero or more name=value pairs separated by comma or whitespace; you may even
-specify macro names that Postfix does know about!
+specify macro names that Postfix does not know about!
 
 WWoorrkkaarroouunnddss
 
@@ -627,10 +663,24 @@ the CONTENT_INSPECTION_README document for a discussion.
     command information; they have no access to the message header or body, and
     cannot make modifications to the message or to the envelope.
 
-  * Postfix 2.6 ignores the optional ESMTP parameters in requests to replace
-    the sender (SMFIR_CHGFROM) or to append a recipient (SMFIR_ADDRCPT_PAR).
-    Postfix logs a warning message when a Milter application supplies such
-    ESMTP parameters:
+  * Postfix 3.3 and later support the ESMTP parameters RET and ENVID in
+    requests to replace the envelope sender (SMFIR_CHGFROM). Postfix logs a
+    warning message when a Milter application supplies other ESMTP parameters:
+
+    warning: queue-id: cleanup_chg_from: ignoring bad ESMTP
+        parameter "whatever" in SMFI_CHGFROM request
+
+  * Postfix 3.0 and later support the ESMTP parameters NOTIFY and ORCPT in
+    requests to add an envelope recipient. Postfix logs a warning message when
+    a Milter application supplies other ESMTP parameters:
+
+    warning: queue-id: cleanup_add_rcpt: ignoring ESMTP argument
+        from Milter or header/body_checks: "whatever"
+
+  * Postfix 2.6 and later ignore optional ESMTP parameters in requests to
+    replace the sender (SMFIR_CHGFROM) or to append a recipient
+    (SMFIR_ADDRCPT_PAR). Postfix logs a warning message when a Milter
+    application supplies such ESMTP parameters:
 
     warning: queue-id: cleanup_chg_from: ignoring ESMTP arguments "whatever"
     warning: queue-id: cleanup_add_rcpt: ignoring ESMTP arguments "whatever"
@@ -643,6 +693,6 @@ the CONTENT_INSPECTION_README document for a discussion.
 
     The solution is to use Postfix version 2.4 or later.
 
-  * Most Milter configuration options are global. Future Postfix versions may
-    support per-Milter timeouts, per-Milter error handling, etc.
+  * Postfix versions before 3.0 did not support per-Milter timeouts, per-Milter
+    error handling, etc.
 

postfix/README_FILES/MONGODB_README

@@ -0,0 +1,188 @@
+PPoossttffiixx MMoonnggooDDBB HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+MMoonnggooDDBB SSuuppppoorrtt iinn PPoossttffiixx
+
+Postfix can use MongoDB as a source for any of its lookups: aliases(5), virtual
+(5), canonical(5), etc. This allows you to keep information for your mail
+service in a replicated noSQL database with fine-grained access controls. By
+not storing it locally on the mail server, the administrators can maintain it
+from anywhere, and the users can control whatever bits of it you think
+appropriate. You can have multiple mail servers using the same information,
+without the hassle and delay of having to copy it to each.
+
+Topics covered in this document:
+
+  * Building Postfix with MongoDB support
+  * Configuring MongoDB lookups
+  * Example: virtual alias maps
+  * Example: Mailing lists
+  * Example: MongoDB projections
+  * Feedback
+  * Credits
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh MMoonnggooDDBB ssuuppppoorrtt
+
+These instructions assume that you build Postfix from source code as described
+in the INSTALL document. Some modification may be required if you build Postfix
+from a vendor-specific source package.
+
+The Postfix MongoDB client requires the mmoonnggoo--cc--ddrriivveerr library. This can be
+built from source code from the mongod-c project, or this can be installed as a
+binary package from your OS distribution, typically named mmoonnggoo--cc--ddrriivveerr,
+mmoonnggoo--cc--ddrriivveerr--ddeevveell or lliibbmmoonnggoocc--ddeevv. Installing the mongo-c-driver library
+may also install lliibbbbssoonn as a dependency.
+
+To build Postfix with mongodb map support, add to the CCARGS environment
+variable the options -DHAS_MONGODB and -I for the directory containing the
+mongodb headers, and specify the AUXLIBS_MONGODB with the libmongoc and libbson
+libraries, for example:
+
+    % make tidy
+    % make -f Makefile.init makefiles \
+        CCARGS="$CCARGS -DHAS_MONGODB -I/usr/include/libmongoc-1.0 \
+        -I/usr/include/libbson-1.0" \
+        AUXLIBS_MONGODB="-lmongoc-1.0 -lbson-1.0"
+
+The 'make tidy' command is needed only if you have previously built Postfix
+without MongoDB support.
+
+If your MongoDB shared library is in a directory that the RUN-TIME linker does
+not know about, add a "-Wl,-R,/path/to/directory" option after "-lbson-1.0".
+Then, just run 'make'.
+
+CCoonnffiigguurriinngg MMoonnggooDDBB llooookkuuppss
+
+In order to use MongoDB lookups, define a MongoDB source as a table lookup in
+main.cf, for example:
+
+    alias_maps = hash:/etc/aliases, proxy:mongodb:/etc/postfix/mongo-aliases.cf
+
+The file /etc/postfix/mongo-aliases.cf can specify a number of parameters. For
+a complete description, see the mongodb_table(5) manual page.
+
+EExxaammppllee:: vviirrttuuaall((55)) aalliiaass mmaappss
+
+Here's a basic example for using MongoDB to look up virtual(5) aliases. Assume
+that in main.cf, you have:
+
+    virtual_alias_maps = hash:/etc/postfix/virtual_aliases,
+        proxy:mongodb:/etc/postfix/mongo-virtual-aliases.cf
+
+and in mongodb:/etc/postfix/mongo-virtual-aliases.cf you have:
+
+    uri = mongodb+srv://user_name:password@some_server
+    dbname = mail
+    collection = mailbox
+    query_filter = {"$or": [{"username":"%s"}, {"alias.address": "%s"}],
+    "active": 1}
+    result_attribute = username
+
+This example assumes mailbox names are stored in a MongoDB backend, in a format
+like:
+
+    { "username": "user@example.com",
+      "alias": [
+        {"address": "admin@example.com"},
+        {"address": "abuse@example.com"}
+      ],
+      "active": 1
+    }
+
+Upon receiving mail for "admin@example.com" that isn't found in the /etc/
+postfix/virtual_aliases database, Postfix will search the MongoDB server/
+cluster listening at port 27017 on some_server. It will connect using the
+provided credentials, and search for any entries whose username is, or alias
+field has "admin@example.com". It will return the username attribute of those
+found, and build a list of their email addresses.
+
+Notes:
+
+  * As with pprroojjeeccttiioonn (see below), the Postfix mongodb client automatically
+    removes the top-level '_id' field from a result_attribute result.
+
+  * The Postfix mongodb client will only parse result fields with data types
+    UTF8, INT32, INT64 and ARRAY. Other fields will be ignored, with a warning
+    in the logs.
+
+EExxaammppllee:: MMaaiilliinngg lliissttss
+
+When it comes to mailing lists, one way of implementing one would be as below:
+
+    { "name": "dev@example.com", "active": 1, "address":
+      [ "hamid@example.com", "wietse@example.com", "viktor@example.com" ] }
+
+using the filter below, will result in a comma separated string with all email
+addresses in this list.
+
+    query_filter = {"name": "%s", "active": 1}
+    result_attribute = address
+
+Notes:
+
+  * As with pprroojjeeccttiioonn (see below), the Postfix mongodb client automatically
+    removes the top-level '_id' field from a result_attribute result.
+
+  * The Postfix mongodb client will only parse result fields with data types
+    UTF8, INT32, INT64 and ARRAY. Other fields will be ignored, with a warning
+    in the logs.
+
+EExxaammppllee:: aaddvvaanncceedd pprroojjeeccttiioonnss
+
+This module also supports the use of more complex MongoDB projections. There
+may be some use cases where operations such as concatenation are necessary to
+be performed on the data retrieved from the database. Although it is encouraged
+to keep the database design simple enough so this is not necessary, postfix
+supports the use of MongoDB projections to achieve the goal.
+
+Consider the example below:
+
+    { "username": "user@example.com",
+      "local_part": "user",
+      "domain": "example.com",
+      "alias": [
+        {"address": "admin@example.com"},
+        {"address": "abuse@example.com"}
+      ],
+      "active": 1
+    }
+
+virtual_mailbox_maps can be created using below parameters in a mongodb:/etc/
+postfix/mongo-virtual-mailboxes.cf file:
+
+    uri = mongodb+srv://user_name:password@some_server
+    dbname = mail
+    collection = mailbox
+    query_filter = {"$or": [{"username":"%s"}, {"alias.address": "%s"}],
+    "active": 1}
+    projection = { "mail_path": {"$concat": ["$domain", "/", "$local_part"]} }
+
+This will return 'example.com/user' path built from the database fields.
+
+A couple of considerations when using projections:
+
+  * As with rreessuulltt__aattttrriibbuuttee, the Postfix mongodb client automatically removes
+    the top-level '_id' field from a projection result.
+
+  * The Postfix mongodb client will only parse fields with data types UTF8,
+    INT32, INT64 and ARRAY. Other fields will be ignored, with a warning in the
+    logs. It is suggested to exclude any unnecessary fields when using a
+    projection.
+
+FFeeeeddbbaacckk
+
+If you have questions, send them to postfix-users@postfix.org. Please include
+relevant information about your Postfix setup: MongoDB-related output from
+postconf, which libraries you built with, and such. If your question involves
+your database contents, please include the applicable bits of some database
+entries.
+
+CCrreeddiittss
+
+  * Stephan Ferraro (Aionda GmbH) implemented an early version of the Postfix
+    MongoDB client.
+  * Hamid Maadani (Dextrous Technologies, LLC) added support for projections
+    and %letter interpolation, and added documentation.
+  * Wietse Venema adopted and restructured the code and documentation.
+

postfix/README_FILES/MULTI_INSTANCE_README

@@ -16,7 +16,7 @@ Topics covered in this document:
   * Null-client instances versus service instances
   * Multi-instance walk-through
   * Components of a Postfix system
-  * The default Postfix instance
+  * The primary Postfix instance
   * Instance groups
   * Multi-instance configuration parameters
   * Using the postmulti(1) command
@@ -64,7 +64,7 @@ that multiple instances will be easier to use than ever before.
 NNuullll--cclliieenntt iinnssttaanncceess vveerrssuuss sseerrvviiccee iinnssttaanncceess
 
 In the multi-instance approach to configuring Postfix, the first simplification
-is with the default local-submission Postfix instance.
+is with the primary local-submission Postfix instance.
 
 Most UNIX systems require support for email submission with the sendmail(1)
 command so that system processes such as cron jobs can send status reports, and
@@ -103,7 +103,7 @@ scrutiny, locally submitted messages are typically limited to mail from cron
 jobs and other system services. In this regard the border MTA is not different
 from other Unix hosts in your environment. For this reason, it will submit
 locally-generated email to the internal mail hub. We start the construction of
-the border mail server with the default instance, which will be a local-
+the border mail server with the primary instance, which will be a local-
 submission null client:
 
     /etc/postfix/main.cf:
@@ -196,7 +196,7 @@ running "make"), then start and test the null-client:
     testing
     EOF
 
-The test message should be delivered the members of the "mtaadmin" address
+The test message should be delivered to the members of the "mtaadmin" address
 group (or whatever address group you choose) with the following headers:
 
     From: mtaadmin+root=mta1@example.com
@@ -213,7 +213,7 @@ before the input instance can be fully tested, and when the system boots, the
 and input instances into a single instance group named "mta".
 
 Just once, when adding the first secondary instance, enable multi-instance
-support in the default (null-client) instance:
+support in the primary (null-client) instance:
 
     # postmulti -e init
 
@@ -223,7 +223,7 @@ Then create the output instance:
 
 The instance configuration directory defaults to /etc/postfix-out, more
 precisely, the "postfix-out" subdirectory of the parent directory of the
-default-instance configuration directory. The new instance will be created in a
+primary-instance configuration directory. The new instance will be created in a
 "disabled" state:
 
     /etc/postfix-out/main.cf
@@ -240,7 +240,7 @@ default-instance configuration directory. The new instance will be created in a
 
 This instance has a "stock" master.cf file, and its queue and data directories,
 also named "postfix-out", will be located in the same parent directories as the
-corresponding directories of the default instance (e.g., /var/spool/postfix-out
+corresponding directories of the primary instance (e.g., /var/spool/postfix-out
 and /var/lib/postfix-out).
 
 While this instance is immediately safe to start, it is not yet usefully
@@ -294,7 +294,7 @@ injection SMTP service. Typical additions include:
         smtpd_relay_restrictions =
         smtpd_recipient_restrictions = permit_mynetworks, reject
 
-        # Tolerate occasional high latency in the  content filter.
+        # Tolerate occasional high latency in the content filter.
         #
         smtpd_timeout = 1200s
 
@@ -367,7 +367,7 @@ instance group:
 
 The new instance configuration directory defaults to /etc/postfix-in, more
 precisely, the "postfix-in" subdirectory of the parent directory of the
-default-instance configuration directory. The new instance will be created in a
+primary-instance configuration directory. The new instance will be created in a
 "disabled" state:
 
     /etc/postfix-in/main.cf
@@ -520,7 +520,7 @@ set in main.cf is $config_directory, as this defines the location of the
 main.cf file itself.
 
 Though config_directory cannot be set in main.cf, postfix(1) and most of the
-other command-line Postfix utilities allow you to specify a non-default
+other command-line Postfix utilities allow you to specify a secondary
 configuration directory via a command line option (typically --cc) or via the
 MAIL_CONFIG environment variable. In this way, it is possible to have multiple
 configuration directories on the same machine, and to have multiple running
@@ -535,27 +535,27 @@ Each combination of configuration directory, together with the queue directory
 and data directory (specified in the corresponding main.cf file) make up a
 Postfix iinnssttaannccee.
 
-TThhee ddeeffaauulltt PPoossttffiixx iinnssttaannccee
+TThhee pprriimmaarryy PPoossttffiixx iinnssttaannccee
 
 One Postfix instance is special: this is the instance whose configuration
 directory is the default one compiled into the Postfix utilities. The location
 of the default configuration directory is typically /etc/postfix, and can be
 queried via the "postconf -d config_directory" command. We call the instance
-with this configuration directory the "default instance".
+with this configuration directory the "primary instance".
 
-The default instance is responsible for local mail submission. The setgid
+The primary instance is responsible for local mail submission. The setgid
 postdrop(1) utility is used by the sendmail(1) local submission program to
 spool messages into the mmaaiillddrroopp sub-directory of the queue directory of the
-default instance.
+primary instance.
 
 Even in the rare case when "sendmail -C" is used to submit local mail into a
-non-default Postfix instance, for security reasons, postdrop(1) will consult
-the default main.cf file to check the validity of the requested non-default
+secondary Postfix instance, for security reasons, postdrop(1) will consult the
+primary main.cf file to check the validity of the requested non-default
 configuration directory.
 
-So, while in most other respects, all instances are equal, the default instance
-is "more equal than others". You may choose to create additional instances, but
-you must have at least the default instance, with its configuration directory
+So, while in most other respects, all instances are equal, the primary instance
+is "more equal than others". You may choose to create secondary instances, but
+you must have at least the primary instance, with its configuration directory
 in the default compiled-in location.
 
 IInnssttaannccee ggrroouuppss
@@ -575,9 +575,9 @@ the related instances should be members of a single instance group (however,
 the content filter usually has its own start/stop procedure that is separate
 from any Postfix instance).
 
-The default instance main.cf file's $multi_instance_directories configuration
+The primary instance main.cf file's $multi_instance_directories configuration
 parameter lists the configuration directories of all secondary (non-default)
-instances. Together with the default instance, these secondary instances are
+instances. Together with the primary instance, these secondary instances are
 managed by the multi-instance manager. Instances are started in the order
 listed, and stopped in the opposite order. For instances that are members of a
 service "group", you should arrange to start the service back-to-front, with
@@ -587,16 +587,16 @@ started.
 MMuullttii--iinnssttaannccee ccoonnffiigguurraattiioonn ppaarraammeetteerrss
 
 multi_instance_wrapper
-    This default-instance configuration parameter must be set to a suitable
+    This primary-instance configuration parameter must be set to a suitable
     multi-instance manager's "wrapper" program that controls the starting,
     stopping, etc. of a multi-instance Postfix system. To use the postmulti(1)
     manager described in this document, this parameter should be set with the
     "postmulti -e init" command.
 
 multi_instance_directories
-    This default-instance configuration parameter specifies an optional list of
+    This primary-instance configuration parameter specifies an optional list of
     the secondary instances controlled via the multi-instance manager.
-    Instances are listed in their "start" order, with the default instance
+    Instances are listed in their "start" order, with the primary instance
     always started first (if enabled). If $multi_instance_directories is left
     empty, the postfix(1) command runs with multi-instance support turned off,
     and none of the multi_instance_ configuration parameters will have any
@@ -672,37 +672,37 @@ IInniittiiaalliizziinngg tthhee mmuullttii--iinnssttaa
 
 Before postmulti(1) is used for the first time, you must install it as the
 multi_instance_wrapper for your Postfix system and enable multi-instance
-operation of the default Postfix instance. You can then proceed to add new or
+operation of the primary Postfix instance. You can then proceed to add new or
 existing instances to the multi-instance configuration. This initial
 installation is accomplished as follows:
 
         # postmulti -e init
 
-This updates the default instance main.cf file as follows:
+This updates the primary instance main.cf file as follows:
 
         # Use postmulti(1) as a postfix-wrapper(5)
         #
         multi_instance_wrapper = ${command_directory}/postmulti -p --
 
-        # Configure the default instance to start when in multi-instance mode
+        # Configure the primary instance to start when in multi-instance mode
         #
         multi_instance_enable = yes
 
-If you prefer, you can make these changes by editing the default main.cf
+If you prefer, you can make these changes by editing the primary main.cf
 directly, or by using "postconf -e".
 
 LLiissttiinngg mmaannaaggeedd iinnssttaanncceess
 
-The list of managed instances consists of the default instance and the
-additional instances whose configuration directories are listed (in start
-order) under the multi_instance_directories parameter of the default main.cf
+The list of managed instances consists of the primary instance and the
+secondary instances whose configuration directories are listed (in start order)
+under the multi_instance_directories parameter of the primary main.cf
 configuration file.
 
 You can list selected instances, groups of instances or all instances by
 specifying only the instance matching options with the "-l" option. The "-a"
 option is assumed if no other instance selection options are specified (this
 behavior changes with the "-e" option). As a special case, even if it has an
-explicit name, the default instance can always be selected via "-i -".
+explicit name, the primary instance can always be selected via "-i -".
 
     # postmulti -l -a
     # postmulti -l -g a_group
@@ -732,8 +732,8 @@ either the instance name or the instance group is not set, it is shown as a "-
 
 When selecting an existing instance via the "-i" option, you can always use the
 full pathname of its configuration directory instead of the instance (short)
-name. This is the only way to select a non-default nameless instance. The
-default instance can be selected via "-i -", whether it has a name or not.
+name. This is the only way to select a secondary nameless instance. The primary
+instance can be selected via "-i -", whether it has a name or not.
 
 To list instances in reverse start order, include the "-R" option together with
 the instance selection options.
@@ -826,9 +826,9 @@ possibilities:
 
 CCrreeaattiinngg aa nneeww PPoossttffiixx iinnssttaannccee
 
-The postmulti(1) command can be used to create additional Postfix instances.
-New instances are created with local submission and all "inet" services
-disabled via the following non-default parameter settings in the main.cf file:
+The postmulti(1) command can be used to create secondary Postfix instances. New
+instances are created with local submission and all "inet" services disabled
+via the following non-default parameter settings in the main.cf file:
 
     authorized_submit_users =
     master_service_disable = inet
@@ -839,8 +839,8 @@ will also not accept any mail until they are fully configured, at which point
 you can do away with one or both of the above safety measures.
 
 The postmulti(1) command encourages a preferred way of organizing the
-configuration directories, queue directories and data directories of non-
-default instances. If the default instance settings are:
+configuration directories, queue directories and data directories of secondary
+instances. If the primary instance settings are:
 
     config_directory = /conf-path/postfix
     queue_directory = /queue-path/postfix
@@ -885,7 +885,7 @@ existing instances. By default, the configuration directories of newly managed
 instances are appended to the instance list. You can use the "-i" or "-g" or "-
 a" options to insert the new instance before the specified instance or group,
 or at the beginning of the instance list (multi_instance_directories parameter
-of the default instance).
+of the primary instance).
 
 If you do specify a name (use "-I" with a name that is not "-") for the new
 instance, you may omit any of the 3 instance installation parameters whose

postfix/README_FILES/MYSQL_README

@@ -28,16 +28,18 @@ Postfix.
 The Postfix MySQL client utilizes the mysql client library, which can be
 obtained from:
 
-    http://www.mysql.com/downloads/
-    http://sourceforge.net/projects/mysql/
+    https://www.mysql.com/downloads/
 
 In order to build Postfix with mysql map support, you will need to add -
 DHAS_MYSQL and -I for the directory containing the mysql headers, and the
 mysqlclient library (and libm) to AUXLIBS_MYSQL, for example:
 
     make -f Makefile.init makefiles \
-        'CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include' \
-        'AUXLIBS_MYSQL=-L/usr/local/mysql/lib -lmysqlclient -lz -lm'
+        "CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include" \
+        "AUXLIBS_MYSQL=-L/usr/local/mysql/lib -lmysqlclient -lz -lm"
+
+If your MySQL shared library is in a directory that the RUN-TIME linker does
+not know about, add a "-Wl,-R,/path/to/directory" option after "-lmysqlclient".
 
 Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_MYSQL. With Postfix
 3.0 and later, the old AUXLIBS variable still supports building a statically-
@@ -52,9 +54,9 @@ building a dynamically-loaded or statically-loaded MySQL database client.
 On Solaris, use this instead:
 
     make -f Makefile.init makefiles \
-        'CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include' \
-        'AUXLIBS_MYSQL=-L/usr/local/mysql/lib -R/usr/local/mysql/lib \
-            -lmysqlclient -lz -lm'
+        "CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include" \
+        "AUXLIBS_MYSQL=-L/usr/local/mysql/lib -R/usr/local/mysql/lib \
+            -lmysqlclient -lz -lm"
 
 Then, just run 'make'. This requires libz, the compression library. Older mysql
 implementations build without libz.
@@ -129,5 +131,5 @@ CCrreeddiittss
     configuration feature.
   * Liviu Daia with further refinements from Jose Luis Tallon and Victor
     Duchovni developed the common query, result_format, domain and
-    expansion_limit interface for LDAP, MySQL and PosgreSQL.
+    expansion_limit interface for LDAP, MySQL and PostgreSQL.
 

postfix/README_FILES/OVERVIEW

@@ -109,8 +109,8 @@ unnumbered names inside shaded areas represent Postfix queues.
     error(8) delivery agents are special: they discard or bounce all mail, and
     are not shown in the figure above.
 
-    The queue manager maintains a small active queue with the messages that it
-    has opened for delivery. The active queue acts as a limited window on
+    The queue manager maintains a limited active queue with the messages that
+    it has opened for delivery. The active queue acts as a limited window on
     potentially large incoming or deferred queues. The limited active queue
     prevents the queue manager from running out of memory under heavy load.
 
@@ -126,11 +126,13 @@ unnumbered names inside shaded areas represent Postfix queues.
     relocated(5) table for recipients whose address has changed; mail for such
     recipients is returned to the sender with an explanation.
 
-  * The smtp(8) client looks up a list of mail exchangers for the destination
-    host, sorts the list by preference, and tries each server in turn until it
-    finds a server that responds. It then encapsulates the sender, recipient
-    and message content as required by the SMTP protocol; this includes
-    conversion of 8-bit MIME to 7-bit encoding.
+  * The smtp(8) client looks up a list of SMTP servers for the destination(s)
+    in a delivery request, sorts the list by preference, and tries each server
+    in turn until it has delivered or bounced all recipients in the delivery
+    request. It encapsulates the sender, recipients and message content as
+    required by the SMTP protocol; this includes message body conversion from
+    8-bit MIME to 7-bit encoding, but does not include RFC 2047 header
+    encoding.
 
   * The lmtp(8) client speaks a protocol similar to SMTP that is optimized for
     delivery to mailbox servers such as Cyrus. The advantage of this setup is
@@ -158,10 +160,11 @@ unnumbered names inside shaded areas represent Postfix queues.
 
   * The pipe(8) mailer is the outbound interface to other mail processing
     systems (the Postfix sendmail(1) command being the inbound interface). The
-    interface is UNIX compatible: it provides information on the command line
-    and on the standard input stream, and expects a process exit status code as
-    defined in <sysexits.h>. Examples of delivery via the pipe(8) mailer are in
-    the MAILDROP_README and UUCP_README documents.
+    interface is UNIX compatible: the pipe(8) mailer provides information to a
+    child process command line, environment variables, and standard input
+    stream, and expects a child process exit status code as defined in
+    <sysexits.h>. Examples of delivery via the pipe(8) mailer are in the
+    FILTER_README, MAILDROP_README, and UUCP_README documents.
 
 PPoossttffiixx bbeehhiinndd tthhee sscceenneess
 
@@ -237,11 +240,12 @@ queues.
                    message
                   logfiles
 
-  * The flush(8) servers maintain per-destination logs and implement both ETRN
-    and "sendmail -qRdestination", as described in the ETRN_README document.
-    This moves selected queue files from the deferred queue back to the
-    incoming queue and requests their delivery. The flush(8) service is
-    available with Postfix version 1.0 and later.
+  * The flush(8) servers maintain per-destination logs and implement "sendmail
+    -qRsite", "sendmail -qIqueueid" "postqueue -s site", "postqueue -
+    i queueid", and ETRN as described in the ETRN_README document. This moves
+    selected queue files from the deferred queue back to the incoming queue and
+    requests their delivery. The flush(8) service is available with Postfix
+    version 1.0 and later.
 
                                   incoming
                                      ^
@@ -282,16 +286,41 @@ queues.
     Postfix version 2.2 and later. More information about this feature is in
     the CONNECTION_CACHE_README document.
 
-            /-- smtp(8) --> Internet
+            /--  smtp(8)  --> Internet
 
-    qmgr(8)       |  
-                  |
-            \--   | smtp(8) --> Internet
-                  |
-                  ^          
-                  |
+    qmgr(8)
+                |
+            \-- |    smtp(8)
+                |
+                |     ^
+                v     |
 
-                  scache(8)
+                scache(8)
+
+    A Postfix smtp(8) client can reuse a TLS-encrypted connection (with
+    "smtp_tls_connection_reuse = yes"). This can greatly reduce the overhead of
+    connection setup and improves message delivery rates. After a Postfix smtp
+    (8) client connects to a remote SMTP server and sends plaintext EHLO and
+    STARTTLS commands, the smtp(8) client inserts a tlsproxy(8) process into
+    the connection as shown in the top of the figure below.
+
+            /--  smtp(8)  --> tlsproxy(8) --> Internet
+
+    qmgr(8)
+                |
+            \-- |    smtp(8)
+                |
+                |     ^
+                v     |
+
+                scache(8)
+
+    After the mail transaction completes, the Postfix smtp(8) client gives the
+    smtp(8)-to-tlsproxy(8) connection to the scache(8) server, which keeps the
+    connection open for a limited amount of time. The smtp(8) client continues
+    with some other mail delivery request. Meanwhile, any Postfix smtp(8)
+    client can ask the scache(8) server for that cached connection and reuse it
+    for mail delivery.
 
   * The showq(8) servers list the Postfix queue status. This is the queue
     listing service that does the work for the mailq(1) and postqueue(1)
@@ -324,7 +353,7 @@ queues.
 
                         <---seed---            ---seed--->
     Network-> smtpd(8)              tlsmgr(8)               smtp(8)  ->Network
-                        <-session->            <-session->      
+                        <-session->            <-session->
 
                                   /       |    \
                                           |
@@ -342,11 +371,9 @@ queues.
     This process is described in the ADDRESS_VERIFICATION_README document. The
     verify(8) service is available with Postfix version 2.1 and later.
 
-                               
                                              probe     Postfix
                                             message ->   mail
-                                                        queue
-    Network -> smtpd(8) <->   verify(8)  ->
+    Network -> smtpd(8) <->   verify(8)  ->             queue
 
                                                             |
                                                             v
@@ -356,7 +383,6 @@ queues.
                                     ^                   agents
                                     |
                                     v
-                                          
 
                               Address
                             verification
@@ -370,33 +396,51 @@ queues.
     While postscreen(8) keeps the zombies away, more smtpd(8) processes remain
     available for legitimate clients.
 
-    postscreen(8) maintains a temporary whitelist for clients that pass its
-    tests; by allowing whitelisted clients to skip tests, postscreen(8)
+    postscreen(8) maintains a temporary allowlist for clients that pass its
+    tests; by allowing allowlisted clients to skip tests, postscreen(8)
     minimizes its impact on legitimate email traffic.
 
     The postscreen(8) server is available with Postfix 2.8 and later. To keep
-    the implementation simple, postscreen(8) delegates DNS white/blacklist
+    the implementation simple, postscreen(8) delegates DNS allow/denylist
     lookups to dnsblog(8) server processes, and delegates TLS encryption/
     decryption to tlsproxy(8) server processes. This delegation is invisible to
-    the remote SMTP client, and is not shown in the diagram below.
+    the remote SMTP client.
 
-    zombie
+                zombie
 
-           \
+                         \
 
-    zombie -                    - smtpd(8)
+    zombie - tlsproxy(8) -                    - smtpd(8)
 
-             \               /
+                           \               /
 
-    other  --- postscreen(8)
+                 other   --- postscreen(8)
 
-             /               \
+                           /               \
 
-    other  -                    - smtpd(8)
+                 other   -                    - smtpd(8)
 
-           /
+                         /
 
-    zombie
+                zombie
+
+  * The postlogd(8) server provides an alternative to syslog logging, which
+    remains the default. This feature is available with Postfix version 3.4 or
+    later, and supports the following modes:
+
+      o Logging to file, which addresses a usability problem with MacOS, and
+        eliminates information loss caused by systemd rate limits.
+
+         commands    -> postlogd(8) -> /path/to/file
+        or daemons
+
+      o Logging to stdout, which eliminates a syslog dependency when Postfix
+        runs inside a container.
+
+         commands  -> postlogd(8) ->    stdout inherited
+        or daemons                   from "postfix start-fg"
+
+    See MAILLOG_README for details and limitations.
 
 PPoossttffiixx ssuuppppoorrtt ccoommmmaannddss
 

postfix/README_FILES/PCRE_README

@@ -11,36 +11,45 @@ This is because the pcre implementation is often more efficient than the POSIX
 regular expression implementation that you find on many systems.
 
 A description of how to use pcre tables, including examples, is given in the
-pcre_table(5) manual page. Information about PCRE itself can be found at http:/
-/www.pcre.org/.
+pcre_table(5) manual page. Information about PCRE itself can be found at https:
+//www.pcre.org/.
 
-BBuuiillddiinngg PPoossttffiixx wwiitthh PPCCRREE ssuuppppoorrtt
+UUssiinngg PPoossttffiixx ppaacckkaaggeess wwiitthh PPCCRREE ssuuppppoorrtt
+
+To use pcre with Debian GNU/Linux's Postfix, or with Fedora or RHEL Postfix,
+all you need is to install the postfix-pcre package and you're done. There is
+no need to recompile Postfix.
+
+BBuuiillddiinngg PPoossttffiixx ffrroomm ssoouurrccee wwiitthh PPCCRREE ssuuppppoorrtt
 
 These instructions assume that you build Postfix from source code as described
-in the INSTALL document. Some modification may be required if you build Postfix
-from a vendor-specific source package.
+in the INSTALL document.
 
-Note: to use pcre with Debian GNU/Linux's Postfix, all you need is to install
-the postfix-pcre package and you're done. There is no need to recompile
-Postfix.
+To build Postfix from source with pcre support, you need a pcre library.
+Install a vendor package, or download the source code from locations in https:/
+/www.pcre.org/ and build that yourself.
 
-In some future, Postfix will have a plug-in interface for adding map types.
-Until then, you need to compile PCRE support into Postfix.
+Postfix can build with the pcre2 library or the legacy pcre library. It's
+probably easiest to let the Postfix build procedure pick one. The following
+commands will first discover if the pcre2 library is installed, and if that is
+not available, will discover if the legacy pcre library is installed.
 
-First of all, you need the PCRE library (Perl Compatible Regular Expressions),
-which can be obtained from:
+    $ make -f Makefile.init makefiles
+    $ make
 
-    ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/.
+To build Postfix explicitly with a pcre2 library (Postfix 3.7 and later):
 
-NOTE: pcre versions prior to 2.06 cannot be used.
+    $ make -f Makefile.init makefiles \
+        "CCARGS=-DHAS_PCRE=2 `pcre2-config --cflags`" \
+        "AUXLIBS_PCRE=`pcre2-config --libs8`"
+    $ make
 
-In order to build Postfix with PCRE support you need to add -DHAS_PCRE and a -
-I option for the PCRE include file to CCARGS, and add the path to the PCRE
-library to AUXLIBS_PCRE, for example:
+To build Postfix explicitly with a legacy pcre library (all Postfix versions):
 
-    make -f Makefile.init makefiles \
-        "CCARGS=-DHAS_PCRE `pcre-config --cflags`" \
+    $ make -f Makefile.init makefiles \
+        "CCARGS=-DHAS_PCRE=1 `pcre-config --cflags`" \
         "AUXLIBS_PCRE=`pcre-config --libs`"
+    $ make
 
 Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_PCRE. With Postfix
 3.0 and later, the old AUXLIBS variable still supports building a statically-

postfix/README_FILES/PGSQL_README

@@ -33,8 +33,11 @@ For example:
 
     % make tidy
     % make -f Makefile.init makefiles \
-            'CCARGS=-DHAS_PGSQL -I/usr/local/include/pgsql' \
-            'AUXLIBS_PGSQL=-L/usr/local/lib -lpq'
+            "CCARGS=-DHAS_PGSQL -I/usr/local/include/pgsql" \
+            "AUXLIBS_PGSQL=-L/usr/local/lib -lpq"
+
+If your PostgreSQL shared library is in a directory that the RUN-TIME linker
+does not know about, add a "-Wl,-R,/path/to/directory" option after "-lpq".
 
 Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_PGSQL. With Postfix
 3.0 and later, the old AUXLIBS variable still supports building a statically-

postfix/README_FILES/POSTSCREEN_3_5_README

@@ -0,0 +1,863 @@
+PPoossttffiixx PPoossttssccrreeeenn HHoowwttoo ((PPoossttffiixx 22..88 -- 33..55))
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+This document describes features that are available in Postfix 2.8 - 3.5.
+
+The Postfix postscreen(8) daemon provides additional protection against mail
+server overload. One postscreen(8) process handles multiple inbound SMTP
+connections, and decides which clients may talk to a Postfix SMTP server
+process. By keeping spambots away, postscreen(8) leaves more SMTP server
+processes available for legitimate clients, and delays the onset of server
+overload conditions.
+
+postscreen(8) should not be used on SMTP ports that receive mail from end-user
+clients (MUAs). In a typical deployment, postscreen(8) handles the MX service
+on TCP port 25, while MUA clients submit mail via the submission service on TCP
+port 587 which requires client authentication. Alternatively, a site could set
+up a dedicated, non-postscreen, "port 25" server that provides submission
+service and client authentication, but no MX service.
+
+postscreen(8) maintains a temporary allowlist for clients that pass its tests;
+by allowing allowlisted clients to skip tests, postscreen(8) minimizes its
+impact on legitimate email traffic.
+
+postscreen(8) is part of a multi-layer defense.
+
+  * As the first layer, postscreen(8) blocks connections from zombies and other
+    spambots that are responsible for about 90% of all spam. It is implemented
+    as a single process to make this defense as inexpensive as possible.
+
+  * The second layer implements more complex SMTP-level access checks with
+    Postfix SMTP servers, policy daemons, and Milter applications.
+
+  * The third layer performs light-weight content inspection with the Postfix
+    built-in header_checks and body_checks. This can block unacceptable
+    attachments such as executable programs, and worms or viruses with easy-to-
+    recognize signatures.
+
+  * The fourth layer provides heavy-weight content inspection with external
+    content filters. Typical examples are Amavisd-new, SpamAssassin, and Milter
+    applications.
+
+Each layer reduces the spam volume. The general strategy is to use the less
+expensive defenses first, and to use the more expensive defenses only for the
+spam that remains.
+
+Topics in this document:
+
+  * Introduction
+  * The basic idea behind postscreen(8)
+  * General operation
+  * Quick tests before everything else
+  * Tests before the 220 SMTP server greeting
+  * Tests after the 220 SMTP server greeting
+  * Other errors
+  * When all tests succeed
+  * Configuring the postscreen(8) service
+  * Historical notes and credits
+
+TThhee bbaassiicc iiddeeaa bbeehhiinndd ppoossttssccrreeeenn((88))
+
+Most email is spam, and most spam is sent out by zombies (malware on
+compromised end-user computers). Wietse expects that the zombie problem will
+get worse before things improve, if ever. Without a tool like postscreen(8)
+that keeps the zombies away, Postfix would be spending most of its resources
+not receiving email.
+
+The main challenge for postscreen(8) is to make an is-a-zombie decision based
+on a single measurement. This is necessary because many zombies try to fly
+under the radar and avoid spamming the same site repeatedly. Once postscreen(8)
+decides that a client is not-a-zombie, it allowlists the client temporarily to
+avoid further delays for legitimate mail.
+
+Zombies have challenges too: they have only a limited amount of time to deliver
+spam before their IP address becomes denylisted. To speed up spam deliveries,
+zombies make compromises in their SMTP protocol implementation. For example,
+they speak before their turn, or they ignore responses from SMTP servers and
+continue sending mail even when the server tells them to go away.
+
+postscreen(8) uses a variety of measurements to recognize zombies. First,
+postscreen(8) determines if the remote SMTP client IP address is denylisted.
+Second, postscreen(8) looks for protocol compromises that are made to speed up
+delivery. These are good indicators for making is-a-zombie decisions based on
+single measurements.
+
+postscreen(8) does not inspect message content. Message content can vary from
+one delivery to the next, especially with clients that (also) send legitimate
+email. Content is not a good indicator for making is-a-zombie decisions based
+on single measurements, and that is the problem that postscreen(8) is focused
+on.
+
+GGeenneerraall ooppeerraattiioonn
+
+For each connection from an SMTP client, postscreen(8) performs a number of
+tests in the order as described below. Some tests introduce a delay of a few
+seconds. postscreen(8) maintains a temporary allowlist for clients that pass
+its tests; by allowing allowlisted clients to skip tests, postscreen(8)
+minimizes its impact on legitimate email traffic.
+
+By default, postscreen(8) hands off all connections to a Postfix SMTP server
+process after logging its findings. This mode is useful for non-destructive
+testing.
+
+In a typical production setting, postscreen(8) is configured to reject mail
+from clients that fail one or more tests, after logging the helo, sender and
+recipient information.
+
+Note: postscreen(8) is not an SMTP proxy; this is intentional. The purpose is
+to keep zombies away from Postfix, with minimal overhead for legitimate
+clients.
+
+QQuuiicckk tteessttss bbeeffoorree eevveerryytthhiinngg eellssee
+
+Before engaging in SMTP-level tests. postscreen(8) queries a number of local
+deny and allowlists. These tests speed up the handling of known clients.
+
+  * Permanent allow/denylist test
+  * Temporary allowlist test
+  * MX Policy test
+
+PPeerrmmaanneenntt aallllooww//ddeennyylliisstt tteesstt
+
+The postscreen_access_list parameter (default: permit_mynetworks) specifies a
+permanent access list for SMTP client IP addresses. Typically one would specify
+something that allowlists local networks, followed by a CIDR table for
+selective allow- and denylisting.
+
+Example:
+
+/etc/postfix/main.cf:
+    postscreen_access_list = permit_mynetworks,
+        cidr:/etc/postfix/postscreen_access.cidr
+
+/etc/postfix/postscreen_access.cidr:
+   # Rules are evaluated in the order as specified.
+   # Denylist 192.168.* except 192.168.0.1.
+   192.168.0.1          permit
+   192.168.0.0/16       reject
+
+See the postscreen_access_list manpage documentation for more details.
+
+When the SMTP client address matches a "permit" action, postscreen(8) logs this
+with the client address and port number as:
+
+    WWHHIITTEELLIISSTTEEDD [address]:port
+
+The allowlist action is not configurable: immediately hand off the connection
+to a Postfix SMTP server process.
+
+When the SMTP client address matches a "reject" action, postscreen(8) logs this
+with the client address and port number as:
+
+    BBLLAACCKKLLIISSTTEEDD [address]:port
+
+The postscreen_blacklist_action parameter specifies the action that is taken
+next. See "When tests fail before the 220 SMTP server greeting" below.
+
+TTeemmppoorraarryy aalllloowwlliisstt tteesstt
+
+The postscreen(8) daemon maintains a temporary allowlist for SMTP client IP
+addresses that have passed all the tests described below. The
+postscreen_cache_map parameter specifies the location of the temporary
+allowlist. The temporary allowlist is not used for SMTP client addresses that
+appear on the permanent access list.
+
+By default the temporary allowlist is not shared with other postscreen(8)
+daemons. See Sharing the temporary allowlist below for alternatives.
+
+When the SMTP client address appears on the temporary allowlist, postscreen(8)
+logs this with the client address and port number as:
+
+    PPAASSSS OOLLDD [address]:port
+
+The action is not configurable: immediately hand off the connection to a
+Postfix SMTP server process. The client is excluded from further tests until
+its temporary allowlist entry expires, as controlled with the postscreen_*_ttl
+parameters. Expired entries are silently renewed if possible.
+
+MMXX PPoolliiccyy tteesstt
+
+When the remote SMTP client is not on the static access list or temporary
+allowlist, postscreen(8) can implement a number of allowlist tests, before it
+grants the client a temporary allowlist status that allows it to talk to a
+Postfix SMTP server process.
+
+When postscreen(8) is configured to monitor all primary and backup MX
+addresses, it can refuse to allowlist clients that connect to a backup MX
+address only (an old spammer trick to take advantage of backup MX hosts with
+weaker anti-spam policies than primary MX hosts).
+
+    NOTE: The following solution is for small sites. Larger sites would have to
+    share the postscreen(8) cache between primary and backup MTAs, which would
+    introduce a common point of failure.
+
+  * First, configure the host to listen on both primary and backup MX
+    addresses. Use the appropriate ifconfig or ip command for the local
+    operating system, or update the appropriate configuration files and
+    "refresh" the network protocol stack.
+
+    Second, configure Postfix to listen on the new IP address (this step is
+    needed when you have specified inet_interfaces in main.cf).
+
+  * Then, configure postscreen(8) to deny the temporary allowlist status on the
+    backup MX address(es). An example for Wietse's server is:
+
+    /etc/postfix/main.cf:
+        postscreen_whitelist_interfaces = !168.100.189.8 static:all
+
+    Translation: allow clients to obtain the temporary allowlist status on all
+    server IP addresses except 168.100.189.8, which is a backup MX address.
+
+When a non-allowlisted client connects the backup MX address, postscreen(8)
+logs this with the client address and port number as:
+
+    CCOONNNNEECCTT ffrroomm [address]:port ttoo [[116688..110000..118899..88]]::2255
+    WWHHIITTEELLIISSTT VVEETTOO [address]:port
+
+Translation: the client at [address]:port connected to the backup MX address
+168.100.189.8 while it was not allowlisted. The client will not be granted the
+temporary allowlist status, even if passes all the allowlist tests described
+below.
+
+TTeessttss bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
+
+The postscreen_greet_wait parameter specifies a short time interval before the
+"220 text..." server greeting, where postscreen(8) can run a number of tests in
+parallel.
+
+When a good client passes these tests, and no "deep protocol tests" are
+configured, postscreen(8) adds the client to the temporary allowlist and hands
+off the "live" connection to a Postfix SMTP server process. The client can then
+continue as if postscreen(8) never even existed (except of course for the short
+postscreen_greet_wait delay).
+
+  * Pregreet test
+  * DNS Allow/denylist test
+  * When tests fail before the 220 SMTP server greeting
+
+PPrreeggrreeeett tteesstt
+
+The SMTP protocol is a classic example of a protocol where the server speaks
+before the client. postscreen(8) detects zombies that are in a hurry and that
+speak before their turn. This test is enabled by default.
+
+The postscreen_greet_banner parameter specifies the text portion of a "220-
+text..." teaser banner (default: $smtpd_banner). Note that this becomes the
+first part of a multi-line server greeting. The postscreen(8) daemon sends this
+before the postscreen_greet_wait timer is started. The purpose of the teaser
+banner is to confuse zombies so that they speak before their turn. It has no
+effect on SMTP clients that correctly implement the protocol.
+
+To avoid problems with poorly-implemented SMTP engines in network appliances or
+network testing tools, either exclude them from all tests with the
+postscreen_access_list feature or else specify an empty teaser banner:
+
+/etc/postfix/main.cf:
+    # Exclude broken clients by allowlisting. Clients in mynetworks
+    # should always be allowlisted.
+    postscreen_access_list = permit_mynetworks,
+        cidr:/etc/postfix/postscreen_access.cidr
+
+/etc/postfix/postscreen_access.cidr:
+    192.168.254.0/24 permit
+
+/etc/postfix/main.cf:
+    # Disable the teaser banner (try allowlisting first if you can).
+    postscreen_greet_banner =
+
+When an SMTP client sends a command before the postscreen_greet_wait time has
+elapsed, postscreen(8) logs this as:
+
+    PPRREEGGRREEEETT count aafftteerr time ffrroomm [address]:port text...
+
+Translation: the client at [address]:port sent count bytes before its turn to
+speak. This happened time seconds after the postscreen_greet_wait timer was
+started. The text is what the client sent (truncated to 100 bytes, and with
+non-printable characters replaced with C-style escapes such as \r for carriage-
+return and \n for newline).
+
+The postscreen_greet_action parameter specifies the action that is taken next.
+See "When tests fail before the 220 SMTP server greeting" below.
+
+DDNNSS AAllllooww//ddeennyylliisstt tteesstt
+
+The postscreen_dnsbl_sites parameter (default: empty) specifies a list of DNS
+blocklist servers with optional filters and weight factors (positive weights
+for denylisting, negative for allowlisting). These servers will be queried in
+parallel with the reverse client IP address. This test is disabled by default.
+
+    CAUTION: when postscreen rejects mail, its SMTP reply contains the DNSBL
+    domain name. Use the postscreen_dnsbl_reply_map feature to hide "password"
+    information in DNSBL domain names.
+
+When the postscreen_greet_wait time has elapsed, and the combined DNSBL score
+is equal to or greater than the postscreen_dnsbl_threshold parameter value,
+postscreen(8) logs this as:
+
+    DDNNSSBBLL rraannkk count ffoorr [address]:port
+
+Translation: the SMTP client at [address]:port has a combined DNSBL score of
+count.
+
+The postscreen_dnsbl_action parameter specifies the action that is taken when
+the combined DNSBL score is equal to or greater than the threshold. See "When
+tests fail before the 220 SMTP server greeting" below.
+
+WWhheenn tteessttss ffaaiill bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
+
+When the client address matches the permanent denylist, or when the client
+fails the pregreet or DNSBL tests, the action is specified with
+postscreen_blacklist_action, postscreen_greet_action, or
+postscreen_dnsbl_action, respectively.
+
+iiggnnoorree (default)
+    Ignore the failure of this test. Allow other tests to complete. Repeat this
+    test the next time the client connects. This option is useful for testing
+    and collecting statistics without blocking mail.
+eennffoorrccee
+    Allow other tests to complete. Reject attempts to deliver mail with a 550
+    SMTP reply, and log the helo/sender/recipient information. Repeat this test
+    the next time the client connects.
+ddrroopp
+    Drop the connection immediately with a 521 SMTP reply. Repeat this test the
+    next time the client connects.
+
+TTeessttss aafftteerr tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
+
+In this phase of the protocol, postscreen(8) implements a number of "deep
+protocol" tests. These tests use an SMTP protocol engine that is built into the
+postscreen(8) server.
+
+Important note: these protocol tests are disabled by default. They are more
+intrusive than the pregreet and DNSBL tests, and they have limitations as
+discussed next.
+
+  * The main limitation of "after 220 greeting" tests is that a new client must
+    disconnect after passing these tests (reason: postscreen is not a proxy).
+    Then the client must reconnect from the same IP address before it can
+    deliver mail. The following measures may help to avoid email delays:
+
+      o Allow "good" clients to skip tests with the
+        postscreen_dnsbl_whitelist_threshold feature (Postfix 2.11 and later).
+        This is especially effective for sites such as Google that never retry
+        immediately from the same IP address.
+
+      o Small sites: Configure postscreen(8) to listen on multiple IP
+        addresses, published in DNS as different IP addresses for the same MX
+        hostname or for different MX hostnames. This avoids mail delivery
+        delays with clients that reconnect immediately from the same IP
+        address.
+
+      o Large sites: Share the postscreen(8) cache between different Postfix
+        MTAs with a large-enough memcache_table(5). Again, this avoids mail
+        delivery delays with clients that reconnect immediately from the same
+        IP address.
+
+  * postscreen(8)'s built-in SMTP engine does not implement the AUTH, XCLIENT,
+    and XFORWARD features. If you need to make these services available on port
+    25, then do not enable the tests after the 220 server greeting.
+
+  * End-user clients should connect directly to the submission service, so that
+    they never have to deal with postscreen(8)'s tests.
+
+The following "after 220 greeting" tests are available:
+
+  * Command pipelining test
+  * Non-SMTP command test
+  * Bare newline test
+  * When tests fail after the 220 SMTP server greeting
+
+CCoommmmaanndd ppiippeelliinniinngg tteesstt
+
+By default, SMTP is a half-duplex protocol: the sender and receiver send one
+command and one response at a time. Unlike the Postfix SMTP server, postscreen
+(8) does not announce support for ESMTP command pipelining. Therefore, clients
+are not allowed to send multiple commands. postscreen(8)'s deep protocol test
+for this is disabled by default.
+
+With "postscreen_pipelining_enable = yes", postscreen(8) detects zombies that
+send multiple commands, instead of sending one command and waiting for the
+server to reply.
+
+This test is opportunistically enabled when postscreen(8) has to use the built-
+in SMTP engine anyway. This is to make postscreen(8) logging more informative.
+
+When a client sends multiple commands, postscreen(8) logs this as:
+
+    CCOOMMMMAANNDD PPIIPPEELLIINNIINNGG ffrroomm [address]:port aafftteerr command: text
+
+Translation: the SMTP client at [address]:port sent multiple SMTP commands,
+instead of sending one command and then waiting for the server to reply. This
+happened after the client sent command. The text shows part of the input that
+was sent too early; it is not logged with Postfix 2.8.
+
+The postscreen_pipelining_action parameter specifies the action that is taken
+next. See "When tests fail after the 220 SMTP server greeting" below.
+
+NNoonn--SSMMTTPP ccoommmmaanndd tteesstt
+
+Some spambots send their mail through open proxies. A symptom of this is the
+usage of commands such as CONNECT and other non-SMTP commands. Just like the
+Postfix SMTP server's smtpd_forbidden_commands feature, postscreen(8) has an
+equivalent postscreen_forbidden_commands feature to block these clients.
+postscreen(8)'s deep protocol test for this is disabled by default.
+
+With "postscreen_non_smtp_command_enable = yes", postscreen(8) detects zombies
+that send commands specified with the postscreen_forbidden_commands parameter.
+This also detects commands with the syntax of a message header label. The
+latter is a symptom that the client is sending message content after ignoring
+all the responses from postscreen(8) that reject mail.
+
+This test is opportunistically enabled when postscreen(8) has to use the built-
+in SMTP engine anyway. This is to make postscreen(8) logging more informative.
+
+When a client sends non-SMTP commands, postscreen(8) logs this as:
+
+    NNOONN--SSMMTTPP CCOOMMMMAANNDD ffrroomm [address]:port aafftteerr command: text
+
+Translation: the SMTP client at [address]:port sent a command that matches the
+postscreen_forbidden_commands parameter, or that has the syntax of a message
+header label (text followed by optional space and ":"). The "aafftteerr command"
+portion is logged with Postfix 2.10 and later.
+
+The postscreen_non_smtp_command_action parameter specifies the action that is
+taken next. See "When tests fail after the 220 SMTP server greeting" below.
+
+BBaarree nneewwlliinnee tteesstt
+
+SMTP is a line-oriented protocol: lines have a limited length, and are
+terminated with <CR><LF>. Lines ending in a "bare" <LF>, that is newline not
+preceded by carriage return, are not allowed in SMTP. postscreen(8)'s deep
+protocol test for this is disabled by default.
+
+With "postscreen_bare_newline_enable = yes", postscreen(8) detects clients that
+send lines ending in bare newline characters.
+
+This test is opportunistically enabled when postscreen(8) has to use the built-
+in SMTP engine anyway. This is to make postscreen(8) logging more informative.
+
+When a client sends bare newline characters, postscreen(8) logs this as:
+
+    BBAARREE NNEEWWLLIINNEE ffrroomm [address]:port aafftteerr command
+
+Translation: the SMTP client at [address]:port sent a bare newline character,
+that is newline not preceded by carriage return. The "aafftteerr command" portion is
+logged with Postfix 2.10 and later.
+
+The postscreen_bare_newline_action parameter specifies the action that is taken
+next. See "When tests fail after the 220 SMTP server greeting" below.
+
+WWhheenn tteessttss ffaaiill aafftteerr tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
+
+When the client fails the pipelining, non-SMTP command or bare newline tests,
+the action is specified with postscreen_pipelining_action,
+postscreen_non_smtp_command_action or postscreen_bare_newline_action,
+respectively.
+
+iiggnnoorree (default for bare newline)
+    Ignore the failure of this test. Allow other tests to complete. Do NOT
+    repeat this test before the result from some other test expires. This
+    option is useful for testing and collecting statistics without blocking
+    mail permanently.
+eennffoorrccee (default for pipelining)
+    Allow other tests to complete. Reject attempts to deliver mail with a 550
+    SMTP reply, and log the helo/sender/recipient information. Repeat this test
+    the next time the client connects.
+ddrroopp (default for non-SMTP commands)
+    Drop the connection immediately with a 521 SMTP reply. Repeat this test the
+    next time the client connects. This action is compatible with the Postfix
+    SMTP server's smtpd_forbidden_commands feature.
+
+OOtthheerr eerrrroorrss
+
+When an SMTP client hangs up unexpectedly, postscreen(8) logs this as:
+
+    HHAANNGGUUPP aafftteerr time ffrroomm [address]:port iinn test name
+
+Translation: the SMTP client at [address]:port disconnected unexpectedly, time
+seconds after the start of the test named test name.
+
+There is no punishment for hanging up. A client that hangs up without sending
+the QUIT command can still pass all postscreen(8) tests.
+
+The following errors are reported by the built-in SMTP engine. This engine
+never accepts mail, therefore it has per-session limits on the number of
+commands and on the session length.
+
+    CCOOMMMMAANNDD TTIIMMEE LLIIMMIITT ffrroomm [address]:port aafftteerr command
+
+Translation: the SMTP client at [address]:port reached the per-command time
+limit as specified with the postscreen_command_time_limit parameter. The
+session is terminated immediately. The "aafftteerr command" portion is logged with
+Postfix 2.10 and later.
+
+    CCOOMMMMAANNDD CCOOUUNNTT LLIIMMIITT ffrroomm [address]:port aafftteerr command
+
+Translation: the SMTP client at [address]:port reached the per-session command
+count limit as specified with the postscreen_command_count_limit parameter. The
+session is terminated immediately. The "aafftteerr command" portion is logged with
+Postfix 2.10 and later.
+
+    CCOOMMMMAANNDD LLEENNGGTTHH LLIIMMIITT ffrroomm [address]:port aafftteerr command
+
+Translation: the SMTP client at [address]:port reached the per-command length
+limit, as specified with the line_length_limit parameter. The session is
+terminated immediately. The "aafftteerr command" portion is logged with Postfix 2.10
+and later.
+
+When an SMTP client makes too many connections at the same time, postscreen(8)
+rejects the connection with a 421 status code and logs:
+
+    NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: ttoooo mmaannyy ccoonnnneeccttiioonnss
+
+The postscreen_client_connection_count_limit parameter controls this limit.
+
+When an SMTP client connects after postscreen(8) has reached a connection count
+limit, postscreen(8) rejects the connection with a 421 status code and logs:
+
+    NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: aallll ssccrreeeenniinngg ppoorrttss bbuussyy
+    NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: aallll sseerrvveerr ppoorrttss bbuussyy
+
+The postscreen_pre_queue_limit and postscreen_post_queue_limit parameters
+control these limits.
+
+WWhheenn aallll tteessttss ssuucccceeeedd
+
+When a new SMTP client passes all tests (i.e. it is not allowlisted via some
+mechanism), postscreen(8) logs this as:
+
+    PPAASSSS NNEEWW [address]:port
+
+Where [address]:port are the client IP address and port. Then, postscreen(8)
+creates a temporary allowlist entry that excludes the client IP address from
+further tests until the temporary allowlist entry expires, as controlled with
+the postscreen_*_ttl parameters.
+
+When no "deep protocol tests" are configured, postscreen(8) hands off the
+"live" connection to a Postfix SMTP server process. The client can then
+continue as if postscreen(8) never even existed (except for the short
+postscreen_greet_wait delay).
+
+When any "deep protocol tests" are configured, postscreen(8) cannot hand off
+the "live" connection to a Postfix SMTP server process in the middle of the
+session. Instead, postscreen(8) defers mail delivery attempts with a 4XX
+status, logs the helo/sender/recipient information, and waits for the client to
+disconnect. The next time the client connects it will be allowed to talk to a
+Postfix SMTP server process to deliver its mail. postscreen(8) mitigates the
+impact of this limitation by giving deep protocol tests a long expiration time.
+
+CCoonnffiigguurriinngg tthhee ppoossttssccrreeeenn((88)) sseerrvviiccee
+
+postscreen(8) has been tested on FreeBSD [4-8], Linux 2.[4-6] and Solaris 9
+systems.
+
+  * Turning on postscreen(8) without blocking mail
+  * postscreen(8) TLS configuration
+  * Blocking mail with postscreen(8)
+  * Turning off postscreen(8)
+  * Sharing the temporary allowlist
+
+TTuurrnniinngg oonn ppoossttssccrreeeenn((88)) wwiitthhoouutt bblloocckkiinngg mmaaiill
+
+To enable the postscreen(8) service and log client information without blocking
+mail:
+
+ 1. Make sure that local clients and systems with non-standard SMTP
+    implementations are excluded from any postscreen(8) tests. The default is
+    to exclude all clients in mynetworks. To exclude additional clients, for
+    example, third-party performance monitoring tools (these tend to have
+    broken SMTP implementations):
+
+    /etc/postfix/main.cf:
+        # Exclude broken clients by allowlisting. Clients in mynetworks
+        # should always be allowlisted.
+        postscreen_access_list = permit_mynetworks,
+            cidr:/etc/postfix/postscreen_access.cidr
+
+    /etc/postfix/postscreen_access.cidr:
+        192.168.254.0/24 permit
+
+ 2. Comment out the "smtp inet ... smtpd" service in master.cf, including any
+    "-o parameter=value" entries that follow.
+
+    /etc/postfix/master.cf:
+        #smtp      inet  n       -       n       -       -       smtpd
+        #    -o parameter=value ...
+
+ 3. Uncomment the new "smtpd pass ... smtpd" service in master.cf, and
+    duplicate any "-o parameter=value" entries from the smtpd service that was
+    commented out in the previous step.
+
+    /etc/postfix/master.cf:
+        smtpd     pass  -       -       n       -       -       smtpd
+            -o parameter=value ...
+
+ 4. Uncomment the new "smtp inet ... postscreen" service in master.cf.
+
+    /etc/postfix/master.cf:
+        smtp      inet  n       -       n       -       1       postscreen
+
+ 5. Uncomment the new "tlsproxy unix ... tlsproxy" service in master.cf. This
+    service implements STARTTLS support for postscreen(8).
+
+    /etc/postfix/master.cf:
+        tlsproxy  unix  -       -       n       -       0       tlsproxy
+
+ 6. Uncomment the new "dnsblog unix ... dnsblog" service in master.cf. This
+    service does DNSBL lookups for postscreen(8) and logs results.
+
+    /etc/postfix/master.cf:
+        dnsblog   unix  -       -       n       -       0       dnsblog
+
+ 7. To enable DNSBL lookups, list some DNS blocklist sites in main.cf,
+    separated by whitespace. Different sites can have different weights. For
+    example:
+
+    /etc/postfix/main.cf:
+        postscreen_dnsbl_threshold = 2
+        postscreen_dnsbl_sites = zen.spamhaus.org*2
+            bl.spamcop.net*1 b.barracudacentral.org*1
+
+    Note: if your DNSBL queries have a "secret" in the domain name, you must
+    censor this information from the postscreen(8) SMTP replies. For example:
+
+    /etc/postfix/main.cf:
+        postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
+
+    /etc/postfix/dnsbl_reply:
+        # Secret DNSBL name           Name in postscreen(8) replies
+        secret.zen.dq.spamhaus.net    zen.spamhaus.org
+
+    The texthash: format is similar to hash: except that there is no need to
+    run postmap(1) before the file can be used, and that it does not detect
+    changes after the file is read. It is new with Postfix version 2.8.
+
+ 8. Read the new configuration with "postfix reload".
+
+Notes:
+
+  * Some postscreen(8) configuration parameters implement stress-dependent
+    behavior. This is supported only when the default value is stress-dependent
+    (that is, "postconf -d parametername" output shows "parametername = $
+    {stress?something}${stress:something}" or "parametername = ${stress?
+    {something}:{something}}"). Other parameters always evaluate as if the
+    stress value is the empty string.
+
+  * See "Tests before the 220 SMTP server greeting" for details about the
+    logging from these postscreen(8) tests.
+
+  * If you run Postfix 2.6 or earlier you must stop and start the master daemon
+    ("postfix stop; postfix start"). This is needed because the Postfix "pass"
+    master service type did not work reliably on all systems.
+
+ppoossttssccrreeeenn((88)) TTLLSS ccoonnffiigguurraattiioonn
+
+postscreen(8) TLS support is available for remote SMTP clients that aren't
+allowlisted, including clients that need to renew their temporary allowlist
+status. When a remote SMTP client requests TLS service, postscreen(8) invisibly
+hands off the connection to a tlsproxy(8) process. Then, tlsproxy(8) encrypts
+and decrypts the traffic between postscreen(8) and the remote SMTP client. One
+tlsproxy(8) process can handle multiple SMTP sessions. The number of tlsproxy
+(8) processes slowly increases with server load, but it should always be much
+smaller than the number of postscreen(8) TLS sessions.
+
+TLS support for postscreen(8) and tlsproxy(8) uses the same parameters as with
+smtpd(8). We recommend that you keep the relevant configuration parameters in
+main.cf. If you must specify "-o smtpd_mumble=value" parameter overrides in
+master.cf for a postscreen-protected smtpd(8) service, then you should specify
+those same parameter overrides for the postscreen(8) and tlsproxy(8) services.
+
+BBlloocckkiinngg mmaaiill wwiitthh ppoossttssccrreeeenn((88))
+
+For compatibility with smtpd(8), postscreen(8) implements the soft_bounce
+safety feature. This causes Postfix to reject mail with a "try again" reply
+code.
+
+  * To turn this on for all of Postfix, specify "soft_bounce = yes" in main.cf.
+
+  * To turn this on for postscreen(8) only, append "-o soft_bounce=yes" (note:
+    NO SPACES around '=') to the postscreen entry in master.cf.
+
+Execute "postfix reload" to make the change effective.
+
+After testing, do not forget to remove the soft_bounce feature, otherwise
+senders won't receive their non-delivery notification until many days later.
+
+To use the postscreen(8) service to block mail, edit main.cf and specify one or
+more of:
+
+  * "postscreen_dnsbl_action = enforce", to reject clients that are on DNS
+    blocklists, and to log the helo/sender/recipient information. With good
+    DNSBLs this reduces the amount of load on Postfix SMTP servers
+    dramatically.
+
+  * "postscreen_greet_action = enforce", to reject clients that talk before
+    their turn, and to log the helo/sender/recipient information. This stops
+    over half of all known-to-be illegitimate connections to Wietse's mail
+    server. It is backup protection for zombies that haven't yet been
+    denylisted.
+
+  * You can also enable "deep protocol tests", but these are more intrusive
+    than the pregreet or DNSBL tests.
+
+    When a good client passes the "deep protocol tests", postscreen(8) adds the
+    client to the temporary allowlist but it cannot hand off the "live"
+    connection to a Postfix SMTP server process in the middle of the session.
+    Instead, postscreen(8) defers mail delivery attempts with a 4XX status,
+    logs the helo/sender/recipient information, and waits for the client to
+    disconnect.
+
+    When the good client comes back in a later session, it is allowed to talk
+    directly to a Postfix SMTP server. See "Tests after the 220 SMTP server
+    greeting" above for limitations with AUTH and other features that clients
+    may need.
+
+    An unexpected benefit from "deep protocol tests" is that some "good"
+    clients don't return after the 4XX reply; these clients were not so good
+    after all.
+
+    Unfortunately, some senders will retry requests from different IP
+    addresses, and may never get allowlisted. For this reason, Wietse stopped
+    using "deep protocol tests" on his own internet-facing mail server.
+
+  * There is also support for permanent denylisting and allowlisting; see the
+    description of the postscreen_access_list parameter for details.
+
+TTuurrnniinngg ooffff ppoossttssccrreeeenn((88))
+
+To turn off postscreen(8) and handle mail directly with Postfix SMTP server
+processes:
+
+ 1. Comment out the "smtp inet ... postscreen" service in master.cf, including
+    any "-o parameter=value" entries that follow.
+
+    /etc/postfix/master.cf:
+        #smtp      inet  n       -       n       -       1       postscreen
+        #    -o parameter=value ...
+
+ 2. Comment out the "dnsblog unix ... dnsblog" service in master.cf.
+
+    /etc/postfix/master.cf:
+        #dnsblog   unix  -       -       n       -       0       dnsblog
+
+ 3. Comment out the "smtpd pass ... smtpd" service in master.cf, including any
+    "-o parameter=value" entries that follow.
+
+    /etc/postfix/master.cf:
+        #smtpd     pass  -       -       n       -       -       smtpd
+        #    -o parameter=value ...
+
+ 4. Comment out the "tlsproxy unix ... tlsproxy" service in master.cf,
+    including any "-o parameter=value" entries that follow.
+
+    /etc/postfix/master.cf:
+        #tlsproxy  unix  -       -       n       -       0       tlsproxy
+        #    -o parameter=value ...
+
+ 5. Uncomment the "smtp inet ... smtpd" service in master.cf, including any "-
+    o parameter=value" entries that may follow.
+
+    /etc/postfix/master.cf:
+        smtp       inet  n       -       n       -       -       smtpd
+            -o parameter=value ...
+
+ 6. Read the new configuration with "postfix reload".
+
+SShhaarriinngg tthhee tteemmppoorraarryy aalllloowwlliisstt
+
+By default, the temporary allowlist is not shared between multiple postscreen
+(8) daemons. To enable sharing, choose one of the following options:
+
+  * A non-persistent memcache: temporary allowlist can be shared between
+    postscreen(8) daemons on the same host or different hosts. Disable cache
+    cleanup (postscreen_cache_cleanup_interval = 0) in all postscreen(8)
+    daemons because memcache: has no first-next API (but see example 4 below
+    for memcache: with persistent backup). This requires Postfix 2.9 or later.
+
+        # Example 1: non-persistent memcache: allowlist.
+        /etc/postfix/main.cf:
+            postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
+            postscreen_cache_cleanup_interval = 0
+
+        /etc/postfix/postscreen_cache:
+            memcache = inet:127.0.0.1:11211
+            key_format = postscreen:%s
+
+  * A persistent lmdb: temporary allowlist can be shared between postscreen(8)
+    daemons that run under the same master(8) daemon, or under different master
+    (8) daemons on the same host. Disable cache cleanup
+    (postscreen_cache_cleanup_interval = 0) in all postscreen(8) daemons except
+    one that is responsible for cache cleanup. This requires Postfix 2.11 or
+    later.
+
+        # Example 2: persistent lmdb: allowlist.
+        /etc/postfix/main.cf:
+            postscreen_cache_map = lmdb:$data_directory/postscreen_cache
+            # See note 1 below.
+            # postscreen_cache_cleanup_interval = 0
+
+  * Other kinds of persistent temporary allowlist can be shared only between
+    postscreen(8) daemons that run under the same master(8) daemon. In this
+    case, temporary allowlist access must be shared through the proxymap(8)
+    daemon. This requires Postfix 2.9 or later.
+
+        # Example 3: proxied btree: allowlist.
+        /etc/postfix/main.cf:
+            postscreen_cache_map =
+                proxy:btree:/var/lib/postfix/postscreen_cache
+            # See note 1 below.
+            # postscreen_cache_cleanup_interval = 0
+
+        # Example 4: proxied btree: allowlist with memcache: accelerator.
+        /etc/postfix/main.cf:
+            postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
+            proxy_write_maps =
+                proxy:btree:/var/lib/postfix/postscreen_cache
+                ... other proxied tables ...
+            # See note 1 below.
+            # postscreen_cache_cleanup_interval = 0
+
+        /etc/postfix/postscreen_cache:
+            # Note: the $data_directory macro is not defined in this context.
+            memcache = inet:127.0.0.1:11211
+            backup = proxy:btree:/var/lib/postfix/postscreen_cache
+            key_format = postscreen:%s
+
+    Note 1: disable cache cleanup (postscreen_cache_cleanup_interval = 0) in
+    all postscreen(8) daemons except one that is responsible for cache cleanup.
+
+    Note 2: postscreen(8) cache sharing via proxymap(8) requires Postfix 2.9 or
+    later; earlier proxymap(8) implementations don't support cache cleanup.
+
+HHiissttoorriiccaall nnootteess aanndd ccrreeddiittss
+
+Many ideas in postscreen(8) were explored in earlier work by Michael Tokarev,
+in OpenBSD spamd, and in MailChannels Traffic Control.
+
+Wietse threw together a crude prototype with pregreet and dnsbl support in June
+2009, because he needed something new for a Mailserver conference presentation
+in July. Ralf Hildebrandt ran this code on several servers to collect real-
+world statistics. This version used the dnsblog(8) ad-hoc DNS client program.
+
+Wietse needed new material for a LISA conference presentation in November 2010,
+so he added support for DNSBL weights and filters in August, followed by a
+major code rewrite, deep protocol tests, helo/sender/recipient logging, and
+stress-adaptive behavior in September. Ralf Hildebrandt ran this code on
+several servers to collect real-world statistics. This version still used the
+embarrassing dnsblog(8) ad-hoc DNS client program.
+
+Wietse added STARTTLS support in December 2010. This makes postscreen(8) usable
+for sites that require TLS support. The implementation introduces the tlsproxy
+(8) event-driven TLS proxy that decrypts/encrypts the sessions for multiple
+SMTP clients.
+
+The tlsproxy(8) implementation led to the discovery of a "new" class of
+vulnerability (CVE-2011-0411) that affected multiple implementations of SMTP,
+POP, IMAP, NNTP, and FTP over TLS.
+
+postscreen(8) was officially released as part of the Postfix 2.8 stable release
+in January 2011.
+

postfix/README_FILES/POSTSCREEN_README

@@ -4,7 +4,8 @@ PPoossttffiixx PPoossttssccrreeeenn HHoowwttoo
 
 IInnttrroodduuccttiioonn
 
-This document describes features that are available in Postfix 2.8 and later.
+This document describes features that are available in Postfix 3.6 and later.
+See POSTSCREEN_3_5_README.html for Postfix versions 2.8 - 3.5.
 
 The Postfix postscreen(8) daemon provides additional protection against mail
 server overload. One postscreen(8) process handles multiple inbound SMTP
@@ -20,8 +21,8 @@ port 587 which requires client authentication. Alternatively, a site could set
 up a dedicated, non-postscreen, "port 25" server that provides submission
 service and client authentication, but no MX service.
 
-postscreen(8) maintains a temporary whitelist for clients that pass its tests;
-by allowing whitelisted clients to skip tests, postscreen(8) minimizes its
+postscreen(8) maintains a temporary allowlist for clients that pass its tests;
+by allowing allowlisted clients to skip tests, postscreen(8) minimizes its
 impact on legitimate email traffic.
 
 postscreen(8) is part of a multi-layer defense.
@@ -70,17 +71,17 @@ not receiving email.
 The main challenge for postscreen(8) is to make an is-a-zombie decision based
 on a single measurement. This is necessary because many zombies try to fly
 under the radar and avoid spamming the same site repeatedly. Once postscreen(8)
-decides that a client is not-a-zombie, it whitelists the client temporarily to
+decides that a client is not-a-zombie, it allowlists the client temporarily to
 avoid further delays for legitimate mail.
 
 Zombies have challenges too: they have only a limited amount of time to deliver
-spam before their IP address becomes blacklisted. To speed up spam deliveries,
+spam before their IP address becomes denylisted. To speed up spam deliveries,
 zombies make compromises in their SMTP protocol implementation. For example,
 they speak before their turn, or they ignore responses from SMTP servers and
-continue sending mail even when the server tells them to go away.
+continue sending commands even when the server tells them to go away.
 
 postscreen(8) uses a variety of measurements to recognize zombies. First,
-postscreen(8) determines if the remote SMTP client IP address is blacklisted.
+postscreen(8) determines if the remote SMTP client IP address is denylisted.
 Second, postscreen(8) looks for protocol compromises that are made to speed up
 delivery. These are good indicators for making is-a-zombie decisions based on
 single measurements.
@@ -95,8 +96,8 @@ GGeenneerraall ooppeerraattiioonn
 
 For each connection from an SMTP client, postscreen(8) performs a number of
 tests in the order as described below. Some tests introduce a delay of a few
-seconds. postscreen(8) maintains a temporary whitelist for clients that pass
-its tests; by allowing whitelisted clients to skip tests, postscreen(8)
+seconds. postscreen(8) maintains a temporary allowlist for clients that pass
+its tests; by allowing allowlisted clients to skip tests, postscreen(8)
 minimizes its impact on legitimate email traffic.
 
 By default, postscreen(8) hands off all connections to a Postfix SMTP server
@@ -113,19 +114,19 @@ clients.
 
 QQuuiicckk tteessttss bbeeffoorree eevveerryytthhiinngg eellssee
 
-Before engaging in SMTP-level tests. postscreen(8) queries a number of local
-black and whitelists. These tests speed up the handling of known clients.
+Before engaging in SMTP-level tests, postscreen(8) queries a number of local
+deny and allowlists. These tests speed up the handling of known clients.
 
-  * Permanent white/blacklist test
-  * Temporary whitelist test
+  * Permanent allow/denylist test
+  * Temporary allowlist test
   * MX Policy test
 
-PPeerrmmaanneenntt wwhhiittee//bbllaacckklliisstt tteesstt
+PPeerrmmaanneenntt aallllooww//ddeennyylliisstt tteesstt
 
 The postscreen_access_list parameter (default: permit_mynetworks) specifies a
 permanent access list for SMTP client IP addresses. Typically one would specify
-something that whitelists local networks, followed by a CIDR table for
-selective white- and blacklisting.
+something that allowlists local networks, followed by a CIDR table for
+selective allow- and denylisting.
 
 Example:
 
@@ -135,7 +136,7 @@ Example:
 
 /etc/postfix/postscreen_access.cidr:
    # Rules are evaluated in the order as specified.
-   # Blacklist 192.168.* except 192.168.0.1.
+   # Denylist 192.168.* except 192.168.0.1.
    192.168.0.1          permit
    192.168.0.0/16       reject
 
@@ -144,49 +145,55 @@ See the postscreen_access_list manpage documentation for more details.
 When the SMTP client address matches a "permit" action, postscreen(8) logs this
 with the client address and port number as:
 
-    WWHHIITTEELLIISSTTEEDD [address]:port
+    AALLLLOOWWLLIISSTTEEDD [address]:port
 
-The whitelist action is not configurable: immediately hand off the connection
+    Use the respectful_logging configuration parameter to select a deprecated
+    form of this logging.
+
+The allowlist action is not configurable: immediately hand off the connection
 to a Postfix SMTP server process.
 
 When the SMTP client address matches a "reject" action, postscreen(8) logs this
 with the client address and port number as:
 
-    BBLLAACCKKLLIISSTTEEDD [address]:port
+    DDEENNYYLLIISSTTEEDD [address]:port
 
-The postscreen_blacklist_action parameter specifies the action that is taken
+    Use the respectful_logging configuration parameter to select a deprecated
+    form of this logging.
+
+The postscreen_denylist_action parameter specifies the action that is taken
 next. See "When tests fail before the 220 SMTP server greeting" below.
 
-TTeemmppoorraarryy wwhhiitteelliisstt tteesstt
+TTeemmppoorraarryy aalllloowwlliisstt tteesstt
 
-The postscreen(8) daemon maintains a temporary whitelist for SMTP client IP
+The postscreen(8) daemon maintains a temporary allowlist for SMTP client IP
 addresses that have passed all the tests described below. The
 postscreen_cache_map parameter specifies the location of the temporary
-whitelist. The temporary whitelist is not used for SMTP client addresses that
+allowlist. The temporary allowlist is not used for SMTP client addresses that
 appear on the permanent access list.
 
-By default the temporary whitelist is not shared with other postscreen(8)
-daemons. See Sharing the temporary whitelist below for alternatives.
+By default the temporary allowlist is not shared with other postscreen(8)
+daemons. See Sharing the temporary allowlist below for alternatives.
 
-When the SMTP client address appears on the temporary whitelist, postscreen(8)
+When the SMTP client address appears on the temporary allowlist, postscreen(8)
 logs this with the client address and port number as:
 
     PPAASSSS OOLLDD [address]:port
 
 The action is not configurable: immediately hand off the connection to a
 Postfix SMTP server process. The client is excluded from further tests until
-its temporary whitelist entry expires, as controlled with the postscreen_*_ttl
+its temporary allowlist entry expires, as controlled with the postscreen_*_ttl
 parameters. Expired entries are silently renewed if possible.
 
 MMXX PPoolliiccyy tteesstt
 
 When the remote SMTP client is not on the static access list or temporary
-whitelist, postscreen(8) can implement a number of whitelist tests, before it
-grants the client a temporary whitelist status that allows it to talk to a
+allowlist, postscreen(8) can implement a number of allowlist tests, before it
+grants the client a temporary allowlist status that allows it to talk to a
 Postfix SMTP server process.
 
 When postscreen(8) is configured to monitor all primary and backup MX
-addresses, it can refuse to whitelist clients that connect to a backup MX
+addresses, it can refuse to allowlist clients that connect to a backup MX
 address only (an old spammer trick to take advantage of backup MX hosts with
 weaker anti-spam policies than primary MX hosts).
 
@@ -195,31 +202,34 @@ weaker anti-spam policies than primary MX hosts).
     introduce a common point of failure.
 
   * First, configure the host to listen on both primary and backup MX
-    addresses. Use the appropriate ifconfig command for the local operating
-    system, or update the appropriate configuration files and "refresh" the
-    network protocol stack.
+    addresses. Use the appropriate ifconfig or ip command for the local
+    operating system, or update the appropriate configuration files and
+    "refresh" the network protocol stack.
 
     Second, configure Postfix to listen on the new IP address (this step is
     needed when you have specified inet_interfaces in main.cf).
 
-  * Then, configure postscreen(8) to deny the temporary whitelist status on the
+  * Then, configure postscreen(8) to deny the temporary allowlist status on the
     backup MX address(es). An example for Wietse's server is:
 
     /etc/postfix/main.cf:
-        postscreen_whitelist_interfaces = !168.100.189.8 static:all
+        postscreen_allowlist_interfaces = !168.100.189.8 static:all
 
-    Translation: allow clients to obtain the temporary whitelist status on all
+    Translation: allow clients to obtain the temporary allowlist status on all
     server IP addresses except 168.100.189.8, which is a backup MX address.
 
-When a non-whitelisted client connects the backup MX address, postscreen(8)
+When a non-allowlisted client connects the backup MX address, postscreen(8)
 logs this with the client address and port number as:
 
     CCOONNNNEECCTT ffrroomm [address]:port ttoo [[116688..110000..118899..88]]::2255
-    WWHHIITTEELLIISSTT VVEETTOO [address]:port
+    AALLLLOOWWLLIISSTT VVEETTOO [address]:port
+
+    Use the respectful_logging configuration parameter to select a deprecated
+    form of this logging.
 
 Translation: the client at [address]:port connected to the backup MX address
-168.100.189.8 while it was not whitelisted. The client will not be granted the
-temporary whitelist status, even if passes all the whitelist tests described
+168.100.189.8 while it was not allowlisted. The client will not be granted the
+temporary allowlist status, even if passes all the allowlist tests described
 below.
 
 TTeessttss bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
@@ -229,13 +239,13 @@ The postscreen_greet_wait parameter specifies a short time interval before the
 parallel.
 
 When a good client passes these tests, and no "deep protocol tests" are
-configured, postscreen(8) adds the client to the temporary whitelist and hands
+configured, postscreen(8) adds the client to the temporary allowlist and hands
 off the "live" connection to a Postfix SMTP server process. The client can then
 continue as if postscreen(8) never even existed (except of course for the short
 postscreen_greet_wait delay).
 
   * Pregreet test
-  * DNS White/blacklist test
+  * DNS Allow/denylist test
   * When tests fail before the 220 SMTP server greeting
 
 PPrreeggrreeeett tteesstt
@@ -256,8 +266,8 @@ network testing tools, either exclude them from all tests with the
 postscreen_access_list feature or else specify an empty teaser banner:
 
 /etc/postfix/main.cf:
-    # Exclude broken clients by whitelisting. Clients in mynetworks
-    # should always be whitelisted.
+    # Exclude broken clients by allowlisting. Clients in mynetworks
+    # should always be allowlisted.
     postscreen_access_list = permit_mynetworks,
         cidr:/etc/postfix/postscreen_access.cidr
 
@@ -265,7 +275,7 @@ postscreen_access_list feature or else specify an empty teaser banner:
     192.168.254.0/24 permit
 
 /etc/postfix/main.cf:
-    # Disable the teaser banner (try whitelisting first if you can).
+    # Disable the teaser banner (try allowlisting first if you can).
     postscreen_greet_banner =
 
 When an SMTP client sends a command before the postscreen_greet_wait time has
@@ -282,11 +292,11 @@ return and \n for newline).
 The postscreen_greet_action parameter specifies the action that is taken next.
 See "When tests fail before the 220 SMTP server greeting" below.
 
-DDNNSS WWhhiittee//bbllaacckklliisstt tteesstt
+DDNNSS AAllllooww//ddeennyylliisstt tteesstt
 
 The postscreen_dnsbl_sites parameter (default: empty) specifies a list of DNS
 blocklist servers with optional filters and weight factors (positive weights
-for blacklisting, negative for whitelisting). These servers will be queried in
+for denylisting, negative for allowlisting). These servers will be queried in
 parallel with the reverse client IP address. This test is disabled by default.
 
     CAUTION: when postscreen rejects mail, its SMTP reply contains the DNSBL
@@ -308,9 +318,9 @@ tests fail before the 220 SMTP server greeting" below.
 
 WWhheenn tteessttss ffaaiill bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
 
-When the client address matches the permanent blacklist, or when the client
+When the client address matches the permanent denylist, or when the client
 fails the pregreet or DNSBL tests, the action is specified with
-postscreen_blacklist_action, postscreen_greet_action, or
+postscreen_denylist_action, postscreen_greet_action, or
 postscreen_dnsbl_action, respectively.
 
 iiggnnoorree (default)
@@ -341,9 +351,9 @@ discussed next.
     deliver mail. The following measures may help to avoid email delays:
 
       o Allow "good" clients to skip tests with the
-        postscreen_dnsbl_whitelist_threshold feature (Postfix 2.11 and later).
-        This is especially effective for sites such as Google that never retry
-        immediately from the same IP address.
+        postscreen_dnsbl_allowlist_threshold feature. This is especially
+        effective for large providers that usually don't retry from the same IP
+        address.
 
       o Small sites: Configure postscreen(8) to listen on multiple IP
         addresses, published in DNS as different IP addresses for the same MX
@@ -508,26 +518,32 @@ limit, as specified with the line_length_limit parameter. The session is
 terminated immediately. The "aafftteerr command" portion is logged with Postfix 2.10
 and later.
 
-When an SMTP client makes too many connections at the same time, or when all
-postscreen(8) ports are busy, postscreen(8) rejects the connection with a 421
-status code and logs:
+When an SMTP client makes too many connections at the same time, postscreen(8)
+rejects the connection with a 421 status code and logs:
 
     NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: ttoooo mmaannyy ccoonnnneeccttiioonnss
+
+The postscreen_client_connection_count_limit parameter controls this limit.
+
+When an SMTP client connects after postscreen(8) has reached a connection count
+limit, postscreen(8) rejects the connection with a 421 status code and logs:
+
+    NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: aallll ssccrreeeenniinngg ppoorrttss bbuussyy
     NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: aallll sseerrvveerr ppoorrttss bbuussyy
 
-The postscreen_client_connection_count_limit and postscreen_pre_queue_limit
-parameters control these limits.
+The postscreen_pre_queue_limit and postscreen_post_queue_limit parameters
+control these limits.
 
 WWhheenn aallll tteessttss ssuucccceeeedd
 
-When a new SMTP client passes all tests (i.e. it is not whitelisted via some
+When a new SMTP client passes all tests (i.e. it is not allowlisted via some
 mechanism), postscreen(8) logs this as:
 
     PPAASSSS NNEEWW [address]:port
 
 Where [address]:port are the client IP address and port. Then, postscreen(8)
-creates a temporary whitelist entry that excludes the client IP address from
-further tests until the temporary whitelist entry expires, as controlled with
+creates a temporary allowlist entry that excludes the client IP address from
+further tests until the temporary allowlist entry expires, as controlled with
 the postscreen_*_ttl parameters.
 
 When no "deep protocol tests" are configured, postscreen(8) hands off the
@@ -552,7 +568,7 @@ systems.
   * postscreen(8) TLS configuration
   * Blocking mail with postscreen(8)
   * Turning off postscreen(8)
-  * Sharing the temporary whitelist
+  * Sharing the temporary allowlist
 
 TTuurrnniinngg oonn ppoossttssccrreeeenn((88)) wwiitthhoouutt bblloocckkiinngg mmaaiill
 
@@ -566,8 +582,8 @@ mail:
     broken SMTP implementations):
 
     /etc/postfix/main.cf:
-        # Exclude broken clients by whitelisting. Clients in mynetworks
-        # should always be whitelisted.
+        # Exclude broken clients by allowlisting. Clients in mynetworks
+        # should always be allowlisted.
         postscreen_access_list = permit_mynetworks,
             cidr:/etc/postfix/postscreen_access.cidr
 
@@ -636,8 +652,9 @@ Notes:
   * Some postscreen(8) configuration parameters implement stress-dependent
     behavior. This is supported only when the default value is stress-dependent
     (that is, "postconf -d parametername" output shows "parametername = $
-    {stress?something}${stress:something}"). Other parameters always evaluate
-    as if the stress value is the empty string.
+    {stress?something}${stress:something}" or "parametername = ${stress?
+    {something}:{something}}"). Other parameters always evaluate as if the
+    stress value is the empty string.
 
   * See "Tests before the 220 SMTP server greeting" for details about the
     logging from these postscreen(8) tests.
@@ -649,7 +666,7 @@ Notes:
 ppoossttssccrreeeenn((88)) TTLLSS ccoonnffiigguurraattiioonn
 
 postscreen(8) TLS support is available for remote SMTP clients that aren't
-whitelisted, including clients that need to renew their temporary whitelist
+allowlisted, including clients that need to renew their temporary allowlist
 status. When a remote SMTP client requests TLS service, postscreen(8) invisibly
 hands off the connection to a tlsproxy(8) process. Then, tlsproxy(8) encrypts
 and decrypts the traffic between postscreen(8) and the remote SMTP client. One
@@ -691,13 +708,13 @@ more of:
     their turn, and to log the helo/sender/recipient information. This stops
     over half of all known-to-be illegitimate connections to Wietse's mail
     server. It is backup protection for zombies that haven't yet been
-    blacklisted.
+    denylisted.
 
   * You can also enable "deep protocol tests", but these are more intrusive
     than the pregreet or DNSBL tests.
 
     When a good client passes the "deep protocol tests", postscreen(8) adds the
-    client to the temporary whitelist but it cannot hand off the "live"
+    client to the temporary allowlist but it cannot hand off the "live"
     connection to a Postfix SMTP server process in the middle of the session.
     Instead, postscreen(8) defers mail delivery attempts with a 4XX status,
     logs the helo/sender/recipient information, and waits for the client to
@@ -713,10 +730,10 @@ more of:
     after all.
 
     Unfortunately, some senders will retry requests from different IP
-    addresses, and may never get whitelisted. For this reason, Wietse stopped
+    addresses, and may never get allowlisted. For this reason, Wietse stopped
     using "deep protocol tests" on his own internet-facing mail server.
 
-  * There is also support for permanent blacklisting and whitelisting; see the
+  * There is also support for permanent denylisting and allowlisting; see the
     description of the postscreen_access_list parameter for details.
 
 TTuurrnniinngg ooffff ppoossttssccrreeeenn((88))
@@ -759,18 +776,18 @@ processes:
 
  6. Read the new configuration with "postfix reload".
 
-SShhaarriinngg tthhee tteemmppoorraarryy wwhhiitteelliisstt
+SShhaarriinngg tthhee tteemmppoorraarryy aalllloowwlliisstt
 
-By default, the temporary whitelist is not shared between multiple postscreen
+By default, the temporary allowlist is not shared between multiple postscreen
 (8) daemons. To enable sharing, choose one of the following options:
 
-  * A non-persistent memcache: temporary whitelist can be shared between
+  * A non-persistent memcache: temporary allowlist can be shared between
     postscreen(8) daemons on the same host or different hosts. Disable cache
     cleanup (postscreen_cache_cleanup_interval = 0) in all postscreen(8)
     daemons because memcache: has no first-next API (but see example 4 below
     for memcache: with persistent backup). This requires Postfix 2.9 or later.
 
-        # Example 1: non-persistent memcache: whitelist.
+        # Example 1: non-persistent memcache: allowlist.
         /etc/postfix/main.cf:
             postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
             postscreen_cache_cleanup_interval = 0
@@ -779,32 +796,32 @@ By default, the temporary whitelist is not shared between multiple postscreen
             memcache = inet:127.0.0.1:11211
             key_format = postscreen:%s
 
-  * A persistent lmdb: temporary whitelist can be shared between postscreen(8)
+  * A persistent lmdb: temporary allowlist can be shared between postscreen(8)
     daemons that run under the same master(8) daemon, or under different master
     (8) daemons on the same host. Disable cache cleanup
     (postscreen_cache_cleanup_interval = 0) in all postscreen(8) daemons except
     one that is responsible for cache cleanup. This requires Postfix 2.11 or
     later.
 
-        # Example 2: persistent lmdb: whitelist.
+        # Example 2: persistent lmdb: allowlist.
         /etc/postfix/main.cf:
             postscreen_cache_map = lmdb:$data_directory/postscreen_cache
             # See note 1 below.
             # postscreen_cache_cleanup_interval = 0
 
-  * Other kinds of persistent temporary whitelist can be shared only between
+  * Other kinds of persistent temporary allowlist can be shared only between
     postscreen(8) daemons that run under the same master(8) daemon. In this
-    case, temporary whitelist access must be shared through the proxymap(8)
+    case, temporary allowlist access must be shared through the proxymap(8)
     daemon. This requires Postfix 2.9 or later.
 
-        # Example 3: proxied btree: whitelist.
+        # Example 3: proxied btree: allowlist.
         /etc/postfix/main.cf:
             postscreen_cache_map =
                 proxy:btree:/var/lib/postfix/postscreen_cache
             # See note 1 below.
             # postscreen_cache_cleanup_interval = 0
 
-        # Example 4: proxied btree: whitelist with memcache: accelerator.
+        # Example 4: proxied btree: allowlist with memcache: accelerator.
         /etc/postfix/main.cf:
             postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
             proxy_write_maps =
@@ -854,3 +871,6 @@ POP, IMAP, NNTP, and FTP over TLS.
 postscreen(8) was officially released as part of the Postfix 2.8 stable release
 in January 2011.
 
+Noel Jones helped with the Postfix 3.6 transition towards respectful
+documentation.
+

postfix/README_FILES/QSHAPE_README

@@ -68,11 +68,11 @@ sender domain distribution for captured spam in the "hold" queue:
 When the output is a terminal intermediate results showing the top 20 domains
 (-n option) are displayed after every 1000 messages (-N option) and the final
 output also shows only the top 20 domains. This makes qshape useful even when
-the deferred queue is very large and it may otherwise take prohibitively long
-to read the entire deferred queue.
+the "deferred" queue is very large and it may otherwise take prohibitively long
+to read the entire "deferred" queue.
 
-By default, qshape shows statistics for the union of both the incoming and
-active queues which are the most relevant queues to look at when analyzing
+By default, qshape shows statistics for the union of both the "incoming" and
+"active" queues which are the most relevant queues to look at when analyzing
 performance.
 
 One can request an alternate list of queues:
@@ -80,8 +80,8 @@ One can request an alternate list of queues:
     $ qshape deferred
     $ qshape incoming active deferred
 
-this will show the age distribution of the deferred queue or the union of the
-incoming active and deferred queues.
+this will show the age distribution of the "deferred" queue or the union of the
+"incoming", "active" and "deferred" queues.
 
 Command line options control the number of display "buckets", the age limit for
 the smallest bucket, display of parent domain counts and so on. The "-h" option
@@ -96,16 +96,16 @@ recipient counts, approximately when a burst of mail started, and when it
 stopped.
 
 The problem destinations or sender domains appear near the top left corner of
-the output table. Remember that the active queue can accommodate up to 20000
+the output table. Remember that the "active" queue can accommodate up to 20000
 ($qmgr_message_active_limit) messages. To check whether this limit has been
 reached, use:
 
     $ qshape -s active       (show sender statistics)
 
-If the total sender count is below 20000 the active queue is not yet saturated,
-any high volume sender domains show near the top of the output.
+If the total sender count is below 20000 the "active" queue is not yet
+saturated, any high volume sender domains show near the top of the output.
 
-With oqmgr(8) the active queue is also limited to at most 20000 recipient
+With oqmgr(8) the "active" queue is also limited to at most 20000 recipient
 addresses ($qmgr_message_recipient_limit). To check for exhaustion of this
 limit use:
 
@@ -117,44 +117,44 @@ recent messages pertaining to the domains in question.
     # Find deliveries to example.com
     #
     $ tail -10000 /var/log/maillog |
-            egrep -i ': to=<.*@example\.com>,' |
+            grep -E -i ': to=<.*@example\.com>,' |
             less
 
     # Find messages from example.com
     #
     $ tail -10000 /var/log/maillog |
-            egrep -i ': from=<.*@example\.com>,' |
+            grep -E -i ': from=<.*@example\.com>,' |
             less
 
 You may want to drill in on some specific queue ids:
 
     # Find all messages for a specific queue id.
     #
-    $ tail -10000 /var/log/maillog | egrep ': 2B2173FF68: '
+    $ tail -10000 /var/log/maillog | grep -E ': 2B2173FF68: '
 
 Also look for queue manager warning messages in the log. These warnings can
 suggest strategies to reduce congestion.
 
-    $ egrep 'qmgr.*(panic|fatal|error|warning):' /var/log/maillog
+    $ grep -E 'qmgr.*(panic|fatal|error|warning):' /var/log/maillog
 
 When all else fails try the Postfix mailing list for help, but please don't
 forget to include the top 10 or 20 lines of qshape(1) output.
 
 EExxaammppllee 11:: HHeeaalltthhyy qquueeuuee
 
-When looking at just the incoming and active queues, under normal conditions
-(no congestion) the incoming and active queues are nearly empty. Mail leaves
-the system almost as quickly as it comes in or is deferred without congestion
-in the active queue.
+When looking at just the "incoming" and "active" queues, under normal
+conditions (no congestion) the "incoming" and "active" queues are nearly empty.
+Mail leaves the system almost as quickly as it comes in or is deferred without
+congestion in the "active" queue.
 
-    $ qshape        (show incoming and active queue status)
+    $ qshape        (show "incoming" and "active" queue status)
 
                      T  5 10 20 40 80 160 320 640 1280 1280+
               TOTAL  5  0  0  0  1  0   0   0   1    1     2
       meri.uwasa.fi  5  0  0  0  1  0   0   0   1    1     2
 
-If one looks at the two queues separately, the incoming queue is empty or
-perhaps briefly has one or two messages, while the active queue holds more
+If one looks at the two queues separately, the "incoming" queue is empty or
+perhaps briefly has one or two messages, while the "active" queue holds more
 messages and for a somewhat longer time:
 
     $ qshape incoming
@@ -173,8 +173,8 @@ EExxaammppllee 22:: DDeeffeerrrreedd qquueeuuee ffuulll
 This is from a server where recipient validation is not yet available for some
 of the hosted domains. Dictionary attacks on the unvalidated domains result in
 bounce backscatter. The bounces dominate the queue, but with proper tuning they
-do not saturate the incoming or active queues. The high volume of deferred mail
-is not a direct cause for alarm.
+do not saturate the "incoming" or "active" queues. The high volume of deferred
+mail is not a direct cause for alarm.
 
     $ qshape deferred | head
 
@@ -192,8 +192,8 @@ is not a direct cause for alarm.
 The domains shown are mostly bulk-mailers and all the volume is the tail end of
 the time distribution, showing that short term arrival rates are moderate.
 Larger numbers and lower message ages are more indicative of current trouble.
-Old mail still going nowhere is largely harmless so long as the active and
-incoming queues are short. We can also see that the groups.msn.com
+Old mail still going nowhere is largely harmless so long as the "active" and
+"incoming" queues are short. We can also see that the groups.msn.com
 undeliverables are low rate steady stream rather than a concentrated dictionary
 attack that is now over.
 
@@ -215,16 +215,15 @@ messages are bounces.
 EExxaammppllee 33:: CCoonnggeessttiioonn iinn tthhee aaccttiivvee qquueeuuee
 
 This example is taken from a Feb 2004 discussion on the Postfix Users list.
-Congestion was reported with the active and incoming queues large and not
+Congestion was reported with the "active" and "incoming" queues large and not
 shrinking despite very large delivery agent process limits. The thread is
-archived at: http://groups.google.com/
-groups?threadm=c0b7js$2r65$1@FreeBSD.csie.NCTU.edu.tw and http://
+archived at: https://web.archive.org/web/20120227170207/http://
 archives.neohapsis.com/archives/postfix/2004-02/thread.html#1371
 
 Using an older version of qshape(1) it was quickly determined that all the
 messages were for just a few destinations:
 
-    $ qshape        (show incoming and active queue status)
+    $ qshape        (show "incoming" and "active" queue status)
 
                                T   A   5  10  20  40  80 160 320 320+
                      TOTAL 11775 9996  0   0   1   1  42  94 221 1420
@@ -232,10 +231,10 @@ messages were for just a few destinations:
      lists.sourceforge.net  2313 2313  0   0   0   0   0   0   0    0
             gzd.gotdns.com   102    0  0   0   0   0   0   0   2  100
 
-The "A" column showed the count of messages in the active queue, and the
-numbered columns showed totals for the deferred queue. At 10000 messages
-(Postfix 1.x active queue size limit) the active queue is full. The incoming
-was growing rapidly.
+The "A" column showed the count of messages in the "active" queue, and the
+numbered columns showed totals for the "deferred" queue. At 10000 messages
+(Postfix 1.x "active" queue size limit) the "active" queue is full. The
+"incoming" queue was growing rapidly.
 
 With the trouble destinations clearly identified, the administrator quickly
 found and fixed the problem. It is substantially harder to glean the same
@@ -246,7 +245,7 @@ by looking at the queue one message at a time.
 EExxaammppllee 44:: HHiigghh vvoolluummee ddeessttiinnaattiioonn bbaacckklloogg
 
 When a site you send a lot of email to is down or slow, mail messages will
-rapidly build up in the deferred queue, or worse, in the active queue. The
+rapidly build up in the "deferred" queue, or worse, in the "active" queue. The
 qshape output will show large numbers for the destination domain in all age
 buckets that overlap the starting time of the problem:
 
@@ -258,14 +257,14 @@ buckets that overlap the starting time of the problem:
                  ...
 
 Here the "highvolume.com" destination is continuing to accumulate deferred
-mail. The incoming and active queues are fine, but the deferred queue started
-growing some time between 1 and 2 hours ago and continues to grow.
+mail. The "incoming" and "active" queues are fine, but the "deferred" queue
+started growing some time between 1 and 2 hours ago and continues to grow.
 
 If the high volume destination is not down, but is instead slow, one might see
-similar congestion in the active queue. Active queue congestion is a greater
-cause for alarm; one might need to take measures to ensure that the mail is
-deferred instead or even add an access(5) rule asking the sender to try again
-later.
+similar congestion in the "active" queue. "Active" queue congestion is a
+greater cause for alarm; one might need to take measures to ensure that the
+mail is deferred instead or even add an access(5) rule asking the sender to try
+again later.
 
 If a high volume destination exhibits frequent bursts of consecutive
 connections refused by all MX hosts or "421 Server busy errors", it is possible
@@ -456,7 +455,7 @@ Congestion in this queue is indicative of an excessive local message submission
 rate or perhaps excessive CPU consumption in the cleanup(8) service due to
 excessive body_checks, or (Postfix >= 2.3) high latency milters.
 
-Note, that once the active queue is full, the cleanup service will attempt to
+Note, that once the "active" queue is full, the cleanup service will attempt to
 slow down message injection by pausing $in_flow_delay for each message. In this
 case "maildrop" queue congestion may be a consequence of congestion downstream,
 rather than a problem in its own right.
@@ -504,18 +503,18 @@ and notifies the queue manager of new mail arrival. The queue manager ignores
 incomplete queue files whose mode is 0600, as these are still being written by
 cleanup.
 
-The queue manager scans the incoming queue bringing any new mail into the
-"active" queue if the active queue resource limits have not been exceeded. By
-default, the active queue accommodates at most 20000 messages. Once the active
-queue message limit is reached, the queue manager stops scanning the incoming
-(and deferred, see below) queue.
+The queue manager scans the "incoming" queue bringing any new mail into the
+"active" queue if the "active" queue resource limits have not been exceeded. By
+default, the "active" queue accommodates at most 20000 messages. Once the
+"active" queue message limit is reached, the queue manager stops scanning the
+"incoming" queue (and the "deferred" queue, see below).
 
-Under normal conditions the incoming queue is nearly empty (has only mode 0600
-files), with the queue manager able to import new messages into the active
-queue as soon as they become available.
+Under normal conditions the "incoming" queue is nearly empty (has only mode
+0600 files), with the queue manager able to import new messages into the
+"active" queue as soon as they become available.
 
-The incoming queue grows when the message input rate spikes above the rate at
-which the queue manager can import messages into the active queue. The main
+The "incoming" queue grows when the message input rate spikes above the rate at
+which the queue manager can import messages into the "active" queue. The main
 factors slowing down the queue manager are disk I/O and lookup queries to the
 trivial-rewrite service. If the queue manager is routinely not keeping up,
 consider not using "slow" lookup services (MySQL, LDAP, ...) for transport
@@ -540,8 +539,8 @@ but is not strong enough to deflect an excessive input rate from many sources
 at the same time.
 
 If a server is being hammered from multiple directions, consider raising the
-in_flow_delay to 10 seconds, but only if the incoming queue is growing even
-while the active queue is not full and the trivial-rewrite service is using a
+in_flow_delay to 10 seconds, but only if the "incoming" queue is growing even
+while the "active" queue is not full and the trivial-rewrite service is using a
 fast transport lookup mechanism.
 
 TThhee ""aaccttiivvee"" qquueeuuee
@@ -549,8 +548,8 @@ TThhee ""aaccttiivvee"" qquueeuuee
 The queue manager is a delivery agent scheduler; it works to ensure fast and
 fair delivery of mail to all destinations within designated resource limits.
 
-The active queue is somewhat analogous to an operating system's process run
-queue. Messages in the active queue are ready to be sent (runnable), but are
+The "active" queue is somewhat analogous to an operating system's process run
+queue. Messages in the "active" queue are ready to be sent (runnable), but are
 not necessarily in the process of being sent (running).
 
 While most Postfix administrators think of the "active" queue as a directory on
@@ -562,9 +561,9 @@ below) do not occupy memory; they are safely stored on disk waiting for their
 turn to be processed. The envelope information for messages in the "active"
 queue is managed in memory, allowing the queue manager to do global scheduling,
 allocating available delivery agent processes to an appropriate message in the
-active queue.
+"active" queue.
 
-Within the active queue, (multi-recipient) messages are broken up into groups
+Within the "active" queue, (multi-recipient) messages are broken up into groups
 of recipients that share the same transport/nexthop combination; the group size
 is capped by the transport's recipient concurrency limit.
 
@@ -577,14 +576,14 @@ per-recipient concurrency limits rather than per-domain concurrency limits.
 Per-recipient limits are appropriate when performing final delivery to
 mailboxes rather than when relaying to a remote server.
 
-Congestion occurs in the active queue when one or more destinations drain
+Congestion occurs in the "active" queue when one or more destinations drain
 slower than the corresponding message input rate.
 
-Input into the active queue comes both from new mail in the "incoming" queue,
+Input into the "active" queue comes both from new mail in the "incoming" queue,
 and retries of mail in the "deferred" queue. Should the "deferred" queue get
 really large, retries of old mail can dominate the arrival rate of new mail.
 Systems with more CPU, faster disks and more network bandwidth can deal with
-larger deferred queues, but as a rule of thumb the deferred queue scales to
+larger "deferred" queues, but as a rule of thumb the "deferred" queue scales to
 somewhere between 100,000 and 1,000,000 messages with good performance unlikely
 above that "limit". Systems with queues this large should typically stop
 accepting new mail, or put the backlog "on hold" until the underlying issue is
@@ -592,14 +591,14 @@ fixed (provided that there is enough capacity to handle just the new mail).
 
 When a destination is down for some time, the queue manager will mark it dead,
 and immediately defer all mail for the destination without trying to assign it
-to a delivery agent. In this case the messages will quickly leave the active
-queue and end up in the deferred queue (with Postfix < 2.4, this is done
+to a delivery agent. In this case the messages will quickly leave the "active"
+queue and end up in the "deferred" queue (with Postfix < 2.4, this is done
 directly by the queue manager, with Postfix >= 2.4 this is done via the "retry"
 delivery agent).
 
 When the destination is instead simply slow, or there is a problem causing an
-excessive arrival rate the active queue will grow and will become dominated by
-mail to the congested destination.
+excessive arrival rate the "active" queue will grow and will become dominated
+by mail to the congested destination.
 
 The only way to reduce congestion is to either reduce the input rate or
 increase the throughput. Increasing the throughput requires either increasing
@@ -635,7 +634,7 @@ per second.
 The best way to avoid bottlenecks when one or more MX hosts is non-responsive
 is to use connection caching. Connection caching was introduced with Postfix
 2.2 and is by default enabled on demand for destinations with a backlog of mail
-in the active queue. When connection caching is in effect for a particular
+in the "active" queue. When connection caching is in effect for a particular
 destination, established connections are re-used to send additional messages,
 this reduces the number of connections made per message delivery and maintains
 good throughput even in the face of partial unavailability of the destination's
@@ -664,73 +663,75 @@ a separate delivery agent pool to these destinations and allows separate tuning
 of timeouts and concurrency limits.
 
 Another common cause of congestion is unwarranted flushing of the entire
-deferred queue. The deferred queue holds messages that are likely to fail to be
-delivered and are also likely to be slow to fail delivery (time out). As a
-result the most common reaction to a large deferred queue (flush it!) is more
-than likely counter-productive, and typically makes the congestion worse. Do
-not flush the deferred queue unless you expect that most of its content has
-recently become deliverable (e.g. relayhost back up after an outage)!
+"deferred" queue. The "deferred" queue holds messages that are likely to fail
+to be delivered and are also likely to be slow to fail delivery (time out). As
+a result the most common reaction to a large "deferred" queue (flush it!) is
+more than likely counter-productive, and typically makes the congestion worse.
+Do not flush the "deferred" queue unless you expect that most of its content
+has recently become deliverable (e.g. relayhost back up after an outage)!
 
 Note that whenever the queue manager is restarted, there may already be
-messages in the active queue directory, but the "real" active queue in memory
-is empty. In order to recover the in-memory state, the queue manager moves all
-the active queue messages back into the incoming queue, and then uses its
-normal incoming queue scan to refill the active queue. The process of moving
-all the messages back and forth, redoing transport table (trivial-rewrite(8)
-resolve service) lookups, and re-importing the messages back into memory is
-expensive. At all costs, avoid frequent restarts of the queue manager (e.g. via
-frequent execution of "postfix reload").
+messages in the "active" queue directory, but the "real" "active" queue in
+memory is empty. In order to recover the in-memory state, the queue manager
+moves all the "active" queue messages back into the "incoming" queue, and then
+uses its normal "incoming" queue scan to refill the "active" queue. The process
+of moving all the messages back and forth, redoing transport table (trivial-
+rewrite(8) resolve service) lookups, and re-importing the messages back into
+memory is expensive. At all costs, avoid frequent restarts of the queue manager
+(e.g. via frequent execution of "postfix reload").
 
 TThhee ""ddeeffeerrrreedd"" qquueeuuee
 
 When all the deliverable recipients for a message are delivered, and for some
 recipients delivery failed for a transient reason (it might succeed later), the
-message is placed in the deferred queue.
+message is placed in the "deferred" queue.
 
-The queue manager scans the deferred queue periodically. The scan interval is
-controlled by the queue_run_delay parameter. While a deferred queue scan is in
-progress, if an incoming queue scan is also in progress (ideally these are
-brief since the incoming queue should be short), the queue manager alternates
+The queue manager scans the "deferred" queue periodically. The scan interval is
+controlled by the queue_run_delay parameter. While a "deferred" queue scan is
+in progress, if an "incoming" queue scan is also in progress (ideally these are
+brief since the "incoming" queue should be short), the queue manager alternates
 between looking for messages in the "incoming" queue and in the "deferred"
-queue. This "round-robin" strategy prevents starvation of either the incoming
-or the deferred queues.
+queue. This "round-robin" strategy prevents starvation of either the "incoming"
+or the "deferred" queues.
 
-Each deferred queue scan only brings a fraction of the deferred queue back into
-the active queue for a retry. This is because each message in the deferred
-queue is assigned a "cool-off" time when it is deferred. This is done by time-
-warping the modification time of the queue file into the future. The queue file
-is not eligible for a retry if its modification time is not yet reached.
+Each "deferred" queue scan only brings a fraction of the "deferred" queue back
+into the "active" queue for a retry. This is because each message in the
+"deferred" queue is assigned a "cool-off" time when it is deferred. This is
+done by time-warping the modification time of the queue file into the future.
+The queue file is not eligible for a retry if its modification time is not yet
+reached.
 
 The "cool-off" time is at least $minimal_backoff_time and at most
 $maximal_backoff_time. The next retry time is set by doubling the message's age
 in the queue, and adjusting up or down to lie within the limits. This means
 that young messages are initially retried more often than old messages.
 
-If a high volume site routinely has large deferred queues, it may be useful to
-adjust the queue_run_delay, minimal_backoff_time and maximal_backoff_time to
+If a high volume site routinely has large "deferred" queues, it may be useful
+to adjust the queue_run_delay, minimal_backoff_time and maximal_backoff_time to
 provide short enough delays on first failure (Postfix >= 2.4 has a sensibly low
 minimal backoff time by default), with perhaps longer delays after multiple
 failures, to reduce the retransmission rate of old messages and thereby reduce
-the quantity of previously deferred mail in the active queue. If you want a
+the quantity of previously deferred mail in the "active" queue. If you want a
 really low minimal_backoff_time, you may also want to lower queue_run_delay,
 but understand that more frequent scans will increase the demand for disk I/O.
 
-One common cause of large deferred queues is failure to validate recipients at
-the SMTP input stage. Since spammers routinely launch dictionary attacks from
-unrepliable sender addresses, the bounces for invalid recipient addresses clog
-the deferred queue (and at high volumes proportionally clog the active queue).
-Recipient validation is strongly recommended through use of the
+One common cause of large "deferred" queues is failure to validate recipients
+at the SMTP input stage. Since spammers routinely launch dictionary attacks
+from unrepliable sender addresses, the bounces for invalid recipient addresses
+clog the "deferred" queue (and at high volumes proportionally clog the "active"
+queue). Recipient validation is strongly recommended through use of the
 local_recipient_maps and relay_recipient_maps parameters. Even when bounces
 drain quickly they inundate innocent victims of forgery with unwanted email. To
 avoid this, do not accept mail for invalid recipients.
 
 When a host with lots of deferred mail is down for some time, it is possible
-for the entire deferred queue to reach its retry time simultaneously. This can
-lead to a very full active queue once the host comes back up. The phenomenon
-can repeat approximately every maximal_backoff_time seconds if the messages are
-again deferred after a brief burst of congestion. Perhaps, a future Postfix
-release will add a random offset to the retry time (or use a combination of
-strategies) to reduce the odds of repeated complete deferred queue flushes.
+for the entire "deferred" queue to reach its retry time simultaneously. This
+can lead to a very full "active" queue once the host comes back up. The
+phenomenon can repeat approximately every maximal_backoff_time seconds if the
+messages are again deferred after a brief burst of congestion. Perhaps, a
+future Postfix release will add a random offset to the retry time (or use a
+combination of strategies) to reduce the odds of repeated complete "deferred"
+queue flushes.
 
 CCrreeddiittss
 

postfix/README_FILES/SASL_README

@@ -174,9 +174,20 @@ You can read more about the following topics:
 
   * Cyrus SASL version 2.1.22 and newer additionally search in /etc/sasl2/.
 
-  * Some Postfix distributions are modified and look for the Cyrus SASL
-    configuration file in /etc/postfix/sasl/, /var/lib/sasl2/ etc. See the
-    distribution-specific documentation to determine the expected location.
+  * With Postfix 2.5 and later you can explicitly configure the search path via
+    the cyrus_sasl_config_path configuration parameter. Specify zero or more
+    colon-separated directories. If set empty (the default value) the search
+    path is the one compiled into the Cyrus SASL library.
+
+  * Some Postfix distributions employ a non-empty default value for
+    cyrus_sasl_config_path to look for the Cyrus SASL configuration file in /
+    etc/postfix/sasl/, /var/lib/sasl2/ etc. See the output of postconf
+    cyrus_sasl_config_path and/or the distribution-specific documentation to
+    determine the expected location.
+
+  * Some Debian-based Postfix distributions ignore the "cyrus_sasl_config_path"
+    parameter setting, and force Postfix to open the file /etc/postfix/sasl/
+    smtpd.conf.
 
     NNoottee
 
@@ -558,8 +569,8 @@ The following is a summary of applicable smtpd.conf file entries:
         Specify ldapdb to enable the plugin.
 
     ldapdb_uri
-        Specify either ldapi:// for to connect over a UNIX-domain socket, ldap:
-        // for an unencrypted TCP connection or ldaps:// for an encrypted TCP
+        Specify either ldapi:// to connect over a UNIX-domain socket, ldap:/
+        / for an unencrypted TCP connection, or ldaps:// for an encrypted TCP
         connection.
 
     ldapdb_id
@@ -973,7 +984,7 @@ authentication information:
 
     The mmmmeennccooddee command is part of the metamail software.
 
-  * Using Perl MMIIMMEE::::BBaassee6644 (from http://www.cpan.org/):
+  * Using Perl MMIIMMEE::::BBaassee6644 (from https://www.cpan.org/):
 
         % ppeerrll --MMMMIIMMEE::::BBaassee6644 --ee \\
             ''pprriinntt eennccooddee__bbaassee6644((""\\00uusseerrnnaammee\\00ppaasssswwoorrdd""));;''
@@ -987,7 +998,7 @@ authentication information:
         password:
 
     The ggeenn--aauutthh Perl script was written by John Jetmore and can be found at
-    http://jetmore.org/john/code/gen-auth.
+    https://jetmore.org/john/code/gen-auth.
 
 CCoonnffiigguurriinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
 
@@ -1058,9 +1069,9 @@ username/password information.
     standard "AUTH=mmeetthhoodd....." syntax in response to the EHLO command; this
     requires no additional Postfix client configuration.
 
-  * The Postfix SMTP client does not support the obsolete "wrappermode"
-    protocol, which uses TCP port 465 on the SMTP server. See TLS_README for a
-    solution that uses the stunnel command.
+  * With the setting "smtp_tls_wrappermode = yes", the Postfix SMTP client
+    supports the "wrappermode" protocol, which uses TCP port 465 on the SMTP
+    server (Postfix 3.0 and later).
 
   * With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP
     client to send username and password information to the mail gateway
@@ -1134,14 +1145,14 @@ final resort.
     single MySQL database, and configure different Postfix queries to extract
     the appropriate information.
 
-  * Specify dbm instead of hash if your system uses dbm files instead of db
+  * Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
     files. To find out what lookup tables Postfix supports, use the command
-    "postconf -m".
+    "ppoossttccoonnff --mm".
 
-  * Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change
+  * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change
     the sasl_passwd table.
 
-  * Execute the command "postmap /etc/postfix/sender_relay" whenever you change
+  * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//sseennddeerr__rreellaayy" whenever you change
     the sender_relay table.
 
 PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm pprrooppeerrttiieess
@@ -1285,35 +1296,35 @@ To generate the necessary Makefiles, execute the following in the Postfix top-
 level directory:
 
     % mmaakkee ttiiddyy # if you have left-over files from a previous build
-    % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==''--DDUUSSEE__SSAASSLL__AAUUTTHH \\
-        --DDDDEEFF__SSEERRVVEERR__SSAASSLL__TTYYPPEE==\\""ddoovveeccoott\\""''
+    % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH \\
+        --DDDDEEFF__SSEERRVVEERR__SSAASSLL__TTYYPPEE==\\\\\\""ddoovveeccoott\\\\\\""""
 
 After this, proceed with "make" as described in the INSTALL document.
 
 NNoottee
 
-  * The -DDEF_SERVER_SASL_TYPE=\"dovecot\" is not necessary; it just makes
+  * The -DDEF_SERVER_SASL_TYPE=\\\"dovecot\\\" is not necessary; it just makes
     Postfix configuration a little more convenient because you don't have to
     specify the SASL plug-in type in the Postfix main.cf file (but this may
     cause surprises when you switch to a later Postfix version that is built
-    with the default SASL type of sasl).
+    with the default SASL type of cyrus).
 
   * If you also want support for LDAP or TLS (or for Cyrus SASL), you need to
     merge their CCARGS and AUXLIBS options into the above command line; see the
     LDAP_README and TLS_README for details.
 
         % mmaakkee ttiiddyy # if you have left-over files from a previous build
-        % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==''--DDUUSSEE__SSAASSLL__AAUUTTHH \\
-            --DDDDEEFF__SSEERRVVEERR__SSAASSLL__TTYYPPEE==\\""ddoovveeccoott\\"" \\
-            ......CCCCAARRGGSS ooppttiioonnss ffoorr LLDDAAPP oorr TTLLSS eettcc........'' \\
-           AAUUXXLLIIBBSS==''......AAUUXXLLIIBBSS ooppttiioonnss ffoorr LLDDAAPP oorr TTLLSS eettcc........''
+        % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH \\
+            --DDDDEEFF__SSEERRVVEERR__SSAASSLL__TTYYPPEE==\\\\\\""ddoovveeccoott\\\\\\"" \\
+            ......CCCCAARRGGSS ooppttiioonnss ffoorr LLDDAAPP oorr TTLLSS eettcc........"" \\
+           AAUUXXLLIIBBSS==""......AAUUXXLLIIBBSS ooppttiioonnss ffoorr LLDDAAPP oorr TTLLSS eettcc........""
 
 BBuuiillddiinngg CCyyrruuss SSAASSLL ssuuppppoorrtt
 
 BBuuiillddiinngg tthhee CCyyrruuss SSAASSLL lliibbrraarryy
 
 Postfix works with cyrus-sasl-1.5.x or cyrus-sasl-2.1.x, which are available
-from ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/.
+from https://github.com/cyrusimap/cyrus-sasl/releases.
 
     IImmppoorrttaanntt
 
@@ -1344,6 +1355,10 @@ Cyrus SASL version 2.1.x
     % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH --DDUUSSEE__CCYYRRUUSS__SSAASSLL \\
         --II//uussrr//llooccaall//iinncclluuddee//ssaassll"" AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb --llssaassll22""
 
+    If your Cyrus SASL shared library is in a directory that the RUN-TIME
+    linker does not know about, add a "-Wl,-R,/path/to/directory" option after
+    "-lsasl2".
+
 Cyrus SASL version 1.5.x
 
     % mmaakkee ttiiddyy # if you have left-over files from a previous build

postfix/README_FILES/SCHEDULER_README

@@ -496,7 +496,7 @@ This document is divided into sections as follows:
 TThhee ssttrruuccttuurreess uusseedd bbyy nnqqmmggrr
 
 Let's start by recapitulating the structures and terms used when referring to
-queue manager and how it operates. Many of these are partially described
+the queue manager and how it operates. Many of these are partially described
 elsewhere, but it is nice to have a coherent overview in one place:
 
   * Each message structure represents one mail message which Postfix is to
@@ -512,8 +512,8 @@ elsewhere, but it is nice to have a coherent overview in one place:
     set of queues (describing the destinations it shall talk to) and jobs
     (referencing the messages it shall deliver).
 
-  * Each transport queue (not to be confused with the on-disk active queue or
-    incoming queue) groups everything what is going be delivered to given
+  * Each transport queue (not to be confused with the on-disk "active" queue or
+    "incoming" queue) groups everything what is going be delivered to given
     destination (aka nexthop) by its transport. Each queue belongs to one
     transport, so each destination may be referred to by several queues, one
     for each transport. Each queue maintains a list of all recipient entries
@@ -547,17 +547,17 @@ description above anytime you'll feel you have lost a sense what is what.
 
 WWhhaatt hhaappppeennss wwhheenn nnqqmmggrr ppiicckkss uupp tthhee mmeessssaaggee
 
-Whenever nqmgr moves a queue file into the active queue, the following happens:
-It reads all necessary information from the queue file as oqmgr does, and also
-reads as many recipients as possible - more on that later, for now let's just
-pretend it always reads all recipients.
+Whenever nqmgr moves a queue file into the "active" queue, the following
+happens: It reads all necessary information from the queue file as oqmgr does,
+and also reads as many recipients as possible - more on that later, for now
+let's just pretend it always reads all recipients.
 
 Then it resolves the recipients as oqmgr does, which means obtaining (address,
 nexthop, transport) triple for each recipient. For each triple, it finds the
 transport; if it does not exist yet, it instantiates it (unless it's dead).
-Within the transport, it finds the destination queue for given nexthop; if it
-does not exist yet, it instantiates it (unless it's dead). The triple is then
-bound to given destination queue. This happens in qmgr_resolve() and is
+Within the transport, it finds the destination queue for the given nexthop; if
+it does not exist yet, it instantiates it (unless it's dead). The triple is
+then bound to given destination queue. This happens in qmgr_resolve() and is
 basically the same as in oqmgr.
 
 Then for each triple which was bound to some queue (and thus transport), the
@@ -566,19 +566,19 @@ context; if it does not exist yet, it instantiates it. Within the job, it finds
 the peer which represents the bound destination queue within this jobs context;
 if it does not exist yet, it instantiates it. Finally, it stores the address
 from the resolved triple to the recipient entry which is appended to both the
-queue entry list and the peer entry list. The addresses for same nexthop are
-batched in the entries up to recipient_concurrency limit for that transport.
-This happens in qmgr_assign() and apart from that it operates with job and peer
-structures it is basically the same as in oqmgr.
+queue entry list and the peer entry list. The addresses for the same nexthop
+are batched in the entries up to the transport_destination_recipient_limit for
+that transport. This happens in qmgr_message_assign(), and apart from that it
+operates with job and peer structures, it is basically the same as in oqmgr.
 
 When the job is instantiated, it is enqueued on the transport's job list based
 on the time its message was picked up by nqmgr. For first batch of recipients
 this means it is appended to the end of the job list, but the ordering of the
 job list by the enqueue time is important as we will see shortly.
 
-[Now you should have pretty good idea what is the state of the nqmgr after
-couple of messages was picked up, what is the relation between all those job,
-peer, queue and entry structures.]
+[Now you should have a pretty good idea what the state of the nqmgr is after a
+couple of messages were picked up, and what the relation is between all those
+job, peer, queue and entry structures.]
 
 HHooww tthhee eennttrryy sseelleeccttiioonn wwoorrkkss
 
@@ -606,9 +606,9 @@ job list is by default kept in the order the message was picked up by the
 nqmgr. So by default we get the top-level round-robin transport, and within
 each transport we get the FIFO message delivery. The round-robin of the peers
 by the destination is perhaps of little importance in most real-life cases
-(unless the recipient_concurrency limit is reached, in one job there is only
-one peer structure for each destination), but theoretically it makes sure that
-even within single jobs, destinations are treated fairly.
+(unless the transport_destination_recipient_limit is reached, in one job there
+is only one peer structure for each destination), but theoretically it makes
+sure that even within single jobs, destinations are treated fairly.
 
 [By now you should have a feeling you really know how the scheduler works,
 except for the preemption, under ideal conditions - that is, no recipient
@@ -661,14 +661,14 @@ with more than one recipient? Say if we have one four-recipient mail followed
 by two two-recipient mails?
 
 The simple answer would be to use delivery sequence 12121313. But the problem
-is that this does not scale well. Imagine you have mail with thousand
-recipients followed by mail with hundred recipients. It is tempting to suggest
-the delivery sequence like 121212...., but alas! Imagine there arrives another
-mail with say ten recipients. But there are no free slots anymore, so it can't
-slip by, not even if it had just only one recipients. It will be stuck until
+is that this does not scale well. Imagine you have mail with a thousand
+recipients followed by mail with a hundred recipients. It is tempting to
+suggest the delivery sequence like 121212...., but alas! Imagine there arrives
+another mail with say ten recipients. But there are no free slots anymore, so
+it can't slip by, not even if it had only one recipient. It will be stuck until
 the hundred-recipient mail is delivered, which really sucks.
 
-So, it becomes obvious that while inflating the message to get free slots is
+So, it becomes obvious that while inflating the message to get free slots is a
 great idea, one has to be really careful of how the free slots are assigned,
 otherwise one might corner himself. So, how does nqmgr really use the free
 slots?
@@ -689,30 +689,30 @@ slots, and then we could preempt it and sneak in the ten-recipient mail... Wait
 wait wait! Could we? Aren't we overinflating the original one thousand
 recipient mail?
 
-Well, despite it looks so at the first glance, another trick will allow us to
-answer "no, we are not!". If we had said that we will inflate the delivery time
-twice at maximum, and then we consider every other slot as a free slot, then we
-would overinflate in case of the recursive preemption. BUT! The trick is that
-if we use only every n-th slot as a free slot for n>2, there is always some
-worst inflation factor which we can guarantee not to be breached, even if we
-apply the algorithm recursively. To be precise, if for every k>1 normally used
-slots we accumulate one free delivery slot, than the inflation factor is not
-worse than k/(k-1) no matter how many recursive preemptions happen. And it's
-not worse than (k+1)/k if only non-recursive preemption happens. Now, having
-got through the theory and the related math, let's see how nqmgr implements
-this.
+Well, despite the fact that it looks so at the first glance, another trick will
+allow us to answer "no, we are not!". If we had said that we will inflate the
+delivery time twice at maximum, and then we consider every other slot as a free
+slot, then we would overinflate in case of the recursive preemption. BUT! The
+trick is that if we use only every n-th slot as a free slot for n>2, there is
+always some worst inflation factor which we can guarantee not to be breached,
+even if we apply the algorithm recursively. To be precise, if for every k>1
+normally used slots we accumulate one free delivery slot, than the inflation
+factor is not worse than k/(k-1) no matter how many recursive preemptions
+happen. And it's not worse than (k+1)/k if only non-recursive preemption
+happens. Now, having got through the theory and the related math, let's see how
+nqmgr implements this.
 
 Each job has so called "available delivery slot" counter. Each transport has a
 transport_delivery_slot_cost parameter, which defaults to
 default_delivery_slot_cost parameter which is set to 5 by default. This is the
 k from the paragraph above. Each time k entries of the job are selected for
 delivery, this counter is incremented by one. Once there are some slots
-accumulated, job which requires no more than that number of slots to be fully
+accumulated, a job which requires no more than that number of slots to be fully
 delivered can preempt this job.
 
 [Well, the truth is, the counter is incremented every time an entry is selected
-and it is divided by k when it is used. But for the understanding it's good
-enough to use the above approximation of the truth.]
+and it is divided by k when it is used. But to understand, it's good enough to
+use the above approximation of the truth.]
 
 OK, so now we know the conditions which must be satisfied so one job can
 preempt another one. But what job gets preempted, how do we choose what job
@@ -720,11 +720,11 @@ preempts it if there are several valid candidates, and when does all this
 exactly happen?
 
 The answer for the first part is simple. The job whose entry was selected the
-last time is so called current job. Normally, it is the first job on the
+last time is the so called current job. Normally, it is the first job on the
 scheduler's job list, but destination concurrency limits may change this as we
 will see later. It is always only the current job which may get preempted.
 
-Now for the second part. The current job has certain amount of recipient
+Now for the second part. The current job has a certain amount of recipient
 entries, and as such may accumulate at maximum some amount of available
 delivery slots. It might have already accumulated some, and perhaps even
 already used some when it was preempted before (remember a job can be preempted
@@ -737,22 +737,22 @@ The answer is - the one with maximum enqueue_time/recipient_entry_count. That
 is, the older the job is, the more we should try to deliver it in order to get
 best message delivery rates. These rates are of course subject to how many
 recipients the message has, therefore the division by the recipient (entry)
-count. No one shall be surprised that message with n recipients takes n times
-longer to deliver than message with one recipient.
+count. No one shall be surprised that a message with n recipients takes n times
+longer to deliver than a message with one recipient.
 
 Now let's recap the previous two paragraphs. Isn't it too complicated? Why
 don't the candidates come only among the jobs which can be delivered within the
 number of slots the current job already accumulated? Why do we need to estimate
 how much it has yet to accumulate? If you found out the answer, congratulate
 yourself. If we did it this simple way, we would always choose the candidate
-with least recipient entries. If there were enough single recipient mails
+with the fewest recipient entries. If there were enough single recipient mails
 coming in, they would always slip by the bulk mail as soon as possible, and the
-two and more recipients mail would never get a chance, no matter how long they
+two or more recipients mail would never get a chance, no matter how long they
 have been sitting around in the job list.
 
-This candidate selection has interesting implication - that when we choose the
-best candidate for preemption (this is done in qmgr_choose_candidate()), it may
-happen that we may not use it for preemption immediately. This leads to an
+This candidate selection has an interesting implication - that when we choose
+the best candidate for preemption (this is done in qmgr_choose_candidate()), it
+may happen that we may not use it for preemption immediately. This leads to an
 answer to the last part of the original question - when does the preemption
 happen?
 
@@ -760,23 +760,23 @@ The preemption attempt happens every time next transport's recipient entry is
 to be chosen for delivery. To avoid needless overhead, the preemption is not
 attempted if the current job could never accumulate more than
 transport_minimum_delivery_slots (defaults to default_minimum_delivery_slots
-which defaults to 3). If there is already enough accumulated slots to preempt
+which defaults to 3). If there are already enough accumulated slots to preempt
 the current job by the chosen best candidate, it is done immediately. This
 basically means that the candidate is moved in front of the current job on the
 scheduler's job list and decreasing the accumulated slot counter by the amount
-used by the candidate. If there is not enough slots... well, I could say that
+used by the candidate. If there are not enough slots... well, I could say that
 nothing happens and the another preemption is attempted the next time. But
 that's not the complete truth.
 
 The truth is that it turns out that it is not really necessary to wait until
 the jobs counter accumulates all the delivery slots in advance. Say we have
 ten-recipient mail followed by two two-recipient mails. If the preemption
-happened when enough delivery slot accumulate (assuming slot cost 2), the
+happened when enough delivery slots accumulate (assuming slot cost 2), the
 delivery sequence becomes 11112211113311. Now what would we get if we would
 wait only for 50% of the necessary slots to accumulate and we promise we would
 wait for the remaining 50% later, after we get back to the preempted job? If we
-use such slot loan, the delivery sequence becomes 11221111331111. As we can
-see, it makes it no considerably worse for the delivery of the ten-recipient
+use such a slot loan, the delivery sequence becomes 11221111331111. As we can
+see, it makes it not considerably worse for the delivery of the ten-recipient
 mail, but it allows the small messages to be delivered sooner.
 
 The concept of these slot loans is where the transport_delivery_slot_discount
@@ -787,11 +787,11 @@ many percent (resp. how many slots) one "gets in advance", when the number of
 slots required to deliver the best candidate is compared with the number of
 slots the current slot had accumulated so far.
 
-And it pretty much concludes this chapter.
+And that pretty much concludes this chapter.
 
 [Now you should have a feeling that you pretty much understand the scheduler
-and the preemption, or at least that you will have it after you read the last
-chapter couple more times. You shall clearly see the job list and the
+and the preemption, or at least that you will have after you read the last
+chapter a couple more times. You shall clearly see the job list and the
 preemption happening at its head, in ideal delivery conditions. The feeling of
 understanding shall last until you start wondering what happens if some of the
 jobs are blocked, which you might eventually figure out correctly from what had
@@ -805,17 +805,18 @@ The nqmgr uses the same algorithm for destination concurrency control as oqmgr.
 Now what happens when the destination limits are reached and no more entries
 for that destination may be selected by the scheduler?
 
-From user's point of view it is all simple. If some of the peers of a job can't
-be selected, those peers are simply skipped by the entry selection algorithm
-(the pseudo-code described before) and only the selectable ones are used. If
-none of the peers may be selected, the job is declared a "blocker job". Blocker
-jobs are skipped by the entry selection algorithm and they are also excluded
-from the candidates for preemption of current job. Thus the scheduler
-effectively behaves as if the blocker jobs didn't exist on the job list at all.
-As soon as at least one of the peers of a blocker job becomes unblocked (that
-is, the delivery agent handling the delivery of the recipient entry for given
-destination successfully finishes), the job's blocker status is removed and the
-job again participates in all further scheduler actions normally.
+From the user's point of view it is all simple. If some of the peers of a job
+can't be selected, those peers are simply skipped by the entry selection
+algorithm (the pseudo-code described before) and only the selectable ones are
+used. If none of the peers may be selected, the job is declared a "blocker
+job". Blocker jobs are skipped by the entry selection algorithm and they are
+also excluded from the candidates for preemption of the current job. Thus the
+scheduler effectively behaves as if the blocker jobs didn't exist on the job
+list at all. As soon as at least one of the peers of a blocker job becomes
+unblocked (that is, the delivery agent handling the delivery of the recipient
+entry for the given destination successfully finishes), the job's blocker
+status is removed and the job again participates in all further scheduler
+actions normally.
 
 So the summary is that the users don't really have to be concerned about the
 interaction of the destination limits and scheduling algorithm. It works well
@@ -844,8 +845,8 @@ are selected, and once they are all selected, job 1 continues.
 As we see, it's all very clean and straightforward. Now how does this change
 because of blockers?
 
-The answer is: a lot. Any job may become blocker job at any time, and also
-become normal job again at any time. This has several important implications:
+The answer is: a lot. Any job may become a blocker job at any time, and also
+become a normal job again at any time. This has several important implications:
 
  1. The jobs may be completed in arbitrary order. For example, in the example
     above, if the current job 7 becomes blocked, the next job 4 may complete
@@ -854,7 +855,7 @@ become normal job again at any time. This has several important implications:
     completed and only after that 4 becomes unblocked and is completed... You
     get the idea.
 
-    [Interesting side note: even when jobs are delivered out of order, from
+    [Interesting side note: even when jobs are delivered out of order, from a
     single destination's point of view the jobs are still delivered in the
     expected order (that is, FIFO unless there was some preemption involved).
     This is because whenever a destination queue becomes unblocked (the
@@ -885,7 +886,7 @@ the point 3) example: jobs 7 and 8 preempt job 4, now job 8 becomes blocked
 too, then job 4 completes. Tricky, huh?
 
 If I illustrate the relations after the above mentioned examples (but those in
-point 1)), the situation would look like this:
+point 1), the situation would look like this:
 
                                 v- parent
 
@@ -900,11 +901,11 @@ point 1)), the situation would look like this:
 Now how does nqmgr deal with all these complicated relations?
 
 Well, it maintains them all as described, but fortunately, all these relations
-are necessary only for purposes of proper counting of available delivery slots.
-For purposes of ordering the jobs for entry selection, the original rule still
-applies: "the job preempting the current job is moved in front of the current
-job on the job list". So for entry selection purposes, the job relations remain
-as simple as this:
+are necessary only for the purpose of proper counting of available delivery
+slots. For the purpose of ordering the jobs for entry selection, the original
+rule still applies: "the job preempting the current job is moved in front of
+the current job on the job list". So for entry selection purposes, the job
+relations remain as simple as this:
 
     7--8--1--2--6--3--5--..   <- scheduler's job list order
 
@@ -916,8 +917,8 @@ introduction to the problem domain. Otherwise I suggest you just forget about
 all this and stick with the user's point of view: the blocker jobs are simply
 ignored.
 
-[By now, you should have a feeling that there is more things going under the
-hood than you ever wanted to know. You decide that forgetting about this
+[By now, you should have a feeling that there are more things going on under
+the hood than you ever wanted to know. You decide that forgetting about this
 chapter is the best you can do for the sake of your mind's health and you
 basically stick with the idea how the scheduler works in ideal conditions, when
 there are no blockers, which is good enough.]
@@ -925,25 +926,25 @@ there are no blockers, which is good enough.]
 DDeeaalliinngg wwiitthh mmeemmoorryy rreessoouurrccee lliimmiittss
 
 When discussing the nqmgr scheduler, we have so far assumed that all recipients
-of all messages in the active queue are completely read into the memory. This
-is simply not true. There is an upper bound on the amount of memory the nqmgr
-may use, and therefore it must impose some limits on the information it may
-store in the memory at any given time.
+of all messages in the "active" queue are completely read into memory. This is
+simply not true. There is an upper bound on the amount of memory the nqmgr may
+use, and therefore it must impose some limits on the information it may store
+in memory at any given time.
 
 First of all, not all messages may be read in-core at once. At any time, only
 qmgr_message_active_limit messages may be read in-core at maximum. When read
-into memory, the messages are picked from the incoming and deferred message
-queues and moved to the active queue (incoming having priority), so if there is
-more than qmgr_message_active_limit messages queued in the active queue, the
-rest will have to wait until (some of) the messages in the active queue are
+into memory, the messages are picked from the "incoming" and "deferred" queues
+and moved to the "active" queue (incoming having priority), so if there are
+more than qmgr_message_active_limit messages queued in the "active" queue, the
+rest will have to wait until (some of) the messages in the "active" queue are
 completely delivered (or deferred).
 
 Even with the limited amount of in-core messages, there is another limit which
-must be imposed in order to avoid memory exhaustion. Each message may contain
-huge amount of recipients (tens or hundreds of thousands are not uncommon), so
-if nqmgr read all recipients of all messages in the active queue, it may easily
-run out of memory. Therefore there must be some upper bound on the amount of
-message recipients which are read into the memory at the same time.
+must be imposed in order to avoid memory exhaustion. Each message may contain a
+huge number of recipients (tens or hundreds of thousands are not uncommon), so
+if nqmgr read all recipients of all messages in the "active" queue, it may
+easily run out of memory. Therefore there must be some upper bound on the
+amount of message recipients which are read into memory at the same time.
 
 Before discussing how exactly nqmgr implements the recipient limits, let's see
 how the sole existence of the limits themselves affects the nqmgr and its
@@ -951,7 +952,7 @@ scheduler.
 
 The message limit is straightforward - it just limits the size of the lookahead
 the nqmgr's scheduler has when choosing which message can preempt the current
-one. Messages not in the active queue simply are not considered at all.
+one. Messages not in the "active" queue are simply not considered at all.
 
 The recipient limit complicates more things. First of all, the message reading
 code must support reading the recipients in batches, which among other things
@@ -967,14 +968,14 @@ file, the scheduler can't operate with exact counts of recipient entries. With
 unread recipients, it is not clear how many recipient entries there will be, as
 they are subject to per-destination grouping. It is not even clear to what
 transports (and thus jobs) the recipients will be assigned. And with messages
-coming from the deferred queue, it is not even clear how many unread recipients
-are still to be delivered. This all means that the scheduler must use only
-estimates of how many recipients entries there will be. Fortunately, it is
-possible to estimate the minimum and maximum correctly, so the scheduler can
-always err on the safe side. Obviously, the better the estimates, the better
-results, so it is best when we are able to read all recipients in-core and turn
-the estimates into exact counts, or at least try to read as many as possible to
-make the estimates as accurate as possible.
+coming from the "deferred" queue, it is not even clear how many unread
+recipients are still to be delivered. This all means that the scheduler must
+use only estimates of how many recipients entries there will be. Fortunately,
+it is possible to estimate the minimum and maximum correctly, so the scheduler
+can always err on the safe side. Obviously, the better the estimates, the
+better the results, so it is best when we are able to read all recipients in-
+core and turn the estimates into exact counts, or at least try to read as many
+as possible to make the estimates as accurate as possible.
 
 The third complication is that it is no longer true that the scheduler is done
 with a job once all of its in-core recipients are delivered. It is possible
@@ -987,9 +988,9 @@ And finally, the fourth complication is that the nqmgr code must somehow impose
 the recipient limit itself. Now how does it achieve it?
 
 Perhaps the easiest solution would be to say that each message may have at
-maximum X recipients stored in-core, but such solution would be poor for
+maximum X recipients stored in-core, but such a solution would be poor for
 several reasons. With reasonable qmgr_message_active_limit values, the X would
-have to be quite low to maintain reasonable memory footprint. And with low X
+have to be quite low to maintain a reasonable memory footprint. And with low X
 lots of things would not work well. The nqmgr would have problems to use the
 transport_destination_recipient_limit efficiently. The scheduler's preemption
 would be suboptimal as the recipient count estimates would be inaccurate. The
@@ -997,28 +998,28 @@ message queue file would have to be accessed many times to read in more
 recipients again and again.
 
 Therefore it seems reasonable to have a solution which does not use a limit
-imposed on per-message basis, but which maintains a pool of available recipient
-slots, which can be shared among all messages in the most efficient manner. And
-as we do not want separate transports to compete for resources whenever
-possible, it seems appropriate to maintain such recipient pool for each
-transport separately. This is the general idea, now how does it work in
+imposed on a per-message basis, but which maintains a pool of available
+recipient slots, which can be shared among all messages in the most efficient
+manner. And as we do not want separate transports to compete for resources
+whenever possible, it seems appropriate to maintain such a recipient pool for
+each transport separately. This is the general idea, now how does it work in
 practice?
 
-First we have to solve little chicken-and-egg problem. If we want to use the
-per-transport recipient pools, we first need to know to what transport(s) is
-the message assigned. But we will find that out only after we read in the
-recipients first. So it is obvious that we first have to read in some
-recipients, use them to find out to what transports is the message to be
-assigned, and only after that we can use the per-transport recipient pools.
+First we have to solve a little chicken-and-egg problem. If we want to use the
+per-transport recipient pools, we first need to know to what transport(s) the
+message is assigned. But we will find that out only after we first read in the
+recipients. So it is obvious that we first have to read in some recipients, use
+them to find out to what transports the message is to be assigned, and only
+after that can we use the per-transport recipient pools.
 
 Now how many recipients shall we read for the first time? This is what
 qmgr_message_recipient_minimum and qmgr_message_recipient_limit values control.
 The qmgr_message_recipient_minimum value specifies how many recipients of each
-message we will read for the first time, no matter what. It is necessary to
-read at least one recipient before we can assign the message to a transport and
-create the first job. However, reading only qmgr_message_recipient_minimum
-recipients even if there are only few messages with few recipients in-core
-would be wasteful. Therefore if there is less than qmgr_message_recipient_limit
+message we will read the first time, no matter what. It is necessary to read at
+least one recipient before we can assign the message to a transport and create
+the first job. However, reading only qmgr_message_recipient_minimum recipients
+even if there are only few messages with few recipients in-core would be
+wasteful. Therefore if there are fewer than qmgr_message_recipient_limit
 recipients in-core so far, the first batch of recipients may be larger than
 qmgr_message_recipient_minimum - as large as is required to reach the
 qmgr_message_recipient_limit limit.
@@ -1033,12 +1034,12 @@ recipient batch may be as large as the sum of all recipient slots of all jobs
 of the message permits (plus the qmgr_message_recipient_minimum amount which
 always applies).
 
-For example, if a message has three jobs, first with 1 recipient still in-core
-and 4 recipient slots, second with 5 recipient in-core and 5 recipient slots,
-and third with 2 recipients in-core and 0 recipient slots, it has 1+5+2=7
-recipients in-core and 4+5+0=9 jobs' recipients slots in total. This means that
-we could immediately read 2+qmgr_message_recipient_minimum more recipients of
-that message in core.
+For example, if a message has three jobs, the first with 1 recipient still in-
+core and 4 recipient slots, the second with 5 recipients in-core and 5
+recipient slots, and the third with 2 recipients in-core and 0 recipient slots,
+it has 1+5+2=8 recipients in-core and 4+5+0=9 jobs' recipients slots in total.
+This means that we could immediately read 2+qmgr_message_recipient_minimum more
+recipients of that message in core.
 
 The above example illustrates several things which might be worth mentioning
 explicitly: first, note that although the per-transport slots are assigned to
@@ -1067,17 +1068,17 @@ job list does.
 More specifically, each time a job is created and appended to the job list, it
 gets all unused recipient slots from its transport's pool. It keeps them until
 all recipients of its message are read. When this happens, all unused recipient
-slots are transferred to the next job (which is now in fact now first such job)
+slots are transferred to the next job (which is now in fact the first such job)
 on the job list which still has some recipients unread, or eventually back to
-the transport pool if there is no such job. Such transfer then also happens
+the transport pool if there is no such job. Such a transfer then also happens
 whenever a recipient entry of that job is delivered.
 
 There is also a scenario when a job is not appended to the end of the job list
-(for example it was created as a result of second or later recipient batch).
+(for example it was created as a result of a second or later recipient batch).
 Then it works exactly as above, except that if it was put in front of the first
 unread job (that is, the job of a message which still has some unread
-recipients in queue file), that job is first forced to return all of its unused
-recipient slots to the transport pool.
+recipients in the queue file), that job is first forced to return all of its
+unused recipient slots to the transport pool.
 
 The algorithm just described leads to the following state: The first unread job
 on the job list always gets all the remaining recipient slots of that transport
@@ -1087,22 +1088,22 @@ maximum as many slots as they still have recipients in-core (the maximum is
 there because of the sponsoring mentioned before) and the jobs after this job
 get nothing from the transport recipient pool (unless they got something before
 and then the first unread job was created and enqueued in front of them later -
-in such case the also get at maximum as many slots as they have recipients in-
-core).
+in such a case, they also get at maximum as many slots as they have recipients
+in-core).
 
-Things work fine in such state for most of the time, because the current job is
-either completely read in-core or has as much recipient slots as there are, but
-there is one situation which we still have to take care of specially. Imagine
-if the current job is preempted by some unread job from the job list and there
-are no more recipient slots available, so this new current job could read only
-batches of qmgr_message_recipient_minimum recipients at a time. This would
-really degrade performance. For this reason, each transport has extra pool of
-transport_extra_recipient_limit recipient slots, dedicated exactly for this
-situation. Each time an unread job preempts the current job, it gets half of
-the remaining recipient slots from the normal pool and this extra pool.
+Things work fine in such a state for most of the time, because the current job
+is either completely read in-core or has as many recipient slots as there are,
+but there is one situation which we still have to take care of specially.
+Imagine if the current job is preempted by some unread job from the job list
+and there are no more recipient slots available, so this new current job could
+read only batches of qmgr_message_recipient_minimum recipients at a time. This
+would really degrade performance. For this reason, each transport has an extra
+pool of transport_extra_recipient_limit recipient slots, dedicated exactly for
+this situation. Each time an unread job preempts the current job, it gets half
+of the remaining recipient slots from the normal pool and this extra pool.
 
 And that's it. It sure does sound pretty complicated, but fortunately most
-people don't really have to care how exactly it works as long as it works.
+people don't really have to care exactly how it works as long as it works.
 Perhaps the only important things to know for most people are the following
 upper bound formulas:
 
@@ -1126,14 +1127,14 @@ The total amount of recipients in core is
 
 where the sum is over all used transports.
 
-And this terribly complicated chapter concludes the documentation of nqmgr
+And this terribly complicated chapter concludes the documentation of the nqmgr
 scheduler.
 
 [By now you should theoretically know the nqmgr scheduler inside out. In
 practice, you still hope that you will never have to really understand the last
 or last two chapters completely, and fortunately most people really won't.
 Understanding how the scheduler works in ideal conditions is more than good
-enough for vast majority of users.]
+enough for the vast majority of users.]
 
 CCrreeddiittss
 

postfix/README_FILES/SMTPD_ACCESS_README

@@ -23,8 +23,8 @@ RReellaayy ccoonnttrrooll,, jjuunnkk mmaaiill ccoonnttr
 In a distant past, the Internet was a friendly environment. Mail servers
 happily forwarded mail on behalf of anyone towards any destination. On today's
 Internet, spammers abuse servers that forward mail from arbitrary systems, and
-abused systems end up on anti-spammer blacklists. See, for example, the
-information on http://www.mail-abuse.org/ and other websites.
+abused systems end up on anti-spammer denylists. See, for example, the
+information on https://www.spamhaus.org/ and other websites.
 
 By default, Postfix has a moderately restrictive approach to mail relaying.
 Postfix forwards mail only from clients in trusted networks, from clients that
@@ -50,11 +50,11 @@ email.
     Protocol-oriented access controls become less useful over time as spammers
     and worm writers learn to read RFC documents.
 
-  * Blacklist oriented: some SMTP server access controls query blacklists with
+  * Denylist oriented: some SMTP server access controls query denylists with
     known to be bad sites such as open mail relays, open web proxies, and home
     computers that have been compromised and that are under remote control by
-    criminals. The effectiveness of these blacklists depends on how complete
-    and how up to date they are.
+    criminals. The effectiveness of these denylists depends on how complete and
+    how up to date they are.
 
   * Threshold oriented: some SMTP server access controls attempt to raise the
     bar by either making the client do more work (greylisting) or by asking for
@@ -131,12 +131,6 @@ Examples of simple restriction lists are:
     # Don't accept mail from domains that don't exist.
     smtpd_sender_restrictions = reject_unknown_sender_domain
 
-    # Relay control (Postfix 2.10 and later): local clients and
-    # authenticated clients may specify any destination domain.
-    smtpd_relay_restrictions = permit_mynetworks,
-        permit_sasl_authenticated,
-        reject_unauth_destination
-
     # Spam control: exclude local clients and authenticated clients
     # from DNSBL lookups.
     smtpd_recipient_restrictions = permit_mynetworks,
@@ -150,6 +144,12 @@ Examples of simple restriction lists are:
         reject_rhsbl_helo dbl.spamhaus.org,
         reject_rhsbl_sender dbl.spamhaus.org
 
+    # Relay control (Postfix 2.10 and later): local clients and
+    # authenticated clients may specify any destination domain.
+    smtpd_relay_restrictions = permit_mynetworks,
+        permit_sasl_authenticated,
+        reject_unauth_destination
+
     # Block clients that speak too early.
     smtpd_data_restrictions = reject_unauth_pipelining
 
@@ -160,8 +160,9 @@ Each restriction list is evaluated from left to right until some restriction
 produces a result of PERMIT, REJECT or DEFER (try again later). The end of each
 list is equivalent to a PERMIT result. By placing a PERMIT restriction before a
 REJECT restriction you can make exceptions for specific clients or users. This
-is called whitelisting; the fourth example above allows mail from local
-networks but otherwise rejects mail to arbitrary destinations.
+is called allowlisting; the smtpd_relay_restrictions example above allows mail
+from local networks, and from SASL authenticated clients, but otherwise rejects
+mail to arbitrary destinations.
 
 The table below summarizes the purpose of each SMTP access restriction list.
 All lists use the exact same syntax; they differ only in the time of evaluation
@@ -186,15 +187,6 @@ and in the effect of a REJECT or DEFER result.
     |                              |       |                            |information|
     |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
     |                              |       |Required if                 |           |
-    |                              |>= 2.10|smtpd_recipient_restrictions|           |
-    |                              |       |does not enforce relay      |Reject RCPT|
-    |smtpd_relay_restrictions      |       |policy                      |TO         |
-    |                              |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |information|
-    |                              |       |                            |           |
-    |                              |< 2.10 |Not available               |           |
-    |                              |       |                            |           |
-    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
-    |                              |       |Required if                 |           |
     |                              |>= 2.10|smtpd_relay_restrictions    |           |
     |                              |       |does not enforce relay      |Reject RCPT|
     |smtpd_recipient_restrictions  |       |policy                      |TO         |
@@ -203,6 +195,15 @@ and in the effect of a REJECT or DEFER result.
     |                              |< 2.10 |Required                    |           |
     |                              |       |                            |           |
     |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+    |                              |       |Required if                 |           |
+    |                              |>= 2.10|smtpd_recipient_restrictions|           |
+    |                              |       |does not enforce relay      |Reject RCPT|
+    |smtpd_relay_restrictions      |       |policy                      |TO         |
+    |                              |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |information|
+    |                              |       |                            |           |
+    |                              |< 2.10 |Not available               |           |
+    |                              |       |                            |           |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
     |smtpd_data_restrictions       |>= 2.0 |Optional                    |Reject DATA|
     |                              |       |                            |command    |
     |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
@@ -248,7 +249,7 @@ Benefits of delayed restriction evaluation, and of restriction mixing:
     logging only the client hostname and IP address and not knowing whose mail
     was being blocked.
 
-  * Mixing is needed for complex whitelisting policies. For example, in order
+  * Mixing is needed for complex allowlisting policies. For example, in order
     to reject local sender addresses in mail from non-local clients, you need
     to be able to mix restrictions on client information with restrictions on
     sender information in the same restriction list. Without this ability, many

postfix/README_FILES/SMTPD_POLICY_README

@@ -14,7 +14,7 @@ document. A complete example can be found in the Postfix source code, in the
 directory examples/smtpd-policy.
 
 Another example of policy delegation is the SPF policy server at http://
-www.openspf.org/Software.
+www.open-spf.org/Software/
 
 Policy delegation is now the preferred method for adding policies to Postfix.
 It's much easier to develop a new feature in few lines of Perl, Python, Ruby,
@@ -36,10 +36,14 @@ This document covers the following topics:
 
 PPrroottooccooll ddeessccrriippttiioonn
 
-The Postfix policy delegation protocol is really simple. The client request is
-a sequence of name=value attributes separated by newline, and is terminated by
-an empty line. The server reply is one name=value attribute and it, too, is
-terminated by an empty line.
+The Postfix policy delegation protocol is really simple. The client sends a
+request and the server sends a response. Unless there was an error, the server
+must not close the connection, so that the same connection can be used multiple
+times.
+
+The client request is a sequence of name=value attributes separated by newline,
+and is terminated by an empty line. The server reply is one name=value
+attribute and it, too, is terminated by an empty line.
 
 Here is an example of all the attributes that the Postfix SMTP server sends in
 a delegated SMTPD access policy request:
@@ -81,6 +85,9 @@ a delegated SMTPD access policy request:
     PPoossttffiixx vveerrssiioonn 33..22 aanndd llaatteerr::
     server_address=10.3.2.1
     server_port=54321
+    PPoossttffiixx vveerrssiioonn 33..88 aanndd llaatteerr::
+    compatibility_level=major.minor.patch
+    mail_version=3.8.0
     [empty line]
 
 Notes:
@@ -100,11 +107,15 @@ Notes:
 
   * The "recipient" attribute is available in the "RCPT TO" stage. It is also
     available in the "DATA" and "END-OF-MESSAGE" stages if Postfix accepted
-    only one recipient for the current message.
+    only one recipient for the current message. The DATA protocol state also
+    applies to email that is received with BDAT commands (Postfix 3.4 and
+    later).
 
   * The "recipient_count" attribute (Postfix 2.3 and later) is non-zero only in
     the "DATA" and "END-OF-MESSAGE" stages. It specifies the number of
-    recipients that Postfix accepted for the current message.
+    recipients that Postfix accepted for the current message. The DATA protocol
+    state also applies to email that is received with BDAT commands (Postfix
+    3.4 and later).
 
   * The remote client or local server IP address is an IPv4 dotted quad in the
     form 1.2.3.4 or it is an IPv6 address in the form 1:2:3::4:5:6.
@@ -128,8 +139,8 @@ Notes:
 
   * The "size" attribute value specifies the message size that the client
     specified in the MAIL FROM command (zero if none was specified). With
-    Postfix 2.2 and later, it specifies the actual message size when the client
-    sends the END-OF-DATA command.
+    Postfix 2.2 and later, it specifies the actual message size after the
+    client sends the END-OF-MESSAGE.
 
   * The "sasl_*" attributes (Postfix 2.2 and later) specify information about
     how the client was authenticated via SASL. These attributes are empty in
@@ -156,13 +167,23 @@ Notes:
   * The "policy_context" attribute provides a way to pass information that is
     not available via other attributes (Postfix version 3.1 and later).
 
+  * The "compatibility_level" attribute corresponds to the compatibility_level
+    parameter value. It has the form major.minor.patch where minor and patch
+    may be absent.
+
+  * The "mail_version" attribute corresponds to the mail_version parameter
+    value. It has the form major.minor.patch for stable releases, and
+    major.minor-yyyymmdd for unstable releases.
+
 The following is specific to SMTPD delegated policy requests:
 
   * Protocol names are ESMTP or SMTP.
 
   * Protocol states are CONNECT, EHLO, HELO, MAIL, RCPT, DATA, END-OF-MESSAGE,
     VRFY or ETRN; these are the SMTP protocol states where the Postfix SMTP
-    server makes an OK/REJECT/HOLD/etc. decision.
+    server makes an OK/REJECT/HOLD/etc. decision. The DATA protocol state also
+    applies to email that is received with BDAT commands (Postfix 3.4 and
+    later).
 
 The policy server replies with any action that is allowed in a Postfix SMTPD
 access(5) table. Example:
@@ -191,7 +212,7 @@ The first example specifies that the policy server listens on a TCP socket at
 127.0.0.1 port 9998. The second example specifies an absolute pathname of a
 UNIX-domain socket. The third example specifies a pathname relative to the
 Postfix queue directory; use this for policy servers that are spawned by the
-Postfix master daemon.
+Postfix master daemon. On many systems, "local" is a synonym for "unix".
 
 To create a policy service that listens on a UNIX-domain socket called
 "policy", and that runs under control of the Postfix spawn(8) daemon, you would
@@ -230,7 +251,7 @@ NOTES:
 
   * Line 11: this increases the time that a policy server process may run to
     3600 seconds. The default time limit of 1000 seconds is too short; the
-    policy daemon needs to run long as the SMTP server process that talks to
+    policy daemon needs to run as long as the SMTP server process that talks to
     it. See the spawn(8) manpage for more information about the
     transport_time_limit parameter.
 
@@ -314,11 +335,12 @@ timeout, and with "DUNNO" as default action when the service is unvailable. The
 "DUNNO" action causes Postfix to ignore the result.
 
     1 /etc/postfix/main.cf:
-    2     smtpd_recipient_restrictions =
+    2     mua_recipient_restrictions =
     3         ...
     4         reject_unauth_destination
     5         check_policy_service { inet:host:port,
-    6             timeout=10s, default_action=DUNNO }
+    6             timeout=10s, default_action=DUNNO
+    7             policy_context=submission }
     8         ...
 
 Instead of a server endpoint, we now have a list enclosed in {}.
@@ -326,7 +348,7 @@ Instead of a server endpoint, we now have a list enclosed in {}.
   * Line 5: The first item in the list is the server endpoint. This supports
     the exact same "inet" and "unix" syntax as described earlier.
 
-  * Line 6: The remainder of the list contains per-client settings. These
+  * Line 6-7: The remainder of the list contains per-client settings. These
     settings override global main.cf parameters, and have the same name as
     those parameters, without the "smtpd_policy_service_" prefix.
 
@@ -343,16 +365,16 @@ text:
     4         reject_unauth_destination
     5         check_policy_service {
     6           inet:host:port1,
-    7           { default_action = 451 4.3.5 See http://www.example.com/
+    7           { default_action = 451 4.3.5 See https://www.example.com/
     support1 }
     8         }
     9         ...
 
 EExxaammppllee:: ggrreeyylliisstt ppoolliiccyy sseerrvveerr
 
-Greylisting is a defense against junk email that is described at http://
+Greylisting is a defense against junk email that is described at https://
 www.greylisting.org/. The idea was discussed on the postfix-users mailing list
-one year before it was popularized.
+one year before it was popularized (alternative version).
 
 The file examples/smtpd-policy/greylist.pl in the Postfix source tree
 implements a simplified greylist policy server. This server stores a time stamp
@@ -421,8 +443,8 @@ Notes:
 
   * Line 6: this increases the time that a greylist server process may run to
     3600 seconds. The default time limit of 1000 seconds is too short; the
-    greylist daemon needs to run long as the SMTP server process that talks to
-    it. See the spawn(8) manpage for more information about the
+    greylist daemon needs to run as long as the SMTP server process that talks
+    to it. See the spawn(8) manpage for more information about the
     transport_time_limit parameter.
 
   * Line 9: reject_unauth_destination is not needed here if the mail relay
@@ -459,8 +481,9 @@ GGrreeyylliissttiinngg mmaaiill ffrroomm ffrreeqquueen
 
 It is relatively safe to turn on greylisting for specific domains that often
 appear in forged email. At some point in cyberspace/time a list of frequently
-forged MAIL FROM domains could be found at http://www.monkeys.com/anti-spam/
-filtering/sender-domain-validate.in.
+forged MAIL FROM domains could be found at https://web.archive.org/web/
+20080526153208/http://www.monkeys.com/anti-spam/filtering/sender-domain-
+validate.in.
 
      1 /etc/postfix/main.cf:
      2     smtpd_recipient_restrictions =
@@ -505,7 +528,7 @@ If you turn on greylisting for all mail you may want to make exceptions for
 mailing lists that use one-time sender addresses, because each message will be
 delayed due to greylisting, and the one-time sender addresses can pollute your
 greylist database relatively quickly. Instead of making exceptions, you can
-automatically whitelist clients that survive greylisting repeatedly; this
+automatically allowlist clients that survive greylisting repeatedly; this
 avoids most of the delays and most of the database pollution problem.
 
      1 /etc/postfix/main.cf:
@@ -567,11 +590,11 @@ $database_name="/var/mta/greylist.db";
 $greylist_delay=60;
 
 #
-# Auto-whitelist threshold. Specify 0 to disable, or the number of
+# Auto-allowlist threshold. Specify 0 to disable, or the number of
 # successful "come backs" after which a client is no longer subject
 # to greylisting.
 #
-$auto_whitelist_threshold = 10;
+$auto_allowlist_threshold = 10;
 
 #
 # Demo SMTPD access policy routine. The result is an action just like
@@ -584,10 +607,10 @@ sub smtpd_access_policy {
     # Open the database on the fly.
     open_database() unless $database_obj;
 
-    # Search the auto-whitelist.
-    if ($auto_whitelist_threshold > 0) {
+    # Search the auto-allowlist.
+    if ($auto_allowlist_threshold > 0) {
         $count = read_database($attr{"client_address"});
-        if ($count > $auto_whitelist_threshold) {
+        if ($count > $auto_allowlist_threshold) {
             return "dunno";
         }
     }
@@ -616,8 +639,8 @@ sub smtpd_access_policy {
     #
     syslog $syslog_priority, "request age %d", $now - $time_stamp if $verbose;
     if ($now - $time_stamp > $greylist_delay) {
-        # Update the auto-whitelist.
-        if ($auto_whitelist_threshold > 0) {
+        # Update the auto-allowlist.
+        if ($auto_allowlist_threshold > 0) {
             update_database($attr{"client_address"}, $count + 1);
         }
         return "dunno";

postfix/README_FILES/SMTPD_PROXY_README

@@ -71,6 +71,25 @@ PPrrooss aanndd ccoonnss ooff bbeeffoorree--qquueeuuee
     sender (which is usually forged anyway). Mail that is not accepted remains
     the responsibility of the remote SMTP client.
 
+  * Con: The smtpd(8) service before the smtpd_proxy_filter cannot support
+    features that involve header or body access, or that involve queue file
+    manipulation (i.e., anything that involves processing by the cleanup(8)
+    service).
+
+      o No support for HOLD actions in Postfix smtpd access(5) restrictions.
+
+      o No support for smtpd_milters features that involve message header or
+        body content.
+
+      o No support for receive_override_options.
+
+    Instead, specify those features with the smtpd(8) service behind the
+    smtpd_proxy_filter. In some cases, it may be possible to combine a before-
+    filter PREPEND action that emits a unique pattern (for example containing
+    the MTA domain name), with an after-filter header_checks action that does
+    what you want, and with an smtp_header_checks IGNORE action that deletes
+    the prepended header from transit mail.
+
   * Con: The remote SMTP client expects an SMTP reply within a deadline. As the
     system load increases, fewer and fewer CPU cycles remain available to
     answer within the deadline, and eventually you either have to stop
@@ -102,8 +121,9 @@ From then on mail is processed as usual.
 
 The content filter itself is not described here. You can use any filter that is
 SMTP enabled. For non-SMTP capable content filtering software, Bennett Todd's
-SMTP proxy implements a nice Perl-based framework. See: http://
-bent.latency.net/smtpprox/ or https://github.com/jnorell/smtpprox.
+SMTP proxy implements a nice Perl-based framework. See: https://
+web.archive.org/web/20151022025756/http://bent.latency.net/smtpprox/ or https:/
+/github.com/jnorell/smtpprox/
 
                                                Postfix
                   Postfix      filter on     SMTP server    Postfix    Postfix
@@ -197,9 +217,9 @@ The after-filter SMTP server is a new master.cf entry:
 
 By default, the filter has 100 seconds to do its work. If it takes longer then
 Postfix gives up and reports an error to the remote SMTP client. You can
-increase this time limit (see configuration parameter section below) but doing
-so is pointless because you can't control when the remote SMTP client times
-out.
+increase this time limit (see the "Configuration parameters" section below) but
+doing so is pointless because you can't control when the remote SMTP client
+times out.
 
 CCoonnffiigguurraattiioonn ppaarraammeetteerrss
 

postfix/README_FILES/SMTPUTF8_README

@@ -173,7 +173,7 @@ This section applies only to systems that have SMTPUTF8 support turned on
 
 For compatibility with pre-SMTPUTF8 environments, Postfix does not
 automatically set the "SMTPUTF8 requested" flag on messages from non-SMTPUTF8
-clients that contain an UTF-8 header value or UTF-8 address localpart. This
+clients that contain a UTF-8 header value or UTF-8 address localpart. This
 would make such messages undeliverable to non-SMTPUTF8 servers, and could be a
 barrier to SMTPUTF8 adoption.
 
@@ -253,12 +253,21 @@ localparts (and in headers) as before. The vast majority of email software is
 perfectly capable of handling such email, even if pre-SMTPUTF8 standards do not
 support such practice.
 
-However, when you specify "smtputf8_enable = yes", Postfix requires that non-
-ASCII address information is encoded in UTF-8 and will reject other encodings
-such as ISO-8859. It is not practical for Postfix to support multiple encodings
-at the same time. There is no problem with RFC 2047 encodings such as "=?ISO-
-8859-1?Q?text?=", because those use only characters from the ASCII
-characterset.
+RReejjeeccttiinngg nnoonn--UUTTFF88 aaddddrreesssseess
+
+With "smtputf8_enable = yes", Postfix requires that non-ASCII address
+information is encoded in UTF-8 and will reject other encodings such as ISO-
+8859. It is not practical for Postfix to support multiple encodings at the same
+time. There is no problem with RFC 2047 encodings such as "=?ISO-8859-
+1?Q?text?=", because those use only characters from the ASCII characterset.
+
+RReejjeeccttiinngg nnoonn--AASSCCIIII aaddddrreesssseess iinn nnoonn--SSMMTTPPUUTTFF88 ttrraannssaaccttiioonnss
+
+Setting "strict_smtputf8 = yes" in addition to "smtputf8_enable = yes" will
+enable stricter enforcement of the SMTPUTF8 protocol. Specifically, the Postfix
+SMTP server will not only reject non-UTF8 sender or recipient addresses, it
+will in addition accept UTF-8 sender or recipient addresses only when the
+client requests an SMTPUTF8 mail transaction.
 
 CCoommppaattiibbiilliittyy wwiitthh IIDDNNAA22000033
 
@@ -269,8 +278,8 @@ current versions of the Firefox and Chrome web browsers. Specify
 "enable_idna2003_compatibility = yes" to get the historical behavior.
 
 This affects the conversion of domain names that contain for example the German
-sz (ß) and the Greek zeta (ς). See http://unicode.org/cldr/utility/idna.jsp
-for more examples.
+sz (ß) and the Greek (final) sigma (ς). See https://unicode.org/cldr/utility/
+idna.jsp for more examples.
 
 CCrreeddiittss
 

postfix/README_FILES/SOHO_README

@@ -28,7 +28,7 @@ PPoossttffiixx oonn aa ssttaanndd--aalloonnee IInntteer
 
 Postfix should work out of the box without change on a stand-alone machine that
 has direct Internet access. At least, that is how Postfix installs when you
-download the Postfix source code via http://www.postfix.org/.
+download the Postfix source code via https://www.postfix.org/.
 
 You can use the command "ppoossttccoonnff --nn" to find out what settings are overruled
 by your main.cf. Besides a few pathname settings, few parameters should be set
@@ -73,8 +73,8 @@ addresses by valid Internet addresses. This mapping happens ONLY when mail
 leaves the machine; not when you send mail between users on the same machine.
 
 The following example presents additional configuration. You need to combine
-this with basic configuration information as discussed the first half of this
-document.
+this with basic configuration information as discussed in the first half of
+this document.
 
     1 /etc/postfix/main.cf:
     2     smtp_generic_maps = hash:/etc/postfix/generic
@@ -109,8 +109,8 @@ fantasy addresses, including mail to local fantasy addresses that don't have a
 valid Internet address of their own.
 
 The following example presents additional configuration. You need to combine
-this with basic configuration information as discussed the first half of this
-document.
+this with basic configuration information as discussed in the first half of
+this document.
 
      1 /etc/postfix/main.cf:
      2     myhostname = hostname.localdomain
@@ -200,9 +200,9 @@ username/password information.
     standard "AUTH=mmeetthhoodd....." syntax in response to the EHLO command; this
     requires no additional Postfix client configuration.
 
-  * The Postfix SMTP client does not support the obsolete "wrappermode"
-    protocol, which uses TCP port 465 on the SMTP server. See TLS_README for a
-    solution that uses the stunnel command.
+  * With the setting "smtp_tls_wrappermode = yes", the Postfix SMTP client
+    supports the "wrappermode" protocol, which uses TCP port 465 on the SMTP
+    server (Postfix 3.0 and later).
 
   * With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP
     client to send username and password information to the mail gateway
@@ -276,13 +276,13 @@ final resort.
     single MySQL database, and configure different Postfix queries to extract
     the appropriate information.
 
-  * Specify dbm instead of hash if your system uses dbm files instead of db
+  * Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
     files. To find out what lookup tables Postfix supports, use the command
-    "postconf -m".
+    "ppoossttccoonnff --mm".
 
-  * Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change
+  * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change
     the sasl_passwd table.
 
-  * Execute the command "postmap /etc/postfix/sender_relay" whenever you change
+  * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//sseennddeerr__rreellaayy" whenever you change
     the sender_relay table.
 

postfix/README_FILES/SQLITE_README

@@ -14,7 +14,7 @@ BBuuiillddiinngg PPoossttffiixx wwiitthh SSQQLLiittee s
 The Postfix SQLite client utilizes the sqlite3 library, which can be obtained
 from:
 
-    http://www.sqlite.org/
+    https://www.sqlite.org/
 
 In order to build Postfix with sqlite map support, you will need to add to
 CCARGS the flags -DHAS_SQLITE and -I with the directory containing the sqlite
@@ -23,8 +23,11 @@ sqlite3 library, plus the name of the standard POSIX thread library (pthread).
 For example:
 
     make -f Makefile.init makefiles \
-         'CCARGS=-DHAS_SQLITE -I/usr/local/include' \
-         'AUXLIBS_SQLITE=-L/usr/local/lib -lsqlite3 -lpthread'
+         "CCARGS=-DHAS_SQLITE -I/usr/local/include" \
+         "AUXLIBS_SQLITE=-L/usr/local/lib -lsqlite3 -lpthread"
+
+If your SQLite shared library is in a directory that the RUN-TIME linker does
+not know about, add a "-Wl,-R,/path/to/directory" option after "-lsqlite3".
 
 Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_SQLITE. With Postfix
 3.0 and later, the old AUXLIBS variable still supports building a statically-
@@ -62,12 +65,6 @@ dbpath = /some/path/to/sqlite_database
 # See sqlite_table(5) for details.
 query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
 
-AAddddiittiioonnaall nnootteess
-
-The SQLite configuration interface setup allows for multiple sqlite databases:
-you can use one for a virtual table, one for an access table, and one for an
-aliases table if you want.
-
 CCrreeddiittss
 
 SQLite support was added with Postfix version 2.8.

postfix/README_FILES/STANDARD_CONFIGURATION_README

@@ -31,7 +31,7 @@ PPoossttffiixx oonn aa ssttaanndd--aalloonnee IInntteer
 
 Postfix should work out of the box without change on a stand-alone machine that
 has direct Internet access. At least, that is how Postfix installs when you
-download the Postfix source code via http://www.postfix.org/.
+download the Postfix source code via https://www.postfix.org/.
 
 You can use the command "ppoossttccoonnff --nn" to find out what settings are overruled
 by your main.cf. Besides a few pathname settings, few parameters should be set
@@ -113,7 +113,7 @@ As usual, the examples show only parameters that are not left at their default
 settings.
 
 First we present the non-mailhost configuration, because it is the simpler one.
-This machine sends mail as "user@example.com" and is final destination for
+This machine sends mail as "user@example.com" and is the final destination for
 "user@hostname.example.com".
 
     1 /etc/postfix/main.cf:
@@ -135,8 +135,8 @@ Translation:
     below, "Postfix behind a firewall".
 
 Next we present the mailhost configuration. This machine sends mail as
-"user@example.com" and is final destination for "user@hostname.example.com" as
-well as "user@example.com".
+"user@example.com" and is the final destination for "user@hostname.example.com"
+as well as "user@example.com".
 
      1 DNS:
      2     example.com    IN    MX  10 mailhost.example.com.
@@ -238,7 +238,7 @@ Translation:
     literals matching $inet_interfaces or $proxy_interfaces are deemed local.
     So "localpart@[a.d.d.r]" can be matched as simply "localpart" in canonical
     (5) and virtual(5). This avoids the need to specify firewall IP addresses
-    into Postfix configuration files.
+    in Postfix configuration files.
 
 The last part of the solution does the email forwarding, which is the real
 purpose of the firewall email function.
@@ -270,7 +270,7 @@ purpose of the firewall email function.
     17      . . .
     18
     19 /etc/postfix/transport:
-    20     example.com   smtp:[inside-gateway.example.com]
+    20     example.com   relay:[inside-gateway.example.com]
 
 Translation:
 
@@ -286,7 +286,12 @@ Translation:
     "@example.com x" wild-card in the relay_recipients table.
 
   * Lines 12, 19-20: Route mail for "example.com" to the inside gateway
-    machine. The [] forces Postfix to do no MX lookup.
+    machine. The [] forces Postfix to do no MX lookup. This uses the "relay"
+    delivery transport (a copy of the default "smtp" delivery transport) to
+    forward inbound mail. This can improve performance of deliveries to
+    internal domains because they will compete for SMTP clients from the
+    "relay" delivery transport, instead of competing with other SMTP deliveries
+    for SMTP clients from the default "smtp" delivery transport.
 
 Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
 To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
@@ -301,9 +306,8 @@ In some installations, there may be separate instances of Postfix processing
 inbound and outbound mail on a multi-homed firewall. The inbound Postfix
 instance has an SMTP server listening on the external firewall interface, and
 the outbound Postfix instance has an SMTP server listening on the internal
-interface. In such a configuration is it is tempting to configure
-$inet_interfaces in each instance with just the corresponding interface
-address.
+interface. In such a configuration it is tempting to configure $inet_interfaces
+in each instance with just the corresponding interface address.
 
 In most cases, using inet_interfaces in this way will not work, because as
 documented in the $inet_interfaces reference manual, the smtp(8) delivery agent
@@ -348,8 +352,8 @@ Note: this example requires Postfix version 2.0 and later. To find out what
 Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
 
 The following example presents additional configuration. You need to combine
-this with basic configuration information as discussed the first half of this
-document.
+this with basic configuration information as discussed in the first half of
+this document.
 
      1 /etc/postfix/main.cf:
      2     transport_maps = hash:/etc/postfix/transport
@@ -386,7 +390,8 @@ transport table.
 CCoonnffiigguurriinngg PPoossttffiixx aass pprriimmaarryy oorr bbaacckkuupp MMXX hhoosstt ffoorr aa rreemmoottee ssiittee
 
 This section presents additional configuration. You need to combine this with
-basic configuration information as discussed the first half of this document.
+basic configuration information as discussed in the first half of this
+document.
 
 When your system is SECONDARY MX host for a remote site this is all you need:
 
@@ -472,7 +477,8 @@ This section applies to dialup connections that are down most of the time. For
 dialup connections that are up 24x7, see the local area network section above.
 
 This section presents additional configuration. You need to combine this with
-basic configuration information as discussed the first half of this document.
+basic configuration information as discussed in the first half of this
+document.
 
 If you do not have your own hostname and IP address (usually with dialup, cable
 TV or DSL connections) then you should also study the section on "Postfix on
@@ -553,8 +559,8 @@ addresses by valid Internet addresses. This mapping happens ONLY when mail
 leaves the machine; not when you send mail between users on the same machine.
 
 The following example presents additional configuration. You need to combine
-this with basic configuration information as discussed the first half of this
-document.
+this with basic configuration information as discussed in the first half of
+this document.
 
     1 /etc/postfix/main.cf:
     2     smtp_generic_maps = hash:/etc/postfix/generic
@@ -589,8 +595,8 @@ fantasy addresses, including mail to local fantasy addresses that don't have a
 valid Internet address of their own.
 
 The following example presents additional configuration. You need to combine
-this with basic configuration information as discussed the first half of this
-document.
+this with basic configuration information as discussed in the first half of
+this document.
 
      1 /etc/postfix/main.cf:
      2     myhostname = hostname.localdomain

postfix/README_FILES/STRESS_README

@@ -66,7 +66,7 @@ Symptoms of Postfix SMTP server overload are:
      condition, increase the process count in master.cf or reduce the
      service time per client
     Oct  3 20:39:27 spike postfix/master[28905]: warning: see
-      http://www.postfix.org/STRESS_README.html for examples of
+      https://www.postfix.org/STRESS_README.html for examples of
       stress-adapting configuration settings
 
 Legitimate mail that doesn't get through during an episode of Postfix SMTP
@@ -259,7 +259,7 @@ to Postfix.
     maps. The Postfix SMTP server will reject mail and disconnect without
     waiting for the remote SMTP client to send a QUIT command.
 
-  * To hang up connections from blacklisted zombies, you can set specific
+  * To hang up connections from denylisted zombies, you can set specific
     Postfix SMTP server reject codes for specific RBLs, and for individual
     responses from specific RBLs. We'll use zen.spamhaus.org as an example; by
     the time you read this document, details may have changed. Right now, their
@@ -299,7 +299,7 @@ to Postfix.
 
   * You can automatically turn on the above overload measure with Postfix 2.5
     and later, or with earlier releases that contain the stress-adaptive
-    behavior source code patch from the mirrors listed at http://
+    behavior source code patch from the mirrors listed at https://
     www.postfix.org/download.html. Simply replace line above 8 with:
 
      8      rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
@@ -311,7 +311,7 @@ TTeemmppoorraarryy mmeeaassuurreess ffoorr oollddeerr P
 
 See the section "Automatic stress-adaptive behavior" if you are running Postfix
 version 2.5 or later, or if you have applied the source code patch for stress-
-adaptive behavior from the mirrors listed at http://www.postfix.org/
+adaptive behavior from the mirrors listed at https://www.postfix.org/
 download.html.
 
 The following measures can be applied temporarily during overload. They still
@@ -410,7 +410,7 @@ OOtthheerr mmeeaassuurreess ttoo ooffff--llooaadd zzoom
 
 The postscreen(8) daemon, introduced with Postfix 2.8, provides additional
 protection against mail server overload. One postscreen(8) process handles
-multiple inbound SMTP connections, and decides which clients may to talk to a
+multiple inbound SMTP connections, and decides which clients may talk to a
 Postfix SMTP server process. By keeping spambots away, postscreen(8) leaves
 more SMTP server processes available for legitimate clients, and delays the
 onset of server overload conditions.

postfix/README_FILES/TLSRPT_README

@@ -0,0 +1,365 @@
+PPoossttffiixx TTLLSSRRPPTT HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+TTaabbllee ooff CCoonntteennttss
+
+  * Introduction
+  * Building Postfix with TLSRPT support
+  * Turning on TLSRPT
+  * Connection reuse versus session resumption
+  * TLSRPT Status logging
+  * Delivering TLSRPT summaries via email
+  * MTA-STS Support via smtp_tls_policy_maps
+  * Limitations
+  * Credits
+
+IInnttrroodduuccttiioonn
+
+The TLSRPT protocol is defined in RFC 8460. With this, an email receiving
+domain can publish a policy in DNS, and request daily summary reports for
+successful and failed SMTP over TLS connections to that domain's MX hosts.
+Support for TLSRPT was added in Postfix 3.10.
+
+A policy for domain example.com could look like this:
+
+    _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:smtp-tls-
+    report@example.com"
+
+Instead of mailto:, a policy may specify an https: destination.
+
+The diagram below shows how successful or failed Postfix TLS handshake events
+are collected and processed into daily summary reports.
+
+     Postfix SMTP and      TLSRPT client     TLSRPT collector,    Email or HTTP
+    TLS client engines -> library (linked ->   fetcher, and    ->   delivery
+                           into Postfix)     summary generator
+
+  * The Postfix SMTP and TLS client engines will generate a "success" or
+    "failure" event for each TLS handshake,
+
+  * They will pass those events to an in-process TLSRPT client library that
+    sends data over a local socket to
+
+  * A local TLSRPT collector that runs on each Postfix machine. A TLSRPT
+    fetcher gathers information from individual collectors, and a central
+    TLSRPT report generator produces daily summary reports.
+
+The TLSRPT client library, and the infrastructure to collect, fetch, and report
+TLSRPT information, are implemented and maintained by sys4 at https://
+github.com/sys4/libtlsrpt and https://github.com/sys4/tlsrpt-reporter,
+respectively.
+
+The Postfix implementation supports TLSRPT for domains with DANE (Postfix
+built-in) and MTA-STS (through an smtp_tls_policy_maps plug-in).
+
+The Postfix smtp(8) client process implements the SMTP client engine. With
+"smtp_tls_connection_reuse = no", the smtp(8) client process also implements
+the TLS client engine. With "smtp_tls_connection_reuse = yes", the smtp(8)
+client process delegates TLS processing to a Postfix tlsproxy(8) process.
+Either way, Postfix will generate the exact same TLSRPT events.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh TTLLSSRRPPTT ssuuppppoorrtt
+
+These instructions assume that you build Postfix from source code as described
+in the INSTALL document. Some modification may be required if you build Postfix
+from a vendor-specific source package.
+
+The Postfix TLSRPT client builds on a TLSRPT library which may be available as
+a built package (rpm, deb, etc.), or which you can build from source code from:
+
+    https://github.com/sys4/libtlsrpt
+
+The library is typically installed as a header file in /usr/local/include/
+tlsrpt.h and an object library in /usr/local/lib/libtlsrpt.a or /usr/local/lib/
+libtlsrpt.so. The actual pathnames will depend on OS platform conventions.
+
+In order to build Postfix with TLSRPT support, you will need to add compiler
+options -DUSE_TLSRPT (to build with TLSRPT support) and -I (with the directory
+containing the tlsrpt.h header file), and you will need to add linker options
+to link with the TLSRPT client library, for example:
+
+    make -f Makefile.init makefiles \
+      "CCARGS=-DUSE_TLSRPT -I/usr/local/include" \
+      "AUXLIBS=-L/usr/local/lib -Wl,-rpath,/usr/local/lib -ltlsrpt"
+
+(On Solaris systems you may need to use "-Wl,-R" instead of "-Wl,-rpath".)
+
+Then, just run 'make'.
+
+    Note: if your build command line already has CCARGS or AUXLIBS settings,
+    then simply append the above settings to the existing CCARGS or AUXLIBS
+    values:
+
+    make -f Makefile.init makefiles \
+      "CCARGS=... -DUSE_TLSRPT -I/usr/local/include" \
+      "AUXLIBS=... -L/usr/local/lib -Wl,-rpath,/usr/local/lib -ltlsrpt"
+
+TTuurrnniinngg oonn TTLLSSRRPPTT
+
+After installing Postfix TLSRPT support, you can enable TLSRPT support in
+main.cf like this:
+
+    smtp_tlsrpt_enable = yes
+    smtp_tlsrpt_socket_name = path/to/socket
+
+The smtp_tlsrpt_socket_name parameter specifies either an absolute pathname, or
+a pathname that is relative to $queue_directory.
+
+Notes:
+
+  * The recommended socket location is still to be determined. A good socket
+    location would be under the Postfix queue directory, for example:
+    "smtp_tlsrpt_socket_name = run/tlsrpt/tlsrpt.sock". The advantage of using
+    a relative name is that it will work equally well whether or not Postfix
+    chroot is turned on.
+
+  * Regardless of whether Postfix chroot is enabled, the TLSRPT receiver
+    (tlsrpt_collectd) will need to be configured with the socket's absolute
+    pathname.
+
+  * Do not specify a TLSRPT socket location under a Postfix socket directory
+    such as private or public. Only Postfix programs should create sockets
+    there.
+
+For details on how to run the TLSRPT collection and reporting infrastructure,
+see the documentation at https://github.com/sys4/tlsrpt-reporter.
+
+CCoonnnneeccttiioonn rreeuussee vveerrssuuss sseessssiioonn rreessuummppttiioonn
+
+The Postfix SMTP client implements two kinds of reuse:
+
+  * SSMMTTPP CCoonnnneeccttiioonn rreeuussee:: a Postfix SMTP client creates a new SMTP connection,
+    sends one email message, and saves the connection instead of closing it.
+    Later, some SMTP client reuses that connection, sends an email message, and
+    saves or closes the connection depending on whether it has reached some
+    reuse limit. Each connection can be used by only one Postfix SMTP client at
+    a time.
+
+  * TTLLSS SSeessssiioonn rreessuummppttiioonn:: a Postfix SMTP client saves the result from a "new"
+    TLS handshake. Later, one or more SMTP clients create a new SMTP connection
+    and resume the saved TLS session on their new connection.
+
+Of course there is a third case:
+
+  * CCoommbbiinneedd rreeuussee aanndd rreessuummppttiioonn:: a Postfix SMTP client creates a new SMTP
+    connection, sends one email message, saves the result from a "new" TLS
+    handshake, and also saves the connection instead of closing it. Later, one
+    SMTP client reuses (and saves) that connection, one client at a time, and
+    one or more clients create a new SMTP connection and resume the saved TLS
+    session on their new connection.
+
+In all cases, there is no TLS handshake when a saved SMTP connection is reused,
+and there is no "new" TLS handshake when a saved TLS session is resumed.
+
+As described next, Postfix will by default log and generate only a TLSRPT event
+for a "new" TLS handshake.
+
+TTLLSSRRPPTT SSttaattuuss llooggggiinngg
+
+With TLSRPT support turned on, the Postfix TLSRPT client will not only report
+an event to an invisible daily success/fail summary queue, but it will also log
+a visible record to the mail logfile.
+
+Below are a few examples of logging from a Postfix SMTP client or tlsproxy
+daemon:
+
+    TLSRPT: status=success, domain=example.com, receiving_mx=mail.example.com
+    [ipaddr]
+
+    TLSRPT: status=failure, domain=example.org, receiving_mx=mail.example.org
+    [ipaddr],
+        failure_type=starttls_not_supported
+
+    TLSRPT: status=failure, domain=example.net, receiving_mx=mail.example.net
+    [ipaddr],
+        failure_type=validation_failure, failure_reason=self-signed_certificate
+
+Notes:
+
+  * Postfix logs and reports the TLSRPT status only for TLS handshakes on a new
+    SMTP connection. There is no TLS handshake, and thus no TLSRPT status
+    logging, when an SMTP connection is reused. Such connections have Postfix
+    SMTP client logging like this:
+
+    Verified TTLLSS ccoonnnneeccttiioonn rreeuusseedd to mail.example.com[ipaddr]:25:
+        TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
+
+    Untrusted TTLLSS ccoonnnneeccttiioonn rreeuusseedd to mail.example.com[ipaddr]:25:
+        TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
+
+  * With TLSRPT enabled, the Postfix SMTP client reports the TLSRPT status for
+    all TLS handshakes (the default as of Postfix 3.11). Specify
+    "smtp_tlsrpt_skip_reused_handshakes = yes" (the default with Postfix 3.10)
+    to skip reporting TLS handshakes that reuse a previously-negotiated TLS
+    session as there would be no new information to report.
+
+  * Postfix logging for certificate verification failures may differ between
+    new or reused TLS sessions.
+
+      o New TLS session:
+
+        TLSRPT: status=failure, domain=example.org,
+        receiving_mx=mail.example.org[ipaddr],
+            ffaaiilluurree__ttyyppee==vvaalliiddaattiioonn__ffaaiilluurree, ffaaiilluurree__rreeaassoonn==sseellff--
+        ssiiggnneedd__cceerrttiiffiiccaattee
+
+      o Reused TLS session:
+
+        mail.example.org[ipaddr]:25: rree--uussiinngg sseessssiioonn with untrusted peer
+            credential, look for details earlier in the log
+        TLSRPT: status=failure, domain=example.org,
+        receiving_mx=mail.example.org[ipaddr],
+            ffaaiilluurree__ttyyppee==cceerrttiiffiiccaattee__nnoott__ttrruusstteedd
+
+    The logging may differ because a reused TLS session does not have the
+    details for why TLS authentication failed.
+
+DDeelliivveerriinngg TTLLSSRRPPTT ssuummmmaarriieess vviiaa eemmaaiill
+
+RFC 8460 Section 3 specifies that an MTA must not enforce TLS security when
+sending failure reports via email.
+
+Options:
+
+  * In an email report, specify the "TTLLSS--RReeqquuiirreedd:: nnoo" message header, defined
+    in RFC 8689, to reduce the Postfix SMTP client TLS security level to "mmaayy"
+    (that is, do not verify remote SMTP server certificates, and fall back to
+    plaintext if TLS is unavailable).
+
+    This feature is available in Postfix 3.10 and later. If your outbound MTAs
+    run an older version, you can use one of the options described below.
+
+  * Do nothing. When TLS security enforcement is required but fails, a TLSRPT
+    summary message will be delayed until the problem is addressed, or until
+    the message expires in the mail queue. Keep in mind that TLSRPT is not a
+    real-time monitoring service; it takes on average 12 hours before a failure
+    is reported through TLSRPT.
+
+  * On outbound MTAs that don't support the "TTLLSS--RReeqquuiirreedd:: nnoo" header feature
+    (such as Postfix 3.9 and earlier), disable TLS security enforcement for the
+    sender of TLSRPT summaries. Implement the configuration below on outbound
+    MTA instances (replace noreply-smtp-tls-reporting@example.com with your
+    actual report generator's sender address):
+
+    /etc/postfix/main.cf:
+        # Limitation: this setting is overruled with transport_maps.
+        sender_dependent_default_transport_maps = inline:{
+            { noreply-smtp-tls-reporting@example.com = allow-plaintext } }
+
+    /etc/postfix/master.cf:
+        # service name    type    private unpriv  chroot  wakeup  maxproc
+    command
+        allow-plaintext   unix    -       -       -       -       -       smtp
+            -o { smtp_tls_security_level = may }
+            -o { smtp_tls_policy_maps = static:may }
+
+MMTTAA--SSTTSS SSuuppppoorrtt vviiaa ssmmttpp__ttllss__ppoolliiccyy__mmaappss
+
+Postfix supports MTA-STS through an smtp_tls_policy_maps policy plugin, which
+replies with a TLS security level and name=value attributes with certificate
+matching requirements. Postfix 3.10 and later extend the policy plugin response
+with additional name=value attributes that are needed for TLSRPT.
+
+Examples of smtp_tls_policy_maps plugins with MTA-STS support are:
+
+  * postfix-tlspol, supports domains with DANE (using Postfix built-in DANE),
+    and domains with MTA-STS.
+
+  * postfix-mta-sts-resolver, supports domains with MTA-STS as of release 1.5.0
+    (February 2025).
+
+Both plugins can generate the additional name=value attributes that Postfix
+needs for TLSRPT support (as of February 2025). This is enabled by setting a
+tlsrpt boolean in a plugin configuration file. This setting is safe with
+Postfix 3.10 and later, even if Postfix TLSRPT support is disabled (at build
+time or at run time). Postfix versions 3.9 and earlier will report a policy
+error with "invalid attribute name".
+
+The examples in the text below apply to this MTA-STS policy example given in
+RFC 8461 Section 3.2:
+
+    version: STSv1
+    mode: enforce
+    mx: mail.example.com
+    mx: *.example.net
+    mx: backupmx.example.com
+    max_age: 604800
+
+The list of supported attributes is given below. Instead of name=value, specify
+{ name = value } when a value may contain whitespace. A policy response may
+contain line breaks.
+
+  * policy_type=type
+
+    Specify sts or no-policy-found.
+
+    Example: policy_type=sts
+
+  * policy_domain=name
+
+    The domain that the MTA-STS policy applies to.
+
+    Example: policy_domain=example.com
+
+  * { policy_string = value }
+
+    Specify one policy_string instance for each MTA-STS policy feature,
+    enclosed inside "{" and "}" to protect whitespace in attribute values.
+
+    Example: { policy_string = version: STSv1 } { policy_string = mode: enforce
+    } ...
+
+    The above form ignores whitespace after the opening "{", around the "=",
+    and before the closing "}".
+
+  * mx_host_pattern=pattern
+
+    Specify one mx_host_pattern instance for each "mx:" feature in the MTA-STS
+    policy.
+
+    Example: mx_host_pattern=mail.example.com mx_host_pattern=*.example.net ...
+
+  * policy_failure=type
+
+    If specified, forces MTA-STS policy enforcement to fail with the indicated
+    error, even if a server certificate would satisfy conventional PKI
+    constraints. Valid errors are sts-policy-fetch-error, sts-policy-invalid,
+    sts-webpki-invalid, or the less informative validation-failure.
+
+    Example: policy_failure=sts-webpki-invalid
+
+  * policy_ttl=time (deprecated)
+
+    This attribute is deprecated. The time value is not used, and support for
+    this attribute will eventually be removed from the code.
+
+Notes:
+
+  * Postfix 3.10 and later will accept these additional attributes in an MTA-
+    STS response even if Postfix TLSRPT support is disabled (at build time or
+    at run time). With Postfix TLSRPT support turned off, Postfix may still use
+    the policy_failure attribute, and will ignore the attributes that are used
+    only for TLSRPT.
+
+  * It is an error to specify these attributes for a non-STS policy.
+
+LLiimmiittaattiioonnss
+
+The Postfix TLSRPT implementation reports only TLS handshake success or
+failure. It does not report failure to connect, or connections that break
+before or after a TLS handshake.
+
+The Postfix TLSRPT implementation reports at most one final TLS handshake
+status (either 'success' or 'failure') per SMTP connection. Postfix TLSRPT will
+not report a recoverable failure and then later report a final status of
+'success' for that same connection. The reason is that it's too complicated to
+filter TLS errors and to report error details from the TLS engine back to the
+SMTP protocol engine. It just is not how Postfix works internally.
+
+CCrreeddiittss
+
+  * The TLSRPT client library, and the infrastructure to collect, fetch, and
+    report TLSRPT information, are implemented and maintained by sys4.
+  * Wietse Venema implemented the integration with Postfix.
+

postfix/README_FILES/TLS_LEGACY_README

@@ -5,7 +5,7 @@ PPoossttffiixx lleeggaaccyy TTLLSS SSuuppppoorrtt
 NNOOTTEE
 
 This document describes an old TLS user interface that is based on a third-
-party TLS patch by Lutz Jänicke. As of Postfix version 2.3, the old user
+party TLS patch by Lutz Ja"nicke. As of Postfix version 2.3, the old user
 interface still exists to allow migration from earlier Postfix releases, but
 its functionality is frozen.
 
@@ -51,7 +51,7 @@ programs. Other colored boxes represent storage elements.
 
                     <---seed---              ---seed--->
 Network-> smtpd(8)                tlsmgr(8)                 smtp(8)  ->Network
-                    <-session->              <-session->        
+                    <-session->              <-session->
 
                                 /       |    \
                                         |
@@ -126,7 +126,7 @@ SSeerrvveerr--ssiiddee cceerrttiiffiiccaattee aanndd p
 
 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
+meaning: the key must be accessible without a 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
@@ -147,7 +147,7 @@ with:
 
     % ccaatt sseerrvveerr__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> sseerrvveerr..ppeemm
 
-A Postfix SMTP server certificate supplied here must be usable as SSL server
+A Postfix SMTP server certificate supplied here must be usable as an 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,
@@ -410,8 +410,8 @@ server access control:
 
 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
+CA issues the client certificates, and only if this CA is listed as a 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.
 
@@ -447,9 +447,9 @@ Example:
 SSeerrvveerr--ssiiddee cciipphheerr ccoonnttrroollss
 
 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!
+cipherlist string. A detailed description would go too 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!!!
 
@@ -520,8 +520,8 @@ 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.
+accessible without a 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
@@ -534,7 +534,7 @@ with:
 
     % ccaatt cclliieenntt__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> cclliieenntt..ppeemm
 
-A Postfix SMTP client certificate supplied here must be usable as SSL client
+A Postfix SMTP client certificate supplied here must be usable as an 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,
@@ -780,9 +780,9 @@ summarized as follows:
     "smtp_use_tls = yes".
 
   * When both hostname and next-hop destination lookups produce a result, the
-    more specific per-site policy (NONE, MUST, etc) overrides the less specific
-    one (MAY), and the more secure per-site policy (MUST, etc) overrides the
-    less secure one (NONE).
+    more specific per-site policy (NONE, MUST, etc.) overrides the less
+    specific one (MAY), and the more secure per-site policy (MUST, etc.)
+    overrides the less secure one (NONE).
 
   * After the per-site policy lookups are combined, the result generally
     overrides the global policy. The exception is the less specific MMAAYY per-
@@ -827,7 +827,7 @@ Example:
         example.org                 NONE
 
         # TLS should not be used with the host smtp.example.com.
-        smtp.example.com             NONE
+        [smtp.example.com]          NONE
 
 DDiissccoovveerriinngg sseerrvveerrss tthhaatt ssuuppppoorrtt TTLLSS
 
@@ -862,9 +862,9 @@ Example:
 CClliieenntt--ssiiddee cciipphheerr ccoonnttrroollss
 
 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!
+cipherlist string. A detailed description would go too 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!!!
 
@@ -1071,10 +1071,10 @@ Please differentiate when possible between:
   * Problems in the TLS code: <postfix_tls@aet.tu-cottbus.de>
   * Problems in vanilla Postfix: <postfix-users@postfix.org>
 
-CCoommppaattiibbiilliittyy wwiitthh PPoossttffiixx <<22..22 TTLLSS ssuuppppoorrtt
+CCoommppaattiibbiilliittyy wwiitthh PPoossttffiixx << 22..22 TTLLSS ssuuppppoorrtt
 
 Postfix version 2.2 TLS support is based on the Postfix/TLS patch by Lutz
-Jänicke, but differs in a few minor ways.
+Ja"nicke, but differs in a few minor ways.
 
   * main.cf: Specify "btree" instead of "sdbm" for TLS session cache databases.
 
@@ -1109,8 +1109,8 @@ support cycle.
 
 CCrreeddiittss
 
-  * TLS support for Postfix was originally developed by Lutz Jänicke at Cottbus
-    Technical University.
+  * TLS support for Postfix was originally developed by Lutz Ja"nicke at
+    Cottbus Technical University.
   * Wietse Venema adopted the code, did some restructuring, and compiled this
     part of the documentation from Lutz's documents.
   * Victor Duchovni was instrumental with the re-implementation of the

postfix/README_FILES/TLS_README

@@ -12,7 +12,7 @@ NOTE: By turning on TLS support in Postfix, you not only get the ability to
 encrypt mail and to authenticate remote SMTP clients or servers. You also turn
 on hundreds of 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.
+introduces one additional bug into Postfix.
 
 Topics covered in this document:
 
@@ -91,15 +91,21 @@ require a server certificate.
 
 For servers that are nnoott public Internet MX hosts, Postfix supports
 configurations with no certificates. This entails the use of just the anonymous
-TLS ciphers, which are not supported by typical SMTP clients. Since such
-clients will not, as a rule, fall back to plain text after a TLS handshake
-failure, a certificate-less Postfix SMTP server will be unable to receive email
-from most TLS enabled clients. To avoid accidental configurations with no
-certificates, Postfix enables certificate-less operation only when the
-administrator explicitly sets "smtpd_tls_cert_file = none". This ensures that
-new Postfix SMTP server configurations will not accidentally run with no
+TLS ciphers, which are not supported by typical SMTP clients. Since some
+clients may not fall back to plain text after a TLS handshake failure, a
+certificate-less Postfix SMTP server will be unable to receive email from some
+TLS-enabled clients. To avoid accidental configurations with no certificates,
+Postfix enables certificate-less operation only when the administrator
+explicitly sets "smtpd_tls_cert_file = none". This ensures that new Postfix
+SMTP server configurations will not accidentally enable TLS without
 certificates.
 
+Note that server certificates are nnoott optional in TLS 1.3. To run without
+certificates you'd have to disable the TLS 1.3 protocol by including
+"<=TLSv1.2" (or, for Postfix < 3.6, "!TLSv1.3") in "smtpd_tls_protocols" and
+perhaps also "smtpd_tls_mandatory_protocols". It is simpler instead to just
+configure a certificate chain. Certificate-less operation is not recommended.
+
 RSA, DSA and ECDSA (Postfix >= 2.6) certificates are supported. Most sites only
 have RSA certificates. You can configure all three at the same time, in which
 case the ciphersuite negotiated with the remote SMTP client determines which
@@ -115,7 +121,7 @@ To verify the Postfix SMTP server certificate, the remote SMTP client must
 receive the issuing CA certificates via the TLS handshake or via public-key
 infrastructure. This means that the Postfix server public-key certificate file
 must include the server certificate first, then the issuing CA(s) (bottom-up
-order). The Postfix SMTP server certificate must be usable as SSL server
+order). The Postfix SMTP server certificate must be usable as an SSL server
 certificate and hence pass the "openssl verify -purpose sslserver ..." test.
 
 The examples that follow show how to create a server certificate file. We
@@ -143,11 +149,9 @@ assume that the certificate for "server.example.com" was issued by
     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.
+    As a best practice, publish "3 1 1" TLSA associations that specify the
+    SHA256 digest of the server's public key. These continue to work unmodified
+    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
@@ -168,6 +172,48 @@ $smtpd_tls_CAfile or install it in the $smtpd_tls_CApath directory.
 
 CCoonnffiigguurriinngg tthhee sseerrvveerr cceerrttiiffiiccaattee aanndd kkeeyy ffiilleess
 
+Example: Postfix >= 3.4 all-in-one chain file(s). One or more chain files that
+start with a key that is immediately followed by the corresponding certificate
+and any additional issuer certificates. A single file can hold multiple (key,
+cert, [chain]) sequences, one per algorithm. It is typically simpler to keep
+the chain for each algorithm in its own file. Most users are likely to deploy
+just a single RSA chain, but with OpenSSL 1.1.1, it is possible to deploy up to
+five chains, one each for RSA, ECDSA, ED25519, ED448, and even the obsolete
+DSA.
+
+        # Postfix >= 3.4.  Preferred configuration interface.  Each file
+        # starts with the private key, followed by the corresponding
+        # certificate, and any intermediate issuer certificates. The root CA
+        # cert may also be needed when published as a DANE trust anchor.
+        #
+        smtpd_tls_chain_files =
+            /etc/postfix/rsa.pem,
+            /etc/postfix/ecdsa.pem,
+            /etc/postfix/ed25519.pem,
+            /etc/postfix/ed448.pem
+
+You can also store the keys separately from their certificates, again provided
+each is listed before the corresponding certificate chain. Storing a key and
+its associated certificate chain in separate files is not recommended, because
+this is prone to race conditions during key rollover, as there is no way to
+update multiple files atomically.
+
+        # Postfix >= 3.4.
+        # Storing keys separately from the associated certificates is not
+        # recommended.
+        smtpd_tls_chain_files =
+            /etc/postfix/rsakey.pem,
+            /etc/postfix/rsacerts.pem,
+            /etc/postfix/ecdsakey.pem,
+            /etc/postfix/ecdsacerts.pem
+
+The below examples show the legacy algorithm-specific configurations for
+Postfix 3.3 and older. With Postfix <= 3.3, even if the key is stored in the
+same file as the certificate, the file is read twice and a (brief) race
+condition still exists during key rollover. While Postfix >= 3.4 avoids the
+race when the key and certificate are in the same file, you should use the new
+"smtpd_tls_chain_files" interface shown above.
+
 RSA key and certificate examples:
 
     /etc/postfix/main.cf:
@@ -183,8 +229,8 @@ Their DSA counterparts:
 Their ECDSA counterparts (Postfix >= 2.6 + OpenSSL >= 1.0.0):
 
     /etc/postfix/main.cf:
-        # Most clients will not be ECDSA capable, so you will likely also need
-        # an RSA or DSA certificate and private key.
+        # Some clients will not be ECDSA capable, so you will likely still need
+        # an RSA certificate and private key.
         #
         smtpd_tls_eccert_file = /etc/postfix/server-ecdsa.pem
         smtpd_tls_eckey_file = $smtpd_tls_eccert_file
@@ -193,6 +239,8 @@ TLS without certificates for servers serving exclusively anonymous-cipher
 capable clients:
 
     /etc/postfix/main.cf:
+        # Not recommended: breaks TLS 1.3 and clients that don't support
+        # anonymous cipher suites.
         smtpd_tls_cert_file = none
 
 To verify a remote SMTP client certificate, the Postfix SMTP server needs to
@@ -317,21 +365,22 @@ Example:
     /etc/postfix/main.cf:
         smtpd_tls_security_level = encrypt
 
-TLS is sometimes used in the non-standard "wrapper" mode where a server always
-uses TLS, instead of announcing STARTTLS support and waiting for remote SMTP
-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).
+TLS is also used in the "wrapper" mode where a server always uses TLS, instead
+of announcing STARTTLS support and waiting for remote SMTP 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" (note: no space around the "=") as an smtpd(8)
-command line option. Port 465 (smtps) was once chosen for this feature.
+command line option. Port 465 (submissions, formerly called smtps) is the most
+common example.
 
 Example:
 
     /etc/postfix/master.cf:
-        smtps    inet  n       -       n       -       -       smtpd
+        submissions inet  n       -       n       -       -       smtpd
           -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
 
 CClliieenntt cceerrttiiffiiccaattee vveerriiffiiccaattiioonn
@@ -498,12 +547,17 @@ server access control:
 
 The digest algorithm used to compute the client certificate fingerprints is
 specified with the main.cf smtpd_tls_fingerprint_digest parameter. The default
-is "md5", for compatibility with Postfix versions < 2.5.
+algorithm is sshhaa225566 with Postfix >= 3.6 and the ccoommppaattiibbiilliittyy__lleevveell set to 3.6
+or higher. With Postfix <= 3.5, the default algorithm is mmdd55. The best-practice
+algorithm is now sshhaa225566. Recent advances in hash function cryptanalysis have
+led to md5 and sha1 being deprecated in favor of sha256. However, as long as
+there are no known "second pre-image" attacks against the older algorithms,
+their use in this context, though not recommended, is still likely safe.
 
 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
+CA issues the client certificates, and only if this CA is listed as a 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.
 
@@ -549,26 +603,12 @@ command extracts the public key always in "PEM" format. We pipe the result to
 another OpenSSL command that converts the key to DER and then to the "dgst"
 command to compute the fingerprint.
 
-The actual command to transform the key to DER format depends on the version of
-OpenSSL used. With OpenSSL 1.0.0 and later, the "pkey" command supports all key
-types. With OpenSSL 0.9.8 and earlier, the key type is always RSA (nobody uses
-DSA, and EC keys are not fully supported by 0.9.8), so the "rsa" command is
-used.
+Example:
 
-    # OpenSSL 1.0 with all certificates and SHA-1 fingerprints.
     $ openssl x509 -in cert.pem -noout -pubkey |
         openssl pkey -pubin -outform DER |
-        openssl dgst -sha1 -c
-    (stdin)= 64:3f:1f:f6:e5:1e:d4:2a:56:8b:fc:09:1a:61:98:b5:bc:7c:60:58
-
-    # OpenSSL 0.9.8 with RSA certificates and MD5 fingerprints.
-    $ openssl x509 -in cert.pem -noout -pubkey |
-        openssl rsa -pubin -outform DER |
-        openssl dgst -md5 -c
-    (stdin)= f4:62:60:f6:12:8f:d5:8d:28:4d:13:a7:db:b2:ff:50
-
-Note: Postfix 2.9.0-2.9.5 computed the public key fingerprint incorrectly. To
-use public-key fingerprints, upgrade to Postfix 2.9.6 or later.
+        openssl dgst -sha256 -c
+    (stdin)= 64:3f:1f:f6:e5:1e:d4:2a:...:8b:fc:09:1a:61:98:b5:bc:7c:60:58
 
 SSeerrvveerr--ssiiddee cciipphheerr ccoonnttrroollss
 
@@ -594,8 +634,8 @@ With mandatory and opportunistic TLS encryption, the Postfix SMTP server by
 default disables SSLv2 and SSLv3 with Postfix releases after the middle of
 2015; older releases only disable SSLv2 for mandatory TLS. The mandatory TLS
 protocol list is specified via the smtpd_tls_mandatory_protocols configuration
-parameter. The smtpd_tls_protocols parameter (Postfix >= 2.6) controls the SSL/
-TLS protocols used with opportunistic TLS.
+parameter. The smtpd_tls_protocols parameter (Postfix >= 2.6) controls the TLS
+protocols used with opportunistic TLS.
 
 Note that the OpenSSL library only supports protocol exclusion (not inclusion).
 For this reason, Postfix can exclude only protocols that are known at the time
@@ -606,10 +646,12 @@ source code.
 For a server that is not a public Internet MX host, Postfix supports
 configurations with no server certificates that use oonnllyy 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.
+specifying an smtpd_tls_dcert_file or smtpd_tls_eccert_file. Such
+configurations may not interoperate with some clients, and require that TLSv1.3
+be explicitly disabled. Therefore, they are not recommended, it is better and
+simpler to just configure a suitable certificate.
 
-Example, MSA that requires TLSv1 or higher, not SSLv2 or SSLv3, with high grade
-ciphers:
+Example, MSA that requires TLSv1.2 or higher, with high grade ciphers:
 
     /etc/postfix/main.cf:
         smtpd_tls_cert_file = /etc/postfix/cert.pem
@@ -617,10 +659,21 @@ ciphers:
         smtpd_tls_mandatory_ciphers = high
         smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
         smtpd_tls_security_level = encrypt
-        # Preferred syntax with Postfix >= 2.5:
-        smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
+        # Preferred syntax with Postfix >= 3.6:
+        smtpd_tls_mandatory_protocols = >=TLSv1.2
         # Legacy syntax:
-        smtpd_tls_mandatory_protocols = TLSv1
+        smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
+
+With Postfix >= 3.4, specify instead a single file that holds the key followed
+by the corresponding certificate and any associated issuing certificates,
+leaving the "smtpd_tls_cert_file" and "smtpd_tls_key_file" and related DSA and
+ECDSA parameters empty.
+
+    /etc/postfix/main.cf:
+        smtpd_tls_chain_files = /etc/postfix/rsachain.pem
+        smtpd_tls_cert_file =
+        smtpd_tls_key_file =
+        ...
 
 If you want to take maximal advantage of ciphers that offer forward secrecy see
 the Getting started section of FORWARD_SECRECY_README. The full document
@@ -660,11 +713,12 @@ Example:
         smtpd_starttls_timeout = 300s
 
 With Postfix 2.8 and later, the tls_disable_workarounds parameter specifies a
-list or bit-mask of OpenSSL bug work-arounds to disable. This may be necessary
-if one of the work-arounds enabled by default in OpenSSL proves to pose a
-security risk, or introduces an unexpected interoperability issue. Some bug
-work-arounds known to be problematic are disabled in the default value of the
-parameter when linked with an OpenSSL library that could be vulnerable.
+list or bit-mask of default-enabled OpenSSL bug work-arounds to disable. This
+may be necessary if one of the work-arounds enabled by default in OpenSSL
+proves to pose a security risk, or introduces an unexpected interoperability
+issue. The list of enabled bug work-arounds is OpenSSL-release-specific. See
+the tls_disable_workarounds parameter documentation for the list of supported
+values.
 
 Example:
 
@@ -677,16 +731,9 @@ mask of OpenSSL options to enable. Specify one or more of the named options
 below, or a hexadecimal bitmask of options found in the ssl.h file
 corresponding to the run-time OpenSSL library. While it may be reasonable to
 turn off all bug workarounds (see above), it is not a good idea to attempt to
-turn on all features.
+turn on all features. See the tls_ssl_options parameter documentation for the
+list of supported values.
 
-LLEEGGAACCYY__SSEERRVVEERR__CCOONNNNEECCTT
-    See SSL_CTX_set_options(3).
-NNOO__TTIICCKKEETT
-    See SSL_CTX_set_options(3).
-NNOO__CCOOMMPPRREESSSSIIOONN
-    Disable SSL compression even if supported by the OpenSSL library.
-    Compression is CPU-intensive, and compression before encryption does not
-    always improve security.
 Example:
 
     /etc/postfix/main.cf:
@@ -707,13 +754,14 @@ Topics covered in this section:
   * Configuring TLS in the SMTP/LMTP client
   * Client-side TLS activity logging
   * Client-side certificate and private key configuration
+  * Client-side TLS connection reuse
   * Client-side TLS session cache
   * Client TLS limitations
   * Per-destination TLS policy
   * Discovering servers that support TLS
   * Server certificate verification depth
   * Client-side cipher controls
-  * Client-side SMTPS support
+  * Client-side submissions (formerly called smtps) support
   * Miscellaneous client controls
 
 CCoonnffiigguurriinngg TTLLSS iinn tthhee SSMMTTPP//LLMMTTPP cclliieenntt
@@ -831,7 +879,7 @@ interoperability and security guidelines.
 
 Despite the potential for eliminating passive eavesdropping attacks, mandatory
 TLS encryption is not viable as a default security level for mail delivery to
-the public Internet. Most MX hosts do not support TLS at all, and some of those
+the public Internet. Some MX hosts do not support TLS at all, and some of those
 that do have broken implementations. On a host that delivers mail to the
 Internet, you should not configure mandatory TLS encryption as the default
 security level.
@@ -877,9 +925,10 @@ not specified consistently.
     submission
 
     /etc/postfix/tls_policy:
-        [example.net]:587 encrypt protocols=TLSv1 ciphers=high
-        [example.net]:msa encrypt protocols=TLSv1 ciphers=high
-        [example.net]:submission encrypt protocols=TLSv1 ciphers=high
+        # Postfix >= 3.6 "protocols" syntax
+        [example.net]:587 encrypt protocols=>=TLSv1.2 ciphers=high
+        # Legacy "protocols" syntax
+        [example.net]:msa encrypt protocols=!SSLv2:!SSLv3 ciphers=high
 
 DDAANNEE TTLLSS aauutthheennttiiccaattiioonn..
 
@@ -977,8 +1026,9 @@ The pre-requisites for DANE support in the Postfix SMTP client are:
 The above client pre-requisites do not apply to the Postfix SMTP server. It
 will support DANE provided it supports TLSv1 and its TLSA records are published
 in a DNSSEC signed zone. To receive DANE secured mail for multiple domains, use
-the same hostname to add the server to each domain's MX records. There are no
-plans to implement SNI in the Postfix SMTP server.
+the same hostname to add the server to each domain's MX records. The Postfix
+SMTP server supports SNI (Postfix 3.4 and later), configured with
+tls_server_sni_maps.
 
 Note: The Postfix SMTP client's internal stub DNS resolver is DNSSEC-aware, but
 it does not itself validate DNSSEC records, rather it delegates DNSSEC
@@ -1073,6 +1123,14 @@ fingerprints can be combined with a "|" delimiter in a single match attribute,
 or multiple match attributes can be employed. The ":" character is not used as
 a delimiter as it occurs between each pair of fingerprint (hexadecimal) digits.
 
+The default algorithm is sshhaa225566 with Postfix >= 3.6 and the ccoommppaattiibbiilliittyy__lleevveell
+set to 3.6 or higher; with Postfix <= 3.5, the default algorithm is mmdd55. The
+best-practice algorithm is now sshhaa225566. Recent advances in hash function
+cryptanalysis have led to md5 and sha1 being deprecated in favor of sha256.
+However, as long as there are no known "second pre-image" attacks against the
+older algorithms, their use in this context, though not recommended, is still
+likely safe.
+
 Example: fingerprint TLS security with an internal mailhub. Two matching
 fingerprints are listed. The relayhost may be multiple physical hosts behind a
 load-balancer, each with its own private/public key and self-signed
@@ -1082,22 +1140,22 @@ trusted just prior to the transition.
 
         relayhost = [mailhub.example.com]
         smtp_tls_security_level = fingerprint
-        smtp_tls_fingerprint_digest = md5
+        smtp_tls_fingerprint_digest = sha256
         smtp_tls_fingerprint_cert_match =
-            3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
-            EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+            51:e9:af:2e:1e:40:1f:de:64:...:30:35:2d:09:16:31:5a:eb:82:76
+            b6:b4:72:34:e2:59:cd:fb:c2:...:63:0d:4d:cc:2c:7d:84:de:e6:2f
 
 Example: Certificate fingerprint verification with selected destinations. As in
 the example above, we show two matching fingerprints:
 
     /etc/postfix/main.cf:
         smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
-        smtp_tls_fingerprint_digest = md5
+        smtp_tls_fingerprint_digest = sha256
 
     /etc/postfix/tls_policy:
         example.com fingerprint
-            match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
-            match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+            match=51:e9:af:2e:1e:40:1f:de:...:35:2d:09:16:31:5a:eb:82:76
+            match=b6:b4:72:34:e2:59:cd:fb:...:0d:4d:cc:2c:7d:84:de:e6:2f
 
 To extract the public key fingerprint from an X.509 certificate, you need to
 extract the public key from the certificate and compute the appropriate digest
@@ -1106,26 +1164,12 @@ command extracts the public key always in "PEM" format. We pipe the result to
 another OpenSSL command that converts the key to DER and then to the "dgst"
 command to compute the fingerprint.
 
-The actual command to transform the key to DER format depends on the version of
-OpenSSL used. With OpenSSL 1.0.0 and later, the "pkey" command supports all key
-types. With OpenSSL 0.9.8 and earlier, the key type is always RSA (nobody uses
-DSA, and EC keys are not fully supported by 0.9.8), so the "rsa" command is
-used.
+Example:
 
-    # OpenSSL 1.0 with all certificates and SHA-1 fingerprints.
     $ openssl x509 -in cert.pem -noout -pubkey |
         openssl pkey -pubin -outform DER |
-        openssl dgst -sha1 -c
-    (stdin)= 64:3f:1f:f6:e5:1e:d4:2a:56:8b:fc:09:1a:61:98:b5:bc:7c:60:58
-
-    # OpenSSL 0.9.8 with RSA certificates and MD5 fingerprints.
-    $ openssl x509 -in cert.pem -noout -pubkey |
-        openssl rsa -pubin -outform DER |
-        openssl dgst -md5 -c
-    (stdin)= f4:62:60:f6:12:8f:d5:8d:28:4d:13:a7:db:b2:ff:50
-
-Note: Postfix 2.9.0-2.9.5 computed the public key fingerprint incorrectly. To
-use public-key fingerprints, upgrade to Postfix 2.9.6 or later.
+        openssl dgst -sha256 -c
+    (stdin)= 64:3f:1f:f6:e5:1e:d4:2a:56:...:09:1a:61:98:b5:bc:7c:60:58
 
 MMaannddaattoorryy sseerrvveerr cceerrttiiffiiccaattee vveerriiffiiccaattiioonn
 
@@ -1158,8 +1202,8 @@ SMTP server, and any untrusted issuing parent certificates will be ignored.
 
 Despite the potential for eliminating "man-in-the-middle" and other attacks,
 mandatory certificate trust chain and subject name verification is not viable
-as a default Internet mail delivery policy. Most MX hosts do not support TLS at
-all, and a significant portion of TLS enabled MTAs use self-signed
+as a default Internet mail delivery policy. Some MX hosts do not support TLS at
+all, and a significant portion of TLS-enabled MTAs use self-signed
 certificates, or certificates that are signed by a private Certification
 Authority. On a machine that delivers mail to the Internet, you should not
 configure mandatory server certificate verification as a default policy.
@@ -1219,8 +1263,8 @@ SMTP server, and any untrusted issuing parent certificates will be ignored.
 
 Despite the potential for eliminating "man-in-the-middle" and other attacks,
 mandatory secure server certificate verification is not viable as a default
-Internet mail delivery policy. Most MX hosts do not support TLS at all, and a
-significant portion of TLS enabled MTAs use self-signed certificates, or
+Internet mail delivery policy. Some MX hosts do not support TLS at all, and a
+significant portion of TLS-enabled MTAs use self-signed certificates, or
 certificates that are signed by a private Certification Authority. On a machine
 that delivers mail to the Internet, you should not configure secure TLS
 verification as a default policy.
@@ -1342,17 +1386,18 @@ them. The recommended setting is to let the defaults stand:
         # Postfix >= 2.6
         smtp_tls_eccert_file =
         smtp_tls_eckey_file =
+        # Postfix >= 3.4
+        smtp_tls_chain_files =
 
 The best way to use the default settings is to comment out the above parameters
 in main.cf if present.
 
 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.
+certificate to the remote SMTP server. Browsers typically let the user select
+among the certificates that match the CA names indicated by the remote SMTP
+server. The Postfix SMTP client does not yet have a mechanism to select from
+multiple candidate certificates on the fly, and supports a single set of
+certificates (at most one per public key algorithm).
 
 RSA, DSA and ECDSA (Postfix >= 2.6) certificates are supported. You can
 configure all three at the same time, in which case the cipher used determines
@@ -1361,8 +1406,15 @@ 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.
+accessible without a password. Both parts (certificate and private key) may be
+in the same file.
+
+With OpenSSL 1.1.1 and Postfix >= 3.4 it is also possible to configure Ed25519
+and Ed448 certificates. Rather than add two more pairs of key and certificate
+parameters, Postfix 3.4 introduces a new "smtp_tls_chain_files" parameter which
+specifies all the configured certificates at once, and handles files that hold
+both the key and the associated certificates in one pass, thereby avoiding
+potential race conditions during key rollover.
 
 To enable remote SMTP servers to verify the Postfix SMTP client certificate,
 the issuing CA certificates must be made available to the server. You should
@@ -1370,22 +1422,64 @@ include the required certificates in the client certificate file, the client
 certificate first, then the issuing CA(s) (bottom-up order).
 
 Example: the certificate for "client.example.com" was issued by "intermediate
-CA" which itself has a certificate issued by "root CA". Create the client.pem
-file with:
+CA" which itself has a certificate issued by "root CA". As the "root" super-
+user create the client.pem file with:
 
-    % ccaatt cclliieenntt__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> cclliieenntt..ppeemm
+    # uummaasskk 007777
+    # ccaatt cclliieenntt__kkeeyy..ppeemm cclliieenntt__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> cchhaaiinn..ppeemm
 
-A Postfix SMTP client certificate supplied here must be usable as SSL client
+A Postfix SMTP client certificate supplied here must be usable as an 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.
+of the "chain.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.
 
+Example: Postfix >= 3.4 all-in-one chain file(s). One or more chain files that
+start with a key that is immediately followed by the corresponding certificate
+and any additional issuer certificates. A single file can hold multiple (key,
+cert, [chain]) sequences, one per algorithm. It is typically simpler to keep
+the chain for each algorithm in its own file. Most users are likely to deploy
+at most a single RSA chain, but with OpenSSL 1.1.1, it is possible to deploy up
+five chains, one each for RSA, ECDSA, ED25519, ED448, and even the obsolete
+DSA.
+
+        # Postfix >= 3.4.  Preferred configuration interface.  Each file
+        # starts with the private key, followed by the corresponding
+        # certificate, and any intermediate issuer certificates.
+        #
+        smtp_tls_chain_files =
+            /etc/postfix/rsa.pem,
+            /etc/postfix/ecdsa.pem,
+            /etc/postfix/ed25519.pem,
+            /etc/postfix/ed448.pem
+
+You can also store the keys separately from their certificates, again provided
+each is listed before the corresponding certificate chain. Storing a key and
+its associated certificate chain in separate files is not recommended, because
+this is prone to race conditions during key rollover, as there is no way to
+update multiple files atomically.
+
+        # Postfix >= 3.4.
+        # Storing keys separately from the associated certificates is not
+        # recommended.
+        smtp_tls_chain_files =
+            /etc/postfix/rsakey.pem,
+            /etc/postfix/rsacerts.pem,
+            /etc/postfix/ecdsakey.pem,
+            /etc/postfix/ecdsacerts.pem
+
+The below examples show the legacy algorithm-specific configurations for
+Postfix 3.3 and older. With Postfix <= 3.3, even if the key is stored in the
+same file as the certificate, the file is read twice and a (brief) race
+condition still exists during key rollover. While Postfix >= 3.4 avoids the
+race when the key and certificate are in the same file, you should use the new
+"smtp_tls_chain_files" interface shown above.
+
 RSA key and certificate examples:
 
     /etc/postfix/main.cf:
@@ -1432,6 +1526,43 @@ Example:
         smtp_tls_CAfile = /etc/postfix/CAcert.pem
         smtp_tls_CApath = /etc/postfix/certs
 
+CClliieenntt--ssiiddee TTLLSS ccoonnnneeccttiioonn rreeuussee
+
+Historically, the Postfix SMTP client has supported multiple deliveries per
+plaintext connection. Postfix 3.4 introduces support for multiple deliveries
+per TLS-encrypted connection. Multiple deliveries per connection improve mail
+delivery performance, especially for destinations that throttle clients that
+don't combine deliveries.
+
+To enable multiple deliveries per TLS connection, specify:
+
+    /etc/postfix/main.cf:
+        smtp_tls_connection_reuse = yes
+
+Alternatively, specify the attribute "connection_reuse=yes" in an
+smtp_tls_policy_maps entry.
+
+The implementation of TLS connection reuse relies on the same scache(8) service
+as used for delivering plaintext SMTP mail, the same tlsproxy(8) daemon as used
+by the postscreen(8) service, and relies on the same hints from the qmgr(8)
+daemon. See "Postfix Connection Cache" for a description of the underlying
+connection reuse infrastructure.
+
+Initial SMTP handshake:
+
+    smtp(8) -> remote SMTP server
+
+Reused SMTP/TLS connection, or new SMTP/TLS connection:
+
+    smtp(8) -> tlsproxy(8) -> remote SMTP server
+
+Cached SMTP/TLS connection:
+
+    scache(8) -> tlsproxy(8) -> remote SMTP server
+
+As of Postfix 3.4, TLS connection reuse is disabled by default. This may change
+once the impact on over-all performance is understood.
+
 CClliieenntt--ssiiddee TTLLSS sseessssiioonn ccaacchhee
 
 The remote SMTP server and the Postfix SMTP client negotiate a session, which
@@ -1553,11 +1684,13 @@ verified TLS on the public Internet.
 Historical note: while the documentation of these issues and many of the
 related features were new with Postfix 2.3, the issue was well understood
 before Postfix 1.0, when Lutz Ja"nicke was designing the first unofficial
-Postfix TLS patch. See his original post http://www.imc.org/ietf-apps-tls/mail-
-archive/msg00304.html and the first response http://www.imc.org/ietf-apps-tls/
-mail-archive/msg00305.html. The problem is not even unique to SMTP or even TLS,
-similar issues exist for secure connections via aliases for HTTPS and Kerberos.
-SMTP merely uses indirect naming (via MX records) more frequently.
+Postfix TLS patch. See his original post https://web.archive.org/web/
+20070816181658/http://www.imc.org/ietf-apps-tls/mail-archive/msg00304.html and
+the first response https://web.archive.org/web/20070807073846/http://
+www.imc.org/ietf-apps-tls/mail-archive/msg00305.html. The problem is not even
+unique to SMTP or even TLS, similar issues exist for secure connections via
+aliases for HTTPS and Kerberos. SMTP merely uses indirect naming (via MX
+records) more frequently.
 
 TTLLSS ppoolliiccyy ttaabbllee
 
@@ -1596,69 +1729,109 @@ describe the corresponding table syntax:
 nnoonnee
     No TLS. No additional attributes are supported at this level.
 mmaayy
-    Opportunistic TLS. The optional "ciphers", "exclude" and "protocols"
-    attributes (available for opportunistic TLS with Postfix >= 2.6) override
-    the "smtp_tls_ciphers", "smtp_tls_exclude_ciphers" and "smtp_tls_protocols"
-    configuration parameters.
+    Opportunistic TLS. The optional "ciphers", "exclude", and "protocols"
+    attributes (available for opportunistic TLS with Postfix >= 2.6) and
+    "connection_reuse" attribute (Postfix >= 3.4) override the
+    "smtp_tls_ciphers", "smtp_tls_exclude_ciphers", "smtp_tls_protocols", and
+    "smtp_tls_connection_reuse" configuration parameters. At this level and
+    higher, the optional "servername" attribute (available with Postfix >= 3.4)
+    overrides the global "smtp_tls_servername" parameter, enabling per-
+    destination configuration of the SNI extension sent to the remote SMTP
+    server. The optional "enable_rpk" attribute (Postfix >= 3.9) overrides the
+    main.cf smtp_tls_enable_rpk parameter. When opportunistic TLS handshakes
+    fail, Postfix retries the connection with TLS disabled. This allows mail
+    delivery to sites with non-interoperable TLS implementations.
 eennccrryypptt
     Mandatory encryption. Mail is delivered only if the remote SMTP server
     offers STARTTLS and the TLS handshake succeeds. At this level and higher,
     the optional "protocols" attribute overrides the main.cf
     smtp_tls_mandatory_protocols parameter, the optional "ciphers" attribute
-    overrides the main.cf smtp_tls_mandatory_ciphers parameter, and the
-    optional "exclude" attribute (Postfix >= 2.6) overrides the main.cf
-    smtp_tls_mandatory_exclude_ciphers parameter.
+    overrides the main.cf smtp_tls_mandatory_ciphers parameter, the optional
+    "exclude" attribute (Postfix >= 2.6) overrides the main.cf
+    smtp_tls_mandatory_exclude_ciphers parameter, and the optional
+    "connection_reuse" attribute (Postfix >= 3.4) overrides the main.cf
+    smtp_tls_connection_reuse parameter. The optional "enable_rpk" attribute
+    (Postfix >= 3.9) overrides the main.cf smtp_tls_enable_rpk parameter.
 ddaannee
     Opportunistic DANE TLS. The TLS policy for the destination is obtained via
     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+3 are automatically disabled
-    (see smtp_tls_mandatory_protocols), and the server certificate must match
-    the TLSA records. RFC 7672 (DANE) TLS authentication and DNSSEC support is
-    available with Postfix 2.11 and later.
+    obtained for the remote SMTP server, the server certificate must match the
+    TLSA records (and the SNI name is unconditionally set to the TLSA base
+    domain). RFC 7672 (DANE) TLS authentication and DNSSEC support is available
+    with Postfix 2.11 and later. The optional "connection_reuse" attribute
+    (Postfix >= 3.4) overrides the main.cf smtp_tls_connection_reuse parameter.
+    When the effective security level used is may, the optional "ciphers",
+    "exclude", and "protocols" attributes (Postfix >= 2.6) override the
+    "smtp_tls_ciphers", "smtp_tls_exclude_ciphers", and "smtp_tls_protocols"
+    configuration parameters. When the effective security level used is
+    encrypt, the optional "ciphers", "exclude", and "protocols" attributes
+    (Postfix >= 2.6) override the "smtp_tls_mandatory_ciphers",
+    "smtp_tls_mandatory_exclude_ciphers", and "smtp_tls_mandatory_protocols"
+    configuration parameters.
 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+3 are automatically disabled (see
-    smtp_tls_mandatory_protocols), and the server certificate must match the
-    TLSA records. RFC 7672 (DANE) TLS authentication and DNSSEC support is
-    available with Postfix 2.11 and later.
+    the remote SMTP server, the server certificate must match the TLSA records.
+    RFC 7672 (DANE) TLS authentication and DNSSEC support is available with
+    Postfix 2.11 and later. The optional "ciphers", "exclude", and "protocols"
+    attributes (Postfix >= 2.6) override the "smtp_tls_mandatory_ciphers",
+    "smtp_tls_mandatory_exclude_ciphers", and "smtp_tls_mandatory_protocols"
+    configuration parameters. The optional "connection_reuse" attribute
+    (Postfix >= 3.4) overrides the main.cf smtp_tls_connection_reuse parameter.
 ffiinnggeerrpprriinntt
     Certificate fingerprint verification. Available with Postfix 2.5 and later.
     At this security level, there are no trusted Certification Authorities. The
     certificate trust chain, expiration date, ... are not checked. Instead, the
-    optional mmaattcchh attribute, or else the main.cf
-    ssmmttpp__ttllss__ffiinnggeerrpprriinntt__cceerrtt__mmaattcchh parameter, lists the server certificate
-    fingerprints or public key fingerprints (Postfix 2.9 and later). The digest
-    algorithm used to calculate fingerprints is selected by the
-    ssmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt parameter. Multiple fingerprints can be
-    combined with a "|" delimiter in a single match attribute, or multiple
-    match attributes can be employed. The ":" character is not used as a
-    delimiter as it occurs between each pair of fingerprint (hexadecimal)
-    digits.
+    optional "match" attribute, or else the main.cf
+    ssmmttpp__ttllss__ffiinnggeerrpprriinntt__cceerrtt__mmaattcchh parameter, lists the certificate
+    fingerprints or the public key fingerprints (Postfix 2.9 and later) of
+    acceptable server certificates. The digest algorithm used to calculate the
+    fingerprint is selected by the ssmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt parameter.
+    Multiple fingerprints can be combined with a "|" delimiter in a single
+    match attribute, or multiple match attributes can be employed. The ":
+    " character is not used as a delimiter as it occurs between each pair of
+    fingerprint (hexadecimal) digits. The optional "ciphers", "exclude", and
+    "protocols" attributes (Postfix >= 2.6) override the
+    "smtp_tls_mandatory_ciphers", "smtp_tls_mandatory_exclude_ciphers", and
+    "smtp_tls_mandatory_protocols" configuration parameters. The optional
+    "connection_reuse" attribute (Postfix >= 3.4) overrides the main.cf
+    smtp_tls_connection_reuse parameter. The optional "enable_rpk" attribute
+    (Postfix >= 3.9) overrides the main.cf smtp_tls_enable_rpk parameter.
 vveerriiffyy
     Mandatory server certificate verification. Mail is delivered only if the
-    TLS handshake succeeds, if the remote SMTP server certificate can be
-    validated (not expired or revoked, and signed by a trusted Certification
-    Authority), and if the server certificate name matches the optional "match"
-    attribute (or the main.cf smtp_tls_verify_cert_match parameter value when
-    no optional "match" attribute is specified). With Postfix >= 2.11 the
+    TLS handshake succeeds, the remote SMTP server certificate chain can be
+    validated, and a DNS name in the certificate matches the specified match
+    criteria. At this security level, DNS MX lookups are presumed to be secure
+    enough, and the name verified in the server certificate is potentially
+    obtained via unauthenticated DNS MX lookups. The server certificate name
+    must match either the optional "match" attribute, or else the main.cf
+    smtp_tls_verify_cert_match parameter value. With Postfix >= 2.11 the
     "tafile" attribute optionally modifies trust chain verification in the same
     manner as the "smtp_tls_trust_anchor_file" parameter. The "tafile"
     attribute may be specified multiple times to load multiple trust-anchor
-    files.
+    files. The optional "connection_reuse" attribute (Postfix >= 3.4) overrides
+    the main.cf smtp_tls_connection_reuse parameter.
 sseeccuurree
     Secure certificate verification. Mail is delivered only if the TLS
-    handshake succeeds, if the remote SMTP server certificate can be validated
-    (not expired or revoked, and signed by a trusted Certification Authority),
-    and if the server certificate name matches the optional "match" attribute
-    (or the main.cf smtp_tls_secure_cert_match parameter value when no optional
-    "match" attribute is specified). With Postfix >= 2.11 the "tafile"
-    attribute optionally modifies trust chain verification in the same manner
-    as the "smtp_tls_trust_anchor_file" parameter. The "tafile" attribute may
-    be specified multiple times to load multiple trust-anchor files.
+    handshake succeeds, the remote SMTP server certificate chain can be
+    validated, and a DNS name in the certificate matches the specified match
+    criteria. At this security level, DNS MX lookups, though potentially used
+    to determine the candidate next-hop gateway IP addresses, are nnoott presumed
+    to be secure enough for TLS peername verification. Instead, the default
+    name verified in the server certificate is obtained directly from the next-
+    hop, or is explicitly specified via the optional "match" attribute which
+    overrides the main.cf smtp_tls_secure_cert_match parameter. The optional
+    "ciphers", "exclude", and "protocols" attributes (Postfix >= 2.6) override
+    the "smtp_tls_mandatory_ciphers", "smtp_tls_mandatory_exclude_ciphers", and
+    "smtp_tls_mandatory_protocols" configuration parameters. With Postfix >=
+    2.11 the "tafile" attribute optionally modifies trust chain verification in
+    the same manner as the "smtp_tls_trust_anchor_file" parameter. The "tafile"
+    attribute may be specified multiple times to load multiple trust-anchor
+    files. The optional "connection_reuse" attribute (Postfix >= 3.4) overrides
+    the main.cf smtp_tls_connection_reuse parameter.
 Notes:
 
   * The "match" attribute is especially useful to verify TLS certificates for
@@ -1691,7 +1864,7 @@ Example:
     /etc/postfix/main.cf:
         smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
         # Postfix 2.5 and later
-        smtp_tls_fingerprint_digest = md5
+        smtp_tls_fingerprint_digest = sha256
     /etc/postfix/tls_policy:
         example.edu             none
         example.mil             may
@@ -1702,10 +1875,13 @@ Example:
         [mail.example.org]:587  secure match=nexthop
         # Postfix 2.5 and later
         [thumb.example.org]         fingerprint
-            match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
-            match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
-        # Postfix 2.6 and later
-        example.info            may protocols=!SSLv2 ciphers=medium
+            match=b6:b4:72:34:e2:59:cd:fb:...:0d:4d:cc:2c:7d:84:de:e6:2f
+            match=51:e9:af:2e:1e:40:1f:de:...:35:2d:09:16:31:5a:eb:82:76
+        # Postfix >= 3.6 "protocols" syntax
+        example.info            may protocols=>=TLSv1 ciphers=medium
+    exclude=3DES
+        # Legacy protocols syntax
+        example.info            may protocols=!SSLv2:!SSLv3 ciphers=medium
     exclude=3DES
 
 NNoottee:: The "hostname" strategy if listed in a non-default setting of
@@ -1778,8 +1954,8 @@ the minimum opportunistic TLS cipher grade is always "export".
 With mandatory and opportunistic TLS encryption, the Postfix SMTP client will
 by default disable SSLv2 and SSLv3. The mandatory TLS protocol list is
 specified via the smtp_tls_mandatory_protocols configuration parameter. The
-corresponding smtp_tls_protocols parameter (Postfix >= 2.6) controls the SSL/
-TLS protocols used with opportunistic TLS.
+corresponding smtp_tls_protocols parameter (Postfix >= 2.6) controls the TLS
+protocols used with opportunistic TLS.
 
 Example:
 
@@ -1787,56 +1963,59 @@ Example:
         smtp_tls_mandatory_ciphers = medium
         smtp_tls_mandatory_exclude_ciphers = RC4, MD5
         smtp_tls_exclude_ciphers = aNULL
-        # Preferred form with Postfix >= 2.5:
-        smtp_tls_mandatory_protocols = !SSLv2
-        # Legacy form for Postfix < 2.5:
-        smtp_tls_mandatory_protocols = SSLv3, TLSv1
-        # Also available with Postfix >= 2.6:
         smtp_tls_ciphers = medium
-        smtp_tls_protocols = !SSLv2
+        # Preferred form with Postfix >= 3.6:
+        smtp_tls_mandatory_protocols = >=TLSv1.2
+        smtp_tls_protocols = >=TLSv1
+        # Legacy form for Postfix < 3.6:
+        smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
+        smtp_tls_protocols = !SSLv2,!SSLv3
 
-CClliieenntt--ssiiddee SSMMTTPPSS ssuuppppoorrtt
+CClliieenntt--ssiiddee ssuubbmmiissssiioonnss ((ffoorrmmeerrllyy ccaalllleedd ssmmttppss)) ssuuppppoorrtt
 
 These sections show how to send mail to a server that does not support
-STARTTLS, but that provides the deprecated SMTPS service on TCP port 465.
+STARTTLS, but that provides the submissions (smtps) service on TCP port 465.
 Depending on the Postfix version, some additional tooling may be required.
 
 PPoossttffiixx >>== 33..00
 
-The Postfix SMTP client has SMTPS support built-in as of version 3.0. Use one
-of the following examples, to send all remote mail, or to send only some remote
-mail, to an SMTPS server.
+The Postfix SMTP client has submissions service support built-in as of version
+3.0. Use one of the following examples, to send all remote mail, or to send
+only some remote mail, to a submissions (smtps) server.
 
-PPoossttffiixx >>== 33..00:: SSeennddiinngg aallll rreemmoottee mmaaiill ttoo aann SSMMTTPPSS sseerrvveerr
+PPoossttffiixx >>== 33..00:: SSeennddiinngg aallll rreemmoottee mmaaiill ttoo aa ssuubbmmiissssiioonnss ((ffoorrmmeerrllyy ccaalllleedd
+ssmmttppss)) sseerrvveerr
 
-The first example will send all remote mail over SMTPS through a provider's
+The first example will send all remote mail to through a provider's submissions
 server called "mail.example.com":
 
     /etc/postfix/main.cf:
-        # Client-side SMTPS requires "encrypt" or stronger.
+        # Client-side submissions requires "encrypt" or stronger.
         smtp_tls_security_level = encrypt
         smtp_tls_wrappermode = yes
         # The [] suppress MX lookups.
-        relayhost = [mail.example.com]:465
+        relayhost = [mail.example.com]:submissions
 
 Use "postfix reload" to make the change effective.
 
 See SOHO_README for additional information about SASL authentication.
 
-PPoossttffiixx >>== 33..00:: SSeennddiinngg oonnllyy mmaaiill ffoorr aa ssppeecciiffiicc ddeessttiinnaattiioonn vviiaa SSMMTTPPSS
+PPoossttffiixx >>== 33..00:: SSeennddiinngg oonnllyy mmaaiill ffoorr aa ssppeecciiffiicc ddeessttiinnaattiioonn ttoo aa ssuubbmmiissssiioonnss
+((ffoorrmmeerrllyy ccaalllleedd ssmmttppss)) sseerrvviiccee
 
-The second example will send only mail for "example.com" via SMTPS. This time,
-Postfix uses a transport map to deliver only mail for "example.com" via SMTPS:
+The second example will send only mail for "example.com" using the submissions
+(smtps) service. This time, Postfix uses a transport map to deliver only mail
+for "example.com" using the submissions (smtps) service:
 
     /etc/postfix/main.cf:
         transport_maps = hash:/etc/postfix/transport
 
     /etc/postfix/transport:
-        example.com  relay-smtps:example.com:465
+        example.com  relay-submissions:example.com:submissions
 
     /etc/postfix/master.cf:
-        relay-smtps  unix  -       -       n       -       -       smtp
-            # Client-side SMTPS requires "encrypt" or stronger.
+        relay-submissions  unix  -       -       n       -       -       smtp
+            # Client-side submissions service requires "encrypt" or stronger.
             -o smtp_tls_security_level=encrypt
             -o smtp_tls_wrappermode=yes
 
@@ -1847,62 +2026,7 @@ See SOHO_README for additional information about SASL authentication.
 
 PPoossttffiixx << 33..00
 
-Although older Postfix SMTP client versions do not support TLS wrapper mode, it
-is relatively easy to forward a connection through the stunnel program if
-Postfix needs to deliver mail to some legacy system that doesn't support
-STARTTLS.
-
-PPoossttffiixx << 33..00:: SSeennddiinngg aallll rreemmoottee mmaaiill ttoo aann SSMMTTPPSS sseerrvveerr
-
-The first example uses SMTPS to send all remote mail to a provider's mail
-server called "mail.example.com".
-
-A minimal stunnel.conf file is sufficient to set up a tunnel from local port
-11125 to the remote destination "mail.example.com" and port "smtps". Postfix
-will later use this tunnel to connect to the remote server.
-
-    /path/to/stunnel.conf:
-        [smtp-tls-wrapper]
-        accept = 11125
-        client = yes
-        connect = mail.example.com:smtps
-
-To test this tunnel, use:
-
-    $ telnet localhost 11125
-
-This should produce the greeting from the remote SMTP server at
-mail.example.com.
-
-On the Postfix side, the relayhost feature sends all remote mail through the
-local stunnel listener on port 11125:
-
-    /etc/postfix/main.cf:
-        relayhost = [127.0.0.1]:11125
-
-Use "postfix reload" to make the change effective.
-
-See SOHO_README for additional information about SASL authentication.
-
-PPoossttffiixx << 33..00:: SSeennddiinngg oonnllyy mmaaiill ffoorr aa ssppeecciiffiicc ddeessttiinnaattiioonn vviiaa SSMMTTPPSS
-
-The second example will use SMTPS to send only mail for "example.com" via
-SMTPS. It uses the same stunnel configuration file as the first example, so it
-won't be repeated here.
-
-This time, the Postfix side uses a transport map to direct only mail for
-"example.com" through the tunnel:
-
-    /etc/postfix/main.cf:
-        transport_maps = hash:/etc/postfix/transport
-
-    /etc/postfix/transport:
-        example.com  relay:[127.0.0.1]:11125
-
-Use "postmap hash:/etc/postfix/transport" and "postfix reload" to make the
-change effective.
-
-See SOHO_README for additional information about SASL authentication.
+Please see TLS_LEGACY_README.
 
 MMiisscceellllaanneeoouuss cclliieenntt ccoonnttrroollss
 
@@ -2040,7 +2164,7 @@ authentication. This is sufficient for testing, and for exchanging email with
 sites that you have no trust relationship with. For real authentication you
 need also enable DNSSEC record signing for your domain and publish TLSA records
 and/or your Postfix public key certificate needs to be signed by a recognized
-Certification Authority. To authenticate the certificates of remote host you
+Certification Authority. To authenticate the certificates of a remote host you
 need a DNSSEC-validating local resolver and to enable DANE authentication and/
 or configure the Postfix SMTP client with a list of public key certificates of
 Certification Authorities, but make sure to read about the limitations of the
@@ -2090,7 +2214,7 @@ If you're willing to revert your settings to the defaults and switch to a
 "stock" opportunistic TLS configuration, then you can: erase all the SMTP
 client TLS settings and then enable client TLS:
 
-    # postconf -X `postconf -nH | egrep '^smtp(_|_enforce_|_use_)tls'`
+    # postconf -X `postconf -nH | grep -E '^smtp(_|_enforce_|_use_)tls'`
     # postfix tls enable-client
     # postfix reload
 
@@ -2114,7 +2238,7 @@ If you're willing to revert your settings to the defaults and switch to a
 "stock" server TLS configuration, then you can: erase all the SMTP server TLS
 settings and then enable server TLS:
 
-    # postconf -X `postconf -nH | egrep '^smtpd(_|_enforce_|_use_)tls'`
+    # postconf -X `postconf -nH | grep -E '^smtpd(_|_enforce_|_use_)tls'`
     # postfix tls enable-server
     # postfix reload
 
@@ -2128,7 +2252,10 @@ SSeellff--ssiiggnneedd sseerrvveerr cceerrttiiffiiccaa
 
 The following commands (credits: Viktor Dukhovni) generate and install a 2048-
 bit RSA private key and 10-year self-signed certificate for the local Postfix
-system. This requires super-user privileges.
+system. This requires super-user privileges. (By using date-specific filenames
+for the certificate and key files, and updating main.cf with new filenames, a
+potential race condition in which the key and certificate might not match is
+avoided).
 
     # dir="$(postconf -h config_directory)"
     # fqdn=$(postconf -h myhostname)
@@ -2255,7 +2382,7 @@ PPrriivvaattee CCeerrttiiffiiccaattiioonn AAuutthhoorr
     Often servers that perform TLS client authentication will issue the
     required certificates signed by their own CA. If you configure the client
     certificate and key incorrectly, you will be unable to send mail to sites
-    that request client certificate, but don't require them from all clients.
+    that request a client certificate, but don't require them from all clients.
 
         /etc/postfix/main.cf:
             smtp_tls_CAfile = /etc/postfix/cacert.pem
@@ -2303,6 +2430,10 @@ aapppprroopprriiaattee..
         % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__TTLLSS --II//uussrr//llooccaall//iinncclluuddee"" \\
             AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb --llssssll --llccrryyppttoo""
 
+    If your OpenSSL shared library is in a directory that the RUN-TIME linker
+    does not know about, add a "-Wl,-R,/path/to/directory" option after "-
+    lcrypto".
+
     On Solaris, specify the -R option as shown below:
 
         % mmaakkee ttiiddyy # if you have left-over files from a previous build
@@ -2326,7 +2457,7 @@ as it is installed.
 
 RReeppoorrttiinngg pprroobblleemmss
 
-Problems are preferably reported via <postfix-users@postfix.org>. See http://
+Problems are preferably reported via <postfix-users@postfix.org>. See https://
 www.postfix.org/lists.html for subscription information. When reporting a
 problem, please be thorough in the report. Patches, when possible, are greatly
 appreciated too.

postfix/README_FILES/TUNING_README

@@ -285,9 +285,8 @@ than the default 20) simultaneous connections, especially if the gateway
 forwards to multiple MX hosts. When all MX hosts are up and accepting
 connections in a timely fashion, throughput will be high. If any MX host is
 down and completely unresponsive, the average connection latency rises to at
-least 1/N * $smtp_connection_timeout, if there are N MX hosts. This limits
-throughput to at most the destination concurrency * N /
-$smtp_connection_timeout.
+least 1/N * $smtp_connect_timeout, if there are N MX hosts. This limits
+throughput to at most the destination concurrency * N / $smtp_connect_timeout.
 
 For example, with a destination concurrency of 100 and 2 MX hosts, each host
 will handle up to 50 simultaneous connections. If one MX host is down and the
@@ -298,10 +297,10 @@ low as 5s or even 1s can be used to prevent congestion when one or more, but
 not all MX hosts are down.
 
 If necessary, set a higher transport_destination_concurrency_limit (in main.cf
-since this is a queue manager parameter) and a lower smtp_connection_timeout
-(with a "-o" override in master.cf since this parameter has no per-transport
-name) for the relay transport and any transports dedicated for specific high
-volume destinations.
+since this is a queue manager parameter) and a lower smtp_connect_timeout (with
+a "-o" override in master.cf since this parameter has no per-transport name)
+for the relay transport and any transports dedicated for specific high volume
+destinations.
 
 TTuunniinngg tthhee nnuummbbeerr ooff rreecciippiieennttss ppeerr ddeelliivveerryy
 

postfix/README_FILES/UUCP_README

@@ -8,7 +8,7 @@ Despite a serious lack of sex-appeal, email via UUCP over TCP is a practical
 option for sites without permanent Internet connections, and for sites without
 a fixed IP address. For first-hand information, see the following guides:
 
-  * Jim Seymour's guide for using UUCP over TCP at http://jimsun.LinxNet.com/
+  * Jim Seymour's guide for using UUCP over TCP at https://jimsun.LinxNet.com/
     jdp/uucp_over_tcp/index.html,
   * Craig Sanders's guide for SSL-encrypted UUCP over TCP using stunnel at
     http://taz.net.au/postfix/uucp/.

postfix/README_FILES/VERP_README

@@ -19,7 +19,7 @@ Thus, undeliverable mail can reveal the undeliverable recipient address without
 requiring the list owner to parse bounce messages.
 
 The VERP concept was popularized by the qmail MTA and by the ezmlm mailing list
-manager. See http://cr.yp.to/proto/verp.txt for the ideas behind this concept.
+manager. See https://cr.yp.to/proto/verp.txt for the ideas behind this concept.
 
 Topics covered in this document:
 

postfix/README_FILES/VIRTUAL_README

@@ -27,14 +27,14 @@ The following topics are covered:
 
 CCaannoonniiccaall vveerrssuuss hhoosstteedd vveerrssuuss ootthheerr ddoommaaiinnss
 
-Most Postfix systems are ffiinnaall ddeessttiinnaattiioonn for only a few domain names. These
-include the hostnames and [the IP addresses] of the machine that Postfix runs
-on, and sometimes also include the parent domain of the hostname. The remainder
-of this document will refer to these domains as the canonical domains. They are
-usually implemented with the Postfix local domain address class, as defined in
-the ADDRESS_CLASS_README file.
+Most Postfix systems are the ffiinnaall ddeessttiinnaattiioonn for only a few domain names.
+These include the hostnames and [the IP addresses] of the machine that Postfix
+runs on, and sometimes also include the parent domain of the hostname. The
+remainder of this document will refer to these domains as the canonical
+domains. They are usually implemented with the Postfix local domain address
+class, as defined in the ADDRESS_CLASS_README file.
 
-Besides the canonical domains, Postfix can be configured to be ffiinnaall
+Besides the canonical domains, Postfix can be configured to be the ffiinnaall
 ddeessttiinnaattiioonn for any number of additional domains. These domains are called
 hosted, because they are not directly associated with the name of the machine
 itself. Hosted domains are usually implemented with the virtual alias domain
@@ -49,8 +49,8 @@ implemented with the relay domain address class, as defined in the
 ADDRESS_CLASS_README file.
 
 Finally, Postfix can be configured as a transit host for sending mail across
-the internet. Obviously, Postfix is not final destination for such mail. This
-function is available only for authorized clients and/or users, and is
+the internet. Obviously, Postfix is not the final destination for such mail.
+This function is available only for authorized clients and/or users, and is
 implemented by the default domain address class, as defined in the
 ADDRESS_CLASS_README file.
 

postfix/README_FILES/XCLIENT_README

@@ -100,8 +100,8 @@ Note 3: Postfix implementations prior to version 2.3 do not xtext encode
 attribute values. Servers that wish to interoperate with these older
 implementations should be prepared to receive unencoded information.
 
-Note 4: Some Postfix implementations do not implement the PORT or LOGIN
-attributes.
+Note 4: The PORT attribute is implemented in Postfix 2.5 and later; the LOGIN
+attribute in Postfix 2.9 and later.
 
 XXCCLLIIEENNTT SSeerrvveerr rreessppoonnssee
 

postfix/RELEASE_NOTES

@@ -1,29 +1,27 @@
-This is the Postfix 3.3 (experimental) release.
+This is the Postfix 3.11 experimental release.
 
-The stable Postfix release is called postfix-3.2.x where 3=major
-release number, 2=minor release number, x=patchlevel.  The stable
+The stable Postfix release is called postfix-3.10.x where 3=major
+release number, 10=minor release number, x=patchlevel. The stable
 release never changes except for patches that address bugs or
 emergencies. Patches change the patchlevel and the release date.
 
 New features are developed in snapshot releases. These are called
-postfix-3.3-yyyymmdd where yyyymmdd is the release date (yyyy=year,
-mm=month, dd=day).  Patches are never issued for snapshot releases;
+postfix-3.11-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
 instead, a new snapshot is released.
 
 The mail_release_date configuration parameter (format: yyyymmdd)
 specifies the release date of a stable release or snapshot release.
 
-If you upgrade from Postfix 3.1 or earlier, read RELEASE_NOTES-3.2
+If you upgrade from Postfix 3.9 or earlier, please read RELEASE_NOTES-3.10
 before proceeding.
 
-Incompatible changes with snapshot 201800107
---------------------------------------------
+Dual license
+------------
 
-This release changes the format of 'full name' information in
-Postfix-generated From: headers, when a local program such as
-/bin/mail submits a message without From: header.
-
-Postfix-generated From: headers with 'full name' information are
-now formatted as "From: name <address>" by default. Specify
-"header_from_format = obsolete" to get the earlier form "From:
-address (name)". See the postconf(5) manpage for more details.
+As of Postfix 3.2.5 this software is distributed with a dual license:
+in addition to the historical IBM Public License (IPL) 1.0, it is
+now also distributed with the more recent Eclipse Public License
+(EPL) 2.0. Recipients can choose to take the software under the
+license of their choice. Those who are more comfortable with the
+IPL can continue with that license.

postfix/RELEASE_NOTES-3.10

@@ -0,0 +1,200 @@
+This is the Postfix 3.10 stable release.
+
+The stable Postfix release is called postfix-3.10.x where 3=major
+release number, 10=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-3.11-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 3.8 or earlier, please read RELEASE_NOTES-3.9
+before proceeding.
+
+Dual license
+------------
+
+As of Postfix 3.2.5 this software is distributed with a dual license:
+in addition to the historical IBM Public License (IPL) 1.0, it is
+now also distributed with the more recent Eclipse Public License
+(EPL) 2.0. Recipients can choose to take the software under the
+license of their choice. Those who are more comfortable with the
+IPL can continue with that license.
+
+Major changes - tls
+-------------------
+
+[Forward compatibility 20250212] Support for OpenSSL 3.5 post-quantum
+cryptography. To manage algorithm selection, OpenSSL introduces new
+TLS group syntax that Postfix will not attempt to imitate. Instead,
+Postfix now allows the tls_eecdh_auto_curves and tls_ffdhe_auto_groups
+parameter values to have an empty value. When both are set empty,
+the algorithm selection can be managed through OpenSSL configuration.
+For more, look for "Post-quantum" in the postconf(5) manpage.
+
+[Feature 20250117] Support for the RFC 8689 "TLS-Required: no"
+message header to request delivery of messages such as TLSRPT
+summaries even if the preferred TLS security policy cannot be
+enforced. This limits the Postfix SMTP client to "smtp_tls_security_level
+= may" which does not authenticate server certificates and which
+allows falling back to plaintext.
+
+Support for the REQUIRETLS SMTP service extension remains future work.
+
+[Feature 20240926] Support for the TLSRPT protocol (defined in RFC
+8460). With this, a domain can publish a policy in DNS, and request
+daily summary reports for successful and failed SMTP-over-TLS
+connections to that domain's MX hosts.
+
+Postfix supports TLSRPT summaries for DANE (built-in) and MTA-STS
+(via an smtp_tls_policy_maps plugin). For details, see TLSRPT_README.
+
+Major changes - privacy
+-----------------------
+
+[Feature 20250205] With "smtpd_hide_client_session = yes", the
+Postfix SMTP server generates a Received: header without client
+session info This setting may be used with the MUA submission
+services (port 465 and 587), but it must not be used with the MTA
+service (port 25).
+
+Depending on the number of recipients, a redacted Received: header
+has one of the following forms:
+
+Received: by mail.example.com (Postfix) id postfix-queue-id
+        for <user@example.com>; Day, dd Mon yyyy hh:mm:ss tz-offset (zone)
+
+Received: by mail.example.com (Postfix) id postfix-queue-id
+        Day, dd Mon yyyy hh:mm:ss tz-offset (zone)
+
+The redacted form hides that a message was received with SMTP, and
+therefore it does not need to provide the information required by
+RFC 5321. It only has to satisfy RFC 5322.
+
+Major changes - rfc2047
+-----------------------
+
+[Feature 20250105] Support for automatic RFC 2047 encoding of
+non-ASCII "full name" information in Postfix-generated From: message
+headers.  Encoding non-ASCII full names can avoid the need to use
+SMTPUTF8, and therefore can avoid incompatibility with sites that
+do not support SMTPUTF8.
+
+The encoded result looks like "=?charset?Q?gibberish?=: for
+quoted-printable encoding, or "=?charset?B?gibberish?=" for base64
+encoding. Postfix uses quoted-printable for a full name that is
+short or mostly ASCII, and uses base64 otherwise.
+
+Background: when a message without a From: header is submitted with
+the Postfix sendmail(1) command, Postfix may add a From: header and
+use the sender's full name specified with the Postfix sendmail(1)
+"-F" option, with the sendmail(1) "NAME" environment variable, or
+with the GECOS field in the UNIX password database.
+
+This introduces a new configuration parameter "full_name_encoding_charset"
+(default: utf8) which specifies the character set of the full name
+information in the Postfix sendmail(1) "-F" option or "NAME"
+environment variable, or in the GECOS field in the UNIX password
+database. The parameter value becomes part of the encoded full name,
+and informs a Mail User Agent how to display the decoded gibberish.
+
+Major changes - bugfix
+----------------------
+
+[Incompat 20241130] The spawn(8) daemon failed to enforce the command
+time limit. It was sending the SIGKILL signal using the wrong
+effective UID and GID. The pipe(8) daemon has always done this
+right.
+
+Major changes - database
+------------------------
+
+[Feature 20250207] When mysql: or pgsql: configuration specifies
+a single host, assume that it is a load balancer and reconnect
+immediately after a single failure, instead of failing all requests
+for 60s.
+
+[Feature 20250114] first/next iterator support for cdb: tables, and
+other cdb: table code cleanups by Michael Tokarev.
+
+[Feature 20241024] In a pgsql: client configuration, the setting
+"dbname" is required, but ignored when the setting "hosts" contains
+an URI with a database name.
+
+[Feature 20241025] The Postfix pgsql: client configuration now
+allows any well-formed URI prefix as a pgsql: client connection
+target (the PostgreSQL URI parser decides what is allowed). The
+dbname setting is now optional if the hosts setting specifies only
+URIs.
+
+Major changes - internal protocol
+---------------------------------
+
+[Incompat 20250116] Postfix needs "postfix reload" after upgrade,
+because of a change in the delivery agent protocol. If this step
+is skipped, Postfix delivery agents will log a warning:
+
+    unexpected attribute smtputf8 from xxx socket (expecting: sendopts)
+
+where xxx is the delivery agent service name.
+
+Major changes - milter
+----------------------
+
+[Incompat 20250106] The logging of the Milter 'quarantine' action
+has changed.  Instead of logging "milter triggers HOLD action", it
+logs the reason given by a Milter application, or "default_action"
+if a Milter application was unavailable and the milter_default_action
+parameter or per-Milter "default_action" property specifies
+"quarantine".
+
+[Feature 20250106] The Postfix Milter implementation now logs the
+reason for a 'quarantine' action, instead of "milter triggers HOLD
+action".
+
+- If the quarantine action was requested by a Milter application,
+  Postfix will log the reason given by the application.
+
+- If the quarantine action was requested with the "milter_default_action"
+  parameter setting or with a per-Milter "default_action" property,
+  Postfix will log "default_action".
+
+Major changes - logging
+-----------------------
+
+[Feature 20250106] The Postfix Milter implementation now logs the
+reason for a 'quarantine' action, instead of "milter triggers HOLD
+action".
+
+- If the quarantine action was requested by a Milter application,
+  Postfix will log the reason given by the application.
+
+- If the quarantine action was requested with the "milter_default_action"
+  parameter setting or with a per-Milter "default_action" property,
+  Postfix will log "default_action".
+
+[Incompat 20250105] The SMTP server now logs the queue ID (or
+"NOQUEUE") when a connection ends abnormally (timeout, lost connection,
+or too many errors).
+
+[Feature 20250105] The SMTP server now logs the queue ID (or
+"NOQUEUE") when a connection ends abnormally (timeout, lost connection,
+or too many errors).
+
+[Incompat 20241104] The cleanup server now logs "queueid: canceled"
+when a message transaction is started but not completed.
+
+[Feature 20241104] The cleanup server now logs "queueid: canceled"
+when a message transaction is started but not completed. This
+provides a clear signal to logfile collation tools.
+
+[Incompat 20241031] the Dovecot SASL client logging for "Invalid
+authentication mechanism" now includes the name of that mechanism.
+
+[Incompat 20241023] Postfix SMTP server 'reject' logging now shows
+the sasl_method, sasl_username, and sasl_sender if available.

postfix/RELEASE_NOTES-3.3

@@ -0,0 +1,124 @@
+This is the Postfix 3.3 (stable) release.
+
+The stable Postfix release is called postfix-3.3.x where 3=major
+release number, 3=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-3.4-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 3.1 or earlier, read RELEASE_NOTES-3.2
+before proceeding.
+
+License change
+---------------
+
+This software is distributed with a dual license: in addition to the
+historical IBM Public License 1.0, it is now also distributed with the
+more recent Eclipse Public License 2.0. Recipients can choose to take
+the software under the license of their choice. Those who are more
+comfortable with the IPL can continue with that license.
+
+Major changes - compatibility safety net
+----------------------------------------
+
+[20180106] With compatibility_level < 1, the Postfix SMTP server
+now warns for mail that would be blocked by the Postfix 2.10
+smtpd_relay_restrictions feature, without blocking that mail. This
+extends the compatibility safety net for sites that upgrade from
+earlier Postfix versions (questions on the postfix-users list show
+there is a steady trickle). See COMPATIBILITY_README for details.
+
+Major changes - configuration
+-----------------------------
+
+[20170617] The postconf command now warns about unknown parameter
+names in a Postfix database configuration file. As with other unknown
+parameter names, these warnings can help to find typos early.
+
+[20180113] New read-only service_name parameter that contains the
+master.cf service name of a Postfix daemon process (it that is empty
+in a non-daemon process). This can make Postfix SMTP server logging
+logging distinct by setting the syslog_name in master.cf with "-o
+syslog_name=postfix/$service_name" for the "submission" and "smtps"
+services, and can make Postfix SMTP client distinct by setting "-o
+syslog_name=postfix/$service_name" for the "relay" service.
+
+Major changes - container support
+---------------------------------
+
+[20171218] Preliminary support to run Postfix in the foreground,
+with "postfix start-fg". This requires that Postfix multi-instance
+support is disabled. To receive Postfix syslog information on the
+container's host, mount the host's /dev/log socket inside the
+container (example: "docker run -v /dev/log:/dev/log ..."), and
+specify a distinct Postfix "syslog_name" prefix that identifies the
+logging from the Postfix instance. Postfix does not log systemd
+events.
+
+Major changes - database support
+---------------------------------
+
+[20170617] The postconf command warns about unknown parameter names
+in a Postfix database configuration file.
+
+[20171227] The pgsql_table(5) hosts parameter now supports the
+postgresql:// URI syntax. Contributed by Magosányi Árpád.
+
+Major changes - header format
+-----------------------------
+
+[20180010] This release changes the format of 'full name' information
+in Postfix-generated From: headers, when a local program such as
+/bin/mail submits a message without From: header.
+
+Postfix-generated From: headers with 'full name' information are
+now formatted as "From: name <address>" by default. Specify
+"header_from_format = obsolete" to get the earlier form "From:
+address (name)". See the postconf(5) manpage for more details.
+
+Major changes - invisible changes
+---------------------------------
+
+[20170617] Additional paranoia in the VSTRING implementation: a
+null byte after the end of vstring buffers (this is a safety net
+so that C-style string operations won't scribble past the end);
+earlier detection of bad length and precision format string specifiers
+(these are the result of programming error, as Postfix format strings
+cannot be specified externally).
+
+Major changes - milter support
+------------------------------
+
+[20171223] Milter applications can now send RET and ENVID parameters
+in SMFIR_CHGFROM (change envelope sender) requests.
+
+Major changes - mixed IPv6/IPv4 support
+---------------------------------------
+
+[20170505] Workaround for mail delivery problems when 1) both Postfix
+IPv6 and IPv4 support are enabled, 2) some destination announces
+more primary IPv6 MX addresses than primary IPv4 MX addresses, 3)
+the destination is unreachable over IPv6, and 4) Postfix runs into
+the smtp_mx_address_limit before it can try to deliver over IPv4.
+
+When both Postfix IPv6 and IPv4 support are enabled, the Postfix
+SMTP client will now relax MX preferences so that it can schedule
+similar numbers of IPv4 and IPv6 destination addresses. This ensures
+that an IPv6 connectivity problem will not prevent mail from being
+delivered over IPv4 (and vice versa). Specify "smtp_balance_inet_protocols
+= no" to disable this workaround.
+
+Major changes - xclient
+-----------------------
+
+[20171218] The Postfix SMTP server now allows the XCLIENT command
+before STARTTLS when TLS is required. This is useful for servers
+that run behind a reverse proxy server such as nginx.
+

postfix/RELEASE_NOTES-3.4

@@ -0,0 +1,208 @@
+This is the Postfix 3.4 (stable) release.
+
+The stable Postfix release is called postfix-3.4.x where 3=major
+release number, 4=minor release number, x=patchlevel.  The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-3.5-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day).  Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 3.2 or earlier, read RELEASE_NOTES-3.3
+before proceeding.
+
+License change
+---------------
+
+This software is distributed with a dual license: in addition to the
+historical IBM Public License 1.0, it is now also distributed with the
+more recent Eclipse Public License 2.0. Recipients can choose to take
+the software under the license of their choice. Those who are more
+comfortable with the IPL can continue with that license.
+
+Summary of changes
+------------------
+
+Incompatible changes, bdat support, containers, database support,
+logging, safety, tls connection pooling, tls support, usability,
+
+Incompatible changes
+--------------------
+
+[Incompat 20180826] The Postfix SMTP server announces CHUNKING (BDAT
+command) by default. In the unlikely case that this breaks some
+important remote SMTP client, disable the feature as follows:
+
+/etc/postfix/main.cf:
+    # The logging alternative:
+    smtpd_discard_ehlo_keywords = chunking
+    # The non-logging alternative:
+    smtpd_discard_ehlo_keywords = chunking, silent_discard
+
+See BDAT_README for more.
+
+[Incompat 20190126] This introduces a new master.cf service 'postlog'
+with type 'unix-dgram' that is used by the new postlogd(8) daemon.
+Before backing out to an older Postfix version, edit the master.cf
+file and remove the postlog entry.
+
+[Incompat 20190106] Postfix 3.4 drops support for OpenSSL 1.0.1
+(end-of-life was December 31, 2016) and all earlier releases.
+
+[Incompat 20180701] To avoid performance loss under load, the
+tlsproxy(8) daemon now requires a zero process limit in master.cf
+(this setting is provided with the default master.cf file). By
+default, a tlsproxy(8) process will retire after several hours.
+
+To set the tlsproxy process limit to zero:
+
+# postconf -F tlsproxy/unix/process_limit=0
+# postfix reload
+
+Major changes - bdat support
+--------------------
+
+[Feature 20180826] Postfix SMTP server support for RFC 3030 CHUNKING
+(the BDAT command) without BINARYMIME, in both smtpd(8) and
+postscreen(8). This has no effect on Milters, smtpd_mumble_restrictions,
+and smtpd_proxy_filter. See BDAT_README for more.
+
+Major changes - containers
+--------------------------
+
+[Feature 20190126] Support for logging to file or stdout, instead
+of using syslog.
+
+- Logging to file solves a usability problem for MacOS, and
+  eliminates multiple problems with systemd-based systems.
+
+- Logging to stdout is useful when Postfix runs in a container, as
+  it eliminates a syslogd dependency.
+
+See MAILLOG_README for configuration examples and logfile rotation.
+
+[Feature 20180422] Better handling of undocumented(!) Linux behavior
+whether or not signals are delivered to a PID=1 process.
+
+Major changes - database support
+--------------------------------
+
+[Feature 20181105] Support for (key, list of filenames) in map
+source text.
+
+- Currently, this feature is used only by tls_server_sni_maps.
+
+- When a map is created from source with "postmap -F maptype:mapname",
+  the command processes each key as usual and processes each value
+  as a list of filenames, concatenates the content of those files
+  (with one newline character in-between files), and stores an entry
+  with (key, base64-encoded result).
+
+- When a map is queried with "postmap -F -q ...", the command
+  base64-decodes each value. It reports an error when a value is
+  not in base64 form.
+
+  This "postmap -F -q ..." behavior also works when querying the
+  memory-resident map types cidr:, inline:, pcre:, randmap:, regexp:,
+  and static:. Postfix reads the files specified as table values,
+  stores base64-encoded content, and base64-decodes content upon
+  table lookup.
+
+  Internally, Postfix will turn on this behavior for lookups (not
+  updates) when a map is opened with the DICT_FLAG_RHS_IS_FILE flag.
+
+Major changes - logging
+-----------------------
+
+[Feature 20190126] Support for logging to file or stdout, instead
+of using syslog.
+
+- Logging to file solves a usability problem for MacOS, and
+  eliminates multiple problems with systemd-based systems.
+
+- Logging to stdout is useful when Postfix runs in a container, as
+  it eliminates a syslogd dependency.
+
+See MAILLOG_README for configuration examples and logfile rotation.
+
+Major changes - safety
+----------------------
+
+[Feature 20180623] Automatic retirement: dnsblog(8) and tlsproxy(8) process
+will now voluntarily retire after after max_idle*max_use, or some
+sane limit if either limit is disabled. Without this, a process
+could stay busy for days or more.
+
+Major changes - tls connection pooling
+--------------------------------------
+
+[Feature 20180617] Postfix SMTP client support for multiple deliveries
+per TLS-encrypted connection. This is primarily to improve mail
+delivery performance for destinations that throttle clients when
+they don't combine deliveries.
+
+This feature is enabled with "smtp_tls_connection_reuse=yes" in
+main.cf, or with "tls_connection_reuse=yes" in smtp_tls_policy_maps.
+It supports all Postfix TLS security levels including dane and
+dane-only.
+
+The implementation of TLS connection reuse relies on the same
+scache(8) service as used for delivering plaintext SMTP mail, the
+same tlsproxy(8) daemon as used by the postscreen(8) service for
+inbound connections, and relies on the same hints from the qmgr(8)
+daemon. It reuses the configuration parameters described in
+CONNECTION_CACHE_README.
+
+The Postfix SMTP client now logs whether an SMTP-over-TLS connection
+is newly established ("TLS connection established") or whether the
+connection is reused ("TLS connection reused").
+
+The following illustrates how TLS connections are reused:
+
+    Initial plaintext SMTP handshake:
+      smtp(8) -> remote SMTP server
+
+    Reused SMTP/TLS connection, or new SMTP/TLS connection:
+      smtp(8) -> tlsproxy(8) -> remote SMTP server
+
+    Cached SMTP/TLS connection:
+      scache(8) -> tlsproxy(8) -> remote SMTP server
+
+Major changes - tls support
+---------------------------
+
+[Feature 20190106] SNI support in the Postfix SMTP server, the
+Postfix SMTP client, and in the tlsproxy(8) daemon (both server and
+client roles). See the postconf(5) documentation for the new
+tls_server_sni_maps and smtp_tls_servername parameters.
+
+[Feature 20190106] Support for files that contain multiple (key,
+certificate, trust chain) instances. This was required to implement
+server-side SNI table lookups, but it also eliminates the need for
+separate cert/key files for RSA, DSA, Elliptic Curve, and so on.
+The file format is documented in the TLS_README sections "Server-side
+certificate and private key configuration" and "Client-side certificate
+and private key configuration", and in the postconf(5) documentation
+for the parameters smtp_tls_chain_files, smtpd_tls_chain_files,
+tlsproxy_client_chain_files, and tlsproxy_tls_chain_files.
+
+Note: the command "postfix tls" does not yet support the new
+consolidated certificate chain format.  If you switch to the new
+format, you'll need to manage your keys and certificates directly,
+rather than via postfix-tls(1).
+
+Major changes - usability
+-------------------------
+
+[Feature 20180812] Support for smtpd_reject_footer_maps (as well
+as the postscreen variant postscreen_reject_footer_maps) for more
+informative reject messages. This is indexed with the Postfix SMTP
+server response text, and overrides the footer specified with
+smtpd_reject_footer.  One will want to use a pcre: or regexp: map
+with this.
+

postfix/RELEASE_NOTES-3.5

@@ -0,0 +1,157 @@
+This is the Postfix 3.5 (stable) release.
+
+The stable Postfix release is called postfix-3.5.x where 3=major
+release number, 5=minor release number, x=patchlevel.  The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-3.6-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day).  Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 3.3 or earlier, read RELEASE_NOTES-3.4
+before proceeding.
+
+License change
+---------------
+
+This software is distributed with a dual license: in addition to the
+historical IBM Public License 1.0, it is now also distributed with the
+more recent Eclipse Public License 2.0. Recipients can choose to take
+the software under the license of their choice. Those who are more
+comfortable with the IPL can continue with that license.
+
+Major changes - multiple relayhost in SMTP
+------------------------------------------
+
+[Feature 20200111] the Postfix SMTP and LMTP client support a list
+of nexthop destinations separated by comma or whitespace. These
+destinations will be tried in the specified order.
+
+The list form can be specified in relayhost, transport_maps,
+default_transport, and sender_dependent_default_transport_maps.
+
+Examples:
+/etc/postfix/main.cf:
+    relayhost = foo.example, bar.example
+    default_transport = smtp:foo.example, bar.example.
+
+NOTE: this is an SMTP and LMTP client feature. It does not work for
+other Postfix delivery agents.
+
+Major changes - certificate access
+----------------------------------
+
+[Feature 20190517] Search order support for check_ccert_access.
+Search order support for other tables is in design (canonical_maps,
+virtual_alias_maps, transport_maps, etc.).
+
+The following check_ccert_access setting uses the built-in search
+order: it first looks up the client certificate fingerprint, then
+the client certificate public-key fingerprint, and it stops when a
+decision is made.
+
+/etc/postfix/main.cf:
+    smtpd_mumble_restrictions =
+        ...
+        check_ccert_access hash:/etc/postfix/ccert-access
+        ...
+
+The following setting, with explicit search order, produces the
+exact same result:
+
+/etc/postfix/main.cf:
+    smtpd_mumble_restrictions =
+        ...
+        check_ccert_access {
+            hash:/etc/postfix/ccert-access {
+                search_order = cert_fingerprint, pubkey_fingerprint } }
+        ...
+
+Support is planned for other certificate features.
+
+Major changes - dovecot usability
+---------------------------------
+
+[Feature 20190615] The SMTP+LMTP delivery agent can now prepend
+Delivered-To, X-Original-To and Return-Path headers, just like the
+pipe(8) and local(8) delivery agents. 
+
+This uses the "flags=DORX" command-line flags in master.cf. See the
+smtp(8) manpage for details.
+
+This obsoletes the "lmtp_assume_final = yes" setting, and replaces
+it with "flags=...X...", for consistency with the pipe(8) delivery
+agent.
+
+Major changes - forced expiration
+---------------------------------
+
+[Feature 20200202] Support to force-expire email messages. This
+introduces new postsuper(1) command-line options to request expiration,
+and additional information in mailq(1) or postqueue(1) output.
+
+The forced-to-expire status is stored in a queue file attribute.
+An expired message is returned to the sender when the queue manager
+attempts to deliver that message (note that Postfix will never
+deliver messages in the hold queue).
+
+The postsuper(1) -e and -f options both set the forced-to-expire
+queue file attribute. The difference is that -f will also release
+a message if it is in the hold queue. With -e, such a message would
+not be returned to the sender until it is released with -f or -H.
+
+In the mailq(1) or postqueue(1) -p output, a forced-to-expire message
+is indicated with # after the queue file name. In postqueue(1) JSON
+output, there is a new per-message field "forced_expire" (with value
+true or false) that shows the forced-to-expire status.
+
+Major changes - haproxy2 protocol
+---------------------------------
+
+[Feature 20200112] Support for the haproxy v2 protocol. The Postfix
+implementation supports TCP over IPv4 and IPv6, as well as non-proxied
+connections; the latter are typically used for heartbeat tests.
+
+The haproxy v2 protocol introduces no additional Postfix configuration.
+The Postfix smtpd(8) and postscreen(8) daemons accept both v1 and
+v2 protocol versions.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20191109] Postfix daemon processes now log the from= and
+to= addresses in external (quoted) form in non-debug logging (info,
+warning, etc.).  This means that when an address localpart contains
+spaces or other special characters, the localpart will be quoted,
+for example:
+
+    from=<"name with spaces"@example.com>
+
+Older Postfix versions would log the internal (unquoted) form:
+
+    from=<name with spaces@example.com>
+
+The external and internal forms are identical for the vast majority
+of email addresses that contain no spaces or other special characters
+in the localpart.
+
+Specify "info_log_address_format = internal" for backwards
+compatibility.
+
+The logging in external form is consistent with the address form
+that Postfix 3.2 and later prefer for table lookups. It is therefore
+the more useful form for non-debug logging.
+
+Major changes - IP address normalization
+----------------------------------------
+
+[Incompat 20190427] Postfix now normalizes IP addresses received
+with XCLIENT, XFORWARD, or with the HaProxy protocol, for consistency
+with direct connections to Postfix. This may change the appearance
+of logging, and the way that check_client_access will match subnets
+of an IPv6 address.

postfix/RELEASE_NOTES-3.6

@@ -0,0 +1,277 @@
+This is the Postfix 3.6 (stable) release.
+
+The stable Postfix release is called postfix-3.6.x where 3=major
+release number, 6=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-3.7-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 3.4 or earlier, read RELEASE_NOTES-3.5
+before proceeding.
+
+License change
+---------------
+
+This software is distributed with a dual license: in addition to the
+historical IBM Public License 1.0, it is now also distributed with the
+more recent Eclipse Public License 2.0. Recipients can choose to take
+the software under the license of their choice. Those who are more
+comfortable with the IPL can continue with that license.
+
+Major changes - internal protocol identification
+------------------------------------------------
+
+[Incompat 20200920] Internal protocols have changed. You need to
+"postfix stop" before updating, or before backing out to an earlier
+release, otherwise long-running daemons (pickup, qmgr, verify, tlsproxy,
+postscreen) may fail to communicate with the rest of Postfix, causing
+mail delivery delays until Postfix is restarted.
+
+This change does not affect message files in Postfix queue directories,
+only the communication between running Postfix programs.
+
+With this change, every Postfix internal service, including the postdrop
+command, announces the name of its protocol before doing any other I/O.
+Every Postfix client program, including the Postfix sendmail command,
+will verify that the protocol name matches what it is supposed to be.
+
+The purpose of this change is to produce better error messages, for
+example, when someone configures the discard daemon as a bounce
+service in master.cf, or vice versa.
+
+This change may break third-party programs that implement a
+Postfix-internal protocol such as qpsmtpd. Such programs have never
+been supported. Fortunately, this will be an easy fix: look at the
+first data from the cleanup daemon: if it is a protocol announcement,
+you're talking to Postfix 3.6 or later. That's the only real change.
+
+Major changes - tls
+-------------------
+
+[Incompat 20200705] The minimum supported OpenSSL version is 1.1.1,
+which will reach the end of life by 2023-09-11. Postfix 3.6 is
+expected to reach the end of support in 2025. Until then, Postfix
+will be updated as needed for compatibility with OpenSSL.
+
+The default fingerprint digest has changed from md5 to sha256 (Postfix
+3.6 with compatibility_level >= 3.6). With a lower compatibility_level
+setting, Postfix defaults to using md5, and logs a warning when a Postfix
+configuration specifies no explicit digest type.
+
+Export-grade Diffie-Hellman key exchange is no longer supported,
+and the tlsproxy_tls_dh512_param_file parameter is ignored,
+
+[Feature 20200906] The tlstype.pl helper script by Viktor Dukhovni
+reports TLS information per message delivery. This processes output
+from the collate.pl script. See auxiliary/collate/README.tlstype and
+auxiliary/collate/tlstype.pl.
+
+Major changes - compatibility level
+-----------------------------------
+
+[Feature 20210109] Starting with Postfix version 3.6, the compatibility
+level is "3.6". In future Postfix releases, the compatibility level will
+be the Postfix version that introduced the last incompatible change. The
+level is formatted as 'major.minor.patch', where 'patch' is usually
+omitted and defaults to zero. Earlier compatibility levels are 0, 1 and 2.
+
+This also introduces main.cf and master.cf support for the <=level,
+<level, and other operators to compare compatibility levels. With the
+standard <=, <, etc. operators, compatibility level 3.10 would be less
+than 3.9, which is undesirable.
+
+Major changes - services(5) override
+------------------------------------
+
+[Feature 20210418] Postfix no longer uses the services(5) database
+to look up the TCP ports for SMTP and LMTP services. Instead, this
+information is configured with the new known_tcp_ports configuration
+parameter (default: lmtp=24, smtp=25, smtps=submissions=465,
+submission=587). When a service is not specified in known_tcp_ports,
+Postfix will still query the services(5) database.
+
+Major changes - local_login_sender_maps
+---------------------------------------
+
+[Feature 20201025] Fine-grained control over the envelope sender address
+for submission with the Postfix sendmail (or postdrop) commands.
+
+The local_login_sender_maps parameter (default: static:*) specifies
+a list of lookup tables that are searched by the UNIX login name, and
+that return a list of allowed envelope sender patterns separated by
+space or comma. The default is backwards-compatible: every user may
+specify any sender envelope address.
+
+This feature is enforced by the postdrop command. When no UNIX login
+name is available, the postdrop command will prepend "uid:" to the
+numerical UID and use that instead.
+
+This feature ignores address extensions in the user-specified
+envelope sender address.
+
+Besides the special pattern "*" which allows any sender address,
+there are "<>" which matches an empty sender address, and the
+"@domain" wildcard pattern. More information about those can be found
+in the postconf(5) manpage.
+
+Example:
+
+/etc/postfix/main.cf:
+    # Allow root and postfix full control, anyone else can only
+    # send mail as themselves. Use "uid:" followed by the numerical
+    # UID when the UID has no entry in the UNIX password file.
+    local_login_sender_maps =
+        inline:{ { root = *}, { postfix = * } },
+        pcre:/etc/postfix/login_senders
+
+/etc/postfix/login_senders:
+   # Allow both the bare username and the user@domain forms.
+    /(.+)/ $1 $1@example.com
+
+Major changes - order of relay and recipient restrictions
+---------------------------------------------------------
+
+[Incompat 20210131] With smtpd_relay_before_recipient_restrictions=yes,
+the Postfix SMTP server will evaluate smtpd_relay_restrictions before
+smtpd_recipient_restrictions. This is the default behavior with
+compatibility_level >= 3.6.
+
+This change makes the implemented behavior consistent with existing
+documentation. There is a backwards-compatibility warning that allows
+users to freeze historical behavior. See COMPATIBILITY_README for
+details.
+
+Major changes - respectful logging
+----------------------------------
+
+[Feature 20210220] Postfix version 3.6 deprecates terminology
+that implies white is better than black. Instead, Postfix prefers
+'allowlist', 'denylist', and variations on those words. This change
+affects Postfix documentation, and postscreen parameters and logging.
+
+To keep the old postscreen logging set "respectful_logging = no"
+in main.cf.
+
+Noel Jones assisted with the initial transition.
+
+Changes in documentation
+------------------------
+
+Postfix documentation was updated to use 'allowlist', 'denylist', etc.
+These documentation changes do not affect Postfix behavior.
+
+Changes in parameter names
+--------------------------
+
+The following postscreen parameters replace names that contain 'blacklist'
+or 'whitelist':
+
+    postscreen_allowlist_interfaces
+    postscreen_denylist_action
+    postscreen_dnsbl_allowlist_threshold
+
+These new parameters have backwards-compatible default settings
+that support the old parameter names, so that the name change should
+not affect Postfix behavior. This means that existing management tools
+that use the old parameter names should keep working as before.
+
+This compatibility safety net may break when some management tools
+use the new parameter names, and some use the old names, such that
+different tools will disagree on how Postfix works.
+
+Changes in logging
+------------------
+
+The following logging replaces forms that contain 'blacklist' or
+'whitelist':
+
+    postfix/postscreen[pid]: ALLOWLIST VETO [address]:port
+    postfix/postscreen[pid]: ALLOWLISTED [address]:port
+    postfix/postscreen[pid]: DENYLISTED [address]:port
+
+To avoid breaking logfile analysis tools, Postfix keeps logging the old
+forms by default, as long as the compatibility_level parameter setting
+is less than 3.6, and the respectful_logging parameter is not explicitly
+configured. As a reminder, Postfix will log the following:
+
+    postfix/postscreen[pid]: Using backwards-compatible default setting
+        respectful_logging=no for client [address]:port
+
+To keep logging the old form, make the setting "respectful_logging =
+no" permanent in main.cf, for example:
+
+    # postconf "respectful_logging = no"
+    # postfix reload
+
+To stop the reminder, configure the respectful_logging parameter to
+"yes" or "no", or configure "compatibility_level = 3.6".
+
+Major changes - threaded bounces
+--------------------------------
+
+[Feature 20201205] Support for threaded bounces. This allows mail
+readers to present a non-delivery, delayed delivery, or successful
+delivery notification in the same email thread as the original
+message.
+
+Unfortunately, this also makes it easy for users to mistakenly delete
+the whole email thread (all related messages), instead of deleting
+only the delivery status notification.
+
+To enable, specify "enable_threaded_bounces = yes".
+
+Other changes - smtpd_sasl_mechanism_list
+-----------------------------------------
+
+[Feature 20200906] The smtpd_sasl_mechanism_list parameter (default:
+!external, static:rest) prevents confusing errors when a SASL backend
+announces EXTERNAL support which Postfix does not support.
+
+Other changes - delivery logging
+--------------------------------
+
+[Incompat 20200531] Postfix delivery agents now log an explicit record
+when delegating delivery to a different Postfix delivery agent.
+
+For example, with "best_mx_transport = local", an SMTP delivery
+agent will now log when a recipient will be delivered locally. This
+makes the delegating delivery agent visible, where it would otherwise
+have remained invisible, which would complicate troubleshooting.
+
+  postfix/smtp[pid]: queueid: passing <recipient> to transport=local
+
+This will usually be followed by logging for an actual delivery:
+
+  postfix/local[pid]: queueid: to=<recipient>, relay=local, ...
+
+Other examples: the local delivery agent will log a record that it
+defers mailbox delivery through mailbox_transport or through
+fallback_transport.
+
+Other changes - error logging
+-----------------------------
+
+[Incompat 20200531] Postfix programs will now log "Application error"
+instead of "Success" or "Unknown error: 0" when an operation fails with
+errno == 0, i.e., the error originates from non-kernel code.
+
+Other changes - dns lookups
+---------------------------
+
+[Feature 20200509] The threadsafe resolver API (res_nxxx() calls)
+is now the default, not because the API is threadsafe, but because
+this is the API where new features are being added.
+
+To build old style, build with:
+
+    make makefiles CCARGS="-DNO_RES_NCALLS..."
+
+This is the default for systems that are known not to support the
+threadsafe resolver API.

postfix/RELEASE_NOTES-3.7

@@ -0,0 +1,179 @@
+This is the Postfix 3.7 (stable) release.
+
+The stable Postfix release is called postfix-3.7.x where 3=major
+release number, 7=minor release number, x=patchlevel.  The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-3.8-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day).  Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 3.5 or earlier, read RELEASE_NOTES-3.6
+before proceeding.
+
+License change
+---------------
+
+This software is distributed with a dual license: in addition to the
+historical IBM Public License 1.0, it is now also distributed with the
+more recent Eclipse Public License 2.0. Recipients can choose to take
+the software under the license of their choice. Those who are more
+comfortable with the IPL can continue with that license.
+
+Major changes - configuration
+-----------------------------
+
+[Feature 20210605] Support to inline the content of small cidr:,
+pcre:, and regexp: tables in Postfix parameter values.
+
+Example:
+
+    smtpd_forbidden_commands =
+	CONNECT GET POST regexp:{{/^[^A-Z]/ Thrash}}
+
+This is the new smtpd_forbidden_commands default value. It will
+immediately disconnect a remote SMTP client when a command does not
+start with a letter (a-z or A-Z).
+
+The basic syntax is:
+
+/etc/postfix/main.cf:
+    parameter = .. map-type:{ { rule-1 }, { rule-2 } .. } ..
+
+/etc/postfix/master.cf:
+    .. -o { parameter = .. map-type:{ { rule-1 }, { rule-2 } .. } .. } ..
+
+where map-type is one of cidr, pcre, or regexp.
+
+Postfix ignores whitespace after '{' and before '}', and writes each
+rule as one text line to a nameless in-memory file: 
+
+in-memory file:
+    rule-1
+    rule-2
+    ..
+
+Postfix parses the result as if it is a file in /etc/postfix.
+
+Note: if a rule contains $, specify $$ to keep Postfix from trying
+to do $name expansion as it evaluates the parameter value.
+
+Major changes - lmdb support
+----------------------------
+
+[Feature 20210605] Overhauled the LMDB client's error handling, and
+added integration tests for future-proofing. There are no visible
+changes in documented behavior.
+
+Major changes - logging
+-----------------------
+
+[Feature 20210815] To make the maillog_file feature more useful,
+the postlog(1) command is now set-gid postdrop, so that unprivileged
+programs can use it to write logging through the postlogd(8) daemon.
+This required hardening the postlog(1) command against privilege
+escalation attacks. DO NOT turn on the set-gid bit with older
+postlog(1) implementations.
+
+Major changes - pcre2 support
+-----------------------------
+
+[Feature 20211127] Support for the pcre2 library (the legacy pcre
+library is no longer maintained). The Postfix build procedure
+automatically detects if the pcre2 library is installed, and if it
+is unavailable, the Postfix build procedure will detect if the
+legacy pcre library is installed. See PCRE_README if you need to
+build Postfix with a specific library.
+
+Visible differences: some error messages may have a different text,
+and the 'X' pattern flag is no longer supported with pcre2.
+
+Major changes - security
+------------------------
+
+[Feature 20220102] Postfix programs now randomize the initial state
+of in-memory hash tables, to defend against hash collision attacks
+involving a large number of attacker-chosen lookup keys. Presently,
+the only known opportunity for such attacks involves remote SMTP
+client IPv6 addresses in the anvil(8) service. The attack would
+require making hundreds of short-lived connections per second from
+thousands of different IP addresses, because the anvil(8) service
+drops inactive counters after 100s. Other in-memory hash tables
+with attacker-chosen lookup keys are by design limited in size. The
+fix is cheap, and therefore implemented for all Postfix in-memory
+hash tables. Problem reported by Pascal Junod.
+
+[Feature 20211030] The postqueue command now sanitizes non-printable
+characters (such as newlines) in strings before they are formatted
+as json or as legacy output. These outputs are piped into other
+programs that are run by administrative users. This closes a
+hypothetical opportunity for privilege escalation.
+
+[Feature 20210815] Updated defense against remote clients or servers
+that 'trickle' SMTP or LMTP traffic, based on per-request deadlines
+and minimum data rates.
+
+Per-request deadlines:
+
+The new {smtpd,smtp,lmtp}_per_request_deadline parameters replace
+{smtpd,smtp,lmtp}_per_record_deadline, with backwards compatible
+default settings. This defense is enabled by default in the Postfix
+SMTP server in case of overload.
+
+The new smtpd_per_record_deadline parameter limits the combined
+time for the Postfix SMTP server to receive a request and to send
+a response, while the new {smtp,lmtp}_per_record_deadline parameters
+limit the combined time for the Postfix SMTP or LMTP client to send
+a request and to receive a response.
+
+Minimum data rates:
+
+The new smtpd_min_data_rate parameter enforces a minimum plaintext
+data transfer rate for DATA and BDAT requests, but only when
+smtpd_per_record_deadline is enabled. After a read operation transfers
+N plaintext bytes (possibly after TLS decryption), and after the
+DATA or BDAT request deadline is decreased by the elapsed time of
+that read operation, the DATA or BDAT request deadline is increased
+by N/smtpd_min_data_rate seconds. However, the deadline is never
+increased beyond the smtpd_timeout value. The default minimum data
+rate is 500 (bytes/second) but is still subject to change.
+
+The new {smtp,lmtp}_min_data_rate parameters enforce the corresponding
+minimum DATA transfer rates for the Postfix SMTP and LMTP client.
+
+Major changes - tls support
+---------------------------
+
+[Cleanup 20220121] The new tlsproxy_client_security_level parameter
+replaces tlsproxy_client_level, and the new tlsproxy_client_policy_maps
+parameter replaces tlsproxy_client_policy. This is for consistent
+parameter naming (tlsproxy_client_xxx corresponds to smtp_tls_xxx).
+This change was made with backwards-compatible default settings.
+
+[Feature 20210926] Postfix was updated to support OpenSSL 3.0.0 API
+features, and to work around OpenSSL 3.0.0 bit-rot (avoid using
+deprecated API features).
+
+Other code health
+-----------------
+
+[typos] Typo fixes by raf.
+
+[pre-release checks] Added pre-release checks to detect a) new typos
+in documentation and source-code comments, b) missing entries in
+the postfix-files file (some documentation would not be installed),
+c) missing rules in the postlink script (some text would not have
+a hyperlink in documentation), and d) missing map-based $parameter
+names in the proxy_read_maps default value (the proxymap daemon
+would not automatically authorize some proxied maps).
+
+[memory stream] Improved support for memory-based streams made it
+possible to inline small cidr:, pcre:, and regexp: maps in Postfix
+parameter values, and to eliminate some ad-hoc code that converted
+tlsproxy(8) protocol data to or from serialized form.
+

postfix/RELEASE_NOTES-3.8

@@ -0,0 +1,128 @@
+This is the Postfix 3.8 stable release.
+
+The stable Postfix release is called postfix-3.8.x where 3=major
+release number, 8=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-3.9-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 3.6 or earlier, please read RELEASE_NOTES-3.7
+before proceeding.
+
+Dual license
+------------
+
+As of Postfix 3.2.5 this software is distributed with a dual license:
+in addition to the historical IBM Public License (IPL) 1.0, it is
+now also distributed with the more recent Eclipse Public License
+(EPL) 2.0. Recipients can choose to take the software under the
+license of their choice. Those who are more comfortable with the
+IPL can continue with that license.
+
+Major changes - documentation and code cleanup
+----------------------------------------------
+
+There are numerous small fixes to Postfix documentation, and small
+code-health changes that should not affect documented behavior but
+may improve Postfix behavior for malformed input, or that make
+Postfix easier to maintain. See the HISTORY file for details.
+
+Major changes - SRV support
+---------------------------
+
+[Feature 20230214] Support to look up DNS SRV records in the Postfix
+SMTP/LMTP client, Based on code by Tomas Korbar (Red Hat).
+
+For example, with "use_srv_lookup = submission" and "relayhost =
+example.com:submission", the Postfix SMTP client will look up DNS
+SRV records for _submission._tcp.example.com, and will relay email
+through the hosts and ports that are specified with those records.
+
+See https://www.postfix.org/postconf.5.html#use_srv_lookup for more
+details, including how to selectively use SRV in a configuration
+that connects to multiple ISP accounts.
+
+SRV support may also be useful inside a cloud-based infrastructure
+when Postfix needs to deliver mail to services that run on a
+dynamically-allocated port.
+
+Major changes - TLS support
+---------------------------
+
+[Incompat 20230304] This introduces the following changes:
+
+- Postfix treats the "export" and "low" cipher grade settings as
+  "medium". The  "export" and "low" grades are no longer supported
+  in OpenSSL 1.1.1, the minimum version that Postfix requires.
+
+- Postfix default settings now exclude the following deprecated or
+  unused ciphers (SEED, IDEA, 3DES, RC2, RC4, RC5), digest (MD5),
+  key exchange algorithms (DH, ECDH), and public key algorithm
+  (DSS).
+
+[Feature 20230108] New configuration parameter tls_ffdhe_auto_groups
+for finite-field Diffie-Hellman ephemeral (FFDHE) support in TLS
+1.3 with OpenSSL 3.0.
+
+Major changes - attack resistance
+---------------------------------
+
+[Feature 20240312] the Postfix SMTP server can now aggregate
+smtpd_client_*_rate and smtpd_client_*_count statistics by network
+block, as specified with smtpd_client_ipv4_prefix_length (default
+32, no aggregation) and smtpd_client_ipv6_prefix_length (default
+84, aggregation by /84 network blocks). The latter raises the bar
+for a memory exhaustion attack.
+
+[Feature 20221023] Unconditionally disable a CPU resource attack
+requesting TLS renegotiation. There's no good reason to support
+this in the middle of an SMTP connection.
+
+Major changes - bit rot
+-----------------------
+
+[Incompat 20221228] Postfix documentation and code have been converted
+to use "grep -E" and "grep -F" instead of the historical forms
+"egrep" and "fgrep". To build Postfix on a system that supports
+only the historical forms, run the script auxiliary/fix-grep/fix-grep.sh
+to revert this change.
+
+Major changes - configuration checks
+------------------------------------
+
+[Feature 20240406] The postconf command now warns for #comment in
+or after a Postfix parameter value. Postfix programs do not support
+#comment after other text, and treat that as input.
+
+Major changes - database support
+--------------------------------
+
+[Incompat 20220509] The PostgreSQL client encoding is now configurable
+with the "encoding" Postfix configuration file attribute. The default
+is "UTF8". Previously the encoding was hard-coded as "LATIN1".
+
+Major changes - logging
+-----------------------
+
+[Incompat 20230308] The postfix(1) and postlog(1) commands now
+produce stderr logging even when stderr is not connected to a
+terminal. This eliminates an inconsistency, and makes these programs
+easier to use in some automated procedures. The canonical example
+is to capture output from "postmulti -p status" to figure out which
+instances are or are not running.
+
+Major changes - source code organization
+----------------------------------------
+
+[Incompat 20220507] Most global/mkmap*.[hc] files are moved to the
+util directory; only global/mkmap_proxy.* remains. The old file
+organization was designed before support for dynamically-loadable
+databases was added, and that code suffered from complexity.
+

postfix/RELEASE_NOTES-3.9

@@ -0,0 +1,309 @@
+This is the Postfix 3.9 stable release.
+
+The stable Postfix release is called postfix-3.9.x where 3=major
+release number, 9=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-3.10-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 3.7 or earlier, please read RELEASE_NOTES-3.8
+before proceeding.
+
+Dual license
+------------
+
+As of Postfix 3.2.5 this software is distributed with a dual license:
+in addition to the historical IBM Public License (IPL) 1.0, it is
+now also distributed with the more recent Eclipse Public License
+(EPL) 2.0. Recipients can choose to take the software under the
+license of their choice. Those who are more comfortable with the
+IPL can continue with that license.
+
+Topics in this document
+-----------------------
+- changes that are less visible
+- database support
+- envid support
+- feature deprecation
+- mime conversion
+- protocol compliance
+- security
+- tls support
+
+Changes that are less visible
+-----------------------------
+
+The documentation has been updated to address many questions
+that were asked on the postfix-users mailing list.
+
+More unit tests to make Postfix future-proof. Wietse is now looking
+into migrating unit tests to Google test, because other people are
+familiar with that framework, than with a Postfix-specific one.
+
+Major changes - database support
+--------------------------------
+
+[Feature 20240208] MongoDB client support, contributed by Hamid
+Maadani, based on earlier code by Stephan Ferraro. For build and
+usage instructions see MONGODB_README and mongodb_table(5).
+
+[Feature 20240129] In the mysql: and pgsql: clients, the hard-coded
+idle and retry timer settings are now configurable. Details are in
+the updated mysql_table(5) and pgsql_table(5) manpages.
+
+[Incompat 20230903] The MySQL client no longer supports MySQL
+versions < 4.0. MySQL version 4.0 was released in 2003.
+
+[Incompat 20230419] The MySQL client default characterset is now
+configurable with the "charset" configuration file attribute. The
+default is "utf8mb4", consistent with the MySQL 8.0 built-in default,
+but different from earlier MySQL versions where the built-in default
+was "latin1".
+
+Major changes - envid support
+-----------------------------
+
+[Feature 20230901] The local(8) delivery agent exports an ENVID
+environment variable with the RFC 3461 envelope ID if available.
+
+The pipe(8) delivery agent supports an ${envid} command-line attribute
+that expands to the RFC 3461 envelope ID if available.
+
+Major changes - feature deprecation
+-----------------------------------
+
+[Incompat 20240218] The new document DEPRECATION_README covers
+features that have been removed and that will be removed in the
+future, with suggestions how to migrate.
+
+The Postfix SMTP server logs a warning when "permit_mx_backup" is
+used (support for restriction "permit_mx_backup" will be removed
+from Postfix; instead, use "relay_domains"). File: smtpd/smtpd_check.c.
+
+The postconf command logs a warning when the following parameters
+are specified in main.cf or master.cf: xxx_use_tls, xxx_enforce_tls
+(use the corresponding xxx_security_level setting instead);
+xxx_per_site (use the corresponding xxx_policy_maps setting instead);
+disable_dns_lookups (use smtp_dns_support_level instead);
+smtpd_tls_dh1024_param_file, smtpd_tls_eecdh_grade (do not specify,
+leave at default). These warning are silenced with the "postconf
+-q".
+
+[Incompat 20240218] The Postfix SMTP server now logs that
+permit_naked_ip_address, reject_maps_rbl, and check_relay_domains
+have been removed and suggests a replacement. These features have
+been logging deprecation warnings since 2005 or earlier, and were
+removed from Postfix documentation in 2004.
+
+Major changes - mime conversion
+-------------------------------
+
+[Feature 20230901] New parameter force_mime_input_conversion (default:
+no) to convert body content that claims to be 8-bit into quoted-printable,
+before header_checks, body_checks, Milters, and before after-queue
+content filters. This feature does not affect messages that are
+sent into smtpd_proxy_filter.
+
+The typical use case is an MTA that applies this conversion before
+signing outbound messages, so that the signatures will remain valid
+when a message is later handled by an MTA that does not announce
+8BITMIME support, or when a message line exceeds the SMTP length
+limit.
+
+Major changes - protocol compliance
+-----------------------------------
+
+[Incompat 20240206] In message headers, Postfix now formats numerical
+days as two-digit days, i.e. days 1-9 have a leading zero instead
+of a leading space.  This change was made because the RFC 5322 date
+and time specification recommends (i.e. SHOULD) that a single space
+be used in each place that FWS appears. This change avoids a breaking
+change in the date string length.
+
+Major changes - security
+------------------------
+
+[Incompat 20240226] The Postfix DNS client now limits the total
+size of DNS lookup results to 100 records; it drops the excess
+records, and logs a warning. This limit is 20x larger than the
+number of server addresses that the Postfix SMTP client is willing
+to consider when delivering mail, and is far below the number of
+records that could cause a tail recursion crash in dns_rr_append()
+as reported by Toshifumi Sakaguchi.
+
+This change introduces a similar limit on the number of DNS requests
+that a check_*_*_access restriction can make.
+
+[Incompat 20240110] With "cleanup_replace_stray_cr_lf = yes" (the
+default), the cleanup daemon replaces each stray <CR> or <LF>
+character in message content with a space character. The replacement
+happens before any other content management (header/body_checks,
+Milters, etc).
+
+This prevents outbound SMTP smuggling, where an attacker uses Postfix
+to send email containing a non-standard End-of-DATA sequence, to
+exploit inbound SMTP smuggling at a vulnerable remote SMTP server.
+
+This also improves the remote evaluation of Postfix-added DKIM and
+other signatures, as the evaluation result will not depend on how
+a remote email server handles stray <CR> or <LF> characters.
+
+This feature applies to all email that Postfix locally or remotely
+sends out. It is not allowlisted based on client identity.
+
+[Feature 20240118] This updates Postfix fixes for inbound SMTP smuggling
+attacks. For background, see https://www.postfix.org/smtp-smuggling.html
+
+This will be back ported to Postfix 3.8.5, 3.7.10, 3.6.14, and 3.5.24.
+
+- Better compatibility: the recommended setting "smtpd_forbid_bare_newline
+  = normalize" requires the standard End-of-DATA sequence
+  <CR><LF>.<CR><LF>, but allows bare newlines from SMTP clients,
+  maintaining more compatibility with existing infrastructure.
+
+- Improved logging for rejected input (it now includes queue ID,
+  helo, mail, and rcpt, if available).
+
+- The setting "smtpd_forbid_bare_newline = reject" requires
+  that input lines end in <CR><LF>, requires the standard End-of-DATA
+  sequence <CR><LF>.<CR><LF>, and rejects a command or message that
+  contains a bare newline. To disconnect the client, specify
+  "smtpd_forbid_bare_newline_reject_code = 521".
+
+- The Postfix SMTP server no longer strips extra <CR> as in
+  <CR><LF>.<CR><CR><LF>, to silence false alarms from test tools
+  that send attack sequences that real mail servers cannot send.
+  Details at https://www.postfix.org/false-smuggling-claims.html
+
+- The old setting "yes" has become an alias for "normalize".
+
+- The old setting "no" has not changed, and allows SMTP smuggling.
+
+The recommended settings are now:
+
+    # Require the standard End-of-DATA sequence <CR><LF>.<CR><LF>.
+    # Otherwise, allow bare <LF> and process it as if the client sent
+    # <CR><LF>.
+    #
+    # This maintains compatibility with many legitimate SMTP client
+    # applications that send a mix of standard and non-standard line
+    # endings, but will fail to receive email from client implementations
+    # that do not terminate DATA content with the standard End-of-DATA
+    # sequence <CR><LF>.<CR><LF>.
+    #
+    # Such clients can be allowlisted with smtpd_forbid_bare_newline_exclusions.
+    # The example below allowlists SMTP clients in trusted networks.
+    #
+    smtpd_forbid_bare_newline = normalize
+    smtpd_forbid_bare_newline_exclusions = $mynetworks
+
+Alternative settings:
+
+    # Reject input lines that contain <LF> and log a "bare <LF> received"
+    # error. Require that input lines end in <CR><LF>, and require the
+    # standard End-of-DATA sequence <CR><LF>.<CR><LF>.
+    #
+    # This will reject email from SMTP clients that send any non-standard
+    # line endings such as web applications, netcat, or load balancer
+    # health checks.
+    #
+    # This will also reject email from services that use BDAT to send
+    # MIME text containing a bare newline (RFC 3030 Section 3 requires
+    # canonical MIME format for text message types, defined in RFC 2045
+    # Sections 2.7 and 2.8).
+    #
+    # Such clients can be allowlisted with smtpd_forbid_bare_newline_exclusions.
+    # The example below allowlists SMTP clients in trusted networks.
+    #
+    smtpd_forbid_bare_newline = reject
+    smtpd_forbid_bare_newline_exclusions = $mynetworks
+    #
+    # Alternatively, in the case of BDAT violations, BDAT can be selectively
+    # disabled with smtpd_discard_ehlo_keyword_address_maps, or globally
+    # disabled with smtpd_discard_ehlo_keywords.
+    #
+    # smtpd_discard_ehlo_keyword_address_maps = cidr:/path/to/file
+    # /path/to/file:
+    #     10.0.0.0/24 chunking, silent-discard
+    # smtpd_discard_ehlo_keywords = chunking, silent-discard
+
+[Incompat 20230603] the Postfix SMTP server by default disconnects
+remote SMTP clients that violate RFC 2920 (or 5321) command pipelining
+constraints. The server replies with "554 5.5.0 Error: SMTP protocol
+synchronization" and logs the unexpected remote SMTP client input.
+Specify "smtpd_reject_unauth_pipelining = no" to disable.
+
+Major changes - tls support
+---------------------------
+
+[Feature 20230807] Optional Postfix TLS support to request an RFC7250
+raw public key instead of an X.509 public-key certificate. The
+configuration settings for raw key public support will be ignored
+when there is no raw public key support in the local TLS implementation
+(i.e.  Postfix with OpenSSL versions before 3.2).
+
+- With "smtpd_tls_enable_rpk = yes", the Postfix SMTP server will
+  request that a remote SMTP client sends an RFC7250 raw public key
+  instead of an X.509 certificate when asking for or requiring TLS
+  client authentication. The Postfix SMTP server will still accept
+  a client public-key certificate instead of a public key.
+
+- With "smtp_tls_enable_rpk = yes" (or "enable_rpk = yes" in an
+  smtp policy table) at the security levels "may", "encrypt" or
+  "fingerprint", the Postfix SMTP client will request that a remote
+  SMTP server sends an RFC7250 raw public key instead of an X.509
+  certificate. The Postfix SMTP client will still accept a server
+  public key certificate instead of a public key.
+
+- At the "secure" and "verify" security level, the Postfix SMTP
+  client will ignore smtp_tls_enable_rpk or enable_rpk settings,
+  because these levels require a server certificate.
+
+- At the "dane" and "dane-only" security levels, the Postfix SMTP
+  client will ignore smtp_tls_enable_rpk or enable_rpk settings,
+  and will request that a remote SMTP server sends an RFC7250 raw
+  public key instead of an X.509 certificate when all valid TLSA
+  records specify only server public keys (no certificates). The
+  Postfix SMTP client will still accept a server public key
+  certificate.
+
+- The Postfix SMTP client and server always send a raw public key
+  instead of a certificate, if solicited by the remote SMTP peer
+  and the local TLS implementation supports raw public keys.
+
+- If a remote SMTP client sends a server name indication with an
+  SNI TLS extension, and tls_server_sni_maps is configured, the
+  Postfix SMTP server will extract a raw public key from the indicated
+  certificate.
+
+Caution: enabling Postfix raw key support will break authentication
+based on certificate fingerprints in check_ccert_access or
+smtp_tls_policy_maps, when a remote peer's TLS implementation starts
+to send a raw public key instead of a certificate. The solution is
+to always use public key fingerprint patterns; these will match not
+only a "raw" public key, but also the public key in a certificate.
+
+To detect such problems before they happen, the Postfix SMTP server
+will log a warning when it requests an RFC7250 raw public key instead
+of an X.509 certificate, the remote peer sends a certificate instead
+of a public key, and check_ccert_access has a matching fingerprint
+for the certificate but not for the public key in that certificate.
+There is no corresponding warning from the Postfix SMTP client.
+
+For instructions to generate public-key fingerprints, see the
+postconf(5) man pages for smtp_tls_enable_rpk and smtpd_tls_enable_rpk.
+
+[Feature 20230522] Preliminary support for OpenSSL configuration
+files, primarily OpenSSL 1.1.1b and later. This introduces two new
+parameters "tls_config_file" and "tls_config_name", which can be
+used to limit collateral damage from OS distributions that crank
+up security to 11, increasing the number of plaintext email deliveries.
+Details are in the postconf(5) manpage under "tls_config_file" and
+"tls_config_name".

postfix/TLS_ACKNOWLEDGEMENTS

@@ -1,5 +1,5 @@
 - Walcir Fontanini <walcir@densis.fee.unicamp.br>
-  * tested on Solaris 2.5 and and reported missing "snprintf()"
+  * tested on Solaris 2.5 and reported missing "snprintf()"
     -> was fixed in pfixtls-0.1.2
   * contributed the script to add fingerprints
 	contributed/fp.csh

postfix/TLS_CHANGES

@@ -1940,7 +1940,7 @@
   - Updated configuration information:
     * As of OpenSSL 0.9.4, certificate chain verification is not sufficient,
       since the certificate purpose is not checked, so I recommend to add
-      all intermediate CAs the the list of CAs and stay with a verification
+      all intermediate CAs the list of CAs and stay with a verification
       depth of 1.
       Work is in progress for 0.9.5.
   - Stepped up to the just released new patchlevel postfix-19990906-pl09.
@@ -2070,7 +2070,7 @@
 
 1999/10/09
   - Set an absolut maximum length of 32 for the IDs used for session caching.
-    This matches the default in OpenSSL, but I don´t want to see surprises
+    This matches the default in OpenSSL, but I don't want to see surprises
     when somebody sometimes will run into a longer session id.
 
 1999/10/05	== Released 0.4.0 ==
@@ -2107,11 +2107,11 @@
     to computer sience students.
 
 1999/09/28
-  - I cannot use the mod_ssl way for session caching and I don´t want to
-    spend an extra "gcache" daemon as ApacheSSL does. So I follow Wietse´s
+  - I cannot use the mod_ssl way for session caching and I don't want to
+    spend an extra "gcache" daemon as ApacheSSL does. So I follow Wietse's
     idea realized for his mail queues and create hash level based subdirectory
     structures. The good thing: I can cannibalize the mail_queue code.
-    The bad thing: there is a path length of 100 chars fix coded in Wietse´s
+    The bad thing: there is a path length of 100 chars fix coded in Wietse's
     routines. It does hold for 32byte session ideas.
     Status: can save sessions to disk and recall them (server side).
 
@@ -2119,8 +2119,8 @@
   - Created new call backs for external session caching for the server side.
     In a first step, they can print out the session ids for the newly created
     session and when recalling a session.
-    As the OpenSSL documentation on this is pretty sparse, Ben Laurie´s
-    ApacheSSL code is very helpful, Ralph Engelschall´s Mod_SSL code for
+    As the OpenSSL documentation on this is pretty sparse, Ben Laurie's
+    ApacheSSL code is very helpful, Ralph Engelschall's Mod_SSL code for
     session caching is far more complicated.
 
 1999/09/23	== Released 0.3.10 ==
@@ -2146,7 +2146,7 @@
     SSL_CTX_set_session_id_context() call was missing. To find this, I
     had to trace through the OpenSSL library and when I finally found it
     in ssl/ssl_sess.c, there was an appropriate comment about this. I however
-    have to find out why I didn´t receive the appropriate error message...
+    have to find out why I didn't receive the appropriate error message...
   - This bug was hidden during the first developing stages, as the shutdown
     sequence was not working correct, so the session was not cached.
 
@@ -2181,7 +2181,7 @@
 1999/09/09	== Released 0.3.6 ==
 
 1999/09/09
-  - Added a missing ´#ifdef HAS_SSL #endif´ in smtp_connect.c.
+  - Added a missing '#ifdef HAS_SSL #endif' in smtp_connect.c.
     Noted by Jeff Johnson <jeff@websitefactory.net>.
   - HINT:
     On 1999/09/06 a new "stable" version of postfix was released.
@@ -2357,7 +2357,7 @@
 1999/04/14
   - Ported from OpenSSL the BIO_callback functions to dump out the negotiation
     and transmission for debugging purposes. The functions are triggered
-    by the the new loglevels 3 and 4.
+    by the new loglevels 3 and 4.
   - Call SSL_free() to get rid of the SSL connection structure not used
     anymore.
 

postfix/US_PATENT_6321267

@@ -1,3 +1,8 @@
+[The patent discussed in this document expired in 2019, without a
+request for extension. The owner of that patent can no longer sue for
+infringement. However, other patents may make similar claims. The text
+below may serve as an example for dealing with them.]
+
 1. Disclaimer: This text is not an authoritative statement.  If
 you are concerned about the implications of US patent 6,321,267,
 then you should give this text to your own lawyer and get their

postfix/WISHLIST

@@ -2,11 +2,381 @@ Wish list:
 
 	Things to do before the stable release:
 
-	Spell-check, double-word check, and HTML validator check.
+	For the stable releases, make the spawn_command fix conditional
+	on compatibility_level.
+
+	make pre-release-check, HTML validator check.
 
 	Disable -DSNAPSHOT and -DNONPROD in makedefs.
 
-	Add $smtpd_sender_login_maps to proxy_read_maps.
+	Add a mail_version chek to each pluggable database client.
+
+	Unify conf/postfix-wrapper and proto/postfix-wrapper (make
+	one a dependency of the other). They have diverged.
+
+	Should the SMTP client log the queue ID with the TLS status?
+
+	relay_recipient_maps empty should default to 'no valid
+	recipients'. Subject to compatibility level.
+
+	Replace static result buffers with per-instance buffers in
+	dict_unix.c, dict_ni*c.
+
+	The Milter 'quarantine' action should be reported with a
+	call-back function, instead of setting the Milter default
+	reply. However, we still need the existing 'reply' based
+	channel to support "milter_default_action = quarantine".
+
+	In pipe_command() and spawn_command(), the child process
+	should call initgroups() to corrrectly the access rights
+	of interactive shell users.
+
+	relay_recipient_maps empty should default to 'no valid
+	recipients'. Subject to compatibility level.
+
+	In mantools/postlink, allow newline etc. in "<a href".
+
+	Add an option for a TLSRPT built-in JSON generator. This
+	would simplify TLSRPT adoption by eliminating a build-time
+	and run-time dependency on the libtlsrpt client library.
+	Prior art: this approach was previously used to implement
+	Postfix Milter support.
+
+	Make TLSRPT support pluggable (postfix-tlsrpt.so, like
+	postfix-ldap.so, postfix-mysql.so and so on). This avods a
+	hard install-time dependency on sys4 libtlsrpt. The sys4
+	code would still be a required build-time dependency, but
+	it would become an optional install-time dependency.
+
+	Add smtp_tlsrpt_allow_list feature (default: static:all) to limit
+	the domains for which Postfix generates TLSRPT daily summaries.
+
+	Rename TLS_SESS_STATE.rpt_reported to skip_tlsrpt_report.
+
+	Add unit tests for smtp_tlsrpt.c, tlstrpd_wrapper.c, ...
+
+	Add sample master.cf entries for dovecot-lmtp and dovecot-pipe
+	with flags=DORX as appropriate, and single-recipient hints.
+
+	Add unit test for extpar.c
+
+	Add tests for Message-ID extraction in the cleanup daemon.
+
+	When debug logging is enabled, dict_db_open() logs a newline
+	character after the version info.
+
+	postsuper fails to write the maillog file while Postfix is
+	down (the fallback to 'direct write' happens after an
+	irreversible set_ugid() call). Possible solution: figure
+	out if we can open the maillog file before dropping privileges.
+
+	The postdrop code should be more explicit about what
+	attrributes it will pass through. rec_attr_map() is not
+	supposed to be an approver.
+
+	Many master.cf services don't expect wakeup calls, resulting
+	in weird warnings. Maybe the master daemon could signal the
+	wakeup intent through a child process command-line option,
+	so that the child can log "do not enable wakeups". Or the
+	client could announce to the xxx_server-main() skeleton
+	whether it wants wakeups. Or the child process could
+	special-case messages that consist only of a "W". We're not
+	using FIFOs anymore, and trigger servers could use a proper
+	(attribute, value) protocol.
+
+	The Sendmail feature _FFR_MDS_NEGOTIATE allows negotiating
+	a larger milter command data size limit. To be investigated:
+	what parts of the protocol are included in this limit when
+	sending a message header (header name, protocol formatting,
+	etc.) and how this will interact with the Postfix built-in
+	header_size_limit (default: 102400).
+
+	SEND_ATTR_FUNC should send the name of the object being sent,
+	so that SCAN_ATTR_FUNC can check it.
+
+	Send XFORWARD attributes in the SMTPD policy delegation
+	protocol.
+
+	With "smtpd_reject_unlisted_mumble = no" the Postfix SMTP
+	server should still reject recipients that resolve to the
+	error or retry transport.
+
+	bounce/annotate.sh should include the 'QUICK INSTRUCTIONS'
+	into the bounce.cf.default file.
+
+	Should smtp_tls_wrappermode have an SMTP_TLS_POLICY override?
+
+	The postsceen NON-SMTP test should log the command in
+	the same format as the BARE NEWLINE and PREGREET tests.
+	Consider logging the entire unadulterated command line.
+
+	"postconf -d" should not complain about a missing master.cf
+	file.
+
+	qmgr_message.c should do the right thing when the
+	double_bounce_sender value contains @.
+
+	migrate rbl -> dnsbl
+
+	migrate smtpd_sasl_tls_security_options to "noanonymous"
+	(drop the "noplaintext" part).
+
+	Safety: restrict sender-dependent features to, for example,
+	mail from an authorized client (SASL, TLS, or IP address).
+	If this becomes the default then it needs to be subject to
+	comptibility_level.
+
+	Make some of the message editing features available for
+	non-Milter configurations (for example, set envelope.from
+	from primary header.from). 
+
+	The postconf command needs more mongodb tests.
+
+	The mongodb client needs tests.
+
+	Change Postfix SMTP debug logging to display the entire
+	input, instead of stopping at the first null byte.
+
+	SRS-friendly envelope.from output rewrite in the SMTP client.
+	TBD: before or after smtp_generic_maps. The two mechanisms
+	are unlikely to be useful in combination.
+
+	Cleanup: In documentation, replace DBM with LMDB (*.lmdb).
+
+	Cleanup: Is it time to remove SDBM support? Its iterator
+	was unusable, when the SDBM client was adopted in Postfix
+	2.2.
+
+	In documentation and configuration file examples, replace
+	IPv4 address prefixes from Cloud9 with 192.168.* from RFC
+	1918, and replace IPv6 address prefixes with unique local
+	IPv6 address prefixes fd00:* from RFC 4193.
+
+	Add a pre-release check for '.' instead of ','. Generalize
+	from grep '[a-zA-Z0-9]\.  *[a-z]' proto/*|egrep -v
+	'i\.e\.|etc\.|e\.g\.|\.  *[a-zA-Z0-9]*\('
+
+	Update DKIM examples for signing with the benefits of forced
+	MIME converison with "force_mime_input_conversion = yes"
+
+	Scan Postfix code with github.com/googleprojectzero/weggli
+	(depends on "rust").
+
+	Investigate clang-format compatibility as a possible migration
+	away from indent. This requires that the output is stable.
+
+	Check out https://github.com/milter-manager/milter-manager/
+
+	Check out https://github.com/clear-code/cutter
+	(https://cutter.osdn.jp/) for C/C++ unit tests.
+
+	postscreen hints to smtpd to suppress the server greeting
+	after a remote SMTP client has pregreeted. This makes the
+	PIPELINING detection more meaningful.
+
+	Multi-recipient support in sender/recipient_bcc_maps and
+	always_bcc.
+
+	mail_conf_xxx supprt for non-negative numbers (i.e. 
+	numbers with a lower bound of zero).
+
+	Log anvil transgressions with their address range (in
+	addition to the offending IP address. We should not disclose
+	to random clients how we aggregate anvil event counters.
+
+	Should "postconf -f" pretty-print text inside {}?
+
+	Is there any code that calls attr_scan*() and that works
+	when the number of attributes received < the expected number?
+	If there is no such code, then we can simplify a few things.
+
+	Update TLS_README diagram, tlsmgr no longer manages cert
+	info.
+
+	Consider renaming local_header_rewrite_clients to
+	local_header_canonicalize_clients, as a more accurate name.
+	Optionally support "local_header_canonicalize_classes =
+	rewrite_addresses, add_missing_headers" (default setting).
+
+	And ditto for remote_header_rewrite_domain, whether it
+	should rewrite address, add missing headers, or both.
+
+	Add weight factors to randmap, for example randmap:{{result1}*99,
+	{result2}*1}. To parse out weights, see postscreen.
+
+	randmap already allows randmap:{{result}, ...}, to support
+	whitespace and comma in result values, but it should also
+	extract the value from {}.
+
+	Migrate masquerade_domains from ARGV to STRING_LIST, or
+	deprecate this feature because it breaks table-driven address
+	validation.
+
+	Enforce var_line_limit in util/attr_scan*c. This is needed if
+	we want to expose Postfix RPC protocols externally.
+
+	Can tests use LD_PRELOAD to inject fake modules such as
+	fake_dns(3), fake_msg(3), fake_myaddrinfo(3) and so on?
+	One limitation is that functions etc. in a preloaded object
+	always take precedence, even in code that is not being
+	tested.
+
+	'%l' support, similar to %D in the Dovecot LDAP driver.
+	Subject: Feature request: '%l' expansion for ldap_table,
+	Date: Tue, 5 Apr 2022.  Message-ID:
+	<ef7c661c-d86a-2366-6a73-ec8d51d75012@dev.snart.me>
+
+	WARN_IF_REJECT like prefix that disables the error counter increment.
+
+	Consider migrating Postfix server sockets from directory
+	$queue_directory/public to $queue_directory/protected. The
+	directory $queue_directory/public can then be used for
+	non-Postfix listeners (one subdirectory per application).
+
+	FILTER_README needs some text on multi-instance implementations,
+	and existing multi-instance references need to be updated.
+
+	Fix code that still uses "long" for data_size and data_offset,
+	and sscanf("%ld or strtou?l()). This seems relevant for 32-bit
+	systems. This would use a new REC_TYPE_OFFS with a corresponding
+	data type of off_t, using off_cvt() for conversion from string,
+	and new code to convert off_t to string.
+
+	A smart query service for live Postfix tables that outputs JSON?
+	If the idea is to introspect on a running Postfix system, this
+	involves adding an RPC endpoint to specific Postfix services.
+	That could work for single-instance services like qmgr, verify,
+	postscreen.
+
+	JSON logging?
+
+	default_transport_maps? This would simplify configuration.
+
+	Add a pointer to
+	https://fabianlee.org/2019/10/23/docker-running-a-postfix-container-for-testing-mail-during-development/
+	and https://github.com/docker-mailserver/docker-mailserver
+
+	Add a pointer to
+	https://github.com/tarickb/sasl-xoauth2 and/or
+	http://mmogilvi.users.sourceforge.net/software/oauthbearer.html
+	in documentation or on-line howtos.
+
+	Read the above links and see how we can improve usability on
+	the Postfix side.
+
+	Add verp=+= to the qmgr "from=" logging. This is already
+	implemented but not yet integrated.
+
+	Need canonical Dovecot example that has virtual_mailbox_domains,
+	(virtual_mailbox_maps or reject unverified_recipient), and
+	virtual_transport.
+
+	Make smtpd_relay_before_recipient_restrictions settable
+	in smtpd_checks tests.
+
+	Make the DNS resolver library pluggable, so that we can a)
+	plug in a fake resolver library for DNS-related regression
+	tests and make DNS tests hermetic (no external dependency;
+	b) add support for non-libbind resolvers. Gracefully handle
+	requests for unsupported functionality; return an error status,
+	instead of terminating.
+
+	Add a robust dnssec_probe regression test (success and fail)
+	that does not break existing regression tests.
+
+	smtp_sasl_tls_security_options = noanonymous, and make
+	smtp_sasl_security_options the default dependent on the
+	smtp_sasl_tls_security_options default (i.e. reverse the
+	dependency). Or make them independent.
+
+	Try to make the master throttle more distrusting. Currently,
+	the master throttles a service after a child process cannot be
+	created (fork() fails), or if a child process fails upon its
+	first use. The master always unthrottles the service if a process
+	handles a client successfully. This is sufficient to mitigate
+	local errors that break all attempts to use a service. It also
+	slows down stupid remote attacks as long as malicious traffic
+	dominates benign traffic. Perhaps monitor a crashing percentage?
+	If 50% of all connections to a service result in abnormal
+	termination, that would be bad even under a non-attack scenario.
+
+	More accurate address verification: do a quota check before
+	reporting that a local(8) or virtual(8) recipient is deliverable.
+
+	Eliminate duplicate mail submission permission checks from
+	sendmail, so that they happen in postdrop only. Then, pass the
+	result through the postdrop-to-sendmail protocol. This requires
+	that postdrop reads all inputs before responding (the
+	local_login_sender_maps check depends on the envelope
+	sender). Then sendmail can save input to dead.letter (no setgid
+	privilege, but it would still have to use safe_open() to avoid
+	clobbering files).
+
+	Consider removing compat_level_from_numbers() and aliases,
+	because they are no longer used anywhere.
+
+	Allow '}' at the beginning of a line. This would make multi-line
+	configuration settings easier to enter. This may be true
+	for main.cf, master.cf and similar files (such as database
+	configuration files, but not necessarily elsewhere). So it
+	may have to be a readlline flag.
+
+	Understand what happens with DNSSEC related status fields 
+	in posttls-finger when resolv.conf points to a host that
+	runs no DNS server.
+
+	Hardening the half-dane behavior: some sites may rely on
+	current behavior which allows original MX domain name for
+	certificate matches. Requires a new (compatibility) parameter
+	setting?
+
+	Code deduplication: migrate multi_server applications to
+	event_server, because the multi_server and event_server
+	skeletons are much more similar than other skeletons. In
+	addition to the default event_server accept() handler, also
+	register a read event callback for handling post_accept
+	events. But the currrent multi_server API fits typical usage
+	better.
+
+	When a secondary instance has no multi_instance_name set,
+	postmulti -i won't be able to find it.
+
+	nbbio: exercise the sanity checks with fake msg(3) functions.
+
+	optreset (bsd-ism) how badly do we need it?
+
+	transport policy protocol (clone of check_policy).
+
+	See also postscreen event-driven client for policy delegation
+	below.
+
+	smtp_line_length_limit can insert a line break in the middle
+	of a multi-byte character (which is not necessarily UTF-8,
+	so we can't simply look at the 8th bit). Also, note that a
+	multi-byte character may span queue file record boundaries,
+	for example if line_length_limit == smtp_line_length_limit.
+	The only way to fix this is to make the smtp_text_out()
+	routine aware of every possible multi-byte encoding.
+
+	Replace ad-hoc code for pipe(8) flags handling, with
+	infrastructure that was built for smtp(8).
+
+	Move map descriptions from postconf(1) to DATABASE_README
+	and point there. The text in DATABASE_README is less complete
+	than that in postconf(1).
+
+	make tls_pre_jail_init() safe by design for use in programs
+	that implement both clients and servers.
+
+	In smtpd(8) and postscreen(8), set the ehlo_discard_mask
+	to ~0 so that STARTTLS, BDAT, DSN, etc. work only for clients
+	that send EHLO.
+
+	Wordsmithing: "replace by X" -> "replace with X" unless X
+	is "responsible" for making the substitution.
+
+	In postscreen, don't fork after 'postfix reload' when
+	psc_check_queue_length (and psc_post_queue_length?) is zero.
 
 	After I/O error, store errno in VSTREAM object before errno
 	may be overwritten.
@@ -134,10 +504,6 @@ Wish list:
 	Maybe don't whitelist a client that has maxed out its
 	per-MTA connection count limit.
 
-	Inline support for pcre:{/pattern/=action, ...} and ditto
-	support for regexp: and cidr: tables. Factor out and reuse
-	code that already exists in inline: and other tables.
-
 	Log command=good/bad statistics in postscreen?
 
 	smtpd_checks tests either must use a DNS dummy resolver
@@ -680,22 +1046,6 @@ Wish list:
 	Cleanup: make DNSBL query format configurable beyond the
 	client's reversed IP address.
 
-	With 'final delivery' in the LMTP client, need an option
-	to also add delivered-to and other pipe(8) features.  This
-	requires making mail_copy() functionality available in
-	non-mailbox context.
-
-	Cleanup: modernize the "add missing From: header" code, to
-	``phrase <addr>'' form. Most likely, quote the entire phrase
-	if it contains any text that is special, then rfc822_externalize
-	the whole thing.
-
-	SMTP server: make the server_addr and server_port available
-	to policy server, Dovecot, and perhaps Milters.
-
-	Med: local and remote source port and IP address for smtpd
-	policy hook.
-
 	Maybe change maps_rbl_reject_code default to 521, and
 	update wording in STRESS_README.
 
@@ -708,15 +1058,6 @@ Wish list:
 	Plan for time_t larger than long, or wait for LP64 to
 	dominate the world?
 
-	Make "AUTH=<>" appendage to MAIL FROM configurable, enabled
-	by default.
-
-	To support ternary operator without a huge parsing effort,
-	consider ${value?{xxx}:{yyy}} where ${name} is existing
-	syntax, and where ?{text} and :{text} are new syntax that
-	is unlikely to break existing configurations. Or perhaps
-	it's just too ugly.
-
 	Write delivery rate delay example (which _README?) and auth
 	failure cache example (SASL_README). Then include them in
 	SOHO_README.

postfix/auxiliary/collate/README.tlstype

@@ -0,0 +1,37 @@
+On Mon, Apr 06, 2020 at 08:21:32AM +0100, Dominic Raferd wrote:
+
+> Using setting 'smtp_tls_security_level = may' (postfix 3.3.0) is there
+> a reliable way to see from log which outgoing emails were sent in the
+> clear i.e. *not* using TLS?
+
+Yes, provided you don't lose too many log messages[1], and your logging
+subsystem does not reorder them[1], set:
+
+    smtp_tls_loglevel = 1
+
+and use "collate":
+
+    https://github.com/vdukhovni/postfix/tree/master/postfix/auxiliary/collate
+
+whose output you'd send to the attached Perl script.  On my system for
+example:
+
+    # bzcat $(ls -tr /var/log/maillog*) | perl collate.pl | perl tlstype.pl
+
+-- 
+    Viktor.
+
+[1] If your system is suffering under the yoke of systemd-journald, you
+should strongly consider enabling the built-in logging in recent
+versions of Postfix to bypass systemd's broken logging subsystem.
+
+    - It is single-threaded, performs poorly on multi-cpu servers and
+      may not be able to keep up with all the messages generated on a
+      busy multi-cpu system.
+
+    - By default has low message rate limits, dropping messages
+      that exceed the limits.
+
+    - Listens on stream socket rather than a dgram socket, which
+      breaks message ordering from multi-process systems like
+      Postfix.

postfix/auxiliary/collate/collate.pl

@@ -25,6 +25,7 @@ my %smtp;
 my %transaction;
 my $i = 0;
 my %seqno;
+my %deleted;
 
 my %isagent = map { ($_, 1) } @agents;
 
@@ -36,6 +37,7 @@ while (<>) {
 		if (m{\Gconnect from }gc) {
 			# Start new log
 			$smtpd{$pid}->{"log"} = $_; next;
+			undef $smtpd{$pid}->{"qid"};
 		}
 
 		$smtpd{$pid}->{"log"} .= $_;
@@ -52,7 +54,14 @@ while (<>) {
 		my $qid = $smtpd{$pid}->{"qid"};
 		$transaction{$qid} .= $_
 			if (defined($qid) && exists $transaction{$qid});
-		delete $smtpd{$pid} if (m{\Gdisconnect from}gc);
+		if (m{\Gdisconnect from}gc) {
+			if (!defined($qid)) {
+				print $smtpd{$pid}->{"log"}, "\n";
+			} elsif (delete $deleted{$qid}) {
+				print delete $transaction{$qid}, "\n";
+			}
+			delete $smtpd{$pid};
+		}
 		next;
 	}
 
@@ -73,6 +82,9 @@ while (<>) {
 		my $qid = "$inst/$1";
 		$transaction{$qid} .= $_;
 		$seqno{$qid} = ++$i if (! exists $seqno{$qid});
+		if (m{\G(?:milter(?:-(?:header|body))?-)?(?:reject|discard|hold): }) {
+			$deleted{$qid} = 1;
+		}
 		next;
 	}
 

postfix/auxiliary/collate/tlstype.pl

@@ -0,0 +1,31 @@
+#! /usr/bin/env perl
+
+use strict;
+use warnings;
+
+local $/ = "\n\n";
+
+while (<>) {
+    my $qid;
+    my %tls;
+    my $smtp;
+    foreach my $line (split("\n")) {
+	if ($line =~ m{ postfix(?:\S*?)/qmgr\[\d+\]: (\w+): from=<.*>, size=\d+, nrcpt=\d+ [(]queue active[)]$}) {
+	    $qid //= $1;
+	    next;
+	}
+	if ($line =~ m{ postfix(?:\S*?)/smtp\[(\d+)\]: (\S+) TLS connection established to (\S+): (.*)}) {
+	    $tls{$1}->{lc($3)} = [$2, $4];
+	    next;
+	}
+	if ($line =~ m{.*? postfix(?:\S*?)/smtp\[(\d+)\]: (\w+): (to=.*), relay=(\S+), (delay=\S+, delays=\S+, dsn=2\.\S+, status=sent .*)}) {
+	    next unless $qid eq $2;
+	    if (defined($tls{$1}->{lc($4)}) && ($tls{$1}->{lc($4)}->[2] //= $5) eq $5) {
+		printf "qid=%s, relay=%s, %s -> %s %s\n", $qid, lc($4), $3, @{$tls{$1}->{lc($4)}}[0..1];
+	    } else {
+		delete $tls{$1};
+		printf "qid=%s, relay=%s, %s -> cleartext\n", $qid, lc($4), $3;
+	    }
+	}
+    }
+}

postfix/auxiliary/fix-grep/fix-grep.sh

@@ -0,0 +1,11 @@
+#!/bin/sh
+
+# Fix grep -[EF] for systems that require the historical forms egrep
+# and fgrep. Run this script in the top-level Postfix directory as
+#     sh auxiliary/fix-grep/fix-grep.sh
+
+# Use only historical grep syntax.
+find * -type f | xargs grep -l 'grep -[EF]' | xargs perl -pi -e '
+	s/grep -E/egrep/g;
+	s/grep -F/fgrep/g;
+'

postfix/auxiliary/name-addr-test/gethostbyaddr.c

@@ -25,7 +25,7 @@ char  **argv;
     long    addr;
 
     if (argc != 2) {
-	fprintf(stderr, "usage: %s i.p.addres\n", argv[0]);
+	fprintf(stderr, "usage: %s i.p.address\n", argv[0]);
 	exit(1);
     }
     addr = inet_addr(argv[1]);

postfix/auxiliary/name-addr-test/getnameinfo.c

@@ -36,7 +36,7 @@ int     main(int argc, char **argv)
 #define NO_SERVICE ((char *) 0)
 
     if (argc != 2) {
-	fprintf(stderr, "usage: %s ipaddres\n", argv[0]);
+	fprintf(stderr, "usage: %s ipaddress\n", argv[0]);
 	exit(1);
     }
 

postfix/auxiliary/qshape/qshape.pl

@@ -138,7 +138,7 @@ do {
 	"The 's' option shows sender domain counts.\n".
 	"The 'p' option shows address counts by for parent domains.\n".
 	"Parent domains are shown with a leading '.' before the domain name.\n".
-	"Parent domains are only shown if the the domain is not a TLD, and at\n".
+	"Parent domains are only shown if the domain is not a TLD, and at\n".
 	"least <min_subdomains> (default 5) subdomains are shown in the output.\n\n".
 
 	"The bucket age ranges in units of <bucket_time> minutes are\n".

postfix/conf/access

@@ -31,7 +31,7 @@
 # 
 #        Alternatively,  the  table  can  be  provided  as  a regu-
 #        lar-expression map where patterns  are  given  as  regular
-#        expressions,  or  lookups  can  be  directed  to TCP-based
+#        expressions,  or  lookups  can  be directed to a TCP-based
 #        server. In those cases, the lookups are done in a slightly
 #        different way as described below under "REGULAR EXPRESSION
 #        TABLES" or "TCP-BASED TABLES".
@@ -59,7 +59,7 @@
 #               line that starts with whitespace continues a  logi-
 #               cal line.
 # 
-# EMAIL ADDRESS PATTERNS
+# EMAIL ADDRESS PATTERNS IN INDEXED TABLES
 #        With lookups from indexed files such as DB or DBM, or from
 #        networked tables such as NIS, LDAP or  SQL,  patterns  are
 #        tried in the order as listed below:
@@ -97,7 +97,7 @@
 #        becomes:  user+foo@domain, user@domain, domain, user+foo@,
 #        and user@.
 # 
-# HOST NAME/ADDRESS PATTERNS
+# HOST NAME/ADDRESS PATTERNS IN INDEXED TABLES
 #        With lookups from indexed files such as DB or DBM, or from
 #        networked  tables  such as NIS, LDAP or SQL, the following
 #        lookup patterns are examined in the order as listed:
@@ -122,21 +122,17 @@
 # 
 #        net.work
 # 
-#        net    Matches the specified IPv4 host address or  subnet-
-#               work.  An  IPv4  host address is a sequence of four
-#               decimal octets separated by ".".
+#        net    Matches a  remote  IPv4  host  address  or  network
+#               address  range.  Specify one to four decimal octets
+#               separated by ".". Do not specify "[]" , "/",  lead-
+#               ing zeros, or hexadecimal forms.
 # 
-#               Subnetworks are matched  by  repeatedly  truncating
-#               the last ".octet" from the remote IPv4 host address
-#               string until a match is found in the access  table,
+#               Network ranges are matched by repeatedly truncating
+#               the last ".octet" from a remote IPv4  host  address
+#               string, until a match is found in the access table,
 #               or until further truncation is not possible.
 # 
-#               NOTE 1: The access map lookup key must be in canon-
-#               ical form: do not specify unnecessary null  charac-
-#               ters,  and  do not enclose network address informa-
-#               tion with "[]" characters.
-# 
-#               NOTE 2: use the cidr lookup table type  to  specify
+#               NOTE: use the cidr lookup  table  type  to  specify
 #               network/netmask  patterns.  See  cidr_table(5)  for
 #               details.
 # 
@@ -146,25 +142,20 @@
 # 
 #        net:work
 # 
-#        net    Matches the specified IPv6 host address or  subnet-
-#               work.  An  IPv6 host address is a sequence of three
-#               to eight hexadecimal octet pairs separated by  ":".
+#        net    Matches a  remote  IPv6  host  address  or  network
+#               address  range.  Specify three to eight hexadecimal
+#               octet pairs separated by ":", using the  compressed
+#               form  "::"  for  a  sequence  of  zero-valued octet
+#               pairs. Do not specify "[]", "/", leading zeros,  or
+#               non-compressed forms.
 # 
-#               Subnetworks  are  matched  by repeatedly truncating
-#               the last ":octetpair" from  the  remote  IPv6  host
-#               address string until a match is found in the access
-#               table, or until further truncation is not possible.
+#               A network range is matched by repeatedly truncating
+#               the  last  ":octetpair"  from  the  compressed-form
+#               remote  IPv6  host address string, until a match is
+#               found in the access table, or until further trunca-
+#               tion is not possible.
 # 
-#               NOTE 1: the truncation and comparison are done with
-#               the string representation of the IPv6 host address.
-#               Thus, not all the ":" subnetworks will be tried.
-# 
-#               NOTE 2: The access map lookup key must be in canon-
-#               ical form: do not specify unnecessary null  charac-
-#               ters,  and  do not enclose network address informa-
-#               tion with "[]" characters.
-# 
-#               NOTE 3: use the cidr lookup table type  to  specify
+#               NOTE:  use  the  cidr  lookup table type to specify
 #               network/netmask  patterns.  See  cidr_table(5)  for
 #               details.
 # 
@@ -175,64 +166,64 @@
 # 
 #        all-numerical
 #               An all-numerical result is treated as OK. This for-
-#               mat is generated by address-based relay  authoriza-
+#               mat  is generated by address-based relay authoriza-
 #               tion schemes such as pop-before-smtp.
 # 
 #        For other accept actions, see "OTHER ACTIONS" below.
 # 
 # REJECT ACTIONS
-#        Postfix  version  2.3  and  later  support enhanced status
-#        codes as defined in RFC 3463.  When no code  is  specified
-#        at  the  beginning  of  the  text below, Postfix inserts a
-#        default enhanced status code of "5.7.1"  in  the  case  of
-#        reject  actions, and "4.7.1" in the case of defer actions.
+#        Postfix version 2.3  and  later  support  enhanced  status
+#        codes  as  defined in RFC 3463.  When no code is specified
+#        at the beginning of the  text  below,  Postfix  inserts  a
+#        default  enhanced  status  code  of "5.7.1" in the case of
+#        reject actions, and "4.7.1" in the case of defer  actions.
 #        See "ENHANCED STATUS CODES" below.
 # 
 #        4NN text
 # 
 #        5NN text
-#               Reject the address etc. that matches  the  pattern,
+#               Reject  the  address etc. that matches the pattern,
 #               and respond with the numerical three-digit code and
-#               text. 4NN means "try again later", while 5NN  means
+#               text.  4NN means "try again later", while 5NN means
 #               "do not try again".
 # 
-#               The  following  responses  have special meaning for
+#               The following responses have  special  meaning  for
 #               the Postfix SMTP server:
 # 
 #               421 text (Postfix 2.3 and later)
 # 
 #               521 text (Postfix 2.6 and later)
-#                      After   responding   with   the    numerical
-#                      three-digit  code and text, disconnect imme-
+#                      After    responding   with   the   numerical
+#                      three-digit code and text, disconnect  imme-
 #                      diately from the SMTP client.  This frees up
-#                      SMTP  server  resources  so that they can be
+#                      SMTP server resources so that  they  can  be
 #                      made available to another SMTP client.
 # 
 #                      Note: The "521" response should be used only
-#                      with  botnets and other malware where inter-
+#                      with botnets and other malware where  inter-
 #                      operability is of no concern.  The "send 521
-#                      and  disconnect"  behavior is NOT defined in
+#                      and disconnect" behavior is NOT  defined  in
 #                      the SMTP standard.
 # 
 #        REJECT optional text...
-#               Reject the address etc. that matches  the  pattern.
-#               Reply    with   "$access_map_reject_code   optional
-#               text..." when the optional text is specified,  oth-
+#               Reject  the  address etc. that matches the pattern.
+#               Reply   with   "$access_map_reject_code    optional
+#               text..."  when the optional text is specified, oth-
 #               erwise reply with a generic error response message.
 # 
 #        DEFER optional text...
-#               Reject the address etc. that matches  the  pattern.
-#               Reply    with    "$access_map_defer_code   optional
-#               text..." when the optional text is specified,  oth-
+#               Reject  the  address etc. that matches the pattern.
+#               Reply   with    "$access_map_defer_code    optional
+#               text..."  when the optional text is specified, oth-
 #               erwise reply with a generic error response message.
 # 
 #               This feature is available in Postfix 2.6 and later.
 # 
 #        DEFER_IF_REJECT optional text...
-#               Defer  the  request if some later restriction would
-#               result   in   a   REJECT   action.    Reply    with
-#               "$access_map_defer_code   4.7.1  optional  text..."
-#               when the  optional  text  is  specified,  otherwise
+#               Defer the request if some later  restriction  would
+#               result    in    a   REJECT   action.   Reply   with
+#               "$access_map_defer_code  4.7.1  optional   text..."
+#               when  the  optional  text  is  specified, otherwise
 #               reply with a generic error response message.
 # 
 #               Prior to Postfix 2.6, the SMTP reply code is 450.
@@ -240,10 +231,10 @@
 #               This feature is available in Postfix 2.1 and later.
 # 
 #        DEFER_IF_PERMIT optional text...
-#               Defer the request if some later  restriction  would
-#               result  in a an explicit or implicit PERMIT action.
-#               Reply with "$access_map_defer_code 4.7.1   optional
-#               text..."  when the optional text is specified, oth-
+#               Defer  the  request if some later restriction would
+#               result in an explicit or  implicit  PERMIT  action.
+#               Reply  with "$access_map_defer_code 4.7.1  optional
+#               text..." when the optional text is specified,  oth-
 #               erwise reply with a generic error response message.
 # 
 #               Prior to Postfix 2.6, the SMTP reply code is 450.
@@ -258,108 +249,114 @@
 #               reject_unauth_destination, and so on).
 # 
 #        BCC user@domain
-#               Send  one  copy  of  the  message  to the specified
+#               Send one copy  of  the  message  to  the  specified
 #               recipient.
 # 
-#               If multiple BCC actions are  specified  within  the
-#               same  SMTP  MAIL transaction, with Postfix 3.0 only
+#               If  multiple  BCC  actions are specified within the
+#               same SMTP MAIL transaction, with Postfix  3.0  only
 #               the last action will be used.
 # 
 #               This feature is available in Postfix 3.0 and later.
 # 
 #        DISCARD optional text...
-#               Claim  successful delivery and silently discard the
-#               message.  Log the optional text if specified,  oth-
+#               Claim successful delivery and silently discard  the
+#               message.   Log the optional text if specified, oth-
 #               erwise log a generic message.
 # 
-#               Note:  this action currently affects all recipients
-#               of the message.   To  discard  only  one  recipient
-#               without  discarding  the  entire  message,  use the
+#               Note: this action currently affects all  recipients
+#               of  the  message.   To  discard  only one recipient
+#               without discarding  the  entire  message,  use  the
 #               transport(5) table to direct mail to the discard(8)
 #               service.
 # 
 #               This feature is available in Postfix 2.0 and later.
 # 
-#        DUNNO  Pretend that the lookup key  was  not  found.  This
-#               prevents  Postfix  from  trying  substrings  of the
-#               lookup key (such as a subdomain name, or a  network
+#        DUNNO  Pretend  that  the  lookup  key was not found. This
+#               prevents Postfix  from  trying  substrings  of  the
+#               lookup  key (such as a subdomain name, or a network
 #               address subnetwork).
 # 
 #               This feature is available in Postfix 2.0 and later.
 # 
 #        FILTER transport:destination
-#               After the message is queued, send the  entire  mes-
+#               After  the  message is queued, send the entire mes-
 #               sage through the specified external content filter.
-#               The transport name specifies the first field  of  a
-#               mail  delivery  agent  definition in master.cf; the
-#               syntax of the next-hop destination is described  in
+#               The  transport  name specifies the first field of a
+#               mail delivery agent definition  in  master.cf;  the
+#               syntax  of the next-hop destination is described in
 #               the  manual  page  of  the  corresponding  delivery
-#               agent.  More  information  about  external  content
+#               agent.   More  information  about  external content
 #               filters is in the Postfix FILTER_README file.
 # 
-#               Note  1: do not use $number regular expression sub-
-#               stitutions for transport or destination unless  you
+#               Note 1: do not use $number regular expression  sub-
+#               stitutions  for transport or destination unless you
 #               know that the information has a trusted origin.
 # 
-#               Note  2:  this  action  overrides  the main.cf con-
-#               tent_filter setting, and affects all recipients  of
-#               the  message.  In  the  case  that  multiple FILTER
+#               Note 2: this  action  overrides  the  main.cf  con-
+#               tent_filter  setting, and affects all recipients of
+#               the message.  In  the  case  that  multiple  FILTER
 #               actions fire, only the last one is executed.
 # 
-#               Note 3: the purpose of the  FILTER  command  is  to
-#               override  message routing.  To override the recipi-
-#               ent's transport but not the  next-hop  destination,
-#               specify  an  empty  filter destination (Postfix 2.7
+#               Note  3:  the  purpose  of the FILTER command is to
+#               override message routing.  To override the  recipi-
+#               ent's  transport  but not the next-hop destination,
+#               specify an empty filter  destination  (Postfix  2.7
 #               and later), or specify a transport:destination that
-#               delivers   through  a  different  Postfix  instance
-#               (Postfix 2.6 and earlier). Other options are  using
-#               the  recipient-dependent transport_maps or the sen-
+#               delivers  through  a  different  Postfix   instance
+#               (Postfix  2.6 and earlier). Other options are using
+#               the recipient-dependent transport_maps or the  sen-
 #               der-dependent   sender_dependent_default_transport-
 #               _maps features.
 # 
 #               This feature is available in Postfix 2.0 and later.
 # 
 #        HOLD optional text...
-#               Place the message on the hold queue, where it  will
-#               sit  until someone either deletes it or releases it
-#               for delivery.  Log the optional text if  specified,
+#               Place  the message on the hold queue, where it will
+#               sit until someone either deletes it or releases  it
+#               for  delivery.  Log the optional text if specified,
 #               otherwise log a generic message.
 # 
-#               Mail  that  is  placed on hold can be examined with
-#               the postcat(1) command, and  can  be  destroyed  or
+#               Mail that is placed on hold can  be  examined  with
+#               the  postcat(1)  command,  and  can be destroyed or
 #               released with the postsuper(1) command.
 # 
-#               Note:  use  "postsuper -r" to release mail that was
-#               kept on hold for a significant fraction  of  $maxi-
+#               Note: use "postsuper -r" to release mail  that  was
+#               kept  on  hold for a significant fraction of $maxi-
 #               mal_queue_lifetime  or  $bounce_queue_lifetime,  or
-#               longer. Use "postsuper -H" only for mail that  will
+#               longer.  Use "postsuper -H" only for mail that will
 #               not expire within a few delivery attempts.
 # 
-#               Note:  this action currently affects all recipients
+#               Note: this action currently affects all  recipients
 #               of the message.
 # 
 #               This feature is available in Postfix 2.0 and later.
 # 
 #        PREPEND headername: headervalue
-#               Prepend  the  specified  message header to the mes-
-#               sage.  When more than one PREPEND action  executes,
-#               the  first prepended header appears before the sec-
+#               Prepend the specified message header  to  the  mes-
+#               sage.   When more than one PREPEND action executes,
+#               the first prepended header appears before the  sec-
 #               ond etc. prepended header.
 # 
-#               Note: this action must execute before  the  message
-#               content  is received; it cannot execute in the con-
+#               Note:  this  action must execute before the message
+#               content is received; it cannot execute in the  con-
 #               text of smtpd_end_of_data_restrictions.
 # 
 #               This feature is available in Postfix 2.1 and later.
 # 
 #        REDIRECT user@domain
-#               After  the  message  is queued, send the message to
+#               After the message is queued, send  the  message  to
 #               the  specified  address  instead  of  the  intended
 #               recipient(s).  When multiple REDIRECT actions fire,
 #               only the last one takes effect.
 # 
-#               Note: this action overrides the FILTER action,  and
-#               currently  overrides all recipients of the message.
+#               Note  1:  this  action overrides the FILTER action,
+#               and currently overrides all recipients of the  mes-
+#               sage.
+# 
+#               Note 2: a REDIRECT address is subject to canonical-
+#               ization (add missing domain)  but  NOT  subject  to
+#               canonical,  masquerade,  bcc, or virtual alias map-
+#               ping.
 # 
 #               This feature is available in Postfix 2.1 and later.
 # 

postfix/conf/aliases

@@ -44,10 +44,20 @@ decode:		root
 # SYNOPSIS
 #        newaliases
 # 
+#        postalias -q name [file-type]:[file-name]
+# 
 # DESCRIPTION
-#        The  aliases(5)  table provides a system-wide mechanism to
-#        redirect mail for local recipients. The  redirections  are
-#        processed by the Postfix local(8) delivery agent.
+#        The  optional aliases(5) table (alias_maps) redirects mail
+#        for local recipients. The redirections  are  processed  by
+#        the  Postfix local(8) delivery agent. This table is always
+#        searched with an email address localpart (no  domain  por-
+#        tion).
+# 
+#        This  is  unlike  virtual(5) aliasing (virtual_alias_maps)
+#        which applies to all recipients:  local(8),  virtual,  and
+#        remote, and which is implemented by the cleanup(8) daemon.
+#        That table is often searched with  a  full  email  address
+#        (including domain).
 # 
 #        Normally, the aliases(5) table is specified as a text file
 #        that serves as input  to  the  postalias(1)  command.  The
@@ -108,16 +118,20 @@ decode:		root
 #               with the RFC 822 standard.
 # 
 #        /file/name
-#               Mail  is  appended  to /file/name. See local(8) for
-#               details of delivery to file.  Delivery is not  lim-
-#               ited  to regular files.  For example, to dispose of
-#               unwanted mail, deflect it to /dev/null.
+#               Mail  is appended to /file/name. For details on how
+#               a file is written see the sections  "EXTERNAL  FILE
+#               DELIVERY"  and  "DELIVERY  RIGHTS"  in the local(8)
+#               documentation.  Delivery is not limited to  regular
+#               files.   For  example, to dispose of unwanted mail,
+#               deflect it to /dev/null.
 # 
 #        |command
 #               Mail is piped into command. Commands  that  contain
 #               special  characters,  such as whitespace, should be
-#               enclosed between double quotes.  See  local(8)  for
-#               details of delivery to command.
+#               enclosed between double quotes. For details on  how
+#               a  command is executed see "EXTERNAL COMMAND DELIV-
+#               ERY" and "DELIVERY RIGHTS" in the local(8) documen-
+#               tation.
 # 
 #               When the command fails, a limited amount of command
 #               output is mailed back  to  the  sender.   The  file
@@ -129,7 +143,8 @@ decode:		root
 #        :include:/file/name
 #               Mail is sent to  the  destinations  listed  in  the
 #               named file.  Lines in :include: files have the same
-#               syntax as the right-hand side of alias entries.
+#               syntax  as  the  right-hand  side   of   aliases(5)
+#               entries.
 # 
 #               A  destination  can  be  any  destination  that  is
 #               described in this manual page. However, delivery to
@@ -139,12 +154,12 @@ decode:		root
 # 
 # ADDRESS EXTENSION
 #        When alias database search fails, and the recipient local-
-#        part  contains  the  optional  recipient  delimiter (e.g.,
-#        user+foo), the  search  is  repeated  for  the  unextended
+#        part contains  the  optional  recipient  delimiter  (e.g.,
+#        user+foo),  the  search  is  repeated  for  the unextended
 #        address (e.g., user).
 # 
-#        The   propagate_unmatched_extensions   parameter  controls
-#        whether an unmatched address extension  (+foo)  is  propa-
+#        The  propagate_unmatched_extensions   parameter   controls
+#        whether  an  unmatched  address extension (+foo) is propa-
 #        gated to the result of table lookup.
 # 
 # CASE FOLDING
@@ -152,47 +167,52 @@ decode:		root
 #        to lowercase before database lookup.
 # 
 # REGULAR EXPRESSION TABLES
-#        This section describes how the table lookups  change  when
+#        This  section  describes how the table lookups change when
 #        the table is given in the form of regular expressions. For
-#        a description of regular expression lookup  table  syntax,
-#        see  regexp_table(5) or pcre_table(5). NOTE: these formats
+#        a  description  of regular expression lookup table syntax,
+#        see regexp_table(5) or pcre_table(5). NOTE: these  formats
 #        do not use ":" at the end of a pattern.
 # 
-#        Each regular expression is applied to  the  entire  search
-#        string.  Thus,  a  search string user+foo is not broken up
+#        Each  regular  expression  is applied to the entire search
+#        string. Thus, a search string user+foo is  not  broken  up
 #        into user and foo.
 # 
-#        Regular expressions are applied in the order as  specified
-#        in  the  table,  until  a regular expression is found that
+#        Regular  expressions are applied in the order as specified
+#        in the table, until a regular  expression  is  found  that
 #        matches the search string.
 # 
-#        Lookup results are the same as with indexed file  lookups.
-#        For  security  reasons there is no support for $1, $2 etc.
+#        Lookup  results are the same as with indexed file lookups.
+#        For security reasons there is no support for $1,  $2  etc.
 #        substring interpolation.
 # 
 # SECURITY
-#        The local(8) delivery agent disallows  regular  expression
-#        substitution  of $1 etc. in alias_maps, because that would
+#        The  local(8)  delivery agent disallows regular expression
+#        substitution of $1 etc. in alias_maps, because that  would
 #        open a security hole.
 # 
-#        The local(8) delivery agent will silently ignore  requests
-#        to  use  the proxymap(8) server within alias_maps. Instead
-#        it will open the table directly.  Before  Postfix  version
-#        2.2,  the  local(8)  delivery  agent will terminate with a
+#        The  local(8) delivery agent will silently ignore requests
+#        to use the proxymap(8) server within  alias_maps.  Instead
+#        it  will  open the table directly.  Before Postfix version
+#        2.2, the local(8) delivery agent  will  terminate  with  a
 #        fatal error.
 # 
 # CONFIGURATION PARAMETERS
-#        The following main.cf parameters are especially  relevant.
-#        The  text  below  provides  only  a parameter summary. See
+#        The  following main.cf parameters are especially relevant.
+#        The text below provides  only  a  parameter  summary.  See
 #        postconf(5) for more details including examples.
 # 
 #        alias_database (see 'postconf -d' output)
-#               The alias databases for local(8) delivery that  are
+#               The  alias databases for local(8) delivery that are
 #               updated with "newaliases" or with "sendmail -bi".
 # 
 #        alias_maps (see 'postconf -d' output)
-#               The  alias  databases  that  are  used for local(8)
-#               delivery.
+#               Optional lookup tables that are searched only  with
+#               an  email  address  localpart  (no domain) and that
+#               apply only to local(8) recipients; this  is  unlike
+#               virtual_alias_maps  that  are often searched with a
+#               full email  address  (including  domain)  and  that
+#               apply  to  all  recipients:  local(8), virtual, and
+#               remote.
 # 
 #        allow_mail_to_commands (alias, forward)
 #               Restrict local(8) mail delivery  to  external  com-
@@ -218,18 +238,17 @@ decode:		root
 #               the recipient_delimiter is set to "-".
 # 
 #        recipient_delimiter (empty)
-#               The set of characters that can separate a user name
-#               from its extension (example: user+foo), or a  .for-
-#               ward  file  name from its extension (example: .for-
-#               ward+foo).
+#               The  set  of  characters that can separate an email
+#               address localpart, user name, or  a  .forward  file
+#               name from its extension.
 # 
 #        Available in Postfix version 2.3 and later:
 # 
 #        frozen_delivered_to (yes)
-#               Update the local(8) delivery agent's  idea  of  the
-#               Delivered-To:     address    (see    prepend_deliv-
-#               ered_header) only once, at the start of a  delivery
-#               attempt;  do  not  update the Delivered-To: address
+#               Update  the  local(8)  delivery agent's idea of the
+#               Delivered-To:    address    (see     prepend_deliv-
+#               ered_header)  only once, at the start of a delivery
+#               attempt; do not update  the  Delivered-To:  address
 #               while expanding aliases or .forward files.
 # 
 # STANDARDS
@@ -242,12 +261,12 @@ decode:		root
 #        postconf(5), configuration parameters
 # 
 # README FILES
-#        Use "postconf readme_directory" or  "postconf  html_direc-
+#        Use  "postconf  readme_directory" or "postconf html_direc-
 #        tory" to locate this information.
 #        DATABASE_README, Postfix lookup table overview
 # 
 # LICENSE
-#        The  Secure  Mailer  license must be distributed with this
+#        The Secure Mailer license must be  distributed  with  this
 #        software.
 # 
 # AUTHOR(S)

postfix/conf/canonical

@@ -29,7 +29,7 @@
 # 
 #        Alternatively,  the  table  can  be  provided  as  a regu-
 #        lar-expression map where patterns  are  given  as  regular
-#        expressions,  or  lookups  can  be  directed  to TCP-based
+#        expressions,  or  lookups  can  be directed to a TCP-based
 #        server. In those cases, the lookups are done in a slightly
 #        different way as described below under "REGULAR EXPRESSION
 #        TABLES" or "TCP-BASED TABLES".
@@ -121,13 +121,29 @@
 #               recipients and then tries to return  that  mail  as
 #               "undeliverable" to the often forged sender address.
 # 
+#               To avoid backscatter  with  mail  for  a  wild-card
+#               domain, replace the wild-card mapping with explicit
+#               1:1 mappings, or add a  reject_unverified_recipient
+#               restriction for that domain:
+# 
+#                   smtpd_recipient_restrictions =
+#                       ...
+#                       reject_unauth_destination
+#                       check_recipient_access
+#                           inline:{example.com=reject_unverified_recipient}
+#                   unverified_recipient_reject_code = 550
+# 
+#               In  the above example, Postfix may contact a remote
+#               server if the recipient is rewritten  to  a  remote
+#               address.
+# 
 # RESULT ADDRESS REWRITING
 #        The lookup result is subject to address rewriting:
 # 
-#        o      When the result  has  the  form  @otherdomain,  the
+#        o      When  the  result  has  the  form @otherdomain, the
 #               result becomes the same user in otherdomain.
 # 
-#        o      When  "append_at_myorigin=yes", append "@$myorigin"
+#        o      When "append_at_myorigin=yes", append  "@$myorigin"
 #               to addresses without "@domain".
 # 
 #        o      When "append_dot_mydomain=yes", append ".$mydomain"
@@ -135,128 +151,130 @@
 # 
 # ADDRESS EXTENSION
 #        When a mail address localpart contains the optional recip-
-#        ient delimiter (e.g., user+foo@domain), the  lookup  order
+#        ient  delimiter  (e.g., user+foo@domain), the lookup order
 #        becomes: user+foo@domain, user@domain, user+foo, user, and
 #        @domain.
 # 
-#        The  propagate_unmatched_extensions   parameter   controls
-#        whether  an  unmatched  address extension (+foo) is propa-
+#        The   propagate_unmatched_extensions   parameter  controls
+#        whether an unmatched address extension  (+foo)  is  propa-
 #        gated to the result of table lookup.
 # 
 # REGULAR EXPRESSION TABLES
-#        This section describes how the table lookups  change  when
+#        This  section  describes how the table lookups change when
 #        the table is given in the form of regular expressions. For
-#        a description of regular expression lookup  table  syntax,
+#        a  description  of regular expression lookup table syntax,
 #        see regexp_table(5) or pcre_table(5).
 # 
-#        Each  pattern  is  a regular expression that is applied to
+#        Each pattern is a regular expression that  is  applied  to
 #        the entire address being looked up. Thus, user@domain mail
-#        addresses  are  not  broken up into their user and @domain
+#        addresses are not broken up into their  user  and  @domain
 #        constituent parts, nor is user+foo broken up into user and
 #        foo.
 # 
-#        Patterns  are applied in the order as specified in the ta-
-#        ble, until a pattern is  found  that  matches  the  search
+#        Patterns are applied in the order as specified in the  ta-
+#        ble,  until  a  pattern  is  found that matches the search
 #        string.
 # 
-#        Results  are  the  same as with indexed file lookups, with
-#        the additional feature that parenthesized substrings  from
+#        Results are the same as with indexed  file  lookups,  with
+#        the  additional feature that parenthesized substrings from
 #        the pattern can be interpolated as $1, $2 and so on.
 # 
 # TCP-BASED TABLES
-#        This  section  describes how the table lookups change when
+#        This section describes how the table lookups  change  when
 #        lookups are directed to a TCP-based server. For a descrip-
 #        tion of the TCP client/server lookup protocol, see tcp_ta-
 #        ble(5).  This feature is not available up to and including
 #        Postfix version 2.4.
 # 
 #        Each lookup operation uses the entire address once.  Thus,
-#        user@domain mail addresses are not broken  up  into  their
+#        user@domain  mail  addresses  are not broken up into their
 #        user and @domain constituent parts, nor is user+foo broken
 #        up into user and foo.
 # 
 #        Results are the same as with indexed file lookups.
 # 
 # BUGS
-#        The table format does not understand quoting  conventions.
+#        The  table format does not understand quoting conventions.
 # 
 # CONFIGURATION PARAMETERS
-#        The  following main.cf parameters are especially relevant.
-#        The text below provides  only  a  parameter  summary.  See
+#        The following main.cf parameters are especially  relevant.
+#        The  text  below  provides  only  a parameter summary. See
 #        postconf(5) for more details including examples.
 # 
-#        canonical_classes
-#               What  addresses  are  subject  to canonical address
-#               mapping.
+#        canonical_classes  (envelope_sender,   envelope_recipient,
+#        header_sender, header_recipient)
+#               What  addresses  are  subject   to   canonical_maps
+#               address mapping.
 # 
-#        canonical_maps
-#               List of canonical mapping tables.
+#        canonical_maps (empty)
+#               Optional  address mapping lookup tables for message
+#               headers and envelopes.
 # 
-#        recipient_canonical_maps
-#               Address  mapping  lookup  table  for  envelope  and
-#               header recipient addresses.
+#        recipient_canonical_maps (empty)
+#               Optional address mapping lookup tables for envelope
+#               and header recipient addresses.
 # 
-#        sender_canonical_maps
-#               Address  mapping  lookup  table  for  envelope  and
-#               header sender addresses.
+#        sender_canonical_maps (empty)
+#               Optional address mapping lookup tables for envelope
+#               and header sender addresses.
 # 
-#        propagate_unmatched_extensions
-#               A list of address rewriting  or  forwarding  mecha-
-#               nisms  that propagate an address extension from the
-#               original address to the result.   Specify  zero  or
-#               more   of   canonical,   virtual,  alias,  forward,
-#               include, or generic.
+#        propagate_unmatched_extensions (canonical, virtual)
+#               What address lookup tables copy an  address  exten-
+#               sion from the lookup key to the lookup result.
 # 
 #        Other parameters of interest:
 # 
-#        inet_interfaces
-#               The network interface addresses  that  this  system
-#               receives mail on.  You need to stop and start Post-
-#               fix when this parameter changes.
+#        inet_interfaces (all)
+#               The  local  network  interface  addresses that this
+#               mail system receives mail on.
 # 
-#        local_header_rewrite_clients
-#               Rewrite message header addresses in mail from these
-#               clients  and  update  incomplete addresses with the
-#               domain name in $myorigin or $mydomain; either don't
-#               rewrite  message headers from other clients at all,
-#               or rewrite message headers  and  update  incomplete
-#               addresses   with   the   domain  specified  in  the
-#               remote_header_rewrite_domain parameter.
+#        local_header_rewrite_clients (permit_inet_interfaces)
+#               Rewrite or add message headers in mail  from  these
+#               clients,  updating  incomplete  addresses  with the
+#               domain name in $myorigin or $mydomain,  and  adding
+#               missing headers.
 # 
-#        proxy_interfaces
-#               Other interfaces that this machine receives mail on
-#               by way of a proxy agent or network address transla-
-#               tor.
+#        proxy_interfaces (empty)
+#               The  remote  network  interface addresses that this
+#               mail system receives mail on by way of a  proxy  or
+#               network address translation unit.
 # 
-#        masquerade_classes
-#               List of address classes  subject  to  masquerading:
-#               zero  or  more of envelope_sender, envelope_recipi-
-#               ent, header_sender, header_recipient.
+#        masquerade_classes     (envelope_sender,    header_sender,
+#        header_recipient)
+#               What addresses are subject to address masquerading.
 # 
-#        masquerade_domains
-#               List of domains that hide  their  subdomain  struc-
-#               ture.
+#        masquerade_domains (empty)
+#               Optional list of domains whose subdomain  structure
+#               will be stripped off in email addresses.
 # 
-#        masquerade_exceptions
-#               List  of user names that are not subject to address
-#               masquerading.
+#        masquerade_exceptions (empty)
+#               Optional  list of user names that are not subjected
+#               to address masquerading, even when their  addresses
+#               match $masquerade_domains.
 # 
-#        mydestination
-#               List of domains that  this  mail  system  considers
-#               local.
+#        mydestination  ($myhostname,  localhost.$mydomain,  local-
+#        host)
+#               The  list  of  domains  that  are delivered via the
+#               $local_transport mail delivery transport.
 # 
-#        myorigin
-#               The domain that is appended to locally-posted mail.
+#        myorigin ($myhostname)
+#               The domain name that locally-posted mail appears to
+#               come  from,  and that locally posted mail is deliv-
+#               ered to.
 # 
-#        owner_request_special
-#               Give special treatment to owner-xxx and xxx-request
-#               addresses.
+#        owner_request_special (yes)
+#               Enable special treatment for owner-listname entries
+#               in the aliases(5) file, and don't split owner-list-
+#               name and listname-request address  localparts  when
+#               the recipient_delimiter is set to "-".
 # 
-#        remote_header_rewrite_domain
-#               Don't  rewrite  message headers from remote clients
-#               at all when this parameter is empty; otherwise, re-
-#               write  message  headers  and  append  the specified
-#               domain name to incomplete addresses.
+#        remote_header_rewrite_domain (empty)
+#               Rewrite  or add message headers in mail from remote
+#               clients if the remote_header_rewrite_domain parame-
+#               ter   value   is   non-empty,  updating  incomplete
+#               addresses  with  the  domain   specified   in   the
+#               remote_header_rewrite_domain  parameter, and adding
+#               missing headers.
 # 
 # SEE ALSO
 #        cleanup(8), canonicalize and enqueue mail

postfix/conf/dynamicmaps.cf

@@ -2,6 +2,7 @@
 cdb	${LIB_PREFIX}cdb${LIB_SUFFIX}	dict_cdb_open	mkmap_cdb_open
 ldap	${LIB_PREFIX}ldap${LIB_SUFFIX}	dict_ldap_open
 lmdb	${LIB_PREFIX}lmdb${LIB_SUFFIX}	dict_lmdb_open	mkmap_lmdb_open
+mongodb	${LIB_PREFIX}mongodb${LIB_SUFFIX}	dict_mongodb_open
 mysql	${LIB_PREFIX}mysql${LIB_SUFFIX}	dict_mysql_open
 pcre	${LIB_PREFIX}pcre${LIB_SUFFIX}	dict_pcre_open
 pgsql	${LIB_PREFIX}pgsql${LIB_SUFFIX}	dict_pgsql_open

postfix/conf/generic

@@ -42,8 +42,8 @@
 # 
 #        Alternatively, the  table  can  be  provided  as  a  regu-
 #        lar-expression  map  where  patterns  are given as regular
-#        expressions, or  lookups  can  be  directed  to  TCP-based
-#        server.  In those case, the lookups are done in a slightly
+#        expressions, or lookups can be  directed  to  a  TCP-based
+#        server. In those cases, the lookups are done in a slightly
 #        different way as described below under "REGULAR EXPRESSION
 #        TABLES" or "TCP-BASED TABLES".
 # 
@@ -140,8 +140,8 @@
 #        This  section  describes how the table lookups change when
 #        lookups are directed to a TCP-based server. For a descrip-
 #        tion of the TCP client/server lookup protocol, see tcp_ta-
-#        ble(5).  This feature is not available up to and including
-#        Postfix version 2.4.
+#        ble(5).  This feature is  available  in  Postfix  2.5  and
+#        later.
 # 
 #        Each lookup operation uses the entire address once.  Thus,
 #        user@domain mail addresses are not broken  up  into  their
@@ -180,40 +180,42 @@
 #        The  text  below  provides  only  a parameter summary. See
 #        postconf(5) for more details including examples.
 # 
-#        smtp_generic_maps
-#               Address  mapping  lookup  table  for  envelope  and
-#               header  sender and recipient addresses while deliv-
-#               ering mail via SMTP.
+#        smtp_generic_maps (empty)
+#               Optional lookup tables that perform address rewrit-
+#               ing in the Postfix SMTP client, typically to trans-
+#               form a locally valid address into a globally  valid
+#               address when sending mail across the Internet.
 # 
-#        propagate_unmatched_extensions
-#               A list of address rewriting  or  forwarding  mecha-
-#               nisms  that propagate an address extension from the
-#               original address to the result.   Specify  zero  or
-#               more   of   canonical,   virtual,  alias,  forward,
-#               include, or generic.
+#        propagate_unmatched_extensions (canonical, virtual)
+#               What  address  lookup tables copy an address exten-
+#               sion from the lookup key to the lookup result.
 # 
 #        Other parameters of interest:
 # 
-#        inet_interfaces
-#               The network interface addresses  that  this  system
-#               receives mail on.  You need to stop and start Post-
-#               fix when this parameter changes.
+#        inet_interfaces (all)
+#               The local network  interface  addresses  that  this
+#               mail system receives mail on.
 # 
-#        proxy_interfaces
-#               Other interfaces that this machine receives mail on
-#               by way of a proxy agent or network address transla-
-#               tor.
+#        proxy_interfaces (empty)
+#               The  remote  network  interface addresses that this
+#               mail system receives mail on by way of a  proxy  or
+#               network address translation unit.
 # 
-#        mydestination
-#               List of domains that  this  mail  system  considers
-#               local.
+#        mydestination  ($myhostname,  localhost.$mydomain,  local-
+#        host)
+#               The  list  of  domains  that  are delivered via the
+#               $local_transport mail delivery transport.
 # 
-#        myorigin
-#               The domain that is appended to locally-posted mail.
+#        myorigin ($myhostname)
+#               The domain name that locally-posted mail appears to
+#               come  from,  and that locally posted mail is deliv-
+#               ered to.
 # 
-#        owner_request_special
-#               Give special treatment to owner-xxx and xxx-request
-#               addresses.
+#        owner_request_special (yes)
+#               Enable special treatment for owner-listname entries
+#               in the aliases(5) file, and don't split owner-list-
+#               name and listname-request address  localparts  when
+#               the recipient_delimiter is set to "-".
 # 
 # SEE ALSO
 #        postmap(1), Postfix lookup table manager

postfix/conf/header_checks

@@ -346,10 +346,15 @@
 #               message is queued, it will be sent to the specified
 #               address instead of the intended recipient(s).
 # 
-#               Note: this action overrides the FILTER action,  and
-#               affects  all recipients of the message. If multiple
-#               REDIRECT actions fire, only the last  one  is  exe-
-#               cuted.
+#               Note 1: this action overrides  the  FILTER  action,
+#               and  affects all recipients of the message. If mul-
+#               tiple REDIRECT actions fire, only the last  one  is
+#               executed.
+# 
+#               Note 2: a REDIRECT address is subject to canonical-
+#               ization (add missing domain)  but  NOT  subject  to
+#               canonical,  masquerade,  bcc, or virtual alias map-
+#               ping.
 # 
 #               This feature is available in Postfix 2.1 and later.
 # 
@@ -357,34 +362,34 @@
 #               checks.
 # 
 #        REPLACE text...
-#               Replace  the  current line with the specified text,
+#               Replace the current line with the  specified  text,
 #               and inspect the next input line.
 # 
 #               This feature is available in Postfix 2.2 and later.
-#               The  description below applies to Postfix 2.2.2 and
+#               The description below applies to Postfix 2.2.2  and
 #               later.
 # 
 #               Notes:
 # 
-#               o      When replacing a message  header  line,  the
-#                      replacement  text  must  begin  with a valid
+#               o      When  replacing  a  message header line, the
+#                      replacement text must  begin  with  a  valid
 #                      header label.
 # 
-#               o      The replaced text remains part of the  input
-#                      stream.  Unlike  the result from the PREPEND
-#                      action, a replaced  message  header  may  be
-#                      subject  to address rewriting and may affect
-#                      the way that Postfix  adds  missing  message
+#               o      The  replaced text remains part of the input
+#                      stream. Unlike the result from  the  PREPEND
+#                      action,  a  replaced  message  header may be
+#                      subject to address rewriting and may  affect
+#                      the  way  that  Postfix adds missing message
 #                      headers.
 # 
 #        REJECT optional text...
-#               Reject  the  entire  message.  Do  not  inspect the
-#               remainder  of  the  input  message.    Reply   with
-#               optional  text...  when the optional text is speci-
+#               Reject the  entire  message.  Do  not  inspect  the
+#               remainder   of   the  input  message.   Reply  with
+#               optional text... when the optional text  is  speci-
 #               fied, otherwise reply with a generic error message.
 # 
-#               Note:   this  action  disables  further  header  or
-#               body_checks inspection of the current  message  and
+#               Note:  this  action  disables  further  header   or
+#               body_checks  inspection  of the current message and
 #               affects all recipients.
 # 
 #               Postfix version 2.3 and later support enhanced sta-
@@ -398,94 +403,80 @@
 #        STRIP optional text...
 #               Log a "strip:" record with the optional text... (or
 #               log a generic text), delete the input line from the
-#               input,  and inspect the next input line. See IGNORE
+#               input, and inspect the next input line. See  IGNORE
 #               for a silent alternative.
 # 
 #               This feature is available in Postfix 3.2 and later.
 # 
 #        WARN optional text...
-#               Log  a  "warning:" record with the optional text...
+#               Log a "warning:" record with the  optional  text...
 #               (or log a generic text), and inspect the next input
-#               line.  This  action is useful for debugging and for
-#               testing a  pattern  before  applying  more  drastic
+#               line. This action is useful for debugging  and  for
+#               testing  a  pattern  before  applying  more drastic
 #               actions.
 # 
 # BUGS
 #        Empty lines never match, because some map types mis-behave
-#        when given a zero-length search string.   This  limitation
-#        may  be  removed for regular expression tables in a future
+#        when  given  a zero-length search string.  This limitation
+#        may be removed for regular expression tables in  a  future
 #        release.
 # 
-#        Many people overlook the main limitations  of  header  and
+#        Many  people  overlook  the main limitations of header and
 #        body_checks rules.
 # 
-#        o      These  rules  operate on one logical message header
+#        o      These rules operate on one logical  message  header
 #               or one body line at a time. A decision made for one
 #               line is not carried over to the next line.
 # 
-#        o      If  text  in the message body is encoded (RFC 2045)
+#        o      If text in the message body is encoded  (RFC  2045)
 #               then the rules need to be specified for the encoded
 #               form.
 # 
-#        o      Likewise,  when  message  headers  are encoded (RFC
-#               2047) then the rules need to be specified  for  the
+#        o      Likewise, when message  headers  are  encoded  (RFC
+#               2047)  then  the rules need to be specified for the
 #               encoded form.
 # 
-#        Message  headers added by the cleanup(8) daemon itself are
+#        Message headers added by the cleanup(8) daemon itself  are
 #        excluded from inspection. Examples of such message headers
 #        are From:, To:, Message-ID:, Date:.
 # 
-#        Message  headers  deleted by the cleanup(8) daemon will be
+#        Message headers deleted by the cleanup(8) daemon  will  be
 #        examined before they are deleted. Examples are: Bcc:, Con-
 #        tent-Length:, Return-Path:.
 # 
 # CONFIGURATION PARAMETERS
-#        body_checks
-#               Lookup tables with content filter rules for message
-#               body lines.  These filters see one physical line at
-#               a  time,  in  chunks  of at most $line_length_limit
-#               bytes.
+#        body_checks (empty)
+#               Optional lookup tables for  content  inspection  as
+#               specified in the body_checks(5) manual page.
 # 
-#        body_checks_size_limit
-#               The amount of  content  per  message  body  segment
-#               (attachment) that is subjected to $body_checks fil-
-#               tering.
+#        body_checks_size_limit (51200)
+#               How much text in a message body segment (or attach-
+#               ment, if you prefer to use that term) is  subjected
+#               to body_checks inspection.
 # 
-#        header_checks
+#        header_checks (empty)
+#               Optional  lookup  tables  for content inspection of
+#               primary non-MIME message headers, as  specified  in
+#               the header_checks(5) manual page.
 # 
-#        mime_header_checks (default: $header_checks)
+#        mime_header_checks ($header_checks)
+#               Optional  lookup  tables  for content inspection of
+#               MIME related message headers, as described  in  the
+#               header_checks(5) manual page.
 # 
-#        nested_header_checks (default: $header_checks)
-#               Lookup tables with content filter rules for message
-#               header  lines:  respectively,  these are applied to
-#               the initial message  headers  (not  including  MIME
-#               headers),  to the MIME headers anywhere in the mes-
-#               sage, and to the initial headers of  attached  mes-
-#               sages.
+#        nested_header_checks ($header_checks)
+#               Optional  lookup  tables  for content inspection of
+#               non-MIME message headers in attached  messages,  as
+#               described in the header_checks(5) manual page.
 # 
-#               Note:  these filters see one logical message header
-#               at a time, even when a message header spans  multi-
-#               ple  lines.  Message  headers  that are longer than
-#               $header_size_limit characters are truncated.
-# 
-#        disable_mime_input_processing
-#               While receiving mail, give no special treatment  to
-#               MIME  related  message  headers; all text after the
-#               initial message headers is considered to be part of
-#               the  message body. This means that header_checks is
-#               applied to all the  initial  message  headers,  and
-#               that body_checks is applied to the remainder of the
-#               message.
-# 
-#               Note: when used in this  manner,  body_checks  will
-#               process  a  multi-line message header one line at a
-#               time.
+#        disable_mime_input_processing (no)
+#               Turn off MIME processing while receiving mail.
 # 
 # EXAMPLES
-#        Header pattern to block attachments  with  bad  file  name
-#        extensions.   For  convenience, the PCRE /x flag is speci-
-#        fied, so that there is no need  to  collapse  the  pattern
-#        into   a   single  line  of  text.   The  purpose  of  the
+#        Header  pattern  to  block  attachments with bad file name
+#        extensions.  For convenience, the PCRE /x flag  is  speci-
+#        fied,  so  that  there  is no need to collapse the pattern
+#        into  a  single  line  of  text.   The  purpose   of   the
 #        [[:xdigit:]] sub-expressions is to recognize Windows CLSID
 #        strings.
 # 
@@ -524,7 +515,7 @@
 #        RFC 2047, message header encoding for non-ASCII text
 # 
 # README FILES
-#        Use "postconf readme_directory" or  "postconf  html_direc-
+#        Use  "postconf  readme_directory" or "postconf html_direc-
 #        tory" to locate this information.
 #        DATABASE_README, Postfix lookup table overview
 #        CONTENT_INSPECTION_README, Postfix content inspection overview
@@ -532,7 +523,7 @@
 #        BACKSCATTER_README, blocking returned forged mail
 # 
 # LICENSE
-#        The  Secure  Mailer  license must be distributed with this
+#        The Secure Mailer license must be  distributed  with  this
 #        software.
 # 
 # AUTHOR(S)

postfix/conf/main.cf

@@ -2,10 +2,14 @@
 # of all parameters. For the syntax, and for a complete parameter
 # list, see the postconf(5) manual page (command: "man 5 postconf").
 #
+# TIP: use the command "postconf -n" to view main.cf parameter
+# settings, "postconf parametername" to view a specific parameter,
+# and "postconf 'parametername=value'" to set a specific parameter.
+#
 # For common configuration examples, see BASIC_CONFIGURATION_README
 # and STANDARD_CONFIGURATION_README. To find these documents, use
 # the command "postconf html_directory readme_directory", or go to
-# http://www.postfix.org/BASIC_CONFIGURATION_README.html etc.
+# https://www.postfix.org/BASIC_CONFIGURATION_README.html etc.
 #
 # For best results, change no more than 2-3 parameters at a time,
 # and test if Postfix still works after every change.
@@ -27,7 +31,7 @@
 #
 # The level below is what should be used with new (not upgrade) installs.
 #
-compatibility_level = 2
+compatibility_level = 3.11
 
 # SOFT BOUNCE
 #
@@ -247,11 +251,14 @@ unknown_local_recipient_reject_code = 550
 # You can specify the list of "trusted" network addresses by hand
 # or you can let Postfix do it for you (which is the default).
 #
-# By default (mynetworks_style = subnet), Postfix "trusts" SMTP
-# clients in the same IP subnetworks as the local machine.
-# On Linux, this does works correctly only with interfaces specified
-# with the "ifconfig" command.
+# By default (mynetworks_style = host), Postfix "trusts" only
+# the local machine.
 # 
+# Specify "mynetworks_style = subnet" when Postfix should "trust"
+# SMTP clients in the same IP subnetworks as the local machine.
+# On Linux, this works correctly only with interfaces specified
+# with the "ifconfig" or "ip" command.
+#
 # Specify "mynetworks_style = class" when Postfix should "trust" SMTP
 # clients in the same IP class A/B/C networks as the local machine.
 # Don't do this with a dialup site - it would cause Postfix to "trust"
@@ -276,19 +283,21 @@ unknown_local_recipient_reject_code = 550
 # of listing the patterns here. Specify type:table for table-based lookups
 # (the value on the table right-hand side is not used).
 #
-#mynetworks = 168.100.189.0/28, 127.0.0.0/8
+#mynetworks = 168.100.3.0/28, 127.0.0.0/8
 #mynetworks = $config_directory/mynetworks
 #mynetworks = hash:/etc/postfix/network_table
 
 # The relay_domains parameter restricts what destinations this system will
-# relay mail to.  See the smtpd_recipient_restrictions description in
-# postconf(5) for detailed information.
+# relay mail to.  See the smtpd_relay_restrictions and
+# smtpd_recipient_restrictions descriptions in  postconf(5) for detailed
+# information.
 #
 # By default, Postfix relays mail
-# - from "trusted" clients (IP address matches $mynetworks) to any destination,
+# - from "trusted" clients (IP address matches $mynetworks, or is
+#   SASL authenticated) to any destination,
 # - from "untrusted" clients to destinations that match $relay_domains or
 #   subdomains thereof, except addresses with sender-specified routing.
-# The default relay_domains value is $mydestination.
+# The default relay_domains value is empty.
 # 
 # In addition to the above, the Postfix SMTP server by default accepts mail
 # that Postfix is final destination for:
@@ -308,7 +317,7 @@ unknown_local_recipient_reject_code = 550
 # list this system as their primary or backup MX host. See the
 # permit_mx_backup restriction description in postconf(5).
 #
-#relay_domains = $mydestination
+#relay_domains = 
 
 # INTERNET OR INTRANET
 
@@ -443,7 +452,7 @@ unknown_local_recipient_reject_code = 550
 # The mailbox_command parameter specifies the optional external
 # command to use instead of mailbox delivery. The command is run as
 # the recipient with proper HOME, SHELL and LOGNAME environment settings.
-# Exception:  delivery for root is done as $default_user.
+# Exception:  delivery for root is done as $default_privs.
 #
 # Other environment variables of interest: USER (recipient username),
 # EXTENSION (address extension), DOMAIN (domain part of address),

postfix/conf/master.cf

@@ -1,7 +1,7 @@
 #
 # Postfix master process configuration file.  For details on the format
 # of the file, see the master(5) manual page (command: "man 5 master" or
-# on-line: http://www.postfix.org/master.5.html).
+# on-line: https://www.postfix.org/master.5.html).
 #
 # Do not forget to execute "postfix reload" after editing this file.
 #
@@ -14,28 +14,46 @@ smtp      inet  n       -       n       -       -       smtpd
 #smtpd     pass  -       -       n       -       -       smtpd
 #dnsblog   unix  -       -       n       -       0       dnsblog
 #tlsproxy  unix  -       -       n       -       0       tlsproxy
+# Choose one: enable submission for loopback clients only, or for any client.
+#127.0.0.1:submission inet n -   n       -       -       smtpd
 #submission inet n       -       n       -       -       smtpd
 #  -o syslog_name=postfix/submission
+#  -o smtpd_forbid_unauth_pipelining=no
 #  -o smtpd_tls_security_level=encrypt
 #  -o smtpd_sasl_auth_enable=yes
 #  -o smtpd_tls_auth_only=yes
+#  -o local_header_rewrite_clients=static:all
+#  -o smtpd_hide_client_session=yes
 #  -o smtpd_reject_unlisted_recipient=no
-#  -o smtpd_client_restrictions=$mua_client_restrictions
-#  -o smtpd_helo_restrictions=$mua_helo_restrictions
-#  -o smtpd_sender_restrictions=$mua_sender_restrictions
-#  -o smtpd_recipient_restrictions=
-#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
+#     Instead of specifying complex smtpd_<xxx>_restrictions here,
+#     specify "smtpd_<xxx>_restrictions=$mua_<xxx>_restrictions"
+#     here, and specify mua_<xxx>_restrictions in main.cf (where
+#     "<xxx>" is "client", "helo", "sender", "relay", or "recipient").
+#  -o smtpd_client_restrictions=
+#  -o smtpd_helo_restrictions=
+#  -o smtpd_sender_restrictions=
+#  -o smtpd_relay_restrictions=
+#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
 #  -o milter_macro_daemon_name=ORIGINATING
-#smtps     inet  n       -       n       -       -       smtpd
-#  -o syslog_name=postfix/smtps
+# Choose one: enable submissions for loopback clients only, or for any client.
+#127.0.0.1:submissions inet n  -       n       -       -       smtpd
+#submissions     inet  n       -       n       -       -       smtpd
+#  -o syslog_name=postfix/submissions
+#  -o smtpd_forbid_unauth_pipelining=no
 #  -o smtpd_tls_wrappermode=yes
 #  -o smtpd_sasl_auth_enable=yes
+#  -o local_header_rewrite_clients=static:all
+#  -o smtpd_hide_client_session=yes
 #  -o smtpd_reject_unlisted_recipient=no
-#  -o smtpd_client_restrictions=$mua_client_restrictions
-#  -o smtpd_helo_restrictions=$mua_helo_restrictions
-#  -o smtpd_sender_restrictions=$mua_sender_restrictions
-#  -o smtpd_recipient_restrictions=
-#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
+#     Instead of specifying complex smtpd_<xxx>_restrictions here,
+#     specify "smtpd_<xxx>_restrictions=$mua_<xxx>_restrictions"
+#     here, and specify mua_<xxx>_restrictions in main.cf (where
+#     "<xxx>" is "client", "helo", "sender", "relay", or "recipient").
+#  -o smtpd_client_restrictions=
+#  -o smtpd_helo_restrictions=
+#  -o smtpd_sender_restrictions=
+#  -o smtpd_relay_restrictions=
+#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
 #  -o milter_macro_daemon_name=ORIGINATING
 #628       inet  n       -       n       -       -       qmqpd
 pickup    unix  n       -       n       60      1       pickup
@@ -53,7 +71,7 @@ proxymap  unix  -       -       n       -       -       proxymap
 proxywrite unix -       -       n       -       1       proxymap
 smtp      unix  -       -       n       -       -       smtp
 relay     unix  -       -       n       -       -       smtp
-        -o syslog_name=postfix/$service_name
+        -o syslog_name=${multi_instance_name?{$multi_instance_name}:{postfix}}/$service_name
 #       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
 showq     unix  n       -       n       -       -       showq
 error     unix  -       -       n       -       -       error
@@ -64,6 +82,7 @@ virtual   unix  -       n       n       -       -       virtual
 lmtp      unix  -       -       n       -       -       lmtp
 anvil     unix  -       -       n       -       1       anvil
 scache    unix  -       -       n       -       1       scache
+postlog   unix-dgram n  -       n       -       1       postlogd
 #
 # ====================================================================
 # Interfaces to non-Postfix software. Be sure to examine the manual
@@ -78,7 +97,7 @@ scache    unix  -       -       n       -       1       scache
 # Also specify in main.cf: maildrop_destination_recipient_limit=1
 #
 #maildrop  unix  -       n       n       -       -       pipe
-#  flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
+#  flags=DRXhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
 #
 # ====================================================================
 #
@@ -97,7 +116,7 @@ scache    unix  -       -       n       -       1       scache
 # Also specify in main.cf: cyrus_destination_recipient_limit=1
 #
 #cyrus     unix  -       n       n       -       -       pipe
-#  user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user}
+#  flags=DRX user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user}
 #
 # ====================================================================
 #
@@ -128,5 +147,5 @@ scache    unix  -       -       n       -       1       scache
 #  ${nexthop} ${user} ${extension}
 #
 #mailman   unix  -       n       n       -       -       pipe
-#  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
+#  flags=FRX user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
 #  ${nexthop} ${user}

postfix/conf/post-install

@@ -144,7 +144,7 @@
 #	should not be in the command search path of any users.
 # .IP command_directory
 #	The directory for Postfix administrative commands. This
-#	directory should be in the command search path of adminstrative users.
+#	directory should be in the command search path of administrative users.
 # .IP queue_directory
 #	The directory for Postfix queues.
 # .IP data_directory
@@ -205,6 +205,10 @@
 #	Google, Inc.
 #	111 8th Avenue
 #	New York, NY 10011, USA
+#
+#	Wietse Venema
+#	porcupine.org
+#	Amawalk, NY 10501, USA
 #--
 
 umask 022
@@ -291,8 +295,8 @@ test -d "$config_directory" || {
 # XXX Solaris does not have "test -e".
 
 instances=`test ! -f $def_config_directory/main.cf || 
-    $POSTCONF -c $def_config_directory -h multi_instance_directories | 
-	sed 's/,/ /'` || exit 1
+    $POSTCONF -qc $def_config_directory -h multi_instance_directories | 
+	sed 'y/,/ /'` || exit 1
 
 update_shared_files=1
 for name in $instances
@@ -360,7 +364,7 @@ test -f $config_directory/main.cf && {
         case "$junk" in
         "") eval unset $name;;
         esac
-        eval : \${$name=\`$POSTCONF -c $config_directory -h $name\`} || exit 1
+        eval : \${$name=\`$POSTCONF -qc $config_directory -h $name\`} || exit 1
     done
 }
 
@@ -461,14 +465,14 @@ override=
 for name in $MOST_PARAMETERS
 do
     eval junk=\"\$$name\"
-    test "$junk" = "`$POSTCONF -c $config_directory -h $name`" || {
+    test "$junk" = "`$POSTCONF -qc $config_directory -h $name`" || {
 	override=1
 	break
     }
 done
 
 test -n "$override" && {
-    $POSTCONF -c $config_directory -e \
+    $POSTCONF -qc $config_directory -e \
 	"daemon_directory = $daemon_directory" \
 	"command_directory = $command_directory" \
 	"queue_directory = $queue_directory" \
@@ -679,13 +683,13 @@ EOF
     # require now is that defer and deferred are hashed because those
     # can contain lots of files.
 
-    found=`$POSTCONF -c $config_directory -h hash_queue_names`
+    found=`$POSTCONF -qc $config_directory -h hash_queue_names`
     missing=
     (echo "$found" | grep defer >/dev/null)  || missing="$missing defer"
     (echo "$found" | grep deferred>/dev/null)|| missing="$missing deferred"
     test -n "$missing" && {
 	echo fixing main.cf hash_queue_names for missing $missing
-	$POSTCONF -c $config_directory -e hash_queue_names="$found$missing" ||
+	$POSTCONF -qc $config_directory -e hash_queue_names="$found$missing" ||
 	    exit 1
     }
 
@@ -857,14 +861,14 @@ EOF
     # when IPv6 support is not compiled in. See util/sys_defs.h.
 
     test "`$POSTCONF -dh inet_protocols`" = "ipv4" ||
-	test -n "`$POSTCONF -c $config_directory -n inet_protocols`" || {
+	test -n "`$POSTCONF -qc $config_directory -n inet_protocols`" || {
 	cat <<EOF | ${FMT}
     COMPATIBILITY: editing $config_directory/main.cf, setting
     inet_protocols=ipv4.  Specify inet_protocols explicitly if you
     want to enable IPv6.
     In a future release IPv6 will be enabled by default.
 EOF
-	$POSTCONF -c $config_directory inet_protocols=ipv4 || exit 1
+	$POSTCONF -qc $config_directory inet_protocols=ipv4 || exit 1
     }
 
 # Disabled because unhelpful down-stream maintainers disable the safety net.
@@ -875,7 +879,7 @@ EOF
 #    # PLEASE DO NOT REMOVE THIS CODE. ITS PURPOSE IS TO PREVENT
 #    # INBOUND MAIL FROM UNEXPECTEDLY BOUNCING AFTER UPGRADING FROM
 #    # POSTFIX BEFORE 2.10.
-#    test -n "`$POSTCONF -c $config_directory -n smtpd_relay_restrictions`" || {
+#    test -n "`$POSTCONF -qc $config_directory -n smtpd_relay_restrictions`" || {
 #	cat <<EOF | ${FMT}
 #    COMPATIBILITY: editing $config_directory/main.cf, overriding
 #    smtpd_relay_restrictions to prevent inbound mail from
@@ -883,24 +887,34 @@ EOF
 #    Specify an empty smtpd_relay_restrictions value to keep using 
 #    smtpd_recipient_restrictions as before.
 #EOF
-#	$POSTCONF -c $config_directory "smtpd_relay_restrictions = \
+#	$POSTCONF -qc $config_directory "smtpd_relay_restrictions = \
 #	    permit_mynetworks permit_sasl_authenticated \
 #	    defer_unauth_destination" || exit 1
 #    }
+
+    # Postfix 3.4
+    # Add a postlog service entry.
+
+    grep '^postlog' $config_directory/master.cf >/dev/null || {
+	echo Editing $config_directory/master.cf, adding missing entry for postlog unix-domain datagram service
+	cat >>$config_directory/master.cf <<EOF || exit 1
+postlog   unix-dgram n  -       n       -       1       postlogd
+EOF
+    }
 }
 
 # A reminder if this is the first time Postfix is being installed.
 
 test -n "$first_install_reminder" && {
 
-    ALIASES=`$POSTCONF -c $config_directory -h alias_database | sed 's/^[^:]*://'`
-    NEWALIASES_PATH=`$POSTCONF -c $config_directory -h newaliases_path`
+    ALIASES=`$POSTCONF -qc $config_directory -h alias_database | sed 's/^[^:]*://'`
+    NEWALIASES_PATH=`$POSTCONF -qc $config_directory -h newaliases_path`
     cat <<EOF | ${FMT}
 
     Warning: you still need to edit myorigin/mydestination/mynetworks
     parameter settings in $config_directory/main.cf.
 
-    See also http://www.postfix.org/STANDARD_CONFIGURATION_README.html
+    See also https://www.postfix.org/STANDARD_CONFIGURATION_README.html
     for information about dialup sites or about sites inside a
     firewalled network.
 

postfix/conf/postfix-files

@@ -75,6 +75,7 @@ $shlib_directory/lib${LIB_PREFIX}master${LIB_SUFFIX}:f:root:-:755
 $shlib_directory/${LIB_PREFIX}cdb${LIB_SUFFIX}:f:root:-:755
 $shlib_directory/${LIB_PREFIX}ldap${LIB_SUFFIX}:f:root:-:755
 $shlib_directory/${LIB_PREFIX}lmdb${LIB_SUFFIX}:f:root:-:755
+$shlib_directory/${LIB_PREFIX}mongodb${LIB_SUFFIX}:f:root:-:755
 $shlib_directory/${LIB_PREFIX}mysql${LIB_SUFFIX}:f:root:-:755
 $shlib_directory/${LIB_PREFIX}pcre${LIB_SUFFIX}:f:root:-:755
 $shlib_directory/${LIB_PREFIX}pgsql${LIB_SUFFIX}:f:root:-:755
@@ -109,6 +110,7 @@ $daemon_directory/postfix-script:f:root:-:755
 $daemon_directory/postfix-tls-script:f:root:-:755
 $daemon_directory/postfix-wrapper:f:root:-:755
 $daemon_directory/postmulti-script:f:root:-:755
+$daemon_directory/postlogd:f:root:-:755
 $daemon_directory/postscreen:f:root:-:755
 $daemon_directory/proxymap:f:root:-:755
 $daemon_directory/qmgr:f:root:-:755
@@ -131,7 +133,7 @@ $command_directory/postconf:f:root:-:755
 $command_directory/postfix:f:root:-:755
 $command_directory/postkick:f:root:-:755
 $command_directory/postlock:f:root:-:755
-$command_directory/postlog:f:root:-:755
+$command_directory/postlog:f:root:$setgid_group:2755:u
 $command_directory/postmap:f:root:-:755
 $command_directory/postmulti:f:root:-:755
 $command_directory/postsuper:f:root:-:755
@@ -170,8 +172,8 @@ $manpage_directory/man1/postalias.1:f:root:-:644
 $manpage_directory/man1/postcat.1:f:root:-:644
 $manpage_directory/man1/postconf.1:f:root:-:644
 $manpage_directory/man1/postdrop.1:f:root:-:644
-$manpage_directory/man1/postfix.1:f:root:-:644
 $manpage_directory/man1/postfix-tls.1:f:root:-:644
+$manpage_directory/man1/postfix.1:f:root:-:644
 $manpage_directory/man1/postkick.1:f:root:-:644
 $manpage_directory/man1/postlock.1:f:root:-:644
 $manpage_directory/man1/postlog.1:f:root:-:644
@@ -193,6 +195,7 @@ $manpage_directory/man5/ldap_table.5:f:root:-:644
 $manpage_directory/man5/lmdb_table.5:f:root:-:644
 $manpage_directory/man5/master.5:f:root:-:644
 $manpage_directory/man5/memcache_table.5:f:root:-:644
+$manpage_directory/man5/mongodb_table.5:f:root:-:644
 $manpage_directory/man5/mysql_table.5:f:root:-:644
 $manpage_directory/man5/socketmap_table.5:f:root:-:644
 $manpage_directory/man5/sqlite_table.5:f:root:-:644
@@ -221,6 +224,7 @@ $manpage_directory/man8/nqmgr.8:f:root:-:644:o
 $manpage_directory/man8/oqmgr.8:f:root:-:644:
 $manpage_directory/man8/pickup.8:f:root:-:644
 $manpage_directory/man8/pipe.8:f:root:-:644
+$manpage_directory/man8/postlogd.8:f:root:-:644
 $manpage_directory/man8/postscreen.8:f:root:-:644
 $manpage_directory/man8/proxymap.8:f:root:-:644
 $manpage_directory/man8/qmgr.8:f:root:-:644
@@ -274,6 +278,7 @@ $readme_directory/ADDRESS_REWRITING_README:f:root:-:644
 $readme_directory/ADDRESS_VERIFICATION_README:f:root:-:644
 $readme_directory/BACKSCATTER_README:f:root:-:644
 $readme_directory/BASIC_CONFIGURATION_README:f:root:-:644
+$readme_directory/BDAT_README:f:root:-:644
 $readme_directory/BUILTIN_FILTER_README:f:root:-:644
 $readme_directory/CDB_README:f:root:-:644
 $readme_directory/COMPATIBILITY_README:f:root:-:644
@@ -282,6 +287,7 @@ $readme_directory/CONTENT_INSPECTION_README:f:root:-:644
 $readme_directory/DATABASE_README:f:root:-:644
 $readme_directory/DB_README:f:root:-:644
 $readme_directory/DEBUG_README:f:root:-:644
+$readme_directory/DEPRECATION_README:f:root:-:644
 $readme_directory/DSN_README:f:root:-:644
 $readme_directory/ETRN_README:f:root:-:644
 $readme_directory/FILTER_README:f:root:-:644
@@ -295,16 +301,20 @@ $readme_directory/LMDB_README:f:root:-:644
 $readme_directory/LOCAL_RECIPIENT_README:f:root:-:644
 $readme_directory/MACOSX_README:f:root:-:644:o
 $readme_directory/MAILDROP_README:f:root:-:644
+$readme_directory/MAILLOG_README:f:root:-:644
 $readme_directory/MEMCACHE_README:f:root:-:644
 $readme_directory/MILTER_README:f:root:-:644
+$readme_directory/MONGODB_README:f:root:-:644
 $readme_directory/MULTI_INSTANCE_README:f:root:-:644
 $readme_directory/MYSQL_README:f:root:-:644
+$readme_directory/SMTPUTF8_README:f:root:-:644
 $readme_directory/SQLITE_README:f:root:-:644
 $readme_directory/NFS_README:f:root:-:644
 $readme_directory/OVERVIEW:f:root:-:644
 $readme_directory/PACKAGE_README:f:root:-:644
 $readme_directory/PCRE_README:f:root:-:644
 $readme_directory/PGSQL_README:f:root:-:644
+$readme_directory/POSTSCREEN_3_5_README:f:root:-:644
 $readme_directory/POSTSCREEN_README:f:root:-:644
 $readme_directory/QMQP_README:f:root:-:644:o
 $readme_directory/QSHAPE_README:f:root:-:644
@@ -320,6 +330,7 @@ $readme_directory/STANDARD_CONFIGURATION_README:f:root:-:644
 $readme_directory/STRESS_README:f:root:-:644
 $readme_directory/TLS_LEGACY_README:f:root:-:644
 $readme_directory/TLS_README:f:root:-:644
+$readme_directory/TLSRPT_README:f:root:-:644
 $readme_directory/TUNING_README:f:root:-:644
 $readme_directory/ULTRIX_README:f:root:-:644
 $readme_directory/UUCP_README:f:root:-:644
@@ -332,6 +343,7 @@ $html_directory/ADDRESS_REWRITING_README.html:f:root:-:644
 $html_directory/ADDRESS_VERIFICATION_README.html:f:root:-:644
 $html_directory/BACKSCATTER_README.html:f:root:-:644
 $html_directory/BASIC_CONFIGURATION_README.html:f:root:-:644
+$html_directory/BDAT_README.html:f:root:-:644
 $html_directory/BUILTIN_FILTER_README.html:f:root:-:644
 $html_directory/CDB_README.html:f:root:-:644
 $html_directory/COMPATIBILITY_README.html:f:root:-:644
@@ -341,6 +353,7 @@ $html_directory/CYRUS_README.html:f:root:-:644:o
 $html_directory/DATABASE_README.html:f:root:-:644
 $html_directory/DB_README.html:f:root:-:644
 $html_directory/DEBUG_README.html:f:root:-:644
+$html_directory/DEPRECATION_README.html:f:root:-:644
 $html_directory/DSN_README.html:f:root:-:644
 $html_directory/ETRN_README.html:f:root:-:644
 $html_directory/FILTER_README.html:f:root:-:644
@@ -352,15 +365,20 @@ $html_directory/LINUX_README.html:f:root:-:644
 $html_directory/LMDB_README.html:f:root:-:644
 $html_directory/LOCAL_RECIPIENT_README.html:f:root:-:644
 $html_directory/MAILDROP_README.html:f:root:-:644
+$html_directory/MAILLOG_README.html:f:root:-:644
+$html_directory/MEMCACHE_README.html:f:root:-:644
 $html_directory/MILTER_README.html:f:root:-:644
+$html_directory/MONGODB_README.html:f:root:-:644
 $html_directory/MULTI_INSTANCE_README.html:f:root:-:644
 $html_directory/MYSQL_README.html:f:root:-:644
+$html_directory/SMTPUTF8_README.html:f:root:-:644
 $html_directory/SQLITE_README.html:f:root:-:644
 $html_directory/NFS_README.html:f:root:-:644
 $html_directory/OVERVIEW.html:f:root:-:644
 $html_directory/PACKAGE_README.html:f:root:-:644
 $html_directory/PCRE_README.html:f:root:-:644
 $html_directory/PGSQL_README.html:f:root:-:644
+$html_directory/POSTSCREEN_3_5_README.html:f:root:-:644
 $html_directory/POSTSCREEN_README.html:f:root:-:644
 $html_directory/QMQP_README.html:f:root:-:644:o
 $html_directory/QSHAPE_README.html:f:root:-:644
@@ -375,6 +393,7 @@ $html_directory/STANDARD_CONFIGURATION_README.html:f:root:-:644
 $html_directory/STRESS_README.html:f:root:-:644
 $html_directory/TLS_LEGACY_README.html:f:root:-:644
 $html_directory/TLS_README.html:f:root:-:644
+$html_directory/TLSRPT_README.html:f:root:-:644
 $html_directory/TUNING_README.html:f:root:-:644
 $html_directory/ULTRIX_README.html:f:root:-:644:o
 $html_directory/UUCP_README.html:f:root:-:644
@@ -385,6 +404,7 @@ $html_directory/XFORWARD_README.html:f:root:-:644
 $html_directory/access.5.html:f:root:-:644
 $html_directory/aliases.5.html:f:root:-:644
 $html_directory/anvil.8.html:f:root:-:644
+$html_directory/bounce.5.html:f:root:-:644
 $html_directory/bounce.8.html:f:root:-:644
 $html_directory/canonical.5.html:f:root:-:644
 $html_directory/cidr_table.5.html:f:root:-:644
@@ -399,12 +419,14 @@ $html_directory/generic.5.html:f:root:-:644
 $html_directory/header_checks.5.html:f:root:-:644
 $html_directory/index.html:f:root:-:644
 $html_directory/ldap_table.5.html:f:root:-:644
+$html_directory/lmdb_table.5.html:f:root:-:644
 $html_directory/lmtp.8.html:f:root:-:644
 $html_directory/local.8.html:f:root:-:644
 $html_directory/mailq.1.html:f:root:-:644
 $html_directory/master.5.html:f:root:-:644
 $html_directory/master.8.html:f:root:-:644
 $html_directory/memcache_table.5.html:f:root:-:644
+$html_directory/mongodb_table.5.html:f:root:-:644
 $html_directory/mysql_table.5.html:f:root:-:644
 $html_directory/sqlite_table.5.html:f:root:-:644
 $html_directory/nisplus_table.5.html:f:root:-:644
@@ -421,13 +443,16 @@ $html_directory/postconf.5.html:f:root:-:644
 $html_directory/postdrop.1.html:f:root:-:644
 $html_directory/postfix-logo.jpg:f:root:-:644
 $html_directory/postfix-manuals.html:f:root:-:644
+$html_directory/postfix-tls.1.html:f:root:-:644
 $html_directory/postfix-wrapper.5.html:f:root:-:644
 $html_directory/postfix.1.html:f:root:-:644
+$html_directory/postfix-doc.css:f:root:-:644
 $html_directory/postkick.1.html:f:root:-:644
 $html_directory/postlock.1.html:f:root:-:644
 $html_directory/postlog.1.html:f:root:-:644
 $html_directory/postmap.1.html:f:root:-:644
 $html_directory/postmulti.1.html:f:root:-:644
+$html_directory/postlogd.8.html:f:root:-:644
 $html_directory/postqueue.1.html:f:root:-:644
 $html_directory/postscreen.8.html:f:root:-:644
 $html_directory/postsuper.1.html:f:root:-:644
@@ -439,13 +464,16 @@ $html_directory/qmqp-source.1.html:f:root:-:644
 $html_directory/qmqpd.8.html:f:root:-:644
 $html_directory/regexp_table.5.html:f:root:-:644
 $html_directory/relocated.5.html:f:root:-:644
+$html_directory/scache.8.html:f:root:-:644
 $html_directory/sendmail.1.html:h:$html_directory/mailq.1.html:-:644
 $html_directory/showq.8.html:f:root:-:644
 $html_directory/smtp-sink.1.html:f:root:-:644
 $html_directory/smtp-source.1.html:f:root:-:644
 $html_directory/smtp.8.html:h:$html_directory/lmtp.8.html:-:644
 $html_directory/smtpd.8.html:f:root:-:644
+$html_directory/socketmap_table.5.html:f:root:-:644
 $html_directory/spawn.8.html:f:root:-:644
+$html_directory/tlsmgr.8.html:f:root:-:644
 $html_directory/tlsproxy.8.html:f:root:-:644
 $html_directory/tcp_table.5.html:f:root:-:644
 $html_directory/trace.8.html:h:$html_directory/bounce.8.html:-:644

postfix/conf/postfix-script

@@ -28,6 +28,10 @@
 #	Google, Inc.
 #	111 8th Avenue
 #	New York, NY 10011, USA
+#
+#	Wietse Venema
+#	porcupine.org
+#	Amawalk, NY 10501, USA
 #--
 
 # Avoid POSIX death due to SIGHUP when some parent process exits.
@@ -92,8 +96,8 @@ def_config_directory=`$command_directory/postconf -dh config_directory` || {
 # If this is a secondary instance, don't touch shared files.
 
 instances=`test ! -f $def_config_directory/main.cf ||
-    $command_directory/postconf -c $def_config_directory \
-    -h multi_instance_directories | sed 's/,/ /'` || {
+    $command_directory/postconf -qc $def_config_directory \
+    -h multi_instance_directories | sed 'y/,/ /'` || {
 	$FATAL cannot execute $command_directory/postconf!
 	exit 1
 }
@@ -139,7 +143,7 @@ start|start-fg)
 		# Foreground this so it can be stopped. All inodes are cached.
 		$daemon_directory/postfix-script check-warn
 	fi
-	$INFO starting the Postfix mail system
+	$INFO starting the Postfix mail system || exit 1
 	case $1 in
 	start)
 	    # NOTE: wait in foreground process to get the initialization status.
@@ -150,11 +154,16 @@ start|start-fg)
 	    ;;
 	start-fg)
 	    # Foreground start-up is incompatible with multi-instance mode.
-	    # We can't use "exec $daemon_directory/master" here: that would
-	    # break process group management, and "postfix stop" would kill
-	    # too many processes.
+	    # Use "exec $daemon_directory/master" only if PID == 1.
+	    # Otherwise, doing so would break process group management,
+	    # and "postfix stop" would kill too many processes.
 	    case $instances in
-	    "") $daemon_directory/master
+	    "") case $$ in
+		 1) exec $daemon_directory/master -i
+		    $FATAL "cannot start-fg the master daemon"
+		    exit 1;;
+		 *) $daemon_directory/master -s;;
+		esac
 		;;
 	     *) $FATAL "start-fg does not support multi_instance_directories"
 		exit 1
@@ -211,6 +220,9 @@ abort)
 
 reload)
 
+	# Warn once for deprecated parameters.
+	$command_directory/postconf >/dev/null
+
 	$daemon_directory/master -t 2>/dev/null && {
 		$FATAL the Postfix mail system is not running
 		exit 1
@@ -239,6 +251,9 @@ check)
 
 status)
 
+	# Warn once for deprecated parameters.
+	$command_directory/postconf >/dev/null
+
 	$daemon_directory/master -t 2>/dev/null && {
 		$INFO the Postfix mail system is not running
 		exit 1
@@ -263,6 +278,18 @@ check-fatal)
 		exit 1
 	}
 
+	maillog_file=`$command_directory/postconf -qh maillog_file` || {
+		$FATAL cannot execute $command_directory/postconf!
+		exit 1
+	}
+	test -n "$maillog_file" && {
+		$command_directory/postconf -qM postlog/unix-dgram 2>/dev/null \
+		    | grep . >/dev/null || {
+			$FATAL "missing 'postlog' service in master.cf - run 'postfix upgrade-configuration'"
+			exit 1
+		}
+	}
+
 	# See if all queue files are in the right place. This is slow.
 	# We must scan all queues for mis-named queue files before the
 	# mail system can run.
@@ -274,6 +301,9 @@ check-fatal)
 check-warn)
 	# This command is NOT part of the public interface.
 
+	# Warn once for deprecated parameters.
+	$command_directory/postconf >/dev/null
+
 	# Check Postfix root-owned directory owner/permissions.
 
 	find $queue_directory/. $queue_directory/pid \
@@ -311,7 +341,7 @@ check-warn)
 	# Check Postfix mail_owner-owned directory tree owner.
 
 	find `ls -d $queue_directory/* | \
-	    egrep '/(saved|incoming|active|defer|deferred|bounce|hold|trace|corrupt|public|private|flush)$'` \
+	    grep -E '/(saved|incoming|active|defer|deferred|bounce|hold|trace|corrupt|public|private|flush)$'` \
 	    ! \( -type p -o -type s \) ! -user $mail_owner \
 		-exec $WARN not owned by $mail_owner: {} \;
 
@@ -388,8 +418,41 @@ tls)
 	"$@"
 	;;
 
+logrotate)
+	case $# in
+	1) ;;
+	*) $FATAL "usage postfix $1 (no arguments)"; exit 1;;
+	esac
+	for name in maillog_file maillog_file_compressor \
+	   maillog_file_rotate_suffix
+	do
+	    value="`$command_directory/postconf -qh $name`"
+	    case "$value" in
+	    "") $FATAL "empty '$name' parameter value - logfile rotation failed"
+		exit 1;;
+	    esac
+	    eval $name='"$value"';
+	done
+
+	case "$maillog_file" in
+	/dev/*) $FATAL "not rotating '$maillog_file'"; exit 1;;
+	esac
+
+	errors=`(
+	    suffix="\`date +$maillog_file_rotate_suffix\`" || exit 1
+	    mv "$maillog_file" "$maillog_file.$suffix" || exit 1
+	    $daemon_directory/master -t 2>/dev/null ||
+		kill -HUP \`sed 1q pid/master.pid\` || exit 1
+	    sleep 1
+	    "$maillog_file_compressor" "$maillog_file.$suffix" || exit 1
+	) 2>&1` || {
+	    $FATAL "logfile '$maillog_file' rotation failed: $errors"
+	    exit 1
+	}
+	;;
+
 *)
-	$FATAL "unknown command: '$1'. Usage: postfix start (or stop, reload, abort, flush, check, status, set-permissions, upgrade-configuration)"
+	$FATAL "unknown command: '$1'. Usage: postfix start (or stop, reload, abort, flush, check, status, set-permissions, upgrade-configuration, logrotate)"
 	exit 1
 	;;
 

postfix/conf/postfix-tls-script

@@ -177,10 +177,8 @@
 #	The location of the OpenSSL command line program \fBopenssl\fR(1).
 # .IP "\fBsmtp_tls_loglevel (0)\fR"
 #	Enable additional Postfix SMTP client logging of TLS activity.
-# .IP "\fBsmtp_tls_security_level (empty)\fR"
-#	The default SMTP TLS security level for the Postfix SMTP client;
-#	when a non-empty value is specified, this overrides the obsolete
-#	parameters smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername.
+# .IP "\fBsmtp_tls_security_level (Postfix >= 3.11: may; Postfix < 3.11: empty)\fR"
+#	The default SMTP TLS security level for the Postfix SMTP client.
 # .IP "\fBsmtp_tls_session_cache_database (empty)\fR"
 #	Name of the file containing the optional Postfix SMTP client
 #	TLS session cache.
@@ -333,7 +331,7 @@ $postconf -T compile-version | grep . >/dev/null || {
 }
 rsa=
 ecdsa=
-for _algo in `$postconf -T public-key-algorithms | egrep '^(rsa|ecdsa)$'`
+for _algo in `$postconf -T public-key-algorithms | grep -E '^(rsa|ecdsa)$'`
 do
     eval $_algo=$_algo
 done
@@ -415,7 +413,7 @@ pubkey_dgst() {
     for cmd in ec rsa; do
 	$openssl $cmd -passin "pass:umask 077" -in "$1" -pubout |
 	$openssl $cmd -pubin -outform DER |
-	hex_sha256 | egrep -v "${null256}" && return 0
+	hex_sha256 | grep -E -v "${null256}" && return 0
     done 2>/dev/null
     return 1
 }
@@ -429,7 +427,7 @@ cert_pubkey_dgst() {
     for cmd in ec rsa; do
 	$openssl x509 -pubkey -noout -in "$1" |
 	$openssl $cmd -pubin -outform DER |
-	hex_sha256 | egrep -v "${null256}" && return 0
+	hex_sha256 | grep -E -v "${null256}" && return 0
     done 2>/dev/null
     return 1
 }
@@ -777,7 +775,7 @@ get_cache_db_type() {
 deploy_server_cert() {
     certfile=$1; shift
     keyfile=$1; shift
-    deploy=$1; shift
+    case $# in 0) deploy=;; *) deploy=$1; shift;; esac
 
     # Sets key_algo, key_param and cert_param
     check_key "$keyfile" || return 1

postfix/conf/postfix-wrapper

@@ -188,7 +188,7 @@ POSTFIX=$command_directory/postfix
 # Canonicalize the instance directory list. The list is specified
 # in startup order.
 
-instance_dirs=`$POSTCONF -h multi_instance_directories | sed 's/,/ /'` ||
+instance_dirs=`$POSTCONF -h multi_instance_directories | sed 'y/,/ /'` ||
     exit 1
 
 case "$1" in

postfix/conf/postmulti-script

@@ -16,7 +16,7 @@ umask 022
 #  daemon_directory		- From primary instance
 #  meta_directory		- From primary instance
 #  shlib_directory		- From primary instance
-#  config_directroy		- config_directory of target instance
+#  config_directory		- config_directory of target instance
 #  queue_directory		- queue_directory of target instance
 #  data_directory		- data_directory of target instance
 #
@@ -219,7 +219,7 @@ create|import)
     # and drop from alternate_config_directories
     #
     # XXX: Must happen before set-permissions below, otherwise instance
-    # is treated as a non-slave instance by post-install via postfix(1).
+    # is treated as an independent instance by post-install via postfix(1).
     #
     update_cfdirs del $config_directory || exit 1
 
@@ -227,7 +227,7 @@ create|import)
     # queue_directory and data_directory, ...
     #
     # XXX: Must happen after instance list updates above, otherwise instance
-    # is treated as a non-slave instance by post-install via postfix(1).
+    # is treated as an independent instance by post-install via postfix(1).
     #
     postfix -c $config_directory set-permissions || exit 1
     ;;

postfix/conf/relocated

@@ -24,7 +24,7 @@
 # 
 #        Alternatively, the  table  can  be  provided  as  a  regu-
 #        lar-expression  map  where  patterns  are given as regular
-#        expressions, or  lookups  can  be  directed  to  TCP-based
+#        expressions, or lookups can be  directed  to  a  TCP-based
 #        server.  In those case, the lookups are done in a slightly
 #        different way as described below under "REGULAR EXPRESSION
 #        TABLES" or "TCP-BASED TABLES".
@@ -38,9 +38,10 @@
 #        lookup fields can match both upper and lower case.
 # 
 # TABLE FORMAT
-#        The input format for the postmap(1) command is as follows:
-# 
-#        o      An entry has one of the following form:
+#        o      By default, Postfix will prepend a hard-coded  pre-
+#               fix  "5.1.6  User  has moved to " to a table lookup
+#               result, and the format for a table entry is as fol-
+#               lows:
 # 
 #                    pattern      new_location
 # 
@@ -48,6 +49,15 @@
 #               such as an  email  address,  or  perhaps  a  street
 #               address or telephone number.
 # 
+#        o      Postfix  3.11  and later can optionally disable the
+#               hard-coded prefix. Specify "relocated_prefix_enable
+#               =   no"  in  main.cf,  and  specify  relocated_maps
+#               entries with your own RFC  3463-compliant  enhanced
+#               status code and text, for example:
+# 
+#                    pattern      5.2.0 Mailbox is unavailable
+#                    pattern      5.2.1 Mailbox is disabled
+# 
 #        o      Empty  lines and whitespace-only lines are ignored,
 #               as are lines whose first  non-whitespace  character
 #               is a `#'.
@@ -86,66 +96,74 @@
 #        description of regular expression lookup table syntax, see
 #        regexp_table(5) or pcre_table(5). For a description of the
 #        TCP client/server table lookup protocol, see tcp_table(5).
-#        This feature is not available up to and including  Postfix
-#        version 2.4.
+#        This feature is available in Postfix 2.5 and later.
 # 
-#        Each  pattern  is  a regular expression that is applied to
+#        Each pattern is a regular expression that  is  applied  to
 #        the entire address being looked up. Thus, user@domain mail
-#        addresses  are  not  broken up into their user and @domain
+#        addresses are not broken up into their  user  and  @domain
 #        constituent parts, nor is user+foo broken up into user and
 #        foo.
 # 
-#        Patterns  are applied in the order as specified in the ta-
-#        ble, until a pattern is  found  that  matches  the  search
+#        Patterns are applied in the order as specified in the  ta-
+#        ble,  until  a  pattern  is  found that matches the search
 #        string.
 # 
-#        Results  are  the  same as with indexed file lookups, with
-#        the additional feature that parenthesized substrings  from
+#        Results are the same as with indexed  file  lookups,  with
+#        the  additional feature that parenthesized substrings from
 #        the pattern can be interpolated as $1, $2 and so on.
 # 
 # TCP-BASED TABLES
-#        This  section  describes how the table lookups change when
+#        This section describes how the table lookups  change  when
 #        lookups are directed to a TCP-based server. For a descrip-
 #        tion of the TCP client/server lookup protocol, see tcp_ta-
-#        ble(5).  This feature is not available up to and including
-#        Postfix version 2.4.
+#        ble(5).   This  feature  is  available  in Postfix 2.5 and
+#        later.
 # 
 #        Each lookup operation uses the entire address once.  Thus,
-#        user@domain mail addresses are not broken  up  into  their
+#        user@domain  mail  addresses  are not broken up into their
 #        user and @domain constituent parts, nor is user+foo broken
 #        up into user and foo.
 # 
 #        Results are the same as with indexed file lookups.
 # 
 # BUGS
-#        The table format does not understand quoting  conventions.
+#        The  table format does not understand quoting conventions.
 # 
 # CONFIGURATION PARAMETERS
-#        The  following main.cf parameters are especially relevant.
-#        The text below provides  only  a  parameter  summary.  See
+#        The following main.cf parameters are especially  relevant.
+#        The  text  below  provides  only  a parameter summary. See
 #        postconf(5) for more details including examples.
 # 
-#        relocated_maps
-#               List of lookup tables for relocated users or sites.
+#        relocated_maps (empty)
+#               Optional lookup tables with new contact information
+#               for users or domains that no longer exist.
+# 
+#        Available with Postfix version 3.11 and later:
+# 
+#        relocated_prefix_enable (yes)
+#               Prepend  the  prefix  "5.1.6 User has moved to " to
+#               all relocated_maps lookup results.
 # 
 #        Other parameters of interest:
 # 
-#        inet_interfaces
-#               The network interface addresses  that  this  system
-#               receives mail on.  You need to stop and start Post-
-#               fix when this parameter changes.
+#        inet_interfaces (all)
+#               The local network  interface  addresses  that  this
+#               mail system receives mail on.
 # 
-#        mydestination
-#               List of domains that  this  mail  system  considers
-#               local.
+#        mydestination  ($myhostname,  localhost.$mydomain,  local-
+#        host)
+#               The  list  of  domains  that  are delivered via the
+#               $local_transport mail delivery transport.
 # 
-#        myorigin
-#               The domain that is appended to locally-posted mail.
+#        myorigin ($myhostname)
+#               The domain name that locally-posted mail appears to
+#               come  from,  and that locally posted mail is deliv-
+#               ered to.
 # 
-#        proxy_interfaces
-#               Other interfaces that this machine receives mail on
-#               by way of a proxy agent or network address transla-
-#               tor.
+#        proxy_interfaces (empty)
+#               The remote network interface  addresses  that  this
+#               mail  system  receives mail on by way of a proxy or
+#               network address translation unit.
 # 
 # SEE ALSO
 #        trivial-rewrite(8), address resolver

postfix/conf/transport

@@ -61,7 +61,7 @@
 # 
 #        Alternatively,  the  table  can  be  provided  as  a regu-
 #        lar-expression map where patterns  are  given  as  regular
-#        expressions,  or  lookups  can  be  directed  to TCP-based
+#        expressions,  or  lookups  can  be directed to a TCP-based
 #        server. In those case, the lookups are done in a  slightly
 #        different way as described below under "REGULAR EXPRESSION
 #        TABLES" or "TCP-BASED TABLES".
@@ -91,7 +91,7 @@
 # 
 #        The  pattern specifies an email address, a domain name, or
 #        a domain name hierarchy, as described  in  section  "TABLE
-#        LOOKUP".
+#        SEARCH ORDER".
 # 
 #        The  result is of the form transport:nexthop and specifies
 #        how or where to deliver mail. This is described in section
@@ -144,14 +144,20 @@
 #        transport (the first name of a mail delivery service entry
 #        in the Postfix master.cf file).
 # 
-#        The  interpretation  of  the  nexthop  field  is transport
-#        dependent. In the case of SMTP, specify  a  service  on  a
-#        non-default  port  as  host:service,  and disable MX (mail
-#        exchanger) DNS lookups with [host] or [host]:port. The  []
-#        form is required when you specify an IP address instead of
-#        a hostname.
+#        The  nexthop  field usually specifies one recipient domain
+#        or hostname. In the case of the Postfix SMTP/LMTP  client,
+#        the  nexthop  field may contain a list of nexthop destina-
+#        tions separated by comma or whitespace  (Postfix  3.5  and
+#        later).
 # 
-#        A null transport and null nexthop  result  means  "do  not
+#        The  syntax  of  a nexthop destination is transport depen-
+#        dent.  With SMTP, specify a service on a non-default  port
+#        as  host:service,  and  disable  MX  (mail  exchanger) DNS
+#        lookups  with  [host]  or  [host]:port.  The  []  form  is
+#        required when you specify an IP address instead of a host-
+#        name.
+# 
+#        A null transport and null  nexthop  field  means  "do  not
 #        change":  use  the delivery transport and nexthop informa-
 #        tion that would be used when the  entire  transport  table
 #        did not exist.
@@ -200,8 +206,8 @@
 #        prevents  mail  routing loops when your machine is primary
 #        MX host for example.com.
 # 
-#        In the case of delivery via SMTP, one  may  specify  host-
-#        name:service instead of just a host:
+#        In the case of delivery via SMTP or LMTP, one may  specify
+#        host:service instead of just a host:
 # 
 #             example.com      smtp:bar.example:2025
 # 
@@ -210,6 +216,14 @@
 #        be used. Specify [] around the hostname if MX lookups must
 #        be disabled.
 # 
+#        Deliveries via SMTP or LMTP support multiple  destinations
+#        (Postfix >= 3.5):
+# 
+#             example.com      smtp:bar.example, foo.example
+# 
+#        This  tries  to  deliver  to  bar.example before trying to
+#        deliver to foo.example.
+# 
 #        The error mailer can be used to bounce mail:
 # 
 #             .example.com     error:mail for *.example.com is not deliverable
@@ -256,17 +270,21 @@
 #        The  text  below  provides  only  a parameter summary. See
 #        postconf(5) for more details including examples.
 # 
-#        empty_address_recipient
-#               The address that is looked up instead of  the  null
-#               sender address.
+#        empty_address_recipient (MAILER-DAEMON)
+#               The  recipient  of  mail  addressed  to  the   null
+#               address.
 # 
-#        parent_domain_matches_subdomains
-#               List  of  Postfix features that use domain.tld pat-
-#               terns  to  match  sub.domain.tld  (as  opposed   to
-#               requiring .domain.tld patterns).
+#        parent_domain_matches_subdomains  (see  'postconf -d' out-
+#        put)
+#               A list of Postfix features where the pattern "exam-
+#               ple.com" also matches  subdomains  of  example.com,
+#               instead  of  requiring  an  explicit ".example.com"
+#               pattern.
 # 
-#        transport_maps
-#               List of transport lookup tables.
+#        transport_maps (empty)
+#               Optional lookup tables with mappings from recipient
+#               address  to  (message  delivery transport, next-hop
+#               destination).
 # 
 # SEE ALSO
 #        trivial-rewrite(8), rewrite and resolve addresses
@@ -275,14 +293,14 @@
 #        postmap(1), Postfix lookup table manager
 # 
 # README FILES
-#        Use  "postconf  readme_directory" or "postconf html_direc-
+#        Use "postconf readme_directory" or  "postconf  html_direc-
 #        tory" to locate this information.
 #        ADDRESS_REWRITING_README, address rewriting guide
 #        DATABASE_README, Postfix lookup table overview
 #        FILTER_README, external content filter
 # 
 # LICENSE
-#        The Secure Mailer license must be  distributed  with  this
+#        The  Secure  Mailer  license must be distributed with this
 #        software.
 # 
 # AUTHOR(S)

postfix/conf/virtual

@@ -11,12 +11,18 @@
 #        postmap -q - /etc/postfix/virtual <inputfile
 # 
 # DESCRIPTION
-#        The  optional  virtual(5)  alias  table rewrites recipient
-#        addresses for all local, all virtual, and all remote  mail
-#        destinations.   This  is unlike the aliases(5) table which
-#        is used only for local(8) delivery.  Virtual  aliasing  is
-#        recursive,  and  is  implemented by the Postfix cleanup(8)
-#        daemon before mail is queued.
+#        The  optional  virtual(5) alias table (virtual_alias_maps)
+#        applies to all recipients: local(8), virtual, and  remote.
+#        This feature is implemented in the Postfix cleanup(8) dae-
+#        mon before mail is queued.  These tables are often queried
+#        with a full email address (including domain).
+# 
+#        This  is  unlike  the  aliases(5) table (alias_maps) which
+#        applies only to local(8) recipients. That  table  is  only
+#        queried with the email address localpart (no domain).
+# 
+#        Virtual  aliasing is recursive; to terminate recursion for
+#        a specific address, alias that address to itself.
 # 
 #        The main applications of virtual aliasing are:
 # 
@@ -51,7 +57,7 @@
 # 
 #        Alternatively,  the  table  can  be  provided  as  a regu-
 #        lar-expression map where patterns  are  given  as  regular
-#        expressions,  or  lookups  can  be  directed  to TCP-based
+#        expressions,  or  lookups  can  be directed to a TCP-based
 #        server. In those case, the lookups are done in a  slightly
 #        different way as described below under "REGULAR EXPRESSION
 #        TABLES" or "TCP-BASED TABLES".
@@ -99,8 +105,8 @@
 #               tination,  or when it is listed in $inet_interfaces
 #               or $proxy_interfaces.
 # 
-#               This functionality overlaps with  functionality  of
-#               the  local  aliases(5)  database. The difference is
+#               This functionality overlaps with the  functionality
+#               of the local aliases(5) database. The difference is
 #               that virtual(5) mapping can be applied to non-local
 #               addresses.
 # 
@@ -117,15 +123,31 @@
 #               that mail as "undeliverable" to  the  often  forged
 #               sender address.
 # 
+#               To  avoid  backscatter  with  mail  for a wild-card
+#               domain, replace the wild-card mapping with explicit
+#               1:1  mappings, or add a reject_unverified_recipient
+#               restriction for that domain:
+# 
+#                   smtpd_recipient_restrictions =
+#                       ...
+#                       reject_unauth_destination
+#                       check_recipient_access
+#                           inline:{example.com=reject_unverified_recipient}
+#                   unverified_recipient_reject_code = 550
+# 
+#               In the above example, Postfix may contact a  remote
+#               server  if  the  recipient  is  aliased to a remote
+#               address.
+# 
 # RESULT ADDRESS REWRITING
 #        The lookup result is subject to address rewriting:
 # 
-#        o      When  the  result  has  the  form @otherdomain, the
-#               result becomes the same user in otherdomain.   This
+#        o      When the result  has  the  form  @otherdomain,  the
+#               result  becomes the same user in otherdomain.  This
 #               works only for the first address in a multi-address
 #               lookup result.
 # 
-#        o      When "append_at_myorigin=yes", append  "@$myorigin"
+#        o      When  "append_at_myorigin=yes", append "@$myorigin"
 #               to addresses without "@domain".
 # 
 #        o      When "append_dot_mydomain=yes", append ".$mydomain"
@@ -133,29 +155,29 @@
 # 
 # ADDRESS EXTENSION
 #        When a mail address localpart contains the optional recip-
-#        ient  delimiter  (e.g., user+foo@domain), the lookup order
+#        ient delimiter (e.g., user+foo@domain), the  lookup  order
 #        becomes: user+foo@domain, user@domain, user+foo, user, and
 #        @domain.
 # 
-#        The   propagate_unmatched_extensions   parameter  controls
-#        whether an unmatched address extension  (+foo)  is  propa-
-#        gated to the result of table lookup.
+#        The  propagate_unmatched_extensions   parameter   controls
+#        whether  an  unmatched  address extension (+foo) is propa-
+#        gated to the result of a table lookup.
 # 
 # VIRTUAL ALIAS DOMAINS
-#        Besides  virtual aliases, the virtual alias table can also
+#        Besides virtual aliases, the virtual alias table can  also
 #        be used to implement virtual alias domains. With a virtual
-#        alias  domain,  all  recipient  addresses  are  aliased to
+#        alias domain,  all  recipient  addresses  are  aliased  to
 #        addresses in other domains.
 # 
 #        Virtual alias domains are not to be confused with the vir-
 #        tual mailbox domains that are implemented with the Postfix
 #        virtual(8)  mail  delivery  agent.  With  virtual  mailbox
-#        domains,  each recipient address can have its own mailbox.
+#        domains, each recipient address can have its own  mailbox.
 # 
-#        With a virtual alias domain, the virtual  domain  has  its
-#        own  user  name  space. Local (i.e. non-virtual) usernames
-#        are not visible in a virtual alias domain. In  particular,
-#        local  aliases(5)  and local mailing lists are not visible
+#        With  a  virtual  alias domain, the virtual domain has its
+#        own user name space. Local  (i.e.  non-virtual)  usernames
+#        are  not visible in a virtual alias domain. In particular,
+#        local aliases(5) and local mailing lists are  not  visible
 #        as localname@virtual-alias.domain.
 # 
 #        Support for a virtual alias domain looks like:
@@ -164,7 +186,7 @@
 #            virtual_alias_maps = hash:/etc/postfix/virtual
 # 
 #        Note: some systems use dbm databases instead of hash.  See
-#        the  output  from  "postconf  -m"  for  available database
+#        the output  from  "postconf  -m"  for  available  database
 #        types.
 # 
 #        /etc/postfix/virtual:
@@ -173,105 +195,112 @@
 #            user1@virtual-alias.domain      address1
 #            user2@virtual-alias.domain      address2, address3
 # 
-#        The virtual-alias.domain anything entry is required for  a
+#        The  virtual-alias.domain anything entry is required for a
 #        virtual alias domain. Without this entry, mail is rejected
-#        with "relay access denied", or bounces  with  "mail  loops
+#        with  "relay  access  denied", or bounces with "mail loops
 #        back to myself".
 # 
-#        Do  not  specify virtual alias domain names in the main.cf
+#        Do not specify virtual alias domain names in  the  main.cf
 #        mydestination or relay_domains configuration parameters.
 # 
-#        With a virtual  alias  domain,  the  Postfix  SMTP  server
-#        accepts   mail  for  known-user@virtual-alias.domain,  and
-#        rejects  mail  for  unknown-user@virtual-alias.domain   as
+#        With  a  virtual  alias  domain,  the  Postfix SMTP server
+#        accepts  mail  for  known-user@virtual-alias.domain,   and
+#        rejects   mail  for  unknown-user@virtual-alias.domain  as
 #        undeliverable.
 # 
-#        Instead  of  specifying  the virtual alias domain name via
-#        the virtual_alias_maps table, you may also specify it  via
+#        Instead of specifying the virtual alias  domain  name  via
+#        the  virtual_alias_maps table, you may also specify it via
 #        the main.cf virtual_alias_domains configuration parameter.
-#        This latter parameter uses the same syntax as the  main.cf
+#        This  latter parameter uses the same syntax as the main.cf
 #        mydestination configuration parameter.
 # 
 # REGULAR EXPRESSION TABLES
-#        This  section  describes how the table lookups change when
+#        This section describes how the table lookups  change  when
 #        the table is given in the form of regular expressions. For
-#        a  description  of regular expression lookup table syntax,
+#        a description of regular expression lookup  table  syntax,
 #        see regexp_table(5) or pcre_table(5).
 # 
-#        Each pattern is a regular expression that  is  applied  to
+#        Each  pattern  is  a regular expression that is applied to
 #        the entire address being looked up. Thus, user@domain mail
-#        addresses are not broken up into their  user  and  @domain
+#        addresses  are  not  broken up into their user and @domain
 #        constituent parts, nor is user+foo broken up into user and
 #        foo.
 # 
-#        Patterns are applied in the order as specified in the  ta-
-#        ble,  until  a  pattern  is  found that matches the search
+#        Patterns  are applied in the order as specified in the ta-
+#        ble, until a pattern is  found  that  matches  the  search
 #        string.
 # 
-#        Results are the same as with indexed  file  lookups,  with
-#        the  additional feature that parenthesized substrings from
+#        Results  are  the  same as with indexed file lookups, with
+#        the additional feature that parenthesized substrings  from
 #        the pattern can be interpolated as $1, $2 and so on.
 # 
 # TCP-BASED TABLES
-#        This section describes how the table lookups  change  when
+#        This  section  describes how the table lookups change when
 #        lookups are directed to a TCP-based server. For a descrip-
 #        tion of the TCP client/server lookup protocol, see tcp_ta-
-#        ble(5).  This feature is not available up to and including
-#        Postfix version 2.4.
+#        ble(5).  This feature is  available  in  Postfix  2.5  and
+#        later.
 # 
 #        Each lookup operation uses the entire address once.  Thus,
-#        user@domain  mail  addresses  are not broken up into their
+#        user@domain mail addresses are not broken  up  into  their
 #        user and @domain constituent parts, nor is user+foo broken
 #        up into user and foo.
 # 
 #        Results are the same as with indexed file lookups.
 # 
 # BUGS
-#        The  table format does not understand quoting conventions.
+#        The table format does not understand quoting  conventions.
 # 
 # CONFIGURATION PARAMETERS
-#        The following main.cf parameters are  especially  relevant
-#        to  this  topic.  See  the Postfix main.cf file for syntax
-#        details and for default values. Use the  "postfix  reload"
+#        The  following  main.cf parameters are especially relevant
+#        to this topic. See the Postfix  main.cf  file  for  syntax
+#        details  and  for default values. Use the "postfix reload"
 #        command after a configuration change.
 # 
-#        virtual_alias_maps
-#               List of virtual aliasing tables.
+#        virtual_alias_maps ($virtual_maps)
+#               Optional lookup tables that are often searched with
+#               a  full  email  address (including domain) and that
+#               apply to all  recipients:  local(8),  virtual,  and
+#               remote;  this  is  unlike  alias_maps that are only
+#               searched  with  an  email  address  localpart   (no
+#               domain) and that apply only to local(8) recipients.
 # 
-#        virtual_alias_domains
-#               List  of  virtual alias domains. This uses the same
-#               syntax as the mydestination parameter.
+#        virtual_alias_domains ($virtual_alias_maps)
+#               Postfix is the final destination for the  specified
+#               list of virtual alias domains, that is, domains for
+#               which all addresses are  aliased  to  addresses  in
+#               other local or remote domains.
 # 
-#        propagate_unmatched_extensions
-#               A list of address rewriting  or  forwarding  mecha-
-#               nisms  that propagate an address extension from the
-#               original address to the result.   Specify  zero  or
-#               more   of   canonical,   virtual,  alias,  forward,
-#               include, or generic.
+#        propagate_unmatched_extensions (canonical, virtual)
+#               What  address  lookup tables copy an address exten-
+#               sion from the lookup key to the lookup result.
 # 
 #        Other parameters of interest:
 # 
-#        inet_interfaces
-#               The network interface addresses  that  this  system
-#               receives mail on.  You need to stop and start Post-
-#               fix when this parameter changes.
+#        inet_interfaces (all)
+#               The local network  interface  addresses  that  this
+#               mail system receives mail on.
 # 
-#        mydestination
-#               List of domains that  this  mail  system  considers
-#               local.
+#        mydestination  ($myhostname,  localhost.$mydomain,  local-
+#        host)
+#               The  list  of  domains  that  are delivered via the
+#               $local_transport mail delivery transport.
 # 
-#        myorigin
-#               The  domain  that  is  appended to any address that
-#               does not have a domain.
+#        myorigin ($myhostname)
+#               The domain name that locally-posted mail appears to
+#               come  from,  and that locally posted mail is deliv-
+#               ered to.
 # 
-#        owner_request_special
-#               Give special treatment to owner-xxx and xxx-request
-#               addresses.
+#        owner_request_special (yes)
+#               Enable special treatment for owner-listname entries
+#               in the aliases(5) file, and don't split owner-list-
+#               name and listname-request address  localparts  when
+#               the recipient_delimiter is set to "-".
 # 
-#        proxy_interfaces
-#               Other interfaces that this machine receives mail on
-#               by way of a proxy agent or network address transla-
-#               tor.
+#        proxy_interfaces (empty)
+#               The  remote  network  interface addresses that this
+#               mail system receives mail on by way of a  proxy  or
+#               network address translation unit.
 # 
 # SEE ALSO
 #        cleanup(8), canonicalize and enqueue mail

postfix/examples/smtpd-policy/README.SPF

@@ -1,6 +1,6 @@
-See http://www.openspf.org/Software for the current version of the
+See https://www.openspf.org/Software for the current version of the
 SPF policy daemon for Postfix.
 
 SPF support is also available via MILTER plugins, such as sid-milter
-at http://sourceforge.net/projects/sid-milter/ which implements both
+at https://sourceforge.net/projects/sid-milter/ which implements both
 SenderID and SPF.