Adding upstream version 3.10.2.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
2025-06-21 14:19:32 +02:00 · 2025-06-21 14:19:32 +02:00 · 75cf244379
commit 75cf244379
parent b6c197c021
2325 changed files with 583315 additions and 0 deletions
--- a/.indent.pro
+++ b/.indent.pro
@ -0,0 +1,445 @@
+-TABOUNCE_STATE
+-TADDR_MATCH_LIST
+-TADDR_PATTERN
+-TALIAS_TOKEN
+-TANVIL_CLNT
+-TANVIL_LOCAL
+-TANVIL_MAX
+-TANVIL_REMOTE
+-TANVIL_REQ_TABLE
+-TARGV
+-TASN1_INTEGER
+-TASN1_OBJECT
+-TATTR_CLNT
+-TATTR_OVER_INT
+-TATTR_OVER_STR
+-TATTR_OVER_TIME
+-TATTR_TABLE
+-TAUTHORITY_KEYID
+-TAUTO_CLNT
+-TBH_TABLE
+-TBINATTR
+-TBINATTR_INFO
+-TBINHASH
+-TBINHASH_INFO
+-TBIO
+-TBOUNCE_INFO
+-TBOUNCE_LOG
+-TBOUNCE_LOG_DSN_BUF
+-TBOUNCE_LOG_FORGE
+-TBOUNCE_LOG_RCPT_BUF
+-TBOUNCE_STAT
+-TBOUNCE_STR_PARAMETER
+-TBOUNCE_TEMPLATE
+-TBOUNCE_TEMPLATES
+-TBOUNCE_TIME_DIVISOR
+-TBOUNCE_TIME_PARAMETER
+-TBYTE_MASK
+-TCFG_PARSER
+-TCIDR_MATCH
+-TCLEANUP_REGION
+-TCLEANUP_STATE
+-TCLEANUP_STAT_DETAIL
+-TCLIENT_LIST
+-TCLNT_STREAM
+-TCONFIG_BOOL_FN_TABLE
+-TCONFIG_BOOL_TABLE
+-TCONFIG_INT_FN_TABLE
+-TCONFIG_INT_TABLE
+-TCONFIG_LONG_FN_TABLE
+-TCONFIG_LONG_TABLE
+-TCONFIG_NBOOL_FN_TABLE
+-TCONFIG_NBOOL_TABLE
+-TCONFIG_NCODE_TABLE
+-TCONFIG_NINT_FN_TABLE
+-TCONFIG_NINT_TABLE
+-TCONFIG_RAW_FN_TABLE
+-TCONFIG_RAW_TABLE
+-TCONFIG_STR_FN_TABLE
+-TCONFIG_STR_TABLE
+-TCONFIG_TIME_FN_TABLE
+-TCONFIG_TIME_TABLE
+-TCONST_CHAR_STAR
+-TCRYPTO_EX_DATA
+-TCTABLE
+-TCTABLE_ENTRY
+-TDB_COMMON_CTX
+-TDELIVERED_HDR_INFO
+-TDELIVER_ATTR
+-TDELIVER_REQUEST
+-TDELTA_TIME
+-TDICT
+-TDICT_CACHE
+-TDICT_CACHE_SREQ
+-TDICT_CACHE_SREQ_INFO
+-TDICT_CACHE_TEST
+-TDICT_CDBM
+-TDICT_CDBQ
+-TDICT_CIDR
+-TDICT_CIDR_ENTRY
+-TDICT_DB
+-TDICT_DBM
+-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
+-TDICT_NISPLUS
+-TDICT_NODE
+-TDICT_OPEN_EXTEND_FN
+-TDICT_OPEN_FN
+-TDICT_OPEN_INFO
+-TDICT_OWNER
+-TDICT_PCRE
+-TDICT_PCRE_ENGINE
+-TDICT_PCRE_EXPAND_CONTEXT
+-TDICT_PCRE_IF_RULE
+-TDICT_PCRE_MATCH_RULE
+-TDICT_PCRE_PRESCAN_CONTEXT
+-TDICT_PCRE_REGEXP
+-TDICT_PCRE_RULE
+-TDICT_PGSQL
+-TDICT_PIPE
+-TDICT_PROXY
+-TDICT_RAND
+-TDICT_RANDOM
+-TDICT_REGEXP
+-TDICT_REGEXP_EXPAND_CONTEXT
+-TDICT_REGEXP_IF_RULE
+-TDICT_REGEXP_MATCH_RULE
+-TDICT_REGEXP_PATTERN
+-TDICT_REGEXP_PRESCAN_CONTEXT
+-TDICT_REGEXP_RULE
+-TDICT_SDBM
+-TDICT_SOCKMAP
+-TDICT_SOCKMAP_REFC_HANDLE
+-TDICT_SQLITE
+-TDICT_STATIC
+-TDICT_SURROGATE
+-TDICT_TCP
+-TDICT_TEXT
+-TDICT_THASH
+-TDICT_UNION
+-TDICT_UNIX
+-TDICT_UTF8_BACKUP
+-TDICT_WRAPPER
+-TDNS_FIXED
+-TDNS_REPLY
+-TDNS_RR
+-TDOMAIN_LIST
+-TDSN
+-TDSN_BUF
+-TDSN_FILTER
+-TDSN_SPLIT
+-TDSN_STAT
+-TDYMAP_INFO
+-TEC_GROUP
+-TEC_KEY
+-TEDIT_FILE
+-TEVENT_MASK
+-TEVP_CIPHER_CTX
+-TEVP_MAC_CTX
+-TEVP_MD
+-TEVP_MD_CTX
+-TEVP_PKEY
+-TEXPAND_ATTR
+-TFILE
+-TFORWARD_INFO
+-THBC_ACTION_CALL_BACKS
+-THBC_CALL_BACKS
+-THBC_CHECKS
+-THBC_MAP_INFO
+-THBC_OUTPUT_CALL_BACKS
+-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
+-TINT32_TYPE
+-TINTV
+-TINT_TABLE
+-TJMP_BUF_WRAPPER
+-TLDAP
+-TLDAPMessage
+-TLDAPURLDesc
+-TLDAP_CONN
+-TLIB_DP
+-TLIB_FN
+-TLMTP_ATTR
+-TLMTP_RESP
+-TLMTP_SESSION
+-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
+-TMAIL_STREAM
+-TMAIL_VERSION
+-TMAI_HOSTADDR_STR
+-TMAI_HOSTNAME_STR
+-TMAI_SERVNAME_STR
+-TMAI_SERVPORT_STR
+-TMAPS
+-TMAP_SEARCH
+-TMASTER_INT_WATCH
+-TMASTER_PROC
+-TMASTER_SERV
+-TMASTER_STATUS
+-TMASTER_STR_WATCH
+-TMATCH_LIST
+-TMATCH_OPS
+-TMBLOCK
+-TMBOX
+-TMDB_env
+-TMDB_txn
+-TMDB_val
+-TMILTER
+-TMILTER8
+-TMILTERS
+-TMILTER_MACROS
+-TMILTER_MSG_CONTEXT
+-TMIME_ENCODING
+-TMIME_INFO
+-TMIME_STACK
+-TMIME_STATE
+-TMIME_STATE_DETAIL
+-TMIME_TOKEN
+-TMKMAP
+-TMKMAP_DB
+-TMKMAP_DBM
+-TMKMAP_OPEN_EXTEND_FN
+-TMKMAP_OPEN_FN
+-TMKMAP_OPEN_INFO
+-TMKMAP_SDBM
+-TMSG_STATS
+-TMULTI_SERVER
+-TMVECT
+-TMYSQL
+-TMYSQL_NAME
+-TMYSQL_RES
+-TNAMADR_LIST
+-TNAME_ASSIGNMENT
+-TNAME_CODE
+-TNAME_MASK
+-TNBBIO
+-TNVTABLE_INFO
+-TOPTIONS
+-TPCF_DBMS_INFO
+-TPCF_DEPR_PARAM_INFO
+-TPCF_EVAL_CTX
+-TPCF_MASTER_EDIT_REQ
+-TPCF_MASTER_ENT
+-TPCF_MASTER_FLD_REQ
+-TPCF_PARAM_CTX
+-TPCF_PARAM_NODE
+-TPCF_PARAM_TABLE
+-TPCF_SERVICE_DEF
+-TPCF_SERVICE_PATTERN
+-TPCF_STRING_NV
+-TPEER_NAME
+-TPGSQL_NAME
+-TPICKUP_INFO
+-TPIPE_ATTR
+-TPIPE_PARAMS
+-TPIPE_STATE
+-TPLMYSQL
+-TPLPGSQL
+-TPOSTMAP_KEY_STATE
+-TPOST_MAIL_FCLOSE_STATE
+-TPOST_MAIL_STATE
+-TPRIVATE_STR_TABLE
+-TPSC_CALL_BACK_ENTRY
+-TPSC_CLIENT_INFO
+-TPSC_DNSBL_HEAD
+-TPSC_DNSBL_SCORE
+-TPSC_DNSBL_SITE
+-TPSC_ENDPT_LOOKUP_INFO
+-TPSC_HAPROXY_STATE
+-TPSC_SMTPD_COMMAND
+-TPSC_STARTTLS
+-TPSC_STATE
+-TQMGR_ENTRY
+-TQMGR_FEEDBACK
+-TQMGR_JOB
+-TQMGR_MESSAGE
+-TQMGR_PEER
+-TQMGR_QUEUE
+-TQMGR_RCPT
+-TQMGR_RCPT_LIST
+-TQMGR_RECIPIENT
+-TQMGR_SCAN
+-TQMGR_TRANSPORT
+-TQMQPD_STATE
+-TRCPT_BUF
+-TRECIPIENT
+-TRECIPIENT_LIST
+-TREC_TYPE_NAME
+-TRESOLVE_REPLY
+-TRESPONSE
+-TREST_TABLE
+-TRES_CONTEXT
+-TRING
+-TRWR_CONTEXT
+-TSCACHE
+-TSCACHE_CLNT
+-TSCACHE_MULTI
+-TSCACHE_MULTI_DEST
+-TSCACHE_MULTI_ENDP
+-TSCACHE_MULTI_HEAD
+-TSCACHE_SINGLE
+-TSCACHE_SINGLE_DEST
+-TSCACHE_SINGLE_ENDP
+-TSCACHE_SIZE
+-TSCAN_DIR
+-TSCAN_INFO
+-TSCAN_OBJ
+-TSENDER_LOGIN_MATCH
+-TSERVER_AC
+-TSESSION
+-TSHARED_PATH
+-TSINGLE_SERVER
+-TSINK_COMMAND
+-TSINK_STATE
+-TSLMDB
+-TSMFICTX
+-TSMTPD_CMD
+-TSMTPD_DEFER
+-TSMTPD_ENDPT_LOOKUP_INFO
+-TSMTPD_POLICY_CLNT
+-TSMTPD_PROXY
+-TSMTPD_RBL_EXPAND_CONTEXT
+-TSMTPD_RBL_STATE
+-TSMTPD_RCPTMAP_ST
+-TSMTPD_STATE
+-TSMTPD_TOKEN
+-TSMTPD_XFORWARD_ATTR
+-TSMTP_ADDR
+-TSMTP_CLI_ATTR
+-TSMTP_CMD
+-TSMTP_ITERATOR
+-TSMTP_RESP
+-TSMTP_SASL_AUTH_CACHE
+-TSMTP_SESSION
+-TSMTP_STATE
+-TSMTP_TLS_POLICY
+-TSMTP_TLS_SESS
+-TSMTP_TLS_SITE_POLICY
+-TSM_STATE
+-TSOCKADDR_SIZE
+-TSPAWN_ATTR
+-TSSL
+-TSSL_CTX
+-TSSL_SESSION
+-TSTATE
+-TSTRING_LIST
+-TSTRING_TABLE
+-TSYS_EXITS_DETAIL
+-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
+-TTLS_SERVER_START_PROPS
+-TTLS_SESS_STATE
+-TTLS_TICKET_KEY
+-TTLS_TLSA
+-TTLS_USAGE
+-TTLS_VINFO
+-TTLScontext_t
+-TTOK822
+-TTRANSPORT_INFO
+-TTRIGGER_SERVER
+-TUSER_ATTR
+-TVBUF
+-TVSTREAM
+-TVSTREAM_POPEN_ARGS
+-TVSTRING
+-TWAIT_STATUS_T
+-TWATCHDOG
+-TWATCH_FD
+-TX509
+-TX509V3_CTX
+-TX509_EXTENSION
+-TX509_NAME
+-TX509_STORE_CTX
+-TXSASL_CLIENT
+-TXSASL_CLIENT_CREATE_ARGS
+-TXSASL_CLIENT_IMPL
+-TXSASL_CLIENT_IMPL_INFO
+-TXSASL_CYRUS_CB
+-TXSASL_CYRUS_CLIENT
+-TXSASL_CYRUS_ERROR_INFO
+-TXSASL_CYRUS_SERVER
+-TXSASL_DCSRV_MECH
+-TXSASL_DOVECOT_SERVER
+-TXSASL_DOVECOT_SERVER_IMPL
+-TXSASL_DOVECOT_SERVER_MECHS
+-TXSASL_SERVER
+-TXSASL_SERVER_CREATE_ARGS
+-TXSASL_SERVER_IMPL
+-TXSASL_SERVER_IMPL_INFO
+-Tbind_props
+-Tbson_iter_t
+-Tcipher_probe_t
+-Td2i_X509_t
+-Tdane_digest
+-Tdane_mtype
+-Tfilter_ctx
+-Tgeneral_name_stack_t
+-Tiana_digest
+-Toff_t
+-Tpem_load_state_t
+-Tregex_t
+-Tregmatch_t
+-Tsasl_conn_t
+-Tsasl_secret_t
+-Tsfsistat
+-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
--- a/.printfck
+++ b/.printfck
@ -0,0 +1,25 @@
+been_here_xt	2	0
+bounce_append	5	0
+cleanup_out_format	1	0
+defer_append	5	0
+mail_command	1	0
+mail_print	1	0
+msg_error	0	0
+msg_fatal	0	0
+msg_info	0	0
+msg_panic	0	0
+msg_warn	0	0
+opened		4	0
+post_mail_fprintf	1	0
+qmgr_message_bounce	2	0
+rec_fprintf	2	0
+sent	4	0
+smtp_cmd	1	0
+smtp_mesg_fail	2	0
+smtp_printf	1	0
+smtp_rcpt_fail	3	0
+smtp_site_fail	2	0
+udp_syslog	1	0
+vstream_fprintf	1	0
+vstream_printf	0	0
+vstring_sprintf	1	0
--- a/184
+++ b/184
@ -0,0 +1,184 @@
+Purpose of this document
+========================
+
+This document provides a road map of the Postfix mail system source
+code distribution.  I suggest that you
+
+- take a few minutes to read this file,
+
+- review the RELEASE_NOTES file for incompatible changes,
+
+- and then proceed with the INSTALL instructions.
+
+Introduction
+============
+
+This is the public release of the Postfix mail system. Thank you
+for your interest in this project. Send me a postcard if you like
+it. My postal address is below.
+
+You must read the LICENSE file, if you didn't do so already. A copy
+of the LICENSE must be distributed with every original, modified,
+complete, source, or binary copy of this software or parts thereof.
+I suggest that you keep a copy of the file in /etc/postfix/LICENSE.
+
+Purpose of the Postfix mail system
+==================================
+
+Postfix aims to be an alternative to the widely-used sendmail
+program.
+
+Although IBM supported the Postfix development, it abstains from
+control over its evolution. The goal is to have Postfix installed
+on as many systems as possible. To this end, the software is given
+away with no strings attached to it, so that it can evolve with
+input from and under control by its users.
+
+In other words, IBM releases Postfix only once. I will be around
+to guide its development for a limited time.
+
+On-line resources devoted to the Postfix mail system
+====================================================
+
+Web sites:
+
+    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 https://www.postfix.org/.
+
+Acknowledgments
+===============
+
+This release could not have happened without the input from a team
+of competent alpha testers. Their names appear in numerous places
+in the HISTORY file. I appreciate the input from my colleagues at
+the IBM Global Security Analysis Laboratory:  Paul Karger, Dave
+Safford, Douglas Schales, and Leendert van Doorn.  I also appreciate
+the support by Charles Palmer under whose leadership I began this
+project, and who had the privilege to name the software, twice.
+
+Postcards
+=========
+
+If you wish to express your appreciation for the Postfix software,
+you are welcome to send a postcard to:
+
+	Wietse Venema
+	Google
+	111 8th Avenue, 4th floor
+	New York, NY 10011
+	USA
+
+Roadmap of the Postfix source distribution
+==========================================
+
+The RELEASE_NOTES file describes new features, and lists incompatible
+changes with respect to previous Postfix versions.
+
+The INSTALL file provides a step-by-step guide for building and
+installing Postfix on many popular UNIX platforms.
+
+The COMPATIBILITY file lists features that Postfix does or does
+not yet implement, and how well it works with other software.
+
+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 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
+are also available through the HTML interface, which allows you to
+navigate faster.
+
+The PORTING file discusses how to go about porting Postfix to other
+UNIX platforms.
+
+Documentation:
+
+    README_FILES/	Instructions for specific Postfix features
+    html/		HTML format
+    man/		UNIX on-line manual page format
+
+Example files:
+
+    conf/		configuration files, run-time scripts
+    examples/		chroot environments, virtual domains
+
+Library routines:
+
+    src/dns/		DNS client library
+    src/global/		Postfix-specific support routines
+    src/milter/		Postfix Milter (mail filter) client
+    src/tls/		TLS client and server support
+    src/util/		General-purpose support routines
+    src/xsasl/		SASL plug-in API
+
+Command-line utilities:
+
+    src/postalias/	Alias database management
+    src/postcat/	List Postfix queue file
+    src/postconf/	Configuration utility
+    src/postdrop/	Postfix mail submission program
+    src/postfix/	Postfix administrative interface
+    src/postkick/	Postfix IPC for shell scripts
+    src/postlock/	Postfix locking for shell scripts
+    src/postlog/	Postfix logging for shell scripts
+    src/postmap/	Postfix lookup table management
+    src/postmulti/	Postfix multi-instance manager
+    src/postqueue/	Postfix queue control program
+    src/postsuper/	Postfix house keeping program
+    src/sendmail/	Sendmail compatibility interface
+
+Postfix daemons:
+
+    src/anvil/		Connection count/rate limiter
+    src/bounce/		Bounce or defer mail
+    src/cleanup/	Canonicalize and enqueue mail
+    src/discard/	Trivial discard mailer
+    src/dnsblog/	DNS agent for postscreen
+    src/error/		Trivial error mailer
+    src/flush/		Support for ETRN, sendmail -qI, sendmail -qR
+    src/local/		Local delivery
+    src/master/		Postfix resident superserver
+    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
+    src/qmqpd/		QMQPD server
+    src/scache/		Postfix SMTP session cache
+    src/showq/		List Postfix queue status
+    src/smtp/		SMTP and LMTP client
+    src/smtpd/		SMTP server
+    src/spawn/		Run non-Postfix server
+    src/tlsmgr/		TLS session keys and random pool
+    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
+
+Test programs:
+
+    src/fsstone/	Measure file system overhead
+    src/posttls-finger/	Postfix SMTP/LMTP TLS probe utility
+    src/smtpstone/	SMTP and QMQP server torture test
+
+Miscellaneous:
+
+    auxiliary/		Auxiliary software etc.
+    bin/		Postfix command executables
+    conf/		Configuration files, run-time scripts
+    include/		Include files
+    implementation-notes/ Background information
+    lib/		Object libraries
+    libexec/		Postfix daemon executables
+    mantools/		Documentation utilities
+    proto/		Documentation source
--- a/73
+++ b/73
@ -0,0 +1,73 @@
+.forward	yes (empty files; can enable/disable mail to /file or |command)
+/usr/mail	yes (compile time option)
+/usr/spool/mail	yes (compile time option)
+/var/mail	yes (compile time option)
+/var/spool/mail	yes (compile time option)
+:include:	yes (mail to /file and |command is off by default)
+address probing	yes (optional persistent database)
+aliases		yes (can enable/disable mail to /file or |command)
+bare newlines	yes (but will send CRLF)
+blacklisting	yes (client name/addr; helo hostname; mail from; rcpt to)
+connection caching yes (SMTP shared cache; LMTP shared cache)
+content filter	yes (before and after queue, internal and external)
+db tables	yes (compile time option)
+dbm tables	yes (compile time option)
+delivered-to	yes (configurable with prepend_delivered_header)
+dsn		yes
+enhanced status codes	yes
+errors-to:	no (removed with Postfix 2.2)
+esmtp		yes
+etrn support	yes (per-destination log for authorized destinations only)
+fcntl locking	yes (runtime configurable)
+flock locking	yes (runtime configurable)
+genericstable	yes (Postfix 2.2 generic(5) table)
+greylist	yes (delegated policy script)
+home mailbox	yes
+ident lookup	no
+ipv6	        yes (compatibility for ipv4-only systems)
+ldap tables	yes (contributed)
+lmtp support	yes (client only)
+luser relay	yes
+m4 config	no
+mail to command	yes (configurable for .forward, aliases, :include:)
+mail to file	yes (configurable for .forward, aliases, :include:)
+maildir		yes (in home, system mailspool, /file/name/ alias)
+mailertable	yes (it's called transport)
+mailq		yes
+majordomo	yes (edit approve script to delete /^delivered-to:/i)
+milter		yes (except body replacement)
+mime		yes (including 8bit to quoted-printable conversion)
+mysql tables	yes (contributed)
+netinfo tables	yes (contributed)
+newaliases	yes (main alias database only)
+nis tables	yes
+nis+ tables	yes (contributed)
+no <> in smtp	yes (most common address forms)
+pgsql tables	yes (contributed)
+pipeline option	yes (SMTP server and client; LMTP client)
+pop/imap	no
+qmqp server	yes (with verp support)
+rbl support	yes
+return-receipt:	no (use DSN NOTIFY=SUCCESS)
+rhsbl support	yes
+sasl support	yes (compile time option)
+sendmail -bt	no
+sendmail -bv	yes (sends delivery report via email)
+sendmail -q	yes
+sendmail -qRxxx	yes (for domains specified in fast_flush_domains)
+sendmail -qSxxx	no
+sendmail -qtime	ignored
+sendmail -v	yes (sends delivery report via email)
+sendmail.cf	no (uses table-driven address rewriting)
+size option	yes, server and client
+smarthost	yes (specify relayhost in main.cf)
+spf		yes (delegated policy script)
+starttls        yes (compile time option)
+tcp wrapper	no (use built-in blacklist facility)
+user+extension	yes (also: .forward+extension)
+user-extension	yes (also: .forward-extension)
+user.lock	yes (runtime configurable)
+uucp support	yes (sends user@domain recipients)
+verp support	yes (delimiters are configurable)
+virtual domains	yes (via local delivery agent and via dedicated delivery agent)
+year 2000 safe	yes
--- a/35
+++ b/35
@ -0,0 +1,35 @@
+Included for the use of the fix_strcasecmp.c module which works
+around a Solaris problem.
+
+/*
+ * Copyright (c) 1987, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *    must display the following acknowledgement:
+ *	This product includes software developed by the University of
+ *	California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * 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 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
--- a/29031
+++ b/29031
--- a/1168
+++ b/1168
--- a/483
+++ b/483
@ -0,0 +1,483 @@
+ChangeLog for Dean Strik's IPv6 patch for Postfix. The patch is based on
+PLD's patch, which in turn seems to be based on KAME's. For more information:
+
+	http://www.ipnet6.org/postfix/
+
+---------------------------------------------------------------------
+
+Version 1.25	Postfix release 2.1.3
+		Postfix release 2.0.20
+		Postfix snapshot 2.2-20040616
+
+	Bugfix: Misplaced myfree() caused a small memory leak. Reported
+	by Christian von Roques.
+	File: util/match_ops.c
+
+	Removed the colon (:) from the characters XFORWARD replaces by
+	a question mark (IPv6 addresses looked like 2001?610?1108?5010??1
+	in logging). Reported by Philipp Morger.
+	File: smtpd/smtpd.c
+
+Version 1.24	Postfix release 2.1.1
+		Postfix release 2.0.20
+		Postfix snapshot 2.0.19-20040312
+		Postfix snapshot 2.2-20040504
+
+	Bugfix: Prefixlen non-null host portion validation (in CIDR maps
+	for example) yielded incorrect results sometimes because signed
+	arithmetic was used instead of unsigned.
+	File: util/match_ops.c
+
+	Patch correction: The TLS+IPv6 patch for Postfix 2.1.0 missed
+	the master.cf update (used for new installations). Added it
+	back.
+
+Version 1.23	Postfix release 2.1.0
+		Postfix release 2.0.20
+		Postfix snapshot 2.0.19-20040312
+
+	Patch fixes: Several code fixes to make the patch compile
+	and work correctly when compiled without IPv6 support.
+
+	Bugfix (Solaris only?): address family length was not updated
+	which could cause client hostname validation errors.
+	File: smtpd/smtpd_peer.c
+
+	Portability: added support for Darwin 7.3+. This may need
+	some further testing.
+
+	Cleanup: Restructure and redocument interface address
+	retrieval functions. (This reduced the number of preprocessor
+	statements from 99 to 93 ;)
+	File: util/inet_addr_local.c
+
+	Cleanup: make several explicit casts to have compilers shut
+	their pie holes about uninteresting things.
+
+Version 1.22	Postfix release 2.0.19
+		Postfix snapshot 2.0.19-20040312
+
+	Feature: Support "inet_interfaces = IPv4:all" and
+	"inet_interfaces = IPv6:all", to restrict postfix to use
+	either IPv4-only or IPv6-only. A more complete implementation
+	will be part of a future patch. (Slightly modified) patch by
+	Michal Ludvig, SuSE.
+	Files: util/interfaces_to_af.[ch], util/inet_addr_local.c,
+	global/own_inet_addr.c, global/wildcard_inet_addr.[ch],
+	master/master_ent.ch
+
+	Bugfix: In Postfix snapshots, a #define was misplaced with
+	the effect that IPv6 subnets were not included in auto-
+	generated $mynetworks (i.e., mynetworks not defined in main.cf,
+	when also mynetworks_style=subnet) on Linux 2.x systems.
+	File: utils/sys_defs.h
+
+Version 1.21a	Postfix snapshots 2.0.18-2004{0122,0205,0209}
+				  2.0.19-20040312
+
+	TLS/snapshot version: Update TLS patch to 0.8.18-20040122.
+	Performed as a total repatch. 0.8.18 is cleaner with tls_*
+	variables if TLS is not actually compiled in.
+
+Version 1.21	Postfix releases 2.0.18 - 2.0.19
+		Postfix snapshot 2.0.16-20031231
+
+	Bugfix: The SMTP client could fail to setup a connection,
+	erroring with a bogus "getaddrinfo(...): hostname nor servname
+	provided" warning, because the wrong address was selected.
+	File: smtp/smtp_connect.c
+
+	Safety: in dynamically growing data structures, update the
+	length info after (instead of before) updating the data size.
+	File: util/inet_addr_list.c
+
+Version 1.20	Postfix release 2.0.16
+		Postfix snapshot 2.0.16-20031207
+
+	Bugfix: The SMTP client would abort when binding to specific
+	IPv6 addresses.
+	File: smtp/smtp_connect.c
+
+	Synchronisation/bugfix: LMTP source address binding is identical
+	to the SMTP source binding setup, avoiding the need for
+	lmtp_bind_address(6) if inet_interfaces is set to a single
+	host for an address family.
+	File: lmtp/lmtp_connect.c
+
+Version 1.19	Postfix release 2.0.16
+		Postfix snapshot 2.0.16-20031207
+
+	Bugfix: Synchronisation of TLS patches in snapshots of 1.18[ab]
+	was not complete, causing a crash of smtpd if used with the new
+	proxy agent.
+	File: smtpd/smtpd.c
+
+	Bugfix: SMTP source address binding based on a single hostname
+	in inet_interfaces did not work since the code counted IPv4 and
+	IPv6 addresses instead of only the used address family. Fixed,
+	thereby no longer requiring exact specification of
+	smtp_bind_address(6) in this case.
+	File: smtp/smtp_connect.c
+
+	Bugfix: The QMQP sink server did not compile correctly. This
+	program, part of smtpstone tools, is not compiled or installed
+	by default.
+	File: smtpstone/qmqp-sink.c
+
+	Bugfix: NI_WITHSCOPEID was not correctly defined everywhere,
+	which could result in EAI_BADFLAGS. Changed location of
+	definition to correct it.
+	Files: util/sys_defs.h, util/inet_addr_list.h
+
+Version 1.18b	Postfix snapshot 2.0.16-20030921
+
+	IPv6 support: Added IPv6-enabled code to the new snapshot
+	check_*_{ns,mx}_access restrictions.
+	File: smtpd/smtpd_check.c
+
+Version 1.18a	Postfix release 2.0.16
+
+	Update (TLS patches): Updated Lutz Jaenicke's TLS patch to
+	version 0.8.16. See pfixtls/ChangeLog for details.
+	Diff contributed by Tuomo Soini.
+
+	The TLS+IPv6 patch now contains the original TLS patch
+	documentation from Lutz Jaenicke.
+
+Version 1.18	Postfix releases 2.0.14 - 2.0.15
+		Postfix snapshot 2.0.14-20030812
+
+	Bugfix: Perform actual hostname verification in the SMTP
+	and QMTP servers. This was never supported in the IPv6
+	patch. Reported by Wolfgang S. Rupprecht.
+	Files: smtpd/smtpd_peer.c, qmqpd/qmqpd_peer.c
+
+	IPv6 address ranges using address/prefixlength (e.g. in
+	mynetworks and access maps) should be written as
+	[ipv6:addr:ess]/plen (e.g. [fec0:10:20::]/48). The old
+	supported syntax, [ipv6:addr:ess/plen] is deprecated and
+	support will be removed in a later version.
+	Thanks to Dr. Peter Bieringer and Pekka Savola for discussion.
+	Files: util/match_ops.c, global/mynetworks.c
+
+	Explicitly prefer IPv6 over IPv4 addresses when delivering
+	to a host when MX lookups are disabled when SMTP address
+	randomization is on (default).
+	File: smtp/smtp_addr.c
+
+	Compliance: write IPv6 address literals in mail headers 
+	as [IPv6:addr] instead of [addr] as per RFC 2821:4.1.3
+	tagging requirement, for example [IPv6:fec0:10:20::1].
+	Pointed out by Dr. Peter Bieringer.
+	Files: smtpd/smtpd{,_peer,_state}.c, smtpd/smtpd.h
+
+Version 1.17	Postfix release 2.0.13, 2.0.14
+		Postfix snapshot 2.0.13-20030706, 2.0.14-20030812
+
+	Bugfix: Two memory allocation/deallocation bugs were
+	introduced in patch 1.16. The impact of these bugs could
+	be 'arbitrary' memory corruption.
+	File: util/match_ops.c
+
+Version 1.16	Postfix release 2.0.13
+		Postfix snapshot 2.0.13-20030706
+
+	Cleanup: rewrote match_ops.c. This rewrite is partly based on
+	patch by Takahiro Igarashi. The rewrite enables some better
+	handling of scoped addresses, and drops all GPL code from the
+	patch, easying license considerations. Also, allowed for
+	use of this code by the CIDR maps.
+	Files: util/match_ops.[ch]
+
+	Bugfix: correctly relay for scoped unicast addresses when
+	applicable. Until now, while Postfix was able to recognize
+	scoped addresses, it was not able to see e.g. fe80::10%fxp0
+	as local in mynetworks validation.  KAME-only code.
+	(I've never heard of people using scoped addresses (think
+	link-local addresses) for mail relaying though...)
+	Files: util/inet_addr_list.[ch]
+
+	Feature (snapshot only): rewrote CIDR maps code to support
+	IPv6 addresses, using new match_ops code. Allow the use
+	of [::/0] since it allows one to easily disable further
+	checks for IPv6 addresses.
+	File: util/dict_cidr.c
+
+	Consistency: require IPv6 addresses in inet_interfaces to
+	be enclosed in square brackets.
+	File: util/inet_addr_host.c
+
+	Bugfix: (Linux2-only) A #define was misspelled. This could
+	lead to Postfix being unable to read the system's local IPv6
+	addresses (e.g. when using inet_interfaces).
+	Spotted by Jochen Friedrich.
+	File: util/sys_defs.h
+
+	Cleanup: require non-null host portion in CIDR /
+	prefixlength notations for IPv6 (was IPv4-only).
+
+Version 1.15a	Postfix release 2.0.13
+
+	Update (TLS patches): Updated Lutz Jaenicke's TLS patch
+	to version 0.8.15. This version introduces new options
+	for managing SASL mechanisms. More information at:
+	http://www.aet.tu-cottbus.de/personen/jaenicke/pfixtls/
+	Diff contributed by Tuomo Soini.
+
+Version 1.15	Postfix release 2.0.12, 2.0.13
+		Postfix snapshot 2.0.12-20030621
+
+	Bugfix (TLS-snapshots only): a change in Postfix snapshot
+	2.0.11-20030609 broke initialisation of TLS in smtpd,
+	causing TLS to both be unadvertised and unaccepted.
+	This was fixed again by reordering initialisation.
+	File: smtpd/smtpd.c
+
+	Update (TLS patches): Updated Lutz Jaenicke's TLS patch
+	to version 0.8.14. This version introduces a few fixes and
+	uses USE_SSL instead of HAS_SSL. More information at:
+	http://www.aet.tu-cottbus.de/personen/jaenicke/pfixtls/
+	Diff contributed by Tuomo Soini.
+
+	Bugfix (Postfix releases only - this was already added to
+	the snapshots in patch 1.14). KAME derived systems only.
+	Correctly decode scoped addresses, including network
+	interface specifiers.
+	File: util/inet_addr_local.c
+
+Version 1.14	Postfix releases 2.0.9, 2.0.10, 2.0.11, 2.0.12
+		Postfix snapshots 2.0.9-20030424, 2.0.10-20030521,
+				  2.0.11-20030609, 2.0.12-20030611
+
+	Patch change: made the patch available as an IPv6-only
+	patch (i.e., without the TLS code). This on popular
+	request by users and packagers.
+	A TLS+IPv6 version is still available of course.
+
+	Bugfix: correctly decode scoped addresses from now on
+	(KAME derived systems only). I think the original code
+	was written by Itojun, so I'm rather puzzled that it
+	didn't work...
+	File: util/inet_addr_local.c
+
+	Bugfix/portability: Recent KAME snapshots return both
+	TCP and SCTP address information on getaddrinfo() if
+	no protocol was specified. This causes the socket counts
+	to be wrong, confusing child processes.
+	Merged patch by JINMEI Tatuya of KAME to fix this.
+	Files: master/master.h, master/master_{ent,conf}.[ch],
+		util/inet_listen.c
+
+	Documentation: added an IPV6_README file to the patch.
+	This file contains the primary documentation. Also,
+	added a sample-ipv6.cf to describe the (currently few)
+	IPv6 related main.cf parameters.
+
+	Bugfix: the netmask structures for the *unsupported*
+	platforms (boldly assume /64) were added to the wrong
+	list (addresses instead of masks). This bug did not affect
+	any supported platform though.
+	File: util/inet_addr_local.c
+
+	Portability: added support for HP/Compaq Tru64Unix V5.1
+	and later. (compiled with CompaqCC only).
+	Thanks to Sten Spans for providing root access to an
+	IPv6-connected Tru64 testing machine.
+
+Version 1.13	Postfix releases 2.0.4 - 2.0.9
+		Postfix snapshots 2.0.3-20030126 - 2.0.7-20030319
+
+	Bugfix: Due to a missing storage pointer, DNS lookup
+	results in the permit_mx_backups code were not processed,
+	and smtpd would likely crash.
+	Thanks to Wouter de Jong for reporting the crashes.
+	File: smtpd/smtpd_check.c
+
+	Incompatible change: The addresses given to the parameters
+	smtp_bind_address6 and lmtp_bind_address6 now need to be
+	enclosed in square brackets for consistency.
+	Files: [ls]mtp/[ls]mtp_connect.c
+
+Version 1.12	Postfix releases 2.0.2, 2.0.3
+		Postfix snapshots 2.0.2-20030115, 2.0.3-20030126
+
+	Bugfix/workaround (Solaris): A simplified comparison
+	function for Solaris' qsort() function, would result
+	in corruption of network addresses in the SMTP client.
+	Fixed. Reported with possible fix by Edvard Tuinder.
+	File: smtp/smtp_addr.c
+
+Version 1.11	Postfix releases 2.0.0.x, 2.0.1, 2.0.2
+		Postfix snapshots 2.0.0-20030105, 2.0.1-20030112
+			2.0.2-20030115
+
+	Bugfix (Solaris): Properly initialize lifconf structure
+	when requesting host interface addresses. If you get
+	warnings about SIOCGLIFCONF with earlier versions,
+	please upgrade.
+	File: util/inet_addr_local.c
+
+	Patch fix: fixed compilation errors in case the patch is
+	applied but built without IPv6 support (i.e., on unsupported
+	platforms).
+
+Version 1.10	Postfix snapshots 1.1.12-200212{19,21}
+		Postfix releases 2.0.0, 2.0.0.{1,2}
+		Postfix snapshots 2.0.0-20021223 - 2.0.0-20030101
+
+	'Bugfix': don't show spurious warnings on Linux systems
+	about missing /proc/net/if_inet6 unless verbose mode
+	is enabled.
+	File: util/inet_addr_local.c
+
+	Bugfix: If unable to create a socket for a specific adress
+	in the SMTP client (e.g., when trying to create an IPv6
+	connection while the local host has no configured IPv6
+	addresses), then stop the attempt.
+	File: smtp/smtp_connect.c
+
+	Small bugfix: never query DNS for <localpart@[domain.tld]>.
+	This syntax now correctly generates an error immediately.
+	File: global/resolve_local.c
+
+	Updated TLS patch to 0.8.12-1.1.12-20021219-0.9.6h, fixing
+	a bug with "sendmail -bs".
+
+Version 1.9	Postfix version 1.1.11-20021115
+		Postfix version 1.1.12-2002{1124,1209-1213}
+
+	Bugfix: with getifaddrs() code (*BSD, linux-USAGI), IPv4
+	netmasks were set to /32 effectively. Work around broken
+	netmask data structures (*BSD only perhaps).
+
+	Bugfix: same data corruption in another place created
+	entirely wrong IPv4 netmasks. Work around broken
+	SIOCGIFNETMASK structure.
+
+	New code was added for correct IPv6 netmasks. The original
+	code did not contain IPv6 netmask support at all!
+	For Solaris, use SIOCGLIF*; Linux: /proc/net/if_inet6.
+	Getifaddrs() support is used otherwise. This should cover
+	all supported systems. Other systems also work, prefix
+	length is always set to /64 then.
+
+	Since there are no classes (context: Class A, class B etc
+	networks) with IPv6, default to IPv6 subnet style if the
+	mynetworks style is 'class'. I recommend against this style
+	anyway.
+
+	Added support to display IPv6 nets mynetworks output.
+
+Version 1.8	Postfix version 1.1.11-200211{01,15}
+
+	An earlier author of the patch made a typo in the GAI_STRERROR()
+	macro, resulting in bogus error messages when checking for
+	PTR records. Fixed.
+
+	IPv4-mapped addresses in the smtpd are converted to true IPv4
+	addresses just after the connection has been made. This means
+	that all IPv4-mapped addresses are now logged as true IPv4
+	addresses. Hence beside RBL checks, also access maps now treat
+	IPv4-mapped addresses as native IPv4. Note that ::ffff:...
+	entries in your access tables will no longer work.
+
+	You can now specify IPv6 'parent' networks in your access maps,
+	e.g. to reject all mail from 3ffe:200:... nodes, add the line
+		3ffe:200	REJECT
+	Use of trailing colons is discouraged because postmap will
+	warn about it possibly being an alias...
+	NOTE: I'll soon obsolete this again in favor of the more
+	common address/len notation. This was just so trivial to add
+	that it didn't hurt and I needed it :)
+
+	For easy reference, the version of the TLS/IPv6 patch can be
+	dynamically queried using the  tls_ipv6_version  variable.
+	This gives the short version (like, "1.8").
+
+	The service bind address for 'inet' sockets in master.cf (e.g.,
+	smtpd), must be enclosed in square brackets '[..]' for IPv6
+	addresses. The old style (without brackets) still works but is
+	unsupported and may be removed in the future. Example
+	    [::1]:smtp inet n - n - - smtpd
+
+Version 1.7	Postfix version 1.1.11-20021029 - 1.1.11-20021101
+
+	Postfix' SMTP client performs randomization of MX addresses
+	when sending mail. This however could result in A records
+	being used before AAAA records. This has been corrected.
+
+	Note that from Postfix version 1.1.11-20021029 on, there is
+	a  proxy_interfaces  parameter. This has of course not been
+	ported to IPv6 addresses...
+
+Version 1.6	Postfix version 1.1.11-20020928
+
+	Added IPv6 support for backup_mx_networks feature; also the
+	behaviour when DNS lookups fail when checking whether the
+	local host is an MX for a domain conforms to the IPv4 case:
+	defer rather than allow.
+
+Version 1.5	Postfix version 1.1.11-20020917
+
+	I introduced two bugs when I rewrote my older LMTP IPv6 patch.
+	These bugs effectively rendered LMTP useless. Now fixed.
+	Bugs spotted by Kaj Niemi.
+
+	Now supports Solaris 8 and 9. Due to lack of testing equipment,
+	this has been only tested in production on Solaris 9, both
+	with gcc and the Sun Workshop Compiler.
+
+Version 1.4	Postfix version 1.1.11-20020822 - 1.1.11-20020917
+
+	OpenBSD (>=200003) and FreeBSD release 4 and up now use
+        getifaddrs(). This makes for cleaner code. The old code
+	seems to be bug-ridden anyway.
+
+	Got rid of some compiler warnings. Should be cleaner on
+	Alpha as well now. Thanks to Sten Spans for providing me
+	access to an Alpha running FreeBSD4.
+
+	Fixed an old bug in smtpd memory alloation if you compiled
+	without IPv6 support (the wrong buffer size was used. This
+	was harmless for IPv6-enabled compiles since the sizes were
+	equal then).
+
+	Added ChangeLog to the patch (as IPv6-ChangeLog) (this
+	was absent in 1.3 contrary to docs).
+
+Version 1.3	Postfix version 1.1.11-20020613 - 1.1.11-20020718
+
+	FYI: In postfix version 1.1.11-20020718, DNS lookups for
+	AAAA can be done natively. The code matches the code in
+	the patch (though the #ifdef changed from INET6 to T_AAAA).
+	This change causes the patch for 1.1.11-20020718 to be a
+	bit smaller.
+
+Version 1.2	Postfix version 1.1.11-20020613
+
+	Added IPv6 support for the LMTP client.
+
+	Added lmtp_bind_address and lmtp_bind_address6 parameters,
+	similar to those for smtp.
+
+	Added IPv6 support for the QMQP server.
+
+Version 1.1	Postfix version 1.1.11-20020602 - 1.1.11-20020613
+
+	Added parameter smtp_bind_address6. By using this parameter,
+	it is possible to bind to an IPv6 address, independently of
+	IPv4 address binding.
+
+	Lutz fixed a bug in his TLS patch regarding SASL. Incorporated.
+
+Version 1.0.x	Postfix version 1.1.8-20020505 - 1.1.11-20020602
+
+	Patch derived from PLD's IPv6 patch for Postfix, revision 1.10
+	which applied to early Postfix snapshots 1.1.x. Updated this
+	patch to apply to 1.1.8-20020505.
+
+	Added compile-time checks for SS_LEN. Some Linux installations,
+	and maybe other systems, do define SA_LEN, but not SS_LEN.
+
+	Several updates of postfix snapshots.
+
--- a/508
+++ b/508
@ -0,0 +1,508 @@
+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
+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 International Business Machines Corporation ("IBM"), 
+       the Original Program, and 
+    b) in the case of each 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 additions to the Program which:
+       (i)  are separate modules of software distributed in conjunction 
+            with the Program under their own license agreement, and 
+       (ii) are not derivative works of the Program.
+
+"Contributor" means IBM and any other 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.
+
+"Original Program" means the original version of the software accompanying
+this Agreement as released by IBM, including source code, object code
+and documentation, if any.
+
+"Program" means the Original Program and Contributions.
+
+"Recipient" means anyone who receives the Program under this Agreement, 
+including all Contributors.
+
+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, in source code and
+    object code form.
+
+    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 and object code 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.
+
+3.  REQUIREMENTS
+
+A Contributor may choose to distribute the Program in object code form 
+under its own license agreement, provided that:
+    a) it complies with the terms and conditions of this Agreement; and
+    b) its license agreement:
+       i)   effectively disclaims on behalf of all 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 Contributors all 
+            liability for damages, including direct, indirect, special, 
+            incidental and consequential damages, such as lost profits; 
+       iii) states that any provisions which differ from this Agreement 
+            are offered by that Contributor alone and not by any other 
+            party; and
+       iv)  states that source code for the Program is available from 
+            such Contributor, and informs licensees how to obtain it in a 
+            reasonable manner on or through a medium customarily used for 
+            software exchange. 
+
+When the Program is made available in source code form:
+    a) it must be made available under this Agreement; and 
+    b) a copy of this Agreement must be included with each copy of the 
+       Program.  
+
+Each Contributor must include the following in a conspicuous location 
+in the Program: 
+
+    Copyright (c) 1997,1998,1999, International Business Machines
+    Corporation and others. All Rights Reserved.
+
+In addition, each Contributor must identify itself as the originator of
+its Contribution, if any, in a manner that reasonably allows subsequent
+Recipients to identify the originator of the Contribution. 
+
+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, 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, 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 a Contributor with
+respect to a patent applicable to software (including a cross-claim or
+counterclaim in a lawsuit), then any patent licenses granted by that
+Contributor to such Recipient under this Agreement shall terminate
+as of the date such litigation is filed.  In addition, 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. 
+
+IBM may publish new versions (including revisions) of this Agreement
+from time to time.  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. No one other than IBM has the
+right to modify this Agreement.  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.
+
+This Agreement is governed by the laws of the State of New York and the
+intellectual property laws of the United States of America. No party to
+this Agreement will bring a legal action under this Agreement more than
+one year after the cause of action arose.  Each party waives its rights
+to a jury trial in any resulting litigation. 
--- a/22
+++ b/22
@ -0,0 +1,22 @@
+# Usage: 
+#	make makefiles [name=value]...
+#
+# See makedefs for a description of available options.
+# Examples:
+#
+#	make makefiles
+#	make makefiles CC="purify cc"
+#	make makefiles CC=cc OPT=
+#
+SHELL	= /bin/sh
+
+default: update
+
+update depend clean tidy depend_update: Makefiles
+	$(MAKE) MAKELEVEL= $@
+
+install upgrade:
+	@echo Please review the INSTALL instructions first.
+
+makefiles Makefiles:
+	$(MAKE) -f Makefile.in MAKELEVEL= Makefiles
--- a/Makefile.in
+++ b/Makefile.in
@ -0,0 +1,239 @@
+# 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 -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 \
+	src/sendmail src/error src/pickup src/cleanup src/smtpd src/local \
+	src/trivial-rewrite src/qmgr src/oqmgr src/smtp src/bounce \
+	src/pipe src/showq src/postalias src/postcat src/postconf src/postdrop \
+	src/postkick src/postlock src/postlog src/postmap src/postqueue \
+	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/postlogd
+MANDIRS	= proto man html
+LIBEXEC	= libexec/post-install libexec/postfix-script libexec/postfix-wrapper \
+	libexec/postmulti-script libexec/postfix-tls-script
+PLUGINS	= meta/dynamicmaps.cf
+META	= meta/main.cf.proto meta/master.cf.proto meta/postfix-files \
+	meta/makedefs.out $(PLUGINS)
+EXPAND	= sed -e "s;\$${LIB_PREFIX};$(LIB_PREFIX);" \
+	    -e "s;\$${LIB_SUFFIX};$(LIB_SUFFIX);"
+SHLIB_DIR_OVERRIDE = \
+	$${shlib_directory:-`$(SHLIB_ENV) bin/postconf -dhx shlib_directory`}
+
+default: update
+
+# While generating the top-level Makefile, we must get the PLUGIN_LD
+# setting directly from the latest makedefs.out result.
+
+makefiles Makefiles conf/makedefs.out:
+	(echo "# Do not edit -- this file documents how Postfix was built for your machine."; $(SHELL) makedefs) >makedefs.tmp
+	set +e; if cmp makedefs.tmp conf/makedefs.out; then rm makedefs.tmp; \
+	else mv makedefs.tmp conf/makedefs.out; fi >/dev/null 2>/dev/null
+	set -e; for i in $(DIRS); do \
+	 (set -e; echo "[$$i]"; cd $$i; rm -f Makefile; \
+	 $(MAKE) -f Makefile.in Makefile MAKELEVEL=) || exit 1; \
+	done
+	@set -- `grep '^PLUGIN_LD' conf/makedefs.out`; \
+	rm -f Makefile; (cat conf/makedefs.out; \
+	case  "$$3" in \
+	""|":") grep -v '^PLUGINS' Makefile.in;; \
+	     *) cat Makefile.in;; \
+	esac) >Makefile
+
+update tests root_tests:
+	set -e; for i in $(DIRS); do \
+	 (set -e; echo "[$$i]"; cd $$i; $(MAKE) $(OPTS) $@ MAKELEVEL=) || exit 1; \
+	done
+
+update: $(META) $(LIBEXEC)
+
+libexec/post-install: conf/post-install
+	rm -f $@ && ln -f $? $@
+
+# Censor out build directory information.
+
+meta/makedefs.out: conf/makedefs.out
+	grep -v SHLIB_ENV $? > $@
+
+meta/postfix-files: conf/postfix-files conf/makedefs.out Makefile
+	rm -f $@
+	(if [ "${SHLIB_DIR}" = "no" -o "${SHLIB_DIR}" = "" ]; then \
+	    sed -e '/^\$$shlib_directory/d' \
+		-e '/dynamicmaps.cf/d' conf/postfix-files; \
+	elif [ "${PLUGIN_LD}" = ":" -o "${PLUGIN_LD}" = "" ]; then \
+	    sed -e '/dynamicmaps.cf/d' \
+		-e '/^\$$shlib_directory\/\$${LIB_PREFIX}/d' \
+		conf/postfix-files | $(EXPAND); \
+	else \
+	    $(EXPAND) conf/postfix-files | awk -F: ' \
+		BEGIN { \
+		    count = split("'"$(DEFINED_MAP_TYPES)"'", names, " "); \
+		    for (n = 1; n <= count; n++) \
+			have["$$shlib_directory/$(LIB_PREFIX)" names[n] \
+			    "$(LIB_SUFFIX)"] = 1; } \
+		/^[$$]shlib_directory.$(LIB_PREFIX)/ { \
+		    if (have[$$1]) print; next } \
+		{ print } \
+	    '; \
+	fi) | case "$(MAKE_FIX)" in \
+	 *) cat;; \
+	esac > $@
+
+libexec/postfix-script: conf/postfix-script
+	rm -f $@ && ln -f $? $@
+
+libexec/postfix-tls-script: conf/postfix-tls-script
+	rm -f $@ && ln -f $? $@
+
+libexec/postfix-wrapper: conf/postfix-wrapper
+	rm -f $@ && ln -f $? $@
+
+meta/main.cf.proto: conf/main.cf
+	rm -f $@ && ln -f $? $@
+
+meta/master.cf.proto: conf/master.cf
+	rm -f $@ && ln -f $? $@
+
+libexec/postmulti-script: conf/postmulti-script
+	rm -f $@ && ln -f $? $@
+
+meta/dynamicmaps.cf: conf/dynamicmaps.cf Makefile
+	rm -f $@ && $(EXPAND) conf/dynamicmaps.cf | $(AWK) ' \
+		BEGIN { split("'"$(DEFINED_MAP_TYPES)"'", map_types); \
+			for (n in map_types) has_type[map_types[n]] = n } \
+		/^#/ { print } \
+		/^[a-z]/ { if (has_type[$$1]) print } \
+	' >$@
+
+manpages:
+	set -e; for i in $(MANDIRS); do \
+	 (set -e; echo "[$$i]"; cd $$i; $(MAKE) -f Makefile.in $(OPTS) MAKELEVEL=) || exit 1; \
+	done </dev/null
+
+# Some checks require a bin/postconf executable.
+pre-release-checks: 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
+# installed system from dynamicmaps=yes<->dynamicmaps=no or from
+# shared=yes<->shared=no.
+
+install: update
+	SHLIB_ENV_VAR= SHLIB_ENV_VAL= \
+	$(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+		postfix-install $(POSTFIX_INSTALL_OPTS)
+
+package: update
+	SHLIB_ENV_VAR= SHLIB_ENV_VAL= \
+	$(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+		postfix-install -package $(POSTFIX_INSTALL_OPTS)
+
+upgrade: update
+	SHLIB_ENV_VAR= SHLIB_ENV_VAL= \
+	$(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+		postfix-install -non-interactive $(POSTFIX_INSTALL_OPTS)
+	
+
+non-interactive-package: update
+	SHLIB_ENV_VAR= SHLIB_ENV_VAL= \
+	$(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+		postfix-install -non-interactive -package $(POSTFIX_INSTALL_OPTS)
+
+depend clean:
+	set -e; for i in $(DIRS); do \
+	 (set -e; echo "[$$i]"; cd $$i; $(MAKE) $@) || exit 1; \
+	done
+
+depend_update:
+	set -e; for i in $(DIRS); do \
+	 (set -e; echo "[$$i]"; cd $$i; $(MAKE) depend && $(MAKE) $(OPTS) update) \
+	    || exit 1; \
+	done
+
+tidy:	clean
+	rm -f Makefile */Makefile src/*/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]* \
+	    src/*/libpostfix-*.so src/*/libpostfix-*.dylib \
+	    src/*/postfix-*.so src/*/postfix-*.dylib \
+	    junk */junk */*/junk \
+	    *core */*core */*/*core \
+	    .nfs* */.nfs* */*/.nfs* \
+	    .pure */.pure */*/.pure \
+	    *.out */*.out */*/*.out \
+	    *.tmp */*.tmp */*/*.tmp \
+	    *.a */*.a */*/*.a \
+	    *~ */*~ */*/*~ \
+	    *- */*- */*/*- \
+	    *.orig */*.orig */*/*.orig \
+	    *.bak */*.bak */*/*.bak \
+	    make.err */make.err */*/make.err \
+	    *.gmon */*.gmon */*/*.gmon \
+	    conf/main.cf.default conf/bounce.cf.default meta/*
+	find . -type s -print | xargs rm -f
+	find . -type d -print | xargs chmod 755
+	find . -type f -print | xargs chmod a+r
--- a/Makefile.init
+++ b/Makefile.init
@ -0,0 +1,22 @@
+# Usage: 
+#	make makefiles [name=value]...
+#
+# See makedefs for a description of available options.
+# Examples:
+#
+#	make makefiles
+#	make makefiles CC="purify cc"
+#	make makefiles CC=cc OPT=
+#
+SHELL	= /bin/sh
+
+default: update
+
+update depend clean tidy depend_update: Makefiles
+	$(MAKE) MAKELEVEL= $@
+
+install upgrade:
+	@echo Please review the INSTALL instructions first.
+
+makefiles Makefiles:
+	$(MAKE) -f Makefile.in MAKELEVEL= Makefiles
--- a/24
+++ b/24
@ -0,0 +1,24 @@
+In order to port software to a new platform:
+
+- Choose a SYSTEMTYPE name for the new system.  You must use a name
+that includes at least the major version of the operating system
+(such as SUNOS4 or LINUX2), so that different releases of the same
+system can be supported without confusion.
+
+- Add a case statement to the "makedefs" shell script in the source
+code top-level directory that recognizes the new system reliably,
+and that emits the right system-specific information.  Be sure to
+make the code robust against user PATH settings; if the system
+offers multiple UNIX flavors (e.g. BSD and SYSV) be sure to build
+for the native flavor, instead of the emulated one.
+
+- Add an "#ifdef SYSTEMTYPE" section to the central util/sys_defs.h
+include file.  You may have to invent new feature macro names.
+Please choose sensible feature macro names such as HAS_DBM or
+FIONREAD_IN_SYS_FILIO_H.
+
+I strongly recommend against using "#ifdef SYSTEMTYPE" in individual
+source files.  While this may look like the quickest solution, it
+will create a mess when newer versions of the same SYSTEMTYPE need
+to be supported.  You're likely to end up placing "#ifdef" sections
+all over the source code again.
--- a/README_FILES/AAAREADME
+++ b/README_FILES/AAAREADME
@ -0,0 +1,89 @@
+ PPoossttffiixx DDooccuummeennttaattiioonn
+
+-------------------------------------------------------------------------------
+GGeenneerraall ccoonnffiigguurraattiioonn
+
+  * BASIC_CONFIGURATION_README: Basic configuration
+  * SOHO_README: Small/home office hints and tips
+  * STANDARD_CONFIGURATION_README: Standard configuration examples
+  * ADDRESS_REWRITING_README: Address rewriting
+  * VIRTUAL_README: Virtual domain hosting
+  * SASL_README: SASL Authentication
+  * TLS_README: TLS Encryption and authentication
+  * FORWARD_SECRECY_README: TLS Forward Secrecy
+  * 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
+
+  * QSHAPE_README: Bottleneck analysis
+  * STRESS_README: Stress-dependent configuration
+  * TUNING_README: Performance tuning
+  * DEBUG_README: Debugging strategies
+
+CCoonntteenntt iinnssppeeccttiioonn
+
+  * CONTENT_INSPECTION_README: Content inspection overview
+  * BACKSCATTER_README: Stopping backscatter mail
+  * BUILTIN_FILTER_README: Built-in content inspection
+
+  * FILTER_README: After-queue content filter
+  * SMTPD_PROXY_README: Before-queue content filter
+  * MILTER_README: Before-queue Milter applications
+
+SSMMTTPP RReellaayy aanndd aacccceessss ccoonnttrrooll
+
+  * SMTPD_ACCESS_README: Relay/access control overview
+  * SMTPD_POLICY_README: Access policy delegation
+  * ADDRESS_VERIFICATION_README: Address verification
+  * RESTRICTION_CLASS_README: Per-client/user/etc. access
+  * POSTSCREEN_README: SMTP connection triage
+  * ETRN_README: ETRN Support
+  * UUCP_README: LAN connected via UUCP
+
+LLooookkuupp ttaabblleess ((ddaattaabbaasseess))
+
+  * DATABASE_README: Lookup table overview
+  * DB_README: Berkeley DB Howto
+  * CDB_README: CDB Howto
+  * 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
+  * SQLITE_README: SQLite Howto
+
+MMaaiilliinngg lliisstt ssuuppppoorrtt
+
+  * VERP_README: VERP Support
+
+SSppeecciiffiicc eennvviirroonnmmeennttss
+
+  * LINUX_README: Linux issues
+  * NFS_README: NFS issues
+
+OOtthheerr mmaaiill ddeelliivveerryy aaggeennttss
+
+  * MAILDROP_README: Maildrop
+
+OOtthheerr ttooppiiccss
+
+  * OVERVIEW: Architecture overview
+  * postconf(5): All main.cf parameters
+  * LOCAL_RECIPIENT_README: Rejecting Unknown Local Recipients
+  * 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
+  * XFORWARD_README: XFORWARD Command
+
--- a/README_FILES/ADDRESS_CLASS_README
+++ b/README_FILES/ADDRESS_CLASS_README
@ -0,0 +1,210 @@
+PPoossttffiixx AAddddrreessss CCllaasssseess
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix version 2.0 introduces the concept of address classes. This is a way of
+grouping recipient addresses by their delivery method. The idea comes from
+discussions with Victor Duchovni. Although address classes introduced a few
+incompatibilities they also made it possible to improve the handling of hosted
+domains and of unknown recipients.
+
+This document provides information on the following topics:
+
+  * What are address classes good for?
+  * What address classes does Postfix implement?
+  * Improvements compared to Postfix 1.1
+  * Incompatibilities with Postfix 1.1
+
+WWhhaatt aarree aaddddrreessss ccllaasssseess ggoooodd ffoorr??
+
+Why should you care about address classes? This is how Postfix decides what
+mail to accept, and how to deliver it. In other words, address classes are very
+important for the operation of Postfix.
+
+An address class is defined by three items.
+
+  * The list of domains that are a member of that address class.
+
+    Examples: all local domains, or all relay domains.
+
+  * 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??
+
+Initially the list of address classes is hard coded, but this is meant to
+become extensible. The summary below describes the main purpose of each class,
+and what the relevant configuration parameters are.
+
+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 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 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
+    local(8) delivery agent.
+
+The virtual alias domain class.
+
+  * 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 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.
+
+        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.
+
+  * Purpose: final delivery for hosted domains where each recipient address can
+    have its own mailbox, and where users do not need to have a UNIX system
+    account. A virtual mailbox example is given in the VIRTUAL_README file.
+
+  * 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 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)
+    delivery agent.
+
+The relay domain class.
+
+  * Purpose: mail forwarding to remote destinations that list your system as
+    primary or backup MX host. For a discussion of the basic configuration
+    details, see the BASIC_CONFIGURATION_README document. 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 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)
+    delivery agent.
+
+The default domain class.
+
+  * Purpose: mail forwarding to the Internet on behalf of authorized clients.
+    For a discussion of the basic configuration details, see the
+    BASIC_CONFIGURATION_README file. For a discussion of the difference between
+    canonical domains, hosted domains and other domains, see the VIRTUAL_README
+    file.
+
+  * This class has no destination domain table.
+
+  * This class has no valid recipient address table.
+
+  * The mail delivery transport is specified with the default_transport
+    parameter. The default value is ssmmttpp for delivery with the smtp(8) delivery
+    agent.
+
+IImmpprroovveemmeennttss ccoommppaarreedd ttoo PPoossttffiixx 11..11
+
+Postfix 2.0 address classes made the following improvements possible over
+earlier Postfix versions:
+
+  * You no longer need to specify all the virtual(8) mailbox domains in the
+    Postfix transport map. The virtual(8) delivery agent has become a first-
+    class citizen just like local(8) or smtp(8).
+
+  * On mail gateway systems, address classes provide separation of inbound mail
+    relay traffic ($relay_transport) from outbound traffic
+    ($default_transport). This eliminates a problem where inbound mail
+    deliveries could become resource starved in the presence of a high volume
+    of outbound mail.
+
+  * The SMTP server rejects unknown recipients in a more consistent manner than
+    was possible with Postfix version 1. This is needed to keep undeliverable
+    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 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.
+
+IInnccoommppaattiibbiilliittiieess wwiitthh PPoossttffiixx 11..11
+
+Postfix 2.0 address classes introduce a few incompatible changes in documented
+behavior. In order to ease the transitions, new parameters have default values
+that are backwards compatible.
+
+  * The virtual_maps parameter is replaced by virtual_alias_maps (for address
+    lookups) and by virtual_alias_domains (for the names of what were formerly
+    called "Postfix-style virtual domains").
+
+    For backwards compatibility with Postfix version 1.1, the new
+    virtual_alias_maps parameter defaults to $virtual_maps, and the new
+    virtual_alias_domains parameter defaults to $virtual_alias_maps.
+
+  * The virtual_mailbox_maps parameter now has a companion parameter called
+    virtual_mailbox_domains (for the names of domains served by the virtual
+    delivery agent). The virtual_mailbox_maps parameter is now used for address
+    lookups only.
+
+    For backwards compatibility with Postfix version 1.1, the new
+    virtual_mailbox_domains parameter defaults to $virtual_mailbox_maps.
+
+  * Introduction of the relay_recipient_maps parameter. The Postfix SMTP server
+    can use this to block mail for relay recipients that don't exist. This list
+    is empty by default, which means accept any recipient.
+
+  * The local_recipient_maps feature is now turned on by default. The Postfix
+    SMTP server uses this to reject mail for unknown local recipients. See the
+    LOCAL_RECIPIENT_README file hints and tips.
+
+  * Introduction of the relay delivery transport in master.cf. This helps to
+    avoid mail delivery scheduling problems on inbound mail relays when there
+    is a lot of outbound mail, but may require that you update your
+    "defer_transports" setting.
+
--- a/README_FILES/ADDRESS_REWRITING_README
+++ b/README_FILES/ADDRESS_REWRITING_README
@ -0,0 +1,877 @@
+PPoossttffiixx AAddddrreessss RReewwrriittiinngg
+
+-------------------------------------------------------------------------------
+
+PPoossttffiixx aaddddrreessss rreewwrriittiinngg ppuurrppoossee
+
+Address rewriting is at the heart of the Postfix mail system. Postfix rewrites
+addresses for many different purposes. Some are merely cosmetic, and some are
+necessary to deliver correctly formatted mail to the correct destination.
+Examples of address rewriting in Postfix are:
+
+  * Transform an incomplete address into a complete address. For example,
+    transform "username" into "username@example.com", or transform
+    "username@hostname" into "username@hostname.example.com".
+
+  * Replace an address by an equivalent address. For example, replace
+    "username@example.com" by "firstname.lastname@example.com" when sending
+    mail, and do the reverse transformation when receiving mail.
+
+  * Replace an internal address by an external address. For example, replace
+    "username@localdomain.local" by "isp-account@isp.example" when sending mail
+    from a home computer to the Internet.
+
+  * Replace an address by multiple addresses. For example, replace the address
+    of an alias by the addresses listed under that alias.
+
+  * Determine how and where to deliver mail for a specific address. For
+    example, deliver mail for "username@example.com" with the smtp(8) delivery
+    agent, to the hosts that are listed in the DNS as the mail servers for the
+    domain "example.com".
+
+Although Postfix currently has no address rewriting language, it can do
+surprisingly powerful address manipulation via table lookup. Postfix typically
+uses lookup tables with fixed strings to map one address to one or multiple
+addresses, and typically uses regular expressions to map multiple addresses to
+one or multiple addresses. Fixed-string lookup tables may be in the form of
+local files, or in the form of NIS, LDAP or SQL databases. The DATABASE_README
+document gives an introduction to Postfix lookup tables.
+
+Topics covered in this document:
+
+  * To rewrite message headers or not, or to label as invalid
+  * Postfix address rewriting overview
+  * Address rewriting when mail is received
+
+      o Rewrite addresses to standard form
+      o Canonical address mapping
+      o Address masquerading
+      o Automatic BCC recipients
+      o Virtual aliasing
+
+  * Address rewriting when mail is delivered
+
+      o Resolve address to (transport, next-hop destination)
+      o Relocated users table
+
+  * Address rewriting with remote delivery
+
+      o Generic mapping for outgoing SMTP mail
+
+  * Address rewriting with local delivery
+
+      o Local alias database
+      o Local per-user .forward files
+      o Local catch-all address
+
+  * Debugging your address manipulations
+
+TToo rreewwrriittee mmeessssaaggee hheeaaddeerrss oorr nnoott,, oorr ttoo llaabbeell aass iinnvvaalliidd
+
+Postfix versions 2.1 and earlier always rewrite message header addresses, and
+append Postfix's own domain information to addresses that Postfix considers
+incomplete. While rewriting message header addresses is OK for mail with a
+local origin, it is undesirable for remote mail:
+
+  * Message header address rewriting is frowned upon by mail standards,
+  * Appending Postfix's own domain produces incorrect results with some
+    incomplete addresses,
+  * Appending Postfix's own domain sometimes creates the appearance that spam
+    is sent by local users.
+
+Postfix versions 2.2 give you the option to either not rewrite message headers
+from remote SMTP clients at all, or to label incomplete addresses in such
+message headers as invalid. Here is how it works:
+
+  * Postfix always rewrites message headers from local SMTP clients and from
+    the Postfix sendmail command, and appends its own domain to incomplete
+    addresses. The local_header_rewrite_clients parameter controls what SMTP
+    clients Postfix considers local (by default, only local network interface
+    addresses).
+  * Postfix never rewrites message header addresses from remote SMTP clients
+    when the remote_header_rewrite_domain parameter value is empty (the default
+    setting).
+  * Otherwise, Postfix rewrites message headers from remote SMTP clients, and
+    appends the remote_header_rewrite_domain value to incomplete addresses.
+    This feature can be used to append a reserved domain such as
+    "domain.invalid", so that incomplete addresses cannot be mistaken for local
+    addresses.
+
+PPoossttffiixx aaddddrreessss rreewwrriittiinngg oovveerrvviieeww
+
+The figure below zooms in on those parts of Postfix that are most involved with
+address rewriting activity. See the OVERVIEW document for an overview of the
+complete Postfix architecture. Names followed by a number are Postfix daemon
+programs, while unnumbered names represent Postfix queues or internal sources
+of mail messages.
+
+                  trivial-                              trivial-
+                 rewrite(8)                            rewrite(8)
+                 (std form)                            (resolve)
+
+                      ^ |                                   ^ |
+                      | v                                   | v
+
+    smtpd(8)                                                         smtp(8)
+
+    qmqpd(8)  >- cleanup(8) -> incoming ->  active  ->   qmgr(8)  -< lmtp(8)
+
+    pickup(8)                                                        local(8)
+
+                       ^                      ^ |
+                       |                      | v
+
+                  bounces
+                 forwarding                deferred
+                  notices
+
+The table below summarizes all Postfix address manipulations. If you're reading
+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  |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
+
+The cleanup(8) server receives mail from outside of Postfix as well as mail
+from internal sources such as forwarded mail, undeliverable mail that is
+bounced to the sender, and postmaster notifications about problems with the
+mail system.
+
+The cleanup(8) server transforms the sender, recipients and message content
+into a standard form before writing it to an incoming queue file. The server
+cleans up sender and recipient addresses in message headers and in the
+envelope, adds missing message headers such as From: or Date: that are required
+by mail standards, and removes message headers such as Bcc: that should not be
+present. The cleanup(8) server delegates the more complex address manipulations
+to the trivial-rewrite(8) server as described later in this document.
+
+Address manipulations at this stage are:
+
+  * Rewrite addresses to standard form
+  * Canonical address mapping
+  * Address masquerading
+  * Automatic BCC recipients
+  * Virtual aliasing
+
+RReewwrriittee aaddddrreesssseess ttoo ssttaannddaarrdd ffoorrmm
+
+Before the cleanup(8) daemon runs an address through any address mapping lookup
+table, it first rewrites the address to the standard
+"user@fully.qualified.domain" form, by sending the address to the trivial-
+rewrite(8) daemon. The purpose of rewriting to standard form is to reduce the
+number of entries needed in lookup tables.
+
+The Postfix trivial-rewrite(8) daemon implements the following hard-coded
+address manipulations:
+
+    Rewrite "@hosta,@hostb:user@site" to "user@site"
+        In case you wonder what this is, the address form above is called a
+        route address, and specifies that mail for "user@site" be delivered via
+        "hosta" and "hostb". Usage of this form has been deprecated for a long
+        time. Postfix has no ability to handle route addresses, other than to
+        strip off the route part.
+
+        NOTE: Postfix versions 2.2 and later rewrite message headers from
+        remote SMTP clients only if the client matches the
+        local_header_rewrite_clients parameter, or if the
+        remote_header_rewrite_domain configuration parameter specifies a non-
+        empty value. To get the behavior before Postfix 2.2, specify
+        "local_header_rewrite_clients = static:all".
+
+    Rewrite "site!user" to "user@site"
+        This feature is controlled by the boolean swap_bangpath parameter
+        (default: yes). The purpose is to rewrite UUCP-style addresses to
+        domain style. This is useful only when you receive mail via UUCP, but
+        it probably does not hurt otherwise.
+
+        NOTE: Postfix versions 2.2 and later rewrite message headers from
+        remote SMTP clients only if the client matches the
+        local_header_rewrite_clients parameter, or if the
+        remote_header_rewrite_domain configuration parameter specifies a non-
+        empty value. To get the behavior before Postfix 2.2, specify
+        "local_header_rewrite_clients = static:all".
+
+    Rewrite "user%domain" to "user@domain"
+        This feature is controlled by the boolean allow_percent_hack parameter
+        (default: yes). Typically, this is used in order to deal with
+        monstrosities such as "user%domain@otherdomain".
+
+        NOTE: Postfix versions 2.2 and later rewrite message headers from
+        remote SMTP clients only if the client matches the
+        local_header_rewrite_clients parameter, or if the
+        remote_header_rewrite_domain configuration parameter specifies a non-
+        empty value. To get the behavior before Postfix 2.2, specify
+        "local_header_rewrite_clients = static:all".
+
+    Rewrite "user" to "user@$myorigin"
+        This feature is controlled by the boolean append_at_myorigin parameter
+        (default: yes). You should never turn off this feature, because a lot
+        of Postfix components expect that all addresses have the form
+        "user@domain".
+
+        NOTE: Postfix versions 2.2 and later rewrite message headers from
+        remote SMTP clients only if the client matches the
+        local_header_rewrite_clients parameter; otherwise they append the
+        domain name specified with the remote_header_rewrite_domain
+        configuration parameter, if one is specified. To get the behavior
+        before Postfix 2.2, specify "local_header_rewrite_clients = static:
+        all".
+
+        If your machine is not the main machine for $myorigin and you wish to
+        have some users delivered locally without going via that main machine,
+        make an entry in the virtual alias table that redirects
+        "user@$myorigin" to "user@$myhostname". See also the "delivering some
+        users locally" section in the STANDARD_CONFIGURATION_README document.
+
+    Rewrite "user@host" to "user@host.$mydomain"
+        This feature is controlled by the boolean append_dot_mydomain parameter
+        (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
+        local_header_rewrite_clients parameter; otherwise they append the
+        domain name specified with the remote_header_rewrite_domain
+        configuration parameter, if one is specified. To get the behavior
+        before Postfix 2.2, specify "local_header_rewrite_clients = static:
+        all".
+
+        Some will argue that rewriting "host" to "host.domain" is bad. That is
+        why it can be turned off. Others like the convenience of having
+        Postfix's own domain appended automatically.
+
+    Rewrite "user@site." to "user@site" (without the trailing dot).
+        A single trailing dot is silently removed. However, an address that
+        ends in multiple dots will be rejected as an invalid address.
+
+        NOTE: Postfix versions 2.2 and later rewrite message headers from
+        remote SMTP clients only if the client matches the
+        local_header_rewrite_clients parameter, or if the
+        remote_header_rewrite_domain configuration parameter specifies a non-
+        empty value. To get the behavior before Postfix 2.2, specify
+        "local_header_rewrite_clients = static:all".
+
+CCaannoonniiccaall aaddddrreessss mmaappppiinngg
+
+The cleanup(8) daemon uses the canonical(5) tables to rewrite addresses in
+message envelopes and in message headers. By default all header and envelope
+addresses are rewritten; this is controlled with the canonical_classes
+configuration parameter.
+
+NOTE: Postfix versions 2.2 and later rewrite message headers from remote SMTP
+clients only if the client matches the local_header_rewrite_clients parameter,
+or if the remote_header_rewrite_domain configuration parameter specifies a non-
+empty value. To get the behavior before Postfix 2.2, specify
+"local_header_rewrite_clients = static:all".
+
+Address rewriting is done for local and remote addresses. The mapping is useful
+to replace login names by "Firstname.Lastname" style addresses, or to clean up
+invalid domains in mail addresses produced by legacy mail systems.
+
+Canonical mapping is disabled by default. To enable, edit the canonical_maps
+parameter in the main.cf file and specify one or more lookup tables, separated
+by whitespace or commas.
+
+Example:
+
+    /etc/postfix/main.cf:
+        canonical_maps = hash:/etc/postfix/canonical
+
+    /etc/postfix/canonical:
+        wietse        Wietse.Venema
+
+For static mappings as shown above, lookup tables such as hash:, ldap:, mysql:
+or pgsql: are sufficient. For dynamic mappings you can use regular expression
+tables. This requires that you become intimately familiar with the ideas
+expressed in regexp_table(5), pcre_table(5) and canonical(5).
+
+In addition to the canonical maps which are applied to both sender and
+recipient addresses, you can specify canonical maps that are applied only to
+sender addresses or to recipient addresses.
+
+Example:
+
+    /etc/postfix/main.cf:
+        sender_canonical_maps = hash:/etc/postfix/sender_canonical
+        recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
+
+The sender and recipient canonical maps are applied before the common canonical
+maps. The sender_canonical_classes and recipient_canonical_classes parameters
+control what addresses are subject to sender_canonical_maps and
+recipient_canonical_maps mappings, respectively.
+
+Sender-specific rewriting is useful when you want to rewrite ugly sender
+addresses to pretty ones, and still want to be able to send mail to the those
+ugly address without creating a mailer loop.
+
+Canonical mapping can be turned off selectively for mail received by smtpd(8),
+qmqpd(8), or pickup(8), by overriding main.cf settings in the master.cf file.
+This feature is available in Postfix version 2.1 and later.
+
+Example:
+
+    /etc/postfix/master.cf:
+        127.0.0.1:10026    inet  n      -      n      -      -     smtpd
+            -o receive_override_options=no_address_mappings
+
+Note: do not specify whitespace around the "=" here.
+
+AAddddrreessss mmaassqquueerraaddiinngg
+
+Address masquerading is a method to hide hosts inside a domain behind their
+mail gateway, and to make it appear as if the mail comes from the gateway
+itself, instead of from individual machines.
+
+NOTE: Postfix versions 2.2 and later rewrite message headers from remote SMTP
+clients only if the client matches the local_header_rewrite_clients parameter,
+or if the remote_header_rewrite_domain configuration parameter specifies a non-
+empty value. To get the behavior before Postfix 2.2, specify
+"local_header_rewrite_clients = static:all".
+
+Address masquerading is disabled by default, and is implemented by the cleanup
+(8) server. To enable, edit the masquerade_domains parameter in the main.cf
+file and specify one or more domain names separated by whitespace or commas.
+When Postfix tries to masquerade a domain, it processes the list from left to
+right, and processing stops at the first match.
+
+Example:
+
+    /etc/postfix/main.cf:
+        masquerade_domains = foo.example.com example.com
+
+strips "any.thing.foo.example.com" to "foo.example.com", but strips
+"any.thing.else.example.com" to "example.com".
+
+A domain name prefixed with "!" means do not masquerade this domain or its
+subdomains:
+
+    /etc/postfix/main.cf:
+        masquerade_domains = !foo.example.com example.com
+
+does not change "any.thing.foo.example.com" and "foo.example.com", but strips
+"any.thing.else.example.com" to "example.com".
+
+The masquerade_exceptions configuration parameter specifies what user names
+should not be subjected to address masquerading. Specify one or more user names
+separated by whitespace or commas.
+
+Example:
+
+    /etc/postfix/main.cf:
+        masquerade_exceptions = root
+
+By default, Postfix makes no exceptions.
+
+Subtle point: by default, address masquerading is applied only to message
+headers and to envelope sender addresses, but not to envelope recipients. This
+allows you to use address masquerading on a mail gateway machine, while still
+being able to forward mail from outside to users on individual machines.
+
+In order to subject envelope recipient addresses to masquerading, too, specify
+(Postfix version 1.1 and later):
+
+    /etc/postfix/main.cf:
+        masquerade_classes = envelope_sender, envelope_recipient,
+            header_sender, header_recipient
+
+If you rewrite the envelope recipient like this, Postfix will no longer be able
+to send mail to individual machines.
+
+Address masquerading can be turned off selectively for mail received by smtpd
+(8), qmqpd(8), or pickup(8), by overriding main.cf settings in the master.cf
+file. This feature is available in Postfix version 2.1 and later.
+
+Example:
+
+    /etc/postfix/master.cf:
+        127.0.0.1:10026    inet  n      -      n      -      -     smtpd
+            -o receive_override_options=no_address_mappings
+
+Note: do not specify whitespace around the "=" here.
+
+AAuuttoommaattiicc BBCCCC rreecciippiieennttss
+
+After applying the canonical and masquerade mappings, the cleanup(8) daemon can
+generate optional BCC (blind carbon-copy) recipients. Postfix provides three
+mechanisms:
+
+    always_bcc = address
+        Deliver a copy of all mail to the specified address. In Postfix
+        versions before 2.1, this feature is implemented by smtpd(8), qmqpd(8),
+        or pickup(8).
+    sender_bcc_maps = type:table
+        Search the specified "type:table" lookup table with the envelope sender
+        address for an automatic BCC address. This feature is available in
+        Postfix 2.1 and later.
+    recipient_bcc_maps = type:table
+        Search the specified "type:table" lookup table with the envelope
+        recipient address for an automatic BCC address. This feature is
+        available in Postfix 2.1 and later.
+
+Note: automatic BCC recipients are produced only for new mail. To avoid mailer
+loops, automatic BCC recipients are not generated for mail that Postfix
+forwards internally, nor for mail that Postfix generates itself.
+
+Automatic BCC recipients (including always_bcc) can be turned off selectively
+for mail received by smtpd(8), qmqpd(8), or pickup(8), by overriding main.cf
+settings in the master.cf file. This feature is available in Postfix version
+2.1 and later.
+
+Example:
+
+    /etc/postfix/master.cf:
+        127.0.0.1:10026    inet  n      -      n      -      -     smtpd
+            -o receive_override_options=no_address_mappings
+
+Note: do not specify whitespace around the "=" here.
+
+VViirrttuuaall aalliiaassiinngg
+
+Before writing the recipients to the queue file, the cleanup(8) daemon uses the
+optional virtual(5) alias tables to redirect mail for recipients. The mapping
+affects only envelope recipient addresses; it has no effect on message headers
+or envelope sender addresses. Virtual alias lookups are useful to redirect mail
+for virtual alias domains to real user mailboxes, and to redirect mail for
+domains that no longer exist. Virtual alias lookups can also be used to
+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.
+
+Example:
+
+    /etc/postfix/main.cf:
+        virtual_alias_maps = hash:/etc/postfix/virtual
+
+    /etc/postfix/virtual:
+        Wietse.Venema        wietse
+
+Addresses found in virtual alias maps are subjected to another iteration of
+virtual aliasing, but are not subjected to canonical mapping, in order to avoid
+loops.
+
+For static mappings as shown above, lookup tables such as hash:, ldap:, mysql:
+or pgsql: are sufficient. For dynamic mappings you can use regular expression
+tables. This requires that you become intimately familiar with the ideas
+expressed in regexp_table(5), pcre_table(5) and virtual(5).
+
+Virtual aliasing can be turned off selectively for mail received by smtpd(8),
+qmqpd(8), or pickup(8), by overriding main.cf settings in the master.cf file.
+This feature is available in Postfix version 2.1 and later.
+
+Example:
+
+    /etc/postfix/master.cf:
+        127.0.0.1:10026    inet  n      -      n      -      -     smtpd
+            -o receive_override_options=no_address_mappings
+
+Note: do not specify whitespace around the "=" here.
+
+At this point the message is ready to be stored into the Postfix incoming
+queue.
+
+AAddddrreessss rreewwrriittiinngg wwhheenn mmaaiill iiss ddeelliivveerreedd
+
+The Postfix queue manager sorts mail according to its destination and gives it
+to Postfix delivery agents such as local(8), smtp(8), or lmtp(8). Just like the
+cleanup(8) server, the Postfix queue manager delegates the more complex address
+manipulations to the trivial-rewrite(8) server.
+
+Address manipulations at this stage are:
+
+  * Resolve address to (transport, next-hop destination)
+  * Relocated users table
+
+Each Postfix delivery agent tries to deliver the mail to its destination, while
+encapsulating the sender, recipients, and message content according to the
+rules of the SMTP, LMTP, etc. protocol. When mail cannot be delivered, it is
+either returned to the sender or moved to the deferred queue and tried again
+later.
+
+Address manipulations when mail is delivered via the smtp(8) delivery agent:
+
+  * Generic mapping for outgoing SMTP mail
+
+Address manipulations when mail is delivered via the local(8) delivery agent:
+
+  * Local alias database
+  * Local per-user .forward files
+  * Local catch-all address
+
+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 ((ttrraannssppoorrtt,, nneexxtt--hhoopp ddeessttiinnaattiioonn))
+
+The Postfix qmgr(8) queue manager selects new mail from the incoming queue or
+old mail from the deferred queue. First it looks for overrides:
+
+  * 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.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |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 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+
+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.
+
+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.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |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
+
+Next, the trivial-rewrite(8) address rewriting and resolving daemon runs each
+recipient through the relocated(5) database. This table provides information on
+how to reach users that no longer have an account, or what to do with mail for
+entire domains that no longer exist. When mail is sent to an address that is
+listed in this table, the message is returned to the sender with an informative
+message.
+
+The relocated(5) database is searched after transport(5) table lookups, in
+anticipation of transport(5) tables that can replace one recipient address by a
+different one.
+
+Lookups of relocated users are disabled by default. To enable, edit the
+relocated_maps parameter in the main.cf file and specify one or more lookup
+tables, separated by whitespace or commas.
+
+Example:
+
+    /etc/postfix/main.cf:
+        relocated_maps = hash:/etc/postfix/relocated
+
+    /etc/postfix/relocated:
+        username@example.com      otheruser@elsewhere.tld
+
+As of Postfix version 2, mail for a relocated user will be rejected by the SMTP
+server with the reason "user has moved to otheruser@elsewhere.tld". Older
+Postfix versions will receive the mail first, and then return it to the sender
+as undeliverable, with the same reason.
+
+GGeenneerriicc mmaappppiinngg ffoorr oouuttggooiinngg SSMMTTPP mmaaiill
+
+Some hosts have no valid Internet domain name, and instead use a name such as
+localdomain.local. This can be a problem when you want to send mail over the
+Internet, because many mail servers reject mail addresses with invalid domain
+names.
+
+With the smtp_generic_maps parameter you can specify generic(5) lookup tables
+that replace local mail addresses by valid Internet addresses when mail leaves
+the machine via SMTP. The generic(5) mapping replaces envelope and header
+addresses, and is non-recursive. It does not happen when you send mail between
+addresses on the local machine.
+
+This feature is available in Postfix version 2.2 and later.
+
+Example:
+
+    /etc/postfix/main.cf:
+        smtp_generic_maps = hash:/etc/postfix/generic
+
+    /etc/postfix/generic:
+        his@localdomain.local               hisaccount@hisisp.example
+        her@localdomain.local               heraccount@herisp.example
+        @localdomain.local                  hisaccount+local@hisisp.example
+
+When mail is sent to a remote host via SMTP, this replaces
+his@localdomain.local by his ISP mail address, replaces her@localdomain.local
+by her ISP mail address, and replaces other local addresses by his ISP account,
+with an address extension of +local (this example assumes that the ISP supports
+"+" style address extensions).
+
+LLooccaall aalliiaass ddaattaabbaassee
+
+When mail is to be delivered locally, the local(8) delivery agent runs each
+local recipient name through the aliases(5) database. The mapping does not
+affect addresses in message headers. Local aliases are typically used to
+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:
+
+    /etc/postfix/main.cf:
+        alias_maps = hash:/etc/aliases
+        alias_maps = dbm:/etc/aliases, nis:mail.aliases
+
+The pathname of the alias database file is controlled with the alias_database
+configuration parameter. The value is system dependent. Usually it is one of
+the following:
+
+    /etc/postfix/main.cf:
+        alias_database = hash:/etc/aliases (4.4BSD, LINUX)
+        alias_database = dbm:/etc/aliases (4.3BSD, SYSV<4)
+        alias_database = dbm:/etc/mail/aliases (SYSV4)
+
+An aliases(5) file can specify that mail should be delivered to a local file,
+or to a command that receives the message in the standard input stream. For
+security reasons, deliveries to command and file destinations are performed
+with the rights of the alias database owner. A default userid, default_privs,
+is used for deliveries to commands or files in "root"-owned aliases.
+
+LLooccaall ppeerr--uusseerr ..ffoorrwwaarrdd ffiilleess
+
+With delivery via the local(8) delivery agent, users can control their own mail
+delivery by specifying destinations in a file called .forward in their home
+directories. The syntax of these files is the same as with the local aliases(5)
+file, except that the left-hand side of the alias (lookup key and colon) are
+not present.
+
+LLooccaall ccaattcchh--aallll aaddddrreessss
+
+When the local(8) delivery agent finds that a message recipient does not exist,
+the message is normally returned to the sender ("user unknown"). Sometimes it
+is desirable to forward mail for non-existing recipients to another machine.
+For this purpose you can specify an alternative destination with the
+luser_relay configuration parameter.
+
+Alternatively, mail for non-existent recipients can be delegated to an entirely
+different message transport, as specified with the fallback_transport
+configuration parameter. For details, see the local(8) delivery agent
+documentation.
+
+Note: if you use the luser_relay feature in order to receive mail for non-UNIX
+accounts, then you must specify:
+
+    /etc/postfix/main.cf:
+        local_recipient_maps =
+
+(i.e. empty) in the main.cf file, otherwise the Postfix SMTP server will reject
+mail for non-UNIX accounts with "User unknown in local recipient table". See
+the LOCAL_RECIPIENT_README file for more information on this.
+
+luser_relay can specify one address. It is subjected to "$name" expansions.
+Examples:
+
+    $user@other.host
+        The bare username, without address extension, is prepended to
+        "@other.host". For example, mail for "username+foo" is sent to
+        "username@other.host".
+
+    $local@other.host
+        The entire original recipient localpart, including address extension,
+        is prepended to "@other.host". For example, mail for "username+foo" is
+        sent to "username+foo@other.host".
+
+    sysadmin+$user
+        The bare username, without address extension, is appended to
+        "sysadmin". For example, mail for "username+foo" is sent to
+        "sysadmin+username".
+
+    sysadmin+$local
+        The entire original recipient localpart, including address extension,
+        is appended to "sysadmin". For example, mail for "username+foo" is sent
+        to "sysadmin+username+foo".
+
+DDeebbuuggggiinngg yyoouurr aaddddrreessss mmaanniippuullaattiioonnss
+
+Postfix version 2.1 and later can produce mail delivery reports for debugging
+purposes. These reports not only show sender/recipient addresses after address
+rewriting and alias expansion or forwarding, they also show information about
+delivery to mailbox, delivery to non-Postfix command, responses from remote
+SMTP servers, and so on.
+
+Postfix can produce two types of mail delivery reports for debugging:
+
+  * What-if: report what would happen, but do not actually deliver mail. This
+    mode of operation is requested with:
+
+    $ //uussrr//ssbbiinn//sseennddmmaaiill --bbvv aaddddrreessss......
+    Mail Delivery Status Report will be mailed to <your login name>.
+
+  * What happened: deliver mail and report successes and/or failures, including
+    replies from remote SMTP servers. This mode of operation is requested with:
+
+    $ //uussrr//ssbbiinn//sseennddmmaaiill --vv aaddddrreessss......
+    Mail Delivery Status Report will be mailed to <your login name>.
+
+These reports contain information that is generated by Postfix delivery agents.
+Since these run as daemon processes and do not interact with users directly,
+the result is sent as mail to the sender of the test message. The format of
+these reports is practically identical to that of ordinary non-delivery
+notifications.
+
+As an example, below is the delivery report that is produced with the command
+"sendmail -bv postfix-users@postfix.org". The first part of the report contains
+human-readable text. In this case, mail would be delivered via mail.cloud9.net,
+and the SMTP server replies with "250 Ok". Other reports may show delivery to
+mailbox, or delivery to non-Postfix command.
+
+    Content-Description: Notification
+    Content-Type: text/plain
+
+    This is the mail system at host spike.porcupine.org.
+
+    Enclosed is the mail delivery report that you requested.
+
+                            The mail system
+
+    <postfix-users@postfix.org>: delivery via mail.cloud9.net[168.100.1.4]: 250
+    2.1.5 Ok
+
+The second part of the report is in machine-readable form, and includes the
+following information:
+
+  * The envelope sender address (wietse@porcupine.org).
+  * The envelope recipient address (postfix-users@postfix.org). If the
+    recipient address was changed by Postfix then Postfix also includes the
+    original recipient address.
+  * The delivery status.
+
+Some details depend on Postfix version. The example below is for Postfix
+version 2.3 and later.
+
+    Content-Description: Delivery report
+    Content-Type: message/delivery-status
+
+    Reporting-MTA: dns; spike.porcupine.org
+    X-Postfix-Queue-ID: 84863BC0E5
+    X-Postfix-Sender: rfc822; wietse@porcupine.org
+    Arrival-Date: Sun, 26 Nov 2006 17:01:01 -0500 (EST)
+
+    Final-Recipient: rfc822; postfix-users@postfix.org
+    Action: deliverable
+    Status: 2.1.5
+    Remote-MTA: dns; mail.cloud9.net
+    Diagnostic-Code: smtp; 250 2.1.5 Ok
+
+The third part of the report contains the message that Postfix would have
+delivered, including From: and To: message headers, so that you can see any
+effects of address rewriting on those. Mail submitted with "sendmail -bv" has
+no body content so none is shown in the example below.
+
+    Content-Description: Message
+    Content-Type: message/rfc822
+
+    Received: by spike.porcupine.org (Postfix, from userid 1001)
+            id 84863BC0E5; Sun, 26 Nov 2006 17:01:01 -0500 (EST)
+    Subject: probe
+    To: postfix-users@postfix.org
+    Message-Id: <20061126220101.84863BC0E5@spike.porcupine.org>
+    Date: Sun, 26 Nov 2006 17:01:01 -0500 (EST)
+    From: wietse@porcupine.org (Wietse Venema)
+
--- a/README_FILES/ADDRESS_VERIFICATION_README
+++ b/README_FILES/ADDRESS_VERIFICATION_README
@ -0,0 +1,451 @@
+PPoossttffiixx AAddddrreessss VVeerriiffiiccaattiioonn HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+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 denylisted by some
+providers. See also the "Limitations" section below for more.
+
+WWhhaatt PPoossttffiixx aaddddrreessss vveerriiffiiccaattiioonn ccaann ddoo ffoorr yyoouu
+
+Address verification is a feature that allows the Postfix SMTP server to block
+a sender (MAIL FROM) or recipient (RCPT TO) address until the address has been
+verified to be deliverable.
+
+The technique has obvious uses to reject junk mail with an unreplyable sender
+address.
+
+The technique is also useful to block mail for undeliverable recipients, for
+example on a mail relay host that does not have a list of all the valid
+recipient addresses. This prevents undeliverable junk mail from entering the
+queue, so that Postfix doesn't have to waste resources trying to send MAILER-
+DAEMON messages back.
+
+This feature is available in Postfix version 2.1 and later.
+
+Topics covered in this document:
+
+  * How address verification works
+  * Limitations of address verification
+  * Recipient address verification
+  * Sender address verification for mail from frequently forged domains
+  * Sender address verification for all email
+  * Address verification database
+  * Managing the address verification database
+  * Controlling the routing of address verification probes
+  * Forced probe routing examples
+  * Limitations of forced probe routing
+
+HHooww aaddddrreessss vveerriiffiiccaattiioonn wwoorrkkss
+
+A Postfix MTA verifies a sender or recipient address by probing the preferred
+MTAs for that address, without actually delivering mail. The preferred MTAs
+could include the Postfix MTA itself, or some remote MTAs (SMTP interruptus).
+Probe messages are like normal mail, except that they are never delivered,
+deferred or bounced; probe messages are always discarded.
+
+                                             probe     Postfix
+                                            message ->   mail
+                Postfix        Postfix   ->             queue
+    Internet ->  SMTP   <->     verify
+                server          server                      |
+                                                            v
+
+                                         <-            Postfix
+                                             probe  <- delivery -> Local
+                                            status      agents  -> Remote
+                                    ^
+                                    |
+                                    v
+
+                              Address
+                            verification
+                              database
+
+With Postfix address verification turned on, normal mail will suffer only a
+short delay of up to 6 seconds while an address is being verified for the first
+time. Once an address status is known, the status is cached and Postfix replies
+immediately.
+
+When verification takes too long the Postfix SMTP server defers the sender or
+recipient address with a 450 reply. Normal mail clients will connect again
+after some delay. The address verification delay is configurable with the
+main.cf address_verify_poll_count and address_verify_poll_delay parameters. See
+postconf(5) for details.
+
+LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffiiccaattiioonn
+
+  * Postfix assumes that a remote SMTP server will reject unknown addresses in
+    reply to the RCPT TO command. However, some sites report this in reply to
+    the DATA command. For such sites you may configure a workaround with the
+    smtp_address_verify_target parameter (Postfix 3.0 and later).
+
+  * When verifying a remote address, Postfix probes the preferred MTAs for that
+    address, without actually delivering mail. If a preferred MTA accepts the
+    address, then Postfix assumes that the address is deliverable. In reality,
+    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 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
+    intermediate relayhost; this breaks address verification. See below,
+    section "Controlling the routing of address verification probes", for how
+    to override mail routing and for possible limitations when you have to do
+    this.
+
+  * Postfix assumes that an address is undeliverable when a preferred MTA for
+    the address rejects the probe, regardless of the reason for rejection
+    (client rejected, HELO rejected, MAIL FROM rejected, etc.). Thus, Postfix
+    rejects an address when a preferred MTA for that address rejects mail from
+    your machine for any reason. This is not a limitation, but it is mentioned
+    here just in case people believe that it is a limitation.
+
+  * Unfortunately, some sites do not reject unknown addresses in reply to the
+    RCPT TO or DATA command, but instead report a delivery failure in response
+    to end of DATA after a message is transferred. Postfix address verification
+    does not work with such sites.
+
+  * By default, Postfix probe messages have a sender address "double-
+    bounce@$myorigin" (with Postfix versions before 2.5, the default is
+    "postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does
+    not reject mail for this address.
+
+    You can change the probe sender address into the null address
+    ("address_verify_sender ="). This is UNSAFE because address probes will
+    fail with mis-configured sites that reject MAIL FROM: <>, while probes from
+    "double-bounce@$myorigin" would succeed.
+
+  * The downside of using a non-empty sender address is that the address may
+    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
+    address_verify_sender_ttl value.
+
+RReecciippiieenntt aaddddrreessss vveerriiffiiccaattiioonn
+
+As mentioned earlier, recipient address verification is useful to block mail
+for undeliverable recipients on a mail relay host that does not have a list of
+all valid recipient addresses. This can help to prevent the mail queue from
+filling up with MAILER-DAEMON messages.
+
+Recipient address verification is relatively straightforward and there are no
+surprises. If a recipient probe fails, then Postfix rejects mail for the
+recipient address. If a recipient probe succeeds, then Postfix accepts mail for
+the recipient address. However, recipient address verification probes can
+increase the load on down-stream MTAs when you're being flooded by backscatter
+bounces, or when some spammer is mounting a dictionary attack.
+
+By default, address verification results are saved in a persistent database
+(Postfix version 2.7 and later; with earlier versions, specify the database in
+main.cf as described later). The persistent database helps to avoid probing the
+same address repeatedly.
+
+    /etc/postfix/main.cf:
+        smtpd_recipient_restrictions =
+            permit_mynetworks
+            # reject_unauth_destination is not needed here if the mail
+            # relay policy is specified under smtpd_relay_restrictions
+            # (available with Postfix 2.10 and later).
+            reject_unauth_destination
+            ...
+            reject_unknown_recipient_domain
+            reject_unverified_recipient
+            ...
+        # Postfix 2.6 and later privacy feature.
+        # unverified_recipient_reject_reason = Address lookup failed
+
+        # Postfix 3.2 and earlier workaround.
+        # Do not set enable_original_recipient=no. This prevents Postfix
+        # from saving the recipient address verification result under
+        # the original address, when the address verification probe
+        # message goes through address aliasing or canonical mapping.
+
+The "reject_unknown_recipient_domain" restriction blocks mail for non-existent
+domains. Putting this before "reject_unverified_recipient" avoids the overhead
+of generating unnecessary probe messages.
+
+The unverified_recipient_reject_code parameter (default 450) specifies the
+numerical Postfix SMTP server reply code when a recipient address is known to
+bounce. Change this setting into 550 when you trust Postfix's judgments.
+
+The following features are available in Postfix 2.6 and later.
+
+The unverified_recipient_defer_code parameter (default 450) specifies the
+numerical Postfix SMTP server reply code when a recipient address probe fails
+with some temporary error. Some sites insist on changing this into 250. NOTE:
+This change turns MX servers into backscatter sources when the load is high.
+
+The unverified_recipient_reject_reason parameter (default: empty) specifies
+fixed text that Postfix will send to remote SMTP clients, instead of sending
+actual address verification details. Do not specify the SMTP status code or
+enhanced status code.
+
+The unverified_recipient_tempfail_action parameter (default: defer_if_permit)
+specifies the Postfix SMTP server action when a recipient address verification
+probe fails with some temporary error.
+
+SSeennddeerr aaddddrreessss vveerriiffiiccaattiioonn ffoorr mmaaiill ffrroomm ffrreeqquueennttllyy ffoorrggeedd ddoommaaiinnss
+
+Only for very small sites, it is relatively safe to turn on sender address
+verification for specific domains that often appear in forged email.
+
+    /etc/postfix/main.cf:
+        smtpd_sender_restrictions = hash:/etc/postfix/sender_access
+        unverified_sender_reject_code = 550
+        # Postfix 2.6 and later.
+        # unverified_sender_defer_code = 250
+
+        # Default setting for Postfix 2.7 and later.
+        # Note 1: Be sure to read the "Caching" section below!
+        # Note 2: Avoid hash files here. Use btree or lmdb instead.
+        address_verify_map = btree:/var/lib/postfix/verify
+
+        # Postfix 3.2 and earlier workaround.
+        # Do not set enable_original_recipient=no. This prevents Postfix
+        # from saving the sender address verification result under the
+        # original address, when the address verification probe message
+        # goes through address aliasing or canonical mapping.
+
+    /etc/postfix/sender_access:
+        # Don't do this when you handle lots of email.
+        aol.com     reject_unverified_sender
+        hotmail.com reject_unverified_sender
+        bigfoot.com reject_unverified_sender
+        ... etcetera ...
+
+At some point in cyberspace/time, a list of frequently forged MAIL FROM domains
+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.
+
+SSeennddeerr aaddddrreessss vveerriiffiiccaattiioonn ffoorr aallll eemmaaiill
+
+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 allow lists for specific addresses, or
+even for entire domains.
+
+To find out how sender address verification would affect your mail, specify
+"warn_if_reject reject_unverified_sender" so that you can see what mail would
+be blocked:
+
+    /etc/postfix/main.cf:
+        smtpd_sender_restrictions =
+            permit_mynetworks
+            ...
+            check_sender_access hash:/etc/postfix/sender_access
+            reject_unknown_sender_domain
+            warn_if_reject reject_unverified_sender
+            ...
+        # Postfix 2.6 and later.
+        # unverified_sender_reject_reason = Address verification failed
+
+        # Default setting for Postfix 2.7 and later.
+        # Note 1: Be sure to read the "Caching" section below!
+        # Note 2: Avoid hash files here. Use btree or lmdb instead.
+        address_verify_map = btree:/var/lib/postfix/verify
+
+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 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 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.
+
+    /etc/postfix/sender_access
+        securityfocus.com OK
+        ...
+
+The "reject_unknown_sender_domain" restriction blocks mail from non-existent
+domains. Putting this before "reject_unverified_sender" avoids the overhead of
+generating unnecessary probe messages.
+
+The unverified_sender_reject_code parameter (default 450) specifies the
+numerical Postfix server reply code when a sender address is known to bounce.
+Change this setting into 550 when you trust Postfix's judgments.
+
+The following features are available in Postfix 2.6 and later.
+
+The unverified_sender_defer_code parameter (default 450) specifies the
+numerical Postfix SMTP server reply code when a sender address verification
+probe fails with some temporary error. Specify a valid 2xx or 4xx code.
+
+The unverified_sender_reject_reason parameter (default: empty) specifies fixed
+text that Postfix will send to remote SMTP clients, instead of sending actual
+address verification details. Do not specify the SMTP status code or enhanced
+status code.
+
+The unverified_sender_tempfail_action parameter (default: defer_if_permit)
+specifies the Postfix SMTP server action when a sender address verification
+probe fails with some temporary error.
+
+AAddddrreessss vveerriiffiiccaattiioonn ddaattaabbaassee
+
+To improve performance, the Postfix verify(8) daemon can save address
+verification results to a persistent database. This is enabled by default with
+Postfix 2.7 and later. The address_verify_map (NOTE: singular) configuration
+parameter specifies persistent storage for sender or recipient address
+verification results. If you specify an empty value, all address verification
+results are lost after "postfix reload" or "postfix stop".
+
+    # Example 1: Default setting for Postfix 2.7 and later.
+    # Note: avoid hash files here. Use btree or lmdb instead.
+    /etc/postfix/main.cf:
+        address_verify_map = btree:$data_directory/verify_cache
+
+    # Example 2: Shared persistent lmdb: cache (Postfix 2.11 or later).
+    # Disable automatic cache cleanup in all Postfix instances except
+    # for one instance that will be responsible for cache cleanup.
+    /etc/postfix/main.cf:
+        address_verify_map = lmdb:$data_directory/verify_cache
+        # address_verify_cache_cleanup_interval = 0
+
+    # Example 3: Shared persistent btree: cache (Postfix 2.9 or later).
+    # Disable automatic cache cleanup in all Postfix instances except
+    # for one instance that will be responsible for cache cleanup.
+    /etc/postfix/main.cf:
+        address_verify_map = proxy:btree:$data_directory/verify_cache
+        # address_verify_cache_cleanup_interval = 0
+
+    # Example 4: Shared memory cache (requires Postfix 2.9 or later).
+    # Disable automatic cache cleanup in all Postfix instances.
+    # See memcache_table(5) for details.
+    /etc/postfix/main.cf:
+        address_verify_map = memcache:/etc/postfix/verify-memcache.cf
+        address_verify_cache_cleanup_interval = 0
+
+    # Example 5: Default setting for Postfix 2.6 and earlier.
+    # This uses non-persistent storage only.
+    /etc/postfix/main.cf:
+        address_verify_map =
+
+NOTE 1: The database file should be stored under a Postfix-owned directory,
+such as $data_directory.
+
+    As of version 2.5, Postfix no longer uses root privileges when opening this
+    file. To maintain backwards compatibility, an attempt to open the file
+    under a non-Postfix directory is redirected to the Postfix-owned
+    data_directory, and a warning is logged. If you wish to continue using a
+    pre-existing database file, change its file ownership to the account
+    specified with the mail_owner parameter, and either move the file to the
+    data_directory, or move it to some other Postfix-owned directory.
+
+NOTE 2: Do not put this file in a file system that may run out of space. When
+the address verification table gets corrupted the world comes to an end and YOU
+will have to MANUALLY fix things as described in the next section. Meanwhile,
+you will not receive mail via SMTP.
+
+NOTE 3: The verify(8) daemon will create a new database when none exists. It
+will open or create the file before entering the chroot jail.
+
+MMaannaaggiinngg tthhee aaddddrreessss vveerriiffiiccaattiioonn ddaattaabbaassee
+
+The verify(8) manual page describes parameters that control how long address
+verification results are cached before they need to be refreshed, and how long
+results can remain "unrefreshed" before they expire. Postfix uses different
+controls for positive results (address was accepted) and for negative results
+(address was rejected, or address verification failed for some other reason).
+
+The verify(8) daemon will periodically remove expired entries from the address
+verification database, and log the number of entries retained and dropped
+(Postfix versions 2.7 and later). A cleanup run is logged as "partial" when the
+daemon terminates early because of "postfix reload, "postfix stop", or because
+the daemon received no requests for $max_idle seconds. Postfix versions 2.6 and
+earlier do not implement automatic address verification database cleanup.
+There, the database is managed manually as described next.
+
+When the address verification database file becomes too big, or when it becomes
+corrupted, the solution is to manually rename or delete (NOT: truncate) the
+file and run "postfix reload". The verify(8) daemon will then create a new
+database file.
+
+CCoonnttrroolllliinngg tthhee rroouuttiinngg ooff aaddddrreessss vveerriiffiiccaattiioonn pprroobbeess
+
+By default, Postfix sends address verification probe messages via the same
+route as regular mail, because that normally produces the most accurate result.
+It's no good to verify a local address by connecting to your own SMTP port;
+that just triggers all kinds of mailer loop alarms. The same is true for any
+destination that your machine is best MX host for: hidden domains, virtual
+domains, etc.
+
+However, some sites have a complex infrastructure where mail is not sent
+directly to the Internet, but is instead given to an intermediate relayhost.
+This is a problem for address verification, because remote Internet addresses
+can be verified only when Postfix can access remote destinations directly.
+
+For this reason, Postfix allows you to override the routing parameters when it
+delivers an address verification probe message.
+
+First, the address_verify_relayhost parameter allows you to override the
+relayhost setting, and the address_verify_transport_maps parameter allows you
+to override the transport_maps setting. The
+address_verify_sender_dependent_relayhost_maps parameter does the same for
+sender-dependent relayhost selection.
+
+Second, each address class is given its own address verification version of the
+message delivery transport, as shown in the table below. Address classes are
+defined in the ADDRESS_CLASS_README file.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |DDoommaaiinn lliisstt            |RReegguullaarr ttrraannssppoorrtt|VVeerriiffyy ttrraannssppoorrtt                |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |mydestination          |local_transport  |address_verify_local_transport  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |virtual_alias_domains  |(not applicable) |(not applicable)                |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |virtual_mailbox_domains|virtual_transport|address_verify_virtual_transport|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |relay_domains          |relay_transport  |address_verify_relay_transport  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |(not applicable)       |default_transport|address_verify_default_transport|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+By default, the parameters that control delivery of address probes have the
+same value as the parameters that control normal mail delivery.
+
+FFoorrcceedd pprroobbee rroouuttiinngg eexxaammpplleess
+
+In a typical scenario one would override the relayhost setting for address
+verification probes and leave everything else alone:
+
+    /etc/postfix/main.cf:
+        relayhost = $mydomain
+        address_verify_relayhost =
+        ...
+
+Sites behind a network address translation box might have to use a different
+SMTP client that sends the correct hostname information:
+
+    /etc/postfix/main.cf:
+        relayhost = $mydomain
+        address_verify_relayhost =
+        address_verify_default_transport = direct_smtp
+
+    /etc/postfix/master.cf:
+        direct_smtp .. .. .. ..  .. .. .. .. .. smtp
+            -o smtp_helo_name=nat.box.tld
+
+LLiimmiittaattiioonnss ooff ffoorrcceedd pprroobbee rroouuttiinngg
+
+Inconsistencies can happen when probe messages don't follow the same path as
+regular mail. For example, a message can be accepted when it follows the
+regular route while an otherwise identical probe message is rejected when it
+follows the forced route. The opposite can happen, too, but is less likely.
+
--- a/README_FILES/BACKSCATTER_README
+++ b/README_FILES/BACKSCATTER_README
@ -0,0 +1,281 @@
+PPoossttffiixx BBaacckkssccaatttteerr HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document describes features that require Postfix version 2.0 or later.
+
+Topics covered in this document:
+
+  * What is backscatter mail?
+  * How do I block backscatter mail to random recipient addresses?
+  * How do I block backscatter mail to real recipient addresses?
+
+      o Blocking backscatter mail with forged mail server information
+      o Blocking backscatter mail with forged sender information
+      o Blocking backscatter mail with other forged information
+      o Blocking backscatter mail from virus scanners
+
+The examples use Perl Compatible Regular Expressions (Postfix pcre: tables),
+but also provide a translation to POSIX regular expressions (Postfix regexp:
+tables). PCRE is preferred primarily because the implementation is often
+faster.
+
+WWhhaatt iiss bbaacckkssccaatttteerr mmaaiill??
+
+When a spammer or worm sends mail with forged sender addresses, innocent sites
+are flooded with undeliverable mail notifications. This is called backscatter
+mail. With Postfix, you know that you're a backscatter victim when your logfile
+goes on and on like this:
+
+    Dec  4 04:30:09 hostname postfix/smtpd[58549]: NOQUEUE: reject:
+    RCPT from xxxxxxx[x.x.x.x]: 550 5.1.1 <yyyyyy@your.domain.here>:
+    Recipient address rejected: User unknown; from=<>
+    to=<yyyyyy@your.domain.here> proto=ESMTP helo=<zzzzzz>
+
+What you see are lots of "user unknown" errors with "from=<>". These are error
+reports from MAILER-DAEMONs elsewhere on the Internet, about email that was
+sent with a false sender address in your domain.
+
+HHooww ddoo II bblloocckk bbaacckkssccaatttteerr mmaaiill ttoo rraannddoomm rreecciippiieenntt aaddddrreesssseess??
+
+If your machine receives backscatter mail to random addresses, configure
+Postfix to reject all mail for non-existent recipients as described in the
+LOCAL_RECIPIENT_README and STANDARD_CONFIGURATION_README documentation.
+
+If your machine runs Postfix 2.0 and earlier, disable the "pause before reject"
+feature in the SMTP server. If your system is under stress then it should not
+waste time.
+
+    /etc/postfix/main.cf:
+        # Not needed with Postfix 2.1 and later.
+        smtpd_error_sleep_time = 0
+
+        # Not needed with Postfix 2.4 and later.
+        unknown_local_recipient_reject_code = 550
+
+HHooww ddoo II bblloocckk bbaacckkssccaatttteerr mmaaiill ttoo rreeaall rreecciippiieenntt aaddddrreesssseess??
+
+When backscatter mail passes the "unknown recipient" barrier, there still is no
+need to despair. Many mail systems are kind enough to attach the message
+headers of the undeliverable mail in the non-delivery notification. These
+message headers contain information that you can use to recognize and block
+forged mail.
+
+BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill wwiitthh ffoorrggeedd mmaaiill sseerrvveerr iinnffoorrmmaattiioonn
+
+Although my email address is "wietse@porcupine.org", all my mail systems
+announce themselves with the SMTP HELO command as "hostname.porcupine.org".
+Thus, if returned mail has a Received: message header like this:
+
+    Received: from porcupine.org ...
+
+Then I know that this is almost certainly forged mail (almost; see next section
+for the fly in the ointment). Mail that is really sent by my systems looks like
+this:
+
+    Received: from hostname.porcupine.org ...
+
+For the same reason the following message headers are very likely to be the
+result of forgery:
+
+    Received: from host.example.com ([1.2.3.4] helo=porcupine.org) ...
+    Received: from [1.2.3.4] (port=12345 helo=porcupine.org) ...
+    Received: from host.example.com (HELO porcupine.org) ...
+    Received: from host.example.com (EHLO porcupine.org) ...
+
+Some forgeries show up in the way that a mail server reports itself in
+Received: message headers. Keeping in mind that all my systems have a mail
+server name of hostname.porcupine.org, the following is definitely a forgery:
+
+    Received: by porcupine.org ...
+    Received: from host.example.com ( ... ) by porcupine.org ...
+
+Another frequent sign of forgery is the Message-ID: header. My systems produce
+a Message-ID: of <stuff@hostname.porcupine.org>. The following are forgeries,
+especially the first one:
+
+    Message-ID: <1cb479435d8eb9.2beb1.qmail@porcupine.org>
+    Message-ID: <yulszqocfzsficvzzju@porcupine.org>
+
+To block such backscatter I use header_checks and body_checks patterns like
+this:
+
+    /etc/postfix/main.cf:
+        header_checks = pcre:/etc/postfix/header_checks
+        body_checks = pcre:/etc/postfix/body_checks
+
+    /etc/postfix/header_checks:
+        # Do not indent the patterns between "if" and "endif".
+        if /^Received:/
+        /^Received: +from +(porcupine\.org) +/
+            reject forged client name in Received: header: $1
+        /^Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)
+    (porcupine\.org)\)/
+            reject forged client name in Received: header: $2
+        /^Received:.* +by +(porcupine\.org)\b/
+            reject forged mail server name in Received: header: $1
+        endif
+        /^Message-ID:.* <!&!/ DUNNO
+        /^Message-ID:.*@(porcupine\.org)/
+            reject forged domain name in Message-ID: header: $1
+
+    /etc/postfix/body_checks:
+        # Do not indent the patterns between "if" and "endif".
+        if /^[> ]*Received:/
+        /^[> ]*Received: +from +(porcupine\.org) /
+            reject forged client name in Received: header: $1
+        /^[> ]*Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)
+    (porcupine\.org)\)/
+            reject forged client name in Received: header: $2
+        /^[> ]*Received:.* +by +(porcupine\.org)\b/
+            reject forged mail server name in Received: header: $1
+        endif
+        /^[> ]*Message-ID:.* <!&!/ DUNNO
+        /^[> ]*Message-ID:.*@(porcupine\.org)/
+            reject forged domain name in Message-ID: header: $1
+
+Notes:
+
+  * The example uses pcre: tables mainly for speed; with minor modifications,
+    you can use regexp: tables as explained below.
+
+  * The example is simplified for educational purposes. In reality my patterns
+    list multiple domain names, as "(domain|domain|...)".
+
+  * The "\." matches "." literally. Without the "\", the "." would match any
+    character.
+
+  * The "\(" and "\)" match "(" and ")" literally. Without the "\", the "(" and
+    ")" would be grouping operators.
+
+  * The "\b" is used here to match the end of a word. If you use regexp:
+    tables, specify "[[:>:]]" (on some systems you should specify "\>" instead;
+    for details see your system documentation).
+
+  * The "if /pattern/" and "endif" eliminate unnecessary matching attempts. DO
+    NOT indent lines starting with /pattern/ between the "if" and "endif"!
+
+  * The two "Message-ID:.* <!&!" rules are workarounds for some versions of
+    Outlook express, as described in the caveats section below.
+
+CCaavveeaattss
+
+  * Netscape Messenger (and reportedly, Mozilla) sends a HELO name that is
+    identical to the sender address domain part. If you have such clients then
+    the above patterns would block legitimate email.
+
+    My network has only one such machine, and to prevent its mail from being
+    blocked I have configured it to send mail as user@hostname.porcupine.org.
+    On the Postfix server, a canonical mapping translates this temporary
+    address into user@porcupine.org.
+
+        /etc/postfix/main.cf:
+            canonical_maps = hash:/etc/postfix/canonical
+
+        /etc/postfix/canonical:
+            @hostname.porcupine.org @porcupine.org
+
+    This is of course practical only when you have very few systems that send
+    HELO commands like this, and when you never have to send mail to a user on
+    such a host.
+
+    An alternative would be to remove the hostname from
+    "hostname.porcupine.org" with address masquerading, as described in the
+    ADDRESS_REWRITING_README document.
+
+  * Reportedly, Outlook 2003 (perhaps Outlook Express, and other versions as
+    well) present substantially different Message-ID headers depending upon
+    whether or not a DSN is requested (via Options "Request a delivery receipt
+    for this message").
+
+    When a DSN is requested, Outlook 2003 uses a Message-ID string that ends in
+    the sender's domain name:
+
+        Message-ID: <!&! ...very long string... ==@example.com>
+
+    where example.com is the domain name part of the email address specified in
+    Outlook's account settings for the user. Since many users configure their
+    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 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.
+
+BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill wwiitthh ffoorrggeedd sseennddeerr iinnffoorrmmaattiioonn
+
+Like many people I still have a few email addresses in domains that I used in
+the past. Mail for those addresses is forwarded to my current address. Most of
+the backscatter mail that I get claims to be sent from these addresses. Such
+mail is obviously forged and is very easy to stop.
+
+    /etc/postfix/main.cf:
+        header_checks = pcre:/etc/postfix/header_checks
+        body_checks = pcre:/etc/postfix/body_checks
+
+    /etc/postfix/header_checks:
+        /^(From|Return-Path):.*\b(user@domain\.tld)\b/
+            reject forged sender address in $1: header: $2
+
+    /etc/postfix/body_checks:
+        /^[> ]*(From|Return-Path):.*\b(user@domain\.tld)\b/
+            reject forged sender address in $1: header: $2
+
+Notes:
+
+  * The example uses pcre: tables mainly for speed; with minor modifications,
+    you can use regexp: tables as explained below.
+
+  * The example is simplified for educational purposes. In reality, my patterns
+    list multiple email addresses as "(user1@domain1\.tld|user2@domain2\.tld)".
+
+  * The two "\b" as used in "\b(user@domain\.tld)\b" match the beginning and
+    end of a word, respectively. If you use regexp: tables, specify "[[:<:]]
+    and [[:>:]]" (on some systems you should specify "\< and \>" instead; for
+    details see your system documentation).
+
+  * The "\." matches "." literally. Without the "\", the "." would match any
+    character.
+
+BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill wwiitthh ootthheerr ffoorrggeedd iinnffoorrmmaattiioonn
+
+Another sign of forgery can be found in the IP address that is recorded in
+Received: headers next to your HELO host or domain name. This information must
+be used with care, though. Some mail servers are behind a network address
+translator and never see the true client IP address.
+
+BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill ffrroomm vviirruuss ssccaannnneerrss
+
+With all the easily recognizable forgeries eliminated, there is one category of
+backscatter mail that remains, and that is notifications from virus scanner
+software. Unfortunately, some virus scanning software doesn't know that viruses
+forge sender addresses. To make matters worse, the software also doesn't know
+how to report a mail delivery problem, so that we cannot use the above
+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 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
+        /^Content-Disposition:.*VIRUS1_DETECTED_AND_REMOVED/
+            DISCARD virus notification
+        /^Content-Disposition:.*VirusWarning.txt/ DISCARD virus notification
+
+Note: these documents haven't been updated since 2004, so they are useful only
+as a starting point.
+
+A plea to virus or spam scanner operators: please do not make the problem worse
+by sending return mail to forged sender addresses. You're only harassing
+innocent people. If you must return mail to the purported sender, please return
+the full message headers, so that the sender can filter out the obvious
+forgeries.
+
--- a/README_FILES/BASIC_CONFIGURATION_README
+++ b/README_FILES/BASIC_CONFIGURATION_README
@ -0,0 +1,489 @@
+PPoossttffiixx BBaassiicc CCoonnffiigguurraattiioonn
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix has several hundred configuration parameters that are controlled via
+the main.cf file. Fortunately, all parameters have sensible default values. In
+many cases, you need to configure only two or three parameters before you can
+start to play with the mail system. Here's a quick introduction to the syntax:
+
+  * Postfix configuration files
+
+The text below assumes that you already have Postfix installed on the system,
+either by compiling the source code yourself (as described in the INSTALL file)
+or by installing an already compiled version.
+
+This document covers basic Postfix configuration. Information about how to
+configure Postfix for specific applications such as mailhub, firewall or dial-
+up client can be found in the STANDARD_CONFIGURATION_README file. But don't go
+there until you already have covered the material presented below.
+
+The first parameters of interest specify the machine's identity and role in the
+network.
+
+  * What domain name to use in outbound mail
+
+  * What domains to receive mail for
+
+  * What clients to relay mail from
+
+  * What destinations to relay mail to
+
+  * What delivery method: direct or indirect
+
+The default values for many other configuration parameters are derived from
+just these.
+
+The next parameter of interest controls the amount of mail sent to the local
+postmaster:
+
+  * What trouble to report to the postmaster
+
+Be sure to set the following correctly if you're behind a proxy or network
+address translator, and you are running a backup MX host for some other domain:
+
+  * Proxy/NAT external network addresses
+
+Postfix daemon processes run in the background, and log problems and normal
+activity to the syslog daemon. Here are a few things that you need to be aware
+of:
+
+  * What you need to know about Postfix logging
+
+If your machine has unusual security requirements you may want to run Postfix
+daemon processes inside a chroot environment.
+
+  * Running Postfix daemon processes chrooted
+
+If you run Postfix on a virtual network interface, or if your machine runs
+other mailers on virtual interfaces, you'll have to look at the other
+parameters listed here as well:
+
+  * My own hostname
+
+  * My own domain name
+
+  * My own network addresses
+
+PPoossttffiixx ccoonnffiigguurraattiioonn ffiilleess
+
+By default, Postfix configuration files are in /etc/postfix. The two most
+important files are main.cf and master.cf; these files must be owned by root.
+Giving someone else write permission to main.cf or master.cf (or to their
+parent directories) means giving root privileges to that person.
+
+In /etc/postfix/main.cf you will have to set up a minimal number of
+configuration parameters. Postfix configuration parameters resemble shell
+variables, with two important differences: the first one is that Postfix does
+not know about quotes like the UNIX shell does.
+
+You specify a configuration parameter as:
+
+    /etc/postfix/main.cf:
+        parameter = value
+
+and you use it by putting a "$" character in front of its name:
+
+    /etc/postfix/main.cf:
+        other_parameter = $parameter
+
+You can use $parameter before it is given a value (that is the second main
+difference with UNIX shell variables). The Postfix configuration language uses
+lazy evaluation, and does not look at a parameter value until it is needed at
+runtime.
+
+Postfix uses database files for access control, address rewriting and other
+purposes. The DATABASE_README file gives an introduction to how Postfix works
+with Berkeley DB, LDAP or SQL and other types. Here is a common example of how
+Postfix invokes a database:
+
+    /etc/postfix/main.cf:
+        virtual_alias_maps = hash:/etc/postfix/virtual
+
+Whenever you make a change to the main.cf or master.cf file, execute the
+following command as root in order to refresh a running mail system:
+
+    # postfix reload
+
+WWhhaatt ddoommaaiinn nnaammee ttoo uussee iinn oouuttbboouunndd mmaaiill
+
+The myorigin parameter specifies the domain that appears in mail that is posted
+on this machine. The default is to use the local machine name, $myhostname,
+which defaults to the name of the machine. Unless you are running a really
+small site, you probably want to change that into $mydomain, which defaults to
+the parent domain of the machine name.
+
+For the sake of consistency between sender and recipient addresses, myorigin
+also specifies the domain name that is appended to an unqualified recipient
+address.
+
+Examples (specify only one of the following):
+
+    /etc/postfix/main.cf:
+        myorigin = $myhostname (default: send mail as "user@$myhostname")
+        myorigin = $mydomain   (probably desirable: "user@$mydomain")
+
+WWhhaatt ddoommaaiinnss ttoo rreecceeiivvee mmaaiill ffoorr
+
+The mydestination parameter specifies what domains this machine will deliver
+locally, instead of forwarding to another machine. The default is to receive
+mail for the machine itself. See the VIRTUAL_README file for how to configure
+Postfix for hosted domains.
+
+You can specify zero or more domain names, "/file/name" patterns and/or "type:
+table" lookup tables (such as hash:, btree:, nis:, ldap:, or mysql:), separated
+by whitespace and/or commas. A "/file/name" pattern is replaced by its
+contents; "type:table" requests that a table lookup is done and merely tests
+for existence: the lookup result is ignored.
+
+IMPORTANT: If your machine is a mail server for its entire domain, you must
+list $mydomain as well.
+
+Example 1: default setting.
+
+    /etc/postfix/main.cf:
+        mydestination = $myhostname localhost.$mydomain localhost
+
+Example 2: domain-wide mail server.
+
+    /etc/postfix/main.cf:
+        mydestination = $myhostname localhost.$mydomain localhost $mydomain
+
+Example 3: host with multiple DNS A records.
+
+    /etc/postfix/main.cf:
+        mydestination = $myhostname localhost.$mydomain localhost
+            www.$mydomain ftp.$mydomain
+
+Caution: in order to avoid mail delivery loops, you must list all hostnames of
+the machine, including $myhostname, and localhost.$mydomain.
+
+WWhhaatt cclliieennttss ttoo rreellaayy mmaaiill ffrroomm
+
+By default, Postfix will forward mail from clients in authorized network blocks
+to any destination. Authorized networks are defined with the mynetworks
+configuration parameter. The current default is to authorize the local machine
+only. Prior to Postfix 3.0, the default was to authorize all clients in the IP
+subnetworks that the local machine is attached to.
+
+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 the
+"mynetworks_style = subnet" setting may be too friendly.
+
+Examples (specify only one of the following):
+
+    /etc/postfix/main.cf:
+        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" (the default when compatibility_level >=
+    2) when Postfix should forward mail from only the local machine.
+
+  * 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.
+    Don't do this with a dialup site - it would cause Postfix to "trust" your
+    entire provider's network. Instead, specify an explicit mynetworks list by
+    hand, as described below.
+
+Alternatively, you can specify the mynetworks list by hand, in which case
+Postfix ignores the mynetworks_style setting. To specify the list of trusted
+networks by hand, specify network blocks in CIDR (network/mask) notation, for
+example:
+
+    /etc/postfix/main.cf:
+        mynetworks = 168.100.189.0/28, 127.0.0.0/8
+
+You can also specify the absolute pathname of a pattern file instead of listing
+the patterns in the main.cf file.
+
+WWhhaatt ddeessttiinnaattiioonnss ttoo rreellaayy mmaaiill ttoo
+
+By default, Postfix will forward mail from strangers (clients outside
+authorized networks) to authorized remote destinations only. Authorized remote
+destinations are defined with the relay_domains configuration parameter. The
+default is to authorize all domains (and subdomains) of the domains listed with
+the mydestination parameter.
+
+Examples (specify only one of the following):
+
+    /etc/postfix/main.cf:
+        relay_domains = $mydestination (default)
+        relay_domains =           (safe: never forward mail from strangers)
+        relay_domains = $mydomain (forward mail to my domain and subdomains)
+
+WWhhaatt ddeelliivveerryy mmeetthhoodd:: ddiirreecctt oorr iinnddiirreecctt
+
+By default, Postfix tries to deliver mail directly to the Internet. Depending
+on your local conditions this may not be possible or desirable. For example,
+your system may be turned off outside office hours, it may be behind a
+firewall, or it may be connected via a provider who does not allow direct mail
+to the Internet. In those cases you need to configure Postfix to deliver mail
+indirectly via a relay host.
+
+Examples (specify only one of the following):
+
+    /etc/postfix/main.cf:
+        relayhost =                   (default: direct delivery to Internet)
+        relayhost = $mydomain         (deliver via local mailhub)
+        relayhost = [mail.$mydomain]  (deliver via local mailhub)
+        relayhost = [mail.isp.tld]    (deliver via provider mailhub)
+
+The form enclosed with [] eliminates DNS MX lookups. Don't worry if you don't
+know what that means. Just be sure to specify the [] around the mailhub
+hostname that your ISP gave to you, otherwise mail may be mis-delivered.
+
+The STANDARD_CONFIGURATION_README file has more hints and tips for firewalled
+and/or dial-up networks.
+
+WWhhaatt ttrroouubbllee ttoo rreeppoorrtt ttoo tthhee ppoossttmmaasstteerr
+
+You should set up a postmaster alias in the aliases(5) table that directs mail
+to a human person. The postmaster address is required to exist, so that people
+can report mail delivery problems. While you're updating the aliases(5) table,
+be sure to direct mail for the super-user to a human person too.
+
+    /etc/aliases:
+        postmaster: you
+        root: you
+
+Execute the command "newaliases" after changing the aliases file. Instead of /
+etc/aliases, your alias file may be located elsewhere. Use the command
+"postconf alias_maps" to find out.
+
+The Postfix system reports problems to the postmaster alias. You may not be
+interested in all types of trouble reports, so this reporting mechanism is
+configurable. The default is to report only serious problems (resource,
+software) to postmaster:
+
+Default setting:
+
+    /etc/postfix/main.cf:
+        notify_classes = resource, software
+
+The meaning of the classes is as follows:
+
+    bounce
+        Inform the postmaster of undeliverable mail. Either send the postmaster
+        a copy of undeliverable mail that is returned to the sender, or send a
+        transcript of the SMTP session when Postfix rejected mail. For privacy
+        reasons, the postmaster copy of undeliverable mail is truncated after
+        the original message headers. This implies "2bounce" (see below). See
+        also the luser_relay feature. The notification is sent to the address
+        specified with the bounce_notice_recipient configuration parameter
+        (default: postmaster).
+    2bounce
+        When Postfix is unable to return undeliverable mail to the sender, send
+        it to the postmaster instead (without truncating the message after the
+        primary headers). The notification is sent to the address specified
+        with the 2bounce_notice_recipient configuration parameter (default:
+        postmaster).
+    delay
+        Inform the postmaster of delayed mail. In this case, the postmaster
+        receives message headers only. The notification is sent to the address
+        specified with the delay_notice_recipient configuration parameter
+        (default: postmaster).
+    policy
+        Inform the postmaster of client requests that were rejected because of
+        (UCE) policy restrictions. The postmaster receives a transcript of the
+        SMTP session. The notification is sent to the address specified with
+        the error_notice_recipient configuration parameter (default:
+        postmaster).
+    protocol
+        Inform the postmaster of protocol errors (client or server side) or
+        attempts by a client to execute unimplemented commands. The postmaster
+        receives a transcript of the SMTP session. The notification is sent to
+        the address specified with the error_notice_recipient configuration
+        parameter (default: postmaster).
+    resource
+        Inform the postmaster of mail not delivered due to resource problems
+        (for example, queue file write errors). The notification is sent to the
+        address specified with the error_notice_recipient configuration
+        parameter (default: postmaster).
+    software
+        Inform the postmaster of mail not delivered due to software problems.
+        The notification is sent to the address specified with the
+        error_notice_recipient configuration parameter (default: postmaster).
+
+PPrrooxxyy//NNAATT eexxtteerrnnaall nneettwwoorrkk aaddddrreesssseess
+
+Some mail servers are connected to the Internet via a network address
+translator (NAT) or proxy. This means that systems on the Internet connect to
+the address of the NAT or proxy, instead of connecting to the network address
+of the mail server. The NAT or proxy forwards the connection to the network
+address of the mail server, but Postfix does not know this.
+
+If you run a Postfix server behind a proxy or NAT, you need to configure the
+proxy_interfaces parameter and specify all the external proxy or NAT addresses
+that Postfix receives mail on. You may specify symbolic hostnames instead of
+network addresses.
+
+IMPORTANT: You must specify your proxy/NAT external addresses when your system
+is a backup MX host for other domains, otherwise mail delivery loops will
+happen when the primary MX host is down.
+
+Example: host behind NAT box running a backup MX host.
+
+    /etc/postfix/main.cf:
+        proxy_interfaces = 1.2.3.4 (the proxy/NAT external network address)
+
+WWhhaatt yyoouu nneeeedd ttoo kknnooww aabboouutt PPoossttffiixx llooggggiinngg
+
+Postfix daemon processes run in the background, and log problems and normal
+activity to the syslog daemon. The syslogd process sorts events by class and
+severity, and appends them to logfiles. The logging classes, levels and logfile
+names are usually specified in /etc/syslog.conf. At the very least you need
+something like:
+
+    /etc/syslog.conf:
+        mail.err                                    /dev/console
+        mail.debug                                  /var/log/maillog
+
+After changing the syslog.conf file, send a "HUP" signal to the syslogd
+process.
+
+IMPORTANT: many syslogd implementations will not create files. You must create
+files before (re)starting syslogd.
+
+IMPORTANT: on Linux you need to put a "-" character before the pathname, e.g.,
+-/var/log/maillog, otherwise the syslogd process will use more system resources
+than Postfix.
+
+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
+    # grep -E '(reject|warning|error|fatal|panic):' /some/log/file
+
+  * The first line (postfix check) causes Postfix to report file permission/
+    ownership discrepancies.
+
+  * The second line looks for problem reports from the mail software, and
+    reports how effective the relay and junk mail access blocks are. This may
+    produce a lot of output. You will want to apply some postprocessing to
+    eliminate uninteresting information.
+
+The DEBUG_README document describes the meaning of the "warning" etc. labels in
+Postfix logging.
+
+RRuunnnniinngg PPoossttffiixx ddaaeemmoonn pprroocceesssseess cchhrrooootteedd
+
+Postfix daemon processes can be configured (via the master.cf file) to run in a
+chroot jail. The processes run at a fixed low privilege and with file system
+access limited to the Postfix queue directories (/var/spool/postfix). This
+provides a significant barrier against intrusion. The barrier is not
+impenetrable (chroot limits file system access only), but every little bit
+helps.
+
+With the exception of Postfix daemons that deliver mail locally and/or that
+execute non-Postfix commands, every Postfix daemon can run chrooted.
+
+Sites with high security requirements should consider to chroot all daemons
+that talk to the network: the smtp(8) and smtpd(8) processes, and perhaps also
+the lmtp(8) client. The author's own porcupine.org mail server runs all daemons
+chrooted that can be chrooted.
+
+The default /etc/postfix/master.cf file specifies that no Postfix daemon runs
+chrooted. In order to enable chroot operation, edit the file /etc/postfix/
+master.cf, and follow instructions in the file. When you're finished, execute
+"postfix reload" to make the change effective.
+
+Note that a chrooted daemon resolves all filenames relative to the Postfix
+queue directory (/var/spool/postfix). For successful use of a chroot jail, most
+UNIX systems require you to bring in some files or device nodes. The examples/
+chroot-setup directory in the source code distribution has a collection of
+scripts that help you set up Postfix chroot environments on different operating
+systems.
+
+Additionally, you almost certainly need to configure syslogd so that it listens
+on a socket inside the Postfix queue directory. Examples of syslogd command
+line options that achieve this for specific systems:
+
+FreeBSD: syslogd -l /var/spool/postfix/var/run/log
+
+Linux, OpenBSD: syslogd -a /var/spool/postfix/dev/log
+
+MMyy oowwnn hhoossttnnaammee
+
+The myhostname parameter specifies the fully-qualified domain name of the
+machine running the Postfix system. $myhostname appears as the default value in
+many other Postfix configuration parameters.
+
+By default, myhostname is set to the local machine name. If your local machine
+name is not in fully-qualified domain name form, or if you run Postfix on a
+virtual interface, you will have to specify the fully-qualified domain name
+that the mail system should use.
+
+Alternatively, if you specify mydomain in main.cf, then Postfix will use its
+value to generate a fully-qualified default value for the myhostname parameter.
+
+Examples (specify only one of the following):
+
+    /etc/postfix/main.cf:
+        myhostname = host.local.domain (machine name is not FQDN)
+        myhostname = host.virtual.domain (virtual interface)
+        myhostname = virtual.domain (virtual interface)
+
+MMyy oowwnn ddoommaaiinn nnaammee
+
+The mydomain parameter specifies the parent domain of $myhostname. By default,
+it is derived from $myhostname by stripping off the first part (unless the
+result would be a top-level domain).
+
+Conversely, if you specify mydomain in main.cf, then Postfix will use its value
+to generate a fully-qualified default value for the myhostname parameter.
+
+Examples (specify only one of the following):
+
+    /etc/postfix/main.cf:
+        mydomain = local.domain
+        mydomain = virtual.domain (virtual interface)
+
+MMyy oowwnn nneettwwoorrkk aaddddrreesssseess
+
+The inet_interfaces parameter specifies all network interface addresses that
+the Postfix system should listen on; mail addressed to "user@[network address]"
+will be delivered locally, as if it is addressed to a domain listed in
+$mydestination.
+
+You can override the inet_interfaces setting in the Postfix master.cf file by
+prepending an IP address to a server name.
+
+The default is to listen on all active interfaces. If you run mailers on
+virtual interfaces, you will have to specify what interfaces to listen on.
+
+IMPORTANT: If you run MTAs on virtual interfaces you must specify explicit
+inet_interfaces values for the MTA that receives mail for the machine itself:
+this MTA should never listen on the virtual interfaces or you would have a
+mailer loop when a virtual MTA is down.
+
+Example: default setting.
+
+    /etc/postfix/main.cf:
+        inet_interfaces = all
+
+Example: host running one or more virtual mailers. For each Postfix instance,
+specify only one of the following.
+
+    /etc/postfix/main.cf:
+        inet_interfaces = virtual.host.tld         (virtual Postfix)
+        inet_interfaces = $myhostname localhost... (non-virtual Postfix)
+
+Note: you need to stop and start Postfix after changing this parameter.
+
--- a/README_FILES/BDAT_README
+++ b/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.
+
--- a/README_FILES/BUILTIN_FILTER_README
+++ b/README_FILES/BUILTIN_FILTER_README
@ -0,0 +1,321 @@
+ PPoossttffiixx BBuuiilltt--iinn CCoonntteenntt IInnssppeeccttiioonn
+
+-------------------------------------------------------------------------------
+
+BBuuiilltt--iinn ccoonntteenntt iinnssppeeccttiioonn iinnttrroodduuccttiioonn
+
+Postfix supports a built-in filter mechanism that examines message header and
+message body content, one line at a time, before it is stored in the Postfix
+queue. The filter is usually implemented with POSIX or PCRE regular
+expressions, as described in the header_checks(5) manual page.
+
+The original purpose of the built-in filter is to stop an outbreak of specific
+email worms or viruses, and it does this job well. The filter has also helped
+to block bounced junk email, bounced email from worms or viruses, and
+notifications from virus detection systems. Information about this secondary
+application is given in the BACKSCATTER_README document.
+
+Because the built-in filter is optimized for stopping specific worms and virus
+outbreaks, it has limitations that make it NOT suitable for general junk email
+and virus detection. For that, you should use one of the external content
+inspection methods that are described in the FILTER_README, SMTPD_PROXY_README
+and MILTER_README documents.
+
+The following diagram gives an over-all picture of how Postfix built-in content
+inspection works:
+
+                                Postmaster
+                               notifications
+
+                                        |
+                                        v
+
+    Network or  -> BBuuiilltt--iinn ->     Postfix   -> Delivery ->  Network or
+    local users     ffiilltteerr          queue        agents     local mailbox
+
+                                        ^            |
+                                        |            v
+
+                                    Undeliverable mail
+                                      Forwarded mail
+
+The picture makes clear that the filter works while Postfix is receiving new
+mail. This means that Postfix can reject mail from the network without having
+to return undeliverable mail to the originator address (which is often spoofed
+anyway). However, this ability comes at a price: if mail inspection takes too
+much time, then the remote client will time out, and the client may send the
+same message repeatedly.
+
+Topics covered by this document:
+
+  * What mail is subjected to header/body checks
+  * Limitations of Postfix header/body checks
+  * Preventing daily mail status reports from being blocked
+  * Configuring header/body checks for mail from outside users only
+  * Configuring different header/body checks for MX service and submission
+    service
+  * Configuring header/body checks for mail to some domains only
+
+WWhhaatt mmaaiill iiss ssuubbjjeecctteedd ttoo hheeaaddeerr//bbooddyy cchheecckkss
+
+Postfix header/body checks are implemented by the cleanup(8) server before it
+injects mail into the incoming queue. The diagram below zooms in on the cleanup
+(8) server, and shows that this server handles mail from many different
+sources. In order to keep the diagram readable, the sources of postmaster
+notifications are not shown, because they can be produced by many Postfix
+daemon processes.
+
+                    bounce(8)
+                 (undeliverable)
+
+    ssmmttppdd((88))               |
+    ((nneettwwoorrkk)) \            v
+
+    qqmmqqppdd((88))  -\    cleanup(8)   -> incoming
+    ((nneettwwoorrkk)) -/                     queue
+
+    ppiicckkuupp((88)) /            ^
+     ((llooccaall))               |
+
+                     local(8)
+                    (forwarded)
+
+For efficiency reasons, only mail that enters from outside of Postfix is
+inspected with header/body checks. It would be inefficient to filter already
+filtered mail again, and it would be undesirable to block postmaster
+notifications. The table below summarizes what mail is and is not subject to
+header/body checks.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |MMeessssaaggee ttyyppee      |SSoouurrccee   |HHeeaaddeerr//bbooddyy cchheecckkss??|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Undeliverable mail|bounce(8)|No                 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Network mail      |smtpd(8) |Configurable       |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Network mail      |qmqpd(8) |Configurable       |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Local submission  |pickup(8)|Configurable       |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Local forwarding  |local(8) |No                 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |Postmaster notice |many     |No                 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+How does Postfix decide what mail needs to be filtered? It would be clumsy to
+make the decision in the cleanup(8) server, as this program receives mail from
+so many different sources. Instead, header/body checks are requested by the
+source. Examples of how to turn off header/body checks for mail received with
+smtpd(8), qmqpd(8) or pickup(8) are given below under "Configuring header/body
+checks for mail from outside users only", "Configuring different header/body
+checks for MX service and submission service", and "Configuring header/body
+checks for mail to some domains only".
+
+LLiimmiittaattiioonnss ooff PPoossttffiixx hheeaaddeerr//bbooddyy cchheecckkss
+
+  * Header/body checks do not decode message headers or message body content.
+    For example, if text in the message body is BASE64 encoded (RFC 2045) then
+    your regular expressions will have to match the BASE64 encoded form.
+    Likewise, message headers with encoded non-ASCII characters (RFC 2047) need
+    to be matched in their encoded form.
+
+  * Header/body checks cannot filter on a combination of message headers or
+    body lines. Header/body checks examine content one message header at a
+    time, or one message body line at a time, and cannot carry a decision over
+    to the next message header or body line.
+
+  * Header/body checks cannot depend on the recipient of a message.
+
+      o One message can have multiple recipients, and all recipients of a
+        message receive the same treatment. Workarounds have been proposed that
+        involve selectively deferring some recipients of multi-recipient mail,
+        but that results in poor SMTP performance and does not work for non-
+        SMTP mail.
+
+      o Some sources of mail send the headers and content ahead of the
+        recipient information. It would be inefficient to buffer up an entire
+        message before deciding if it needs to be filtered, and it would be
+        clumsy to filter mail and to buffer up all the actions until it is
+        known whether those actions need to be executed.
+
+  * Despite warnings, some people try to use the built-in filter feature for
+    general junk email and/or virus blocking, using hundreds or even thousands
+    of regular expressions. This can result in catastrophic performance
+    failure. The symptoms are as follows:
+
+      o The cleanup(8) processes use up all available CPU time in order to
+        process the regular expressions, and/or they use up all available
+        memory so that the system begins to swap. This slows down all incoming
+        mail deliveries.
+
+      o As Postfix needs more and more time to receive an email message, the
+        number of simultaneous SMTP sessions increases to the point that the
+        SMTP server process limit is reached.
+
+      o While all SMTP server processes are waiting for the cleanup(8) servers
+        to finish, new SMTP clients have to wait until an SMTP server process
+        becomes available. This causes mail deliveries to time out before they
+        have even begun.
+
+    The remedy for this type of performance problem is simple: don't use
+    header/body checks for general junk email and/or virus blocking, and don't
+    filter mail before it is queued. When performance is a concern, use an
+    external content filter that runs after mail is queued, as described in the
+    FILTER_README document.
+
+PPrreevveennttiinngg ddaaiillyy mmaaiill ssttaattuuss rreeppoorrttss ffrroomm bbeeiinngg bblloocckkeedd
+
+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
+logging is also likely to be rejected by those same body_checks patterns. This
+problem does not exist with header_checks patterns, because those are not
+applied to the text that is part of the mail status report.
+
+    You configure Postfix to do body checks, Postfix does its thing, Pflogsumm
+    reports it and Postfix catches the same string in the Pflogsumm report.
+    There are several solutions to this.
+
+    Wolfgang Zeikat contributed this:
+
+        #!/usr/bin/perl
+        use MIME::Lite;
+
+        ### Create a new message:
+        $msg = MIME::Lite->new(
+            From     => 'your@send.er',
+            To       => 'your@recipie.nt',
+            # Cc     => 'some@other.com, some@more.com',
+            Subject  => 'pflogsumm',
+            Date     => `date`,
+            Type     => 'text/plain',
+            Encoding => 'base64',
+            Path     => '/tmp/pflogg',
+        );
+
+        $msg->send;
+
+    Where "/tmp/pflogg" is the output of Pflogsumm. This puts Pflogsumm's
+    output in a base64 MIME attachment.
+
+Note by Wietse: if you run this on a machine that is accessible by untrusted
+users, it is safer to store the Pflogsumm report in a directory that is not
+world writable.
+
+    In a follow-up to a thread in the postfix-users mailing list, Ralf
+    Hildebrandt noted:
+
+        "mpack does the same thing."
+
+And it does. Which tool one should use is a matter of preference.
+
+Other solutions involve additional body_checks rules that make exceptions for
+daily mail status reports, but this is not recommended. Such rules slow down
+all mail and complicate Postfix maintenance.
+
+CCoonnffiigguurriinngg hheeaaddeerr//bbooddyy cchheecckkss ffoorr mmaaiill ffrroomm oouuttssiiddee uusseerrss oonnllyy
+
+The following information applies to Postfix 2.1 and later. Earlier Postfix
+versions do not support the receive_override_options feature.
+
+The easiest approach is to configure ONE Postfix instance with multiple SMTP
+server IP addresses in master.cf:
+
+  * Two SMTP server IP addresses for mail from inside users only, with header/
+    body filtering turned off, and a local mail pickup service with header/body
+    filtering turned off.
+
+    /etc/postfix.master.cf:
+        # ==================================================================
+        # service      type  private unpriv  chroot  wakeup  maxproc command
+        #                    (yes)   (yes)   (yes)   (never) (100)
+        # ==================================================================
+        1.2.3.4:smtp   inet  n       -       n       -       -       smtpd
+            -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         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
+    world.
+
+  * One SMTP server address for mail from outside users with header/body
+    filtering turned on via main.cf.
+
+    /etc/postfix.master.cf:
+        # =================================================================
+        # service     type  private unpriv  chroot  wakeup  maxproc command
+        #                   (yes)   (yes)   (yes)   (never) (100)
+        # =================================================================
+        1.2.3.5:smtp  inet  n       -       n       -       -       smtpd
+
+CCoonnffiigguurriinngg ddiiffffeerreenntt hheeaaddeerr//bbooddyy cchheecckkss ffoorr MMXX sseerrvviiccee aanndd ssuubbmmiissssiioonn sseerrvviiccee
+
+If authorized user submissions require different header/body checks than mail
+from remote MTAs, then this is possible as long as you have separate mail
+streams for authorized users and for MX service.
+
+The example below assumes that authorized users connect to TCP port 587
+(submission) or 465 (smtps), and that remote MTAs connect to TCP port 25
+(smtp).
+
+First, we define a few "user-defined" parameters that will override settings
+for the submission and smtps services.
+
+    /etc/postfix/main.cf:
+        msa_cleanup_service_name = msa_cleanup
+        msa_header_checks = pcre:/etc/postfix/msa_header_checks
+        msa_body_checks = pcre:/etc/postfix/msa_body_checks
+
+Next, we define msa_cleanup as a dedicated cleanup service that will be used
+only by the submission and smtps services. This service uses the header_checks
+and body_checks overrides that were defined above.
+
+    /etc/postfix.master.cf:
+        # =================================================================
+        # service     type  private unpriv  chroot  wakeup  maxproc command
+        #                   (yes)   (yes)   (yes)   (never) (100)
+        # =================================================================
+        smtp          inet  n       -       n       -       -       smtpd
+        msa_cleanup   unix  n       -       n       -       0       cleanup
+            -o header_checks=$msa_header_checks
+            -o body_checks=$msa_body_checks
+        submission    inet  n       -       n       -       -       smtpd
+            -o cleanup_service_name=$msa_cleanup_service_name
+            -o syslog_name=postfix/submission
+            ...[see sample master.cf file for more]...
+        smtps         inet  n       -       n       -       -       smtpd
+            -o cleanup_service_name=$msa_cleanup_service_name
+            -o syslog_name=postfix/smtps
+            -o smtpd_tls_wrappermode=yes
+            ...[see sample master.cf file for more]...
+
+By keeping the "msa_xxx" parameter settings in main.cf, you keep your master.cf
+file simple, and you minimize the amount of duplication.
+
+CCoonnffiigguurriinngg hheeaaddeerr//bbooddyy cchheecckkss ffoorr mmaaiill ttoo ssoommee ddoommaaiinnss oonnllyy
+
+The following information applies to Postfix 2.1. Earlier Postfix versions do
+not support the receive_override_options feature.
+
+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:
+        # =================================================================
+        # service     type  private unpriv  chroot  wakeup  maxproc command
+        #                   (yes)   (yes)   (yes)   (never) (100)
+        # =================================================================
+        # SMTP service for domains with header/body checks turned on.
+        1.2.3.4:smtp  inet  n       -       n       -       -       smtpd
+
+        # SMTP service for domains with header/body checks turned off.
+        1.2.3.5:smtp  inet  n       -       n       -       -       smtpd
+            -o receive_override_options=no_header_body_checks
+
+Once this is set up you can configure MX records in the DNS that route each
+domain to the proper SMTP server instance.
+
--- a/README_FILES/CDB_README
+++ b/README_FILES/CDB_README
@ -0,0 +1,83 @@
+PPoossttffiixx CCDDBB HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+CDB (Constant DataBase) is an indexed file format designed by Daniel Bernstein.
+CDB is optimized exclusively for read access and guarantees that each record
+will be read in at most two disk accesses. This is achieved by forgoing support
+for incremental updates: no single-record inserts or deletes are supported. CDB
+databases can be modified only by rebuilding them completely from scratch,
+hence the "constant" qualifier in the name.
+
+Postfix CDB databases are specified as "cdb:name", where name specifies the CDB
+file name without the ".cdb" suffix (another suffix, ".tmp", is used
+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.
+
+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
+
+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.
+
+Postfix is compatible with two CDB implementations:
+
+  * 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 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.
+
+To build Postfix after you have installed tinycdb, use something like:
+
+    % make tidy
+    % CDB=../../../tinycdb-0.5
+    % make -f Makefile.init makefiles "CCARGS=-DHAS_CDB -I$CDB" \
+        "AUXLIBS_CDB=$CDB/libcdb.a"
+    % make
+
+Alternatively, for the D.J.B. version of CDB:
+
+    % make tidy
+    % CDB=../../../cdb-0.75
+    % make -f Makefile.init makefiles "CCARGS=-DHAS_CDB -I$CDB" \
+        "AUXLIBS_CDB=$CDB/cdb.a $CDB/alloc.a $CDB/buffer.a $CDB/unix.a $CDB/
+    byte.a"
+    % make
+
+Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_CDB. With Postfix
+3.0 and later, the old AUXLIBS variable still supports building a statically-
+loaded CDB database client, but only the new AUXLIBS_CDB variable supports
+building a dynamically-loaded or statically-loaded CDB database client.
+
+    Failure to use the AUXLIBS_CDB variable will defeat the purpose of dynamic
+    database client loading. Every Postfix executable file will have CDB
+    database library dependencies. And that was exactly what dynamic database
+    client loading was meant to avoid.
+
--- a/README_FILES/COMPATIBILITY_README
+++ b/README_FILES/COMPATIBILITY_README
@ -0,0 +1,399 @@
+PPoossttffiixx BBaacckkwwaarrddss--CCoommppaattiibbiilliittyy SSaaffeettyy NNeett
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+Postfix 3.0 introduces a safety net that runs Postfix programs with backwards-
+compatible default settings after an upgrade. The safety net will log a warning
+whenever a "new" default setting could have an negative effect on your mail
+flow.
+
+This document provides information on the following topics:
+
+  * Detailed descriptions of Postfix backwards-compatibility warnings.
+
+  * What backwards-compatible settings you may have to make permanent in
+    main.cf or master.cf.
+
+  * How to turn off Postfix backwards-compatibility warnings.
+
+OOvveerrvviieeww
+
+With backwards compatibility turned on, Postfix logs a message whenever a
+backwards-compatible default setting may be required for continuity of service.
+Based on this logging the system administrator can decide if any backwards-
+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.
+
+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 smtputf8_enable=no
+
+Logged with compatibility_level < 2:
+
+  * Using backwards-compatible default setting mynetworks_style=subnet
+
+  * Using backwards-compatible default setting relay_domains=$mydestination
+
+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
+
+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
+or master.cf, as detailed in the sections that follow.
+
+When no more backwards-compatible settings need to be made permanent, the
+system administrator should turn off the backwards-compatibility safety net as
+described at the end of this document.
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg aappppeenndd__ddoott__mmyyddoommaaiinn==yyeess
+
+The append_dot_mydomain default value has changed from "yes" to "no". This
+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:
+
+  * Messages about missing "localhost" in mydestination or other address class:
+
+        postfix/trivial-rewrite[14777]: using backwards-compatible
+            default setting append_dot_mydomain=yes to rewrite
+            "localhost" to "localhost.example.com"; please add
+            "localhost" to mydestination or other address class
+
+    If Postfix logs the above message, add "localhost" to mydestination (or
+    virtual_alias_domains, virtual_mailbox_domains, or relay_domains) and
+    execute the command "ppoossttffiixx rreellooaadd".
+
+  * Messages about incomplete domains in email addresses:
+
+        postfix/trivial-rewrite[25835]: using backwards-compatible
+            default setting append_dot_mydomain=yes to rewrite "foo" to
+            "foo.example.com"
+
+    If Postfix logs the above message for domains different from "localhost",
+    and the sender cannot be changed to use complete domain names in email
+    addresses, then the system administrator should make the backwards-
+    compatible setting "append_dot_mydomain = yes" permanent in main.cf:
+
+        # ppoossttccoonnff aappppeenndd__ddoott__mmyyddoommaaiinn==yyeess
+        # ppoossttffiixx rreellooaadd
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg cchhrroooott==yy
+
+The master.cf chroot default value has changed from "y" (yes) to "n" (no). The
+new default avoids the need for copies of system files under the Postfix queue
+directory. However, sites with strict security requirements may want to keep
+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:
+
+    postfix/master[27664]: /etc/postfix/master.cf: line 72: using
+        backwards-compatible default setting chroot=y
+
+If this service should remain chrooted, then the system administrator should
+make the backwards-compatible setting "chroot = y" permanent in master.cf. For
+example, to update the chroot setting for the "smtp inet" service:
+
+    # ppoossttccoonnff --FF ssmmttpp//iinneett//cchhrroooott==yy
+    # ppoossttffiixx rreellooaadd
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg ssmmttppdd__rreellaayy__rreessttrriiccttiioonnss == ((eemmppttyy))
+
+The smtpd_relay_restrictions feature was introduced with Postfix version 2.10,
+as a safety mechanism for configuration errors in smtpd_recipient_restrictions
+that could make Postfix an open relay.
+
+The smtpd_relay_restrictions implicit default setting forbids mail to remote
+destinations from clients that don't match permit_mynetworks or
+permit_sasl_authenticated. This could result in unexpected 'Relay access
+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:
+
+    postfix/smtpd[38463]: using backwards-compatible default setting
+        "smtpd_relay_restrictions = (empty)" to avoid "Relay access
+        denied" error for recipient "user@example.com" from client
+        "host.example.net[10.0.0.2]"
+
+If this request should not be blocked, then the system administrator should
+make the backwards-compatible setting "smtpd_relay_restrictions=" (i.e. empty)
+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 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 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:
+
+    postfix/smtpd[17375]: using backwards-compatible default setting
+        mynetworks_style=subnet to permit request from client
+        "foo.example.com[10.1.1.1]"
+
+    postfix/postscreen[24982]: using backwards-compatible default
+        setting mynetworks_style=subnet to permit request from client
+        "10.1.1.1"
+
+If the client request should not be rejected, then the system administrator
+should make the backwards-compatible setting "mynetworks_style = subnet"
+permanent in main.cf:
+
+    # ppoossttccoonnff mmyynneettwwoorrkkss__ssttyyllee==ssuubbnneett
+    # ppoossttffiixx rreellooaadd
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg rreellaayy__ddoommaaiinnss==$$mmyyddeessttiinnaattiioonn
+
+The relay_domains default value has changed from "$mydestination" to the empty
+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.
+
+  * Messages about accepting mail for a remote domain:
+
+        postfix/smtpd[19052]: using backwards-compatible default setting
+            relay_domains=$mydestination to accept mail for domain
+            "foo.example.com"
+
+        postfix/smtpd[19052]: using backwards-compatible default setting
+            relay_domains=$mydestination to accept mail for address
+            "user@foo.example.com"
+
+  * Messages about providing ETRN service for a remote domain:
+
+        postfix/smtpd[19138]: using backwards-compatible default setting
+            relay_domains=$mydestination to flush mail for domain
+            "bar.example.com"
+
+        postfix/smtp[13945]: using backwards-compatible default setting
+            relay_domains=$mydestination to update fast-flush logfile for
+            domain "bar.example.com"
+
+If Postfix should continue to accept mail for that domain or continue to
+provide ETRN service for that domain, then the system administrator should make
+the backwards-compatible setting "relay_domains = $mydestination" permanent in
+main.cf:
+
+    # ppoossttccoonnff ''rreellaayy__ddoommaaiinnss==$$mmyyddeessttiinnaattiioonn''
+    # ppoossttffiixx rreellooaadd
+
+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 ssmmttppdd__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt==mmdd55
+
+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.
+
+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 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
+        smtpd_tls_fingerprint_digest=md5 to compute certificate fingerprints
+
+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 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 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 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 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 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
+
+TTuurrnniinngg ooffff tthhee bbaacckkwwaarrddss--ccoommppaattiibbiilliittyy ssaaffeettyy nneett
+
+Backwards compatibility is turned off by updating the compatibility_level
+setting in main.cf.
+
+    # ppoossttccoonnff ccoommppaattiibbiilliittyy__lleevveell==NN
+    # ppoossttffiixx rreellooaadd
+
+For N specify the number that is logged in your postfix(1) warning message:
+
+    warning: To disable backwards compatibility use "postconf
+    compatibility_level=N" and "postfix reload"
+
+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.
+
--- a/README_FILES/CONNECTION_CACHE_README
+++ b/README_FILES/CONNECTION_CACHE_README
@ -0,0 +1,234 @@
+PPoossttffiixx CCoonnnneeccttiioonn CCaacchhee
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+This document describes the Postfix connection cache implementation, which is
+available with Postfix version 2.2 and later.
+
+Topics covered in this document:
+
+  * What SMTP connection caching can do for you
+  * Connection cache implementation
+  * Connection cache configuration
+  * Connection cache safety mechanisms
+  * Connection cache limitations
+  * Connection cache statistics
+
+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 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:
+
+  * SMTP Connection caching can greatly improve performance when delivering
+    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
+    reply to the QUIT command, and it never waits for the TCP final handshake
+    to complete.
+
+  * SMTP Connection caching introduces some overhead: the client needs to send
+    an RSET command to find out if a connection is still usable, before it can
+    send the next MAIL FROM command. This introduces one additional round-trip
+    delay.
+
+For other potential issues with SMTP connection caching, see the discussion of
+limitations at the end of this document.
+
+CCoonnnneeccttiioonn ccaacchhee iimmpplleemmeennttaattiioonn
+
+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. 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.
+
+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.
+
+After handing over the open connection to the scache(8) server, the smtp(8)
+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 a mail server for domains with different names.
+
+CCoonnnneeccttiioonn ccaacchhee ccoonnffiigguurraattiioonn
+
+The Postfix smtp(8) client supports two connection caching strategies:
+
+  * On-demand connection caching. This is enabled by default, and is controlled
+    with the smtp_connection_cache_on_demand configuration parameter. When this
+    feature is enabled, the Postfix smtp(8) client automatically saves a
+    connection to the connection cache when a destination has a high volume of
+    mail in the active queue.
+
+    Example:
+
+        /etc/postfix/main.cf:
+            smtp_connection_cache_on_demand = yes
+
+  * Per-destination connection caching. This is enabled by explicitly listing
+    specific destinations with the smtp_connection_cache_destinations
+    configuration parameter. After completing delivery to a selected
+    destination, the Postfix smtp(8) client always saves the connection to the
+    connection cache.
+
+    Specify a comma or white space separated list of destinations or pseudo-
+    destinations:
+
+      o if mail is sent without a relay host: a domain name (the right-hand
+        side of an email address, without the [] around a numeric IP address),
+
+      o if mail is sent via a relay host: a relay host name (without the [] or
+        non-default TCP port), as specified in main.cf or in the transport map,
+
+      o a /file/name with domain names and/or relay host names as defined
+        above,
+
+      o a "type:table" with domain names and/or relay host names on the left-
+        hand side. The right-hand side result from "type:table" lookups is
+        ignored.
+
+    Examples:
+
+        /etc/postfix/main.cf:
+            smtp_connection_cache_destinations = $relayhost
+            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
+SMTP connection open for a significant amount of time, and it is unwise to send
+huge numbers of messages through the same connection. In order to avoid
+problems with SMTP connection caching, Postfix implements the following safety
+mechanisms:
+
+  * The Postfix scache(8) server keeps a connection open for only a limited
+    time. The time limit is specified with the smtp_connection_cache_time_limit
+    and with the connection_cache_ttl_limit configuration parameters. This
+    prevents anti-social behavior.
+
+  * The Postfix smtp(8) client reuses a session for only a limited number of
+    times. This avoids triggering bugs in implementations that do not correctly
+    handle multiple deliveries per session.
+
+    As of Postfix 2.3 connection reuse is preferably limited with the
+    smtp_connection_reuse_time_limit parameter. In addition, Postfix 2.11
+    provides smtp_connection_reuse_count_limit to limit how many times a
+    connection may be reused, but this feature is unsafe as it introduces a
+    "fatal attractor" failure mode (when a destination has multiple inbound
+    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:
+
+        Nov  3 16:04:31 myname postfix/smtp[30840]: 19B6B2900FE:
+        to=<wietse@test.example.com>, orig_to=<wietse@test>,
+        relay=mail.example.com[1.2.3.4], ccoonnnn__uussee==22, delay=0.22,
+        delays=0.04/0.01/0.05/0.1, dsn=2.0.0, status=sent (250 2.0.0 Ok)
+
+  * The connection cache explicitly labels each cached connection with
+    destination domain and IP address information. A connection cache lookup
+    succeeds only when the correct information is specified. This prevents mis-
+    delivery of mail.
+
+CCoonnnneeccttiioonn ccaacchhee lliimmiittaattiioonnss
+
+Postfix SMTP connection caching conflicts with certain applications:
+
+  * 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
+    that a SASL credential is valid for all hostnames or domain names that
+    deliver via the same mail server IP address and TCP port, and assumes that
+    the SASL credential does not depend on the message originator.
+
+CCoonnnneeccttiioonn ccaacchhee ssttaattiissttiiccss
+
+The scache(8) connection cache server logs statistics about the peak cache size
+and the cache hit rates. This information is logged every
+connection_cache_status_update_time seconds, when the process terminates after
+the maximal idle time is exceeded, or when Postfix is reloaded.
+
+  * Hit rates for connection cache lookups by domain will tell you how useful
+    connection caching is.
+
+  * Connection cache lookups by network address will always fail, unless you're
+    sending mail to different domains that share the same MX hosts.
+
+  * No statistics are logged when no attempts are made to access the connection
+    cache.
+
--- a/README_FILES/CONTENT_INSPECTION_README
+++ b/README_FILES/CONTENT_INSPECTION_README
@ -0,0 +1,56 @@
+PPoossttffiixx CCoonntteenntt IInnssppeeccttiioonn
+
+-------------------------------------------------------------------------------
+Postfix supports three content inspection methods, ranging from light-weight
+one-line-at-a-time scanning before mail is queued, to heavy duty machinery that
+does sophisticated content analysis after mail is queued. Each approach serves
+a different purpose.
+
+bbeeffoorree qquueeuuee,, bbuuiilltt--iinn,, lliigghhtt--wweeiigghhtt
+    This method inspects mail BEFORE it is stored in the queue, and uses
+    Postfix's built-in message header and message body inspection. Although the
+    main purpose is to stop a specific flood of mail from worms or viruses, it
+    is also useful to block a flood of bounced junk email and email
+    notifications from virus detection systems. The built-in regular
+    expressions are not meant to implement general SPAM and virus detection.
+    For that, you should use one of the content inspection methods described
+    below. Details are described in the BUILTIN_FILTER_README and
+    BACKSCATTER_README documents.
+
+aafftteerr qquueeuuee,, eexxtteerrnnaall,, hheeaavvyy--wweeiigghhtt
+    This method inspects mail AFTER it is stored in the queue, and uses
+    standard protocols such as SMTP or "pipe to command and wait for exit
+    status". After-queue inspection allows you to use content filters of
+    arbitrary complexity without causing timeouts while receiving mail, and
+    without running out of memory resources under a peak load. Details of this
+    approach are in the FILTER_README document.
+
+bbeeffoorree qquueeuuee,, eexxtteerrnnaall,, mmeeddiiuumm--wweeiigghhtt
+    The following two methods inspect mail BEFORE it is stored in the queue.
+
+      * The first method uses the SMTP protocol, and is described in the
+        SMTPD_PROXY_README document. This approach is available with Postfix
+        version 2.1 and later.
+
+      * The second method uses the Sendmail 8 Milter protocol, and is described
+        in the MILTER_README document. This approach is available with Postfix
+        version 2.3 and later.
+
+    Although these approaches appear to be attractive, they have some serious
+    limitations that you need to be aware of. First, content inspection
+    software must finish in a limited amount of time; if content inspection
+    needs too much time then incoming mail deliveries will time out. Second,
+    content inspection software must run in a limited amount of memory; if
+    content inspection needs too much memory then software will crash under a
+    peak load. Before-queue inspection limits the peak load that your system
+    can handle, and limits the sophistication of the content filter that you
+    can use.
+
+The more sophisticated content filtering software is not built into Postfix for
+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 https://
+www.postfix.org/, and on the postfix-users@postfix.org mailing list.
+
--- a/README_FILES/DATABASE_README
+++ b/README_FILES/DATABASE_README
@ -0,0 +1,328 @@
+PPoossttffiixx LLooookkuupp TTaabbllee OOvveerrvviieeww
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document covers the following topics:
+
+  * The Postfix lookup table model
+  * Postfix lists versus tables
+  * Preparing Postfix for LDAP or SQL lookups
+  * Maintaining Postfix lookup table files
+  * Updating Berkeley DB files safely
+  * Postfix lookup table types
+
+TThhee PPoossttffiixx llooookkuupp ttaabbllee mmooddeell
+
+Postfix uses lookup tables to store and look up information for access control,
+address rewriting and even for content filtering. All Postfix lookup tables are
+specified as "type:table", where "type" is one of the database types described
+under "Postfix lookup table types" at the end of this document, and where
+"table" is the lookup table name. The Postfix documentation uses the terms
+"database" and "lookup table" for the same thing.
+
+Examples of lookup tables that appear often in the Postfix documentation:
+
+    /etc/postfix/main.cf:
+        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    (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.
+The (key, value) query interface completely hides the complexities of LDAP or
+SQL from Postfix. This is a good example of connecting complex systems with
+simple interfaces.
+
+Benefits of the Postfix (key, value) query interface:
+
+  * You can implement Postfix lookup tables first with local Berkeley DB files
+    and then switch to LDAP or MySQL without any impact on the Postfix
+    configuration itself, as described under "Preparing Postfix for LDAP or SQL
+    lookups" below.
+  * You can use Berkeley DB files with fixed lookup strings for simple address
+    rewriting operations and you can use regular expression tables for the more
+    complicated work. In other words, you don't have to put everything into the
+    same table.
+
+PPoossttffiixx lliissttss vveerrssuuss ttaabblleess
+
+Most Postfix lookup tables are used to look up information. Examples are
+address rewriting (the lookup string is the old address, and the result is the
+new address) or access control (the lookup string is the client, sender or
+recipient, and the result is an action such as "reject").
+
+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 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
+underlying infrastructure as Postfix lookup tables.
+
+PPrreeppaarriinngg PPoossttffiixx ffoorr LLDDAAPP oorr SSQQLL llooookkuuppss
+
+LDAP and SQL are complex systems. Trying to set up both Postfix and LDAP or SQL
+at the same time is definitely not a good idea. You can save yourself a lot of
+time by implementing Postfix first with local files such as Berkeley DB. Local
+files have few surprises, and are easy to debug with the postmap(1) command:
+
+    % ppoossttmmaapp --qq iinnffoo@@eexxaammppllee..ccoomm hhaasshh:://eettcc//ppoossttffiixx//vviirrttuuaall
+
+Once you have local files working properly you can follow the instructions in
+ldap_table(5), mysql_table(5), pgsql_table(5) or sqlite_table(5) and replace
+local file lookups with LDAP or SQL lookups. When you do this, you should use
+the postmap(1) command again, to verify that database lookups still produce the
+exact same results as local file lookup:
+
+    % ppoossttmmaapp --qq iinnffoo@@eexxaammppllee..ccoomm llddaapp:://eettcc//ppoossttffiixx//vviirrttuuaall..ccff
+
+Be sure to exercise all the partial address or parent domain queries that are
+documented under "table search order" in the relevant manual page: access(5),
+canonical(5), virtual(5), transport(5), or under the relevant configuration
+parameter: mynetworks, relay_domains, parent_domain_matches_subdomains.
+
+MMaaiinnttaaiinniinngg PPoossttffiixx llooookkuupp ttaabbllee ffiilleess
+
+When you make changes to a database while the mail system is running, it would
+be desirable if Postfix avoids reading information while that information is
+being changed. It would also be nice if you can change a database without
+having to execute "postfix reload", in order to force Postfix to use the new
+information. Each time you do "postfix reload" Postfix loses a lot of
+performance.
+
+  * If you change a network database such as LDAP, NIS or SQL, there is no need
+    to execute "postfix reload". The LDAP, NIS or SQL server takes care of
+    read/write access conflicts and gives the new data to Postfix once that
+    data is available.
+
+  * If you change a regexp:, pcre:, cidr: or texthash: file then Postfix may
+    not pick up the file changes immediately. This is because a Postfix process
+    reads the entire file into memory once and never examines the file again.
+
+      o If the file is used by a short-running process such as smtpd(8),
+        cleanup(8) or local(8), there is no need to execute "postfix reload"
+        after making a change.
+
+      o If the file is being used by a long-running process such as trivial-
+        rewrite(8) on a busy server it may be necessary to execute "postfix
+        reload".
+
+  * If you change a local file based database such as DBM or Berkeley DB, there
+    is no need to execute "postfix reload". Postfix uses file locking to avoid
+    read/write access conflicts, and whenever a Postfix daemon process notices
+    that a file has changed it will terminate before handling the next client
+    request, so that a new process can initialize with the new database.
+
+UUppddaattiinngg BBeerrkkeelleeyy DDBB ffiilleess ssaaffeellyy
+
+Postfix uses file locking to avoid access conflicts while updating Berkeley DB
+or other local database files. This used to be safe, but as Berkeley DB has
+evolved to use more aggressive caching, file locking may no longer be
+sufficient.
+
+Furthermore, file locking would not prevent problems when the update fails
+because the disk is full or something else causes a database update to fail. In
+particular, commands such as postmap(1) or postalias(1) overwrite existing
+files. If the overwrite fails in the middle then you have no usable database,
+and Postfix will stop working. This is not an issue with the CDB database type
+available with Postfix 2.2 and later: CDB creates a new file, and renames the
+file upon successful completion.
+
+With Berkeley DB and other "one file" databases, it is possible to add some
+extra robustness by using "mv" to REPLACE an existing database file instead of
+overwriting it:
+
+    # ppoossttmmaapp aacccceessss..iinn &&&& mmvv aacccceessss..iinn..ddbb aacccceessss..ddbb
+
+This converts the input file "access.in" into the output file "access.in.db",
+and replaces the file "access.db" only when the postmap(1) command was
+successful. Of course typing such commands becomes boring quickly, and this is
+why people use "make" instead, as shown below. User input is shown in bold
+font.
+
+    # ccaatt MMaakkeeffiillee
+    all: aliases.db access.db virtual.db ...etcetera...
+
+    # Note 1: commands are specified after a TAB character.
+    # Note 2: use postalias(1) for local aliases, postmap(1) for the rest.
+    aliases.db: aliases.in
+            postalias aliases.in
+            mv aliases.in.db aliases.db
+
+    access.db: access.in
+            postmap access.in
+            mv access.in.db access.db
+
+    virtual.db: virtual.in
+            postmap virtual.in
+            mv virtual.in.db virtual.db
+
+    ...etcetera...
+    # vvii aacccceessss..iinn
+    ...editing session not shown...
+    # mmaakkee
+    postmap access.in
+    mv access.in.db access.db
+    #
+
+The "make" command updates only the files that have changed. In case of error,
+the "make" command will stop and will not invoke the "mv" command, so that
+Postfix will keep using the existing database file as if nothing happened.
+
+PPoossttffiixx llooookkuupp ttaabbllee ttyyppeess
+
+To find out what database types your Postfix system supports, use the "ppoossttccoonnff
+--mm" command. Here is a list of database types that are often supported:
+
+    bbttrreeee
+        A sorted, balanced tree structure. This is available only on systems
+        with support for Berkeley DB databases. Database files are created with
+        the postmap(1) or postalias(1) command. The lookup table name as used
+        in "btree:table" is the database file name without the ".db" suffix.
+    ccddbb
+        A read-optimized structure with no support for incremental updates.
+        Database files are created with the postmap(1) or postalias(1) command.
+        The lookup table name as used in "cdb:table" is the database file name
+        without the ".cdb" suffix. This feature is available with Postfix 2.2
+        and later.
+    cciiddrr
+        A table that associates values with Classless Inter-Domain Routing
+        (CIDR) patterns. The table format is described in cidr_table(5).
+    ddbbmm
+        An indexed file type based on hashing. This is available only on
+        systems with support for DBM databases. Public database files are
+        created with the postmap(1) or postalias(1) command, and private
+        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.
+    eennvviirroonn
+        The UNIX process environment array. The lookup key is the variable
+        name. The lookup table name in "environ:table" is ignored.
+    ffaaiill
+        A table that reliably fails all requests. The lookup table name is used
+        for logging only. This table exists to simplify Postfix error tests.
+    hhaasshh
+        An indexed file type based on hashing. This is available only on
+        systems with support for Berkeley DB databases. Public database files
+        are created with the postmap(1) or postalias(1) command, and private
+        databases are maintained by Postfix daemons. The database name as used
+        in "hash:table" is the database file name without the ".db" suffix.
+    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; 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 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
+        (1) or postalias(1) command, and private databases are maintained by
+        Postfix daemons. The database name as used in "lmdb:table" is the
+        database file name without the ".lmdb" suffix. See lmdb_table(5) for
+        details.
+    llddaapp (read-only)
+        LDAP database client. Configuration details are given in the ldap_table
+        (5).
+    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).
+    nneettiinnffoo (read-only)
+        Netinfo database client.
+    nniiss (read-only)
+        NIS database client.
+    nniisspplluuss (read-only)
+        NIS+ database client. Configuration details are given in nisplus_table
+        (5).
+    ppccrree (read-only)
+        A lookup table based on Perl Compatible Regular Expressions. The file
+        format is described in pcre_table(5). The lookup table name as used in
+        "pcre:table" is the name of the regular expression file.
+    ppiippeemmaapp (read-only)
+        A pipeline of lookup tables. Example: "pipemap:{type1:name1, ...,
+        typen:namen}". Each "pipemap:" query is given to the first table. Each
+        lookup result becomes the query for the next table in the pipeline, and
+        the last table produces the final result. When any table lookup
+        produces no result, the pipeline produces no result. The first and last
+        characters of the "pipemap:" table name must be "{" and "}". Within
+        these, individual maps are separated with comma or whitespace.
+    ppggssqqll (read-only)
+        PostgreSQL database client. Configuration details are given in
+        pgsql_table(5).
+    pprrooxxyy
+        Postfix proxymap(8) client for shared access to Postfix databases. The
+        lookup table name syntax is "proxy:type:table".
+    rraannddmmaapp (read-only)
+        An in-memory table that performs random selection. Example: "randmap:
+        {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. 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:
+        table" is the name of the regular expression file.
+    ssddbbmm
+        An indexed file type based on hashing. This is available only on
+        systems with support for SDBM databases. Public database files are
+        created with the postmap(1) or postalias(1) command, and private
+        databases are maintained by Postfix daemons. The lookup table name as
+        used in "sdbm:table" is the database file name without the ".dir" or
+        ".pag" suffix.
+    ssoocckkeettmmaapp (read-only)
+        Sendmail-style socketmap client. The name of the table is either iinneett:
+        host:port:name for a TCP/IP server, or uunniixx:pathname:name for a UNIX-
+        domain server. See socketmap_table(5) for details.
+    ssqqlliittee (read-only)
+        SQLite database. Configuration details are given in sqlite_table(5).
+    ssttaattiicc (read-only)
+        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 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
+        hostname or a numeric IP address, and "port" specifies a symbolic
+        service name or a numeric port number.
+    tteexxtthhaasshh (read-only)
+        A table that produces similar results as hash: files, except that you
+        don't have to run the postmap(1) command before you can use the file,
+        and that texthash: does not detect changes after the file is read. The
+        lookup table name is "texthash:filename", where the file name is taken
+        literally; no suffix is appended.
+    uunniioonnmmaapp (read-only)
+        A table that sends each query to multiple lookup tables and that
+        concatenates all found results, separated by comma. The table name
+        syntax is the same as for pipemap tables.
+    uunniixx (read-only)
+        A limited view of the UNIX authentication database. The following
+        tables are implemented:
+        uunniixx::ppaasssswwdd..bbyynnaammee
+            The table is the UNIX password database. The key is a login name.
+            The result is a password file entry in passwd(5) format.
+        uunniixx::ggrroouupp..bbyynnaammee
+            The table is the UNIX group database. The key is a group name. The
+            result is a group file entry in group(5) format.
+
+Other lookup table types may be available depending on how Postfix was built.
+With some Postfix distributions the list is dynamically extensible as support
+for lookup tables is dynamically linked into Postfix.
+
--- a/README_FILES/DB_README
+++ b/README_FILES/DB_README
@ -0,0 +1,175 @@
+PPoossttffiixx BBeerrkkeelleeyy DDBB HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix uses databases of various kinds to store and look up information.
+Postfix databases are specified as "type:name". Berkeley DB implements the
+Postfix database type "hash" and "btree". The name of a Postfix Berkeley DB
+database is the name of the database file without the ".db" suffix. Berkeley DB
+databases are maintained with the postmap(1) command.
+
+Note: Berkeley DB version 4 is not supported by Postfix versions before 2.0.
+
+This document describes:
+
+ 1. How to build Postfix without Berkeley DB support even if the system comes
+    with Berkeley DB.
+
+ 2. How to build Postfix on systems that normally have no Berkeley DB library.
+
+ 3. How to build Postfix on BSD or Linux systems with multiple Berkeley DB
+    versions.
+
+ 4. How to tweak performance.
+
+ 5. Missing pthread library trouble.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthhoouutt BBeerrkkeelleeyy DDBB ssuuppppoorrtt eevveenn iiff tthhee ssyysstteemm ccoommeess wwiitthh
+BBeerrkkeelleeyy DDBB
+
+Note: The following instructions apply to Postfix 2.9 and later.
+
+Postfix will normally enable Berkeley DB support if the system is known to have
+it. To build Postfix without Berkeley DB support, build the makefiles as
+follows:
+
+    % make makefiles CCARGS="-DNO_DB"
+    % make
+
+This will disable support for "hash" and "btree" files.
+
+BBuuiillddiinngg PPoossttffiixx oonn ssyysstteemmss tthhaatt nnoorrmmaallllyy hhaavvee nnoo BBeerrkkeelleeyy DDBB lliibbrraarryy
+
+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 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
+implementation, then every Postfix program will dump core because either the
+system library, the SASL library, or Postfix itself ends up using the wrong
+version.
+
+The more recent Berkeley DB versions have a compile-time switch, "--with-
+uniquename", which renames the symbols so that multiple versions of Berkeley DB
+can co-exist in the same application. Although wasteful, this may be the only
+way to keep things from falling apart.
+
+To build Postfix after you installed the Berkeley DB from source code, use
+something like:
+
+    % make makefiles CCARGS="-DHAS_DB -I/usr/local/BerkeleyDB/include" \
+        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" \
+        AUXLIBS="-R/usr/local/BerkeleyDB/lib -L/usr/local/BerkeleyDB/lib -ldb"
+    % make
+
+The exact pathnames depend on the Berkeley DB version, and on how it was
+installed.
+
+Warning: the file format produced by Berkeley DB version 1 is not compatible
+with that of versions 2 and 3 (versions 2 and 3 have the same format). If you
+switch between DB versions, then you may have to rebuild all your Postfix DB
+files.
+
+Warning: if you use Berkeley DB version 2 or later, do not enable DB 1.85
+compatibility mode. Doing so would break fcntl file locking.
+
+Warning: if you use Perl to manipulate Postfix's Berkeley DB files, then you
+need to use the same Berkeley DB version in Perl as in Postfix.
+
+BBuuiillddiinngg PPoossttffiixx oonn BBSSDD ssyysstteemmss wwiitthh mmuullttiippllee BBeerrkkeelleeyy DDBB vveerrssiioonnss
+
+Some BSD systems ship with multiple Berkeley DB implementations. Normally,
+Postfix builds with the default DB version that ships with the system.
+
+To build Postfix on BSD systems with a non-default DB version, use a variant of
+the following commands:
+
+    % make makefiles CCARGS=-I/usr/include/db3 AUXLIBS=-ldb3
+    % make
+
+Warning: the file format produced by Berkeley DB version 1 is not compatible
+with that of versions 2 and 3 (versions 2 and 3 have the same format). If you
+switch between DB versions, then you may have to rebuild all your Postfix DB
+files.
+
+Warning: if you use Berkeley DB version 2 or later, do not enable DB 1.85
+compatibility mode. Doing so would break fcntl file locking.
+
+Warning: if you use Perl to manipulate Postfix's Berkeley DB files, then you
+need to use the same Berkeley DB version in Perl as in Postfix.
+
+BBuuiillddiinngg PPoossttffiixx oonn LLiinnuuxx ssyysstteemmss wwiitthh mmuullttiippllee BBeerrkkeelleeyy DDBB vveerrssiioonnss
+
+Some Linux systems ship with multiple Berkeley DB implementations. Normally,
+Postfix builds with the default DB version that ships with the system.
+
+Warning: some Linux system libraries use Berkeley DB. If you compile Postfix
+with a non-default Berkeley DB implementation, then every Postfix program will
+dump core because either the system library or Postfix itself ends up using the
+wrong version.
+
+On Linux, you need to edit the makedefs script in order to specify a non-
+default DB library. The reason is that the location of the default db.h include
+file changes randomly between vendors and between versions, so that Postfix has
+to choose the file for you.
+
+Warning: the file format produced by Berkeley DB version 1 is not compatible
+with that of versions 2 and 3 (versions 2 and 3 have the same format). If you
+switch between DB versions, then you may have to rebuild all your Postfix DB
+files.
+
+Warning: if you use Berkeley DB version 2 or later, do not enable DB 1.85
+compatibility mode. Doing so would break fcntl file locking.
+
+Warning: if you use Perl to manipulate Postfix's Berkeley DB files, then you
+need to use the same Berkeley DB version in Perl as in Postfix.
+
+TTwweeaakkiinngg ppeerrffoorrmmaannccee
+
+Postfix provides two configuration parameters that control how much buffering
+memory Berkeley DB will use.
+
+  * berkeley_db_create_buffer_size (default: 16 MBytes per table). This setting
+    is used by the commands that maintain Berkeley DB files: postalias(1) and
+    postmap(1). For "hash" files, create performance degrades rapidly unless
+    the memory pool is O(file size). For "btree" files, create performance is
+    good with sorted input even for small memory pools, but with random input
+    degrades rapidly unless the memory pool is O(file size).
+
+  * berkeley_db_read_buffer_size (default: 128 kBytes per table). This setting
+    is used by all other Postfix programs. The buffer size is adequate for
+    reading. If the cache is smaller than the table, random read performance is
+    hardly cache size dependent, except with btree tables, where the cache size
+    must be large enough to contain the entire path from the root node.
+    Empirical evidence shows that 64 kBytes may be sufficient. We double the
+    size to play safe, and to anticipate changes in implementation and bloat.
+
+MMiissssiinngg pptthhrreeaadd lliibbrraarryy ttrroouubbllee
+
+When building Postfix fails with:
+
+    undefined reference to `pthread_condattr_setpshared'
+    undefined reference to `pthread_mutexattr_destroy'
+    undefined reference to `pthread_mutexattr_init'
+    undefined reference to `pthread_mutex_trylock'
+
+Add the "-lpthread" library to the "make makefiles" command.
+
+    % make makefiles .... AUXLIBS="... -lpthread"
+
+More information is available at https://www.oracle.com/database/technologies/
+related/berkeleydb.html.
+
--- a/README_FILES/DEBUG_README
+++ b/README_FILES/DEBUG_README
@ -0,0 +1,402 @@
+PPoossttffiixx DDeebbuuggggiinngg HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document describes how to debug parts of the Postfix mail system when
+things do not work according to expectation. The methods vary from making
+Postfix log a lot of detail, to running some daemon processes under control of
+a call tracer or debugger.
+
+The text assumes that the Postfix main.cf and master.cf configuration files are
+stored in directory /etc/postfix. You can use the command "ppoossttccoonnff
+ccoonnffiigg__ddiirreeccttoorryy" to find out the actual location of this directory on your
+machine.
+
+Listed in order of increasing invasiveness, the debugging techniques are as
+follows:
+
+  * Look for obvious signs of trouble
+  * Debugging Postfix from inside
+  * Try turning off chroot operation in master.cf
+  * Verbose logging for specific SMTP connections
+  * Record the SMTP session with a network sniffer
+  * Making Postfix daemon programs more verbose
+  * Manually tracing a Postfix daemon process
+  * Automatically tracing a Postfix daemon process
+  * Running daemon programs with the interactive ddd debugger
+  * Running daemon programs with the interactive gdb debugger
+  * Running daemon programs under a non-interactive debugger
+  * Unreasonable behavior
+  * Reporting problems to postfix-users@postfix.org
+
+LLooookk ffoorr oobbvviioouuss ssiiggnnss ooff ttrroouubbllee
+
+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:
+
+    % 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.
+
+The nature of each problem is indicated as follows:
+
+  * "ppaanniicc" indicates a problem in the software itself that only a programmer
+    can fix. Postfix cannot proceed until this is fixed.
+
+  * "ffaattaall" is the result of missing files, incorrect permissions, incorrect
+    configuration file settings that you can fix. Postfix cannot proceed until
+    this is fixed.
+
+  * "eerrrroorr" reports an error condition. For safety reasons, a Postfix process
+    will terminate when more than 13 of these happen.
+
+  * "wwaarrnniinngg" indicates a non-fatal error. These are problems that you may not
+    be able to fix (such as a broken DNS server elsewhere on the network) but
+    may also indicate local configuration errors that could become a problem
+    later.
+
+DDeebbuuggggiinngg PPoossttffiixx ffrroomm iinnssiiddee
+
+Postfix version 2.1 and later can produce mail delivery reports for debugging
+purposes. These reports not only show sender/recipient addresses after address
+rewriting and alias expansion or forwarding, they also show information about
+delivery to mailbox, delivery to non-Postfix command, responses from remote
+SMTP servers, and so on.
+
+Postfix can produce two types of mail delivery reports for debugging:
+
+  * What-if: report what would happen, but do not actually deliver mail. This
+    mode of operation is requested with:
+
+    % //uussrr//ssbbiinn//sseennddmmaaiill --bbvv aaddddrreessss......
+    Mail Delivery Status Report will be mailed to <your login name>.
+
+  * What happened: deliver mail and report successes and/or failures, including
+    replies from remote SMTP servers. This mode of operation is requested with:
+
+    % //uussrr//ssbbiinn//sseennddmmaaiill --vv aaddddrreessss......
+    Mail Delivery Status Report will be mailed to <your login name>.
+
+These reports contain information that is generated by Postfix delivery agents.
+Since these run as daemon processes that cannot interact with users directly,
+the result is sent as mail to the sender of the test message. The format of
+these reports is practically identical to that of ordinary non-delivery
+notifications.
+
+For a detailed example of a mail delivery status report, see the debugging
+section at the end of the ADDRESS_REWRITING_README document.
+
+TTrryy ttuurrnniinngg ooffff cchhrroooott ooppeerraattiioonn iinn mmaasstteerr..ccff
+
+A common mistake is to turn on chroot operation in the master.cf file without
+going through all the necessary steps to set up a chroot environment. This
+causes Postfix daemon processes to fail due to all kinds of missing files.
+
+The example below shows an SMTP server that is configured with chroot turned
+off:
+
+    /etc/postfix/master.cf:
+        # =============================================================
+        # service type  private unpriv  cchhrroooott  wakeup  maxproc command
+        #               (yes)   (yes)   ((yyeess))   (never) (100)
+        # =============================================================
+        smtp      inet  n       -       nn       -       -       smtpd
+
+Inspect master.cf for any processes that have chroot operation not turned off.
+If you find any, save a copy of the master.cf file, and edit the entries in
+question. After executing the command "ppoossttffiixx rreellooaadd", see if the problem has
+gone away.
+
+If turning off chrooted operation made the problem go away, then
+congratulations. Leaving Postfix running in this way is adequate for most
+sites. If you prefer chrooted operation, see the Postfix
+BASIC_CONFIGURATION_README file for information about how to prepare Postfix
+for chrooted operation.
+
+VVeerrbboossee llooggggiinngg ffoorr ssppeecciiffiicc SSMMTTPP ccoonnnneeccttiioonnss
+
+In /etc/postfix/main.cf, list the remote site name or address in the
+debug_peer_list parameter. For example, in order to make the software log a lot
+of information to the syslog daemon for connections from or to the loopback
+interface:
+
+    /etc/postfix/main.cf:
+        debug_peer_list = 127.0.0.1
+
+You can specify one or more hosts, domains, addresses or net/masks. To make the
+change effective immediately, execute the command "ppoossttffiixx rreellooaadd".
+
+RReeccoorrdd tthhee SSMMTTPP sseessssiioonn wwiitthh aa nneettwwoorrkk ssnniiffffeerr
+
+This example uses ttccppdduummpp. In order to record a conversation you need to
+specify a large enough buffer with the "--ss" option or else you will miss some
+or all of the packet payload.
+
+    # ttccppdduummpp --ww //ffiillee//nnaammee --ss 00 hhoosstt eexxaammppllee..ccoomm aanndd ppoorrtt 2255
+
+Older tcpdump versions don't support "--ss 00"; in that case, use "--ss 22000000"
+instead.
+
+Run this for a while, stop with Ctrl-C when done. To view the data use a binary
+viewer, eetthheerreeaall, or good old lleessss.
+
+MMaakkiinngg PPoossttffiixx ddaaeemmoonn pprrooggrraammss mmoorree vveerrbboossee
+
+Append one or more "--vv" options to selected daemon definitions in /etc/postfix/
+master.cf and type "ppoossttffiixx rreellooaadd". This will cause a lot of activity to be
+logged to the syslog daemon. For example, to make the Postfix SMTP server
+process more verbose:
+
+    /etc/postfix/master.cf:
+        smtp      inet  n       -       n       -       -       smtpd -v
+
+To diagnose problems with address rewriting specify a "--vv" option for the
+cleanup(8) and/or trivial-rewrite(8) daemon, and to diagnose problems with mail
+delivery specify a "--vv" option for the qmgr(8) or oqmgr(8) queue manager, or
+for the lmtp(8), local(8), pipe(8), smtp(8), or virtual(8) delivery agent.
+
+MMaannuuaallllyy ttrraacciinngg aa PPoossttffiixx ddaaeemmoonn pprroocceessss
+
+Many systems allow you to inspect a running process with a system call tracer.
+For example:
+
+    # ttrraaccee --pp pprroocceessss--iidd (SunOS 4)
+    # ssttrraaccee --pp pprroocceessss--iidd (Linux and many others)
+    # ttrruussss --pp pprroocceessss--iidd (Solaris, FreeBSD)
+    # kkttrraaccee --pp pprroocceessss--iidd (generic 4.4BSD)
+
+Even more informative are traces of system library calls. Examples:
+
+    # llttrraaccee --pp pprroocceessss--iidd (Linux, also ported to FreeBSD and BSD/OS)
+    # ssoottrruussss --pp pprroocceessss--iidd (Solaris)
+
+See your system documentation for details.
+
+Tracing a running process can give valuable information about what a process is
+attempting to do. This is as much information as you can get without running an
+interactive debugger program, as described in a later section.
+
+AAuuttoommaattiiccaallllyy ttrraacciinngg aa PPoossttffiixx ddaaeemmoonn pprroocceessss
+
+Postfix can attach a call tracer whenever a daemon process starts. Call tracers
+come in several kinds.
+
+ 1. System call tracers such as ttrraaccee, ttrruussss, ssttrraaccee, or kkttrraaccee. These show the
+    communication between the process and the kernel.
+
+ 2. Library call tracers such as ssoottrruussss and llttrraaccee. These show calls of
+    library routines, and give a better idea of what is going on within the
+    process.
+
+Append a --DD option to the suspect command in /etc/postfix/master.cf, for
+example:
+
+    /etc/postfix/master.cf:
+        smtp      inet  n       -       n       -       -       smtpd -D
+
+Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes
+the call tracer of your choice, for example:
+
+    /etc/postfix/main.cf:
+        debugger_command =
+             PATH=/bin:/usr/bin:/usr/local/bin;
+             (truss -p $process_id 2>&1 | logger -p mail.info) & sleep 5
+
+Type "ppoossttffiixx rreellooaadd" and watch the logfile.
+
+RRuunnnniinngg ddaaeemmoonn pprrooggrraammss wwiitthh tthhee iinntteerraaccttiivvee dddddd ddeebbuuggggeerr
+
+If you have X Windows installed on the Postfix machine, then an interactive
+debugger such as dddddd can be convenient.
+
+Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes
+dddddd:
+
+    /etc/postfix/main.cf:
+        debugger_command =
+             PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
+             ddd $daemon_directory/$process_name $process_id & sleep 5
+
+Be sure that ggddbb is in the command search path, and export XXAAUUTTHHOORRIITTYY so that X
+access control works, for example:
+
+    % sseetteennvv XXAAUUTTHHOORRIITTYY ~~//..XXaauutthhoorriittyy (csh syntax)
+    $ eexxppoorrtt XXAAUUTTHHOORRIITTYY==$$HHOOMMEE//..XXaauutthhoorriittyy (sh syntax)
+
+Append a --DD option to the suspect daemon definition in /etc/postfix/master.cf,
+for example:
+
+    /etc/postfix/master.cf:
+        smtp      inet  n       -       n       -       -       smtpd -D
+
+Stop and start the Postfix system. This is necessary so that Postfix runs with
+the proper XXAAUUTTHHOORRIITTYY and DDIISSPPLLAAYY settings.
+
+Whenever the suspect daemon process is started, a debugger window pops up and
+you can watch in detail what happens.
+
+RRuunnnniinngg ddaaeemmoonn pprrooggrraammss wwiitthh tthhee iinntteerraaccttiivvee ggddbb ddeebbuuggggeerr
+
+If you have the screen command installed on the Postfix machine, then you can
+run an interactive debugger such as ggddbb as follows.
+
+Edit the debugger_command definition in /etc/postfix/main.cf so that it runs
+ggddbb inside a detached ssccrreeeenn session:
+
+    /etc/postfix/main.cf:
+        debugger_command =
+            PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH; HOME=/root;
+            export HOME; screen -e^tt -dmS $process_name gdb
+            $daemon_directory/$process_name $process_id & sleep 2
+
+Be sure that ggddbb is in the command search path.
+
+Append a --DD option to the suspect daemon definition in /etc/postfix/master.cf,
+for example:
+
+    /etc/postfix/master.cf:
+        smtp      inet  n       -       n       -       -       smtpd -D
+
+Execute the command "ppoossttffiixx rreellooaadd" and wait until a daemon process is started
+(you can see this in the maillog file).
+
+Then attach to the screen, and debug away:
+
+    # HOME=/root screen -r
+    gdb) continue
+    gdb) where
+
+RRuunnnniinngg ddaaeemmoonn pprrooggrraammss uunnddeerr aa nnoonn--iinntteerraaccttiivvee ddeebbuuggggeerr
+
+If you do not have X Windows installed on the Postfix machine, or if you are
+not familiar with interactive debuggers, then you can try to run ggddbb in non-
+interactive mode, and have it print a stack trace when the process crashes.
+
+Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes
+the ggddbb debugger:
+
+    /etc/postfix/main.cf:
+        debugger_command =
+            PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; echo
+            where; sleep 8640000) | gdb $daemon_directory/$process_name
+            $process_id 2>&1
+            >$config_directory/$process_name.$process_id.log & sleep 5
+
+Append a --DD option to the suspect daemon in /etc/postfix/master.cf, for
+example:
+
+    /etc/postfix/master.cf:
+        smtp      inet  n       -       n       -       -       smtpd -D
+
+Type "ppoossttffiixx rreellooaadd" to make the configuration changes effective.
+
+Whenever a suspect daemon process is started, an output file is created, named
+after the daemon and process ID (for example, smtpd.12345.log). When the
+process crashes, a stack trace (with output from the "wwhheerree" command) is
+written to its logfile.
+
+UUnnrreeaassoonnaabbllee bbeehhaavviioorr
+
+Sometimes the behavior exhibited by Postfix just does not match the source
+code. Why can a program deviate from the instructions given by its author?
+There are two possibilities.
+
+  * The compiler has erred. This rarely happens.
+
+  * The hardware has erred. Does the machine have ECC memory?
+
+In both cases, the program being executed is not the program that was supposed
+to be executed, so anything could happen.
+
+There is a third possibility:
+
+  * Bugs in system software (kernel or libraries).
+
+Hardware-related failures usually do not reproduce in exactly the same way
+after power cycling and rebooting the system. There's little Postfix can do
+about bad hardware. Be sure to use hardware that at the very least can detect
+memory errors. Otherwise, Postfix will just be waiting to be hit by a bit
+error. Critical systems deserve real hardware.
+
+When a compiler makes an error, the problem can be reproduced whenever the
+resulting program is run. Compiler errors are most likely to happen in the code
+optimizer. If a problem is reproducible across power cycles and system reboots,
+it can be worthwhile to rebuild Postfix with optimization disabled, and to see
+if optimization makes a difference.
+
+In order to compile Postfix with optimizations turned off:
+
+    % mmaakkee ttiiddyy
+    % mmaakkee mmaakkeeffiilleess OOPPTT==
+
+This produces a set of Makefiles that do not request compiler optimization.
+
+Once the makefiles are set up, build the software:
+
+    % mmaakkee
+    % ssuu
+    Password:
+    # mmaakkee iinnssttaallll
+
+If the problem goes away, then it is time to ask your vendor for help.
+
+RReeppoorrttiinngg pprroobblleemmss ttoo ppoossttffiixx--uusseerrss@@ppoossttffiixx..oorrgg
+
+The people who participate on postfix-users@postfix.org are very helpful,
+especially if YOU provide them with sufficient information. Remember, these
+volunteers are willing to help, but their time is limited.
+
+When reporting a problem, be sure to include the following information.
+
+  * A summary of the problem. Please do not just send some logging without
+    explanation of what YOU believe is wrong.
+
+  * Complete error messages. Please use cut-and-paste, or use attachments,
+    instead of reciting information from memory.
+
+  * Postfix logging. See the text at the top of the DEBUG_README document to
+    find out where logging is stored. Please do not frustrate the helpers by
+    word wrapping the logging. If the logging is more than a few kbytes of
+    text, consider posting an URL on a web or ftp site.
+
+  * Consider using a test email address so that you don't have to reveal email
+    addresses or passwords of innocent people.
+
+  * If you can't use a test email address, please anonymize email addresses and
+    host names consistently. Replace each letter by "A", each digit by "D" so
+    that the helpers can still recognize syntactical errors.
+
+  * Command output from:
+
+      o "ppoossttccoonnff --nn". Please do not send your main.cf file, or 1000+ lines of
+        ppoossttccoonnff command output.
+
+      o "ppoossttccoonnff --MMff" (Postfix 2.9 or later).
+
+  * 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 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.
+
+  * If the problem is protocol related (connections time out, or an SMTP server
+    complains about syntax errors etc.) consider recording a session with
+    ttccppdduummpp, as described in the DEBUG_README document.
+
--- a/README_FILES/DEPRECATION_README
+++ b/README_FILES/DEPRECATION_README
@ -0,0 +1,270 @@
+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|          |                         |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |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 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.
+
--- a/README_FILES/DSN_README
+++ b/README_FILES/DSN_README
@ -0,0 +1,98 @@
+PPoossttffiixx DDSSNN SSuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix version 2.3 introduces support for Delivery Status Notifications as
+described in RFC 3464. This gives senders control over successful and failed
+delivery notifications.
+
+Specifically, DSN support gives an email sender the ability to specify:
+
+  * What notifications are sent: success, failure, delay, or none. Normally,
+    Postfix informs the sender only when mail delivery is delayed or when
+    delivery fails.
+
+  * What content is returned in case of failure: only the message headers, or
+    the full message.
+
+  * An envelope ID that is returned as part of delivery status notifications.
+    This identifies the message submission transaction, and must not be
+    confused with the message ID, which identifies the message content.
+
+The implementation of DSN support involves extra parameters to the SMTP MAIL
+FROM and RCPT TO commands, as well as two Postfix sendmail command line options
+that provide a sub-set of the functions of the extra SMTP command parameters.
+
+This document has information on the following topics:
+
+  * Restricting the scope of "success" notifications
+  * Postfix sendmail command-line interface
+  * Postfix VERP support compatibility
+
+RReessttrriiccttiinngg tthhee ssccooppee ooff ""ssuucccceessss"" nnoottiiffiiccaattiioonnss
+
+Just like reports of undeliverable mail, DSN reports of successful delivery can
+give away more information about the internal infrastructure than desirable.
+Unfortunately, disallowing "success" notification requests requires disallowing
+other DSN requests as well. The RFCs do not offer the option to negotiate
+feature subsets.
+
+This is not as bad as it sounds. When you turn off DSN for remote inbound mail,
+remote senders with DSN support will still be informed that their mail reached
+your Postfix gateway successfully; they just will not get successful delivery
+notices from your internal systems. Remote senders lose very little: they can
+no longer specify how Postfix should report delayed or failed delivery.
+
+Use the smtpd_discard_ehlo_keyword_address_maps feature if you wish to allow
+DSN requests from trusted clients but not from random strangers (see below for
+how to turn this off for all clients):
+
+    /etc/postfix/main.cf:
+        smtpd_discard_ehlo_keyword_address_maps =
+            cidr:/etc/postfix/esmtp_access
+
+    /etc/postfix/esmtp_access:
+        # Allow DSN requests from local subnet only
+        192.168.0.0/28      silent-discard
+        0.0.0.0/0           silent-discard, dsn
+        ::/0                silent-discard, dsn
+
+If you want to disallow all use of DSN requests from the network, use the
+smtpd_discard_ehlo_keywords feature:
+
+    /etc/postfix/main.cf:
+        smtpd_discard_ehlo_keywords = silent-discard, dsn
+
+PPoossttffiixx sseennddmmaaiill ccoommmmaanndd--lliinnee iinntteerrffaaccee
+
+Postfix has two Sendmail-compatible command-line options for DSN support.
+
+  * The first option specifies what notifications are sent for mail that is
+    submitted via the Postfix sendmail(1) command line:
+
+        $ sseennddmmaaiill --NN ssuucccceessss,,ddeellaayy,,ffaaiilluurree ...... (one or more of these)
+        $ sseennddmmaaiill --NN nneevveerr ......                 (or just this by itself)
+
+    The built-in default corresponds with "delay,failure".
+
+  * The second option specifies an envelope ID which is reported in delivery
+    status notifications for mail that is submitted via the Postfix sendmail(1)
+    command line:
+
+        $ sseennddmmaaiill --VV eennvveellooppee--iidd ......
+
+    Note: this conflicts with VERP support in older Postfix versions, as
+    discussed in the next section.
+
+PPoossttffiixx VVEERRPP ssuuppppoorrtt ccoommppaattiibbiilliittyy
+
+With Postfix versions before 2.3, the sendmail(1) command uses the -V command-
+line option to request VERP-style delivery. In order to request VERP style
+delivery with Postfix 2.3 and later, you must specify -XV instead of -V.
+
+The Postfix 2.3 sendmail(1) command will recognize if you try to use -V for
+VERP-style delivery. It will do the right thing and will remind you of the new
+syntax.
+
--- a/README_FILES/ETRN_README
+++ b/README_FILES/ETRN_README
@ -0,0 +1,250 @@
+PPoossttffiixx EETTRRNN HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
+
+The SMTP ETRN command was designed for sites that have intermittent Internet
+connectivity. With ETRN, a site can tell the mail server of its provider to
+"Please deliver all my mail now". The SMTP server searches the queue for mail
+to the customer, and delivers that mail bbyy ccoonnnneeccttiinngg ttoo tthhee ccuussttoommeerr''ss SSMMTTPP
+sseerrvveerr. The mail is not delivered via the connection that was used for sending
+ETRN.
+
+As of version 1.0, Postfix has a fast ETRN implementation that does not require
+Postfix to examine every queue file. Instead, Postfix maintains a record of
+what queue files contain mail for destinations that are configured for ETRN
+service. ETRN service is no longer available for domains that aren't configured
+for the service.
+
+This document provides information on the following topics:
+
+  * Using the Postfix fast ETRN service
+  * How Postfix fast ETRN works
+  * Postfix fast ETRN service limitations
+  * Configuring the Postfix fast ETRN service
+  * Configuring a domain for ETRN service only
+  * Testing the Postfix fast ETRN service
+
+Other documents with information on this subject:
+
+  * flush(8), flush service implementation
+
+UUssiinngg tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
+
+The following is an example SMTP session that shows how an SMTP client requests
+the ETRN service. Client commands are shown in bold font.
+
+    220 my.server.tld ESMTP Postfix
+    HHEELLOO mmyy..cclliieenntt..ttlldd
+    250 Ok
+    EETTRRNN ssoommee..ccuussttoommeerr..ddoommaaiinn
+    250 Queuing started
+    QQUUIITT
+    221 Bye
+
+As mentioned in the introduction, the mail is delivered by connecting to the
+customer's SMTP server; it is not sent over the connection that was used to
+send the ETRN command.
+
+The Postfix operator can request delivery for a specific customer by using the
+command "sendmail -qRdestination" and, with Postfix version 1.1 and later,
+"postqueue -sdestination". Access to this feature is controlled with the
+authorized_flush_users configuration parameter (Postfix version 2.2 and later).
+
+HHooww PPoossttffiixx ffaasstt EETTRRNN wwoorrkkss
+
+When a Postfix delivery agent decides that mail must be delivered later, it
+sends the destination domain name and the queue file name to the flush(8)
+daemon which maintains per-destination logfiles with file names of queued mail.
+These logfiles are kept below $queue_directory/flush. Per-destination logfiles
+are maintained only for destinations that are listed with the
+$fast_flush_domains parameter and that have syntactically valid domain names.
+
+    Postfix                        Postfix               One logfile
+    delivery -(domain, queue ID)->  flush  -(queue ID)-> per eligible
+     agent                         daemon                   domain
+
+When Postfix receives a request to "deliver mail for a domain now", the flush
+(8) daemon moves all deferred queue files that are listed for that domain to
+the incoming queue, and requests that the queue manager deliver them. In order
+to force delivery, the queue manager temporarily ignores the lists of
+undeliverable destinations: the volatile in-memory list of dead domains, and
+the list of message delivery transports specified with the defer_transports
+configuration parameter.
+
+PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee lliimmiittaattiioonnss
+
+The design of the flush(8) server and of the flush queue introduce a few
+limitations that should not be an issue unless you want to turn on fast ETRN
+service for every possible destination.
+
+  * The flush(8) daemon maintains per-destination logfiles with queue file
+    names. When a request to "deliver mail now" arrives, Postfix will attempt
+    to deliver all recipients in the queue files that have mail for the
+    destination in question. This does not perform well with queue files that
+    have recipients in many different domains, such as queue files with
+    outbound mailing list traffic.
+
+  * The flush(8) daemon maintains per-destination logfiles only for
+    destinations listed with $fast_flush_domains. With other destinations you
+    cannot request delivery with "sendmail -qRdestination" or, with Postfix
+    version 1.1 and later, "postqueue -sdestination".
+
+  * Up to and including early versions of Postfix version 2.1, the "fast flush"
+    service may not deliver some messages if the request to "deliver mail now"
+    is received while a deferred queue scan is already in progress. The reason
+    is that the queue manager does not ignore the volatile in-memory list of
+    dead domains, and the list of message delivery transports specified with
+    the defer_transports configuration parameter.
+
+  * Up to and including Postfix version 2.3, the "fast flush" service may not
+    deliver some messages if the request to "deliver mail now" arrives while an
+    incoming queue scan is already in progress.
+
+CCoonnffiigguurriinngg tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
+
+The behavior of the flush(8) daemon is controlled by parameters in the main.cf
+configuration file.
+
+By default, Postfix "fast ETRN" service is available only for destinations that
+Postfix is willing to relay mail to:
+
+    /etc/postfix/main.cf:
+        fast_flush_domains = $relay_domains
+        smtpd_etrn_restrictions = permit_mynetworks, reject
+
+Notes:
+
+  * The relay_domains parameter specifies what destinations Postfix will relay
+    to. For destinations that are not eligible for the "fast ETRN" service,
+    Postfix replies with an error message.
+
+  * The smtpd_etrn_restrictions parameter limits what clients may execute the
+    ETRN command. By default, any client has permission.
+
+To enable "fast ETRN" for some other destination, specify:
+
+    /etc/postfix/main.cf:
+        fast_flush_domains = $relay_domains, some.other.domain
+
+To disable "fast ETRN", so that Postfix rejects all ETRN requests and so that
+it maintains no per-destination logfiles, specify:
+
+    /etc/postfix/main.cf:
+        fast_flush_domains =
+
+CCoonnffiigguurriinngg aa ddoommaaiinn ffoorr EETTRRNN sseerrvviiccee oonnllyy
+
+While an "ETRN" customer is off-line, Postfix will make spontaneous attempts to
+deliver mail to it. These attempts are separated in time by increasing time
+intervals, ranging from $minimal_backoff_time to $maximal_backoff_time, and
+should not be a problem unless a lot of mail is queued.
+
+To prevent Postfix from making spontaneous delivery attempts you can configure
+Postfix to always defer mail for the "ETRN" customer. Mail is delivered only
+after the ETRN command or with "sendmail -q", with "sendmail -qRdomain", or
+with "postqueue -sdomain"(Postfix version 1.1 and later only),
+
+In the example below we configure an "etrn-only" delivery transport which is
+simply a duplicate of the "smtp" and "relay" mail delivery transports. The only
+difference is that mail destined for this delivery transport is deferred as
+soon as it arrives.
+
+     1 /etc/postfix/master.cf:
+     2   # =============================================================
+     3   # service type  private unpriv  chroot  wakeup  maxproc command
+     4   #               (yes)   (yes)   (yes)   (never) (100)
+     5   # =============================================================
+     6   smtp      unix  -       -       n       -       -       smtp
+     7   relay     unix  -       -       n       -       -       smtp
+     8   etrn-only unix  -       -       n       -       -       smtp
+     9
+    10 /etc/postfix/main.cf:
+    11   relay_domains = customer.tld ...other domains...
+    12   defer_transports = etrn-only
+    13   transport_maps = hash:/etc/postfix/transport
+    14
+    15 /etc/postfix/transport:
+    16   customer.tld     etrn-only:[mailhost.customer.tld]
+
+Translation:
+
+  * Line 8: The "etrn-only" mail delivery service is a copy of the "smtp" and
+    "relay" service.
+
+  * Line 11: Don't forget to authorize relaying for this customer, either via
+    relay_domains or with the permit_mx_backup feature.
+
+  * Line 12: The "etrn-only" mail delivery service is configured so that
+    spontaneous mail delivery is disabled.
+
+  * Lines 13-16: Mail for the customer is given to the "etrn-only" mail
+    delivery service.
+
+  * Line 16: The "[mailhost.customer.tld]" turns off MX record lookups; you
+    must specify this if your Postfix server is the primary MX host for the
+    customer's domain.
+
+TTeessttiinngg tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
+
+By default, "fast ETRN" service is enabled for all domains that match
+$relay_domains. If you run Postfix with "fast ETRN" service for the very first
+time, you need to run "sendmail -q" once in order to populate the per-site
+deferred mail logfiles. If you omit this step, no harm is done. The logfiles
+will eventually become populated as Postfix routinely attempts to deliver
+delayed mail, but that will take a couple hours. After the "sendmail -q"
+command has completed all delivery attempts (this can take a while), you're
+ready to test the "fast ETRN" service.
+
+To test the "fast ETRN" service, telnet to the Postfix SMTP server from a
+client that is allowed to execute ETRN commands (by default, that's every
+client), and type the commands shown in boldface:
+
+    220 my.server.tld ESMTP Postfix
+    HHEELLOO mmyy..cclliieenntt..ttlldd
+    250 Ok
+    EETTRRNN ssoommee..ccuussttoommeerr..ddoommaaiinn
+    250 Queuing started
+
+where "some.customer.domain" is the name of a domain that has a non-empty
+logfile somewhere under $queue_directory/flush.
+
+In the maillog file, you should immediately see a couple of logfile records, as
+evidence that the queue manager has opened queue files:
+
+    Oct  2 10:51:19 myhostname postfix/qmgr[51999]: 682E8440A4:
+        from=<whatever>, size=12345, nrcpt=1 (queue active)
+    Oct  2 10:51:19 myhostname postfix/qmgr[51999]: 02249440B7:
+        from=<whatever>, size=4711, nrcpt=1 (queue active)
+
+What happens next depends on whether the destination is reachable. If it's not
+reachable, the mail queue IDs will be added back to the some.customer.domain
+logfile under $queue_directory/flush.
+
+Repeat the exercise with some other destination that your server is willing to
+relay to (any domain listed in $relay_domains), but that has no mail queued.
+The text in bold face stands for the commands that you type:
+
+    220 my.server.tld ESMTP Postfix
+    HHEELLOO mmyy..cclliieenntt..ttlldd
+    250 Ok
+    EETTRRNN ssoommee..ootthheerr..ccuussttoommeerr..ddoommaaiinn
+    250 Queuing started
+
+This time, the "ETRN"" command should trigger NO mail deliveries at all. If
+this triggers delivery of all mail, then you used the wrong domain name, or
+"fast ETRN" service is turned off.
+
+Finally, repeat the exercise with a destination that your mail server is not
+willing to relay to. It does not matter if your server has mail queued for that
+destination.
+
+    220 my.server.tld ESMTP Postfix
+    HHEELLOO mmyy..cclliieenntt..ttlldd
+    250 Ok
+    EETTRRNN nnoott..aa..ccuussttoommeerr..ddoommaaiinn
+    459 <not.a.customer.domain>: service unavailable
+
+In this case, Postfix should reject the request as shown above.
+
--- a/README_FILES/FILTER_README
+++ b/README_FILES/FILTER_README
@ -0,0 +1,617 @@
+PPoossttffiixx AAfftteerr--QQuueeuuee CCoonntteenntt FFiilltteerr
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+This document requires Postfix version 2.1 or later.
+
+Normally, Postfix receives mail, stores it in the mail queue and then delivers
+it. With the external content filter described here, mail is filtered AFTER it
+is queued. This approach decouples mail receiving processes from mail filtering
+processes, and gives you maximal control over how many filtering processes you
+are willing to run in parallel.
+
+The after-queue content filter is meant to be used as follows:
+
+    Network or  -> Postfix -> CCoonntteenntt -> Postfix ->  Network or
+    local users     queue     ffiilltteerr      queue     local mailbox
+
+This document describes implementations that use a single Postfix instance for
+everything: receiving, filtering and delivering mail. Applications that use two
+separate Postfix instances will be covered by a later version of this document.
+
+The after-queue content filter is not to be confused with the approaches
+described in the SMTPD_PROXY_README or MILTER_README documents, where incoming
+SMTP mail is filtered BEFORE it is stored into the Postfix queue.
+
+This document describes two approaches to content filter all email, as well as
+several options to filter mail selectively:
+
+  * Principles of operation
+  * Simple content filter
+
+      o Simple content filter example
+      o Simple content filter performance
+      o Simple content filter limitations
+      o Turning off the simple content filter
+
+  * Advanced content filter
+
+      o Advanced content filter example
+      o Advanced content filter performance
+      o Turning off the advanced content filter
+
+  * Selective content filtering
+
+      o Filtering mail from outside users only
+      o Different filters for different domains
+      o FILTER actions in access or header/body tables
+
+PPrriinncciipplleess ooff ooppeerraattiioonn
+
+An after-queue content filter receives unfiltered mail from Postfix (as
+described further below) and can do one of the following:
+
+ 1. Re-inject the mail back into Postfix, perhaps after changing content and/or
+    destination.
+
+ 2. Discard or quarantine the mail.
+
+ 3. Reject the mail (by sending a suitable status code back to Postfix).
+    Postfix will send the mail back to the sender address.
+
+NOTE: in this time of mail worms and forged spam, it is a VERY BAD IDEA to send
+viruses back to the sender address, because the sender address is almost
+certainly not the originator. It is better to discard known viruses, and to
+quarantine material that is suspect so that a human can decide what to do with
+it.
+
+SSiimmppllee ccoonntteenntt ffiilltteerr eexxaammppllee
+
+The first example is simple to set up, but has major limitations that will be
+addressed in a second example. Postfix receives unfiltered mail from the
+network with the smtpd(8) server, and delivers unfiltered mail to a content
+filter with the Postfix pipe(8) delivery agent. The content filter injects
+filtered mail back into Postfix with the Postfix sendmail(1) command, so that
+Postfix can deliver it to the final destination.
+
+This means that mail submitted via the Postfix sendmail(1) command cannot be
+content filtered.
+
+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
+architecture.
+
+    Unfiltered -> smtpd(8)                   qmgr(8)     local(8) -> Filtered
+                            >- cleanup(8) -> Postfix  -< smtp(8)  -> Filtered
+                  pickup(8)                   queue      pipe(8)
+
+                        ^                                     |
+                        |                                     v
+
+                  maildrop      Postfix      Postfix     Content
+                    queue   <-  postdrop  <- sendmail <-  filter
+                                  (1)          (1)
+
+The content filter can be a simple shell script like this:
+
+     1 #!/bin/sh
+     2
+     3 # Simple shell-based filter. It is meant to be invoked as follows:
+     4 #       /path/to/script -f sender recipients...
+     5
+     6 # Localize these. The -G option does nothing before Postfix 2.3.
+     7 INSPECT_DIR=/var/spool/filter
+     8 SENDMAIL="/usr/sbin/sendmail -G -i" # NEVER NEVER NEVER use "-t" here.
+     9
+    10 # Exit codes from <sysexits.h>
+    11 EX_TEMPFAIL=75
+    12 EX_UNAVAILABLE=69
+    13
+    14 # Clean up when done or when aborting.
+    15 trap "rm -f in.$$" 0 1 2 3 15
+    16
+    17 # Start processing.
+    18 cd $INSPECT_DIR || {
+    19     echo $INSPECT_DIR does not exist; exit $EX_TEMPFAIL; }
+    20
+    21 cat >in.$$ || {
+    22     echo Cannot save mail to file; exit $EX_TEMPFAIL; }
+    23
+    24 # Specify your content filter here.
+    25 # filter <in.$$ || {
+    26 #   echo Message content rejected; exit $EX_UNAVAILABLE; }
+    27
+    28 $SENDMAIL "$@" <in.$$
+    29
+    30 exit $?
+
+Notes:
+
+  * Line 8: The -G option says the filter output is not a local mail
+    submission: don't do silly things like appending the local domain name to
+    addresses in message headers. This option does nothing before Postfix
+    version 2.3.
+
+  * Line 8: The -i option says don't stop reading input when a line contains
+    "." only.
+
+  * Line 8: NEVER NEVER NEVER use the "-t" command-line option here. It will
+    mis-deliver mail, like sending messages from a mailing list back to the
+    mailing list.
+
+  * Line 21: The idea is to first capture the message to file and then run the
+    content through a third-party content filter program.
+
+  * Line 22: If the message cannot be captured to file, mail delivery is
+    deferred by terminating with exit status 75 (EX_TEMPFAIL). Postfix places
+    the message in the deferred mail queue and tries again later.
+
+  * Line 25: You will need to specify a real content filter program here that
+    receives the content on standard input.
+
+  * Line 26: If the content filter program finds a problem, the mail is bounced
+    by terminating with exit status 69 (EX_UNAVAILABLE). Postfix will send the
+    message back to the sender as undeliverable mail.
+
+  * NOTE: in this time of mail worms and spam, it is a BAD IDEA to send known
+    viruses or spam back to the sender, because that address is likely to be
+    forged. It is safer to discard known viruses and to quarantine suspicious
+    content so that it can be inspected by a human being.
+
+  * Line 28: If the content is OK, it is given as input to the Postfix sendmail
+    command, and the exit status of the filter command is whatever exit status
+    the Postfix sendmail command produces. Postfix will deliver the message as
+    usual.
+
+  * Line 30: Postfix returns the exit status of the Postfix sendmail command.
+
+I suggest that you first run this script by hand until you are satisfied with
+the results. Run it with a real message (headers+body) as input:
+
+    % /path/to/script -f sender -- recipient... <message-file
+
+Once you're satisfied with the content filtering script:
+
+  * Create a dedicated local user account called "filter". This user handles
+    all potentially dangerous mail content - that is why it should be a
+    separate account. Do not use "nobody", and most certainly do not use "root"
+    or "postfix".
+
+  * Create a directory /var/spool/filter that is accessible only to the
+    "filter" user. This is where the content filtering script is supposed to
+    store its temporary files.
+
+  * Configure Postfix to deliver mail to the content filter with the pipe(8)
+    delivery agent (see the pipe(8) manpage for a description of the command
+    syntax below).
+
+    /etc/postfix/master.cf:
+      # =============================================================
+      # service type  private unpriv  chroot  wakeup  maxproc command
+      #               (yes)   (yes)   (yes)   (never) (100)
+      # =============================================================
+      filter    unix  -       n       n       -       10      pipe
+        flags=Rq user=filter null_sender=
+        argv=/path/to/script -f ${sender} -- ${recipient}
+
+    This runs up to 10 content filters in parallel. Instead of a limit of 10
+    concurrent processes, use whatever process limit is feasible for your
+    machine. Content inspection software can gobble up a lot of system
+    resources, so you don't want to have too much of it running at the same
+    time. The empty null_sender setting is required with Postfix 2.3 and later.
+
+  * To turn on content filtering for mail arriving via SMTP only, append "-
+    o content_filter=filter:dummy" to the master.cf entry that defines the
+    Postfix SMTP server:
+
+    /etc/postfix/master.cf:
+      # =============================================================
+      # service type  private unpriv  chroot  wakeup  maxproc command
+      #               (yes)   (yes)   (yes)   (never) (100)
+      # =============================================================
+      smtp      inet  ...other stuff here, do not change...   smtpd
+            -o content_filter=filter:dummy
+
+    The "-o content_filter" line causes Postfix to add one content filter
+    request record to each incoming mail message, with content "filter:dummy".
+    This record overrides the normal mail routing and causes mail to be given
+    to the content filter instead.
+
+    The content_filter configuration parameter expects a value of the form
+    transport:destination. 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.
+
+    The meaning of an empty next-hop filter destination is version dependent.
+    Postfix 2.7 and later will use the recipient domain; earlier versions will
+    use $myhostname. Specify "default_filter_nexthop = $myhostname" for
+    compatibility with Postfix 2.6 or earlier, or specify a non-empty next-hop
+    filter destination.
+
+    The content_filter setting has lower precedence than a FILTER action that
+    is specified in an access(5), header_checks(5) or body_checks(5) table.
+
+  * Execute "ppoossttffiixx rreellooaadd" to complete the change.
+
+SSiimmppllee ccoonntteenntt ffiilltteerr ppeerrffoorrmmaannccee
+
+With the shell script as shown above you will lose a factor of four in Postfix
+performance for transit mail that arrives and leaves via SMTP. You will lose
+another factor in transit performance for each additional temporary file that
+is created and deleted in the process of content filtering. The performance
+impact is less for mail that is submitted or delivered locally, because such
+deliveries are already slower than SMTP transit mail.
+
+SSiimmppllee ccoonntteenntt ffiilltteerr lliimmiittaattiioonnss
+
+The problem with content filters like the one above is that they are not very
+robust. The reason is that the software does not talk a well-defined protocol
+with Postfix. If the filter shell script aborts because the shell runs into
+some memory allocation problem, the script will not produce a nice exit status
+as defined in the file /usr/include/sysexits.h. Instead of going to the
+deferred queue, mail will bounce. The same lack of robustness can happen when
+the content filtering software itself runs into a resource problem.
+
+The simple content filter method is not suitable for content filter actions
+that are invoked via header_checks or body_checks patterns. These patterns will
+be applied again after mail is re-injected with the Postfix sendmail command,
+resulting in a mail filtering loop. The advanced content filtering method (see
+below) makes it possible to turn off header_checks or body_checks patterns for
+filtered mail.
+
+TTuurrnniinngg ooffff tthhee ssiimmppllee ccoonntteenntt ffiilltteerr
+
+To turn off "simple" content filtering:
+
+  * Edit the master.cf file, remove the "-o content_filter=filter:dummy" text
+    from the entry that defines the Postfix SMTP server.
+
+  * Execute "ppoossttssuuppeerr --rr AALLLL" to remove content filter request records from
+    existing queue files.
+
+  * Execute another "ppoossttffiixx rreellooaadd".
+
+AAddvvaanncceedd ccoonntteenntt ffiilltteerr eexxaammppllee
+
+The second example is more complex, but can give better performance, and is
+less likely to bounce mail when the machine runs into some resource problem.
+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: 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
+architecture.
+
+    Unfiltered -> smtpd(8)                   qmgr(8)     smtp(8)  -> Filtered
+                            >- cleanup(8) -> Postfix  -<
+    Unfiltered -> pickup(8)                   queue      local(8) -> Filtered
+
+                                     ^            |
+                                     |            v
+
+                                smtpd(8)     smtp(8)
+                                 10026
+
+                                     ^            |
+                                     |            v
+
+                                content filter 10025
+
+The example given here filters all mail, including mail that arrives via SMTP
+and mail that is locally submitted via the Postfix sendmail command (local
+submissions enter Postfix via the pickup(8) server; to keep the figure simple
+we omit local submission details). See examples near the end of this document
+for how to exclude local users from filtering, or how to configure a
+destination dependent content filter.
+
+You can expect to lose about a factor of two in Postfix performance for mail
+that arrives and leaves via SMTP, provided that the content filter creates no
+temporary files. Each temporary file created by the content filter adds another
+factor to the performance loss.
+
+AAddvvaanncceedd ccoonntteenntt ffiilltteerr:: rreeqquueessttiinngg tthhaatt aallll mmaaiill iiss ffiilltteerreedd
+
+To enable the advanced content filter method for all mail, specify in main.cf:
+
+    /etc/postfix/main.cf:
+        content_filter = scan:localhost:10025
+        receive_override_options = no_address_mappings
+
+  * The "receive_override_options" line disables address manipulation before
+    the content filter, so that the content filter sees the original mail
+    addresses instead of the result of virtual alias expansion, canonical
+    mapping, automatic bcc, address masquerading, etc.
+
+  * The "content_filter" line causes Postfix to add one content filter request
+    record to each incoming mail message, with content "scan:localhost:10025".
+    The content filter request records are added by the smtpd(8) and pickup(8)
+    servers (and qmqpd(8) if you decide to enable this service).
+
+  * Content filter requests are stored in queue files; this is how Postfix
+    keeps track of what mail needs filtering. When a queue file contains a
+    content filter request, the queue manager will deliver the mail to the
+    specified content filter regardless of its final destination.
+
+  * The content_filter configuration parameter expects a value of the form
+    transport:destination. 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.
+
+  * The meaning of an empty next-hop filter destination is version dependent.
+    Postfix 2.7 and later will use the recipient domain; earlier versions will
+    use $myhostname. Specify "default_filter_nexthop = $myhostname" for
+    compatibility with Postfix 2.6 or earlier, or specify a non-empty next-hop
+    filter destination.
+
+  * The content_filter setting has lower precedence than a FILTER action that
+    is specified in an access(5), header_checks(5) or body_checks(5) table.
+
+AAddvvaanncceedd ccoonntteenntt ffiilltteerr:: sseennddiinngg uunnffiilltteerreedd mmaaiill ttoo tthhee ccoonntteenntt ffiilltteerr
+
+In this example, "scan" is an instance of the Postfix SMTP client with slightly
+different configuration parameters. This is how one would set up the service in
+the Postfix master.cf file:
+
+    /etc/postfix/master.cf:
+        # =============================================================
+        # service type  private unpriv  chroot  wakeup  maxproc command
+        #               (yes)   (yes)   (yes)   (never) (100)
+        # =============================================================
+        scan      unix  -       -       n       -       10      smtp
+            -o smtp_send_xforward_command=yes
+            -o disable_mime_output_conversion=yes
+            -o smtp_generic_maps=
+
+  * This runs up to 10 content filters in parallel. Instead of a limit of 10
+    concurrent processes, use whatever process limit is feasible for your
+    machine. Content inspection software can gobble up a lot of system
+    resources, so you don't want to have too much of it running at the same
+    time.
+
+  * With "-o smtp_send_xforward_command=yes", the scan transport will try to
+    forward the original client name and IP address through the content filter
+    to the after-filter smtpd process, so that filtered mail is logged with the
+    real client name IP address. See smtp(8) and XFORWARD_README for more
+    information.
+
+  * The "-o disable_mime_output_conversion=yes" is a workaround that prevents
+    the breaking of domainkeys and other digital signatures. This is needed
+    because some SMTP-based content filters don't announce 8BITMIME support,
+    even though they can handle 8-bit mail.
+
+  * The "-o smtp_generic_maps=" is a workaround that prevents local address
+    rewriting with generic(5) maps. Such rewriting should happen only when mail
+    is sent out to the Internet.
+
+AAddvvaanncceedd ccoonntteenntt ffiilltteerr:: rruunnnniinngg tthhee ccoonntteenntt ffiilltteerr
+
+The content filter can be set up with the Postfix spawn service, which is the
+Postfix equivalent of inetd. For example, to instantiate up to 10 content
+filtering processes on localhost port 10025:
+
+    /etc/postfix/master.cf:
+        # ===================================================================
+        # service       type  private unpriv  chroot  wakeup  maxproc command
+        #                     (yes)   (yes)   (yes)   (never) (100)
+        # ===================================================================
+        localhost:10025 inet  n       n       n       -       10      spawn
+            user=filter argv=/path/to/filter localhost 10026
+
+  * "filter" is a dedicated local user account. The user will never log in, and
+    can be given a "*" password and non-existent shell and home directory. This
+    user handles all potentially dangerous mail content - that is why it should
+    be a separate account.
+
+  * By default, Postfix will terminate a command that runs longer than
+    command_time_limit seconds (default: 1000s). This is a safety measure that
+    prevents filters from running forever.
+
+If you want to have your filter listening on port localhost:10025 instead of
+Postfix, then you must run your filter as a stand-alone program, and must not
+use the Postfix spawn service.
+
+AAddvvaanncceedd ffiilltteerr:: iinnjjeeccttiinngg mmaaiill bbaacckk iinnttoo PPoossttffiixx
+
+The job of the content filter is to either bounce mail with a suitable
+diagnostic, or to feed the mail back into Postfix through a dedicated listener
+on port localhost 10026.
+
+The simplest content filter just copies SMTP commands and data between its
+inputs and outputs. If it has a problem, all it has to do is to reply to an
+input of `.' from Postfix with `550 content rejected', and to disconnect
+without sending `.' on the connection that injects mail back into Postfix.
+
+    /etc/postfix/master.cf:
+        # ===================================================================
+        # service       type  private unpriv  chroot  wakeup  maxproc command
+        #                     (yes)   (yes)   (yes)   (never) (100)
+        # ===================================================================
+        localhost:10026 inet  n       -       n       -       10      smtpd
+            -o content_filter=
+            -
+    o
+    receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters
+            -o smtpd_helo_restrictions=
+            -o smtpd_client_restrictions=
+            -o smtpd_sender_restrictions=
+            # Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
+            -o smtpd_relay_restrictions=
+            -o smtpd_recipient_restrictions=permit_mynetworks,reject
+            -o mynetworks=127.0.0.0/8
+            -o smtpd_authorized_xforward_hosts=127.0.0.0/8
+
+  * NOTE: do not use spaces around the "=" or "," characters.
+
+  * NOTE: the SMTP server must not have a smaller process limit than the
+    "filter" master.cf entry.
+
+  * The "-o content_filter=" overrides main.cf settings, and requests no
+    content filtering for mail from the content filter. This is required or
+    else mail will loop.
+
+  * The "-o receive_override_options" overrides main.cf settings to avoid
+    duplicating work that was already done before the content filter. These
+    options are complementary to the options that are specified in main.cf:
+
+      o We specify "no_unknown_recipient_checks" to disable attempts to find
+        out if a recipient is unknown.
+
+      o We specify "no_header_body_checks" to disable header/body checks.
+
+      o We specify "no_milters" to disable Milter applications (this option is
+        available only in Postfix 2.3 and later).
+
+      o We don't specify "no_address_mappings" here. This enables virtual alias
+        expansion, canonical mappings, address masquerading, and other address
+        mappings after the content filter. The main.cf setting of
+        "receive_override_options" disables these mappings before the content
+        filter.
+
+    These receive override options are either implemented by the SMTP server
+    itself, or they are passed on to the cleanup server.
+
+  * The "-o smtpd_xxx_restrictions" and "-o mynetworks=127.0.0.0/8" override
+    main.cf settings. They turn off junk mail controls that would only waste
+    time here.
+
+  * With "-o smtpd_authorized_xforward_hosts=127.0.0.0/8", the scan transport
+    will try to forward the original client name and IP address to the after-
+    filter smtpd process, so that filtered mail is logged with the real client
+    name and IP address. See XFORWARD_README and smtpd(8).
+
+AAddvvaanncceedd ccoonntteenntt ffiilltteerr ppeerrffoorrmmaannccee
+
+With the "sandwich" approach to content filtering described here, it is
+important to match the filter concurrency to the available CPU, memory and I/
+O resources. Too few content filter processes and mail accumulates in the
+active queue even with low traffic volume; too much concurrency and Postfix
+ends up deferring mail destined for the content filter because processes fail
+due to insufficient resources.
+
+Currently, content filter performance tuning is a process of trial and error;
+analysis is handicapped because filtered and unfiltered messages share the same
+queue. As mentioned in the introduction of this document, content filtering
+with multiple Postfix instances will be covered in a future version.
+
+TTuurrnniinngg ooffff tthhee aaddvvaanncceedd ccoonntteenntt ffiilltteerr
+
+To turn off "advanced" content filtering:
+
+  * Delete or comment out the two following main.cf lines. The other changes
+    made for advanced content filtering have no effect when content filtering
+    is turned off.
+
+        /etc/postfix/main.cf:
+            content_filter = scan:localhost:10025
+            receive_override_options = no_address_mappings
+
+  * Execute "ppoossttssuuppeerr --rr AALLLL" to remove content filter request records from
+    existing queue files.
+
+  * Execute another "ppoossttffiixx rreellooaadd".
+
+FFiilltteerriinngg mmaaiill ffrroomm oouuttssiiddee uusseerrss oonnllyy
+
+The easiest approach is to configure ONE Postfix instance with multiple SMTP
+server IP addresses in master.cf:
+
+  * Two SMTP server IP addresses for mail from inside users only, with content
+    filtering turned off.
+
+    /etc/postfix.master.cf:
+        # ==================================================================
+        # service      type  private unpriv  chroot  wakeup  maxproc command
+        #                    (yes)   (yes)   (yes)   (never) (100)
+        # ==================================================================
+        1.2.3.4:smtp   inet  n       -       n       -       -       smtpd
+            -o smtpd_client_restrictions=permit_mynetworks,reject
+        127.0.0.1:smtp inet  n       -       n       -       -       smtpd
+            -o smtpd_client_restrictions=permit_mynetworks,reject
+
+  * One SMTP server address for mail from outside users with content filtering
+    turned on.
+
+    /etc/postfix.master.cf:
+        # =================================================================
+        # service     type  private unpriv  chroot  wakeup  maxproc command
+        #                   (yes)   (yes)   (yes)   (never) (100)
+        # =================================================================
+        1.2.3.5:smtp  inet  n       -       n       -       -       smtpd
+            -o content_filter=filter-service:filter-destination
+            -o receive_override_options=no_address_mappings
+
+After this, you can follow the same procedure as outlined in the "advanced" or
+"simple" content filtering examples above, except that you must not specify
+"content_filter" or "receive_override_options" in the main.cf file.
+
+DDiiffffeerreenntt ffiilltteerrss ffoorr ddiiffffeerreenntt ddoommaaiinnss
+
+If you are an MX service provider and want to apply different content filters
+for different domains, you can configure ONE Postfix instance with multiple
+SMTP server IP addresses in master.cf. Each address provides a different
+content filter service.
+
+    /etc/postfix.master.cf:
+        # =================================================================
+        # service     type  private unpriv  chroot  wakeup  maxproc command
+        #                   (yes)   (yes)   (yes)   (never) (100)
+        # =================================================================
+        # SMTP service for domains that are filtered with service1:dest1
+        1.2.3.4:smtp  inet  n       -       n       -       -       smtpd
+            -o content_filter=service1:dest1
+            -o receive_override_options=no_address_mappings
+
+        # SMTP service for domains that are filtered with service2:dest2
+        1.2.3.5:smtp  inet  n       -       n       -       -       smtpd
+            -o content_filter=service2:dest2
+            -o receive_override_options=no_address_mappings
+
+After this, you can follow the same procedure as outlined in the "advanced" or
+"simple" content filtering examples above, except that you must not specify
+"content_filter" or "receive_override_options" in the main.cf file.
+
+Set up MX records in the DNS that route each domain to the proper SMTP server
+instance.
+
+FFIILLTTEERR aaccttiioonnss iinn aacccceessss oorr hheeaaddeerr//bbooddyy ttaabblleess
+
+The above filtering configurations are static. Mail that follows a given path
+is either always filtered or it is never filtered. As of Postfix 2.0 you can
+also turn on content filtering on the fly.
+
+To turn on content filtering with an access(5) table rule:
+
+    /etc/postfix/access:
+        whatever       FILTER foo:bar
+
+To turn on content filtering with a header_checks(5) or body_checks(5) table
+pattern:
+
+    /etc/postfix/header_checks:
+        /whatever/     FILTER foo:bar
+
+You can do this in smtpd access maps as well as the cleanup server's header/
+body_checks. This feature must be used with great care: you must disable all
+the UCE features in the after-filter smtpd and cleanup daemons or else you will
+have a content filtering loop.
+
+Limitations:
+
+  * FILTER actions from smtpd access maps and header/body_checks take
+    precedence over filters specified with the main.cf content_filter
+    parameter.
+
+  * If a message triggers more than one filter action, only the last one takes
+    effect.
+
+  * The same content filter is applied to all the recipients of a given
+    message.
+
--- a/README_FILES/FORWARD_SECRECY_README
+++ b/README_FILES/FORWARD_SECRECY_README
@ -0,0 +1,480 @@
+ TTLLSS FFoorrwwaarrdd SSeeccrreeccyy iinn PPoossttffiixx
+
+-------------------------------------------------------------------------------
+
+WWaarrnniinngg
+
+Forward secrecy does not protect against active attacks such as forged DNS
+replies or forged TLS server certificates. If such attacks are a concern, then
+the SMTP client will need to authenticate the remote SMTP server in a
+sufficiently-secure manner. For example, by the fingerprint of a (CA or leaf)
+public key or certificate. Conventional PKI relies on many trusted parties and
+is easily subverted by a state-funded adversary.
+
+OOvveerrvviieeww
+
+Postfix supports forward secrecy of TLS network communication since version
+2.2. This support was adopted from Lutz Ja"nicke's "Postfix TLS patch" for
+earlier Postfix versions. This document will focus on TLS Forward Secrecy in
+the Postfix SMTP client and server. See TLS_README for a general description of
+Postfix TLS support.
+
+Topics covered in this document:
+
+  * Give me some background on forward secrecy in Postfix
+
+      o What is Forward Secrecy
+      o Forward Secrecy in TLS
+      o Forward Secrecy in the Postfix SMTP Server
+      o Forward Secrecy in the Postfix SMTP Client
+
+  * Never mind, just show me what it takes to get forward secrecy
+
+      o Getting started, quick and dirty
+      o How can I see that a connection has forward secrecy?
+      o What ciphers provide forward secrecy?
+      o What do "Anonymous", "Untrusted", etc. in Postfix logging mean?
+
+  * Credits
+
+WWhhaatt iiss FFoorrwwaarrdd SSeeccrreeccyy
+
+The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy") is used to
+describe security protocols in which the confidentiality of past traffic is not
+compromised when long-term keys used by either or both sides are later
+disclosed.
+
+Forward secrecy is accomplished by negotiating session keys using per-session
+cryptographically-strong random numbers that are not saved, and signing the
+exchange with long-term authentication keys. Later disclosure of the long-term
+keys allows impersonation of the key holder from that point on, but not
+recovery of prior traffic, since with forward secrecy, the discarded random key
+agreement inputs are not available to the attacker.
+
+Forward secrecy is only "perfect" when brute-force attacks on the key agreement
+algorithm are impractical even for the best-funded adversary and the random-
+number generators used by both parties are sufficiently strong. Otherwise,
+forward secrecy leaves the attacker with the challenge of cracking the key-
+agreement protocol, which is likely quite computationally intensive, but may be
+feasible for sessions of sufficiently high value. Thus forward secrecy places
+cost constraints on the efficacy of bulk surveillance, recovering all past
+traffic is generally infeasible, and even recovery of individual sessions may
+be infeasible given a sufficiently-strong key agreement method.
+
+FFoorrwwaarrdd SSeeccrreeccyy iinn TTLLSS
+
+Early implementations of the SSL protocol do not provide forward secrecy (some
+provide it only with artificially-weakened "export" cipher suites, but we will
+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.
+
+Later revisions to the TLS protocol introduced forward-secrecy cipher suites in
+which the client and server implement a key exchange protocol based on
+ephemeral secrets. Sessions encrypted with one of these newer cipher suites are
+not compromised by future disclosure of long-term authentication keys.
+
+The key-exchange algorithms used for forward secrecy require the TLS server to
+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:
+
+  * 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.
+
+  * 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
+
+The Postfix >= 2.2 SMTP server supports forward secrecy in its default
+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.
+
+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".
+
+FFFFDDHHEE SSeerrvveerr ssuuppppoorrtt
+
+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.
+
+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
+
+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 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. Forward secrecy is always on in
+TLS 1.3.
+
+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.
+
+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 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 >>== 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 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 >>== 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 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.
+
+FFFFDDHHEE CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 33..22,, OOppeennSSSSLL >>== 11..11..11))
+
+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.
+
+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.
+
+FFFFDDHHEE SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss))
+
+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.
+
+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 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??
+
+Postfix can be configured to report information about the negotiated cipher,
+the corresponding key lengths, and the remote peer certificate or public-key
+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 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
+        (actual-key-size/raw-key-size bits)
+
+        postfix/smtpd[process-id]: Anonymous TLS connection established
+        from host.example.com[192.168.0.2]: TLSv1 with cipher cipher-name
+        (actual-key-size/raw-key-size bits)
+
+  * 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. 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
+                (actual-key-size/raw-key-size bits))
+                (Client CN "host.example.com", Issuer "John Doe" (not
+        verified))
+
+        Received: from host.example.com (host.example.com [192.168.0.2])
+                (using TLSv1 with cipher cipher-name
+                (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.
+
+WWhhaatt cciipphheerrss pprroovviiddee ffoorrwwaarrdd sseeccrreeccyy??
+
+There are dozens of ciphers that support forward secrecy. What follows is the
+beginning of a list of 51 ciphers available with OpenSSL 1.0.1e. The list is
+sorted in the default Postfix preference order. It excludes null ciphers that
+only authenticate and don't encrypt, together with export and low-grade ciphers
+whose encryption is too weak to offer meaningful secrecy. The first column
+shows the cipher name, and the second shows the key exchange method.
+
+    $ openssl ciphers -v \
+            'aNULL:-aNULL:kEECDH:kEDH:+RC4:!eNULL:!EXPORT:!LOW:@STRENGTH' |
+        awk '{printf "%-32s %s\n", $1, $3}'
+    AECDH-AES256-SHA                 Kx=ECDH
+    ECDHE-RSA-AES256-GCM-SHA384      Kx=ECDH
+    ECDHE-ECDSA-AES256-GCM-SHA384    Kx=ECDH
+    ECDHE-RSA-AES256-SHA384          Kx=ECDH
+    ECDHE-ECDSA-AES256-SHA384        Kx=ECDH
+    ECDHE-RSA-AES256-SHA             Kx=ECDH
+    ECDHE-ECDSA-AES256-SHA           Kx=ECDH
+    ADH-AES256-GCM-SHA384            Kx=DH
+    ADH-AES256-SHA256                Kx=DH
+    ADH-AES256-SHA                   Kx=DH
+    ADH-CAMELLIA256-SHA              Kx=DH
+    DHE-DSS-AES256-GCM-SHA384        Kx=DH
+    DHE-RSA-AES256-GCM-SHA384        Kx=DH
+    DHE-RSA-AES256-SHA256            Kx=DH
+    ...
+
+To date, all ciphers that support forward secrecy have one of five values for
+the first component of their OpenSSL name: "AECDH", "ECDHE", "ADH", "EDH" or
+"DHE". Ciphers that don't implement forward secrecy have names that don't start
+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 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
+different degrees. If such attacks are a concern, then the SMTP client will
+need to authenticate the remote SMTP server in a sufficiently-secure manner.
+For example, by the fingerprint of a (CA or leaf) public key or certificate.
+Remember that conventional PKI relies on many trusted parties and is easily
+subverted by a state-funded adversary.
+
+AAnnoonnyymmoouuss (no peer certificate)
+    PPoossttffiixx SSMMTTPP cclliieenntt:: With opportunistic TLS (the "may" security level) the
+    Postfix SMTP client does not verify any information in the peer
+    certificate. In this case it enables and prefers anonymous cipher suites in
+    which the remote SMTP server does not present a certificate (these ciphers
+    offer forward secrecy of necessity). When the remote SMTP server also
+    supports anonymous TLS, and agrees to such a cipher suite, the verification
+    status will be logged as "Anonymous".
+
+    PPoossttffiixx SSMMTTPP sseerrvveerr:: This is by far most common, as client certificates are
+    optional, and the Postfix SMTP server does not request client certificates
+    by default (see smtpd_tls_ask_ccert). Even when client certificates are
+    requested, the remote SMTP client might not send a certificate. Unlike the
+    Postfix SMTP client, the Postfix SMTP server "anonymous" verification
+    status does not imply that the cipher suite is anonymous, which corresponds
+    to the server not sending a certificate.
+
+UUnnttrruusstteedd (peer certificate not signed by trusted CA)
+    PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server presented a certificate, but
+    the Postfix SMTP client was unable to check the issuing CA signature. With
+    opportunistic TLS this is common with remote SMTP servers that don't
+    support anonymous cipher suites.
+
+    PPoossttffiixx SSMMTTPP sseerrvveerr:: The remote SMTP client presented a certificate, but
+    the Postfix SMTP server was unable to check the issuing CA signature. This
+    can happen when the server is configured to request client certificates
+    (see smtpd_tls_ask_ccert).
+
+TTrruusstteedd (peer certificate signed by trusted CA, unverified peer name)
+    PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server's certificate was signed by a
+    CA that the Postfix SMTP client trusts, but either the client was not
+    configured to verify the destination server name against the certificate,
+    or the server certificate did not contain any matching names. This is
+    common with opportunistic TLS (smtp_tls_security_level is "may" or else
+    "dane" with no usable TLSA DNS records) when the Postfix SMTP client's
+    trusted CAs can verify the authenticity of the remote SMTP server's
+    certificate, but the client is not configured or unable to verify the
+    server name.
+
+    PPoossttffiixx SSMMTTPP sseerrvveerr:: The remote SMTP client certificate was signed by a CA
+    that the Postfix SMTP server trusts. The Postfix SMTP server never verifies
+    the remote SMTP client name against the names in the client certificate.
+    Since the client chooses to connect to the server, the Postfix SMTP server
+    has no expectation of a particular client hostname.
+
+VVeerriiffiieedd (peer certificate signed by trusted CA and verified peer name; or:
+peer certificate with expected public-key or certificate fingerprint)
+    PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server's certificate was signed by a
+    CA that the Postfix SMTP client trusts, and the certificate name matches
+    the destination or server name(s). The Postfix SMTP client was configured
+    to require a verified name, otherwise the verification status would have
+    been just "Trusted".
+
+    PPoossttffiixx SSMMTTPP cclliieenntt:: The "Verified" status may also mean that the Postfix
+    SMTP client successfully matched the expected fingerprint against the
+    remote SMTP server public key or certificate. The expected fingerprint may
+    come from smtp_tls_policy_maps or from TLSA (secure) DNS records. The
+    Postfix SMTP client ignores the CA signature.
+
+    PPoossttffiixx SSMMTTPP sseerrvveerr:: The status is never "Verified", because the Postfix
+    SMTP server never verifies the remote SMTP client name against the names in
+    the client certificate, and because the Postfix SMTP server does not expect
+    a specific fingerprint in the client public key or certificate.
+
+CCrreeddiittss
+
+  * TLS support for Postfix was originally developed by Lutz Ja"nicke at
+    Cottbus Technical University.
+  * Wietse Venema adopted and restructured the code and documentation.
+  * Viktor Dukhovni implemented support for many subsequent TLS features,
+    including EECDH, and authored the initial version of this document.
+
--- a/README_FILES/INSTALL
+++ b/README_FILES/INSTALL
--- a/README_FILES/IPV6_README
+++ b/README_FILES/IPV6_README
@ -0,0 +1,250 @@
+PPoossttffiixx IIPPvv66 SSuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix 2.2 introduces support for the IPv6 (IP version 6) protocol. IPv6
+support for older Postfix versions was available as an add-on patch. The
+section "Compatibility with Postfix <2.2 IPv6 support" below discusses the
+differences between these implementations.
+
+The main feature of interest is that IPv6 uses 128-bit IP addresses instead of
+the 32-bit addresses used by IPv4. It can therefore accommodate a much larger
+number of hosts and networks without ugly kluges such as NAT. A side benefit of
+the much larger address space is that it makes random network scanning
+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.
+
+This document provides information on the following topics:
+
+  * Supported platforms
+  * Configuration
+  * Known limitations
+  * Compatibility with Postfix <2.2 IPv6 support
+  * IPv6 Support for unsupported platforms
+  * Credits
+
+SSuuppppoorrtteedd PPllaattffoorrmmss
+
+Postfix version 2.2 supports IPv4 and IPv6 on the following platforms:
+
+  * AIX 5.1+
+  * Darwin 7.3+
+  * FreeBSD 4+
+  * Linux 2.4+
+  * NetBSD 1.5+
+  * OpenBSD 2+
+  * Solaris 8+
+  * Tru64Unix V5.1+
+
+On other platforms Postfix will simply use IPv4 as it has always done.
+
+See "IPv6 Support for unsupported platforms" for tips to port Postfix IPv6
+support to other environments.
+
+CCoonnffiigguurraattiioonn
+
+Postfix IPv6 support introduces two new main.cf configuration parameters, and
+introduces an important change in address syntax notation in match lists such
+as mynetworks or debug_peer_list.
+
+Postfix IPv6 address syntax is a little tricky, because there are a few places
+where you must enclose an IPv6 address inside "[]" characters, and a few places
+where you must not. It is a good idea to use "[]" only in the few places where
+you have to. Check out the postconf(5) manual whenever you do IPv6 related
+configuration work with Postfix.
+
+  * Instead of hard-coding 127.0.0.1 and ::1 loopback addresses in master.cf,
+    specify "inet_interfaces = loopback-only" in main.cf. This way you can use
+    the same master.cf file regardless of whether or not Postfix will run on an
+    IPv6-enabled system.
+
+  * The first new parameter is called inet_protocols. This specifies what
+    protocols Postfix will use when it makes or accepts network connections,
+    and also controls what DNS lookups Postfix will use when it makes network
+    connections.
+
+        /etc/postfix/main.cf:
+            # You must stop/start Postfix after changing this parameter.
+            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)
+
+    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: on older Linux and Solaris systems, the setting "inet_protocols =
+    ipv6" will not prevent Postfix from accepting IPv4 connections.
+
+    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
+    smtp_bind_address parameter does for IPv4:
+
+        /etc/postfix/main.cf:
+            smtp_bind_address6 = 2001:240:587:0:250:56ff:fe89:1
+
+  * If you left the value of the mynetworks parameter at its default (i.e. no
+    mynetworks setting in main.cf) Postfix will figure out by itself what its
+    network addresses are. This is what a typical setting looks like:
+
+        % postconf mynetworks
+        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 to
+    update the mynetworks value to include the IPv6 networks the system is in.
+    Be sure to specify IPv6 address information inside "[]", like this:
+
+        /etc/postfix/main.cf:
+            mynetworks = ...IPv4 networks... [::1]/128 [2001:240:587::]/64 ...
+
+NNOOTTEE:: wwhheenn ccoonnffiigguurriinngg PPoossttffiixx mmaattcchh lliissttss ssuucchh aass mmyynneettwwoorrkkss oorr
+ddeebbuugg__ppeeeerr__lliisstt,, yyoouu mmuusstt ssppeecciiffyy IIPPvv66 aaddddrreessss iinnffoorrmmaattiioonn iinnssiiddee ""[[]]"" iinn tthhee
+mmaaiinn..ccff ppaarraammeetteerr vvaalluuee aanndd iinn ffiilleess ssppeecciiffiieedd wwiitthh aa ""//ffiillee//nnaammee"" ppaatttteerrnn..
+IIPPvv66 aaddddrreesssseess ccoonnttaaiinn tthhee ""::"" cchhaarraacctteerr,, aanndd wwoouulldd ootthheerrwwiissee bbee ccoonnffuusseedd wwiitthh
+aa ""ttyyppee::ttaabbllee"" ppaatttteerrnn..
+
+KKnnoowwnn LLiimmiittaattiioonnss
+
+  * Postfix SMTP clients before version 2.8 try to connect over IPv6 before
+    trying IPv4. With more recent Postfix versions, the order of IPv6 versus
+    IPv4 outgoing connection attempts is configurable with the
+    smtp_address_preference parameter.
+
+  * 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
+    "mynetworks_style = subnet".
+
+  * On Tru64Unix and AIX, Postfix can't figure out the local subnet mask and
+    always assumes a /128 network. This is a problem only with
+    "mynetworks_style = subnet" and no explicit mynetworks setting in main.cf.
+
+CCoommppaattiibbiilliittyy wwiitthh PPoossttffiixx <<22..22 IIPPvv66 ssuuppppoorrtt
+
+Postfix version 2.2 IPv6 support is based on the Postfix/IPv6 patch by Dean
+Strik and others, but differs in a few minor ways.
+
+  * main.cf: The inet_interfaces parameter does not support the notation "ipv6:
+    all" or "ipv4:all". Use the inet_protocols parameter instead.
+
+  * main.cf: Specify "inet_protocols = all" or "inet_protocols = ipv4, ipv6" in
+    order to enable both IPv4 and IPv6 support.
+
+  * main.cf: The inet_protocols parameter also controls what DNS lookups
+    Postfix will attempt to make when delivering or receiving mail.
+
+  * 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. 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
+    specified as [ipv6:ipv6address], as described in RFC 2821.
+
+  * The IPv6 network address matching code was rewritten from the ground up,
+    and is expected to be closer to the specification. The result may be
+    incompatible with the Postfix/IPv6 patch.
+
+IIPPvv66 SSuuppppoorrtt ffoorr uunnssuuppppoorrtteedd ppllaattffoorrmmss
+
+Getting Postfix IPv6 working on other platforms involves the following steps:
+
+  * Specify how Postfix should find the local network interfaces. Postfix needs
+    this information to avoid mailer loops and to find out if mail for user@
+    [ipaddress] is a local or remote destination.
+
+    If your system has the getifaddrs() routine then add the following to your
+    platform-specific section in src/util/sys_defs.h:
+
+        #ifndef NO_IPV6
+        # define HAS_IPV6
+        # define HAVE_GETIFADDRS
+        #endif
+
+    Otherwise, if your system has the SIOCGLIF ioctl() command in /usr/include/
+    */*.h, add the following to your platform-specific section in src/util/
+    sys_defs.h:
+
+        #ifndef NO_IPV6
+        # define HAS_IPV6
+        # define HAS_SIOCGLIF
+        #endif
+
+    Otherwise, Postfix will have to use the old SIOCGIF commands and get along
+    with reduced IPv6 functionality (it won't be able to figure out your IPv6
+    netmasks, which are needed for "mynetworks_style = subnet". Add this to
+    your platform-specific section in src/util/sys_defs.h:
+
+        #ifndef NO_IPV6
+        # define HAS_IPV6
+        #endif
+
+  * Test if Postfix can figure out its interface information.
+
+    After compiling Postfix in the usual manner, step into the src/util
+    directory and type "mmaakkee iinneett__aaddddrr__llooccaall". Running this file by hand should
+    produce all the interface addresses and network masks, for example:
+
+        % make
+        % cd src/util
+        % make inet_addr_local
+        [... some messages ...]
+        % ./inet_addr_local
+        [... some messages ...]
+        ./inet_addr_local: inet_addr_local: configured 2 IPv4 addresses
+        ./inet_addr_local: inet_addr_local: configured 4 IPv6 addresses
+        168.100.189.2/255.255.255.224
+        127.0.0.1/255.0.0.0
+        fe80:1::2d0:b7ff:fe88:2ca7/ffff:ffff:ffff:ffff::
+        2001:240:587:0:2d0:b7ff:fe88:2ca7/ffff:ffff:ffff:ffff::
+        fe80:5::1/ffff:ffff:ffff:ffff::
+        ::1/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
+
+    The above is for an old FreeBSD machine. Other systems produce slightly
+    different results, but you get the idea.
+
+If none of all this produces a usable result, send email to the postfix-
+users@postfix.org mailing list and we'll try to help you through this.
+
+CCrreeddiittss
+
+The following information is in part based on information that was compiled by
+Dean Strik.
+
+  * Mark Huizer wrote the original Postfix IPv6 patch.
+
+  * Jun-ichiro 'itojun' Hagino of the KAME project made substantial
+    improvements. Since then, we speak of the KAME patch.
+
+  * The PLD Linux Distribution ported the code to other stacks (notably USAGI).
+    We speak of the PLD patch. A very important feature of the PLD patch was
+    that it can work with Lutz Jaenicke's TLS patch for Postfix.
+
+  * 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 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
+    could be removed. For systems without IPv6 support in the kernel and system
+    libraries, Postfix has a simple compatibility layer, so that it will use
+    IPv4 as before.
+
--- a/README_FILES/LDAP_README
+++ b/README_FILES/LDAP_README
@ -0,0 +1,467 @@
+s!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" "https://
+www.w3.org/TR/html4/loose.dtd">
+
+PPoossttffiixx LLDDAAPP HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+LLDDAAPP SSuuppppoorrtt iinn PPoossttffiixx
+
+Postfix can use an LDAP directory 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 network 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 LDAP support
+  * Configuring LDAP lookups
+  * Example: aliases
+  * Example: virtual domains/addresses
+  * Example: expanding LDAP groups
+  * Other uses of LDAP lookups
+  * Notes and things to think about
+  * Feedback
+  * Credits
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh LLDDAAPP 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.
+
+Note 1: Postfix no longer supports the LDAP version 1 interface.
+
+Note 2: to use LDAP with Debian GNU/Linux's Postfix, all you need is to install
+the postfix-ldap package and you're done. There is no need to recompile
+Postfix.
+
+You need to have LDAP libraries and include files installed somewhere on your
+system, and you need to configure the Postfix Makefiles accordingly.
+
+For example, to build the OpenLDAP libraries for use with Postfix (i.e. LDAP
+client code only), you could use the following command:
+
+    % ./configure  --without-kerberos --without-cyrus-sasl --without-tls \
+        --without-threads --disable-slapd --disable-slurpd \
+        --disable-debug --disable-shared
+
+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
+building a dynamically-loaded or statically-loaded LDAP database client.
+
+    Failure to use the AUXLIBS_LDAP variable will defeat the purpose of dynamic
+    database client loading. Every Postfix executable file will have LDAP
+    database library dependencies. And that was exactly what dynamic database
+    client loading was meant to avoid.
+
+On Solaris 2.x you may have to specify run-time link information, otherwise
+ld.so will not find some of the shared libraries:
+
+    % make tidy
+    % make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \
+        AUXLIBS_LDAP="-L/usr/local/lib -R/usr/local/lib -lldap \
+                -L/usr/local/lib -R/usr/local/lib -llber"
+
+The 'make tidy' command is needed only if you have previously built Postfix
+without LDAP support.
+
+Instead of '/usr/local' specify the actual locations of your LDAP include files
+and libraries. Be sure to not mix LDAP include files and LDAP libraries of
+different versions!!
+
+If your LDAP libraries were built with Kerberos support, you'll also need to
+include your Kerberos libraries in this line. Note that the KTH Kerberos IV
+libraries might conflict with Postfix's lib/libdns.a, which defines dns_lookup.
+If that happens, you'll probably want to link with LDAP libraries that lack
+Kerberos support just to build Postfix, as it doesn't support Kerberos binds to
+the LDAP server anyway. Sorry about the bother.
+
+If you're using one of the Netscape LDAP SDKs, you'll need to change the
+AUXLIBS line to point to libldap10.so or libldapssl30.so or whatever you have,
+and you may need to use the appropriate linker option (e.g. '-R') so the
+executables can find it at runtime.
+
+If you are using OpenLDAP, and the libraries were built with SASL support, you
+can add -DUSE_LDAP_SASL to the CCARGS to enable SASL support. For example:
+
+         CCARGS="-I/usr/local/include -DHAS_LDAP -DUSE_LDAP_SASL"
+
+CCoonnffiigguurriinngg LLDDAAPP llooookkuuppss
+
+In order to use LDAP lookups, define an LDAP source as a table lookup in
+main.cf, for example:
+
+    alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
+
+The file /etc/postfix/ldap-aliases.cf can specify a great number of parameters,
+including parameters that enable LDAP SSL or STARTTLS, and LDAP SASL. For a
+complete description, see the ldap_table(5) manual page.
+
+EExxaammppllee:: llooccaall((88)) aalliiaasseess
+
+Here's a basic example for using LDAP to look up local(8) aliases. Assume that
+in main.cf, you have:
+
+    alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
+
+and in ldap:/etc/postfix/ldap-aliases.cf you have:
+
+    server_host = ldap.example.com
+    search_base = dc=example, dc=com
+
+Upon receiving mail for a local address "ldapuser" that isn't found in the /
+etc/aliases database, Postfix will search the LDAP server listening at port 389
+on ldap.example.com. It will bind anonymously, search for any directory entries
+whose mailacceptinggeneralid attribute is "ldapuser", read the "maildrop"
+attributes of those found, and build a list of their maildrops, which will be
+treated as RFC822 addresses to which the message will be delivered.
+
+EExxaammppllee:: vviirrttuuaall ddoommaaiinnss//aaddddrreesssseess
+
+If you want to keep information for virtual lookups in your directory, it's
+only a little more complicated. First, you need to make sure Postfix knows
+about the virtual domain. An easy way to do that is to add the domain to the
+mailacceptinggeneralid attribute of some entry in the directory. Next, you'll
+want to make sure all of your virtual recipient's mailacceptinggeneralid
+attributes are fully qualified with their virtual domains. Finally, if you want
+to designate a directory entry as the default user for a virtual domain, just
+give it an additional mailacceptinggeneralid (or the equivalent in your
+directory) of "@fake.dom". That's right, no user part. If you don't want a
+catchall user, omit this step and mail to unknown users in the domain will
+simply bounce.
+
+In summary, you might have a catchall user for a virtual domain that looks like
+this:
+
+         dn: cn=defaultrecipient, dc=fake, dc=dom
+         objectclass: top
+         objectclass: virtualaccount
+         cn: defaultrecipient
+         owner: uid=root, dc=someserver, dc=isp, dc=dom
+    1 -> mailacceptinggeneralid: fake.dom
+    2 -> mailacceptinggeneralid: @fake.dom
+    3 -> maildrop: realuser@real.dom
+
+    1: Postfix knows fake.dom is a valid virtual domain when it looks for this
+    and gets something (the maildrop) back.
+
+    2: This causes any mail for unknown users in fake.dom to go to this entry
+    ...
+
+    3: ... and then to its maildrop.
+
+Normal users might simply have one mailacceptinggeneralid and maildrop, e.g.
+"normaluser@fake.dom" and "normaluser@real.dom".
+
+EExxaammppllee:: eexxppaannddiinngg LLDDAAPP ggrroouuppss
+
+LDAP is frequently used to store group member information. There are a number
+of ways of handling LDAP groups. We will show a few examples in order of
+increasing complexity, but owing to the number of independent variables, we can
+only present a tiny portion of the solution space. We show how to:
+
+ 1. query groups as lists of addresses;
+
+ 2. query groups as lists of user objects containing addresses;
+
+ 3. forward special lists unexpanded to a separate list server, for moderation
+    or other processing;
+
+ 4. handle complex schemas by controlling expansion and by treating leaf nodes
+    specially, using features that are new in Postfix 2.4.
+
+The example LDAP entries and implied schema below show two group entries
+("agroup" and "bgroup") and four user entries ("auser", "buser", "cuser" and
+"duser"). The group "agroup" has the users "auser" (1) and "buser" (2) as
+members via DN references in the multi-valued attribute "memberdn", and direct
+email addresses of two external users "auser@example.org" (3) and
+"buser@example.org" (4) stored in the multi-valued attribute "memberaddr". The
+same is true of "bgroup" and "cuser"/"duser" (6)/(7)/(8)/(9), but "bgroup" also
+has a "maildrop" attribute of "bgroup@mlm.example.com" (5):
+
+         dn: cn=agroup, dc=example, dc=com
+         objectclass: top
+         objectclass: ldapgroup
+         cn: agroup
+         mail: agroup@example.com
+    1 -> memberdn: uid=auser, dc=example, dc=com
+    2 -> memberdn: uid=buser, dc=example, dc=com
+    3 -> memberaddr: auser@example.org
+    4 -> memberaddr: buser@example.org
+
+         dn: cn=bgroup, dc=example, dc=com
+         objectclass: top
+         objectclass: ldapgroup
+         cn: bgroup
+         mail: bgroup@example.com
+    5 -> maildrop: bgroup@mlm.example.com
+    6 -> memberdn: uid=cuser, dc=example, dc=com
+    7 -> memberdn: uid=duser, dc=example, dc=com
+    8 -> memberaddr: cuser@example.org
+    9 -> memberaddr: duser@example.org
+
+         dn: uid=auser, dc=example, dc=com
+         objectclass: top
+         objectclass: ldapuser
+         uid: auser
+    10 -> mail: auser@example.com
+    11 -> maildrop: auser@mailhub.example.com
+
+         dn: uid=buser, dc=example, dc=com
+         objectclass: top
+         objectclass: ldapuser
+         uid: buser
+    12 -> mail: buser@example.com
+    13 -> maildrop: buser@mailhub.example.com
+
+         dn: uid=cuser, dc=example, dc=com
+         objectclass: top
+         objectclass: ldapuser
+         uid: cuser
+    14 -> mail: cuser@example.com
+
+         dn: uid=duser, dc=example, dc=com
+         objectclass: top
+         objectclass: ldapuser
+         uid: duser
+    15 -> mail: duser@example.com
+
+Our first use case ignores the "memberdn" attributes, and assumes that groups
+hold only direct "memberaddr" strings as in (3), (4), (8) and (9). The goal is
+to map the group address to the list of constituent "memberaddr" values. This
+is simple, ignoring the various connection related settings (hosts, ports, bind
+settings, timeouts, ...) we have:
+
+        simple.cf:
+            ...
+            search_base = dc=example, dc=com
+            query_filter = mail=%s
+            result_attribute = memberaddr
+        $ postmap -q agroup@example.com ldap:/etc/postfix/simple.cf \
+            auser@example.org,buser@example.org
+
+We search "dc=example, dc=com". The "mail" attribute is used in the
+query_filter to locate the right group, the "result_attribute" setting
+described in ldap_table(5) is used to specify that "memberaddr" values from the
+matching group are to be returned as a comma separated list. Always check
+tables using postmap(1) with the "-q" option, before deploying them into
+production use in main.cf.
+
+Our second use case instead expands "memberdn" attributes (1), (2), (6) and
+(7), follows the DN references and returns the "maildrop" of the referenced
+user entries. Here we use the "special_result_attribute" setting from
+ldap_table(5) to designate the "memberdn" attribute as holding DNs of the
+desired member entries. The "result_attribute" setting selects which attributes
+are returned from the selected DNs. It is important to choose a result
+attribute that is not also present in the group object, because result
+attributes are collected from both the group and the member DNs. In this case
+we choose "maildrop" and assume for the moment that groups never have a
+"maildrop" (the "bgroup" "maildrop" attribute is for a different use case). The
+returned data for "auser" and "buser" is from items (11) and (13) in the
+example data.
+
+        special.cf:
+            ...
+            search_base = dc=example, dc=com
+            query_filter = mail=%s
+            result_attribute = maildrop
+            special_result_attribute = memberdn
+        $ postmap -q agroup@example.com ldap:/etc/postfix/special.cf \
+            auser@mailhub.example.com,buser@mailhub.example.com
+
+Note: if the desired member object result attribute is always also present in
+the group, you get surprising results: the expansion also returns the address
+of the group. This is a known limitation of Postfix releases prior to 2.4, and
+is addressed in the new with Postfix 2.4 "leaf_result_attribute" feature
+described in ldap_table(5).
+
+Our third use case has some groups that are expanded immediately, and other
+groups that are forwarded to a dedicated mailing list manager host for delayed
+expansion. This uses two LDAP tables, one for users and forwarded groups and a
+second for groups that can be expanded immediately. It is assumed that groups
+that require forwarding are never nested members of groups that are directly
+expanded.
+
+        no_expand.cf:
+            ...
+            search_base = dc=example, dc=com
+            query_filter = mail=%s
+            result_attribute = maildrop
+        expand.cf
+            ...
+            search_base = dc=example, dc=com
+            query_filter = mail=%s
+            result_attribute = maildrop
+            special_result_attribute = memberdn
+        $ postmap -q auser@example.com \
+            ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
+            auser@mailhub.example.com
+        $ postmap -q agroup@example.com \
+            ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
+            auser@mailhub.example.com,buser@mailhub.example.com
+        $ postmap -q bgroup@example.com \
+            ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
+            bgroup@mlm.example.com
+
+Non-group objects and groups with delayed expansion (those that have a maildrop
+attribute) are rewritten to a single maildrop value. Groups that don't have a
+maildrop are expanded as the second use case. This admits a more elegant
+solution with Postfix 2.4 and later.
+
+Our final use case is the same as the third, but this time uses new features in
+Postfix 2.4. We now are able to use just one LDAP table and no longer need to
+assume that forwarded groups are never nested inside expanded groups.
+
+        fancy.cf:
+            ...
+            search_base = dc=example, dc=com
+            query_filter = mail=%s
+            result_attribute = memberaddr
+            special_result_attribute = memberdn
+            terminal_result_attribute = maildrop
+            leaf_result_attribute = mail
+        $ postmap -q auser@example.com ldap:/etc/postfix/fancy.cf \
+            auser@mailhub.example.com
+        $ postmap -q cuser@example.com ldap:/etc/postfix/fancy.cf \
+            cuser@example.com
+        $ postmap -q agroup@example.com ldap:/etc/postfix/fancy.cf \
+
+    auser@mailhub.example.com,buser@mailhub.example.com,auser@example.org,buser@example.org
+        $ postmap -q bgroup@example.com ldap:/etc/postfix/fancy.cf \
+            bgroup@mlm.example.com
+
+Above, delayed expansion is enabled via "terminal_result_attribute", which, if
+present, is used as the sole result and all other expansion is suppressed.
+Otherwise, the "leaf_result_attribute" is only returned for leaf objects that
+don't have a "special_result_attribute" (non-groups), while the
+"result_attribute" (direct member address of groups) is returned at every level
+of recursive expansion, not just the leaf nodes. This fancy example illustrates
+all the features of Postfix 2.4 group expansion.
+
+OOtthheerr uusseess ooff LLDDAAPP llooookkuuppss
+
+Other common uses for LDAP lookups include rewriting senders and recipients
+with Postfix's canonical lookups, for example in order to make mail leaving
+your site appear to be coming from "First.Last@example.com" instead of
+"userid@example.com".
+
+NNootteess aanndd tthhiinnggss ttoo tthhiinnkk aabboouutt
+
+  * The bits of schema and attribute names used in this document are just
+    examples. There's nothing special about them, other than that some are the
+    defaults in the LDAP configuration parameters. You can use whatever schema
+    you like, and configure Postfix accordingly.
+
+  * You probably want to make sure that mailacceptinggeneralids are unique, and
+    that not just anyone can specify theirs as postmaster or root, say.
+
+  * An entry can have an arbitrary number of mailacceptinggeneralids or
+    maildrops. Maildrops can also be comma-separated lists of addresses. They
+    will all be found and returned by the lookups. For example, you could
+    define an entry intended for use as a mailing list that looks like this
+    (Warning! Schema made up just for this example):
+
+        dn: cn=Accounting Staff List, dc=example, dc=com
+        cn: Accounting Staff List
+        o: example.com
+        objectclass: maillist
+        mailacceptinggeneralid: accountingstaff
+        mailacceptinggeneralid: accounting-staff
+        maildrop: mylist-owner
+        maildrop: an-accountant
+        maildrop: some-other-accountant
+        maildrop: this, that, theother
+
+  * If you use an LDAP map for lookups other than aliases, you may have to make
+    sure the lookup makes sense. In the case of virtual lookups, maildrops
+    other than mail addresses are pretty useless, because Postfix can't know
+    how to set the ownership for program or file delivery. Your qquueerryy__ffiilltteerr
+    should probably look something like this:
+
+        query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")
+        (maildrop="*:*")(maildrop="*/*"))))
+
+  * 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
+    stuff only for directory entries owned by an administrative account, so
+    that if the object had a program as its maildrop and weren't owned by
+    "cn=root" it wouldn't be returned as a valid local user. This will require
+    some thought on your part to implement safely, considering the
+    ramifications of this type of delivery. You may decide it's not worth the
+    bother to allow any of that nonsense in LDAP lookups, ban it in the
+    qquueerryy__ffiilltteerr, and keep things like majordomo lists in local alias
+    databases.
+
+        query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")
+        (maildrop="*:*")(maildrop="*/*"))(owner=cn=root, dc=your, dc=com)))
+
+  * LDAP lookups are slower than local DB or DBM lookups. For most sites they
+    won't be a bottleneck, but it's a good idea to know how to tune your
+    directory service.
+
+  * Multiple LDAP maps share the same LDAP connection if they differ only in
+    their query related parameters: base, scope, query_filter, and so on. To
+    take advantage of this, avoid spurious differences in the definitions of
+    LDAP maps: host selection order, version, bind, tls parameters, ... should
+    be the same for multiple maps whenever possible.
+
+FFeeeeddbbaacckk
+
+If you have questions, send them to postfix-users@postfix.org. Please include
+relevant information about your Postfix setup: LDAP-related output from
+postconf, which LDAP libraries you built with, and which directory server
+you're using. If your question involves your directory contents, please include
+the applicable bits of some directory entries.
+
+CCrreeddiittss
+
+  * Manuel Guesdon: Spotted a bug with the timeout attribute.
+  * John Hensley: Multiple LDAP sources with more configurable attributes.
+  * Carsten Hoeger: Search scope handling.
+  * LaMont Jones: Domain restriction, URL and DN searches, multiple result
+    attributes.
+  * Mike Mattice: Alias dereferencing control.
+  * Hery Rakotoarisoa: Patches for LDAPv3 updating.
+  * Prabhat K Singh: Wrote the initial Postfix LDAP lookups and connection
+    caching.
+  * Keith Stevenson: RFC 2254 escaping in queries.
+  * Samuel Tardieu: Noticed that searches could include wildcards, prompting
+    the work on RFC 2254 escaping in queries. Spotted a bug in binding.
+  * Sami Haahtinen: Referral chasing and v3 support.
+  * Victor Duchovni: ldap_bind() timeout. With fixes from LaMont Jones:
+    OpenLDAP cache deprecation. Limits on recursion, expansion and search
+    results size. LDAP connection sharing for maps differing only in the query
+    parameters.
+  * Liviu Daia: Support for SSL/STARTTLS. Support for storing map definitions
+    in external files (ldap:/path/ldap.cf) needed to securely store passwords
+    for plain auth.
+  * Liviu Daia revised the configuration interface and added the main.cf
+    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.
+  * Gunnar Wrobel provided a first implementation of a feature to limit LDAP
+    search results to leaf nodes only. Victor generalized this into the Postfix
+    2.4 "leaf_result_attribute" feature.
+  * Quanah Gibson-Mount contributed support for advanced LDAP SASL mechanisms,
+    beyond the password-based LDAP "simple" bind.
+
+And of course Wietse.
+
--- a/README_FILES/LINUX_README
+++ b/README_FILES/LINUX_README
@ -0,0 +1,74 @@
+PPoossttffiixx aanndd LLiinnuuxx
+
+-------------------------------------------------------------------------------
+
+HHoosstt llooookkuupp iissssuueess
+
+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 this, turn on support for multiple IP
+addresses:
+
+    /etc/host.conf:
+        ...
+        # We have machines with multiple IP addresses.
+        multi on
+        ...
+
+Alternatively, specify the RESOLV_MULTI environment variable in main.cf:
+
+    /etc/postfix/main.cf:
+        import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY
+    DISPLAY LANG=C RESOLV_MULTI=on
+
+BBeerrkkeelleeyy DDBB iissssuueess
+
+If you can't compile Postfix because the file "db.h" isn't found, then you MUST
+install the Berkeley DB development package (name: db???-devel-???) that
+matches your system library. You can find out what is installed with the rpm
+command. For example:
+
+    $ rrppmm --qqff //uussrr//lliibb//lliibbddbb..ssoo
+    db4-4.3.29-2
+
+This means that you need to install db4-devel-4.3.29-2 (on some systems,
+specify "rrppmm --qqff //lliibb//lliibbddbb..ssoo" instead).
+
+DO NOT download some Berkeley DB version from the network. Every Postfix
+program will dump core when it is built with a different Berkeley DB version
+than the version that is used by the system library routines. See the DB_README
+file for further information.
+
+PPrrooccmmaaiill iissssuueess
+
+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
+actually use more system resources than Postfix. To avoid such badness, disable
+synchronous mail logfile writes by editing /etc/syslog.conf and by prepending a
+- to the logfile name:
+
+    /etc/syslog.conf:
+        mail.*                          -/var/log/mail.log
+
+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.
+
--- a/README_FILES/LMDB_README
+++ b/README_FILES/LMDB_README
@ -0,0 +1,126 @@
+PPoossttffiixx OOppeennLLDDAAPP LLMMDDBB HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix uses databases of various kinds to store and look up information.
+Postfix databases are specified as "type:name". OpenLDAP LMDB (called "LMDB"
+from here on) implements the Postfix database type "lmdb". The name of a
+Postfix LMDB database is the name of the database file without the ".lmdb"
+suffix.
+
+This document describes:
+
+  * Building Postfix with LMDB support.
+
+  * Configuring LMDB settings.
+
+  * Using LMDB maps with non-Postfix programs.
+
+  * Required minimum LMDB patchlevel.
+
+  * Credits.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh LLMMDDBB ssuuppppoorrtt
+
+Postfix normally does not enable LMDB support. To build Postfix with LMDB
+support, use something like:
+
+    % make makefiles CCARGS="-DHAS_LMDB -I/usr/local/include" \
+        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
+building a dynamically-loaded or statically-loaded LMDB database client.
+
+    Failure to use the AUXLIBS_LMDB variable will defeat the purpose of dynamic
+    database client loading. Every Postfix executable file will have LMDB
+    database library dependencies. And that was exactly what dynamic database
+    client loading was meant to avoid.
+
+Solaris may need this:
+
+    % make makefiles CCARGS="-DHAS_LMDB -I/usr/local/include" \
+        AUXLIBS_LMDB="-R/usr/local/lib -L/usr/local/lib -llmdb"
+    % make
+
+The exact pathnames depend on how LMDB was installed.
+
+When building Postfix fails with:
+
+    undefined reference to `pthread_mutexattr_destroy'
+    undefined reference to `pthread_mutexattr_init'
+    undefined reference to `pthread_mutex_lock'
+
+Add the "-lpthread" library to the "make makefiles" command.
+
+    % make makefiles .... AUXLIBS_LMDB="... -lpthread"
+
+CCoonnffiigguurriinngg LLMMDDBB sseettttiinnggss
+
+Postfix provides one configuration parameter that controls LMDB database
+behavior.
+
+  * lmdb_map_size (default: 16777216). This setting specifies the initial LMDB
+    database size limit in bytes. Each time a database becomes "full", its size
+    limit is doubled. The maximum size is the largest signed integer value of
+    "long".
+
+UUssiinngg LLMMDDBB mmaappss wwiitthh nnoonn--PPoossttffiixx pprrooggrraammss
+
+Programs that use LMDB's built-in locking protocol will corrupt a Postfix LMDB
+database or will read garbage.
+
+Postfix does not use LMDB's built-in locking protocol, because that would
+require world-writable lockfiles, and would violate Postfix security policy.
+Instead, Postfix uses external locks based on fcntl(2) to prevent writers from
+corrupting the database, and to prevent readers from receiving garbage.
+
+See lmdb_table(5) for a detailed description of the locking protocol that all
+programs must use when they access a Postfix LMDB database.
+
+RReeqquuiirreedd mmiinniimmuumm LLMMDDBB ppaattcchhlleevveell
+
+Currently, Postfix requires LMDB 0.9.11 or later. The required minimum LMDB
+patchlevel has evolved over time, as the result of Postfix deployment
+experience:
+
+  * LMDB 0.9.11 allows Postfix daemons to log an LMDB error message, instead of
+    falling out of the sky without any notification.
+
+  * LMDB 0.9.10 closes an information leak where LMDB was writing up to 4-kbyte
+    chunks of uninitialized heap memory to the database. This would persist
+    information that was not meant to be persisted, or share information that
+    was not meant to be shared.
+
+  * LMDB 0.9.9 allows Postfix to use external (fcntl()-based) locks, instead of
+    having to use world-writable LMDB lock files, violating the Postfix
+    security model in multiple ways.
+
+  * LMDB 0.9.8 allows Postfix to recover from a "database full" error without
+    having to close the database. This version adds support to update the
+    database size limit on-the-fly. This is necessary because Postfix database
+    sizes vary with mail server load.
+
+  * LMDB 0.9.7 allows the postmap(1) and postalias(1) commands to use a bulk-
+    mode transaction larger than the amount of physical memory. This is
+    necessary because LMDB supports databases larger than physical memory.
+
+CCrreeddiittss
+
+  * Howard Chu contributed the initial Postfix dict_lmdb driver.
+
+  * Wietse Venema wrote an abstraction layer (slmdb) that behaves more like
+    Berkeley DB, NDBM, etc. This layer automatically retries an LMDB request
+    when a database needs to be resized, or after a database was resized by a
+    different process.
+
+  * Howard and Wietse went through many iterations with changes to both LMDB
+    and Postfix, with input from Viktor Dukhovni.
+
--- a/README_FILES/LOCAL_RECIPIENT_README
+++ b/README_FILES/LOCAL_RECIPIENT_README
@ -0,0 +1,138 @@
+RReejjeeccttiinngg UUnnkknnoowwnn LLooccaall RReecciippiieennttss wwiitthh PPoossttffiixx
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+As of Postfix version 2.0, the Postfix SMTP server rejects mail for unknown
+recipients in local domains (domains that match $mydestination or the IP
+addresses in $inet_interfaces or $proxy_interfaces) with "User unknown in local
+recipient table". This feature was optional with earlier Postfix versions.
+
+The good news is that this keeps undeliverable mail out of your queue, so that
+your mail queue is not clogged up with undeliverable MAILER-DAEMON messages.
+
+The bad news is that it may cause mail to be rejected when you upgrade from a
+Postfix system that was not configured to reject mail for unknown local
+recipients.
+
+This document describes what steps are needed in order to reject unknown local
+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 query format
+
+CCoonnffiigguurriinngg llooccaall__rreecciippiieenntt__mmaappss iinn mmaaiinn..ccff
+
+The local_recipient_maps parameter specifies lookup tables with all names or
+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". 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 (typically, in /etc/passwd) or local aliases (typically, in /etc/
+aliases):
+
+    /etc/postfix/main.cf:
+        local_recipient_maps = proxy:unix:passwd.byname $alias_maps
+
+To turn off unknown local recipient rejects by the SMTP server, specify:
+
+    /etc/postfix/main.cf:
+        local_recipient_maps =
+
+That is, an empty value. With this setting, the Postfix SMTP server will not
+reject mail with "User unknown in local recipient table". DDoonn''tt ddoo tthhiiss oonn
+ssyysstteemmss tthhaatt rreecceeiivvee mmaaiill ddiirreeccttllyy ffrroomm tthhee IInntteerrnneett.. WWiitthh ttooddaayy''ss wwoorrmmss aanndd
+vviirruusseess,, PPoossttffiixx wwiillll bbeeccoommee aa bbaacckkssccaatttteerr ssoouurrccee:: iitt aacccceeppttss mmaaiill ffoorr nnoonn--
+eexxiisstteenntt rreecciippiieennttss aanndd tthheenn ttrriieess ttoo rreettuurrnn tthhaatt mmaaiill aass ""uunnddeelliivveerraabbllee"" ttoo
+tthhee oofftteenn ffoorrggeedd sseennddeerr aaddddrreessss.
+
+WWhheenn yyoouu nneeeedd ttoo cchhaannggee tthhee llooccaall__rreecciippiieenntt__mmaappss sseettttiinngg iinn mmaaiinn..ccff
+
+  * Problem: you don't use the default Postfix local(8) delivery agent for
+    domains matching $mydestination, $inet_interfaces, or $proxy_interfaces.
+    For example, you redefined the "local_transport" setting in main.cf.
+
+    Solution: your local_recipient_maps setting needs to specify a database
+    that lists all the known user names or addresses for that delivery agent.
+    For example, if you deliver users in $mydestination etc. domains via the
+    virtual(8) delivery agent, specify:
+
+    /etc/postfix/main.cf
+        mydestination = $myhostname localhost.$mydomain localhost ...
+        local_transport = virtual
+        local_recipient_maps = $virtual_mailbox_maps
+
+    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
+    recipients.
+
+    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 recipients>
+
+    See the section "Local recipient table format" below for a description of
+    how the table should be populated.
+
+  * Problem: you use the luser_relay feature of the Postfix local delivery
+    agent.
+
+    Solution: you must disable the local_recipient_maps feature completely, so
+    that the Postfix SMTP server accepts mail for all local addresses:
+
+    /etc/postfix/main.cf
+        local_recipient_maps =
+
+LLooccaall rreecciippiieenntt ttaabbllee qquueerryy ffoorrmmaatt
+
+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:
+
+  * 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.
+
+  * 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.
+
+  * 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.
+
+NOTES:
+
+  * 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.
+
--- a/README_FILES/MAILDROP_README
+++ b/README_FILES/MAILDROP_README
@ -0,0 +1,129 @@
+PPoossttffiixx ++ MMaaiillddrroopp HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+This document discusses various options to plug the maildrop delivery agent
+into Postfix:
+
+  * Direct delivery without the local delivery agent
+  * Indirect delivery via the local delivery agent
+  * Credits
+
+DDiirreecctt ddeelliivveerryy wwiitthhoouutt tthhee llooccaall ddeelliivveerryy aaggeenntt
+
+Postfix can be configured to deliver mail directly to maildrop, without using
+the local(8) delivery agent as an intermediate. This means that you do not get
+local aliases(5) expansion or $HOME/.forward file processing. You would
+typically do this for hosted domains with recipients that don't have UNIX home
+directories.
+
+The following example shows how to use maildrop for some.domain and for
+someother.domain. The example comes in two parts.
+
+Part 1 describes changes to the main.cf file:
+
+     1 /etc/postfix/main.cf:
+     2     maildrop_destination_recipient_limit = 1
+     3     virtual_mailbox_domains = some.domain someother.domain
+     4     virtual_transport = maildrop
+     5     virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox
+     6     virtual_alias_maps = hash:/etc/postfix/virtual_alias
+     7
+     8 /etc/postfix/virtual_mailbox:
+     9     user1@some.domain        ...text here does not matter...
+    10     user2@some.domain        ...text here does not matter...
+    11     user3@someother.domain   ...text here does not matter...
+    12
+    13 /etc/postfix/virtual_alias:
+    14     postmaster@some.domain           postmaster
+    15     postmaster@someother.domain      postmaster
+
+  * Line 2 is needed so that Postfix will provide one recipient at a time to
+    the maildrop delivery agent.
+
+  * Line 3 informs Postfix that some.domain and someother.domain are so-called
+    virtual mailbox domains. Instead of listing the names in main.cf you can
+    also list them in a file; see the virtual_mailbox_domains documentation for
+    details.
+
+  * Line 4 specifies that mail for some.domain and someother.domain should be
+    delivered by the maildrop delivery agent.
+
+  * Lines 5 and 8-11 specify what recipients the Postfix SMTP server should
+    receive mail for. This prevents the mail queue from becoming clogged with
+    undeliverable messages. Specify an empty value ("virtual_mailbox_maps =")
+    to disable this feature.
+
+  * Lines 6 and 13-15 redirect mail for postmaster to the local postmaster. RFC
+    821 requires that every domain has a postmaster address.
+
+The vmail userid as used below is the user that maildrop should run as. This
+would be the owner of the virtual mailboxes if they all have the same owner. If
+maildrop is suid (see maildrop documentation), then maildrop will change to the
+appropriate owner to deliver the mail.
+
+Note: Do not use the postfix user as the maildrop user.
+
+Part 2 describes changes to the master.cf file:
+
+    /etc/postfix/master.cf:
+        maildrop  unix  -       n       n       -       -       pipe
+          flags=ODRhu user=vmail argv=/path/to/maildrop -d ${recipient}
+
+The pipe(8) manual page gives a detailed description of the above command line
+arguments, and more.
+
+If you want to support user+extension@domain style addresses, use the following
+instead:
+
+    /etc/postfix/master.cf:
+        maildrop  unix  -       n       n       -       -       pipe
+          flags=ODRhu user=vmail argv=/path/to/maildrop
+          -d ${user}@${domain} ${extension} ${recipient} ${user} ${nexthop}
+
+The mail is delivered to ${user}@${domain} (search key for maildrop userdb
+lookup). The ${extension} and the other address components are available to
+maildrop rules as $1, $2, $3, ... and can be omitted from master.cf or ignored
+by maildrop when not needed.
+
+With Postfix 2.4 and earlier, use ${nexthop} instead of ${domain}.
+
+IInnddiirreecctt ddeelliivveerryy vviiaa tthhee llooccaall ddeelliivveerryy aaggeenntt
+
+Postfix can be configured to deliver mail to maildrop via the local delivery
+agent. This is slightly less efficient than the "direct" approach discussed
+above, but gives you the convenience of local aliases(5) expansion and
+$HOME/.forward file processing. You would typically use this for domains that
+are listed in mydestination and that have users with a UNIX system account.
+
+To configure maildrop delivery for all UNIX system accounts:
+
+    /etc/postfix/main.cf:
+        mailbox_command = /path/to/maildrop -d ${USER}
+
+Note: ${USER} is spelled in upper case.
+
+To enable maildrop delivery for specific users only, you can use the Postfix
+local(8) delivery agent's mailbox_command_maps feature:
+
+    /etc/postfix/main.cf:
+        mailbox_command_maps = hash:/etc/postfix/mailbox_commands
+
+    /etc/postfix/mailbox_commands:
+        you    /path/to/maildrop -d ${USER}
+
+Maildrop delivery for specific users is also possible by invoking it from the
+user's $HOME/.forward file:
+
+    /home/you/.forward:
+        "|/path/to/maildrop -d ${USER}"
+
+CCrreeddiittss
+
+  * The original text was kindly provided by Russell Mosemann.
+  * Victor Duchovni provided tips for supporting user+foo@domain addresses.
+  * Tonni Earnshaw contributed text about delivery via the local(8) delivery
+    agent.
+
--- a/README_FILES/MAILLOG_README
+++ b/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).
+
--- a/README_FILES/MEMCACHE_README
+++ b/README_FILES/MEMCACHE_README
@ -0,0 +1,50 @@
+PPoossttffiixx mmeemmccaacchhee cclliieenntt HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+The Postfix memcache client allows you to hook up Postfix to a memcache server.
+The current implementation supports one memcache server per Postfix table, with
+one optional Postfix database that provides persistent backup. The Postfix
+memcache client supports the lookup, update, delete and sequence operations.
+The sequence (i.e. first/next) operation requires a backup database that
+supports this operation.
+
+Typically, the Postfix memcache client is used to reduce query load on a
+persistent database, but it may also be used to query a memory-only database
+for low-value, easy-to-recreate, information such as a reputation cache for
+postscreen(8), verify(8) or greylisting.
+
+LLiimmiittaattiioonnss
+
+  * The Postfix memcache client cannot be used for security-sensitive tables
+    such as alias_maps (these may contain "|command" and "/file/name"
+    destinations), or virtual_uid_maps, virtual_gid_maps and
+    virtual_mailbox_maps (these specify UNIX process privileges or "/file/name"
+    destinations). Typically, a memcache database is writable by any process
+    that can talk to the memcache server; in contrast, security-sensitive
+    tables must never be writable by the unprivileged Postfix user.
+
+  * The Postfix memcache client requires additional configuration when used as
+    postscreen(8) or verify(8) cache. For details see the backup and ttl
+    parameter discussions in the memcache_table(5) manual page.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh mmeemmccaacchhee ssuuppppoorrtt
+
+The Postfix memcache client has no external dependencies, and is therefore
+built into Postfix by default.
+
+CCoonnffiigguurriinngg mmeemmccaacchhee llooookkuupp ttaabblleess
+
+Configuration is described in the memcache_table(5) manpage.
+
+CCrreeddiittss
+
+The first memcache client for Postfix was written by Omar Kilani, and was based
+on the libmemcache library.
+
+Wietse wrote the current memcache client from the ground up for Postfix version
+2.9. This implementation does not use libmemcache, and bears no resemblance to
+earlier work.
+
--- a/README_FILES/MILTER_README
+++ b/README_FILES/MILTER_README
@ -0,0 +1,698 @@
+PPoossttffiixx bbeeffoorree--qquueeuuee MMiilltteerr ssuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix implements support for the Sendmail version 8 Milter (mail filter)
+protocol. This protocol is used by applications that run outside the MTA to
+inspect SMTP events (CONNECT, DISCONNECT), SMTP commands (HELO, MAIL FROM,
+etc.) as well as mail content (headers and body). All this happens before mail
+is queued.
+
+The reason for adding Milter support to Postfix is that there exists a large
+collection of applications, not only to block unwanted mail, but also to verify
+authenticity (examples: OpenDKIM and DMARC) or to digitally sign mail (example:
+OpenDKIM). Having yet another Postfix-specific version of all that software is
+a poor use of human and system resources.
+
+The Milter protocol has evolved over time, and different Postfix versions
+implement different feature sets. See the workarounds and limitations sections
+at the end of this document for differences between Postfix and Sendmail
+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
+  * Workarounds
+  * Limitations
+
+HHooww MMiilltteerr aapppplliiccaattiioonnss pplluugg iinnttoo PPoossttffiixx
+
+The Postfix Milter implementation uses two different lists of mail filters: one
+list of filters for SMTP mail only, and one list of filters for non-SMTP mail.
+The two lists have different capabilities, which is unfortunate. Avoiding this
+would require major restructuring of Postfix.
+
+  * The SMTP-only filters handle mail that arrives via the Postfix smtpd(8)
+    server. They are typically used to filter unwanted mail and to sign mail
+    from authorized SMTP clients. You specify SMTP-only Milter applications
+    with the smtpd_milters parameter as described in a later section. Mail that
+    arrives via the Postfix smtpd(8) server is not filtered by the non-SMTP
+    filters that are described next.
+
+  * The non-SMTP filters handle mail that arrives via the Postfix sendmail(1)
+    command-line or via the Postfix qmqpd(8) server. They are typically used to
+    digitally sign mail only. Although non-SMTP filters can be used to filter
+    unwanted mail, they have limitations compared to the SMTP-only filters. You
+    specify non-SMTP Milter applications with the non_smtpd_milters parameter
+    as described in a later section.
+
+For those who are familiar with the Postfix architecture, the figure below
+shows how Milter applications plug into Postfix. Names followed by a number are
+Postfix commands or server programs, while unnumbered names inside shaded areas
+represent Postfix queues. To avoid clutter, the path for local submission is
+simplified (the OVERVIEW document has a more complete description of the
+Postfix architecture).
+
+               SMTP-only      non-SMTP
+                 filters       filters
+
+                     ^ |
+                     | v
+                                   ^ |
+                                   | |
+    Network ->   smtpd(8)          | |
+                                   | v
+
+                           \
+
+    Network ->   qmqpd(8)  -> cleanup(8) -> incoming
+
+                           /
+
+                pickup(8)
+
+                      :
+
+    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, 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
+some Linux systems).
+
+Once libmilter is installed, applications such as OpenDKIM and OpenDMARC build
+out of the box without requiring any tinkering:
+
+    $ ggzzccaatt ooppeennddkkiimm--xx..yy..zz..ttaarr..ggzz || ttaarr xxff --
+    $ ccdd ooppeennddkkiimm--xx..yy..zz
+    $ ..//ccoonnffiigguurree ......ooppttiioonnss......
+    $ mmaakkee
+    [...lots of output omitted...]
+    $ mmaakkee iinnssttaallll
+
+RRuunnnniinngg MMiilltteerr aapppplliiccaattiioonnss
+
+To run a Milter application, see the documentation of the filter for options. A
+typical command looks like this:
+
+    # //ssoommee//wwhheerree//ooppeennddkkiimm --ll --uu uusseerriidd --pp iinneett::ppoorrttnnuummbbeerr@@llooccaallhhoosstt ......ootthheerr
+    ooppttiioonnss......
+
+Please specify a userid value that isn't used for other applications (not
+"postfix", not "www", etc.).
+
+CCoonnffiigguurriinngg PPoossttffiixx
+
+Like Sendmail, Postfix has a lot of configuration options that control how it
+talks to Milter applications. Besides global options that apply to all Milter
+applications, Postfix 3.0 and later support per-Milter timeouts, per-Milter
+error handling, etc.
+
+Information in this section:
+
+  * SMTP-Only Milter applications
+  * Non-SMTP Milter applications
+  * Milter error handling
+  * Milter protocol version
+  * Milter protocol timeouts
+  * Different settings for different Milter applications
+  * Different settings for different SMTP clients
+  * Sendmail macro emulation
+  * What macros will Postfix send to Milters?
+
+SSMMTTPP--OOnnllyy MMiilltteerr aapppplliiccaattiioonnss
+
+The SMTP-only Milter applications handle mail that arrives via the Postfix
+smtpd(8) server. They are typically used to filter unwanted mail, and to sign
+mail from authorized SMTP clients. Mail that arrives via the Postfix smtpd(8)
+server is not filtered by the non-SMTP filters that are described in the next
+section.
+
+    NOTE for Postfix versions that have a mail_release_date before 20141018: do
+    not use the header_checks(5) IGNORE action to remove Postfix's own
+    Received: message header. This causes problems with mail signing filters.
+    Instead, keep Postfix's own Received: message header and use the
+    header_checks(5) REPLACE action to sanitize information.
+
+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. 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.
+        # See below for socket address syntax.
+        smtpd_milters = inet:localhost:portnumber ...other filters...
+
+The general syntax for listening sockets is as follows:
+
+    uunniixx::pathname
+        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. On many systems, llooccaall is a synonym for uunniixx
+
+    iinneett::host::port
+        Connect to the specified TCP port on the specified local or remote
+        host. The host and port can be specified in numeric or symbolic form.
+
+        NOTE: Postfix syntax differs from Milter syntax which has the form
+        iinneett::port@@host.
+
+For advanced configuration see "Different settings for different SMTP clients"
+and "Different settings for different Milter applications".
+
+NNoonn--SSMMTTPP MMiilltteerr aapppplliiccaattiioonnss
+
+The non-SMTP Milter applications handle mail that arrives via the Postfix
+sendmail(1) command-line or via the Postfix qmqpd(8) server. They are typically
+used to digitally sign mail. Although non-SMTP filters can be used to filter
+unwanted mail, there are limitations as discussed later in this section. Mail
+that arrives via the Postfix smtpd(8) server is not filtered by the non-SMTP
+filters.
+
+NOTE: Do not use the header_checks(5) IGNORE action to remove Postfix's own
+Received: message header. This causes problems with mail signing filters.
+Instead, keep Postfix's own Received: message header and use the header_checks
+(5) REPLACE action to sanitize information.
+
+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. 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.
+        # See below for socket address syntax.
+        non_smtpd_milters = inet:localhost:portnumber ...other filters...
+
+There's one small complication when using Milter applications for non-SMTP
+mail: there is no SMTP session. To keep Milter applications happy, the Postfix
+cleanup(8) server actually has to simulate the SMTP client CONNECT and
+DISCONNECT events, and the SMTP client EHLO, MAIL FROM, RCPT TO and DATA
+commands.
+
+  * When new mail arrives via the sendmail(1) command line, the Postfix cleanup
+    (8) server pretends that the mail arrives with ESMTP from "localhost" with
+    IP address "127.0.0.1". The result is very similar to what happens with
+    command line submissions in Sendmail version 8.12 and later, although
+    Sendmail uses a different mechanism to achieve this result.
+
+  * When new mail arrives via the qmqpd(8) server, the Postfix cleanup(8)
+    server pretends that the mail arrives with ESMTP, and uses the QMQPD client
+    hostname and IP address.
+
+  * When old mail is re-injected into the queue with "postsuper -r", the
+    Postfix cleanup(8) server uses the same client information that was used
+    when the mail arrived as new mail.
+
+This generally works as expected, with only one exception: non-SMTP filters
+must not REJECT or TEMPFAIL simulated RCPT TO commands. When a
+non_smtpd_milters application REJECTs or TEMPFAILs a recipient, Postfix will
+report a configuration error, and mail will stay in the queue.
+
+SSiiggnniinngg iinntteerrnnaallllyy--ggeenneerraatteedd bboouunnccee mmeessssaaggeess
+
+Postfix normally does not apply content filters to mail that is generated
+internally such as bounces or Postmaster notifications. Filtering internally-
+generated bounces would result in loss of mail when a filter rejects a message,
+as the resulting double-bounce message would almost certainly also be blocked.
+
+To sign Postfix's own bounce messages, enable filtering of internally-generated
+bounces (line 2 below), and don't reject any internally-generated bounces with
+non_smtpd_milters, header_checks or body_checks (lines 3-5 below).
+
+    1 /etc/postfix/main.cf:
+    2     internal_mail_filter_classes = bounce
+    3     non_smtpd_milters = don't reject internally-generated bounces
+    4     header_checks = don't reject internally-generated bounces
+    5     body_checks = don't reject internally-generated bounces
+
+MMiilltteerr eerrrroorr hhaannddlliinngg
+
+The milter_default_action parameter specifies how Postfix handles Milter
+application errors. The default action is to respond with a temporary error
+status, so that the client will try again later. Specify "accept" if you want
+to receive mail as if the filter does not exist, and "reject" to reject mail
+with a permanent status. The "quarantine" action is like "accept" but freezes
+the message in the "hold" queue, and is available with Postfix 2.6 or later.
+
+    /etc/postfix/main.cf:
+        # What to do in case of errors? Specify accept, reject, tempfail,
+        # or quarantine (Postfix 2.6 or later).
+        milter_default_action = tempfail
+
+See "Different settings for different Milter applications" for advanced
+configuration options.
+
+MMiilltteerr pprroottooccooll vveerrssiioonn
+
+As Postfix is not built with the Sendmail libmilter library, you may need to
+configure the Milter protocol version that Postfix should use. The default
+version is 6 (before Postfix 2.6 the default version is 2).
+
+    /etc/postfix/main.cf:
+        # Postfix >= 2.6
+        milter_protocol = 6
+        # 2.3 <= Postfix <= 2.5
+        milter_protocol = 2
+
+If the Postfix milter_protocol setting specifies a too low version, the
+libmilter library will log an error message like this:
+
+    application name: st_optionneg[xxxxx]: 0xyy does not fulfill action
+    requirements 0xzz
+
+The remedy is to increase the Postfix milter_protocol version number. See,
+however, the limitations section below for features that aren't supported by
+Postfix.
+
+With Postfix 2.7 and earlier, if the Postfix milter_protocol setting specifies
+a too high version, the libmilter library simply hangs up without logging a
+warning, and you see a Postfix warning message like one of the following:
+
+    warning: milter inet:host:port: can't read packet header: Unknown error : 0
+    warning: milter inet:host:port: can't read packet header: Success
+    warning: milter inet:host:port: can't read SMFIC_DATA reply packet header:
+    No such file or directory
+
+The remedy is to lower the Postfix milter_protocol version number. Postfix 2.8
+and later will automatically turn off protocol features that the application's
+libmilter library does not expect.
+
+See "Different settings for different Milter applications" for advanced
+configuration options.
+
+MMiilltteerr pprroottooccooll ttiimmeeoouuttss
+
+Postfix uses different time limits at different Milter protocol stages. The
+table shows the timeout settings and the corresponding protocol stages (EOH =
+end of headers; EOM = end of message).
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |PPoossttffiixx ppaarraammeetteerr     |TTiimmee lliimmiitt|MMiilltteerr pprroottooccooll ssttaaggee          |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_connect_timeout|30s       |CONNECT                        |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_command_timeout|30s       |HELO, MAIL, RCPT, DATA, UNKNOWN|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_content_timeout|300s      |HEADER, EOH, BODY, EOM         |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+Beware: 30s may be too short for Milter applications that do lots of DNS
+lookups. However, if you increase the above timeouts too much, remote SMTP
+clients may hang up and mail may be delivered multiple times. This is an
+inherent problem with before-queue filtering.
+
+See "Different settings for different Milter applications" for advanced
+configuration options.
+
+DDiiffffeerreenntt sseettttiinnggss ffoorr ddiiffffeerreenntt MMiilltteerr aapppplliiccaattiioonnss
+
+The previous sections list a number of Postfix main.cf parameters that control
+time limits and other settings for all Postfix Milter clients. This is
+sufficient for simple configurations. With more complex configurations it
+becomes desirable to have different settings for different Milter clients. This
+is supported with Postfix 3.0 and later.
+
+The following example shows a "non-critical" Milter client with a short connect
+timeout, and with "accept" as default action when the service is unvailable.
+
+    1 /etc/postfix/main.cf:
+    2     smtpd_milters = { inet:host:port,
+    3         connect_timeout=10s, default_action=accept }
+
+Instead of a server endpoint, we now have a list enclosed in {}.
+
+  * Line 2: The first item in the list is the server endpoint. This supports
+    the exact same "inet" and "unix" syntax as described earlier.
+
+  * Line 3: The remainder of the list contains per-Milter settings. These
+    settings override global main.cf parameters, and have the same name as
+    those parameters, without the "milter_" prefix. The per-Milter settings
+    that are supported as of Postfix 3.0 are command_timeout, connect_timeout,
+    content_timeout, default_action, and protocol.
+
+Inside the list, syntax is similar to what we already know from main.cf: items
+separated by space or comma. There is one difference: yyoouu mmuusstt eenncclloossee aa
+sseettttiinngg iinn ppaarreenntthheesseess,, aass iinn ""{{ nnaammee == vvaalluuee }}"",, iiff yyoouu wwaanntt ttoo hhaavvee ssppaaccee oorr
+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 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
+    smtpd_milters = inet:host:port, { inet:host:port, ... }, ...
+
+/etc/postfix/smtpd_milter_map:
+    # Disable Milters for local clients.
+    127.0.0.0/8    DISABLE
+    192.168.0.0/16 DISABLE
+    ::/64          DISABLE
+    2001:db8::/32  DISABLE
+
+This feature is available with Postfix 3.2 and later.
+
+SSeennddmmaaiill mmaaccrroo eemmuullaattiioonn
+
+Postfix emulates a limited number of Sendmail macros, as shown in the table.
+Some macro values depend on whether a recipient is rejected (rejected
+recipients are available on request by the Milter application). Different
+macros are available at different Milter protocol stages (EOH = end-of-header,
+EOM = end-of-message); their availability is not always the same as in
+Sendmail. See the workarounds section below for solutions.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |SSeennddmmaaiill mmaaccrroo      |MMiilltteerr pprroottooccooll ssttaaggee    |DDeessccrriippttiioonn               |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |i                   |DATA, EOH, EOM           |Queue ID, also Postfix    |
+    |                    |                         |queue file name           |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |j                   |Always                   |Value of myhostname       |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |_                   |Always                   |The validated client name |
+    |                    |                         |and address               |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{auth_authen}       |MAIL, DATA, EOH, EOM     |SASL login name           |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{auth_author}       |MAIL, DATA, EOH, EOM     |SASL sender               |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{auth_type}         |MAIL, DATA, EOH, EOM     |SASL login method         |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{client_addr}       |Always                   |Remote client IP address  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |                    |                         |Connection concurrency for|
+    |                    |                         |this client (zero if the  |
+    |{client_connections}|CONNECT                  |client is excluded from   |
+    |                    |                         |all smtpd_client_*        |
+    |                    |                         |limits).                  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |                    |                         |Remote client hostname    |
+    |                    |                         |When address -> name      |
+    |{client_name}       |Always                   |lookup or name -> address |
+    |                    |                         |verification fails:       |
+    |                    |                         |"unknown"                 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{client_port}       |Always (Postfix >=2.5)   |Remote client TCP port    |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |                    |                         |Client name from address -|
+    |{client_ptr}        |CONNECT, HELO, MAIL, DATA|> name lookup             |
+    |                    |                         |When address -> name      |
+    |                    |                         |lookup fails: "unknown"   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{cert_issuer}       |HELO, MAIL, DATA, EOH,   |TLS client certificate    |
+    |                    |EOM                      |issuer                    |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{cert_subject}      |HELO, MAIL, DATA, EOH,   |TLS client certificate    |
+    |                    |EOM                      |subject                   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{cipher_bits}       |HELO, MAIL, DATA, EOH,   |TLS session key size      |
+    |                    |EOM                      |                          |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{cipher}            |HELO, MAIL, DATA, EOH,   |TLS cipher                |
+    |                    |EOM                      |                          |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{daemon_addr}       |Always (Postfix >=3.2)   |Local server IP address   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{daemon_name}       |Always                   |value of                  |
+    |                    |                         |milter_macro_daemon_name  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{daemon_port}       |Always (Postfix >=3.2)   |Local server TCP port     |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{mail_addr}         |MAIL                     |Sender address            |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{mail_host}         |MAIL (Postfix >= 2.6,    |Sender next-hop           |
+    |                    |only with smtpd_milters) |destination               |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{mail_mailer}       |MAIL (Postfix >= 2.6,    |Sender mail delivery      |
+    |                    |only with smtpd_milters) |transport                 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |                    |                         |Recipient address         |
+    |{rcpt_addr}         |RCPT                     |With rejected recipient:  |
+    |                    |                         |descriptive text          |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |                    |                         |Recipient next-hop        |
+    |{rcpt_host}         |RCPT (Postfix >= 2.6,    |destination               |
+    |                    |only with smtpd_milters) |With rejected recipient:  |
+    |                    |                         |enhanced status code      |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |                    |                         |Recipient mail delivery   |
+    |{rcpt_mailer}       |RCPT (Postfix >= 2.6,    |transport                 |
+    |                    |only with smtpd_milters) |With rejected recipient:  |
+    |                    |                         |"error"                   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |{tls_version}       |HELO, MAIL, DATA, EOH,   |TLS protocol version      |
+    |                    |EOM                      |                          |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |v                   |Always                   |value of milter_macro_v   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+WWhhaatt mmaaccrrooss wwiillll PPoossttffiixx sseenndd ttoo MMiilltteerrss??
+
+Postfix sends specific sets of macros at different Milter protocol stages. The
+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
+takes precedence over a Postfix-specified list.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |PPoossttffiixx ppaarraammeetteerr            |MMiilltteerr pprroottooccooll|MMiilltteerr pprroottooccooll ssttaaggee|
+    |                             |vveerrssiioonn        |                     |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_connect_macros        |2 or higher    |CONNECT              |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_helo_macros           |2 or higher    |HELO/EHLO            |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_mail_macros           |2 or higher    |MAIL FROM            |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_rcpt_macros           |2 or higher    |RCPT TO              |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_data_macros           |4 or higher    |DATA                 |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_end_of_header_macros  |6 or higher    |EOH                  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_end_of_data_macros    |2 or higher    |EOM                  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |milter_unknown_command_macros|3 or higher    |unknown command      |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+By default, Postfix will send only macros whose values have been updated with
+information from main.cf or master.cf, from an SMTP session (for example; SASL
+login, or TLS certificates) or from a Mail delivery transaction (for example;
+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 not know about!
+
+WWoorrkkaarroouunnddss
+
+  * To avoid breaking DKIM etc. signatures with an SMTP-based content filter,
+    update the before-filter SMTP client in master.cf, and add a line with "-
+    o disable_mime_output_conversion=yes" (note: no spaces around the "="). For
+    details, see the advanced content filter example.
+
+    /etc/postfix/master.cf:
+        # =============================================================
+        # service type  private unpriv  chroot  wakeup  maxproc command
+        #               (yes)   (yes)   (yes)   (never) (100)
+        # =============================================================
+        scan      unix  -       -       n       -       10      smtp
+            -o smtp_send_xforward_command=yes
+            -o disable_mime_output_conversion=yes
+            -o smtp_generic_maps=
+
+  * Some Milter applications use the "{if_addr}" macro to recognize local mail;
+    this macro does not exist in Postfix. Workaround: use the "{daemon_addr}"
+    (Postfix >= 3.2) or "{client_addr}" macro instead.
+
+  * Some Milter applications log a warning that looks like this:
+
+        sid-filter[36540]: WARNING: sendmail symbol 'i' not available
+
+    And they may insert an ugly message header with "unknown-msgid" like this:
+
+        X-SenderID: Sendmail Sender-ID Filter vx.y.z host.example.com <unknown-
+        msgid>
+
+    The problem is that Milter applications expect that the queue ID is known
+    before the MTA accepts the MAIL FROM (sender) command. Postfix does not
+    choose a queue ID, which is used as the queue file name, until after it
+    accepts the first valid RCPT TO (recipient) command.
+
+    If you experience the ugly header problem, see if a recent version of the
+    Milter application fixes it. For example, current versions of dkim-filter
+    and dk-filter already have code that looks up the Postfix queue ID at a
+    later protocol stage, and sid-filter version 1.0.0 no longer includes the
+    queue ID in the message header.
+
+    To fix the ugly message header, you will need to add code that looks up the
+    Postfix queue ID at some later point in time. The example below adds the
+    lookup after the end-of-message.
+
+      o Edit the filter source file (typically named xxx-filter/xxx-filter.c or
+        similar).
+
+      o Look up the mlfi_eom() function and add code near the top shown as bboolldd
+        text below:
+
+        dfc = cc->cctx_msg;
+        assert(dfc != NULL);
+
+        //** DDeetteerrmmiinnee tthhee jjoobb IIDD ffoorr llooggggiinngg.. **//
+        iiff ((ddffcc-->>mmccttxx__jjoobbiidd ==== 00 |||| ssttrrccmmpp((ddffcc-->>mmccttxx__jjoobbiidd,, JJOOBBIIDDUUNNKKNNOOWWNN)) ==== 00))
+        {{
+                cchhaarr **jjoobbiidd == ssmmffii__ggeettssyymmvvaall((ccttxx,, ""ii""));;
+                iiff ((jjoobbiidd !!== 00))
+                        ddffcc-->>mmccttxx__jjoobbiidd == jjoobbiidd;;
+        }}
+
+    NOTES:
+
+      o Different mail filters use slightly different names for variables. If
+        the above code does not compile, look elsewhere in the mail filter
+        source file for code that looks up the "i" macro value, and copy that
+        code.
+
+      o This change fixes only the ugly message header, but not the WARNING
+        message. Fortunately, many Milters log that message only once.
+
+LLiimmiittaattiioonnss
+
+This section lists limitations of the Postfix Milter implementation. Some
+limitations will be removed as the implementation is extended over time. Of
+course the usual limitations of before-queue filtering will always apply. See
+the CONTENT_INSPECTION_README document for a discussion.
+
+  * The Milter protocol has evolved over time. Therefore, different Postfix
+    versions implement different feature sets.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |PPoossttffiixx|SSuuppppoorrtteedd MMiilltteerr rreeqquueessttss                                       |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |   2.6 |All Milter requests of Sendmail 8.14.0 (see notes below).       |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |       |All Milter requests of Sendmail 8.14.0, except:                 |
+    |       |SMFIP_RCPT_REJ (report rejected recipients to the mail filter), |
+    |   2.5 |SMFIR_CHGFROM (replace sender, with optional ESMTP parameters), |
+    |       |SMFIR_ADDRCPT_PAR (add recipient, with optional ESMTP           |
+    |       |parameters).                                                    |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |   2.4 |All Milter requests of Sendmail 8.13.0.                         |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |   2.3 |All Milter requests of Sendmail 8.13.0, except:                 |
+    |       |SMFIR_REPLBODY (replace message body).                          |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+  * For Milter applications that are written in C, you need to use the Sendmail
+    libmilter library.
+
+  * Postfix has TWO sets of mail filters: filters that are used for SMTP mail
+    only (specified with the smtpd_milters parameter), and filters for non-SMTP
+    mail (specified with the non_smtpd_milters parameter). The non-SMTP filters
+    are primarily for local submissions.
+
+    When mail is filtered by non_smtpd_milters, the Postfix cleanup(8) server
+    has to simulate SMTP client requests. This works as expected, with only one
+    exception: non_smtpd_milters must not REJECT or TEMPFAIL simulated RCPT TO
+    commands. When this rule is violated, Postfix will report a configuration
+    error, and mail will stay in the queue.
+
+  * When you use the before-queue content filter for incoming SMTP mail (see
+    SMTPD_PROXY_README), Milter applications have access only to the SMTP
+    command information; they have no access to the message header or body, and
+    cannot make modifications to the message or to the envelope.
+
+  * 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"
+
+  * Postfix 2.3 does not implement requests to replace the message body. Milter
+    applications log a warning message when they need this unsupported
+    operation:
+
+    st_optionneg[134563840]: 0x3d does not fulfill action requirements 0x1e
+
+    The solution is to use Postfix version 2.4 or later.
+
+  * Postfix versions before 3.0 did not support per-Milter timeouts, per-Milter
+    error handling, etc.
+
--- a/README_FILES/MONGODB_README
+++ b/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.
+
--- a/README_FILES/MULTI_INSTANCE_README
+++ b/README_FILES/MULTI_INSTANCE_README
@ -0,0 +1,981 @@
+MMaannaaggiinngg mmuullttiippllee PPoossttffiixx iinnssttaanncceess oonn aa ssiinnggllee hhoosstt
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document is a guide to managing multiple Postfix instances on a single
+host using the postmulti(1) instance manager. Multi-instance support is
+available with Postfix version 2.6 and later. See the postfix-wrapper(5) manual
+page for background on the instance management framework, and on how to deploy
+a custom instance manager.
+
+Topics covered in this document:
+
+  * Why multiple Postfix instances
+  * Null-client instances versus service instances
+  * Multi-instance walk-through
+  * Components of a Postfix system
+  * The default Postfix instance
+  * Instance groups
+  * Multi-instance configuration parameters
+  * Using the postmulti(1) command
+  * Credits
+
+WWhhyy mmuullttiippllee PPoossttffiixx iinnssttaanncceess
+
+Postfix is a general-purpose mail system that can be configured to serve a
+variety of needs. Examples of Postfix applications are:
+
+  * Local mail submission for shell users and system processes.
+
+  * Incoming (MX host) email from the Internet.
+
+  * Outbound mail relay for a corporate network.
+
+  * Authenticated submission for roaming users.
+
+  * Before/after content-filter mail.
+
+A single Postfix configuration can provide many or all of these services, but a
+complex interplay of settings may be required, for example with master.cf
+options overriding main.cf settings. In this document we take the view that
+multiple Postfix instances may be a simpler way to configure a multi-function
+Postfix system. With multiple Postfix instances, each instance has its own
+directories for configuration, queue and data files, but it shares all Postfix
+program and documentation files with other instances.
+
+Since there is no single right way to configure your system, we recommend that
+you choose what makes you most comfortable. If different Postfix services don't
+involve incompatible main.cf or master.cf settings, and if they can be combined
+together without complex tricks, then a single monolithic configuration may be
+the simplest approach.
+
+The purpose of multi-instance support in Postfix is not to force you to create
+multiple Postfix instances, but rather to give you a choice. Multiple instances
+give you the freedom to tune each Postfix instance to a single task that it
+does well and to combine instances into complete systems.
+
+With the introduction of the postmulti(1) utility and the reduction of the per-
+instance configuration footprint of a secondary Postfix instance to just a
+main.cf and master.cf file (other files are now in shared locations), we hope
+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.
+
+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
+so that system users can send email with command-line utilities. Such email can
+be handled with a null-client Postfix configuration that forwards all mail to a
+central mail hub. The null client will typically either not run an SMTP
+listener at all (master_service_disable = inet), or it will listen only on the
+loopback interface (inet_interfaces = loopback-only).
+
+When implementing specialized servers for inbound Internet email, outbound
+MTAs, internal mail hubs, and so on, we recommend using a null client for local
+submission and creating single-function secondary Postfix instances to serve
+the specialized needs.
+
+    Note: usually, you need to use different "myhostname" settings when you run
+    multiple instances on the same host. Otherwise, there will be false "mail
+    loops back to myself" alarms when one instance tries to send mail into
+    another instance. Typically, the null-client instance will use the system's
+    hostname, and other instances will use their own dedicated "myhostname"
+    settings. Different names are not needed when instances send mail to each
+    other with a protocol other than SMTP, or with SMTP over a TCP port other
+    than 25 as is usual with SMTP-based content filters.
+
+MMuullttii--iinnssttaannccee wwaallkk--tthhrroouugghh
+
+Before discussing the fine details of multi-instance operation we first show
+the steps for creating a border mail server. This server has with a null-client
+Postfix instance for local submission, an input Postfix instance to receive
+mail from the Internet, plus an advanced SMTP content-filter and an output
+Postfix instance to deliver filtered email to its internal destination.
+
+SSeettttiinngg uupp tthhee nnuullll--cclliieenntt PPoossttffiixx iinnssttaannccee
+
+On a border mail hub, while mail from the Internet requires a great deal of
+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-
+submission null client:
+
+    /etc/postfix/main.cf:
+        # We are mta1.example.com
+        #
+        myhostname = mta1.example.com
+        mydomain = example.com
+
+        # Flat user-account namespace in example.com:
+        #
+        #   user@example.com not user@host.example.com
+        #
+        myorigin = $mydomain
+
+        # Postfix 2.6+, disable inet services, specifically disable smtpd(8)
+        #
+        master_service_disable = inet
+
+        # No local delivery:
+        #
+        mydestination =
+        local_transport = error:5.1.1 Mailbox unavailable
+        alias_database =
+        alias_maps =
+        local_recipient_maps =
+
+        # Send everything to the internal mailhub
+        #
+        relayhost = [mailhub.example.com]
+
+        # Indexed table macro:
+        # (use "hash", ... when cdb is not available)
+        #
+        default_database_type = cdb
+        indexed = ${default_database_type}:${config_directory}/
+
+        # Expose origin host of mail from "root", ...
+        #
+        smtp_generic_maps = ${indexed}generic
+
+        # Send messages addressed to "root", ... to the MTA support team
+        #
+        virtual_alias_maps = ${indexed}virtual
+
+    /etc/postfix/generic:
+        # The smarthost supports "+" addressing (recipient_delimiter = +).
+        # Mail from "root" exposes the origin host, without replies
+        # and bounces going back to the same host.
+        #
+        # On clustered MTAs this file is typically machine-built from
+        # a template file. The build process expands the template into
+        # "mtaadmin+root=mta1"
+        #
+        root        mtaadmin+root=mta1
+
+    /etc/postfix/virtual:
+        # Caretaker aliases:
+        #
+        root        mtaadmin
+        postmaster  root
+
+You would typically also add a Makefile, to automatically run postmap(1)
+commands when source files change. This Makefile also creates a "generic"
+database when none exists.
+
+    /etc/postfix/Makefile:
+        MTAADMIN=mtaadmin
+
+        all: virtual.cdb generic.cdb
+
+        generic: Makefile
+                @echo Creating $@
+                @rm -f $@.tmp
+                @printf '%s\t%s+root=%s\n' root ${MTAADMIN} `uname -n` > $@.tmp
+                @mv $@.tmp generic
+
+        %.cdb: %
+                postmap cdb:$<
+
+Construct the "virtual" and "generic" databases (the latter is created by
+running "make"), then start and test the null-client:
+
+    # cd /etc/postfix; make
+    # postfix start
+    # sendmail -i -f root -t <<EOF
+    From: root
+    To: root
+    Subject: test
+
+    testing
+    EOF
+
+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
+    To: mtadmin+root=mta1@example.com
+    Subject: test
+
+SSeettttiinngg uupp tthhee ""oouuttppuutt"" PPoossttffiixx iinnssttaannccee
+
+With the null-client instance out of the way, we can create the MTA "output"
+instance that will deliver filtered mail to the inside network. We add the
+"output" instance first, because the output instance needs to be up and running
+before the input instance can be fully tested, and when the system boots, the
+"output" instance must start before the input instance. We will put the output
+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:
+
+    # postmulti -e init
+
+Then create the output instance:
+
+    # postmulti -I postfix-out -G mta -e create
+
+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
+"disabled" state:
+
+    /etc/postfix-out/main.cf
+        #
+        # ... "stock" main.cf settings ...
+        #
+        multi_instance_name = postfix-out
+        queue_directory = /var/spool/postfix-out
+        data_directory = /var/lib/postfix-out
+        #
+        multi_instance_enable = no
+        master_service_disable = inet
+        authorized_submit_users =
+
+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
+and /var/lib/postfix-out).
+
+While this instance is immediately safe to start, it is not yet usefully
+configured. It needs to be customized to fit the role of a post-filter re-
+injection SMTP service. Typical additions include:
+
+    /etc/postfix-out/master.cf:
+        # Replace default "smtp inet" entry with one listening on port 10026.
+        127.0.0.1:10026     inet  n       -       n       -       -       smtpd
+
+    /etc/postfix-out/main.cf
+        # ...
+
+        # Comment out if you don't use IPv6 internally
+        # inet_protocols = ipv4
+        inet_interfaces = loopback-only
+        mynetworks_style = host
+        smtpd_authorized_xforward_hosts = $mynetworks
+
+        # Don't anvil(8) control the re-injection port.
+        #
+        smtpd_client_connection_count_limit = 0
+        smtpd_client_event_limit_exceptions = $mynetworks
+
+        # Best practice when inet_interfaces is set, as this is not a
+        # "secondary IP personality" configuration.
+        #
+        smtp_bind_address = 0.0.0.0
+
+        # All header rewriting happens upstream
+        #
+        local_header_rewrite_clients =
+
+        # No local delivery on border gateway
+        #
+        mydestination =
+        alias_maps =
+        alias_database =
+        local_recipient_maps =
+        local_transport = error:5.1.1 Mailbox unavailable
+
+        # May need a recipient_delimiter for per-user transport lookups:
+        #
+        recipient_delimiter = +
+
+        # Only one (unrestricted client)
+        # With multiple instances, rarely need "-o param=value" overrides
+        # in master.cf, each instance gets its own main.cf file.
+        #
+        # Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
+        smtpd_relay_restrictions =
+        smtpd_recipient_restrictions = permit_mynetworks, reject
+
+        # Tolerate occasional high latency in the content filter.
+        #
+        smtpd_timeout = 1200s
+
+        # Best when empty, with all parent domain matches explicit.
+        #
+        parent_domain_matches_subdomains =
+
+        # Use the "relay" transport for inbound mail, and the default
+        # "smtp" transport for outbound mail (bounces, ...). The latter
+        # won't starve the former of delivery agent slots.
+        #
+        relay_domains = example.com, .example.com
+
+        # With xforward, match the input instance setting, if you
+        # want "yes", set both to "yes".
+        #
+        smtpd_client_port_logging = no
+
+        # Transport settings ...
+        # Message size limit
+        # Concurrency tuning for "relay" and "smtp" transport
+        # ...
+
+With the "output" configuration in place, enable and start the instance:
+
+    1 # postmulti -i postfix-out -x postconf -e \
+    2     "master_service_disable =" "authorized_submit_users = root"
+    3 # postmulti -i postfix-out -e enable
+    4 # postmulti -i postfix-out -p start
+
+This uses the postmulti(1) command to invoke postconf(1) in the context
+(MAIL_CONFIG=/etc/postfix-out) of the output instance.
+
+  * Lines 1-2: With "authorized_submit_users = root", the superuser can test
+    the postfix-out instance with "postmulti -i postfix-out -x sendmail -bv
+    recipient...", but otherwise local submission remains disabled.
+
+  * Lines 1-2: With "master_service_disable =", the "inet" listeners are re-
+    enabled.
+
+  * Line 3: The output instance is enabled for multi-instance start/stop.
+
+  * Line 4: The output instance is started.
+
+Test the output instance by submitting probe messages via "sendmail -bv" and
+"telnet". For production systems, in-depth configuration tests should be done
+on a lab system. The simple tests just suggested will only confirm successful
+deployment of a configuration that should already be known good.
+
+SSeettttiinngg uupp tthhee ccoonntteenntt--ffiilltteerr pprrooxxyy
+
+With the output instance ready, deploy your content-filter proxy. Most proxies
+will need their own /etc/rc* start/stop script. Some proxies, however, are
+started on demand by the Postfix spawn(8) service, in which case you need to
+add the relevant spawn(8) entry to the output instance master.cf file.
+
+Configure the proxy to listen on 127.0.0.1:10025 and to re-inject filtered
+email to 127.0.0.1:10026. Start the proxy service if necessary, then test the
+proxy via "telnet" or automated SMTP injectors. The proxy should support the
+following ESMTP features: DSN, 8BITMIME, and XFORWARD. In addition, the proxy
+should support multiple mail deliveries within an SMTP session.
+
+SSeettttiinngg uupp tthhee iinnppuutt PPoossttffiixx iinnssttaannccee
+
+The input Postfix instance receives mail from the network and sends it through
+the content filter. Now we create the input instance, also part of the "mta"
+instance group:
+
+    # postmulti -I postfix-in -G mta -e create
+
+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
+"disabled" state:
+
+    /etc/postfix-in/main.cf
+        #
+        # ... "stock" main.cf settings ...
+        #
+        multi_instance_name = postfix-in
+        queue_directory = /var/spool/postfix-in
+        data_directory = /var/lib/postfix-in
+        #
+        multi_instance_enable = no
+        master_service_disable = inet
+        authorized_submit_users =
+
+As before, make appropriate changes to main.cf and master.cf to make the
+instance production ready. Consider setting "soft_bounce = yes" during the
+first few hours of deployment, so you can iron-out any unexpected "kinks".
+
+Manual testing can start with:
+
+    /etc/postfix-in/main.cf
+        # Accept only local traffic, but allow impersonation:
+        inet_interfaces = 127.0.0.1
+        smtpd_authorized_xclient_hosts = 127.0.0.1
+
+This allows you to use the Postfix-specific XCLIENT SMTP command to safely
+simulate connections from remote systems before any remote systems are able to
+connect. If the test results look good, revert the above settings to the
+required production values. Typical settings in the pre-filter input instance
+include:
+
+    /etc/postfix-in/main.cf
+        #
+        # ...
+        #
+
+        # No local delivery on border gateway
+        #
+        mydestination =
+        alias_maps =
+        alias_database =
+        local_recipient_maps =
+        local_transport = error:5.1.1 Mailbox unavailable
+
+        # Don't rewrite remote headers
+        #
+        local_header_rewrite_clients =
+
+        # All recipients of not yet filtered email go to the same filter
+    together.
+        #
+        # With multiple instances, the content-filter is specified
+        # via transport settings not the "content_filter" transport
+        # switch override! Here the filter listens on local port 10025.
+        #
+        # If you need to route some users or recipient domains directly to the
+        # output instance bypassing the filter, just define a transport table
+        # with suitable entries.
+        #
+        default_transport = smtp:[127.0.0.1]:10025
+        relay_transport = $default_transport
+        virtual_transport = $default_transport
+        transport_maps =
+
+        # Pass original client log information through the filter.
+        #
+        smtp_send_xforward_command = yes
+
+        # Avoid splitting the envelope and scanning messages multiple times.
+        # Match the re-injection server's recipient limit.
+        #
+        smtp_destination_recipient_limit = 1000
+
+        # Tolerate occasional high latency in the content filter.
+        #
+        smtp_data_done_timeout = 1200s
+
+        # With xforward, match the output instance setting, if you
+        # want "yes", set both to "yes".
+        #
+        smtpd_client_port_logging = no
+
+        # ... Lots of settings for inbound MX host ...
+
+With the "input" instance configured, enable and start it:
+
+    # postmulti -i postfix-in -x postconf -e \
+        "master_service_disable =" "authorized_submit_users = root"
+    # postmulti -i postfix-in -e enable
+    # postmulti -i postfix-in -p start
+
+That's it. You now have a 3-instance configuration. A null-client sending all
+locally submitted mail to the internal mail hub and a pair of "mta" instances
+that receive mail from the Internet, pass it through a content-filter, and then
+deliver it to the internal destination.
+
+Running "postfix start" or "postfix stop" will now start/stop all three Postfix
+instances. You can use "postfix -c /config/path start" to start just one
+instance, or use the instance name (or instance group name) via postmulti(1):
+
+    # postmulti -i - -p stop
+    # postmulti -g mta -p status
+    # postmulti -i postfix-out -p flush
+    # postmulti -i postfix-in -p reload
+    # ...
+
+This example ends the multi-instance "walk through". The remainder of this
+document provides background information on Postfix multi-instance support
+features and options.
+
+CCoommppoonneennttss ooff aa PPoossttffiixx ssyysstteemm
+
+A Postfix system consists of the following components:
+
+Shared among all instances:
+
+  * Command-line utilities for administrators and users installed in
+    $command_directory, $sendmail_path, $mailq_path and $newaliases_path.
+
+  * Daemon executables, and run-time support files installed in
+    $daemon_directory.
+
+  * Bundled documentation, installed in $html_directory, $manpage_directory and
+    $readme_directory.
+
+  * Entries in /etc/passwd and /etc/group for the $mail_owner user and
+    $setgid_group group. The $mail_owner user provides the mail system with a
+    protected (non-root) execution context. The $setgid_group group is used
+    exclusively to support the setgid postdrop(1) and postqueue(1) utilities
+    (it mmuusstt nnoott be the primary group or secondary group of any users,
+    including the $mail_owner user).
+
+Private to each instance:
+
+  * The main.cf, master.cf (and other optional) configuration files in
+    $config_directory.
+
+  * The maildrop, incoming, active, deferred and hold queues in
+    $queue_directory (which contains additional directories needed by Postfix,
+    and which optionally doubles as a chroot jail for Postfix daemon
+    processes).
+
+  * Various caches (TLS session, address verification, ...) in $data_directory.
+
+The Postfix configuration parameters mentioned above are collectively referred
+to as "installation parameters". Their default values are set when the Postfix
+software is built from source, and all but one may be optionally set to a non-
+default value via the main.cf file. The one parameter that (catch-22) cannot be
+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
+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
+master(8) daemons each with its own configuration files, queue directory and
+data directory.
+
+These multiple running copies of master(8) share the base Postfix software.
+They do not (and cannot) share their configuration directories, queue
+directories or data directories.
+
+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
+
+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".
+
+The default 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.
+
+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
+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
+in the default compiled-in location.
+
+IInnssttaannccee ggrroouuppss
+
+The postmulti(1) multi-instance manager supports the notion of an instance
+"group". Typically, the member instances of an instance group constitute a
+logical service, and are expected to all be running or all be stopped.
+
+In many cases a single Postfix instance will be a complete logical "service".
+You should define such instances as stand-alone instances that are not members
+of any instance "group". The null-client instance is an example of a non-group
+instance.
+
+When a logical service consists of multiple Postfix instances, often a pair of
+pre-filter and post-filter instances with a content filter proxy between them,
+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
+parameter lists the configuration directories of all secondary (non-default)
+instances. Together with the default 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
+the output stages started and ready to receive mail before the input stages are
+started.
+
+MMuullttii--iinnssttaannccee ccoonnffiigguurraattiioonn ppaarraammeetteerrss
+
+multi_instance_wrapper
+    This default-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
+    the secondary instances controlled via the multi-instance manager.
+    Instances are listed in their "start" order, with the default 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
+    effect.
+
+    Do not assign a non-empty list of secondary instance configuration
+    directories to multi_instance_directories until you have configured a
+    suitable multi_instance_wrapper setting! This is best accomplished via the
+    "postmulti -e init" command.
+
+multi_instance_name
+    Each Postfix instance may be assigned a distinct name (with "postfix -
+    e create/import/assign -I name..."). This name can be used with the
+    postmulti(1) command-line utility to perform tasks on the instance by name
+    (rather than the full pathname of its configuration directory). Choose a
+    name that concisely captures the role of the instance (it must start with
+    "postfix-"). It is an error for two instances to have the same
+    $multi_instance_name. You can leave an instance "nameless" by leaving this
+    parameter at the default empty setting.
+
+    To avoid confusion in your logs, if you don't assign each secondary
+    instance a non-empty (distinct) $multi_instance_name, you should make sure
+    that the $syslog_name setting is different for each instance. The
+    $syslog_name parameter defaults to $multi_instance_name when the latter is
+    non-empty. If at all possible, the syslog_name should start with "postfix-
+    ", this helps log parsers to identify log entries from secondary Postfix
+    instances.
+
+multi_instance_group
+    Each Postfix instance may be assigned an "instance group" name (with
+    "postfix -e create/import/assign -G name..."). The default (empty) value of
+    multi_instance_group parameter indicates a stand-alone instance that is not
+    part of any group. The group name can be used with the postmulti(1)
+    command-line utility to perform a task on the members of a group by name.
+    Choose a single-word group name that concisely captures the role of the
+    group.
+
+multi_instance_enable
+    This parameter controls whether a Postfix instance will be started by a
+    Postfix multi-instance manager. The default value is "no". The instance can
+    be started explicitly with "postfix -c /path/to/config/directory"; this is
+    useful for testing.
+
+    When an instance is disabled, the postfix(1) "start" command is replaced by
+    "check".
+
+    Some postfix(1) commands (such as "stop", "flush", ...) require a running
+    Postfix instance, and skip instances that are disabled.
+
+    Other postfix(1) commands (such as "status", "set-permissions", "upgrade-
+    configuration", ...) do not require a running Postfix system, and apply to
+    all instances whether enabled or not.
+
+The postmulti(1) utility can be used to create (or destroy) instances. It can
+also be used to "import" or "deport" existing instances into or from the list
+of managed instances. When using postmulti(1) to manage instances, the above
+configuration parameters are managed for you automatically. See below.
+
+UUssiinngg tthhee ppoossttmmuullttii((11)) ccoommmmaanndd
+
+  * Initializing the multi-instance manager
+  * Listing managed instances
+  * Starting or stopping a multi-instance system
+  * Ad-hoc multi-instance operations
+  * Creating a new Postfix instance
+  * Destroying a Postfix instance
+  * Importing an existing Postfix instance
+  * Deporting a managed Postfix instance
+  * Assigning a new name or group name
+  * Enabling/disabling managed instances
+
+IInniittiiaalliizziinngg tthhee mmuullttii--iinnssttaannccee mmaannaaggeerr
+
+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
+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:
+
+        # 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
+        #
+        multi_instance_enable = yes
+
+If you prefer, you can make these changes by editing the default 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
+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 -".
+
+    # postmulti -l -a
+    # postmulti -l -g a_group
+    # postmulti -l -i an_instance
+
+The output is one line per instance (in "postfix start" order):
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |nnaammee   |ggrroouupp|eennaabblleedd|ccoonnffiigg__ddiirreeccttoorryy    |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |-      |-    |yes    |/etc/postfix        |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |mta-out|mta  |yes    |/etc/postfix/mta-out|
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |mta-in |mta  |yes    |/etc/postfix-mta-in |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |msa-out|msa  |yes    |/etc/postfix-msa-out|
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |msa-in |msa  |yes    |/etc/postfix-msa-in |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |test   |-    |no     |/etc/postfix-test   |
+    |_ _ _ _ _ _ _ _|_ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+The first line showing the column headings is not part of the output. When
+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.
+
+To list instances in reverse start order, include the "-R" option together with
+the instance selection options.
+
+SSttaarrttiinngg oorr ssttooppppiinngg aa mmuullttii--iinnssttaannccee ssyysstteemm
+
+To start, stop, reload, etc. the complete (already configured as above) multi-
+instance system just use postfix(1) as you would with a single-instance system.
+The Postfix multi-instance wrapper framework insulates Postfix init.d start and
+package upgrade scripts from the details of multi-instance management!
+
+The --pp option of postmulti(1) turns on postfix(1) compatibility mode. With this
+option the remaining arguments are exactly those supported by postfix(1), but
+commands are applied to all instances or all enabled instances as appropriate.
+As described above, this switch is required when using postmulti(1) as the
+multi_instance_wrapper.
+
+If you want to specify a subset of instances by name, or group name, or run
+arbitrary commands (not just "postfix stop/start/etc. in the context
+(MAIL_CONFIG environment variable setting) of a particular instance or group of
+instances, then you can use the instance-aware postmulti(1) utility directly.
+
+AAdd--hhoocc mmuullttii--iinnssttaannccee ooppeerraattiioonnss
+
+The postmulti(1) command can be used by the administrator to run arbitrary
+commands in the context of one or more Postfix instances. The most common use-
+case is stopping or starting a group of Postfix instances:
+
+    # postmulti -g mygroup -p start
+    # postmulti -g mygroup -p flush
+    # postmulti -g mygroup -p reload
+    # postmulti -g mygroup -p status
+    # postmulti -g mygroup -p stop
+    # postmulti -g mygroup -p upgrade-configuration
+
+The --pp option is essentially a short-hand for a leading ppoossttffiixx command
+argument, but with appropriate additional options turned on depending on the
+first argument. In the case of "start", disabled instances are "checked"
+(postfix check) rather than simply skipped.
+
+The resulting command is executed for each candidate instance with the
+MMAAIILL__CCOONNFFIIGG environment variable set to the configuration directory of the
+corresponding Postfix instance.
+
+The postmulti(1) utility is able to launch commands other than postfix(1), Use
+the --xx option to ask postmulti to execute an ad-hoc command for all instances,
+a group of instances, or just one instance. With ad-hoc commands the
+multi_instance_enable parameter is ignored: the command is unconditionally
+executed for the instances selected via -a, -g or -i. In addition to
+MAIL_CONFIG, the following instance parameters are exported into the command
+environment:
+
+    command_directory=$command_directory
+    daemon_directory=$daemon_directory
+    config_directory=$config_directory
+    queue_directory=$queue_directory
+    data_directory=$data_directory
+    multi_instance_name=$multi_instance_name
+    multi_instance_group=$multi_instance_group
+    multi_instance_enable=$multi_instance_enable
+
+The config_directory setting is of course the same as MAIL_CONFIG, and is
+arguably redundant, but leaving it in is less surprising. If you want to skip
+disabled instances, just check multi_instance_enable environment variable and
+exit if it is set to "no".
+
+The ability to run ad-hoc commands opens up a wealth of additional
+possibilities:
+
+  * Specify an instance by name rather than configuration directory when using
+    sendmail(1) to send a verification probe:
+
+        $ postmulti -i postfix-myinst -x sendmail -bv test@example.net
+
+  * Display non-default main.cf settings of all Postfix instances. This uses an
+    inline shell script to package together multiple shell commands to execute
+    for each instance:
+
+        $ postmulti -x sh -c 'echo "-- $MAIL_CONFIG"; postconf -n'
+
+  * Put all mail in enabled member instances of a group on hold:
+
+        # postmulti -g group_name -x \
+            sh -c 'test $multi_instance_enable = yes && postsuper -h ALL'
+
+  * Show top 10 domains in the deferred queue of all instances:
+
+        # postmulti -x sh -c 'echo "-- $MAIL_CONFIG"; qshape deferred | head -
+        12'
+
+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:
+
+    authorized_submit_users =
+    master_service_disable = inet
+
+The above settings ensure that new instances are safe to start immediately:
+they will not conflict with inet listeners in existing Postfix instances. They
+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:
+
+    config_directory = /conf-path/postfix
+    queue_directory = /queue-path/postfix
+    data_directory = /data-path/postfix
+
+A newly-created instance named postfix-myinst will by default have:
+
+    multi_instance_enable = no
+    multi_instance_name = postfix-myinst
+    config_directory = /conf-path/postfix-myinst
+    queue_directory = /queue-path/postfix-myinst
+    data_directory = /data-path/postfix-myinst
+
+You can override any of these defaults when creating the instance, but unless
+you want to spread instance queue directories over multiple file-systems, use
+the default naming strategy. It keeps the multiple instances organized in a
+uniform, predictable fashion.
+
+When specifying the instance name later, you can refer to it either as
+"postfix-myinst", or via the full path of the configuration directory.
+
+To create a new instance just use the --ee ccrreeaattee option:
+
+    # postmulti -I postfix-myinst -e create
+
+If the new instance is to belong to a group of related instances that implement
+a single logical service, assign it to a group:
+
+    # postmulti -I postfix-myinst -G mygroup -e create
+
+If you want to override the conventional values of the instance installation
+parameters, specify their values on the command-line:
+
+    # postmulti [-I postfix-myinst] [-G mygroup] -e create \
+            "config_directory = /path/to/config_directory" \
+            "queue_directory = /path/to/queue_directory" \
+            "data_directory = /path/to/data_directory"
+
+A note on the --II and --GG options above. These are always used to assign a name
+or group name to an instance, while the --ii and --gg options always select
+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).
+
+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
+instance-name based value is acceptable. Otherwise, all three instance
+installation parameters are required. You should set the "syslog_name"
+explicitly in the main.cf file of a "nameless" instance, in order to avoid
+confusion in the mail logs when multiple instances are in use.
+
+DDeessttrrooyyiinngg aa PPoossttffiixx iinnssttaannccee
+
+If you no longer need an instance, you can destroy it via:
+
+    # postmulti -i postfix-myinst -p stop
+    # postmulti -i postfix-myinst -e disable
+    # postmulti -i postfix-myinst -e destroy
+
+The instance must be stopped, disabled and have no queued messages. This is
+expected to fully delete a just created instance that has never been used. If
+the instance is not freshly created, files added after the instance was created
+will remain in the configuration, queue or data directories, in which case the
+corresponding directory may not be fully removed and a warning to that effect
+will be displayed. You can complete the destruction of the instance manually by
+removing any unwanted remnants of the instance-specific "private" directories.
+
+IImmppoorrttiinngg aann eexxiissttiinngg PPoossttffiixx iinnssttaannccee
+
+If you already have an existing secondary Postfix instance that is not yet
+managed via postmulti(1), you can "import" it into the list of managed
+instances. If your instance is already using the default configuration
+directory naming scheme, just specify the corresponding instance name (the
+multi_instance_name parameter in its configuration file will be adjusted to
+match this name if necessary):
+
+    # postmulti -I postfix-myinst [-G mygroup] -e import
+
+Otherwise, you must specify the location of its configuration directory:
+
+    # postmulti [-I postfix-myinst] [-G mygroup] -e import \
+            "config_directory = /path/of/config_directory"
+
+When the instance is imported, you can assign a name or a group. As with
+"create", you can control the placement of the new instance in the start order
+by using "-i", "-g" or "-a" to prepend before the selected instance or
+instances.
+
+An imported instance is usually not multi-instance "enabled", unless it was
+part of a multi-instance configuration at an earlier time. If it is fully
+configured and ready to run, don't forget to enable it and if necessary start
+it. When other enabled instances are already running, new instances need to be
+started individually when they are first created or imported.
+
+To find out what instances are running, use:
+
+    # postfix status
+
+DDeeppoorrttiinngg aa mmaannaaggeedd PPoossttffiixx iinnssttaannccee
+
+You can "deport" an existing instance from the list of managed instances. This
+does not destroy the instance, rather the instance just becomes a stand-alone
+Postfix instance not registered with the multi-instance manager. postmulti(1)
+will refuse to "deport" an instance that is not stopped and disabled.
+
+    # postmulti -i postfix-myinst -p stop
+    # postmulti -i postfix-myinst -e disable
+    # postmulti -i postfix-myinst -e deport
+
+AAssssiiggnniinngg aa nneeww nnaammee oorr ggrroouupp nnaammee
+
+You can assign a new name or new group to a managed instance. Use "-" as the
+new value to assign the instance to no group or make it nameless. To specify a
+nameless secondary instance use the configuration directory path instead of the
+old name:
+
+    # postmulti -i postfix-old [-I postfix-new] [-G newgroup] -e assign
+
+EEnnaabblliinngg//ddiissaabblliinngg mmaannaaggeedd iinnssttaanncceess
+
+You can enable or disable a managed instance. As documented in postfix-wrapper
+(5), disabled instances are skipped with actions that start, stop or control
+running Postfix instances.
+
+    # postmulti -i postfix-myinst -e enable
+    # postmulti -i postfix-myinst -e disable
+
+CCrreeddiittss
+
+Wietse Venema created Postfix, designed and implemented the multi-instance
+wrapper framework and provided design feedback that made the postmulti(1)
+utility much more general and useful than originally envisioned.
+
+The postmulti(1) utility was developed by Victor Duchovni of Morgan Stanley,
+who also wrote the initial version of this document.
+
--- a/README_FILES/MYSQL_README
+++ b/README_FILES/MYSQL_README
@ -0,0 +1,135 @@
+PPoossttffiixx MMyySSQQLL HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+The Postfix mysql map type allows you to hook up Postfix to a MySQL database.
+This implementation allows for multiple mysql databases: you can use one for a
+virtual(5) table, one for an access(5) table, and one for an aliases(5) table
+if you want. You can specify multiple servers for the same database, so that
+Postfix can switch to a good database server if one goes bad.
+
+Busy mail servers using mysql maps will generate lots of concurrent mysql
+clients, so the mysql server(s) should be run with this fact in mind. You can
+reduce the number of concurrent mysql clients by using the Postfix proxymap(8)
+service.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh MMyySSQQLL 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.
+
+Note: to use mysql with Debian GNU/Linux's Postfix, all you need is to install
+the postfix-mysql package and you're done. There is no need to recompile
+Postfix.
+
+The Postfix MySQL client utilizes the mysql client library, which can be
+obtained from:
+
+    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"
+
+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-
+loaded MySQL database client, but only the new AUXLIBS_MYSQL variable supports
+building a dynamically-loaded or statically-loaded MySQL database client.
+
+    Failure to use the AUXLIBS_MYSQL variable will defeat the purpose of
+    dynamic database client loading. Every Postfix executable file will have
+    MYSQL database library dependencies. And that was exactly what dynamic
+    database client loading was meant to avoid.
+
+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"
+
+Then, just run 'make'. This requires libz, the compression library. Older mysql
+implementations build without libz.
+
+UUssiinngg MMyySSQQLL ttaabblleess
+
+Once Postfix is built with mysql support, you can specify a map type in main.cf
+like this:
+
+    alias_maps = mysql:/etc/postfix/mysql-aliases.cf
+
+The file /etc/postfix/mysql-aliases.cf specifies lots of information telling
+Postfix how to reference the mysql database. For a complete description, see
+the mysql_table(5) manual page.
+
+EExxaammppllee:: llooccaall aalliiaasseess
+
+#
+# mysql config file for local(8) aliases(5) lookups
+#
+
+# The user name and password to log into the mysql server.
+user = someone
+password = some_password
+
+# The database name on the servers.
+dbname = customer_database
+
+# For Postfix 2.2 and later The SQL query template.
+# See mysql_table(5) for details.
+query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
+
+# For Postfix releases prior to 2.2. See mysql_table(5) for details.
+select_field = forw_addr
+table = mxaliases
+where_field = alias
+# Don't forget the leading "AND"!
+additional_conditions = AND status = 'paid'
+
+# This is necessary to make UTF8 queries work for Postfix 2.11 .. 3.1,
+# and is the default setting as of Postfix 3.2.
+option_group = client
+
+AAddddiittiioonnaall nnootteess
+
+Postfix 3.2 and later read [[cclliieenntt]] option group settings by default. To
+disable this, specify no ooppttiioonn__ffiillee and specify "ooppttiioonn__ggrroouupp ==" (i.e. an
+empty value).
+
+Postfix 3.1 and earlier don't read [[cclliieenntt]] option group settings unless a non-
+empty ooppttiioonn__ffiillee or ooppttiioonn__ggrroouupp value are specified. To enable this, specify,
+for example "ooppttiioonn__ggrroouupp == cclliieenntt".
+
+The MySQL configuration interface setup allows for multiple mysql databases:
+you can use one for a virtual table, one for an access table, and one for an
+aliases table if you want.
+
+Since sites that have a need for multiple mail exchangers may enjoy the
+convenience of using a networked mailer database, but do not want to introduce
+a single point of failure to their system, we've included the ability to have
+Postfix reference multiple hosts for access to a single mysql map. This will
+work if sites set up mirrored mysql databases on two or more hosts. Whenever
+queries fail with an error at one host, the rest of the hosts will be tried in
+random order. If no mysql server hosts are reachable, then mail will be
+deferred until at least one of those hosts is reachable.
+
+CCrreeddiittss
+
+  * The initial version was contributed by Scott Cotton and Joshua Marcus, IC
+    Group, Inc.
+  * Liviu Daia revised the configuration interface and added the main.cf
+    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 PostgreSQL.
+
--- a/README_FILES/NFS_README
+++ b/README_FILES/NFS_README
@ -0,0 +1,102 @@
+PPoossttffiixx aanndd NNFFSS
+
+-------------------------------------------------------------------------------
+
+PPoossttffiixx ssuuppppoorrtt ssttaattuuss ffoorr NNFFSS
+
+What is the status of support for Postfix on NFS? The answer is that Postfix
+itself is supported when you use NFS, but there is no promise that an NFS-
+related problem will promptly receive a Postfix workaround, or that a
+workaround will even be possible.
+
+That said, Postfix will in many cases work very well on NFS, because Postfix
+implements a number of workarounds (see below). Good NFS implementations seldom
+if ever give problems with Postfix, so Wietse recommends that you spend your
+money wisely.
+
+PPoossttffiixx ffiillee lloocckkiinngg aanndd NNFFSS
+
+For the Postfix mail queue, it does not matter how well NFS file locking works.
+The reason is that you cannot share Postfix queues among multiple running
+Postfix instances. You can use NFS to switch a Postfix mail queue from one NFS
+client to another one, but only one NFS client can access a Postfix mail queue
+at any particular point in time.
+
+For mailbox file sharing with NFS, your options are to use ffccnnttll (kernel
+locks), ddoottlloocckk (username.lock files), to use both locking methods
+simultaneously, or to switch to maildir format. The maildir format uses one
+file per message and needs no file locking support in Postfix or in other mail
+software.
+
+Many sites that use mailbox format play safe and use both locking methods
+simultaneously.
+
+    /etc/postfix/main.cf:
+        virtual_mailbox_lock = fcntl, dotlock
+        mailbox_delivery_lock = fcntl, dotlock
+
+PPoossttffiixx NNFFSS wwoorrkkaarroouunnddss
+
+The list below summarizes the workarounds that exist for running Postfix on NFS
+as of the middle of 2003. As a reminder, Postfix itself is still supported when
+it runs on NFS, but there is no promise that an NFS-related problem will
+promptly receive a Postfix workaround, or that a workaround will even be
+possible.
+
+  * Problem: when renaming a file, the operation may succeed but report an
+    error anyway[1].
+
+    Workaround: when rename(old, new) reports an error, Postfix checks if the
+    new name exists and the old name is gone. If the check succeeds, Postfix
+    assumes that the rename() operation completed normally.
+
+  * Problem: when creating a directory, the operation may succeed but report an
+    error anyway[1].
+
+    Workaround: when mkdir(new) reports an EEXIST error, Postfix checks if the
+    new name resolves to a directory. If the check succeeds, Postfix assumes
+    that the mkdir() operation completed normally.
+
+  * Problem: when creating a hardlink to a file, the operation may succeed but
+    report an error anyway[1].
+
+    Workaround: when link(old, new) fails, Postfix compares the device and
+    inode number of the old and new files. When the two files are identical,
+    Postfix assumes that the link() operation completed normally.
+
+  * Problem: when creating a dotlock (username.lock) file, the operation may
+    succeed but report an error anyway[1].
+
+    Workaround: in this case, the only safe action is to back off and try again
+    later.
+
+  * Problem: when a file server's "time of day" clock is not synchronized with
+    the client's "time of day" clock, email deliveries are delayed by a minute
+    or more.
+
+    Workaround: Postfix explicitly sets file time stamps to avoid delays with
+    new mail (Postfix uses "last modified" file time stamps to decide when a
+    queue file is ready for delivery).
+
+[1] How can an operation succeed and report an error anyway?
+
+Suppose that an NFS server executes a client request successfully, and that the
+server's reply to the client is lost. After some time the client retransmits
+the request to the server. Normally, the server remembers that it already
+completed the request (it keeps a list of recently-completed requests and
+replies), and simply retransmits the reply.
+
+However, when the server has rebooted or when it has been very busy, the server
+no longer remembers that it already completed the request, and repeats the
+operation. This causes no problems with file read/write requests (they contain
+a file offset and can therefore be repeated safely), but fails with non-
+idempotent operations. For example, when the server executes a retransmitted
+rename() request, the server reports an ENOENT error because the old name does
+not exist; and when the server executes a retransmitted link(), mkdir() or
+create() request, the server reports an EEXIST error because the name already
+exists.
+
+Thus, successful, non-idempotent, NFS operations will report false errors when
+the server reply is lost, the client retransmits the request, and the server
+does not remember that it already completed the request.
+
--- a/README_FILES/OVERVIEW
+++ b/README_FILES/OVERVIEW
@ -0,0 +1,496 @@
+PPoossttffiixx AArrcchhiitteeccttuurree OOvveerrvviieeww
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+This document presents an overview of the Postfix architecture, and provides
+pointers to descriptions of every Postfix command or server program. The text
+gives the general context in which each command or server program is used, and
+provides pointers to documents with specific usage examples and background
+information.
+
+Topics covered by this document:
+
+  * How Postfix receives mail
+  * How Postfix delivers mail
+  * Postfix behind the scenes
+  * Postfix support commands
+
+HHooww PPoossttffiixx rreecceeiivveess mmaaiill
+
+When a message enters the Postfix mail system, the first stop on the inside is
+the incoming queue. The figure below shows the main processes that are involved
+with new mail. Names followed by a number are Postfix commands or server
+programs, while unnumbered names inside shaded areas represent Postfix queues.
+
+                               trivial-
+                              rewrite(8)
+
+    Network ->   smtpd(8)
+
+                                    ^ |
+                           \        | v
+
+    Network ->   qmqpd(8)  -> cleanup(8)  -> incoming
+
+                           /
+
+                pickup(8)  <-   maildrop
+
+                                     ^
+                                     |
+
+    Local   -> sendmail(1) -> postdrop(1)
+
+  * Network mail enters Postfix via the smtpd(8) or qmqpd(8) servers. These
+    servers remove the SMTP or QMQP protocol encapsulation, enforce some sanity
+    checks to protect Postfix, and give the sender, recipients and message
+    content to the cleanup(8) server. The smtpd(8) server can be configured to
+    block unwanted mail, as described in the SMTPD_ACCESS_README document.
+
+  * Local submissions are received with the Postfix sendmail(1) compatibility
+    command, and are queued in the maildrop queue by the privileged postdrop(1)
+    command. This arrangement even works while the Postfix mail system is not
+    running. The local pickup(8) server picks up local submissions, enforces
+    some sanity checks to protect Postfix, and gives the sender, recipients and
+    message content to the cleanup(8) server.
+
+  * Mail from internal sources is given directly to the cleanup(8) server.
+    These sources are not shown in the figure, and include: mail that is
+    forwarded by the local(8) delivery agent (see next section), messages that
+    are returned to the sender by the bounce(8) server (see second-next
+    section), and postmaster notifications about problems with Postfix.
+
+  * The cleanup(8) server implements the final processing stage before mail is
+    queued. It adds missing From: and other message headers, and transforms
+    addresses as described in the ADDRESS_REWRITING_README document.
+    Optionally, the cleanup(8) server can be configured to do light-weight
+    content inspection with regular expressions as described in the
+    BUILTIN_FILTER_README document. The cleanup(8) server places the result as
+    a single file into the incoming queue, and notifies the queue manager (see
+    next section) of the arrival of new mail.
+
+  * The trivial-rewrite(8) server rewrites addresses to the standard
+    "user@fully.qualified.domain" form, as described in the
+    ADDRESS_REWRITING_README document. Postfix currently does not implement a
+    rewriting language, but a lot can be done via table lookups and, if need
+    be, regular expressions.
+
+HHooww PPoossttffiixx ddeelliivveerrss mmaaiill
+
+Once a message has reached the incoming queue the next step is to deliver it.
+The figure shows the main components of the Postfix mail delivery apparatus.
+Names followed by a number are Postfix commands or server programs, while
+unnumbered names inside shaded areas represent Postfix queues.
+
+                             trivial-        smtp(8)  -> Network
+                            rewrite(8)
+                                         /
+
+                                         -   lmtp(8)  -> Network
+                                 ^ |
+                                 | v   /
+
+    incoming ->  active  ->   qmgr(8)  ---  local(8)  -> File, command
+
+                                       \
+                   ^ |
+                   | v                   - virtual(8) -> File
+
+                deferred                 \
+
+                                             pipe(8)  -> Command
+
+  * The queue manager (the qmgr(8) server process in the figure) is the heart
+    of Postfix mail delivery. It contacts the smtp(8), lmtp(8), local(8),
+    virtual(8), pipe(8), discard(8) or error(8) delivery agents, and sends a
+    delivery request for one or more recipient addresses. The discard(8) and
+    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 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.
+
+    The queue manager maintains a separate deferred queue for mail that cannot
+    be delivered, so that a large mail backlog will not slow down normal queue
+    accesses. The queue manager's strategy for delayed mail delivery attempts
+    is described in the QSHAPE_README and TUNING_README documents.
+
+  * The trivial-rewrite(8) server resolves each recipient address according to
+    its local or remote address class, as defined in the ADDRESS_CLASS_README
+    document. Additional routing information can be specified with the optional
+    transport(5) table. The trivial-rewrite(8) server optionally queries the
+    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 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
+    that one Postfix machine can feed multiple mailbox servers over LMTP. The
+    opposite is true as well: one mailbox server can be fed over LMTP by
+    multiple Postfix machines.
+
+  * The local(8) delivery agent understands UNIX-style mailboxes, qmail-
+    compatible maildir files, Sendmail-style system-wide aliases(5) databases,
+    and Sendmail-style per-user .forward files. Multiple local delivery agents
+    can be run in parallel, but parallel delivery to the same user is usually
+    limited.
+
+    The local(8) delivery agent has hooks for alternative forms of local
+    delivery: you can configure it to deliver to mailbox files in user home
+    directories, you can configure it to delegate mailbox delivery to an
+    external command such as procmail, or you can delegate delivery to a
+    different Postfix delivery agent.
+
+  * The virtual(8) delivery agent is a bare-bones delivery agent that delivers
+    to UNIX-style mailbox or qmail-style maildir files only. This delivery
+    agent can deliver mail for multiple domains, which makes it especially
+    suitable for hosting lots of small domains on a single machine. This is
+    described in the VIRTUAL_README document.
+
+  * 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: 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
+
+The previous sections gave an overview of how Postfix server processes send and
+receive mail. These server processes rely on other server processes that do
+things behind the scenes. The text below attempts to visualize each service in
+its own context. As before, names followed by a number are Postfix commands or
+server programs, while unnumbered names inside shaded areas represent Postfix
+queues.
+
+  * The resident master(8) server is the supervisor that keeps an eye on the
+    well-being of the Postfix mail system. It is typically started at system
+    boot time with the "postfix start" command, and keeps running until the
+    system goes down. The master(8) server is responsible for starting Postfix
+    server processes to receive and deliver mail, and for restarting servers
+    that terminate prematurely because of some problem. The master(8) server is
+    also responsible for enforcing the server process count limits as specified
+    in the mmaasstteerr..ccff configuration file. The picture below gives the program
+    hierarchy when Postfix is started up. Only some of the mail handling daemon
+    processes are shown.
+
+                          postfix(1)
+
+                                 |
+                                 |
+
+                     postfix-script(1)
+
+                   /             |     \
+                                 |
+                 /                       \
+
+    postsuper(1)           master(8)       postlog(1)
+
+                   /             |     \
+                                 |
+                 /                       \
+
+       smtpd(8)             qmgr(8)         local(8)
+
+  * The anvil(8) server implements client connection and request rate limiting
+    for all smtpd(8) servers. The TUNING_README document provides guidance for
+    dealing with mis-behaving SMTP clients. The anvil(8) service is available
+    in Postfix version 2.2 and later.
+
+    Network -> smtpd(8) <-> anvil(8)
+
+  * The bounce(8), defer(8) and trace(8) services each maintain their own queue
+    directory trees with per-message logfiles. Postfix uses this information
+    when sending "failed", "delayed" or "success" delivery status notifications
+    to the sender.
+
+    The trace(8) service also implements support for the Postfix "sendmail -bv"
+    and "sendmail -v" commands which produce reports about how Postfix delivers
+    mail, and is available with Postfix version 2.1 and later. See DEBUG_README
+    for examples.
+
+                   qmgr(8)      Delivery
+    cleanup(8) ->  Postfix  ->   agents
+                    queue
+
+          ^             |            |
+          |             v            v
+
+      (Non-)      bounce(8)    Queue id,
+     delivery  <- defer(8)  <- recipient,
+      notice      trace(8)       status
+
+                      ^ |
+                      | v
+
+                    Per-
+                   message
+                  logfiles
+
+  * 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
+                                     ^
+                                  deferred
+
+                                        ^
+                                        |
+
+      smtpd(8)     Destination                   Deferred     Delivery
+    sendmail(1)  -  to flush   -> flush(8)  <- destination, - agents,
+    postqueue(1)                                 queue id     qmgr(8)
+
+                                      ^ |
+                                      | v
+
+                                  Per-dest-
+                                   ination
+                                    logs
+
+  * The proxymap(8) servers provide read-only and read-write table lookup
+    service to Postfix processes. This overcomes chroot restrictions, reduces
+    the number of open lookup tables by sharing one open table among multiple
+    processes, and implements single-updater tables.
+
+  * The scache(8) server maintains the connection cache for the Postfix smtp(8)
+    client. When connection caching is enabled for selected destinations, the
+    smtp(8) client does not disconnect immediately after a mail transaction,
+    but gives the connection to the connection cache 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 smtp(8) process can
+    ask the scache(8) server for that cached connection and reuse it for mail
+    delivery. As a safety measure, Postfix limits the number of times that a
+    connection may be reused.
+
+    When delivering mail to a destination with multiple mail servers,
+    connection caching can help to skip over a non-responding server, and thus
+    dramatically speed up delivery. SMTP connection caching is available in
+    Postfix version 2.2 and later. More information about this feature is in
+    the CONNECTION_CACHE_README document.
+
+            /--  smtp(8)  --> Internet
+
+    qmgr(8)
+                |
+            \-- |    smtp(8)
+                |
+                |     ^
+                v     |
+
+                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)
+    commands.
+
+              mailq(1)                 Postfix
+    Output <-   post-   <- showq(8) <-  queue
+              queue(1)
+
+  * The spawn(8) servers run non-Postfix commands on request, with the client
+    connected via socket or FIFO to the command's standard input, output and
+    error streams. You can find examples of its use in the SMTPD_POLICY_README
+    document.
+
+  * The tlsmgr(8) server runs when TLS (Transport Layer Security, formerly
+    known as SSL) is turned on in the Postfix smtp(8) client or smtpd(8)
+    server. This process has two duties:
+
+      o Maintain the pseudo-random number generator (PRNG) that is used to seed
+        the TLS engines in Postfix smtp(8) client or smtpd(8) server processes.
+        The state of this PRNG is periodically saved to a file, and is read
+        when tlsmgr(8) starts up.
+
+      o Maintain the optional Postfix smtp(8) client or smtpd(8) server caches
+        with TLS session keys. Saved keys can improve performance by reducing
+        the amount of computation at the start of a TLS session.
+
+    TLS support is available in Postfix version 2.2 and later. Information
+    about the Postfix TLS implementation is in the TLS_README document.
+
+                        <---seed---            ---seed--->
+    Network-> smtpd(8)              tlsmgr(8)               smtp(8)  ->Network
+                        <-session->            <-session->
+
+                                  /       |    \
+                                          |
+                                /                \
+
+                         smtpd          PRNG        smtp
+                        session        state       session
+                         cache          file        cache
+
+  * The verify(8) server verifies that a sender or recipient address is
+    deliverable before the smtpd(8) server accepts it. The verify(8) server
+    queries a cache with address verification results. If a result is not
+    found, the verify(8) server injects a probe message into the Postfix queue
+    and processes the status update from a delivery agent or queue manager.
+    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
+    Network -> smtpd(8) <->   verify(8)  ->             queue
+
+                                                            |
+                                                            v
+
+                                         <-  probe     Postfix  -> Local
+                                            status  <- delivery -> Network
+                                    ^                   agents
+                                    |
+                                    v
+
+                              Address
+                            verification
+                               cache
+
+  * The postscreen(8) server can be put "in front" of Postfix smtpd(8)
+    processes. Its purpose is to accept connections from the network and to
+    decide what SMTP clients are allowed to talk to Postfix. According to the
+    2008 MessageLabs annual report, 81% of all email was spam, and 90% of that
+    was sent by botnets; by 2010, those numbers were 92% and 95%, respectively.
+    While postscreen(8) keeps the zombies away, more smtpd(8) processes remain
+    available for legitimate clients.
+
+    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 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.
+
+                zombie
+
+                         \
+
+    zombie - tlsproxy(8) -                    - smtpd(8)
+
+                           \               /
+
+                 other   --- postscreen(8)
+
+                           /               \
+
+                 other   -                    - smtpd(8)
+
+                         /
+
+                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
+
+The Postfix architecture overview ends with a summary of command-line utilities
+for day-to-day use of the Postfix mail system. Besides the Sendmail-compatible
+sendmail(1), mailq(1), and newaliases(1) commands, the Postfix system comes
+with it own collection of command-line utilities. For consistency, these are
+all named postsomething.
+
+  * The postfix(1) command controls the operation of the mail system. It is the
+    interface for starting, stopping, and restarting the mail system, as well
+    as for some other administrative operations. This command is reserved to
+    the super-user.
+
+  * The postalias(1) command maintains Postfix aliases(5) type databases. This
+    is the program that does the work for the newaliases(1) command.
+
+  * The postcat(1) command displays the contents of Postfix queue files. This
+    is a limited, preliminary utility. This program is likely to be superseded
+    by something more powerful that can also edit Postfix queue files.
+
+  * The postconf(1) command displays or updates Postfix main.cf parameters and
+    displays system dependent information about the supported file locking
+    methods, and the supported types of lookup tables.
+
+  * The postdrop(1) command is the mail posting utility that is run by the
+    Postfix sendmail(1) command in order to deposit mail into the maildrop
+    queue directory.
+
+  * The postkick(1) command makes some Postfix internal communication channels
+    available for use in, for example, shell scripts.
+
+  * The postlock(1) command provides Postfix-compatible mailbox locking for use
+    in, for example, shell scripts.
+
+  * The postlog(1) command provides Postfix-compatible logging for shell
+    scripts.
+
+  * The postmap(1) command maintains Postfix lookup tables such as canonical
+    (5), virtual(5) and others. It is a cousin of the UNIX makemap command.
+
+  * The postmulti(1) command repeats the "postfix start" etc. command for each
+    Postfix instance, and supports creation, deletion etc. of Postfix
+    instances. For a tutorial, see MULTI_INSTANCE_README.
+
+  * The postqueue(1) command is the privileged command that is run by Postfix
+    sendmail(1) and mailq(1) in order to flush or list the mail queue.
+
+  * The postsuper(1) command maintains the Postfix queue. It removes old
+    temporary files, and moves queue files into the right directory after a
+    change in the hashing depth of queue directories. This command is run at
+    mail system startup time and when Postfix is restarted.
+
--- a/README_FILES/PACKAGE_README
+++ b/README_FILES/PACKAGE_README
@ -0,0 +1,109 @@
+GGuuiiddeelliinneess ffoorr PPaacckkaaggee BBuuiillddeerrss
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document has hints and tips for those who manage their own Postfix binary
+distribution for internal use, and for those who maintain Postfix binary
+distributions for general use.
+
+GGeenneerraall ddiissttrriibbuuttiioonnss:: pplleeaassee pprroovviiddee aa ssmmaallll ddeeffaauulltt mmaaiinn..ccff ffiillee
+
+The installed main.cf file must be small. PLEASE resist the temptation to list
+all parameters in the main.cf file. Postfix is supposed to be easy to
+configure. Listing all parameters in main.cf defeats the purpose. It is an
+invitation for hobbyists to make random changes without understanding what they
+do, and gets them into endless trouble.
+
+GGeenneerraall ddiissttrriibbuuttiioonnss:: pplleeaassee iinncclluuddee RREEAADDMMEE oorr HHTTMMLL ffiilleess
+
+Please provide the applicable README or HTML files. They are referenced by the
+Postfix manual pages and by other files. Without README or HTML files, Postfix
+will be difficult if not impossible to configure.
+
+PPoossttffiixx IInnssttaallllaattiioonn ppaarraammeetteerrss
+
+Postfix installation is controlled by a dozen installation parameters. See the
+postfix-install and post-install files for details. Most parameters have
+system-dependent default settings that are configurable at compile time, as
+described in the INSTALL file.
+
+PPrreeppaarriinngg aa pprree--bbuuiilltt ppaacckkaaggee ffoorr ddiissttrriibbuuttiioonn ttoo ootthheerr ssyysstteemmss
+
+You can build a Postfix package on a machine that does not have Postfix
+installed on it. All you need is Postfix source code and a compilation
+environment that is compatible with the target system.
+
+You can build a pre-built Postfix package as an unprivileged user.
+
+First compile Postfix. After successful compilation, execute:
+
+     % mmaakkee ppaacckkaaggee
+
+With Postfix versions before 2.2 you must invoke the post-install script
+directly (% sshh ppoosstt--iinnssttaallll).
+
+You will be prompted for installation parameters. Specify an install_root
+directory other than /. The mail_owner and setgid_group installation parameter
+settings will be recorded in the main.cf file, but they won't take effect until
+the package is unpacked and installed on the destination machine.
+
+If you want to fully automate this process, specify all the non-default
+installation parameters on the command line:
+
+     % mmaakkee nnoonn--iinntteerraaccttiivvee--ppaacckkaaggee iinnssttaallll__rroooott==//ssoommee//wwhheerree...
+
+With Postfix versions before 2.2 you must invoke the post-install script
+directly (% sshh ppoosstt--iinnssttaallll --nnoonn--iinntteerraaccttiivvee iinnssttaallll__rroooott......).
+
+With Postfix 3.0 and later, the command "make package name=value ..." will
+replace the string MAIL_VERSION in a configuration parameter value with the
+Postfix release version. Do not try to specify something like $mail_version on
+this command line. This produces inconsistent results with different versions
+of the make(1) command.
+
+BBeeggiinn SSeeccuurriittyy AAlleerrtt
+
+WWhheenn bbuuiillddiinngg aann aarrcchhiivvee ffoorr ddiissttrriibbuuttiioonn,, bbee ssuurree ttoo aarrcchhiivvee oonnllyy ffiilleess aanndd
+ssyymmbboolliicc lliinnkkss,, nnoott tthheeiirr ppaarreenntt ddiirreeccttoorriieess.. OOtthheerrwwiissee,, uunnppaacckkiinngg aa pprree--bbuuiilltt
+PPoossttffiixx ppaacckkaaggee mmaayy mmeessss uupp ppeerrmmiissssiioonn aanndd//oorr oowwnneerrsshhiipp ooff ssyysstteemm ddiirreeccttoorriieess
+ssuucchh aass // //eettcc //uussrr //uussrr//bbiinn //vvaarr //vvaarr//ssppooooll aanndd ssoo oonn.. TThhiiss iiss eessppeecciiaallllyy aann
+iissssuuee iiff yyoouu eexxeeccuutteedd ppoossttffiixx--iinnssttaallll ((sseeee aabboovvee)) aass aann uunnpprriivviilleeggeedd uusseerr..
+
+EEnndd SSeeccuurriittyy AAlleerrtt
+
+Thus, to tar up the pre-built package, take the following steps:
+
+    % cd INSTALL_ROOT
+    % rm -f SOMEWHERE/outputfile
+    % find . \! -type d -print | xargs tar rf SOMEWHERE/outputfile
+    % gzip SOMEWHERE/outputfile
+
+This way you will not include any directories that might cause trouble upon
+extraction.
+
+IInnssttaalllliinngg aa pprree--bbuuiilltt PPoossttffiixx ppaacckkaaggee
+
+  * To unpack a pre-built Postfix package, execute the equivalent of:
+
+    # umask 022
+    # gzip -d <outputfile.tar.gz | (cd / ; tar xvpf -)
+
+    The umask command is necessary for getting the correct permissions on non-
+    Postfix directories that need to be created in the process.
+
+  * Create the necessary mail_owner account and setgid_group group for
+    exclusive use by Postfix.
+
+  * Execute the postfix command to set ownership and permission of Postfix
+    files and directories, and to update Postfix configuration files. If
+    necessary, specify any non-default settings for mail_owner or setgid_group
+    on the postfix command line:
+
+    # postfix set-permissions upgrade-configuration \
+           setgid_group=xxx mail_owner=yyy
+
+    With Postfix versions before 2.1 you achieve the same result by invoking
+    the post-install script directly.
+
--- a/README_FILES/PCRE_README
+++ b/README_FILES/PCRE_README
@ -0,0 +1,78 @@
+PPoossttffiixx PPCCRREE SSuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+PPCCRREE ((PPeerrll CCoommppaattiibbllee RReegguullaarr EExxpprreessssiioonnss)) mmaapp ssuuppppoorrtt
+
+The optional "pcre" map type allows you to specify regular expressions with the
+PERL style notation such as \s for space and \S for non-space. The main
+benefit, however, is that pcre lookups are often faster than regexp lookups.
+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 https:
+//www.pcre.org/.
+
+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.
+
+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.
+
+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.
+
+    $ make -f Makefile.init makefiles
+    $ make
+
+To build Postfix explicitly with a pcre2 library (Postfix 3.7 and later):
+
+    $ make -f Makefile.init makefiles \
+        "CCARGS=-DHAS_PCRE=2 `pcre2-config --cflags`" \
+        "AUXLIBS_PCRE=`pcre2-config --libs8`"
+    $ make
+
+To build Postfix explicitly with a legacy pcre library (all Postfix versions):
+
+    $ 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-
+loaded PCRE database client, but only the new AUXLIBS_PCRE variable supports
+building a dynamically-loaded or statically-loaded PCRE database client.
+
+    Failure to use the AUXLIBS_PCRE variable will defeat the purpose of dynamic
+    database client loading. Every Postfix executable file will have PCRE
+    library dependencies. And that was exactly what dynamic database client
+    loading was meant to avoid.
+
+TThhiinnggss ttoo kknnooww
+
+  * When Postfix searches a pcre: or regexp: lookup table, each pattern is
+    applied to the entire input string. Depending on the application, that
+    string is an entire client hostname, an entire client IP address, or an
+    entire mail address. Thus, no parent domain or parent network search is
+    done, "user@domain" mail addresses are not broken up into their user and
+    domain constituent parts, and "user+foo" is not broken up into user and
+    foo.
+
+  * Regular expression tables such as pcre: or regexp: are not allowed to do
+    $number substitution in lookup results that can be security sensitive:
+    currently, that restriction applies to the local aliases(5) database or the
+    virtual(8) delivery agent tables.
+
--- a/README_FILES/PGSQL_README
+++ b/README_FILES/PGSQL_README
@ -0,0 +1,126 @@
+PPoossttffiixx PPoossttggrreeSSQQLL HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+The Postfix pgsql map type allows you to hook up Postfix to a PostgreSQL
+database. This implementation allows for multiple pgsql databases: you can use
+one for a virtual(5) table, one for an access(5) table, and one for an aliases
+(5) table if you want. You can specify multiple servers for the same database,
+so that Postfix can switch to a good database server if one goes bad.
+
+Busy mail servers using pgsql maps will generate lots of concurrent pgsql
+clients, so the pgsql server(s) should be run with this fact in mind. You can
+reduce the number of concurrent pgsql clients by using the Postfix proxymap(8)
+service.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh PPoossttggrreeSSQQLL 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.
+
+Note: to use pgsql with Debian GNU/Linux's Postfix, all you need to do is to
+install the postfix-pgsql package and you're done. There is no need to
+recompile Postfix.
+
+In order to build Postfix with pgsql map support, you specify -DHAS_PGSQL, the
+directory with the PostgreSQL header files, and the location of the libpq
+library file.
+
+For example:
+
+    % make tidy
+    % make -f Makefile.init makefiles \
+            "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-
+loaded PostgreSQL database client, but only the new AUXLIBS_PGSQL variable
+supports building a dynamically-loaded or statically-loaded PostgreSQL database
+client.
+
+    Failure to use the AUXLIBS_PGSQL variable will defeat the purpose of
+    dynamic database client loading. Every Postfix executable file will have
+    PGSQL database library dependencies. And that was exactly what dynamic
+    database client loading was meant to avoid.
+
+Then just run 'make'.
+
+CCoonnffiigguurriinngg PPoossttggrreeSSQQLL llooookkuupp ttaabblleess
+
+Once Postfix is built with pgsql support, you can specify a map type in main.cf
+like this:
+
+    /etc/postfix/main.cf:
+        alias_maps = pgsql:/etc/postfix/pgsql-aliases.cf
+
+The file /etc/postfix/pgsql-aliases.cf specifies lots of information telling
+postfix how to reference the pgsql database. For a complete description, see
+the pgsql_table(5) manual page.
+
+EExxaammppllee:: llooccaall aalliiaasseess
+
+#
+# pgsql config file for local(8) aliases(5) lookups
+#
+
+#
+# The hosts that Postfix will try to connect to
+hosts = host1.some.domain host2.some.domain
+
+# The user name and password to log into the pgsql server.
+user = someone
+password = some_password
+
+# The database name on the servers.
+dbname = customer_database
+
+# Postfix 2.2 and later The SQL query template. See pgsql_table(5).
+query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
+
+# For Postfix releases prior to 2.2. See pgsql_table(5) for details.
+select_field = forw_addr
+table = mxaliases
+where_field = alias
+# Don't forget the leading "AND"!
+additional_conditions = AND status = 'paid'
+
+UUssiinngg mmiirrrroorreedd ddaattaabbaasseess
+
+Sites that have a need for multiple mail exchangers may enjoy the convenience
+of using a networked mailer database, but do not want to introduce a single
+point of failure to their system.
+
+For this reason we've included the ability to have Postfix reference multiple
+hosts for access to a single pgsql map. This will work if sites set up mirrored
+pgsql databases on two or more hosts.
+
+Whenever queries fail with an error at one host, the rest of the hosts will be
+tried in random order. If no pgsql server hosts are reachable, then mail will
+be deferred until at least one of those hosts is reachable.
+
+CCrreeddiittss
+
+  * This code is based upon the Postfix mysql map by Scott Cotton and Joshua
+    Marcus, IC Group, Inc.
+  * The PostgreSQL changes were done by Aaron Sethman.
+  * Updates for Postfix 1.1.x and PostgreSQL 7.1+ and support for calling
+    stored procedures were added by Philip Warner.
+  * LaMont Jones was the initial Postfix pgsql maintainer.
+  * Liviu Daia revised the configuration interface and added the main.cf
+    configuration feature.
+  * Liviu Daia revised the configuration interface and added the main.cf
+    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.
+  * Leandro Santi updated the PostgreSQL client after the PostgreSQL developers
+    made major database API changes in response to SQL injection problems, and
+    made PQexec() handling more robust.
+
--- a/README_FILES/POSTSCREEN_3_5_README
+++ b/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.
+
--- a/README_FILES/POSTSCREEN_README
+++ b/README_FILES/POSTSCREEN_README
@ -0,0 +1,876 @@
+PPoossttffiixx PPoossttssccrreeeenn HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+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
+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 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 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:
+
+    AALLLLOOWWLLIISSTTEEDD [address]:port
+
+    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:
+
+    DDEENNYYLLIISSTTEEDD [address]:port
+
+    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 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_allowlist_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
+    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 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_denylist_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_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
+        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.
+
+Noel Jones helped with the Postfix 3.6 transition towards respectful
+documentation.
+
--- a/README_FILES/QMQP_README
+++ b/README_FILES/QMQP_README
@ -0,0 +1,5 @@
+PPoossttffiixx qqmmaaiill aanndd eezzmmllmm ssuuppppoorrtt
+
+-------------------------------------------------------------------------------
+This document will be made available via http://www.postfix.org/.
+
--- a/README_FILES/QSHAPE_README
+++ b/README_FILES/QSHAPE_README
@ -0,0 +1,740 @@
+PPoossttffiixx BBoottttlleenneecckk AAnnaallyyssiiss
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document is an introduction to Postfix queue congestion analysis. It
+explains how the qshape(1) program can help to track down the reason for queue
+congestion. qshape(1) is bundled with Postfix 2.1 and later source code, under
+the "auxiliary" directory. This document describes qshape(1) as bundled with
+Postfix 2.4.
+
+This document covers the following topics:
+
+  * Introducing the qshape tool
+  * Trouble shooting with qshape
+  * Example 1: Healthy queue
+  * Example 2: Deferred queue full of dictionary attack bounces
+  * Example 3: Congestion in the active queue
+  * Example 4: High volume destination backlog
+  * Postfix queue directories
+
+      o The "maildrop" queue
+      o The "hold" queue
+      o The "incoming" queue
+      o The "active" queue
+      o The "deferred" queue
+
+  * Credits
+
+IInnttrroodduucciinngg tthhee qqsshhaappee ttooooll
+
+When mail is draining slowly or the queue is unexpectedly large, run qshape(1)
+as the super-user (root) to help zero in on the problem. The qshape(1) program
+displays a tabular view of the Postfix queue contents.
+
+  * On the horizontal axis, it displays the queue age with fine granularity for
+    recent messages and (geometrically) less fine granularity for older
+    messages.
+
+  * The vertical axis displays the destination (or with the "-s" switch the
+    sender) domain. Domains with the most messages are listed first.
+
+For example, in the output below we see the top 10 lines of the (mostly forged)
+sender domain distribution for captured spam in the "hold" queue:
+
+    $ qshape -s hold | head
+                             T  5 10 20 40 80 160 320 640 1280 1280+
+                     TOTAL 486  0  0  1  0  0   2   4  20   40   419
+                 yahoo.com  14  0  0  1  0  0   0   0   1    0    12
+      extremepricecuts.net  13  0  0  0  0  0   0   0   2    0    11
+            ms35.hinet.net  12  0  0  0  0  0   0   0   0    1    11
+          winnersdaily.net  12  0  0  0  0  0   0   0   2    0    10
+               hotmail.com  11  0  0  0  0  0   0   0   0    1    10
+               worldnet.fr   6  0  0  0  0  0   0   0   0    0     6
+            ms41.hinet.net   6  0  0  0  0  0   0   0   0    0     6
+                    osn.de   5  0  0  0  0  0   1   0   0    0     4
+
+  * The "T" column shows the total (in this case sender) count for each domain.
+    The columns with numbers above them, show counts for messages aged fewer
+    than that many minutes, but not younger than the age limit for the previous
+    column. The row labeled "TOTAL" shows the total count for all domains.
+
+  * In this example, there are 14 messages allegedly from yahoo.com, 1 between
+    10 and 20 minutes old, 1 between 320 and 640 minutes old and 12 older than
+    1280 minutes (1440 minutes in a day).
+
+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.
+
+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:
+
+    $ 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.
+
+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
+outputs a summary of the available switches.
+
+TTrroouubbllee sshhoooottiinngg wwiitthh qqsshhaappee
+
+Large numbers in the qshape output represent a large number of messages that
+are destined to (or alleged to come from) a particular domain. It should be
+possible to tell at a glance which domains dominate the queue sender or
+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
+($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.
+
+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:
+
+    $ qshape active          (show recipient statistics)
+
+Having found the high volume domains, it is often useful to search the logs for
+recent messages pertaining to the domains in question.
+
+    # Find deliveries to example.com
+    #
+    $ tail -10000 /var/log/maillog |
+            grep -E -i ': to=<.*@example\.com>,' |
+            less
+
+    # Find messages from example.com
+    #
+    $ tail -10000 /var/log/maillog |
+            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 | grep -E ': 2B2173FF68: '
+
+Also look for queue manager warning messages in the log. These warnings can
+suggest strategies to reduce congestion.
+
+    $ 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.
+
+    $ 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
+messages and for a somewhat longer time:
+
+    $ qshape incoming
+
+                     T  5 10 20 40 80 160 320 640 1280 1280+
+              TOTAL  0  0  0  0  0  0   0   0   0    0     0
+
+    $ qshape active
+
+                     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
+
+EExxaammppllee 22:: DDeeffeerrrreedd qquueeuuee ffuullll ooff ddiiccttiioonnaarryy aattttaacckk bboouunncceess
+
+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.
+
+    $ qshape deferred | head
+
+                             T  5 10 20 40 80 160 320 640 1280 1280+
+                    TOTAL 2234  4  2  5  9 31  57 108 201  464  1353
+      heyhihellothere.com  207  0  0  1  1  6   6   8  25   68    92
+      pleazerzoneprod.com  105  0  0  0  0  0   0   0   5   44    56
+           groups.msn.com   63  2  1  2  4  4  14  14  14    8     0
+        orion.toppoint.de   49  0  0  0  1  0   2   4   3   16    23
+              kali.com.cn   46  0  0  0  0  1   0   2   6   12    25
+            meri.uwasa.fi   44  0  0  0  0  1   0   2   8   11    22
+        gjr.paknet.com.pk   43  1  0  0  1  1   3   3   6   12    16
+     aristotle.algonet.se   41  0  0  0  0  0   1   2  11   12    15
+
+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
+undeliverables are low rate steady stream rather than a concentrated dictionary
+attack that is now over.
+
+    $ qshape -s deferred | head
+
+                         T  5 10 20 40 80 160 320 640 1280 1280+
+                TOTAL 2193  4  4  5  8 33  56 104 205  465  1309
+        MAILER-DAEMON 1709  4  4  5  8 33  55 101 198  452   849
+          example.com  263  0  0  0  0  0   0   0   0    2   261
+          example.org  209  0  0  0  0  0   1   3   6   11   188
+          example.net    6  0  0  0  0  0   0   0   0    0     6
+          example.edu    3  0  0  0  0  0   0   0   0    0     3
+          example.gov    2  0  0  0  0  0   0   0   1    0     1
+          example.mil    1  0  0  0  0  0   0   0   0    0     1
+
+Looking at the sender distribution, we see that as expected most of the
+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
+shrinking despite very large delivery agent process limits. The thread is
+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)
+
+                               T   A   5  10  20  40  80 160 320 320+
+                     TOTAL 11775 9996  0   0   1   1  42  94 221 1420
+      user.sourceforge.net  7678 7678  0   0   0   0   0   0   0    0
+     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" 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
+information from the logs. While a careful reading of mailq(1) output should
+yield similar results, it is much harder to gauge the magnitude of the problem
+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
+qshape output will show large numbers for the destination domain in all age
+buckets that overlap the starting time of the problem:
+
+    $ qshape deferred | head
+
+                        T   5  10  20  40   80  160 320 640 1280 1280+
+               TOTAL 5000 200 200 400 800 1600 1000 200 200  200   200
+      highvolume.com 4000 160 160 320 640 1280 1440   0   0    0     0
+                 ...
+
+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.
+
+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.
+
+If a high volume destination exhibits frequent bursts of consecutive
+connections refused by all MX hosts or "421 Server busy errors", it is possible
+for the queue manager to mark the destination as "dead" despite the transient
+nature of the errors. The destination will be retried again after the
+expiration of a $minimal_backoff_time timer. If the error bursts are frequent
+enough it may be that only a small quantity of email is delivered before the
+destination is again marked "dead". In some cases enabling static (not on
+demand) connection caching by listing the appropriate nexthop domain in a table
+included in "smtp_connection_cache_destinations" may help to reduce the error
+rate, because most messages will re-use existing connections.
+
+The MTA that has been observed most frequently to exhibit such bursts of errors
+is Microsoft Exchange, which refuses connections under load. Some proxy virus
+scanners in front of the Exchange server propagate the refused connection to
+the client as a "421" error.
+
+Note that it is now possible to configure Postfix to exhibit similarly erratic
+behavior by misconfiguring the anvil(8) service. Do not use anvil(8) for
+steady-state rate limiting, its purpose is (unintentional) DoS prevention and
+the rate limits set should be very generous!
+
+If one finds oneself needing to deliver a high volume of mail to a destination
+that exhibits frequent brief bursts of errors and connection caching does not
+solve the problem, there is a subtle workaround.
+
+  * Postfix version 2.5 and later:
+
+      o In master.cf set up a dedicated clone of the "smtp" transport for the
+        destination in question. In the example below we will call it
+        "fragile".
+
+      o In master.cf configure a reasonable process limit for the cloned smtp
+        transport (a number in the 10-20 range is typical).
+
+      o IMPORTANT!!! In main.cf configure a large per-destination pseudo-cohort
+        failure limit for the cloned smtp transport.
+
+        /etc/postfix/main.cf:
+            transport_maps = hash:/etc/postfix/transport
+            fragile_destination_concurrency_failed_cohort_limit = 100
+            fragile_destination_concurrency_limit = 20
+
+        /etc/postfix/transport:
+            example.com  fragile:
+
+        /etc/postfix/master.cf:
+            # service type  private unpriv  chroot  wakeup  maxproc command
+            fragile   unix     -       -       n       -      20    smtp
+
+        See also the documentation for
+        default_destination_concurrency_failed_cohort_limit and
+        default_destination_concurrency_limit.
+
+  * Earlier Postfix versions:
+
+      o In master.cf set up a dedicated clone of the "smtp" transport for the
+        destination in question. In the example below we will call it
+        "fragile".
+
+      o In master.cf configure a reasonable process limit for the transport (a
+        number in the 10-20 range is typical).
+
+      o IMPORTANT!!! In main.cf configure a very large initial and destination
+        concurrency limit for this transport (say 2000).
+
+        /etc/postfix/main.cf:
+            transport_maps = hash:/etc/postfix/transport
+            initial_destination_concurrency = 2000
+            fragile_destination_concurrency_limit = 2000
+
+        /etc/postfix/transport:
+            example.com  fragile:
+
+        /etc/postfix/master.cf:
+            # service type  private unpriv  chroot  wakeup  maxproc command
+            fragile   unix     -       -       n       -      20    smtp
+
+        See also the documentation for default_destination_concurrency_limit.
+
+The effect of this configuration is that up to 2000 consecutive errors are
+tolerated without marking the destination dead, while the total concurrency
+remains reasonable (10-20 processes). This trick is only for a very specialized
+situation: high volume delivery into a channel with multi-error bursts that is
+capable of high throughput, but is repeatedly throttled by the bursts of
+errors.
+
+When a destination is unable to handle the load even after the Postfix process
+limit is reduced to 1, a desperate measure is to insert brief delays between
+delivery attempts.
+
+  * Postfix version 2.5 and later:
+
+      o In master.cf set up a dedicated clone of the "smtp" transport for the
+        problem destination. In the example below we call it "slow".
+
+      o In main.cf configure a short delay between deliveries to the same
+        destination.
+
+        /etc/postfix/main.cf:
+            transport_maps = hash:/etc/postfix/transport
+            slow_destination_rate_delay = 1
+            slow_destination_concurrency_failed_cohort_limit = 100
+
+        /etc/postfix/transport:
+            example.com  slow:
+
+        /etc/postfix/master.cf:
+            # service type  private unpriv  chroot  wakeup  maxproc command
+            slow      unix     -       -       n       -       -    smtp
+
+    See also the documentation for default_destination_rate_delay.
+
+    This solution forces the Postfix smtp(8) client to wait for
+    $slow_destination_rate_delay seconds between deliveries to the same
+    destination.
+
+    IMPORTANT!! The large slow_destination_concurrency_failed_cohort_limit
+    value is needed. This prevents Postfix from deferring all mail for the same
+    destination after only one connection or handshake error (the reason for
+    this is that non-zero slow_destination_rate_delay forces a per-destination
+    concurrency of 1).
+
+  * Earlier Postfix versions:
+
+      o In the transport map entry for the problem destination, specify a dead
+        host as the primary nexthop.
+
+      o In the master.cf entry for the transport specify the problem
+        destination as the fallback_relay and specify a small
+        smtp_connect_timeout value.
+
+        /etc/postfix/main.cf:
+            transport_maps = hash:/etc/postfix/transport
+
+        /etc/postfix/transport:
+            example.com  slow:[dead.host]
+
+        /etc/postfix/master.cf:
+            # service type  private unpriv  chroot  wakeup  maxproc command
+            slow      unix     -       -       n       -       1    smtp
+                -o fallback_relay=problem.example.com
+                -o smtp_connect_timeout=1
+                -o smtp_connection_cache_on_demand=no
+
+    This solution forces the Postfix smtp(8) client to wait for
+    $smtp_connect_timeout seconds between deliveries. The connection caching
+    feature is disabled to prevent the client from skipping over the dead host.
+
+PPoossttffiixx qquueeuuee ddiirreeccttoorriieess
+
+The following sections describe Postfix queues: their purpose, what normal
+behavior looks like, and how to diagnose abnormal behavior.
+
+TThhee ""mmaaiillddrroopp"" qquueeuuee
+
+Messages that have been submitted via the Postfix sendmail(1) command, but not
+yet brought into the main Postfix queue by the pickup(8) service, await
+processing in the "maildrop" queue. Messages can be added to the "maildrop"
+queue even when the Postfix system is not running. They will begin to be
+processed once Postfix is started.
+
+The "maildrop" queue is drained by the single threaded pickup(8) service
+scanning the queue directory periodically or when notified of new message
+arrival by the postdrop(1) program. The postdrop(1) program is a setgid helper
+that allows the unprivileged Postfix sendmail(1) program to inject mail into
+the "maildrop" queue and to notify the pickup(8) service of its arrival.
+
+All mail that enters the main Postfix queue does so via the cleanup(8) service.
+The cleanup service is responsible for envelope and header rewriting, header
+and body regular expression checks, automatic bcc recipient processing, milter
+content processing, and reliable insertion of the message into the Postfix
+"incoming" queue.
+
+In the absence of excessive CPU consumption in cleanup(8) header or body
+regular expression checks or other software consuming all available CPU
+resources, Postfix performance is disk I/O bound. The rate at which the pickup
+(8) service can inject messages into the queue is largely determined by disk
+access times, since the cleanup(8) service must commit the message to stable
+storage before returning success. The same is true of the postdrop(1) program
+writing the message to the "maildrop" directory.
+
+As the pickup service is single threaded, it can only deliver one message at a
+time at a rate that does not exceed the reciprocal disk I/O latency (+ CPU if
+not negligible) of the cleanup service.
+
+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
+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.
+
+Note, you should not attempt to deliver large volumes of mail via the pickup(8)
+service. High volume sites should avoid using "simple" content filters that re-
+inject scanned mail via Postfix sendmail(1) and postdrop(1).
+
+A high arrival rate of locally submitted mail may be an indication of an
+uncaught forwarding loop, or a run-away notification program. Try to keep the
+volume of local mail injection to a moderate level.
+
+The "postsuper -r" command can place selected messages into the "maildrop"
+queue for reprocessing. This is most useful for resetting any stale
+content_filter settings. Requeuing a large number of messages using "postsuper
+-r" can clearly cause a spike in the size of the "maildrop" queue.
+
+TThhee ""hhoolldd"" qquueeuuee
+
+The administrator can define "smtpd" access(5) policies, or cleanup(8) header/
+body checks that cause messages to be automatically diverted from normal
+processing and placed indefinitely in the "hold" queue. Messages placed in the
+"hold" queue stay there until the administrator intervenes. No periodic
+delivery attempts are made for messages in the "hold" queue. The postsuper(1)
+command can be used to manually release messages into the "deferred" queue.
+
+Messages can potentially stay in the "hold" queue longer than
+$maximal_queue_lifetime. If such "old" messages need to be released from the
+"hold" queue, they should typically be moved into the "maildrop" queue using
+"postsuper -r", so that the message gets a new timestamp and is given more than
+one opportunity to be delivered. Messages that are "young" can be moved
+directly into the "deferred" queue using "postsuper -H".
+
+The "hold" queue plays little role in Postfix performance, and monitoring of
+the "hold" queue is typically more closely motivated by tracking spam and
+malware, than by performance issues.
+
+TThhee ""iinnccoommiinngg"" qquueeuuee
+
+All new mail entering the Postfix queue is written by the cleanup(8) service
+into the "incoming" queue. New queue files are created owned by the "postfix"
+user with an access bitmask (or mode) of 0600. Once a queue file is ready for
+further processing the cleanup(8) service changes the queue file mode to 0700
+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" 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.
+
+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
+lookups or speeding up the hosts that provide the lookup service. If the
+problem is I/O starvation, consider striping the queue over more disks, faster
+controllers with a battery write cache, or other hardware improvements. At the
+very least, make sure that the queue directory is mounted with the "noatime"
+option if applicable to the underlying filesystem.
+
+The in_flow_delay parameter is used to clamp the input rate when the queue
+manager starts to fall behind. The cleanup(8) service will pause for
+$in_flow_delay seconds before creating a new queue file if it cannot obtain a
+"token" from the queue manager.
+
+Since the number of cleanup(8) processes is limited in most cases by the SMTP
+server concurrency, the input rate can exceed the output rate by at most "SMTP
+connection count" / $in_flow_delay messages per second.
+
+With a default process limit of 100, and an in_flow_delay of 1s, the coupling
+is strong enough to limit a single run-away injector to 1 message per second,
+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
+fast transport lookup mechanism.
+
+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
+not necessarily in the process of being sent (running).
+
+While most Postfix administrators think of the "active" queue as a directory on
+disk, the real "active" queue is a set of data structures in the memory of the
+queue manager process.
+
+Messages in the "maildrop", "hold", "incoming" and "deferred" queues (see
+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.
+
+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.
+
+Multiple recipient groups (from one or more messages) are queued for delivery
+grouped by transport/nexthop combination. The ddeessttiinnaattiioonn concurrency limit for
+the transports caps the number of simultaneous delivery attempts for each
+nexthop. Transports with a rreecciippiieenntt concurrency limit of 1 are special: these
+are grouped by the actual recipient address rather than the nexthop, yielding
+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
+slower than the corresponding message input rate.
+
+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
+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
+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
+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.
+
+The only way to reduce congestion is to either reduce the input rate or
+increase the throughput. Increasing the throughput requires either increasing
+the concurrency or reducing the latency of deliveries.
+
+For high volume sites a key tuning parameter is the number of "smtp" delivery
+agents allocated to the "smtp" and "relay" transports. High volume sites tend
+to send to many different destinations, many of which may be down or slow, so a
+good fraction of the available delivery agents will be blocked waiting for slow
+sites. Also mail destined across the globe will incur large SMTP command-
+response latencies, so high message throughput can only be achieved with more
+concurrent delivery agents.
+
+The default "smtp" process limit of 100 is good enough for most sites, and may
+even need to be lowered for sites with low bandwidth connections (no use
+increasing concurrency once the network pipe is full). When one finds that the
+queue is growing on an "idle" system (CPU, disk I/O and network not exhausted)
+the remaining reason for congestion is insufficient concurrency in the face of
+a high average latency. If the number of outbound SMTP connections (either
+ESTABLISHED or SYN_SENT) reaches the process limit, mail is draining slowly and
+the system and network are not loaded, raise the "smtp" and/or "relay" process
+limits!
+
+When a high volume destination is served by multiple MX hosts with typically
+low delivery latency, performance can suffer dramatically when one of the MX
+hosts is unresponsive and SMTP connections to that host timeout. For example,
+if there are 2 equal weight MX hosts, the SMTP connection timeout is 30 seconds
+and one of the MX hosts is down, the average SMTP connection will take
+approximately 15 seconds to complete. With a default per-destination
+concurrency limit of 20 connections, throughput falls to just over 1 message
+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
+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
+MX hosts.
+
+If connection caching is not available (Postfix < 2.2) or does not provide a
+sufficient latency reduction, especially for the "relay" transport used to
+forward mail to "your own" domains, consider setting lower than default SMTP
+connection timeouts (1-5 seconds) and higher than default destination
+concurrency limits. This will further reduce latency and provide more
+concurrency to maintain throughput should latency rise.
+
+Setting high concurrency limits to domains that are not your own may be viewed
+as hostile by the receiving system, and steps may be taken to prevent you from
+monopolizing the destination system's resources. The defensive measures may
+substantially reduce your throughput or block access entirely. Do not set
+aggressive concurrency limits to remote domains without coordinating with the
+administrators of the target domain.
+
+If necessary, dedicate and tune custom transports for selected high volume
+destinations. The "relay" transport is provided for forwarding mail to domains
+for which your server is a primary or backup MX host. These can make up a
+substantial fraction of your email traffic. Use the "relay" and not the "smtp"
+transport to send email to these domains. Using the "relay" transport allocates
+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)!
+
+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").
+
+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.
+
+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.
+
+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
+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
+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
+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.
+
+CCrreeddiittss
+
+The qshape(1) program was developed by Victor Duchovni of Morgan Stanley, who
+also wrote the initial version of this document.
+
--- a/README_FILES/RELEASE_NOTES
+++ b/README_FILES/RELEASE_NOTES
@ -0,0 +1 @@
+../RELEASE_NOTES
--- a/README_FILES/RESTRICTION_CLASS_README
+++ b/README_FILES/RESTRICTION_CLASS_README
@ -0,0 +1,166 @@
+PPoossttffiixx PPeerr--CClliieenntt//UUsseerr//eettcc.. AAcccceessss CCoonnttrrooll
+
+-------------------------------------------------------------------------------
+
+PPoossttffiixx rreessttrriiccttiioonn ccllaasssseess
+
+The Postfix SMTP server supports access restrictions such as reject_rbl_client
+or reject_unknown_client_hostname on the right-hand side of SMTP server access
+(5) tables. This allows you to implement different junk mail restrictions for
+different clients or users.
+
+Having to specify lists of access restrictions for every recipient becomes
+tedious quickly. Postfix restriction classes allow you to give easy-to-remember
+names to groups of UCE restrictions (such as "permissive", "restrictive", and
+so on).
+
+The real reason for the existence of Postfix restriction classes is more
+mundane: you can't specify a lookup table on the right-hand side of a Postfix
+access table. This is because Postfix needs to open lookup tables ahead of
+time, but the reader probably does not care about these low-level details.
+
+Example:
+
+    /etc/postfix/main.cf:
+        smtpd_restriction_classes = restrictive, permissive
+        # With Postfix < 2.3 specify reject_unknown_client.
+        restrictive = reject_unknown_sender_domain
+    reject_unknown_client_hostname ...
+        permissive = permit
+
+        smtpd_recipient_restrictions =
+            permit_mynetworks
+            # reject_unauth_destination is not needed here if the mail
+            # relay policy is specified with smtpd_relay_restrictions
+            # (available with Postfix 2.10 and later).
+            reject_unauth_destination
+            check_recipient_access hash:/etc/postfix/recipient_access
+            ...
+
+    /etc/postfix/recipient_access:
+        joe@my.domain       permissive
+        jane@my.domain      restrictive
+
+With this in place, you can use "restrictive" or "permissive" on the right-hand
+side of your per-client, helo, sender, or recipient SMTPD access tables.
+
+The remainder of this document gives examples of how Postfix access restriction
+classes can be used to:
+
+  * Shield an internal mailing list from outside posters,
+  * Prevent external access by internal senders.
+
+These questions come up frequently, and the examples hopefully make clear that
+Postfix restriction classes aren't really the right solution. They should be
+used for what they were designed to do, different junk mail restrictions for
+different clients or users.
+
+PPrrootteeccttiinngg iinntteerrnnaall eemmaaiill ddiissttrriibbuuttiioonn lliissttss
+
+    We want to implement an internal email distribution list. Something like
+    all@our.domain.com, which aliases to all employees. My first thought was to
+    use the aliases map, but that would lead to "all" being accessible from the
+    "outside", and this is not desired... :-)
+
+Postfix can implement per-address access controls. What follows is based on the
+SMTP client IP address, and therefore is subject to IP spoofing.
+
+    /etc/postfix/main.cf:
+        smtpd_recipient_restrictions =
+            ...
+            check_recipient_access hash:/etc/postfix/access
+            ...the usual stuff...
+
+    /etc/postfix/access:
+        all@my.domain   permit_mynetworks,reject
+        all@my.hostname permit_mynetworks,reject
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what map types Postfix supports, use the command ppoossttccoonnff --mm.
+
+Now, that would be sufficient when your machine receives all Internet mail
+directly from the Internet. That's unlikely if your network is a bit larger
+than an office. For example, your backup MX hosts would "launder" the client IP
+address of mail from the outside so it would appear to come from a trusted
+machine.
+
+In the general case you need two lookup tables: one table that lists
+destinations that need to be protected, and one table that lists domains that
+are allowed to send to the protected destinations.
+
+What follows is based on the sender SMTP envelope address, and therefore is
+subject to SMTP sender spoofing.
+
+    /etc/postfix/main.cf:
+        smtpd_recipient_restrictions =
+            ...
+            check_recipient_access hash:/etc/postfix/protected_destinations
+            ...the usual stuff...
+
+        smtpd_restriction_classes = insiders_only
+        insiders_only = check_sender_access hash:/etc/postfix/insiders, reject
+
+    /etc/postfix/protected_destinations:
+        all@my.domain   insiders_only
+        all@my.hostname insiders_only
+
+    /etc/postfix/insiders:
+        my.domain       OK  matches my.domain and subdomains
+        another.domain  OK  matches another.domain and subdomains
+
+Getting past this scheme is relatively easy, because all one has to do is to
+spoof the SMTP sender address.
+
+If the internal list is a low-volume one, perhaps it makes more sense to make
+it moderated.
+
+RReessttrriiccttiinngg wwhhaatt uusseerrss ccaann sseenndd mmaaiill ttoo ooffff--ssiittee ddeessttiinnaattiioonnss
+
+    How can I configure Postfix in a way that some users can send mail to the
+    internet and other users not. The users with no access should receive a
+    generic bounce message. Please don't discuss whether such access
+    restrictions are necessary, it was not my decision.
+
+Postfix has support for per-user restrictions. The restrictions are implemented
+by the SMTP server. Thus, users that violate the policy have their mail
+rejected by the SMTP server. Like this:
+
+    554 <user@remote>: Access denied
+
+The implementation uses two lookup tables. One table defines what users are
+restricted in where they can send mail, and the other table defines what
+destinations are local. It is left as an exercise for the reader to change this
+into a scheme where only some users have permission to send mail to off-site
+destinations, and where most users are restricted.
+
+The example assumes DB/DBM files, but this could also be done with LDAP or SQL.
+
+    /etc/postfix/main.cf:
+        smtpd_recipient_restrictions =
+            ...
+            check_sender_access hash:/etc/postfix/restricted_senders
+            ...other stuff...
+
+        smtpd_restriction_classes = local_only
+        local_only =
+            check_recipient_access hash:/etc/postfix/local_domains, reject
+
+    /etc/postfix/restricted_senders:
+        foo@domain      local_only
+        bar@domain      local_only
+
+    /etc/postfix/local_domains:
+        this.domain     OK      matches this.domain and subdomains
+        that.domain     OK      matches that.domain and subdomains
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what map types Postfix supports, use the command ppoossttccoonnff --mm.
+
+Note: this scheme does not authenticate the user, and therefore it can be
+bypassed in several ways:
+
+  * By sending mail via a less restrictive mail relay host.
+
+  * By sending mail as someone else who does have permission to send mail to
+    off-site destinations.
+
--- a/README_FILES/SASL_README
+++ b/README_FILES/SASL_README
--- a/README_FILES/SCHEDULER_README
+++ b/README_FILES/SCHEDULER_README
--- a/README_FILES/SMTPD_ACCESS_README
+++ b/README_FILES/SMTPD_ACCESS_README
@ -0,0 +1,347 @@
+PPoossttffiixx SSMMTTPP rreellaayy aanndd aacccceessss ccoonnttrrooll
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+The Postfix SMTP server receives mail from the network and is exposed to the
+big bad world of junk email and viruses. This document introduces the built-in
+and external methods that control what SMTP mail Postfix will accept, what
+mistakes to avoid, and how to test your configuration.
+
+Topics covered in this document:
+
+  * Relay control, junk mail control, and per-user policies
+  * Restrictions that apply to all SMTP mail
+  * Getting selective with SMTP access restriction lists
+  * Delayed evaluation of SMTP access restriction lists
+  * Dangerous use of smtpd_recipient_restrictions
+  * SMTP access rule testing
+
+RReellaayy ccoonnttrrooll,, jjuunnkk mmaaiill ccoonnttrrooll,, aanndd ppeerr--uusseerr ppoolliicciieess
+
+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 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
+have authenticated with SASL, or to domains that are configured as authorized
+relay destinations. For a description of the default mail relay policy, see the
+smtpd_relay_restrictions parameter in the postconf(5) manual page, and the
+information that is referenced from there.
+
+    NOTE: Postfix versions before 2.10 did not have smtpd_relay_restrictions.
+    They combined the mail relay and spam blocking policies, under
+    smtpd_recipient_restrictions. This could lead to unexpected results. For
+    example, a permissive spam blocking policy could unexpectedly result in a
+    permissive mail relay policy. An example of this is documented under
+    "Dangerous use of smtpd_recipient_restrictions".
+
+Most of the Postfix SMTP server access controls are targeted at stopping junk
+email.
+
+  * Protocol oriented: some SMTP server access controls block mail by being
+    very strict with respect to the SMTP protocol; these catch poorly
+    implemented and/or poorly configured junk email software, as well as email
+    worms that come with their own non-standard SMTP client implementations.
+    Protocol-oriented access controls become less useful over time as spammers
+    and worm writers learn to read RFC documents.
+
+  * 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 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
+    a second opinion (SPF and sender/recipient address verification). The
+    greylisting and SPF policies are implemented externally, and are the
+    subject of the SMTPD_POLICY_README document. Sender/recipient address
+    verification is the subject of the ADDRESS_VERIFICATION_README document.
+
+Unfortunately, all junk mail controls have the possibility of falsely rejecting
+legitimate mail. This can be a problem for sites with many different types of
+users. For some users it is unacceptable when any junk email slips through,
+while for other users the world comes to an end when a single legitimate email
+message is blocked. Because there is no single policy that is "right" for all
+users, Postfix supports different SMTP access restrictions for different users.
+This is described in the RESTRICTION_CLASS_README document.
+
+RReessttrriiccttiioonnss tthhaatt aappppllyy ttoo aallll SSMMTTPP mmaaiill
+
+Besides the restrictions that can be made configurable per client or per user
+as described in the next section, Postfix implements a few restrictions that
+apply to all SMTP mail.
+
+  * The built-in header_checks and body_checks content restrictions, as
+    described in the BUILTIN_FILTER_README document. This happens while Postfix
+    receives mail, before it is stored in the incoming queue.
+
+  * The external before-queue content restrictions, as described in the
+    SMTPD_PROXY_README document. This happens while Postfix receives mail,
+    before it is stored in the incoming queue.
+
+  * Requiring that the client sends the HELO or EHLO command before sending the
+    MAIL FROM or ETRN command. This may cause problems with home-grown
+    applications that send mail. For this reason, the requirement is disabled
+    by default ("smtpd_helo_required = no").
+
+  * Disallowing illegal syntax in MAIL FROM or RCPT TO commands. This may cause
+    problems with home-grown applications that send mail, and with ancient PC
+    mail clients. For this reason, the requirement is disabled by default
+    ("strict_rfc821_envelopes = no").
+
+      o Disallowing RFC 822 address syntax (example: "MAIL FROM: the dude
+        <dude@example.com>").
+
+      o Disallowing addresses that are not enclosed with <> (example: "MAIL
+        FROM: dude@example.com").
+
+  * Rejecting mail from a non-existent sender address. This form of egress
+    filtering helps to slow down worms and other malware, but may cause
+    problems with home-grown software that sends out mail software with an
+    unreplyable address. For this reason the requirement is disabled by default
+    ("smtpd_reject_unlisted_sender = no").
+
+  * Rejecting mail for a non-existent recipient address. This form of ingress
+    filtering helps to keep the mail queue free of undeliverable MAILER-DAEMON
+    messages. This requirement is enabled by default
+    ("smtpd_reject_unlisted_recipient = yes").
+
+GGeettttiinngg sseelleeccttiivvee wwiitthh SSMMTTPP aacccceessss rreessttrriiccttiioonn lliissttss
+
+Postfix allows you to specify lists of access restrictions for each stage of
+the SMTP conversation. Individual restrictions are described in the postconf(5)
+manual page.
+
+Examples of simple restriction lists are:
+
+/etc/postfix/main.cf:
+    # Allow connections from trusted networks only.
+    smtpd_client_restrictions = permit_mynetworks, reject
+
+    # Don't talk to mail systems that don't know their own hostname.
+    # With Postfix < 2.3, specify reject_unknown_hostname.
+    smtpd_helo_restrictions = reject_unknown_helo_hostname
+
+    # Don't accept mail from domains that don't exist.
+    smtpd_sender_restrictions = reject_unknown_sender_domain
+
+    # Spam control: exclude local clients and authenticated clients
+    # from DNSBL lookups.
+    smtpd_recipient_restrictions = permit_mynetworks,
+        permit_sasl_authenticated,
+        # reject_unauth_destination is not needed here if the mail
+        # relay policy is specified under smtpd_relay_restrictions
+        # (available with Postfix 2.10 and later).
+        reject_unauth_destination
+        reject_rbl_client zen.spamhaus.org,
+        reject_rhsbl_reverse_client dbl.spamhaus.org,
+        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
+
+    # Enforce mail volume quota via policy service callouts.
+    smtpd_end_of_data_restrictions = check_policy_service unix:private/policy
+
+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 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
+and in the effect of a REJECT or DEFER result.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |                              |       |                            |EEffffeecctt ooff  |
+    |RReessttrriiccttiioonn lliisstt nnaammee         |VVeerrssiioonn|SSttaattuuss                      |RREEJJEECCTT oorr  |
+    |                              |       |                            |DDEEFFEERR      |
+    |                              |       |                            |rreessuulltt     |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+    |                              |       |                            |Reject all |
+    |smtpd_client_restrictions     |All    |Optional                    |client     |
+    |                              |       |                            |commands   |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+    |                              |       |                            |Reject     |
+    |smtpd_helo_restrictions       |All    |Optional                    |HELO/EHLO  |
+    |                              |       |                            |information|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+    |                              |       |                            |Reject MAIL|
+    |smtpd_sender_restrictions     |All    |Optional                    |FROM       |
+    |                              |       |                            |information|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+    |                              |       |Required if                 |           |
+    |                              |>= 2.10|smtpd_relay_restrictions    |           |
+    |                              |       |does not enforce relay      |Reject RCPT|
+    |smtpd_recipient_restrictions  |       |policy                      |TO         |
+    |                              |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |information|
+    |                              |       |                            |           |
+    |                              |< 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    |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+    |                              |       |                            |Reject END-|
+    |smtpd_end_of_data_restrictions|>= 2.2 |Optional                    |OF-DATA    |
+    |                              |       |                            |command    |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+    |smtpd_etrn_restrictions       |All    |Optional                    |Reject ETRN|
+    |                              |       |                            |command    |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+
+DDeellaayyeedd eevvaalluuaattiioonn ooff SSMMTTPP aacccceessss rreessttrriiccttiioonn lliissttss
+
+Early Postfix versions evaluated SMTP access restrictions lists as early as
+possible. The client restriction list was evaluated before Postfix sent the
+"220 $myhostname..." greeting banner to the SMTP client, the helo restriction
+list was evaluated before Postfix replied to the HELO (EHLO) command, the
+sender restriction list was evaluated before Postfix replied to the MAIL FROM
+command, and so on. This approach turned out to be difficult to use.
+
+Current Postfix versions postpone the evaluation of client, helo and sender
+restriction lists until the RCPT TO or ETRN command. This behavior is
+controlled by the smtpd_delay_reject parameter. Restriction lists are still
+evaluated in the proper order of (client, helo, etrn) or (client, helo, sender,
+relay, recipient, data, or end-of-data) restrictions. When a restriction list
+(example: client) evaluates to REJECT or DEFER the restriction lists that
+follow (example: helo, sender, etc.) are skipped.
+
+Around the time that smtpd_delay_reject was introduced, Postfix was also
+changed to support mixed restriction lists that combine information about the
+client, helo, sender and recipient or etrn command.
+
+Benefits of delayed restriction evaluation, and of restriction mixing:
+
+  * Some SMTP clients do not expect a negative reply early in the SMTP session.
+    When the bad news is postponed until the RCPT TO reply, the client goes
+    away as it is supposed to, instead of hanging around until a timeout
+    happens, or worse, going into an endless connect-reject-connect loop.
+
+  * Postfix can log more useful information. For example, when Postfix rejects
+    a client name or address and delays the action until the RCPT TO command,
+    it can log the sender and the recipient address. This is more useful than
+    logging only the client hostname and IP address and not knowing whose mail
+    was being blocked.
+
+  * 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
+    per-user access restrictions would be impossible to express.
+
+DDaannggeerroouuss uussee ooff ssmmttppdd__rreecciippiieenntt__rreessttrriiccttiioonnss
+
+By now the reader may wonder why we need smtpd client, helo or sender
+restrictions, when their evaluation is postponed until the RCPT TO or ETRN
+command. Some people recommend placing ALL the access restrictions in the
+smtpd_recipient_restrictions list. Unfortunately, this can result in too
+permissive access. How is this possible?
+
+The purpose of the smtpd_recipient_restrictions feature is to control how
+Postfix replies to the RCPT TO command. If the restriction list evaluates to
+REJECT or DEFER, the recipient address is rejected; no surprises here. If the
+result is PERMIT, then the recipient address is accepted. And this is where
+surprises can happen.
+
+The problem is that Postfix versions before 2.10 did not have
+smtpd_relay_restrictions. They combined the mail relay and spam blocking
+policies, under smtpd_recipient_restrictions. The result is that a permissive
+spam blocking policy could unexpectedly result in a permissive mail relay
+policy.
+
+Here is an example that shows when a PERMIT result can result in too much
+access permission:
+
+1 /etc/postfix/main.cf:
+2     smtpd_recipient_restrictions =
+3         permit_mynetworks
+4         check_helo_access hash:/etc/postfix/helo_access
+5         reject_unknown_helo_hostname
+6         rreejjeecctt__uunnaauutthh__ddeessttiinnaattiioonn
+7
+8 /etc/postfix/helo_access:
+9     localhost.localdomain PERMIT
+
+Line 5 rejects mail from hosts that don't specify a proper hostname in the HELO
+command (with Postfix < 2.3, specify reject_unknown_hostname). Lines 4 and 9
+make an exception to allow mail from some machine that announces itself with
+"HELO localhost.localdomain".
+
+The problem with this configuration is that smtpd_recipient_restrictions
+evaluates to PERMIT for EVERY host that announces itself as
+"localhost.localdomain", making Postfix an open relay for all such hosts.
+
+With Postfix before version 2.10 you should place non-recipient restrictions
+AFTER the reject_unauth_destination restriction, not before. In the above
+example, the HELO based restrictions should be placed AFTER
+reject_unauth_destination, or better, the HELO based restrictions should be
+placed under smtpd_helo_restrictions where they can do no harm.
+
+1 /etc/postfix/main.cf:
+2     smtpd_recipient_restrictions =
+3         permit_mynetworks
+4         rreejjeecctt__uunnaauutthh__ddeessttiinnaattiioonn
+5         check_helo_access hash:/etc/postfix/helo_access
+6         reject_unknown_helo_hostname
+7
+8 /etc/postfix/helo_access:
+9     localhost.localdomain PERMIT
+
+The above mistake will not happen with Postfix 2.10 and later, when the relay
+policy is specified under smtpd_relay_restrictions, and the spam blocking
+policy under smtpd_recipient_restrictions. Then, a permissive spam blocking
+policy will not result in a permissive mail relay policy.
+
+SSMMTTPP aacccceessss rruullee tteessttiinngg
+
+Postfix has several features that aid in SMTP access rule testing:
+
+soft_bounce
+    This is a safety net that changes SMTP server REJECT actions into DEFER
+    (try again later) actions. This keeps mail queued that would otherwise be
+    returned to the sender. Specify "soft_bounce = yes" in the main.cf file to
+    prevent the Postfix SMTP server from rejecting mail permanently, by
+    changing all 5xx SMTP reply codes into 4xx.
+
+warn_if_reject
+    When placed before a reject-type restriction, access table query, or
+    check_policy_service query, this logs a "reject_warning" message instead of
+    rejecting a request (when a reject-type restriction fails due to a
+    temporary error, this logs a "reject_warning" message for any implicit
+    "defer_if_permit" actions that would normally prevent mail from being
+    accepted by some later access restriction). This feature has no effect on
+    defer_if_reject restrictions.
+
+XCLIENT
+    With this feature, an authorized SMTP client can impersonate other systems
+    and perform realistic SMTP access rule tests. Examples of how to
+    impersonate other systems for access rule testing are given at the end of
+    the XCLIENT_README document.
+    This feature is available in Postfix 2.1.
+
--- a/README_FILES/SMTPD_POLICY_README
+++ b/README_FILES/SMTPD_POLICY_README
@ -0,0 +1,651 @@
+PPoossttffiixx SSMMTTPP AAcccceessss PPoolliiccyy DDeelleeggaattiioonn
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff PPoossttffiixx SSMMTTPP aacccceessss ppoolliiccyy ddeelleeggaattiioonn
+
+The Postfix SMTP server has a number of built-in mechanisms to block or accept
+mail at specific SMTP protocol stages. In addition, the Postfix SMTP server can
+delegate decisions to an external policy server (Postfix 2.1 and later).
+
+With this policy delegation mechanism, a simple greylist policy can be
+implemented with only a dozen lines of Perl, as is shown at the end of this
+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.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,
+or TCL, than trying to do the same in C code. The difference in performance
+will be unnoticeable except in the most demanding environments. On active
+systems a policy daemon process is used multiple times, for up to $max_use
+incoming SMTP connections.
+
+This document covers the following topics:
+
+  * Policy protocol description
+  * Simple policy client/server configuration
+  * Advanced policy client configuration
+  * Example: greylist policy server
+  * Greylisting mail from frequently forged domains
+  * Greylisting all your mail
+  * Routine greylist maintenance
+  * Example Perl greylist server
+
+PPrroottooccooll ddeessccrriippttiioonn
+
+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:
+
+    PPoossttffiixx vveerrssiioonn 22..11 aanndd llaatteerr::
+    request=smtpd_access_policy
+    protocol_state=RCPT
+    protocol_name=SMTP
+    helo_name=some.domain.tld
+    queue_id=8045F2AB23
+    sender=foo@bar.tld
+    recipient=bar@foo.tld
+    recipient_count=0
+    client_address=1.2.3.4
+    client_name=another.domain.tld
+    reverse_client_name=another.domain.tld
+    instance=123.456.7
+    PPoossttffiixx vveerrssiioonn 22..22 aanndd llaatteerr::
+    sasl_method=plain
+    sasl_username=you
+    sasl_sender=
+    size=12345
+    ccert_subject=solaris9.porcupine.org
+    ccert_issuer=Wietse+20Venema
+    ccert_fingerprint=C2:9D:F4:87:71:73:73:D9:18:E7:C2:F3:C1:DA:6E:04
+    PPoossttffiixx vveerrssiioonn 22..33 aanndd llaatteerr::
+    encryption_protocol=TLSv1/SSLv3
+    encryption_cipher=DHE-RSA-AES256-SHA
+    encryption_keysize=256
+    etrn_domain=
+    PPoossttffiixx vveerrssiioonn 22..55 aanndd llaatteerr::
+    stress=
+    PPoossttffiixx vveerrssiioonn 22..99 aanndd llaatteerr::
+    ccert_pubkey_fingerprint=68:B3:29:DA:98:93:E3:40:99:C7:D8:AD:5C:B9:C9:40
+    PPoossttffiixx vveerrssiioonn 33..00 aanndd llaatteerr::
+    client_port=1234
+    PPoossttffiixx vveerrssiioonn 33..11 aanndd llaatteerr::
+    policy_context=submission
+    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:
+
+  * The "request" attribute is required. In this example the request type is
+    "smtpd_access_policy".
+
+  * The order of the attributes does not matter. The policy server should
+    ignore any attributes that it does not care about.
+
+  * When the same attribute name is sent more than once, the server may keep
+    the first value or the last attribute value.
+
+  * When an attribute value is unavailable, the client either does not send the
+    attribute, sends the attribute with an empty value ("name="), or sends a
+    zero value ("name=0") in the case of a numerical attribute.
+
+  * 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. 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. 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.
+
+  * The remote client or local server port is a decimal number in the range 0-
+    65535.
+
+  * For a discussion of the differences between reverse and verified
+    client_name information, see the reject_unknown_client_hostname discussion
+    in the postconf(5) document.
+
+  * An attribute name must not contain "=", null or newline, and an attribute
+    value must not contain null or newline.
+
+  * The "instance" attribute value can be used to correlate different requests
+    regarding the same message delivery. These requests are sent over the same
+    policy connection (unless the policy daemon terminates the connection).
+    Once Postfix sends a query with a different instance attribute over that
+    same policy connection, the previous message delivery is either completed
+    or aborted.
+
+  * 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 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
+    case of no SASL authentication.
+
+  * The "ccert_*" attributes (Postfix 2.2 and later) specify information about
+    how the client was authenticated via TLS. These attributes are empty in
+    case of no certificate authentication. As of Postfix 2.2.11 these attribute
+    values are encoded as xtext: some characters are represented by +XX, where
+    XX is the two-digit hexadecimal representation of the character value. With
+    Postfix 2.6 and later, the decoded string is an UTF-8 string without non-
+    printable ASCII characters.
+
+  * The "encryption_*" attributes (Postfix 2.3 and later) specify information
+    about how the connection is encrypted. With plaintext connections the
+    protocol and cipher attributes are empty and the keysize is zero.
+
+  * The "etrn_domain" attribute is defined only in the context of the ETRN
+    command, and specifies the ETRN command parameter.
+
+  * The "stress" attribute is either empty or "yes". See the STRESS_README
+    document for further information.
+
+  * 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. 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:
+
+    action=defer_if_permit Service temporarily unavailable
+    [empty line]
+
+This causes the Postfix SMTP server to reject the request with a 450 temporary
+error code and with text "Service temporarily unavailable", if the Postfix SMTP
+server finds no reason to reject the request permanently.
+
+In case of trouble the policy server must not send a reply. Instead the server
+must log a warning and disconnect. Postfix will retry the request at some later
+time.
+
+SSiimmppllee ppoolliiccyy cclliieenntt//sseerrvveerr ccoonnffiigguurraattiioonn
+
+The Postfix delegated policy client can connect to a TCP socket or to a UNIX-
+domain socket. Examples:
+
+    inet:127.0.0.1:9998
+    unix:/some/where/policy
+    unix:private/policy
+
+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. 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
+use something like this:
+
+     1 /etc/postfix/master.cf:
+     2     policy  unix  -       n       n       -       0       spawn
+     3       user=nobody argv=/some/where/policy-server
+     4
+     5 /etc/postfix/main.cf:
+     6     smtpd_recipient_restrictions =
+     7         ...
+     8         reject_unauth_destination
+     9         check_policy_service unix:private/policy
+    10         ...
+    11     policy_time_limit = 3600
+    12     # smtpd_policy_service_request_limit = 1
+
+NOTES:
+
+  * Lines 2-3: this creates the service called "policy" that listens on a UNIX-
+    domain socket. The service is implemented by the Postfix spawn(8) daemon,
+    which executes the policy server program that is specified with the aarrggvv
+    attribute, using the privileges specified with the uusseerr attribute.
+
+  * Line 2: specify a "0" process limit instead of the default "-", to avoid
+    "connection refused" and other problems when you increase the smtpd process
+    limit.
+
+  * Line 8: reject_unauth_destination is not needed here if the mail relay
+    policy is specified with smtpd_relay_restrictions (available with Postfix
+    2.10 and later).
+
+  * Lines 8, 9: always specify "check_policy_service" AFTER
+    "reject_unauth_destination" or else your system could become an open relay.
+
+  * 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 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.
+
+        Note: the "policy_time_limit" parameter will not show up in "postconf"
+        command output before Postfix version 2.9. This limitation applies to
+        many parameters whose name is a combination of a master.cf service name
+        (in the above example, "policy") and a built-in suffix (in the above
+        example: "_time_limit").
+
+  * Line 12: specify smtpd_policy_service_request_limit to avoid error-recovery
+    delays with policy servers that cannot maintain a persistent connection.
+
+  * With Solaris < 9, or Postfix < 2.10 on any Solaris version, use TCP sockets
+    instead of UNIX-domain sockets:
+
+     1 /etc/postfix/master.cf:
+     2     127.0.0.1:9998  inet  n       n       n       -       0       spawn
+     3       user=nobody argv=/some/where/policy-server
+     4
+     5 /etc/postfix/main.cf:
+     6     smtpd_recipient_restrictions =
+     7         ...
+     8         reject_unauth_destination
+     9         check_policy_service inet:127.0.0.1:9998
+    10         ...
+    11     127.0.0.1:9998_time_limit = 3600
+    12     # smtpd_policy_service_request_limit = 1
+
+Configuration parameters that control the client side of the policy delegation
+protocol:
+
+  * smtpd_policy_service_default_action (default: 451 4.3.5 Server
+    configuration problem): The default action when an SMTPD policy service
+    request fails. Available with Postfix 3.0 and later.
+
+  * smtpd_policy_service_max_idle (default: 300s): The amount of time before
+    the Postfix SMTP server closes an unused policy client connection.
+
+  * smtpd_policy_service_max_ttl (default: 1000s): The amount of time before
+    the Postfix SMTP server closes an active policy client connection.
+
+  * smtpd_policy_service_request_limit (default: 0): The maximal number of
+    requests per policy connection, or zero (no limit). Available with Postfix
+    3.0 and later.
+
+  * smtpd_policy_service_timeout (default: 100s): The time limit to connect to,
+    send to or receive from a policy server.
+
+  * smtpd_policy_service_try_limit (default: 2): The maximal number of attempts
+    to send an SMTPD policy service request before giving up. Available with
+    Postfix 3.0 and later.
+
+  * smtpd_policy_service_retry_delay (default: 1s): The delay between attempts
+    to resend a failed SMTPD policy service request. Available with Postfix 3.0
+    and later.
+
+  * smtpd_policy_service_policy_context (default: empty): Optional information
+    that is passed in the "policy_context" attribute of an SMTPD policy service
+    request (originally, to share the same SMTPD service endpoint among
+    multiple check_policy_service clients). Available with Postfix 3.1 and
+    later.
+
+Configuration parameters that control the server side of the policy delegation
+protocol:
+
+  * transport_time_limit ($command_time_limit): The maximal amount of time the
+    policy daemon is allowed to run before it is terminated. The transport is
+    the service name of the master.cf entry for the policy daemon service. In
+    the above examples, the service name is "policy" or "127.0.0.1:9998".
+
+AAddvvaanncceedd ppoolliiccyy cclliieenntt ccoonnffiigguurraattiioonn
+
+The previous section lists a number of Postfix main.cf parameters that control
+time limits and other settings for all policy clients. This is sufficient for
+simple configurations. With more complex configurations it becomes desirable to
+have different settings per policy client. This is supported with Postfix 3.0
+and later.
+
+The following example shows a "non-critical" policy service with a short
+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     mua_recipient_restrictions =
+    3         ...
+    4         reject_unauth_destination
+    5         check_policy_service { inet:host:port,
+    6             timeout=10s, default_action=DUNNO
+    7             policy_context=submission }
+    8         ...
+
+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-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.
+
+Inside the list, syntax is similar to what we already know from main.cf: items
+separated by space or comma. There is one difference: yyoouu mmuusstt eenncclloossee aa
+sseettttiinngg iinn ppaarreenntthheesseess,, aass iinn ""{{ nnaammee == vvaalluuee }}"",, iiff yyoouu wwaanntt ttoo hhaavvee ssppaaccee oorr
+ccoommmmaa wwiitthhiinn aa vvaalluuee oorr aarroouunndd ""=="". This comes in handy when different policy
+servers require different default actions with different SMTP status codes or
+text:
+
+    1 /etc/postfix/main.cf:
+    2     smtpd_recipient_restrictions =
+    3         ...
+    4         reject_unauth_destination
+    5         check_policy_service {
+    6           inet:host:port1,
+    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 https://
+www.greylisting.org/. The idea was discussed on the postfix-users mailing list
+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
+for every (client, sender, recipient) triple. By default, mail is not accepted
+until a time stamp is more than 60 seconds old. This stops junk mail with
+randomly selected sender addresses, and mail that is sent through randomly
+selected open proxies. It also stops junk mail from spammers that change their
+IP address frequently.
+
+Copy examples/smtpd-policy/greylist.pl to /usr/libexec/postfix or whatever
+location is appropriate for your system.
+
+In the greylist.pl Perl script you need to specify the location of the greylist
+database file, and how long mail will be delayed before it is accepted. The
+default settings are:
+
+    $database_name="/var/mta/greylist.db";
+    $greylist_delay=60;
+
+The /var/mta directory (or whatever you choose) should be writable by "nobody",
+or by whatever username you configure below in master.cf for the policy
+service.
+
+Example:
+
+    # mkdir /var/mta
+    # chown nobody /var/mta
+
+Note: DO NOT create the greylist database in a world-writable directory such as
+/tmp or /var/tmp, and DO NOT create the greylist database in a file system that
+may run out of space. Postfix can survive "out of space" conditions with the
+mail queue and with the mailbox store, but it cannot survive a corrupted
+greylist database. If the file becomes corrupted you may not be able to receive
+mail at all until you delete the file by hand.
+
+The greylist.pl Perl script can be run under control by the Postfix master
+daemon. For example, to run the script as user "nobody", using a UNIX-domain
+socket that is accessible by Postfix processes only:
+
+     1 /etc/postfix/master.cf:
+     2     greylist  unix  -       n       n       -       0       spawn
+     3       user=nobody argv=/usr/bin/perl /usr/libexec/postfix/greylist.pl
+     4
+     5 /etc/postfix/main.cf:
+     6     greylist_time_limit = 3600
+     7     smtpd_recipient_restrictions =
+     8         ...
+     9         reject_unauth_destination
+    10         check_policy_service unix:private/greylist
+    11         ...
+    12     # smtpd_policy_service_request_limit = 1
+
+Notes:
+
+  * Lines 2-3: this creates the service called "greylist" that listens on a
+    UNIX-domain socket. The service is implemented by the Postfix spawn(8)
+    daemon, which executes the greylist.pl script that is specified with the
+    aarrggvv attribute, using the privileges specified with the uusseerr attribute.
+
+  * Line 2: specify a "0" process limit instead of the default "-", to avoid
+    "connection refused" and other problems when you increase the smtpd process
+    limit.
+
+  * Line 3: Specify "greylist.pl -v" for verbose logging of each request and
+    reply.
+
+  * 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 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
+    policy is specified with smtpd_relay_restrictions (available with Postfix
+    2.10 and later).
+
+        Note: the "greylist_time_limit" parameter will not show up in
+        "postconf" command output before Postfix version 2.9. This limitation
+        applies to many parameters whose name is a combination of a master.cf
+        service name (in the above example, "greylist") and a built-in suffix
+        (in the above example: "_time_limit").
+
+  * Line 12: specify smtpd_policy_service_request_limit to avoid error-recovery
+    delays with policy servers that cannot maintain a persistent connection.
+
+With Solaris < 9, or Postfix < 2.10 on any Solaris version, use inet: style
+sockets instead of unix: style, as detailed in the "Policy client/server
+configuration" section above.
+
+     1 /etc/postfix/master.cf:
+     2     127.0.0.1:9998  inet  n       n       n       -       0       spawn
+     3       user=nobody argv=/usr/bin/perl /usr/libexec/postfix/greylist.pl
+     4
+     5 /etc/postfix/main.cf:
+     6     127.0.0.1:9998_time_limit = 3600
+     7     smtpd_recipient_restrictions =
+     8         ...
+     9         reject_unauth_destination
+    10         check_policy_service inet:127.0.0.1:9998
+    11         ...
+    12     # smtpd_policy_service_request_limit = 1
+
+GGrreeyylliissttiinngg mmaaiill ffrroomm ffrreeqquueennttllyy ffoorrggeedd ddoommaaiinnss
+
+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 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 =
+     3         reject_unlisted_recipient
+     4         ...
+     5         reject_unauth_destination
+     6         check_sender_access hash:/etc/postfix/sender_access
+     7         ...
+     8     smtpd_restriction_classes = greylist
+     9     greylist = check_policy_service unix:private/greylist
+    10
+    11 /etc/postfix/sender_access:
+    12     aol.com     greylist
+    13     hotmail.com greylist
+    14     bigfoot.com greylist
+    15     ... etcetera ...
+
+NOTES:
+
+  * Line 9: On Solaris < 9, or Postfix < 2.10 on any Solaris version, use inet:
+    style sockets instead of unix: style, as detailed in the "Example: greylist
+    policy server" section above.
+
+  * Line 5: reject_unauth_destination is not needed here if the mail relay
+    policy is specified with smtpd_relay_restrictions (available with Postfix
+    2.10 and later).
+
+  * Line 6: Be sure to specify "check_sender_access" AFTER
+    "reject_unauth_destination" or else your system could become an open mail
+    relay.
+
+  * Line 3: With Postfix 2.0 snapshot releases, "reject_unlisted_recipient" is
+    called "check_recipient_maps". Postfix 2.1 understands both forms.
+
+  * Line 3: The greylist database gets polluted quickly with bogus addresses.
+    It helps if you protect greylist lookups with other restrictions that
+    reject unknown senders and/or recipients.
+
+GGrreeyylliissttiinngg aallll yyoouurr mmaaiill
+
+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 allowlist clients that survive greylisting repeatedly; this
+avoids most of the delays and most of the database pollution problem.
+
+     1 /etc/postfix/main.cf:
+     2     smtpd_recipient_restrictions =
+     3         reject_unlisted_recipient
+     4         ...
+     5         reject_unauth_destination
+     6         check_sender_access hash:/etc/postfix/sender_access
+     7         check_policy_service unix:private/policy
+     8         ...
+     9
+    10 /etc/postfix/sender_access:
+    11     securityfocus.com OK
+    12     ...
+
+NOTES:
+
+  * Line 7: On Solaris < 9, or Postfix < 2.10 on any Solaris version, use inet:
+    style sockets instead of unix: style, as detailed in the "Example: greylist
+    policy server" section above.
+
+  * Line 5: reject_unauth_destination is not needed here if the mail relay
+    policy is specified with smtpd_relay_restrictions (available with Postfix
+    2.10 and later).
+
+  * Lines 6-7: Be sure to specify check_sender_access and check_policy_service
+    AFTER reject_unauth_destination or else your system could become an open
+    mail relay.
+
+  * Line 3: The greylist database gets polluted quickly with bogus addresses.
+    It helps if you precede greylist lookups with restrictions that reject
+    unknown senders and/or recipients.
+
+RRoouuttiinnee ggrreeyylliisstt mmaaiinntteennaannccee
+
+The greylist database grows over time, because the greylist server never
+removes database entries. If left unattended, the greylist database will
+eventually run your file system out of space.
+
+When the status file size exceeds some threshold you can simply rename or
+remove the file without adverse effects; Postfix automatically creates a new
+file. In the worst case, new mail will be delayed by an hour or so. To lessen
+the impact, rename or remove the file in the middle of the night at the
+beginning of a weekend.
+
+EExxaammppllee PPeerrll ggrreeyylliisstt sseerrvveerr
+
+This is the Perl subroutine that implements the example greylist policy. It is
+part of a general purpose sample policy server that is distributed with the
+Postfix source as examples/smtpd-policy/greylist.pl.
+
+#
+# greylist status database and greylist time interval. DO NOT create the
+# greylist status database in a world-writable directory such as /tmp
+# or /var/tmp. DO NOT create the greylist database in a file system
+# that can run out of space.
+#
+$database_name="/var/mta/greylist.db";
+$greylist_delay=60;
+
+#
+# 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_allowlist_threshold = 10;
+
+#
+# Demo SMTPD access policy routine. The result is an action just like
+# it would be specified on the right-hand side of a Postfix access
+# table.  Request attributes are available via the %attr hash.
+#
+sub smtpd_access_policy {
+    my($key, $time_stamp, $now);
+
+    # Open the database on the fly.
+    open_database() unless $database_obj;
+
+    # Search the auto-allowlist.
+    if ($auto_allowlist_threshold > 0) {
+        $count = read_database($attr{"client_address"});
+        if ($count > $auto_allowlist_threshold) {
+            return "dunno";
+        }
+    }
+
+    # Lookup the time stamp for this client/sender/recipient.
+    $key =
+        lc $attr{"client_address"}."/".$attr{"sender"}."/".$attr{"recipient"};
+    $time_stamp = read_database($key);
+    $now = time();
+
+    # If new request, add this client/sender/recipient to the database.
+    if ($time_stamp == 0) {
+        $time_stamp = $now;
+        update_database($key, $time_stamp);
+    }
+
+    # The result can be any action that is allowed in a Postfix access(5) map.
+    #
+    # To label the mail, return ``PREPEND headername: headertext''
+    #
+    # In case of success, return ``DUNNO'' instead of ``OK'', so that the
+    # check_policy_service restriction can be followed by other restrictions.
+    #
+    # In case of failure, return ``DEFER_IF_PERMIT optional text...'',
+    # so that mail can still be blocked by other access restrictions.
+    #
+    syslog $syslog_priority, "request age %d", $now - $time_stamp if $verbose;
+    if ($now - $time_stamp > $greylist_delay) {
+        # Update the auto-allowlist.
+        if ($auto_allowlist_threshold > 0) {
+            update_database($attr{"client_address"}, $count + 1);
+        }
+        return "dunno";
+    } else {
+        return "defer_if_permit Service temporarily unavailable";
+    }
+}
+
--- a/README_FILES/SMTPD_PROXY_README
+++ b/README_FILES/SMTPD_PROXY_README
@ -0,0 +1,263 @@
+PPoossttffiixx BBeeffoorree--QQuueeuuee CCoonntteenntt FFiilltteerr
+
+-------------------------------------------------------------------------------
+
+WWAARRNNIINNGG
+
+The before-queue content filtering feature described in this document limits
+the amount of mail that a site can handle. See the "Pros and Cons" section
+below for details.
+
+TThhee PPoossttffiixx bbeeffoorree--qquueeuuee ccoonntteenntt ffiilltteerr ffeeaattuurree
+
+As of version 2.1, the Postfix SMTP server can forward all incoming mail to a
+content filtering proxy server that inspects all mail BEFORE it is stored in
+the Postfix mail queue. It is roughly equivalent in capabilities to the
+approach described in MILTER_README, except that the latter uses a dedicated
+protocol instead of SMTP.
+
+The before-queue content filter is meant to be used as follows:
+
+                Postfix    BBeeffoorree    Postfix    Postfix    Postfix     smtp
+    Internet ->  SMTP   -> qquueeuuee  ->  SMTP   -> cleanup ->  queue  -<  local
+                server     ffiilltteerr    server     server                virtual
+
+The before-queue content filter is not to be confused with the approach
+described in the FILTER_README document, where mail is filtered AFTER it is
+stored in the Postfix mail queue.
+
+This document describes the following topics:
+
+  * Principles of operation
+  * Pros and cons of before-queue content filtering
+  * Configuring the Postfix SMTP pass-through proxy feature
+  * Configuration parameters
+  * How Postfix talks to the before-queue content filter
+
+PPrriinncciipplleess ooff ooppeerraattiioonn
+
+As shown in the diagram above, the before-queue filter sits between two Postfix
+SMTP server processes.
+
+  * The before-filter Postfix SMTP server accepts connections from the Internet
+    and does the usual relay access control, SASL authentication, TLS
+    negotiation, RBL lookups, rejecting non-existent sender or recipient
+    addresses, etc.
+
+  * The before-queue filter receives unfiltered mail content from Postfix and
+    does one of the following:
+
+     1. Re-inject the mail back into Postfix via SMTP, perhaps after changing
+        its content and/or destination.
+
+     2. Discard or quarantine the mail.
+
+     3. Reject the mail by sending a suitable SMTP status code back to Postfix.
+        Postfix passes the status back to the remote SMTP client. This way,
+        Postfix does not have to send a bounce message.
+
+  * The after-filter Postfix SMTP server receives mail from the content filter.
+    From then on Postfix processes the mail as usual.
+
+The before-queue content filter described here works just like the after-queue
+content filter described in the FILTER_README document. In many cases you can
+use the same software, within the limitations as discussed in the "Pros and
+Cons" section below.
+
+PPrrooss aanndd ccoonnss ooff bbeeffoorree--qquueeuuee ccoonntteenntt ffiilltteerriinngg
+
+  * Pro: Postfix can reject mail before the incoming SMTP mail transfer
+    completes, so that Postfix does not have to send rejected mail back to the
+    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
+    accepting mail or you have to stop filtering mail. It is for this reason
+    that the before-queue content filter limits the amount of mail that a site
+    can handle.
+
+  * Con: Content filtering software can use lots of memory resources. You have
+    to reduce the number of simultaneous content filter processes so that a
+    burst of mail will not drive your system into the ground.
+
+      o With Postfix versions 2.7 and later, SMTP clients will experience an
+        increase in the delay between the time the client sends "end-of-
+        message" and the time the Postfix SMTP server replies (here, the number
+        of before-filter SMTP server processes can be larger than the number of
+        filter processes).
+
+      o With Postfix versions before 2.7, SMTP clients will experience an
+        increase in the delay before they can receive service (here, the number
+        of before-filter SMTP server processes is always equal to the number of
+        filter processes).
+
+CCoonnffiigguurriinngg tthhee PPoossttffiixx SSMMTTPP ppaassss--tthhrroouugghh pprrooxxyy ffeeaattuurree
+
+In the following example, the before-filter Postfix SMTP server gives mail to a
+content filter that listens on localhost port 10025. The after-filter Postfix
+SMTP server receives mail from the content filter via localhost port 10026.
+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: 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
+    Internet -> SMTP server -> localhost  ->     on      -> cleanup -> incoming
+                on port 25     port 10025     localhost     server      queue
+                                             port 10026
+
+This is configured by editing the master.cf file:
+
+    /etc/postfix/master.cf:
+        # =============================================================
+        # service type  private unpriv  chroot  wakeup  maxproc command
+        #               (yes)   (yes)   (yes)   (never) (100)
+        # =============================================================
+        #
+        # Before-filter SMTP server. Receive mail from the network and
+        # pass it to the content filter on localhost port 10025.
+        #
+        smtp      inet  n       -       n       -       20      smtpd
+            -o smtpd_proxy_filter=127.0.0.1:10025
+            -o smtpd_client_connection_count_limit=10
+            # Postfix 2.7 and later performance feature.
+            # -o smtpd_proxy_options=speed_adjust
+        #
+        # After-filter SMTP server. Receive mail from the content filter
+        # on localhost port 10026.
+        #
+        127.0.0.1:10026 inet n  -       n       -        -      smtpd
+            -o smtpd_authorized_xforward_hosts=127.0.0.0/8
+            -o smtpd_client_restrictions=
+            -o smtpd_helo_restrictions=
+            -o smtpd_sender_restrictions=
+            # Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
+            -o smtpd_relay_restrictions=
+            -o smtpd_recipient_restrictions=permit_mynetworks,reject
+            -o smtpd_data_restrictions=
+            -o mynetworks=127.0.0.0/8
+            -o receive_override_options=no_unknown_recipient_checks
+
+Note: do not specify spaces around the "=" or "," characters.
+
+The before-filter SMTP server entry is a modified version of the default
+Postfix SMTP server entry that is normally configured at the top of the
+master.cf file:
+
+  * The number of SMTP sessions is reduced from the default 100 to only 20.
+    This prevents a burst of mail from running your system into the ground with
+    too many content filter processes.
+
+  * The "-o smtpd_client_connection_count_limit=10" prevents one SMTP client
+    from using up all 20 SMTP server processes. This limit is not necessary if
+    you receive all mail from a trusted relay host.
+
+    Note: this setting is available in Postfix version 2.2 and later. Earlier
+    Postfix versions will ignore it.
+
+  * The "-o smtpd_proxy_filter=127.0.0.1:10025" tells the before-filter SMTP
+    server that it should give incoming mail to the content filter that listens
+    on localhost TCP port 10025.
+
+  * The "-o smtpd_proxy_options=speed_adjust" tells the before-filter SMTP
+    server that it should receive an entire email message before it connects to
+    a content filter. This reduces the number of simultaneous filter processes.
+
+    NOTE 1: When this option is turned on, a content filter must not
+    selectively reject recipients of a multi-recipient message. Rejecting all
+    recipients is OK, as is accepting all recipients.
+
+    NOTE 2: This feature increases the minimum amount of free queue space by
+    $message_size_limit. The extra space is needed to save the message to a
+    temporary file.
+
+  * Postfix >= 2.3 supports both TCP and UNIX-domain filters. The above filter
+    could be specified as "inet:127.0.0.1:10025". To specify a UNIX-domain
+    filter, specify "unix:pathname". A relative pathname is interpreted
+    relative to the Postfix queue directory.
+
+The after-filter SMTP server is a new master.cf entry:
+
+  * The "127.0.0.1:10026" makes the after-filter SMTP server listen on the
+    localhost address only, without exposing it to the network. NEVER expose
+    the after-filter SMTP server to the Internet :-)
+
+  * The "-o smtpd_authorized_xforward_hosts=127.0.0.0/8" allows the after-
+    filter SMTP server to receive remote SMTP client information from the
+    before-filter SMTP server, so that the after-filter Postfix daemons log the
+    remote SMTP client information instead of logging localhost[127.0.0.1].
+
+  * The other after-filter SMTP server settings avoid duplication of work that
+    is already done in the "before filter" SMTP server.
+
+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 the "Configuration parameters" section below) but
+doing so is pointless because you can't control when the remote SMTP client
+times out.
+
+CCoonnffiigguurraattiioonn ppaarraammeetteerrss
+
+Parameters that control proxying:
+
+  * smtpd_proxy_filter (syntax: host:port): The host and TCP port of the
+    before-queue content filter. When no host or host: is specified here,
+    localhost is assumed.
+
+  * smtpd_proxy_timeout (default: 100s): Timeout for connecting to the before-
+    queue content filter and for sending and receiving commands and data. All
+    proxy errors are logged to the maillog file. For privacy reasons, all the
+    remote SMTP client sees is "451 Error: queue file write error". It would
+    not be right to disclose internal details to strangers.
+
+  * smtpd_proxy_ehlo (default: $myhostname): The hostname to use when sending
+    an EHLO command to the before-queue content filter.
+
+HHooww PPoossttffiixx ttaallkkss ttoo tthhee bbeeffoorree--qquueeuuee ccoonntteenntt ffiilltteerr
+
+The before-filter Postfix SMTP server connects to the content filter, delivers
+one message, and disconnects. While sending mail into the content filter,
+Postfix speaks ESMTP but uses no command pipelining. Postfix generates its own
+EHLO, XFORWARD (for logging the remote client IP address instead of localhost
+[127.0.0.1]), DATA and QUIT commands, and forwards unmodified copies of all the
+MAIL FROM and RCPT TO commands that the before-filter Postfix SMTP server
+didn't reject itself. Postfix sends no other SMTP commands.
+
+The content filter should accept the same MAIL FROM and RCPT TO command syntax
+as the before-filter Postfix SMTP server, and should forward the commands
+without modification to the after-filter SMTP server. If the content filter or
+after-filter SMTP server does not support all the ESMTP features that the
+before-filter Postfix SMTP server supports, then the missing features must be
+turned off in the before-filter Postfix SMTP server with the
+smtpd_discard_ehlo_keywords parameter.
+
+When the filter rejects content, it should send a negative SMTP response back
+to the before-filter Postfix SMTP server, and it should abort the connection
+with the after-filter Postfix SMTP server without completing the SMTP
+conversation with the after-filter Postfix SMTP server.
+
--- a/README_FILES/SMTPUTF8_README
+++ b/README_FILES/SMTPUTF8_README
@ -0,0 +1,294 @@
+ PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document describes Postfix support for Email Address Internationalization
+(EAI) as defined in RFC 6531 (SMTPUTF8 extension), RFC 6532 (Internationalized
+email headers) and RFC 6533 (Internationalized delivery status notifications).
+Introduced with Postfix version 3.0, this fully supports UTF-8 email addresses
+and UTF-8 message header values.
+
+Topics covered in this document:
+
+  * Building with/without SMTPUTF8 support
+  * Enabling Postfix SMTPUTF8 support
+  * Using Postfix SMTPUTF8 support
+  * SMTPUTF8 autodetection
+  * Limitations of the current implementation
+  * Compatibility with pre-SMTPUTF8 environments
+  * Compatibility with IDNA2003
+  * Credits
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh//wwiitthhoouutt SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+Postfix will build with SMTPUTF8 support if the ICU version >= 46 library and
+header files are installed on the system. The package name varies with the OS
+distribution. The table shows package names for a number of platforms at the
+time this text was written.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |OOSS DDiissttrriibbuuttiioonn      |PPaacckkaaggee     |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |FreeBSD, NetBSD, etc.|icu         |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |Centos, Fedora, RHEL |libicu-devel|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |Debian, Ubuntu       |libicu-dev  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+
+To force Postfix to build without SMTPUTF8, specify:
+
+    $ mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDNNOO__EEAAII ......""
+
+See the INSTALL document for more "make makefiles" options.
+
+EEnnaabblliinngg PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+There is more to SMTPUTF8 than just Postfix itself. The rest of your email
+infrastructure also needs to be able to handle UTF-8 email addresses and
+message header values. This includes SMTPUTF8 protocol support in SMTP-based
+content filters (Amavisd), LMTP servers (Dovecot), and down-stream SMTP
+servers.
+
+Postfix SMTPUTF8 support is enabled by default, but it may be disabled as part
+of a backwards-compatibility safety net (see the COMPATIBILITY_README file).
+
+SMTPUTF8 support is enabled by setting the smtputf8_enable parameter in
+main.cf:
+
+    # ppoossttccoonnff ""ssmmttppuuttff88__eennaabbllee == yyeess""
+    # ppoossttffiixx rreellooaadd
+
+(With Postfix <= 3.1, you may also need to specify "ooppttiioonn__ggrroouupp == cclliieenntt" in
+Postfix MySQL client files, to enable UTF8 support in MySQL queries. This
+setting is the default as of Postfix 3.2.)
+
+With SMTPUTF8 support enabled, Postfix changes behavior with respect to earlier
+Postfix releases:
+
+  * UTF-8 is permitted in the myorigin parameter value. However, the myhostname
+    and mydomain parameters must currently specify ASCII-only domain names.
+    This limitation may be removed later.
+
+  * UTF-8 is the only form of non-ASCII text that Postfix supports in access
+    tables, address rewriting tables, and other tables that are indexed with an
+    email address, hostname, or domain name.
+
+  * The header_checks-like and body_checks-like features are not UTF-8 enabled,
+    and therefore they do not enforce UTF-8 syntax rules on inputs and outputs.
+    The reason is that non-ASCII text may be sent in encodings other than UTF-
+    8, and that real email sometimes contains malformed headers. Instead of
+    skipping non-UTF-8 content, Postfix should be able to filter it. You may
+    try to enable UTF-8 processing by starting a PCRE pattern with the sequence
+    (*UTF8), but this is will result in "message not accepted, try again later"
+    errors when the PCRE pattern matcher encounters non-UTF-8 input. Other
+    features that are not UTF-8 enabled are smtpd_command_filter,
+    smtp_reply_filter, the *_delivery_status_filter features, and the
+    *_dns_reply_filter features (the latter because DNS is by definition an
+    ASCII protocol).
+
+  * The Postfix SMTP server announces SMTPUTF8 support in the EHLO response.
+
+    220 server.example.com ESMTP Postfix
+    EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+    250-server.example.com
+    250-PIPELINING
+    250-SIZE 10240000
+    250-VRFY
+    250-ETRN
+    250-STARTTLS
+    250-AUTH PLAIN LOGIN
+    250-ENHANCEDSTATUSCODES
+    250-8BITMIME
+    250-DSN
+    250 SMTPUTF8
+
+  * The Postfix SMTP server accepts the SMTPUTF8 request in MAIL FROM and VRFY
+    commands.
+
+    MMAAIILL FFRROOMM::<<aaddddrreessss>> SSMMTTPPUUTTFF88 ......
+
+    VVRRFFYY aaddddrreessss SSMMTTPPUUTTFF88
+
+  * The Postfix SMTP client may issue the SMTPUTF8 request in MAIL FROM
+    commands.
+
+  * The Postfix SMTP server accepts UTF-8 in email address domains, but only
+    after the remote SMTP client issues the SMTPUTF8 request in MAIL FROM or
+    VRFY commands.
+
+Postfix already permitted UTF-8 in message header values and in address
+localparts. This does not change.
+
+UUssiinngg PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+After Postfix SMTPUTF8 support is turned on, Postfix behavior will depend on 1)
+whether a remote SMTP client requests SMTPUTF8 support, 2) the presence of UTF-
+8 content in the message envelope and headers, and 3) whether a down-stream
+SMTP (or LMTP) server announces SMTPUTF8 support.
+
+  * When the Postfix SMTP server receives a message WITHOUT the SMTPUTF8
+    request, Postfix handles the message as it has always done (at least that
+    is the default, see autodetection below). Specifically, the Postfix SMTP
+    server does not accept UTF-8 in the envelope sender domain name or envelope
+    recipient domain name, and the Postfix SMTP client does not issue the
+    SMTPUTF8 request when delivering that message to an SMTP or LMTP server
+    that announces SMTPUTF8 support (again, that is the default). Postfix will
+    accept UTF-8 in message header values and in the localpart of envelope
+    sender and recipient addresses, because it has always done that.
+
+  * When the Postfix SMTP server receives a message WITH the SMTPUTF8 request,
+    Postfix will issue the SMTPUTF8 request when delivering that message to an
+    SMTP or LMTP server that announces SMTPUTF8 support. This is not
+    configurable.
+
+  * When a message is received with the SMTPUTF8 request, Postfix will deliver
+    the message to a non-SMTPUTF8 SMTP or LMTP server ONLY if:
+
+      o No message header value contains UTF-8.
+
+      o The envelope sender address contains no UTF-8,
+
+      o No envelope recipient address for that specific SMTP/LMTP delivery
+        transaction contains UTF-8.
+
+            NOTE: Recipients in other email delivery transactions for that same
+            message may still contain UTF-8.
+
+    Otherwise, Postfix will return the recipient(s) for that email delivery
+    transaction as undeliverable. The delivery status notification message will
+    be an SMTPUTF8 message. It will therefore be subject to the same
+    restrictions as email that is received with the SMTPUTF8 request.
+
+  * When the Postfix SMTP server receives a message with the SMTPUTF8 request,
+    that request also applies after the message is forwarded via a virtual or
+    local alias, or $HOME/.forward file.
+
+SSMMTTPPUUTTFF88 aauuttooddeetteeccttiioonn
+
+This section applies only to systems that have SMTPUTF8 support turned on
+(smtputf8_enable = yes).
+
+For compatibility with pre-SMTPUTF8 environments, Postfix does not
+automatically set the "SMTPUTF8 requested" flag on messages from non-SMTPUTF8
+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.
+
+By default, Postfix sets the "SMTPUTF8 requested" flag only on address
+verification probes and on Postfix sendmail submissions that contain UTF-8 in
+the sender address, UTF-8 in a recipient address, or UTF-8 in a message header
+value.
+
+    /etc/postfix/main.cf:
+        smtputf8_autodetect_classes = sendmail, verify
+
+However, if you have a non-ASCII myorigin or mydomain setting, or if you have a
+configuration that introduces UTF-8 addresses with virtual aliases, canonical
+mappings, or BCC mappings, then you may have to apply SMTPUTF8 autodetection to
+all email:
+
+    /etc/postfix/main.cf:
+        smtputf8_autodetect_classes = all
+
+This will, of course, also flag email that was received without SMTPUTF8
+request, but that contains UTF-8 in a sender address localpart, receiver
+address localpart, or message header value. Such email was not standards-
+compliant, but Postfix would have delivered it if SMTPUTF8 support was
+disabled.
+
+LLiimmiittaattiioonnss ooff tthhee ccuurrrreenntt iimmpplleemmeennttaattiioonn
+
+The Postfix implementation is a work in progress; limitations are steadily
+being removed. The text below describes the situation at one point in time.
+
+NNoo aauuttoommaattiicc ccoonnvveerrssiioonnss bbeettwweeeenn AASSCCIIII aanndd UUTTFF--88 ddoommaaiinn nnaammeess..
+
+Some background: According to RFC 6530 and related documents, an
+internationalized domain name can appear in two forms: the UTF-8 form, and the
+ASCII (xn--mumble) form. An internationalized address localpart must be encoded
+in UTF-8; the RFCs do not define an ASCII alternative form.
+
+Postfix currently does not convert internationalized domain names from UTF-
+8 into ASCII (or from ASCII into UTF-8) before using domain names in SMTP
+commands and responses, before looking up domain names in lists such as
+mydestination, relay_domains or in lookup tables such as access tables, etc.,
+before using domain names in a policy daemon or Milter request, or before
+logging events.
+
+Postfix does, however, casefold domain names and email addresses before
+matching them against a Postfix configuration parameter or lookup table.
+
+In order to use Postfix SMTPUTF8 support:
+
+  * The Postfix parameters myhostname and mydomain must be in ASCII form. One
+    is a substring of the other, and the myhostname value is used in SMTP
+    commands and responses that require ASCII. The parameter myorigin (added to
+    local addresses without domain) supports UTF-8.
+
+  * You need to configure both the ASCII and UTF-8 forms of an
+    Internationalized domain name in Postfix parameters such as mydestination
+    and relay_domains, as well as lookup table search keys.
+
+  * Milters, content filters, policy servers and logfile analysis tools need to
+    be able to handle both the ASCII and UTF-8 forms of Internationalized
+    domain names.
+
+CCoommppaattiibbiilliittyy wwiitthh pprree--SSMMTTPPUUTTFF88 eennvviirroonnmmeennttss
+
+MMaaiilliinngg lliissttss wwiitthh UUTTFF--88 aanndd nnoonn--UUTTFF--88 ssuubbssccrriibbeerrss
+
+With Postfix, there is no need to split mailing lists into UTF-8 and non-UTF-
+8 members. Postfix will try to deliver the non-UTF8 subscribers over
+"traditional" non-SMTPUTF8 sessions, as long as the message has an ASCII
+envelope sender address and all-ASCII header values. The mailing list manager
+may have to apply RFC 2047 encoding to satisfy that last condition.
+
+PPrree--eexxiissttiinngg nnoonn--AASSCCIIII eemmaaiill fflloowwss
+
+With "smtputf8_enable = no", Postfix handles email with non-ASCII in address
+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.
+
+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
+
+Postfix >= 3.2 by default disables the 'transitional' compatibility between
+IDNA2003 and IDNA2008, when converting UTF-8 domain names to/from the ASCII
+form that is used in DNS lookups. This makes Postfix behavior consistent with
+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 https://unicode.org/cldr/utility/idna.jsp
+for more examples.
+
+CCrreeddiittss
+
+  * May 15, 2014: Arnt Gulbrandsen posted his patch for Unicode email support.
+    This work was sponsored by CNNIC.
+
+  * July 15, 2014: Wietse integrated Arnt Gulbrandsen's code and released
+    Postfix with SMTPUTF8 support.
+
+  * January 2015: Wietse added UTF-8 support for casefolding in Postfix lookup
+    tables and caseless string comparison in Postfix list-based features.
+
--- a/README_FILES/SOHO_README
+++ b/README_FILES/SOHO_README
@ -0,0 +1,288 @@
+PPoossttffiixx SSmmaallll//HHoommee OOffffiiccee HHiinnttss aanndd TTiippss
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document combines hints and tips for "small office/home office"
+applications into one document so that they are easier to find. The text
+describes the mail sending side only. If your machine does not receive mail
+directly (i.e. it does not have its own Internet domain name and its own fixed
+IP address), then you will need a solution such as "fetchmail", which is
+outside the scope of the Postfix documentation.
+
+  * Selected topics from the STANDARD_CONFIGURATION_README document:
+
+      o Postfix on a stand-alone Internet host
+      o Postfix on hosts without a real Internet hostname
+
+    Selected topics from the SASL_README document:
+
+      o Enabling SASL authentication in the Postfix SMTP client
+      o Configuring Sender-Dependent SASL authentication
+
+See the SASL_README and STANDARD_CONFIGURATION_README documents for further
+information on these topics.
+
+PPoossttffiixx oonn aa ssttaanndd--aalloonnee IInntteerrnneett hhoosstt
+
+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 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
+on a stand-alone box, beyond what is covered in the BASIC_CONFIGURATION_README
+document:
+
+    /etc/postfix/main.cf:
+        # Optional: send mail as user@domainname instead of user@hostname.
+        #myorigin = $mydomain
+
+        # Optional: specify NAT/proxy external address.
+        #proxy_interfaces = 1.2.3.4
+
+        # Alternative 1: don't relay mail from other hosts.
+        mynetworks_style = host
+        relay_domains =
+
+        # Alternative 2: relay mail from local clients only.
+        # mynetworks = 192.168.1.0/28
+        # relay_domains =
+
+See also the section "Postfix on hosts without a real Internet hostname" if
+this is applicable to your configuration.
+
+PPoossttffiixx oonn hhoossttss wwiitthhoouutt aa rreeaall IInntteerrnneett hhoossttnnaammee
+
+This section is for hosts that don't have their own Internet hostname.
+Typically these are systems that get a dynamic IP address via DHCP or via
+dialup. Postfix will let you send and receive mail just fine between accounts
+on a machine with a fantasy name. However, you cannot use a fantasy hostname in
+your email address when sending mail into the Internet, because no-one would be
+able to reply to your mail. In fact, more and more sites refuse mail addresses
+with non-existent domain names.
+
+Note: the following information is Postfix version dependent. To find out what
+Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
+
+SSoolluuttiioonn 11:: PPoossttffiixx vveerrssiioonn 22..22 aanndd llaatteerr
+
+Postfix 2.2 uses the generic(5) address mapping to replace local fantasy email
+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 in the first half of
+this document.
+
+    1 /etc/postfix/main.cf:
+    2     smtp_generic_maps = hash:/etc/postfix/generic
+    3
+    4 /etc/postfix/generic:
+    5     his@localdomain.local             hisaccount@hisisp.example
+    6     her@localdomain.local             heraccount@herisp.example
+    7     @localdomain.local                hisaccount+local@hisisp.example
+
+When mail is sent to a remote host via SMTP:
+
+  * Line 5 replaces his@localdomain.local by his ISP mail address,
+
+  * Line 6 replaces her@localdomain.local by her ISP mail address, and
+
+  * Line 7 replaces other local addresses by his ISP account, with an address
+    extension of +local (this example assumes that the ISP supports "+" style
+    address extensions).
+
+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".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ggeenneerriicc" whenever you change the
+generic table.
+
+SSoolluuttiioonn 22:: PPoossttffiixx vveerrssiioonn 22..11 aanndd eeaarrlliieerr
+
+The solution with older Postfix systems is to use valid Internet addresses
+where possible, and to let Postfix map valid Internet addresses to local
+fantasy addresses. With this, you can send mail to the Internet and to local
+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 in the first half of
+this document.
+
+     1 /etc/postfix/main.cf:
+     2     myhostname = hostname.localdomain
+     3     mydomain = localdomain
+     4
+     5     canonical_maps = hash:/etc/postfix/canonical
+     6
+     7     virtual_alias_maps = hash:/etc/postfix/virtual
+     8
+     9 /etc/postfix/canonical:
+    10     your-login-name    your-account@your-isp.com
+    11
+    12 /etc/postfix/virtual:
+    13     your-account@your-isp.com       your-login-name
+
+Translation:
+
+  * Lines 2-3: Substitute your fantasy hostname here. Do not use a domain name
+    that is already in use by real organizations on the Internet. See RFC 2606
+    for examples of domain names that are guaranteed not to be owned by anyone.
+
+  * Lines 5, 9, 10: This provides the mapping from "your-login-
+    name@hostname.localdomain" to "your-account@your-isp.com". This part is
+    required.
+
+  * Lines 7, 12, 13: Deliver mail for "your-account@your-isp.com" locally,
+    instead of sending it to the ISP. This part is not required but is
+    convenient.
+
+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".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ccaannoonniiccaall" whenever you change the
+canonical table.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" whenever you change the
+virtual table.
+
+EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
+
+This section shows a typical scenario where the Postfix SMTP client sends all
+messages via a mail gateway server that requires SASL authentication.
+
+    TTrroouubbllee ssoollvviinngg ttiippss::
+
+      * If your SASL logins fail with "SASL authentication failure: No worthy
+        mechs found" in the mail logfile, then see the section "Postfix SMTP/
+        LMTP client policy - SASL mechanism pprrooppeerrttiieess".
+
+      * For a solution to a more obscure class of SASL authentication failures,
+        see "Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess".
+
+To make the example more readable we introduce it in two parts. The first part
+takes care of the basic configuration, while the second part sets up the
+username/password information.
+
+    /etc/postfix/main.cf:
+        smtp_sasl_auth_enable = yes
+        smtp_tls_security_level = encrypt
+        smtp_sasl_tls_security_options = noanonymous
+        relayhost = [mail.isp.example]
+        # Alternative form:
+        # relayhost = [mail.isp.example]:submission
+        smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+
+  * The smtp_sasl_auth_enable setting enables client-side authentication. We
+    will configure the client's username and password information in the second
+    part of the example.
+
+  * The smtp_tls_security_level setting ensures that the connection to the
+    remote smtp server will be encrypted, and smtp_sasl_tls_security_options
+    removes the prohibition on plaintext passwords.
+
+  * The relayhost setting forces the Postfix SMTP to send all remote messages
+    to the specified mail server instead of trying to deliver them directly to
+    their destination.
+
+  * In the relayhost setting, the "[" and "]" prevent the Postfix SMTP client
+    from looking up MX (mail exchanger) records for the enclosed name.
+
+  * The relayhost destination may also specify a non-default TCP port. For
+    example, the alternative form [mail.isp.example]:submission tells Postfix
+    to connect to TCP network port 587, which is reserved for email client
+    applications.
+
+  * The Postfix SMTP client is compatible with SMTP servers that use the non-
+    standard "AUTH=mmeetthhoodd....." syntax in response to the EHLO command; this
+    requires no additional Postfix client configuration.
+
+  * 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
+    server. As discussed in the next section, the Postfix SMTP client supports
+    multiple ISP accounts. For this reason the username and password are stored
+    in a table that contains one username/password combination for each mail
+    gateway server.
+
+    /etc/postfix/sasl_passwd:
+        # destination                   credentials
+        [mail.isp.example]              username:password
+        # Alternative form:
+        # [mail.isp.example]:submission username:password
+
+    IImmppoorrttaanntt
+
+    Keep the SASL client password file in /etc/postfix, and make the file
+    read+write only for root to protect the username/password combinations
+    against other users. The Postfix SMTP client will still be able to read the
+    SASL client passwords. It opens the file as user root before it drops
+    privileges, and before entering an optional chroot jail.
+
+  * Use the postmap command whenever you change the /etc/postfix/sasl_passwd
+    file.
+
+  * If you specify the "[" and "]" in the relayhost destination, then you must
+    use the same form in the smtp_sasl_password_maps file.
+
+  * If you specify a non-default TCP Port (such as ":submission" or ":587") in
+    the relayhost destination, then you must use the same form in the
+    smtp_sasl_password_maps file.
+
+CCoonnffiigguurriinngg SSeennddeerr--DDeeppeennddeenntt SSAASSLL aauutthheennttiiccaattiioonn
+
+Postfix supports different ISP accounts for different sender addresses (version
+2.3 and later). This can be useful when one person uses the same machine for
+work and for personal use, or when people with different ISP accounts share the
+same Postfix server.
+
+To make this possible, Postfix supports per-sender SASL passwords and per-
+sender relay hosts. In the example below, the Postfix SMTP client will search
+the SASL password file by sender address before it searches that same file by
+destination. Likewise, the Postfix trivial-rewrite(8) daemon will search the
+per-sender relayhost file, and use the default relayhost setting only as a
+final resort.
+
+    /etc/postfix/main.cf:
+        smtp_sender_dependent_authentication = yes
+        sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
+        smtp_sasl_auth_enable = yes
+        smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+        relayhost = [mail.isp.example]
+        # Alternative form:
+        # relayhost = [mail.isp.example]:submission
+
+    /etc/postfix/sasl_passwd:
+        # Per-sender authentication; see also /etc/postfix/sender_relay.
+        user1@example.com               username1:password1
+        user2@example.net               username2:password2
+        # Login information for the default relayhost.
+        [mail.isp.example]              username:password
+        # Alternative form:
+        # [mail.isp.example]:submission username:password
+
+    /etc/postfix/sender_relay:
+        # Per-sender provider; see also /etc/postfix/sasl_passwd.
+        user1@example.com               [mail.example.com]:submission
+        user2@example.net               [mail.example.net]
+
+  * If you are creative, then you can try to combine the two tables into one
+    single MySQL database, and configure different Postfix queries to extract
+    the appropriate information.
+
+  * 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".
+
+  * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change
+    the sasl_passwd table.
+
+  * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//sseennddeerr__rreellaayy" whenever you change
+    the sender_relay table.
+
--- a/README_FILES/SQLITE_README
+++ b/README_FILES/SQLITE_README
@ -0,0 +1,74 @@
+PPoossttffiixx SSQQLLiittee HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+The Postfix sqlite map type allows you to hook up Postfix to a SQLite database.
+This implementation allows for multiple sqlite databases: you can use one for a
+virtual(5) table, one for an access(5) table, and one for an aliases(5) table
+if you want.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh SSQQLLiittee ssuuppppoorrtt
+
+The Postfix SQLite client utilizes the sqlite3 library, which can be obtained
+from:
+
+    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
+header files, and you will need to add to AUXLIBS the directory and name of the
+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"
+
+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-
+loaded SQLite database client, but only the new AUXLIBS_SQLITE variable
+supports building a dynamically-loaded or statically-loaded SQLite database
+client.
+
+    Failure to use the AUXLIBS_SQLITE variable will defeat the purpose of
+    dynamic database client loading. Every Postfix executable file will have
+    SQLITE database library dependencies. And that was exactly what dynamic
+    database client loading was meant to avoid.
+
+Then, just run 'make'.
+
+UUssiinngg SSQQLLiittee ttaabblleess
+
+Once Postfix is built with sqlite support, you can specify a map type in
+main.cf like this:
+
+    alias_maps = sqlite:/etc/postfix/sqlite-aliases.cf
+
+The file /etc/postfix/sqlite-aliases.cf specifies lots of information telling
+Postfix how to reference the sqlite database. For a complete description, see
+the sqlite_table(5) manual page.
+
+EExxaammppllee:: llooccaall aalliiaasseess
+
+#
+# sqlite config file for local(8) aliases(5) lookups
+#
+
+# Path to database
+dbpath = /some/path/to/sqlite_database
+
+# See sqlite_table(5) for details.
+query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
+
+CCrreeddiittss
+
+SQLite support was added with Postfix version 2.8.
+
+  * Implementation by Axel Steiner
+  * Documentation by Jesus Garcia Crespo
+
--- a/README_FILES/STANDARD_CONFIGURATION_README
+++ b/README_FILES/STANDARD_CONFIGURATION_README
@ -0,0 +1,637 @@
+PPoossttffiixx SSttaannddaarrdd CCoonnffiigguurraattiioonn EExxaammpplleess
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document presents a number of typical Postfix configurations. This
+document should be reviewed after you have followed the basic configuration
+steps as described in the BASIC_CONFIGURATION_README document. In particular,
+do not proceed here if you don't already have Postfix working for local mail
+submission and for local mail delivery.
+
+The first part of this document presents standard configurations that each
+solve one specific problem.
+
+  * Postfix on a stand-alone Internet host
+  * Postfix on a null client
+  * Postfix on a local network
+  * Postfix email firewall/gateway
+
+The second part of this document presents additional configurations for hosts
+in specific environments.
+
+  * Delivering some but not all accounts locally
+  * Running Postfix behind a firewall
+  * Configuring Postfix as primary or backup MX host for a remote site
+  * Postfix on a dialup machine
+  * Postfix on hosts without a real Internet hostname
+
+PPoossttffiixx oonn aa ssttaanndd--aalloonnee IInntteerrnneett hhoosstt
+
+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 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
+on a stand-alone box, beyond what is covered in the BASIC_CONFIGURATION_README
+document:
+
+    /etc/postfix/main.cf:
+        # Optional: send mail as user@domainname instead of user@hostname.
+        #myorigin = $mydomain
+
+        # Optional: specify NAT/proxy external address.
+        #proxy_interfaces = 1.2.3.4
+
+        # Alternative 1: don't relay mail from other hosts.
+        mynetworks_style = host
+        relay_domains =
+
+        # Alternative 2: relay mail from local clients only.
+        # mynetworks = 192.168.1.0/28
+        # relay_domains =
+
+See also the section "Postfix on hosts without a real Internet hostname" if
+this is applicable to your configuration.
+
+PPoossttffiixx oonn aa nnuullll cclliieenntt
+
+A null client is a machine that can only send mail. It receives no mail from
+the network, and it does not deliver any mail locally. A null client typically
+uses POP, IMAP or NFS for mailbox access.
+
+In this example we assume that the Internet domain name is "example.com" and
+that the machine is named "hostname.example.com". As usual, the examples show
+only parameters that are not left at their default settings.
+
+    1 /etc/postfix/main.cf:
+    2     myhostname = hostname.example.com
+    3     myorigin = $mydomain
+    4     relayhost = $mydomain
+    5     inet_interfaces = loopback-only
+    6     mydestination =
+
+Translation:
+
+  * Line 2: Set myhostname to hostname.example.com, in case the machine name
+    isn't set to a fully-qualified domain name (use the command "postconf -
+    d myhostname" to find out what the machine name is).
+
+  * Line 2: The myhostname value also provides the default value for the
+    mydomain parameter (here, "mydomain = example.com").
+
+  * Line 3: Send mail as "user@example.com" (instead of
+    "user@hostname.example.com"), so that nothing ever has a reason to send
+    mail to "user@hostname.example.com".
+
+  * Line 4: Forward all mail to the mail server that is responsible for the
+    "example.com" domain. This prevents mail from getting stuck on the null
+    client if it is turned off while some remote destination is unreachable.
+    Specify a real hostname here if your "example.com" domain has no MX record.
+
+  * Line 5: Do not accept mail from the network.
+
+  * Line 6: Disable local mail delivery. All mail goes to the mail server as
+    specified in line 4.
+
+PPoossttffiixx oonn aa llooccaall nneettwwoorrkk
+
+This section describes a local area network environment of one main server and
+multiple other systems that send and receive email. As usual we assume that the
+Internet domain name is "example.com". All systems are configured to send mail
+as "user@example.com", and all systems receive mail for
+"user@hostname.example.com". The main server also receives mail for
+"user@example.com". We call this machine by the name of mailhost.example.com.
+
+A drawback of sending mail as "user@example.com" is that mail for "root" and
+other system accounts is also sent to the central mailhost. See the section
+"Delivering some but not all accounts locally" below for possible solutions.
+
+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 the final destination for
+"user@hostname.example.com".
+
+    1 /etc/postfix/main.cf:
+    2     myorigin = $mydomain
+    3     mynetworks = 127.0.0.0/8 10.0.0.0/24
+    4     relay_domains =
+    5     # Optional: forward all non-local mail to mailhost
+    6     #relayhost = $mydomain
+
+Translation:
+
+  * Line 2: Send mail as "user@example.com".
+
+  * Line 3: Specify the trusted networks.
+
+  * Line 4: This host does not relay mail from untrusted networks.
+
+  * Line 6: This is needed if no direct Internet access is available. See also
+    below, "Postfix behind a firewall".
+
+Next we present the mailhost configuration. This machine sends mail as
+"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.
+     3
+     4 /etc/postfix/main.cf:
+     5     myorigin = $mydomain
+     6     mydestination = $myhostname localhost.$mydomain localhost $mydomain
+     7     mynetworks = 127.0.0.0/8 10.0.0.0/24
+     8     relay_domains =
+     9     # Optional: forward all non-local mail to firewall
+    10     #relayhost = [firewall.example.com]
+
+Translation:
+
+  * Line 2: Send mail for the domain "example.com" to the machine
+    mailhost.example.com. Remember to specify the "." at the end of the line.
+
+  * Line 5: Send mail as "user@example.com".
+
+  * Line 6: This host is the final mail destination for the "example.com"
+    domain, in addition to the names of the machine itself.
+
+  * Line 7: Specify the trusted networks.
+
+  * Line 8: This host does not relay mail from untrusted networks.
+
+  * Line 10: This is needed only when the mailhost has to forward non-local
+    mail via a mail server on a firewall. The [] forces Postfix to do no MX
+    record lookups.
+
+In an environment like this, users access their mailbox in one or more of the
+following ways:
+
+  * Mailbox access via NFS or equivalent.
+
+  * Mailbox access via POP or IMAP.
+
+  * Mailbox on the user's preferred machine.
+
+In the latter case, each user has an alias on the mailhost that forwards mail
+to her preferred machine:
+
+    /etc/aliases:
+        joe:    joe@joes.preferred.machine
+        jane:   jane@janes.preferred.machine
+
+On some systems the alias database is not in /etc/aliases. To find out the
+location for your system, execute the command "ppoossttccoonnff aalliiaass__mmaappss".
+
+Execute the command "nneewwaalliiaasseess" whenever you change the aliases file.
+
+PPoossttffiixx eemmaaiill ffiirreewwaallll//ggaatteewwaayy
+
+The idea is to set up a Postfix email firewall/gateway that forwards mail for
+"example.com" to an inside gateway machine but rejects mail for
+"anything.example.com". There is only one problem: with "relay_domains =
+example.com", the firewall normally also accepts mail for
+"anything.example.com". That would not be right.
+
+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 solution is presented in multiple parts. This first part gets rid of local
+mail delivery on the firewall, making the firewall harder to break.
+
+    1 /etc/postfix/main.cf:
+    2     myorigin = example.com
+    3     mydestination =
+    4     local_recipient_maps =
+    5     local_transport = error:local mail delivery is disabled
+    6
+    7 /etc/postfix/master.cf:
+    8     Comment out the local delivery agent
+
+Translation:
+
+  * Line 2: Send mail from this machine as "user@example.com", so that no
+    reason exists to send mail to "user@firewall.example.com".
+
+  * Lines 3-8: Disable local mail delivery on the firewall machine.
+
+For the sake of technical correctness the firewall must be able to receive mail
+for postmaster@[firewall ip address]. Reportedly, some things actually expect
+this ability to exist. The second part of the solution therefore adds support
+for postmaster@[firewall ip address], and as a bonus we do abuse@[firewall ip
+address] as well. All the mail to these two accounts is forwarded to an inside
+address.
+
+    1 /etc/postfix/main.cf:
+    2     virtual_alias_maps = hash:/etc/postfix/virtual
+    3
+    4 /etc/postfix/virtual:
+    5     postmaster      postmaster@example.com
+    6     abuse           abuse@example.com
+
+Translation:
+
+  * Because mydestination is empty (see the previous example), only address
+    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
+    in Postfix configuration files.
+
+The last part of the solution does the email forwarding, which is the real
+purpose of the firewall email function.
+
+     1 /etc/postfix/main.cf:
+     2     mynetworks = 127.0.0.0/8 12.34.56.0/24
+     3     relay_domains = example.com
+     4     parent_domain_matches_subdomains =
+     5         debug_peer_list smtpd_access_maps
+
+     6a    # Postfix 2.10 and later support separate relay control and
+     7a    # spam control.
+     8a    smtpd_relay_restrictions =
+     9a        permit_mynetworks reject_unauth_destination
+    10a    smtpd_recipient_restrictions = ...spam blocking rules....
+
+     6b    # Older configurations combine relay control and spam control. To
+     7b    # use this with Postfix >= 2.10 specify "smtpd_relay_restrictions=".
+     8b    smtpd_recipient_restrictions =
+     9b        permit_mynetworks reject_unauth_destination
+    10b        ...spam blocking rules....
+
+    11     relay_recipient_maps = hash:/etc/postfix/relay_recipients
+    12     transport_maps = hash:/etc/postfix/transport
+    13
+    14 /etc/postfix/relay_recipients:
+    15     user1@example.com   x
+    16     user2@example.com   x
+    17      . . .
+    18
+    19 /etc/postfix/transport:
+    20     example.com   relay:[inside-gateway.example.com]
+
+Translation:
+
+  * Lines 1-10: Accept mail from local systems in $mynetworks, and accept mail
+    from outside for "user@example.com" but not for
+    "user@anything.example.com". The magic is in lines 4-5.
+
+  * Lines 11, 13-16: Define the list of valid addresses in the "example.com"
+    domain that can receive mail from the Internet. This prevents the mail
+    queue from filling up with undeliverable MAILER-DAEMON messages. If you
+    can't maintain a list of valid recipients then you must specify
+    "relay_recipient_maps =" (that is, an empty value), or you must specify an
+    "@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. 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".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//rreellaayy__rreecciippiieennttss" whenever you change
+the relay_recipients table.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you change the
+transport table.
+
+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 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
+will also use the specified interface address as the source address for
+outbound connections and will be unable to reach hosts on "the other side" of
+the firewall. The symptoms are that the firewall is unable to connect to hosts
+that are in fact up. See the inet_interfaces parameter documentation for
+suggested work-arounds.
+
+DDeelliivveerriinngg ssoommee bbuutt nnoott aallll aaccccoouunnttss llooccaallllyy
+
+A drawback of sending mail as "user@example.com" (instead of
+"user@hostname.example.com") is that mail for "root" and other system accounts
+is also sent to the central mailhost. In order to deliver such accounts
+locally, you can set up virtual aliases as follows:
+
+    1 /etc/postfix/main.cf:
+    2     virtual_alias_maps = hash:/etc/postfix/virtual
+    3
+    4 /etc/postfix/virtual:
+    5     root     root@localhost
+    6     . . .
+
+Translation:
+
+  * Line 5: As described in the virtual(5) manual page, the bare name "root"
+    matches "root@site" when "site" is equal to $myorigin, when "site" is
+    listed in $mydestination, or when it matches $inet_interfaces or
+    $proxy_interfaces.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after editing the file.
+
+RRuunnnniinngg PPoossttffiixx bbeehhiinndd aa ffiirreewwaallll
+
+The simplest way to set up Postfix on a host behind a firewalled network is to
+send all mail to a gateway host, and to let that mail host take care of
+internal and external forwarding. Examples of that are shown in the local area
+network section above. A more sophisticated approach is to send only external
+mail to the gateway host, and to send intranet mail directly.
+
+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 in the first half of
+this document.
+
+     1 /etc/postfix/main.cf:
+     2     transport_maps = hash:/etc/postfix/transport
+     3     relayhost =
+     4     # Optional for a machine that isn't "always on"
+     5     #fallback_relay = [gateway.example.com]
+     6
+     7 /etc/postfix/transport:
+     8     # Internal delivery.
+     9     example.com      :
+    10     .example.com     :
+    11     # External delivery.
+    12     *                smtp:[gateway.example.com]
+
+Translation:
+
+  * Lines 2, 7-12: Request that intranet mail is delivered directly, and that
+    external mail is given to a gateway. Obviously, this example assumes that
+    the organization uses DNS MX records internally. The [] forces Postfix to
+    do no MX lookup.
+
+  * Line 3: IMPORTANT: do not specify a relayhost in main.cf.
+
+  * Line 5: This prevents mail from being stuck in the queue when the machine
+    is turned off. Postfix tries to deliver mail directly, and gives
+    undeliverable mail to a gateway.
+
+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".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you edit the
+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 in the first half of this
+document.
+
+When your system is SECONDARY MX host for a remote site this is all you need:
+
+     1 DNS:
+     2     the.backed-up.domain.tld        IN      MX 100 your.machine.tld.
+     3
+     4 /etc/postfix/main.cf:
+     5     relay_domains = . . . the.backed-up.domain.tld
+
+     6a    # Postfix 2.10 and later support separate relay control and
+     7a    # spam control.
+     8a    smtpd_relay_restrictions =
+     9a        permit_mynetworks reject_unauth_destination
+    10a    smtpd_recipient_restrictions = ...spam blocking rules....
+
+     6b    # Older configurations combine relay control and spam control. To
+     7b    # use this with Postfix >= 2.10 specify "smtpd_relay_restrictions=".
+     8b    smtpd_recipient_restrictions =
+     9b        permit_mynetworks reject_unauth_destination
+    10b        ...spam blocking rules....
+
+    11     # You must specify your NAT/proxy external address.
+    12     #proxy_interfaces = 1.2.3.4
+    13
+    14     relay_recipient_maps = hash:/etc/postfix/relay_recipients
+    15
+    16 /etc/postfix/relay_recipients:
+    17     user1@the.backed-up.domain.tld   x
+    18     user2@the.backed-up.domain.tld   x
+    19      . . .
+
+When your system is PRIMARY MX host for a remote site you need the above, plus:
+
+    20 /etc/postfix/main.cf:
+    21     transport_maps = hash:/etc/postfix/transport
+    22
+    23 /etc/postfix/transport:
+    24     the.backed-up.domain.tld       relay:[their.mail.host.tld]
+
+Important notes:
+
+  * Do not list the.backed-up.domain.tld in mydestination.
+
+  * Do not list the.backed-up.domain.tld in virtual_alias_domains.
+
+  * Do not list the.backed-up.domain.tld in virtual_mailbox_domains.
+
+  * Lines 1-9: Forward mail from the Internet for "the.backed-up.domain.tld" to
+    the primary MX host for that domain.
+
+  * Line 12: This is a must if Postfix receives mail via a NAT relay or proxy
+    that presents a different IP address to the world than the local machine.
+
+  * Lines 14-18: Define the list of valid addresses in the "the.backed-
+    up.domain.tld" domain. This prevents your mail queue from filling up with
+    undeliverable MAILER-DAEMON messages. If you can't maintain a list of valid
+    recipients then you must specify "relay_recipient_maps =" (that is, an
+    empty value), or you must specify an "@the.backed-up.domain.tld x" wild-
+    card in the relay_recipients table.
+
+  * Line 24: The [] forces Postfix to do no MX lookup.
+
+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".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you change the
+transport table.
+
+NOTE for Postfix < 2.2: Do not use the fallback_relay feature when relaying
+mail for a backup or primary MX domain. Mail would loop between the Postfix MX
+host and the fallback_relay host when the final destination is unavailable.
+
+  * In main.cf specify "relay_transport = relay",
+  * In master.cf specify "-o fallback_relay =" at the end of the relay entry.
+  * In transport maps, specify "relay:nexthop..." as the right-hand side for
+    backup or primary MX domain entries.
+
+These are default settings in Postfix version 2.2 and later.
+
+PPoossttffiixx oonn aa ddiiaalluupp mmaacchhiinnee
+
+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 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
+hosts without a real Internet hostname".
+
+  * Route all outgoing mail to your network provider.
+    If your machine is disconnected most of the time, there isn't a lot of
+    opportunity for Postfix to deliver mail to hard-to-reach corners of the
+    Internet. It's better to give the mail to a machine that is connected all
+    the time. In the example below, the [] prevents Postfix from trying to look
+    up DNS MX records.
+
+    /etc/postfix/main.cf:
+        relayhost = [smtprelay.someprovider.com]
+
+  * Disable spontaneous SMTP mail delivery (if using on-demand dialup IP only).
+
+    Normally, Postfix attempts to deliver outbound mail at its convenience. If
+    your machine uses on-demand dialup IP, this causes your system to place a
+    telephone call whenever you submit new mail, and whenever Postfix retries
+    to deliver delayed mail. To prevent such telephone calls from being placed,
+    disable spontaneous SMTP mail deliveries.
+
+    /etc/postfix/main.cf:
+        defer_transports = smtp (Only for on-demand dialup IP hosts)
+
+  * Disable SMTP client DNS lookups (dialup LAN only).
+
+    /etc/postfix/main.cf:
+        disable_dns_lookups = yes (Only for on-demand dialup IP hosts)
+
+  * Flush the mail queue whenever the Internet link is established.
+    Put the following command into your PPP or SLIP dialup scripts:
+
+    /usr/sbin/sendmail -q (whenever the Internet link is up)
+
+    The exact location of the Postfix sendmail command is system-specific. Use
+    the command "ppoossttccoonnff sseennddmmaaiill__ppaatthh" to find out where the Postfix sendmail
+    command is located on your machine.
+
+    In order to find out if the mail queue is flushed, use something like:
+
+    #!/bin/sh
+
+    # Start mail deliveries.
+    /usr/sbin/sendmail -q
+
+    # Allow deliveries to start.
+    sleep 10
+
+    # Loop until all messages have been tried at least once.
+    while mailq | grep '^[^ ]*\*' >/dev/null
+    do
+        sleep 10
+    done
+
+    If you have disabled spontaneous SMTP mail delivery, you also need to run
+    the "sseennddmmaaiill --qq" command every now and then while the dialup link is up,
+    so that newly-posted mail is flushed from the queue.
+
+PPoossttffiixx oonn hhoossttss wwiitthhoouutt aa rreeaall IInntteerrnneett hhoossttnnaammee
+
+This section is for hosts that don't have their own Internet hostname.
+Typically these are systems that get a dynamic IP address via DHCP or via
+dialup. Postfix will let you send and receive mail just fine between accounts
+on a machine with a fantasy name. However, you cannot use a fantasy hostname in
+your email address when sending mail into the Internet, because no-one would be
+able to reply to your mail. In fact, more and more sites refuse mail addresses
+with non-existent domain names.
+
+Note: the following information is Postfix version dependent. To find out what
+Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
+
+SSoolluuttiioonn 11:: PPoossttffiixx vveerrssiioonn 22..22 aanndd llaatteerr
+
+Postfix 2.2 uses the generic(5) address mapping to replace local fantasy email
+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 in the first half of
+this document.
+
+    1 /etc/postfix/main.cf:
+    2     smtp_generic_maps = hash:/etc/postfix/generic
+    3
+    4 /etc/postfix/generic:
+    5     his@localdomain.local             hisaccount@hisisp.example
+    6     her@localdomain.local             heraccount@herisp.example
+    7     @localdomain.local                hisaccount+local@hisisp.example
+
+When mail is sent to a remote host via SMTP:
+
+  * Line 5 replaces his@localdomain.local by his ISP mail address,
+
+  * Line 6 replaces her@localdomain.local by her ISP mail address, and
+
+  * Line 7 replaces other local addresses by his ISP account, with an address
+    extension of +local (this example assumes that the ISP supports "+" style
+    address extensions).
+
+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".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ggeenneerriicc" whenever you change the
+generic table.
+
+SSoolluuttiioonn 22:: PPoossttffiixx vveerrssiioonn 22..11 aanndd eeaarrlliieerr
+
+The solution with older Postfix systems is to use valid Internet addresses
+where possible, and to let Postfix map valid Internet addresses to local
+fantasy addresses. With this, you can send mail to the Internet and to local
+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 in the first half of
+this document.
+
+     1 /etc/postfix/main.cf:
+     2     myhostname = hostname.localdomain
+     3     mydomain = localdomain
+     4
+     5     canonical_maps = hash:/etc/postfix/canonical
+     6
+     7     virtual_alias_maps = hash:/etc/postfix/virtual
+     8
+     9 /etc/postfix/canonical:
+    10     your-login-name    your-account@your-isp.com
+    11
+    12 /etc/postfix/virtual:
+    13     your-account@your-isp.com       your-login-name
+
+Translation:
+
+  * Lines 2-3: Substitute your fantasy hostname here. Do not use a domain name
+    that is already in use by real organizations on the Internet. See RFC 2606
+    for examples of domain names that are guaranteed not to be owned by anyone.
+
+  * Lines 5, 9, 10: This provides the mapping from "your-login-
+    name@hostname.localdomain" to "your-account@your-isp.com". This part is
+    required.
+
+  * Lines 7, 12, 13: Deliver mail for "your-account@your-isp.com" locally,
+    instead of sending it to the ISP. This part is not required but is
+    convenient.
+
+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".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ccaannoonniiccaall" whenever you change the
+canonical table.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" whenever you change the
+virtual table.
+
--- a/README_FILES/STRESS_README
+++ b/README_FILES/STRESS_README
@ -0,0 +1,426 @@
+PPoossttffiixx SSttrreessss--DDeeppeennddeenntt CCoonnffiigguurraattiioonn
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document describes the symptoms of Postfix SMTP server overload. It
+presents permanent main.cf changes to avoid overload during normal operation,
+and temporary main.cf changes to cope with an unexpected burst of mail. This
+document makes specific suggestions for Postfix 2.5 and later which support
+stress-adaptive behavior, and for earlier Postfix versions that don't.
+
+Topics covered in this document:
+
+  * Symptoms of Postfix SMTP server overload
+  * Automatic stress-adaptive behavior
+  * Service more SMTP clients at the same time
+  * Spend less time per SMTP client
+  * Disconnect suspicious SMTP clients
+  * Temporary measures for older Postfix releases
+  * Detecting support for stress-adaptive behavior
+  * Forcing stress-adaptive behavior on or off
+  * Other measures to off-load zombies
+  * Credits
+
+SSyymmppttoommss ooff PPoossttffiixx SSMMTTPP sseerrvveerr oovveerrllooaadd
+
+Under normal conditions, the Postfix SMTP server responds immediately when an
+SMTP client connects to it; the time to deliver mail is noticeable only with
+large messages. Performance degrades dramatically when the number of SMTP
+clients exceeds the number of Postfix SMTP server processes. When an SMTP
+client connects while all Postfix SMTP server processes are busy, the client
+must wait until a server process becomes available.
+
+SMTP server overload may be caused by a surge of legitimate mail (example: a
+DNS registrar opens a new zone for registrations), by mistake (mail explosion
+caused by a forwarding loop) or by malice (worm outbreak, botnet, or other
+illegitimate activity).
+
+Symptoms of Postfix SMTP server overload are:
+
+  * Remote SMTP clients experience a long delay before Postfix sends the "220
+    hostname.example.com ESMTP Postfix" greeting.
+
+      o NOTE: Broken DNS configurations can also cause lengthy delays before
+        Postfix sends "220 hostname.example.com ...". These delays also exist
+        when Postfix is NOT overloaded.
+
+      o NOTE: To avoid "overload" delays for end-user mail clients, enable the
+        "submission" service entry in master.cf (present since Postfix 2.1),
+        and tell users to connect to this instead of the public SMTP service.
+
+  * The Postfix SMTP server logs an increased number of "lost connection after
+    CONNECT" events. This happens because remote SMTP clients disconnect before
+    Postfix answers the connection.
+
+      o NOTE: A portscan for open SMTP ports can also result in "lost
+        connection ..." logfile messages.
+
+  * Postfix 2.3 and later logs a warning that all server ports are busy:
+
+    Oct  3 20:39:27 spike postfix/master[28905]: warning: service "smtp"
+     (25) has reached its process limit "30": new clients may experience
+     noticeable delays
+    Oct  3 20:39:27 spike postfix/master[28905]: warning: to avoid this
+     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
+      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
+server overload is not necessarily lost. It should still arrive once the
+situation returns to normal, as long as the overload condition is temporary.
+
+AAuuttoommaattiicc ssttrreessss--aaddaappttiivvee bbeehhaavviioorr
+
+Postfix version 2.5 introduces automatic stress-adaptive behavior. It works as
+follows. When a "public" network service such as the SMTP server runs into an
+"all server ports are busy" condition, the Postfix master(8) daemon logs a
+warning, restarts the service (without interrupting existing network sessions),
+and runs the service with "-o stress=yes" on the server process command line:
+
+    80821  ??  S      0:00.24 smtpd -n smtp -t inet -u -c -o stress=yes
+
+Normally, the Postfix master(8) daemon runs such a service with "-o stress=" on
+the command line (i.e. with an empty parameter value):
+
+    83326  ??  S      0:00.28 smtpd -n smtp -t inet -u -c -o stress=
+
+You won't see "-o stress" command-line parameters with services that have local
+clients only. These include services internal to Postfix such as the queue
+manager, and services that listen on a loopback interface only, such as after-
+filter SMTP services.
+
+The "stress" parameter value is the key to making main.cf parameter settings
+stress adaptive. The following settings are the default with Postfix 2.6 and
+later.
+
+    1 smtpd_timeout = ${stress?{10}:{300}}s
+    2 smtpd_hard_error_limit = ${stress?{1}:{20}}
+    3 smtpd_junk_command_limit = ${stress?{1}:{100}}
+    4 # Parameters added after Postfix 2.6:
+    5 smtpd_per_record_deadline = ${stress?{yes}:{no}}
+    6 smtpd_starttls_timeout = ${stress?{10}:{300}}s
+    7 address_verify_poll_count = ${stress?{1}:{3}}
+
+Postfix versions before 3.0 use the older form ${stress?x}${stress:y} instead
+of the newer form ${stress?{x}:{y}}.
+
+The syntax of ${name?{value}:{value}}, ${name?value} and ${name:value} is
+explained at the beginning of the postconf(5) manual page.
+
+Translation:
+
+  * Line 1: under conditions of stress, use an smtpd_timeout value of 10
+    seconds instead of the default 300 seconds. Experience on the postfix-users
+    list from a variety of sysadmins shows that reducing the "normal"
+    smtpd_timeout to 60s is unlikely to affect legitimate clients. However, it
+    is unlikely to become the Postfix default because it's not RFC compliant.
+    Setting smtpd_timeout to 10s or even 5s under stress will still allow most
+    legitimate clients to connect and send mail, but may delay mail from some
+    clients. No mail should be lost, as long as this measure is used only
+    temporarily.
+
+  * Line 2: under conditions of stress, use an smtpd_hard_error_limit of 1
+    instead of the default 20. This disconnects clients after a single error,
+    giving other clients a chance to connect. However, this may cause
+    significant delays with legitimate mail, such as a mailing list that
+    contains a few no-longer-active user names that didn't bother to
+    unsubscribe. No mail should be lost, as long as this measure is used only
+    temporarily.
+
+  * Line 3: under conditions of stress, use an smtpd_junk_command_limit of 1
+    instead of the default 100. This prevents clients from keeping connections
+    open by repeatedly sending HELO, EHLO, NOOP, RSET, VRFY or ETRN commands.
+
+  * Line 5: under conditions of stress, change the behavior of smtpd_timeout
+    and smtpd_starttls_timeout, from a time limit per read or write system
+    call, to a time limit to send or receive a complete record (an SMTP command
+    line, SMTP response line, SMTP message content line, or TLS protocol
+    message).
+
+  * Line 6: under conditions of stress, reduce the time limit for TLS protocol
+    handshake messages to 10 seconds, from the default value of 300 seconds.
+    See also the smtpd_timeout discussion above.
+
+  * Line 7: under conditions of stress, do not wait up to 6 seconds for the
+    completion of an address verification probe. If the result is not already
+    in the address verification cache, reply immediately with
+    $unverified_recipient_tempfail_action or
+    $unverified_sender_tempfail_action. No mail should be lost, as long as this
+    measure is used only temporarily.
+
+NOTE: Please keep in mind that the stress-adaptive feature is a fairly
+desperate measure to keep ssoommee legitimate mail flowing under overload
+conditions. If a site is reaching the SMTP server process limit when there
+isn't an attack or bot flood occurring, then either the process limit needs to
+be raised or more hardware needs to be added.
+
+SSeerrvviiccee mmoorree SSMMTTPP cclliieennttss aatt tthhee ssaammee ttiimmee
+
+This section and the ones that follow discuss permanent measures against mail
+server overload.
+
+One measure to avoid the "all server processes busy" condition is to service
+more SMTP clients simultaneously. For this you need to increase the number of
+Postfix SMTP server processes. This will improve the responsiveness for remote
+SMTP clients, as long as the server machine has enough hardware and software
+resources to run the additional processes, and as long as the file system can
+keep up with the additional load.
+
+  * You increase the number of SMTP server processes either by increasing the
+    default_process_limit in main.cf (line 3 below), or by increasing the SMTP
+    server's "maxproc" field in master.cf (line 10 below). Either way, you need
+    to issue a "postfix reload" command to make the change effective.
+
+  * Process limits above 1000 require Postfix version 2.4 or later, and an
+    operating system that supports kernel-based event filters (BSD kqueue(2),
+    Linux epoll(4), or Solaris /dev/poll).
+
+  * More processes use more memory. You can reduce the Postfix memory footprint
+    by using cdb: lookup tables instead of Berkeley DB's hash: or btree:
+    tables.
+
+     1 /etc/postfix/main.cf:
+     2     # Raise the global process limit, 100 since Postfix 2.0.
+     3     default_process_limit = 200
+     4
+     5 /etc/postfix/master.cf:
+     6     # =============================================================
+     7     # service type  private unpriv  chroot  wakeup  maxproc command
+     8     # =============================================================
+     9     # Raise the SMTP service process limit only.
+    10     smtp      inet  n       -       n       -       200     smtpd
+
+  * NOTE: older versions of the SMTPD_POLICY_README document contain a mistake:
+    they configure a fixed number of policy daemon processes. When you raise
+    the SMTP server's "maxproc" field in master.cf, SMTP server processes will
+    report problems when connecting to policy server processes, because there
+    aren't enough of them. Examples of errors are "connection refused" or
+    "operation timed out".
+
+    To fix, edit master.cf and specify a zero "maxproc" field in all policy
+    server entries; see line 6 in the example below. Issue a "postfix reload"
+    command to make the change effective.
+
+    1 /etc/postfix/master.cf:
+    2     # =============================================================
+    3     # service type  private unpriv  chroot  wakeup  maxproc command
+    4     # =============================================================
+    5     # Disable the policy service process limit.
+    6     policy    unix  -       n       n       -       0       spawn
+    7         user=nobody argv=/some/where/policy-server
+
+SSppeenndd lleessss ttiimmee ppeerr SSMMTTPP cclliieenntt
+
+When increasing the number of SMTP server processes is not practical, you can
+improve Postfix server responsiveness by eliminating delays. When Postfix
+spends less time per SMTP session, the same number of SMTP server processes can
+service more clients in a given amount of time.
+
+  * Eliminate non-functional RBL lookups (blocklists that are no longer in
+    operation). These lookups can degrade performance. Postfix logs a warning
+    when an RBL server does not respond.
+
+  * Eliminate redundant RBL lookups (people often use multiple Spamhaus RBLs
+    that include each other). To find out whether RBLs include other RBLs, look
+    up the websites that document the RBL's policies.
+
+  * Eliminate header_checks and body_checks, and keep just a few emergency
+    patterns to block the latest worm explosion or backscatter mail. See
+    BACKSCATTER_README for examples of the latter.
+
+  * Group your header_checks and body_checks patterns to avoid unnecessary
+    pattern matching operations:
+
+     1  /etc/postfix/header_checks:
+     2      if /^Subject:/
+     3      /^Subject: virus found in mail from you/ reject
+     4      /^Subject: ..other../ reject
+     5      endif
+     6
+     7      if /^Received:/
+     8      /^Received: from (postfix\.org) / reject forged client name in
+    received header: $1
+     9      /^Received: from ..other../ reject ....
+    10      endif
+
+DDiissccoonnnneecctt ssuussppiicciioouuss SSMMTTPP cclliieennttss
+
+Under conditions of overload you can improve Postfix SMTP server responsiveness
+by hanging up on suspicious clients, so that other clients get a chance to talk
+to Postfix.
+
+  * Use "521" SMTP reply codes (Postfix 2.6 and later) or "421" (Postfix 2.3-
+    2.5) to hang up on clients that that match botnet-related RBLs (see next
+    bullet) or that match selected non-RBL restrictions such as SMTP access
+    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 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
+    documents say that a response of 127.0.0.10 or 127.0.0.11 indicates a
+    dynamic client IP address, which means that the machine is probably running
+    a bot of some kind. To give a 521 response instead of the default 554
+    response, use something like:
+
+     1  /etc/postfix/main.cf:
+     2      smtpd_client_restrictions =
+     3         permit_mynetworks
+     4         reject_rbl_client zen.spamhaus.org=127.0.0.10
+     5         reject_rbl_client zen.spamhaus.org=127.0.0.11
+     6         reject_rbl_client zen.spamhaus.org
+     7
+     8      rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps
+     9
+    10  /etc/postfix/rbl_reply_maps:
+    11      # With Postfix 2.3-2.5 use "421" to hang up connections.
+    12      zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable;
+    13       $rbl_class [$rbl_what] blocked using
+    14       $rbl_domain${rbl_reason?; $rbl_reason}
+    15
+    16      zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable;
+    17       $rbl_class [$rbl_what] blocked using
+    18       $rbl_domain${rbl_reason?; $rbl_reason}
+
+    Although the above example shows three RBL lookups (lines 4-6), Postfix
+    will only do a single DNS query, so it does not affect the performance.
+
+  * With Postfix 2.3-2.5, use reply code 421 (521 will not cause Postfix to
+    disconnect). The down-side of replying with 421 is that it works only for
+    zombies and other malware. If the client is running a real MTA, then it may
+    connect again several times until the mail expires in its queue. When this
+    is a problem, stick with the default 554 reply, and use
+    "smtpd_hard_error_limit = 1" as described below.
+
+  * 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 https://
+    www.postfix.org/download.html. Simply replace line above 8 with:
+
+     8      rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
+
+More information about automatic stress-adaptive behavior is in section
+"Automatic stress-adaptive behavior".
+
+TTeemmppoorraarryy mmeeaassuurreess ffoorr oollddeerr PPoossttffiixx rreelleeaasseess
+
+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 https://www.postfix.org/
+download.html.
+
+The following measures can be applied temporarily during overload. They still
+allow mmoosstt legitimate clients to connect and send mail, but may affect some
+legitimate clients.
+
+  * Reduce smtpd_timeout (default: 300s). Experience on the postfix-users list
+    from a variety of sysadmins shows that reducing the "normal" smtpd_timeout
+    to 60s is unlikely to affect legitimate clients. However, it is unlikely to
+    become the Postfix default because it's not RFC compliant. Setting
+    smtpd_timeout to 10s (line 2 below) or even 5s under stress will still
+    allow mmoosstt legitimate clients to connect and send mail, but may delay mail
+    from some clients. No mail should be lost, as long as this measure is used
+    only temporarily.
+
+  * Reduce smtpd_hard_error_limit (default: 20). Setting this to 1 under stress
+    (line 3 below) helps by disconnecting clients after a single error, giving
+    other clients a chance to connect. However, this may cause significant
+    delays with legitimate mail, such as a mailing list that contains a few no-
+    longer-active user names that didn't bother to unsubscribe. No mail should
+    be lost, as long as this measure is used only temporarily.
+
+  * Use an smtpd_junk_command_limit of 1 instead of the default 100. This
+    prevents clients from keeping idle connections open by repeatedly sending
+    NOOP or RSET commands.
+
+    1  /etc/postfix/main.cf:
+    2      smtpd_timeout = 10
+    3      smtpd_hard_error_limit = 1
+    4      smtpd_junk_command_limit = 1
+
+With these measures, no mail should be lost, as long as these measures are used
+only temporarily. The next section of this document introduces a way to
+automate this process.
+
+DDeetteeccttiinngg ssuuppppoorrtt ffoorr ssttrreessss--aaddaappttiivvee bbeehhaavviioorr
+
+To find out if your Postfix installation supports stress-adaptive behavior, use
+the "ps" command, and look for the smtpd processes. Postfix has stress-adaptive
+support when you see "-o stress=" or "-o stress=yes" command-line options.
+Remember that Postfix never enables stress-adaptive behavior on servers that
+listen on local addresses only.
+
+The following example is for FreeBSD or Linux. On Solaris, HP-UX and other
+System-V flavors, use "ps -ef" instead of "ps ax".
+
+    $ ps ax|grep smtpd
+    83326  ??  S      0:00.28 smtpd -n smtp -t inet -u -c -o stress=
+    84345  ??  Ss     0:00.11 /usr/bin/perl /usr/libexec/postfix/smtpd-
+    policy.pl
+
+You can't use postconf(1) to detect stress-adaptive support. The postconf(1)
+command ignores the existence of the stress parameter in main.cf, because the
+parameter has no effect there. Command-line "-o parameter" settings always take
+precedence over main.cf parameter settings.
+
+If you configure stress-adaptive behavior in main.cf when it isn't supported,
+nothing bad will happen. The processes will run as if the stress parameter
+always has an empty value.
+
+FFoorrcciinngg ssttrreessss--aaddaappttiivvee bbeehhaavviioorr oonn oorr ooffff
+
+You can manually force stress-adaptive behavior on, by adding a "-o stress=yes"
+command-line option in master.cf. This can be useful for testing overrides on
+the SMTP service. Issue "postfix reload" to make the change effective.
+
+Note: setting the stress parameter in main.cf has no effect for services that
+accept remote connections.
+
+    1 /etc/postfix/master.cf:
+    2     # =============================================================
+    3     # service type  private unpriv  chroot  wakeup  maxproc command
+    4     # =============================================================
+    5     #
+    6     smtp      inet  n       -       n       -       -       smtpd
+    7         -o stress=yes
+    8         -o . . .
+
+To permanently force stress-adaptive behavior off with a specific service,
+specify "-o stress=" on its master.cf command line. This may be desirable for
+the "submission" service. Issue "postfix reload" to make the change effective.
+
+Note: setting the stress parameter in main.cf has no effect for services that
+accept remote connections.
+
+    1 /etc/postfix/master.cf:
+    2     # =============================================================
+    3     # service type  private unpriv  chroot  wakeup  maxproc command
+    4     # =============================================================
+    5     #
+    6     submission inet n       -       n       -       -       smtpd
+    7         -o stress=
+    8         -o . . .
+
+OOtthheerr mmeeaassuurreess ttoo ooffff--llooaadd zzoommbbiieess
+
+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 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.
+
+CCrreeddiittss
+
+  * Thanks to the postfix-users mailing list members for sharing early
+    experiences with the stress-adaptive feature.
+  * The RBL example and several other paragraphs of text were adapted from
+    postfix-users postings by Noel Jones.
+  * Wietse implemented stress-adaptive behavior as the smallest possible patch
+    while he should be working on other things.
+
--- a/README_FILES/TLSRPT_README
+++ b/README_FILES/TLSRPT_README
@ -0,0 +1,334 @@
+PPoossttffiixx TTLLSSRRPPTT HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+TTaabbllee ooff CCoonntteennttss
+
+  * Introduction
+  * Building Postfix with TLSRPT support
+  * Turning on TLSRPT
+  * 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 Postfix TLS handshake success and failure 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 or 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.
+
+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)
+
+  * By default, Postfix does not report the TLSRPT status for a TLS handshake
+    that reuses a previously-negotiated TLS session (there would be no new
+    information to report). Specify "smtp_tlsrpt_skip_reused_handshakes = no"
+    to report the TLSRPT status for all TLS handshakes. This may be useful for
+    troubleshooting.
+
+  * 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 though 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.
+
--- a/README_FILES/TLS_LEGACY_README
+++ b/README_FILES/TLS_LEGACY_README
--- a/README_FILES/TLS_README
+++ b/README_FILES/TLS_README
--- a/README_FILES/TUNING_README
+++ b/README_FILES/TUNING_README
@ -0,0 +1,494 @@
+ PPoossttffiixx PPeerrffoorrmmaannccee TTuunniinngg
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff PPoossttffiixx ppeerrffoorrmmaannccee ttuunniinngg
+
+The hints and tips in this document help you improve the performance of Postfix
+systems that already work. If your Postfix system is unable to receive or
+deliver mail, then you need to solve those problems first, using the
+DEBUG_README document as guidance.
+
+For tuning external content filter performance, first read the respective
+information in the FILTER_README and SMTPD_PROXY_README documents. Then make
+sure to avoid latency in the content filter code. As much as possible avoid
+performing queries against external data sources with a high or highly variable
+delay. Your content filter will run with a small concurrency to avoid CPU/
+memory starvation, and if any latency creeps in, content filter throughput will
+suffer. High volume environments should avoid RBL lookups, complex database
+queries and so on.
+
+Topics on mail receiving performance:
+
+  * General mail receiving performance tips
+  * Doing more work with your SMTP server processes
+  * Slowing down SMTP clients that make many errors
+  * Measures against clients that make too many connections
+
+Topics on mail delivery performance:
+
+  * General mail delivery performance tips
+  * Tuning the frequency of deferred mail delivery attempts
+  * Tuning the number of simultaneous deliveries
+  * Tuning the number of recipients per delivery
+
+Other Postfix performance tuning topics:
+
+  * Tuning the number of Postfix processes
+  * Tuning the number of processes on the system
+  * Tuning the number of open files or sockets
+
+The following tools can be used to measure mail system performance under
+artificial loads. They are normally not installed with Postfix.
+
+  * smtp-source, SMTP/LMTP message generator
+  * smtp-sink, SMTP/LMTP message dump
+  * qmqp-source, QMQP message generator
+  * qmqp-sink, QMQP message dump
+
+GGeenneerraall mmaaiill rreecceeiivviinngg ppeerrffoorrmmaannccee ttiippss
+
+  * Read and understand the maildrop queue, incoming queue, and active queue
+    discussions in the QSHAPE_README document.
+
+  * Run a local name server to reduce slow-down due to DNS lookups. If you run
+    multiple Postfix systems, point each local name server to a shared
+    forwarding server to reduce the number of lookups across the upstream
+    network link.
+
+  * Eliminate unnecessary LDAP lookups, by specifying a domain filter. This
+    eliminates lookups for addresses in remote domains, and eliminates lookups
+    of partial addresses. See ldap_table(5) for details.
+
+When Postfix responds slowly to SMTP clients:
+
+  * Look for obvious signs of trouble as described in the DEBUG_README
+    document, and eliminate those problems first.
+
+  * Turn off your header_checks and body_checks patterns and see if the problem
+    goes away.
+
+  * Turn off chroot operation as described in the DEBUG_README document and see
+    if the problem goes away.
+
+  * If Postfix logs the SMTP client as "unknown" then you have a name service
+    problem: the name server is bad, or the resolv.conf file contains bad
+    information, or some packet filter is blocking the DNS requests or replies.
+
+  * If the number of smtpd(8) processes has reached the process limit as
+    specified in master.cf, new SMTP clients must wait until a process becomes
+    available. See the STRESS_README and POSTSCREEN_README documents for
+    measures that help to prevent SMTP server overload.
+
+DDooiinngg mmoorree wwoorrkk wwiitthh yyoouurr SSMMTTPP sseerrvveerr pprroocceesssseess
+
+With Postfix versions 2.0 and earlier, the smtpd(8) server pauses before
+reporting an error to an SMTP client. The idea is called tar pitting. However,
+these delays also slow down Postfix. When the smtpd(8) server replies slowly,
+sessions take more time, so that more smtpd(8) server processes are needed to
+handle the load. When your Postfix smtpd(8) server process limit is reached,
+new clients must wait until a server process becomes available. This means that
+all clients experience poor performance.
+
+You can speed up the handling of smtpd(8) server error replies by turning off
+the delay:
+
+    /etc/postfix/main.cf:
+        # Not needed with Postfix 2.1
+        smtpd_error_sleep_time = 0
+
+With the above setting, Postfix 2.0 and earlier can serve more SMTP clients
+with the same number SMTP server processes. The next section describes how
+Postfix deals with clients that make a large number of errors.
+
+SSlloowwiinngg ddoowwnn SSMMTTPP cclliieennttss tthhaatt mmaakkee mmaannyy eerrrroorrss
+
+The Postfix smtpd(8) server maintains a per-session error count. The error
+count is reset when a message is transferred successfully, and is incremented
+when a client request is unrecognized or unimplemented, when a client request
+violates access restrictions, or when some other error happens.
+
+As the per-session error count increases, the smtpd(8) server changes behavior
+and begins to insert delays into the responses. The idea is to slow down a run-
+away client in order to limit resource usage. The behavior is Postfix version
+dependent.
+
+IMPORTANT: These delays slow down Postfix, too. When too much delay is
+configured, the number of simultaneous SMTP sessions will increase until it
+reaches the smtpd(8) server process limit, and new SMTP clients must wait until
+an smtpd(8) server process becomes available.
+
+Postfix version 2.1 and later:
+
+  * When the error count reaches $smtpd_soft_error_limit (default: 10), the
+    Postfix smtpd(8) server delays all non-error and error responses by
+    $smtpd_error_sleep_time seconds (default: 1 second).
+
+  * When the error count reaches $smtpd_hard_error_limit (default: 20) the
+    Postfix smtpd(8) server breaks the connection.
+
+Postfix version 2.0 and earlier:
+
+  * When the error count is less than $smtpd_soft_error_limit (default: 10) the
+    Postfix smtpd(8) server delays all error replies by $smtpd_error_sleep_time
+    (1 second with Postfix 2.0, 5 seconds with Postfix 1.1 and earlier).
+
+  * When the error count reaches $smtpd_soft_error_limit, the Postfix smtpd(8)
+    server delays all responses by "error count" seconds or
+    $smtpd_error_sleep_time, whichever is more.
+
+  * When the error count reaches $smtpd_hard_error_limit (default: 20) the
+    Postfix smtpd(8) server breaks the connection.
+
+MMeeaassuurreess aaggaaiinnsstt cclliieennttss tthhaatt mmaakkee ttoooo mmaannyy ccoonnnneeccttiioonnss
+
+Note: these features use the Postfix anvil(8) service, introduced with Postfix
+version 2.2.
+
+The Postfix smtpd(8) server can limit the number of simultaneous connections
+from the same SMTP client, as well as the connection rate and the rate of
+certain SMTP commands from the same client. These statistics are maintained by
+the anvil(8) server (translation: if anvil(8) breaks, then connection limits
+stop working).
+
+IMPORTANT: These limits must not be used to regulate legitimate traffic: mail
+will suffer grotesque delays if you do so. The limits are designed to protect
+the smtpd(8) server against abuse by out-of-control clients.
+
+    smtpd_client_connection_count_limit (default: 50)
+        The maximum number of connections that an SMTP client may make
+        simultaneously.
+    smtpd_client_connection_rate_limit (default: no limit)
+        The maximum number of connections that an SMTP client may make in the
+        time interval specified with anvil_rate_time_unit (default: 60s).
+    smtpd_client_message_rate_limit (default: no limit)
+        The maximum number of message delivery requests that an SMTP client may
+        make in the time interval specified with anvil_rate_time_unit (default:
+        60s).
+    smtpd_client_recipient_rate_limit (default: no limit)
+        The maximum number of recipient addresses that an SMTP client may
+        specify in the time interval specified with anvil_rate_time_unit
+        (default: 60s).
+    smtpd_client_new_tls_session_rate_limit (default: no limit)
+        The maximum number of new TLS sessions (without using the TLS session
+        cache) that an SMTP client may negotiate in the time interval specified
+        with anvil_rate_time_unit (default: 60s).
+    smtpd_client_auth_rate_limit (default: no limit)
+        The maximum number of AUTH commands that an SMTP client may send in the
+        time interval specified with anvil_rate_time_unit (default: 60s).
+        Available in Postfix 3.1 and later.
+    smtpd_client_event_limit_exceptions (default: $mynetworks)
+        SMTP clients that are excluded from connection and rate limits
+        specified above.
+
+GGeenneerraall mmaaiill ddeelliivveerryy ppeerrffoorrmmaannccee ttiippss
+
+  * Read and understand the maildrop queue, incoming queue, active queue and
+    deferred queue discussions in the QSHAPE_README document.
+
+  * In case of slow delivery, run the qshape tool as described in the
+    QSHAPE_README document.
+
+  * Submit multiple recipients per message instead of submitting messages with
+    only a few recipients.
+
+  * Submit mail via SMTP instead of /usr/sbin/sendmail. You may have to adjust
+    the smtpd_recipient_limit parameter setting.
+
+  * Don't overwhelm the disk with mail submissions. Optimize the mail
+    submission rate by tuning the number of parallel submissions and/or by
+    tuning the Postfix in_flow_delay parameter setting.
+
+  * Run a local name server to reduce slow-down due to DNS lookups. If you run
+    multiple Postfix systems, point each local name server to a shared
+    forwarding server to reduce the number of lookups across the upstream
+    network link.
+
+  * Reduce the smtp_connect_timeout and smtp_helo_timeout values so that
+    Postfix does not waste lots of time connecting to non-responding remote
+    SMTP servers.
+
+  * Use a dedicated mail delivery transport for problematic destinations, with
+    reduced timeouts and with adjusted concurrency. See "Tuning the number of
+    simultaneous deliveries" below.
+
+  * Use a fallback_relay host for mail that cannot be delivered upon the first
+    attempt. This "graveyard" machine can use shorter retry times for difficult
+    to reach destinations. See "Tuning the frequency of deferred mail delivery
+    attempts" below.
+
+  * Speed up disk updates with a large (64MB) persistent write cache. This
+    allows disk updates to be sorted for optimal access speed without
+    compromising file system integrity when the system crashes.
+
+  * Use a solid-state disk (a persistent RAM disk). This is an expensive
+    solution that should be used in combination with short SMTP timeouts and a
+    fallback_relay "graveyard" machine that delivers mail for problem
+    destinations.
+
+TTuunniinngg tthhee nnuummbbeerr ooff ssiimmuullttaanneeoouuss ddeelliivveerriieess
+
+Although Postfix can be configured to run 1000 SMTP client processes at the
+same time, it is rarely desirable that it makes 1000 simultaneous connections
+to the same remote system. For this reason, Postfix has safety mechanisms in
+place to avoid this so-called "thundering herd" problem.
+
+The Postfix queue manager implements the analog of the TCP slow start flow
+control strategy: when delivering to a site, send a small number of messages
+first, then increase the concurrency as long as all goes well; reduce
+concurrency in the face of congestion.
+
+  * The initial_destination_concurrency parameter (default: 5) controls how
+    many messages are initially sent to the same destination before adapting
+    delivery concurrency. Of course, this setting is effective only as long as
+    it does not exceed the process limit and the destination concurrency limit
+    for the specific mail transport channel.
+
+  * The default_destination_concurrency_limit parameter (default: 20) controls
+    how many messages may be sent to the same destination simultaneously. You
+    can override this setting for specific message delivery transports by
+    taking the name of the master.cf entry and appending
+    "_destination_concurrency_limit".
+
+Examples of transport specific concurrency limits are:
+
+  * The local_destination_concurrency_limit parameter (default: 2) controls how
+    many messages are delivered simultaneously to the same local recipient. The
+    recommended limit is low because delivery to the same mailbox must happen
+    sequentially, so massive parallelism is not useful. Another good reason to
+    limit delivery concurrency to the same recipient: if the recipient has an
+    expensive shell command in her .forward file, or if the recipient is a
+    mailing list manager, you don't want to run too many instances of those
+    processes at the same time.
+
+  * The default smtp_destination_concurrency_limit of 20 seems enough to
+    noticeably load a system without bringing it to its knees. Be careful when
+    changing this to a much larger number.
+
+The above default values of the concurrency limits work well in a broad range
+of situations. Knee-jerk changes to these parameters in the face of congestion
+can actually make problems worse. Specifically, large destination concurrencies
+should never be the default. They should be used only for transports that
+deliver mail to a small number of high volume domains.
+
+A common situation where high concurrency is called for is on gateways relaying
+a high volume of mail between the Internet and an intranet mail environment.
+Approximately half the mail (assuming equal volumes inbound and outbound) will
+be destined for the internal mail hubs. Since the internal mail hubs will be
+receiving all external mail exclusively from the gateway, it is reasonable to
+configure the gateway to make greater demands on the capacity of the internal
+SMTP servers.
+
+The tuning of the inbound concurrency limits need not be trial and error. A
+high volume capable mailhub should be able to easily handle 50 or 100 (rather
+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_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
+default SMTP connection timeout is 30s, the throughput limit is 100 * 2 / 30 ~=
+6 messages per second. This suggests that high volume destinations with good
+connectivity and multiple MX hosts need a lower connection timeout, values as
+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_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
+
+The default_destination_recipient_limit parameter (default: 50) controls how
+many recipients a Postfix delivery agent will send with each copy of an email
+message. You can override this setting for specific Postfix delivery agents.
+For example, "uucp_destination_recipient_limit = 100" would limit the number of
+recipients per UUCP delivery to 100.
+
+If an email message exceeds the recipient limit for some destination, the
+Postfix queue manager breaks up the list of recipients into smaller lists.
+Postfix will attempt to send multiple copies of the message in parallel.
+
+IMPORTANT: Be careful when increasing the recipient limit per message delivery;
+some SMTP servers abort the connection when they run out of memory or when a
+hard recipient limit is reached, so that the message will never be delivered.
+
+The smtpd_recipient_limit parameter (default: 1000) controls how many
+recipients the Postfix smtpd(8) server will take per delivery. The default
+limit is more than any reasonable SMTP client would send. The limit exists to
+protect the local mail system against a run-away client.
+
+TTuunniinngg tthhee ffrreeqquueennccyy ooff ddeeffeerrrreedd mmaaiill ddeelliivveerryy aatttteemmppttss
+
+When a Postfix delivery agent (smtp(8), local(8), etc.) is unable to deliver a
+message it may blame the message itself, or it may blame the receiving party.
+
+  * When the delivery agent blames the message, the queue manager gives the
+    queue file a time stamp into the future, so it won't be looked at for a
+    while. By default, the amount of time to cool down is the amount of time
+    that has passed since the message arrived. This results in so-called
+    exponential backoff behavior.
+
+  * When the delivery agent blames the receiving party (for example a local
+    recipient user, or a remote host), the queue manager not only advances the
+    queue file time stamp, but also puts the receiving party on a "dead" list
+    so that it will be skipped for some amount of time.
+
+This process is governed by a bunch of little parameters.
+
+    queue_run_delay (default: 300 seconds; before Postfix 2.4: 1000s)
+        How often the queue manager scans the queue for deferred mail.
+    minimal_backoff_time (default: 300 seconds; before Postfix 2.4: 1000s)
+        The minimal amount of time a message won't be looked at, and the
+        minimal amount of time to stay away from a "dead" destination.
+    maximal_backoff_time (default: 4000 seconds)
+        The maximal amount of time a message won't be looked at after a
+        delivery failure.
+    maximal_queue_lifetime (default: 5 days)
+        How long a message stays in the queue before it is sent back as
+        undeliverable. Specify 0 for mail that should be returned immediately
+        after the first unsuccessful delivery attempt.
+    bounce_queue_lifetime (default: 5 days, available with Postfix version 2.1
+    and later)
+        How long a MAILER-DAEMON message stays in the queue before it is
+        considered undeliverable. Specify 0 for mail that should be tried only
+        once.
+    qmgr_message_recipient_limit (default: 20000)
+        The size of many in-memory queue manager data structures. Among others,
+        this parameter limits the size of the short-term, in-memory list of
+        "dead" destinations. Destinations that don't fit the list are not
+        added.
+    transport_destination_concurrency_failed_cohort_limit
+        Controls when a destination is considered "dead". This parameter is
+        critical with a non-zero transport_destination_rate_delay, with a
+        reduced transport_destination_concurrency_limit, or with a reduced
+        initial_destination_concurrency.
+
+IMPORTANT: If you increase the frequency of deferred mail delivery attempts, or
+if you flush the deferred mail queue frequently, then you may find that Postfix
+mail delivery performance actually becomes worse. The symptoms are as follows:
+
+  * The active queue becomes saturated with mail that has delivery problems.
+    New mail enters the active queue only when an old message is deferred. This
+    is a slow process that usually requires timing out one or more SMTP
+    connections.
+
+  * All available Postfix delivery agents become occupied trying to connect to
+    unreachable sites etc. New mail has to wait until a delivery agent becomes
+    available. This is a slow process that usually requires timing out one or
+    more SMTP connections.
+
+When mail is being deferred frequently, fixing the problem is always better
+than increasing the frequency of delivery attempts. However, if you can control
+only the delivery attempt frequency, consider using a dedicated fallback_relay
+"graveyard" machine for bad destinations, so that these destinations do not
+ruin the performance of normal mail deliveries.
+
+TTuunniinngg tthhee nnuummbbeerr ooff PPoossttffiixx pprroocceesssseess
+
+The default_process_limit configuration parameter gives direct control over how
+many daemon processes Postfix will run. As of Postfix 2.0 the default limit is
+100 SMTP client processes, 100 SMTP server processes, and so on. This may
+overwhelm systems with little memory, as well as networks with low bandwidth.
+
+You can change the global process limit by specifying a non-default
+default_process_limit in the main.cf file. For example, to run up to 10 SMTP
+client processes, 10 SMTP server processes, and so on:
+
+    /etc/postfix/main.cf:
+        default_process_limit = 10
+
+You need to execute "postfix reload" to make the change effective. This limit
+is enforced by the Postfix master(8) daemon which does not automatically read
+main.cf when it changes.
+
+You can override the process limit for specific Postfix daemons by editing the
+master.cf file. For example, if you do not wish to receive 100 SMTP messages at
+the same time, but do not want to change the process limits for other Postfix
+daemons, you could specify:
+
+    /etc/postfix/master.cf:
+        # ====================================================================
+        # service type  private unpriv  chroot  wakeup  maxproc command + args
+        #               (yes)   (yes)   (yes)   (never) (100)
+        # ====================================================================
+        . . .
+        smtp      inet  n       -       -       -       10      smtpd
+        . . .
+
+TTuunniinngg tthhee nnuummbbeerr ooff pprroocceesssseess oonn tthhee ssyysstteemm
+
+  * MacOS X will run out of process slots when you increase Postfix process
+    limits. The following works with OSX 10.4 and OSX 10.5.
+
+    MacOS X kernel parameters can be specified in /etc/sysctl.conf.
+
+    /etc/sysctl.conf:
+        kern.maxproc=2048
+        kern.maxprocperuid=2048
+
+    Unfortunately these can't simply be set on the fly with "sysctl -w". You
+    also have to set the following in /etc/launchd.conf so that the root user
+    after boot will have the right process limit (2048). Otherwise you have to
+    always run ulimit -u 2048 as root, then start a user shell, and then start
+    processes for things to take effect.
+
+    /etc/launchd.conf:
+        limit maxproc 2048
+
+    Once these are in place, reboot the system. After that, the limits will
+    stay in place.
+
+TTuunniinngg tthhee nnuummbbeerr ooff ooppeenn ffiilleess oorr ssoocckkeettss
+
+When Postfix opens too many files or sockets, processes will abort with fatal
+errors, and the system may log "file table full" errors.
+
+  * Depending on your Postfix and operating system versions you may need to
+    recompile Postfix if you need more than 1024 file descriptors per process:
+
+      o No recompilation is needed for Postfix version 2.4 and later, when it
+        was compiled for systems that support BSD kqueue(2) (FreeBSD 4.1,
+        NetBSD 2.0, OpenBSD 2.9), Solaris 8 /dev/poll, or Linux 2.6 epoll(4).
+
+      o Otherwise, Postfix needs to be recompiled to override the default
+        FD_SETSIZE value.
+
+  * Reduce the number of processes as described under "Tuning the number of
+    Postfix processes" above. Fewer processes need fewer open files and
+    sockets.
+
+  * Configure the kernel for more open files and sockets. The details are
+    extremely system dependent and change with the operating system version. Be
+    sure to verify the following information with your system tuning guide:
+
+      o Some FreeBSD kernel parameters can be specified in /boot/loader.conf,
+        and some can be specified in /etc/sysctl.conf or changed with sysctl
+        commands. Which is which depends on the version.
+
+        kern.ipc.maxsockets="5000"
+        kern.ipc.nmbclusters="65536"
+        kern.maxproc="2048"
+        kern.maxfiles="16384"
+        kern.maxfilesperproc="16384"
+
+      o Linux kernel parameters can be specified in /etc/sysctl.conf or changed
+        with sysctl commands:
+
+        fs.file-max=16384
+        kernel.threads-max=2048
+
+      o Solaris kernel parameters can be specified in /etc/system, as described
+        in the Solaris FAQ entry titled "How can I increase the number of file
+        descriptors per process?"
+
+        * set hard limit on file descriptors
+        set rlim_fd_max = 4096
+        * set soft limit on file descriptors
+        set rlim_fd_cur = 1024
+
--- a/README_FILES/ULTRIX_README
+++ b/README_FILES/ULTRIX_README
@ -0,0 +1,45 @@
+PPoossttffiixx aanndd UUllttrriixx
+
+-------------------------------------------------------------------------------
+
+PPoossttffiixx oonn UUllttrriixx
+
+This document is probably only of historical value, because Ultrix version 4
+dates from the early 1990s. However, as long as Wietse keeps Postfix alive for
+SunOS 4, it is likely to run on Ultrix 4 with very little change. Feedback is
+welcome if anyone actually still uses Postfix on any version of Ultrix.
+
+The source of this document is an email message by Christian von Roques that
+was sent on Jun 2, 1999.
+
+    I've upgraded the MTA of our DECstation-3100 running Ultrix4.3a to postfix-
+    19990317-pl05 and am sending you the patches I needed to get it running
+    under Ultrix.
+
+    . . .
+
+    One of the bugs of Ultrix's /bin/sh is that shell-variables set in
+    arguments of `:' expand to garbage if expanded in here-documents. Using a
+    different shell helps. I needed to replace all calls of ``sh .../makedefs''
+    by ``$(SHELL) .../makedefs'' in all the Makefile.in and am now able to use
+    ``make SHELL=/bin/sh5'' or zsh.
+
+    . . .
+
+    Ultrix's FD_SET_SIZE is 4096, but getdtablesize() returns 64 by default, if
+    not increased when building a new kernel. getrlimit() doesn't know
+    RLIMIT_NOFILE. This makes event_init() always log the warning: `could
+    allocate space for only 64 open files'.
+
+    I just reduced the threshold from 256 to 64, but this is not good. The
+    initial problem still remains: How to disable this warning on Ultrix
+    without making the source ugly?
+
+To work around the first problem, all the Makefile.in files have been updated
+to use `$(SHELL)' instead of `sh'. So you only need to supply a non-default
+shell in order to eliminate Ultrix shell trouble.
+
+To work around the latter, util/sys_defs.h was updated for Ultrix, with a
+default FD_SETSIZE of 100. This should be sufficient for a workstation. Even in
+1999, no-one would run a major mail hub on Ultrix 4.
+
--- a/README_FILES/UUCP_README
+++ b/README_FILES/UUCP_README
@ -0,0 +1,121 @@
+PPoossttffiixx aanndd UUUUCCPP
+
+-------------------------------------------------------------------------------
+
+UUssiinngg UUUUCCPP oovveerr TTCCPP
+
+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 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/.
+
+Here's a graphical description of what this document is about:
+
+                        LAN to                 Internet
+    Local network <--->  UUCP   <--- UUCP ---> to UUCP  <---> Internet
+                        Gateway                Gateway
+
+And here's the table of contents of this document:
+
+  * Setting up a Postfix Internet to UUCP gateway
+  * Setting up a Postfix LAN to UUCP gateway
+
+SSeettttiinngg uupp aa PPoossttffiixx IInntteerrnneett ttoo UUUUCCPP ggaatteewwaayy
+
+Here is how to set up a machine that sits on the Internet and that forwards
+mail to a LAN that is connected via UUCP. See the LAN to UUCP gateway section
+for the other side of the story.
+
+  * You need an rrmmaaiill program that extracts the sender address from mail that
+    arrives via UUCP, and that feeds the mail into the Postfix sseennddmmaaiill
+    command. Most UNIX systems come with an rrmmaaiill utility. If you're in a
+    pinch, try the one bundled with the Postfix source code in the aauuxxiilliiaarryy//
+    rrmmaaiill directory.
+
+  * Define a pipe(8) based mail delivery transport for delivery via UUCP:
+
+    /etc/postfix/master.cf:
+        uucp      unix  -       n       n       -       -       pipe
+          flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
+    ($recipient)
+
+    This runs the uuuuxx command to place outgoing mail into the UUCP queue after
+    replacing $nexthop by the next-hop hostname (the receiving UUCP host) and
+    after replacing $recipient by the recipients. The pipe(8) delivery agent
+    executes the uuuuxx command without assistance from the shell, so there are no
+    problems with shell meta characters in command-line parameters.
+
+  * Specify that mail for example.com, should be delivered via UUCP, to a host
+    named uucp-host:
+
+    /etc/postfix/transport:
+        example.com     uucp:uucp-host
+        .example.com    uucp:uucp-host
+
+    See the transport(5) manual page for more details.
+
+  * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you change
+    the ttrraannssppoorrtt file.
+
+  * Enable ttrraannssppoorrtt table lookups:
+
+    /etc/postfix/main.cf:
+        transport_maps = hash:/etc/postfix/transport
+
+    Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
+    files. To find out what map types Postfix supports, use the command
+    "ppoossttccoonnff --mm".
+
+  * Add example.com to the list of domains that your site is willing to relay
+    mail for.
+
+    /etc/postfix/main.cf:
+        relay_domains = example.com ...other relay domains...
+
+    See the relay_domains configuration parameter description for details.
+
+  * Execute the command "ppoossttffiixx rreellooaadd" to make the changes effective.
+
+SSeettttiinngg uupp aa PPoossttffiixx LLAANN ttoo UUUUCCPP ggaatteewwaayy
+
+Here is how to relay mail from a LAN via UUCP to the Internet. See the Internet
+to UUCP gateway section for the other side of the story.
+
+  * You need an rrmmaaiill program that extracts the sender address from mail that
+    arrives via UUCP, and that feeds the mail into the Postfix sseennddmmaaiill
+    command. Most UNIX systems come with an rrmmaaiill utility. If you're in a
+    pinch, try the one bundled with the Postfix source code in the aauuxxiilliiaarryy//
+    rrmmaaiill directory.
+
+  * Specify that all remote mail must be sent via the uuuuccpp mail transport to
+    your UUCP gateway host, say, uucp-gateway:
+
+    /etc/postfix/main.cf:
+        relayhost = uucp-gateway
+        default_transport = uucp
+
+    Postfix 2.0 and later also allows the following more succinct form:
+
+    /etc/postfix/main.cf:
+        default_transport = uucp:uucp-gateway
+
+  * Define a pipe(8) based message delivery transport for mail delivery via
+    UUCP:
+
+    /etc/postfix/master.cf:
+        uucp      unix  -       n       n       -       -       pipe
+          flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
+    ($recipient)
+
+    This runs the uuuuxx command to place outgoing mail into the UUCP queue. It
+    substitutes the next-hop hostname (uucp-gateway, or whatever you specified)
+    and the recipients before executing the command. The uuuuxx command is
+    executed without assistance from the shell, so there are no problems with
+    shell meta characters.
+
+  * Execute the command "ppoossttffiixx rreellooaadd" to make the changes effective.
+
--- a/README_FILES/VERP_README
+++ b/README_FILES/VERP_README
@ -0,0 +1,186 @@
+PPoossttffiixx VVEERRPP HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPoossttffiixx VVEERRPP ssuuppppoorrtt
+
+Postfix versions 1.1 and later support variable envelope return path addresses
+on request. When VERP style delivery is requested, each recipient of a message
+receives a customized copy of the message, with his/her own recipient address
+encoded in the envelope sender address.
+
+For example, when VERP style delivery is requested, Postfix delivers mail from
+"owner-listname@origin" for a recipient "user@domain", with a sender address
+that encodes the recipient as follows:
+
+    owner-listname+user=domain@origin
+
+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 https://cr.yp.to/proto/verp.txt for the ideas behind this concept.
+
+Topics covered in this document:
+
+  * Postfix VERP configuration parameters
+  * Using VERP with majordomo etc. mailing lists
+  * VERP support in the Postfix SMTP server
+  * VERP support in the Postfix sendmail command
+  * VERP support in the Postfix QMQP server
+
+PPoossttffiixx VVEERRPP ccoonnffiigguurraattiioonn ppaarraammeetteerrss
+
+With Postfix, the whole process is controlled by four configuration parameters.
+
+default_verp_delimiters (default value: +=)
+    What VERP delimiter characters Postfix uses when VERP style delivery is
+    requested but no explicit delimiters are specified.
+
+verp_delimiter_filter (default: -+=)
+    What characters Postfix accepts as VERP delimiter characters on the
+    sendmail command line and in SMTP commands. Many characters must not be
+    used as VERP delimiter characters, either because they already have a
+    special meaning in email addresses (such as the @ or the %), because they
+    are used as part of a username or domain name (such as alphanumerics), or
+    because they are non-ASCII or control characters. And who knows, some
+    characters may tickle bugs in vulnerable software, and we would not want
+    that to happen.
+
+smtpd_authorized_verp_clients (default value: none)
+    What SMTP clients are allowed to request VERP style delivery. The Postfix
+    QMQP server uses its own access control mechanism, and local submission
+    (via /usr/sbin/sendmail etc.) is always authorized. To authorize a host,
+    list its name, IP address, subnet (net/mask) or parent .domain.
+
+    With Postfix versions 1.1 and 2.0, this parameter is called
+    authorized_verp_clients (default: $mynetworks).
+
+disable_verp_bounces (default: no)
+    Send one bounce report for multi-recipient VERP mail, instead of one bounce
+    report per recipient. The default, one per recipient, is what ezmlm needs.
+
+UUssiinngg VVEERRPP wwiitthh mmaajjoorrddoommoo eettcc.. mmaaiilliinngg lliissttss
+
+In order to make VERP useful with majordomo etc. mailing lists, you would
+configure the list manager to submit mail according to one of the following two
+forms:
+
+Postfix 2.3 and later:
+
+    % sendmail -XV -f owner-listname other-arguments...
+
+    % sendmail -XV+= -f owner-listname other-arguments...
+
+Postfix 2.2 and earlier (Postfix 2.3 understands the old syntax for backwards
+compatibility, but will log a warning that reminds you of the new syntax):
+
+    % sendmail -V -f owner-listname other-arguments...
+
+    % sendmail -V+= -f owner-listname other-arguments...
+
+The first form uses the default main.cf VERP delimiter characters. The second
+form allows you to explicitly specify the VERP delimiter characters. The
+example shows the recommended values.
+
+This text assumes that you have set up an owner-listname alias that routes
+undeliverable mail to a real person:
+
+    /etc/aliases:
+        owner-listname: yourname+listname
+
+In order to process bounces we are going to make extensive use of address
+extension tricks.
+
+You need to tell Postfix that + is the separator between an address and its
+optional address extension, that address extensions are appended to .forward
+file names, and that address extensions are to be discarded when doing alias
+expansions:
+
+    /etc/postfix/main.cf:
+        recipient_delimiter = +
+        forward_path = $home/.forward${recipient_delimiter}${extension},
+            $home/.forward
+        propagate_unmatched_extensions = canonical, virtual
+
+(the last two parameter settings are default settings).
+
+You need to set up a file named .forward+listname with the commands that
+process all the mail that is sent to the owner-listname address:
+
+    ~/.forward+listname:
+        "|/some/where/command ..."
+
+With this set up, undeliverable mail for user@domain will be returned to the
+following address:
+
+    owner-listname+user=domain@your.domain
+
+which is processed by the command in your .forward+listname file. The message
+should contain, among others, a To: header with the encapsulated recipient
+sender address:
+
+    To: owner-listname+user=domain@your.domain
+
+It is left as an exercise for the reader to parse the To: header line and to
+pull out the user=domain part from the recipient address.
+
+VVEERRPP ssuuppppoorrtt iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr
+
+The Postfix SMTP server implements a command XVERP to enable VERP style
+delivery. The syntax allows two forms:
+
+    MAIL FROM:<sender@domain> XVERP
+
+    MAIL FROM:<sender@domain> XVERP=+=
+
+The first form uses the default main.cf VERP delimiters, the second form
+overrides them explicitly. The values shown are the recommended ones.
+
+You can use the smtpd_command_filter feature to append XVERP to SMTP commands
+from legacy software. This requires Postfix 2.7 or later.
+
+    /etc/postfix/main.cf:
+        smtpd_command_filter = pcre:/etc/postfix/append_verp.pcre
+        smtpd_authorized_verp_clients = $mynetworks
+
+    /etc/postfix/append_verp.pcre:
+        /^(MAIL FROM:<listname@example\.com>.*)/ $1 XVERP
+
+VVEERRPP ssuuppppoorrtt iinn tthhee PPoossttffiixx sseennddmmaaiill ccoommmmaanndd
+
+The Postfix sendmail command has a -V flag to request VERP style delivery.
+Specify one of the following two forms:
+
+Postfix 2.3 and later:
+
+    % sendmail -XV -f owner-listname ....
+
+    % sendmail -XV+= -f owner-listname ....
+
+Postfix 2.2 and earlier (Postfix 2.3 understands the old syntax for backwards
+compatibility, but will log a warning that reminds you of the new syntax):
+
+    % sendmail -V -f owner-listname ....
+
+    % sendmail -V+= -f owner-listname ....
+
+The first form uses the default main.cf VERP delimiters, the second form
+overrides them explicitly. The values shown are the recommended ones.
+
+VVEERRPP ssuuppppoorrtt iinn tthhee PPoossttffiixx QQMMQQPP sseerrvveerr
+
+When the Postfix QMQP server receives mail with an envelope sender address of
+the form:
+
+    listname-@your.domain-@[]
+
+Postfix generates sender addresses "listname-user=domain@your.domain", using "-
+=" as the VERP delimiters because qmail/ezmlm expect this.
+
+More generally, a sender address of "prefix@origin-@[]" requests VERP style
+delivery with sender addresses of the form "prefixuser=domain@origin". However,
+Postfix allows only VERP delimiters that are specified with the
+verp_delimiter_filter parameter. In particular, the "=" delimiter is required
+for qmail compatibility (see the qmail addresses(5) manual page for details).
+
--- a/README_FILES/VIRTUAL_README
+++ b/README_FILES/VIRTUAL_README
@ -0,0 +1,483 @@
+PPoossttffiixx VViirrttuuaall DDoommaaiinn HHoossttiinngg HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document requires Postfix version 2.0 or later.
+
+This document gives an overview of how Postfix can be used for hosting multiple
+Internet domains, both for final delivery on the machine itself and for the
+purpose of forwarding to destinations elsewhere.
+
+The text not only describes delivery mechanisms that are built into Postfix,
+but also gives pointers for using non-Postfix mail delivery software.
+
+The following topics are covered:
+
+  * Canonical versus hosted versus other domains
+  * Local files versus network databases
+  * As simple as can be: shared domains, UNIX system accounts
+  * Postfix virtual ALIAS example: separate domains, UNIX system accounts
+  * Postfix virtual MAILBOX example: separate domains, non-UNIX accounts
+  * Non-Postfix mailbox store: separate domains, non-UNIX accounts
+  * Mail forwarding domains
+  * Mailing lists
+  * Autoreplies
+
+CCaannoonniiccaall vveerrssuuss hhoosstteedd vveerrssuuss ootthheerr ddoommaaiinnss
+
+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 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
+address class and/or with the virtual mailbox domain address class, as defined
+in the ADDRESS_CLASS_README file.
+
+But wait! There is more. Postfix can be configured as a backup MX host for
+other domains. In this case Postfix is nnoott tthhee ffiinnaall ddeessttiinnaattiioonn for those
+domains. It merely queues the mail when the primary MX host is down, and
+forwards the mail when the primary MX host becomes available. This function is
+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 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.
+
+LLooccaall ffiilleess vveerrssuuss nneettwwoorrkk ddaattaabbaasseess
+
+The examples in this text use table lookups from local files such as DBM or
+Berkeley DB. These are easy to debug with the ppoossttmmaapp command:
+
+    Example: postmap -q info@example.com hash:/etc/postfix/virtual
+
+See the documentation in LDAP_README, MYSQL_README and PGSQL_README for how to
+replace local files by databases. The reader is strongly advised to make the
+system work with local files before migrating to network databases, and to use
+the ppoossttmmaapp command to verify that network database lookups produce the exact
+same results as local file lookup.
+
+    Example: postmap -q info@example.com ldap:/etc/postfix/virtual.cf
+
+AAss ssiimmppllee aass ccaann bbee:: sshhaarreedd ddoommaaiinnss,, UUNNIIXX ssyysstteemm aaccccoouunnttss
+
+The simplest method to host an additional domain is to add the domain name to
+the domains listed in the Postfix mydestination configuration parameter, and to
+add the user names to the UNIX password file.
+
+This approach makes no distinction between canonical and hosted domains. Each
+username can receive mail in every domain.
+
+In the examples we will use "example.com" as the domain that is being hosted on
+the local Postfix machine.
+
+    /etc/postfix/main.cf:
+        mydestination = $myhostname localhost.$mydomain ... example.com
+
+The limitations of this approach are:
+
+  * A total lack of separation: mail for info@my.host.name is delivered to the
+    same UNIX system account as mail for info@example.com.
+  * With users in the UNIX password file, administration of large numbers of
+    users becomes inconvenient.
+
+The examples that follow provide solutions for both limitations.
+
+PPoossttffiixx vviirrttuuaall AALLIIAASS eexxaammppllee:: sseeppaarraattee ddoommaaiinnss,, UUNNIIXX ssyysstteemm aaccccoouunnttss
+
+With the approach described in this section, every hosted domain can have its
+own info etc. email address. However, it still uses UNIX system accounts for
+local mailbox deliveries.
+
+With virtual alias domains, each hosted address is aliased to a local UNIX
+system account or to a remote address. The example below shows how to use this
+mechanism for the example.com domain.
+
+     1 /etc/postfix/main.cf:
+     2     virtual_alias_domains = example.com ...other hosted domains...
+     3     virtual_alias_maps = hash:/etc/postfix/virtual
+     4
+     5 /etc/postfix/virtual:
+     6     postmaster@example.com postmaster
+     7     info@example.com       joe
+     8     sales@example.com      jane
+     9     # Uncomment entry below to implement a catch-all address
+    10     # @example.com         jim
+    11     ...virtual aliases for more domains...
+
+Notes:
+
+  * Line 2: the virtual_alias_domains setting tells Postfix that example.com is
+    a so-called virtual alias domain. If you omit this setting then Postfix
+    will reject mail (relay access denied) or will not be able to deliver it
+    (mail for example.com loops back to myself).
+
+    NEVER list a virtual alias domain name as a mydestination domain!
+
+  * Lines 3-8: the /etc/postfix/virtual file contains the virtual aliases. With
+    the example above, mail for postmaster@example.com goes to the local
+    postmaster, while mail for info@example.com goes to the UNIX account joe,
+    and mail for sales@example.com goes to the UNIX account jane. Mail for all
+    other addresses in example.com is rejected with the error message "User
+    unknown".
+
+  * Line 10: the commented out entry (text after #) shows how one would
+    implement a catch-all virtual alias that receives mail for every
+    example.com address not listed in the virtual alias file. This is not
+    without risk. Spammers nowadays try to send mail from (or mail to) every
+    possible name that they can think of. A catch-all mailbox is likely to
+    receive many spam messages, and many bounces for spam messages that were
+    sent in the name of anything@example.com.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
+file, and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
+
+Note: virtual aliases can resolve to a local address or to a remote address, or
+both. They don't have to resolve to UNIX system accounts on your machine.
+
+More details about the virtual alias file are given in the virtual(5) manual
+page, including multiple addresses on the right-hand side.
+
+Virtual aliasing solves one problem: it allows each domain to have its own info
+mail address. But there still is one drawback: each virtual address is aliased
+to a UNIX system account. As you add more virtual addresses you also add more
+UNIX system accounts. The next section eliminates this problem.
+
+PPoossttffiixx vviirrttuuaall MMAAIILLBBOOXX eexxaammppllee:: sseeppaarraattee ddoommaaiinnss,, nnoonn--UUNNIIXX aaccccoouunnttss
+
+As a system hosts more and more domains and users, it becomes less desirable to
+give every user their own UNIX system account.
+
+With the Postfix virtual(8) mailbox delivery agent, every recipient address can
+have its own virtual mailbox. Unlike virtual alias domains, virtual mailbox
+domains do not need the clumsy translation from each recipient addresses into a
+different address, and owners of a virtual mailbox address do not need to have
+a UNIX system account.
+
+The Postfix virtual(8) mailbox delivery agent looks up the user mailbox
+pathname, uid and gid via separate tables that are searched with the
+recipient's mail address. Maildir style delivery is turned on by terminating
+the mailbox pathname with "/".
+
+If you find the idea of multiple tables bothersome, remember that you can
+migrate the information (once it works), to an SQL database. If you take that
+route, be sure to review the "local files versus databases" section at the top
+of this document.
+
+Here is an example of a virtual mailbox domain "example.com":
+
+     1 /etc/postfix/main.cf:
+     2     virtual_mailbox_domains = example.com ...more domains...
+     3     virtual_mailbox_base = /var/mail/vhosts
+     4     virtual_mailbox_maps = hash:/etc/postfix/vmailbox
+     5     virtual_minimum_uid = 100
+     6     virtual_uid_maps = static:5000
+     7     virtual_gid_maps = static:5000
+     8     virtual_alias_maps = hash:/etc/postfix/virtual
+     9
+    10 /etc/postfix/vmailbox:
+    11     info@example.com    example.com/info
+    12     sales@example.com   example.com/sales/
+    13     # Comment out the entry below to implement a catch-all.
+    14     # @example.com      example.com/catchall
+    15     ...virtual mailboxes for more domains...
+    16
+    17 /etc/postfix/virtual:
+    18     postmaster@example.com postmaster
+
+Notes:
+
+  * Line 2: The virtual_mailbox_domains setting tells Postfix that example.com
+    is a so-called virtual mailbox domain. If you omit this setting then
+    Postfix will reject mail (relay access denied) or will not be able to
+    deliver it (mail for example.com loops back to myself).
+
+    NEVER list a virtual MAILBOX domain name as a mydestination domain!
+
+    NEVER list a virtual MAILBOX domain name as a virtual ALIAS domain!
+
+  * Line 3: The virtual_mailbox_base parameter specifies a prefix for all
+    virtual mailbox pathnames. This is a safety mechanism in case someone makes
+    a mistake. It prevents mail from being delivered all over the file system.
+
+  * Lines 4, 10-15: The virtual_mailbox_maps parameter specifies the lookup
+    table with mailbox (or maildir) pathnames, indexed by the virtual mail
+    address. In this example, mail for info@example.com goes to the mailbox at
+    /var/mail/vhosts/example.com/info while mail for sales@example.com goes to
+    the maildir located at /var/mail/vhosts/example.com/sales/.
+
+  * Line 5: The virtual_minimum_uid specifies a lower bound on the mailbox or
+    maildir owner's UID. This is a safety mechanism in case someone makes a
+    mistake. It prevents mail from being written to sensitive files.
+
+  * Lines 6, 7: The virtual_uid_maps and virtual_gid_maps parameters specify
+    that all the virtual mailboxes are owned by a fixed uid and gid 5000. If
+    this is not what you want, specify lookup tables that are searched by the
+    recipient's mail address.
+
+  * Line 14: The commented out entry (text after #) shows how one would
+    implement a catch-all virtual mailbox address. Be prepared to receive a lot
+    of spam, as well as bounced spam that was sent in the name of
+    anything@example.com.
+
+    NEVER put a virtual MAILBOX wild-card in the virtual ALIAS file!!
+
+  * Lines 8, 17, 18: As you see, it is possible to mix virtual aliases with
+    virtual mailboxes. We use this feature to redirect mail for example.com's
+    postmaster address to the local postmaster. You can use the same mechanism
+    to redirect an address to a remote address.
+
+  * Line 18: This example assumes that in main.cf, $myorigin is listed under
+    the mydestination parameter setting. If that is not the case, specify an
+    explicit domain name on the right-hand side of the virtual alias table
+    entries or else mail will go to the wrong domain.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
+file, execute "ppoossttmmaapp //eettcc//ppoossttffiixx//vvmmaaiillbbooxx" after changing the vmailbox file,
+and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
+
+Note: mail delivery happens with the recipient's UID/GID privileges specified
+with virtual_uid_maps and virtual_gid_maps. Postfix 2.0 and earlier will not
+create mailDIRs in world-writable parent directories; you must create them in
+advance before you can use them. Postfix may be able to create mailBOX files by
+itself, depending on parent directory write permissions, but it is safer to
+create mailBOX files ahead of time.
+
+More details about the virtual mailbox delivery agent are given in the virtual
+(8) manual page.
+
+NNoonn--PPoossttffiixx mmaaiillbbooxx ssttoorree:: sseeppaarraattee ddoommaaiinnss,, nnoonn--UUNNIIXX aaccccoouunnttss
+
+This is a variation on the Postfix virtual mailbox example. Again, every hosted
+address can have its own mailbox. However, most parameters that control the
+virtual(8) delivery agent are no longer applicable: only
+virtual_mailbox_domains and virtual_mailbox_maps stay in effect. These
+parameters are needed to reject mail for unknown recipients.
+
+While non-Postfix software is being used for final delivery, some Postfix
+concepts are still needed in order to glue everything together. For additional
+background on this glue you may want to take a look at the virtual mailbox
+domain class as defined in the ADDRESS_CLASS_README file.
+
+The text in this section describes what things should look like from Postfix's
+point of view. See CYRUS_README or MAILDROP_README for specific information
+about Cyrus or about Courier maildrop.
+
+Here is an example for a hosted domain example.com that delivers to a non-
+Postfix delivery agent:
+
+     1 /etc/postfix/main.cf:
+     2     virtual_transport = ...see below...
+     3     virtual_mailbox_domains = example.com ...more domains...
+     4     virtual_mailbox_maps = hash:/etc/postfix/vmailbox
+     5     virtual_alias_maps = hash:/etc/postfix/virtual
+     6
+     7 /etc/postfix/vmailbox:
+     8     info@example.com    whatever
+     9     sales@example.com   whatever
+    10     # Comment out the entry below to implement a catch-all.
+    11     # Configure the mailbox store to accept all addresses.
+    12     # @example.com      whatever
+    13     ...virtual mailboxes for more domains...
+    14
+    15 /etc/postfix/virtual:
+    16     postmaster@example.com postmaster
+
+Notes:
+
+  * Line 2: With delivery to a non-Postfix mailbox store for hosted domains,
+    the virtual_transport parameter usually specifies the Postfix LMTP client,
+    or the name of a master.cf entry that executes non-Postfix software via the
+    pipe delivery agent. Typical examples (use only one):
+
+        virtual_transport = lmtp:unix:/path/name (uses UNIX-domain socket)
+        virtual_transport = lmtp:hostname:port   (uses TCP socket)
+        virtual_transport = maildrop:            (uses pipe(8) to command)
+
+    Postfix comes ready with support for LMTP. And an example maildrop delivery
+    method is already defined in the default Postfix master.cf file. See the
+    MAILDROP_README document for more details.
+
+  * Line 3: The virtual_mailbox_domains setting tells Postfix that example.com
+    is delivered via the virtual_transport that was discussed in the previous
+    paragraph. If you omit this virtual_mailbox_domains setting then Postfix
+    will either reject mail (relay access denied) or will not be able to
+    deliver it (mail for example.com loops back to myself).
+
+    NEVER list a virtual MAILBOX domain name as a mydestination domain!
+
+    NEVER list a virtual MAILBOX domain name as a virtual ALIAS domain!
+
+  * Lines 4, 7-13: The virtual_mailbox_maps parameter specifies the lookup
+    table with all valid recipient addresses. The lookup result value is
+    ignored by Postfix. In the above example, info@example.com and
+    sales@example.com are listed as valid addresses; other mail for example.com
+    is rejected with "User unknown" by the Postfix SMTP server. It's left up to
+    the non-Postfix delivery agent to reject non-existent recipients from local
+    submission or from local alias expansion. If you intend to use LDAP, MySQL
+    or PgSQL instead of local files, be sure to review the "local files versus
+    databases" section at the top of this document!
+
+  * Line 12: The commented out entry (text after #) shows how one would inform
+    Postfix of the existence of a catch-all address. Again, the lookup result
+    is ignored by Postfix.
+
+    NEVER put a virtual MAILBOX wild-card in the virtual ALIAS file!!
+
+    Note: if you specify a wildcard in virtual_mailbox_maps, then you still
+    need to configure the non-Postfix mailbox store to receive mail for any
+    address in that domain.
+
+  * Lines 5, 15, 16: As you see above, it is possible to mix virtual aliases
+    with virtual mailboxes. We use this feature to redirect mail for
+    example.com's postmaster address to the local postmaster. You can use the
+    same mechanism to redirect any addresses to a local or remote address.
+
+  * Line 16: This example assumes that in main.cf, $myorigin is listed under
+    the mydestination parameter setting. If that is not the case, specify an
+    explicit domain name on the right-hand side of the virtual alias table
+    entries or else mail will go to the wrong domain.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
+file, execute "ppoossttmmaapp //eettcc//ppoossttffiixx//vvmmaaiillbbooxx" after changing the vmailbox file,
+and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
+
+MMaaiill ffoorrwwaarrddiinngg ddoommaaiinnss
+
+Some providers host domains that have no (or only a few) local mailboxes. The
+main purpose of these domains is to forward mail elsewhere. The following
+example shows how to set up example.com as a mail forwarding domain:
+
+     1 /etc/postfix/main.cf:
+     2     virtual_alias_domains = example.com ...other hosted domains...
+     3     virtual_alias_maps = hash:/etc/postfix/virtual
+     4
+     5 /etc/postfix/virtual:
+     6     postmaster@example.com postmaster
+     7     joe@example.com        joe@somewhere
+     8     jane@example.com       jane@somewhere-else
+     9     # Uncomment entry below to implement a catch-all address
+    10     # @example.com         jim@yet-another-site
+    11     ...virtual aliases for more domains...
+
+Notes:
+
+  * Line 2: The virtual_alias_domains setting tells Postfix that example.com is
+    a so-called virtual alias domain. If you omit this setting then Postfix
+    will reject mail (relay access denied) or will not be able to deliver it
+    (mail for example.com loops back to myself).
+
+    NEVER list a virtual alias domain name as a mydestination domain!
+
+  * Lines 3-11: The /etc/postfix/virtual file contains the virtual aliases.
+    With the example above, mail for postmaster@example.com goes to the local
+    postmaster, while mail for joe@example.com goes to the remote address
+    joe@somewhere, and mail for jane@example.com goes to the remote address
+    jane@somewhere-else. Mail for all other addresses in example.com is
+    rejected with the error message "User unknown".
+
+  * Line 10: The commented out entry (text after #) shows how one would
+    implement a catch-all virtual alias that receives mail for every
+    example.com address not listed in the virtual alias file. This is not
+    without risk. Spammers nowadays try to send mail from (or mail to) every
+    possible name that they can think of. A catch-all mailbox is likely to
+    receive many spam messages, and many bounces for spam messages that were
+    sent in the name of anything@example.com.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
+file, and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
+
+More details about the virtual alias file are given in the virtual(5) manual
+page, including multiple addresses on the right-hand side.
+
+MMaaiilliinngg lliissttss
+
+The examples that were given above already show how to direct mail for virtual
+postmaster addresses to a local postmaster. You can use the same method to
+direct mail for any address to a local or remote address.
+
+There is one major limitation: virtual aliases and virtual mailboxes can't
+directly deliver to mailing list managers such as majordomo. The solution is to
+set up virtual aliases that direct virtual addresses to the local delivery
+agent:
+
+    /etc/postfix/main.cf:
+        virtual_alias_maps = hash:/etc/postfix/virtual
+
+    /etc/postfix/virtual:
+        listname-request@example.com listname-request
+        listname@example.com         listname
+        owner-listname@example.com   owner-listname
+
+    /etc/aliases:
+        listname: "|/some/where/majordomo/wrapper ..."
+        owner-listname: ...
+        listname-request: ...
+
+This example assumes that in main.cf, $myorigin is listed under the
+mydestination parameter setting. If that is not the case, specify an explicit
+domain name on the right-hand side of the virtual alias table entries or else
+mail will go to the wrong domain.
+
+More information about the Postfix local delivery agent can be found in the
+local(8) manual page.
+
+Why does this example use a clumsy virtual alias instead of a more elegant
+transport mapping? The reason is that mail for the virtual mailing list would
+be rejected with "User unknown". In order to make the transport mapping work
+one would still need a bunch of virtual alias or virtual mailbox table entries.
+
+  * In case of a virtual alias domain, there would need to be one identity
+    mapping from each mailing list address to itself.
+  * In case of a virtual mailbox domain, there would need to be a dummy mailbox
+    for each mailing list address.
+
+AAuuttoorreepplliieess
+
+In order to set up an autoreply for virtual recipients while still delivering
+mail as normal, set up a rule in a virtual alias table:
+
+    /etc/postfix/main.cf:
+        virtual_alias_maps = hash:/etc/postfix/virtual
+
+    /etc/postfix/virtual:
+        user@domain.tld user@domain.tld, user@domain.tld@autoreply.mydomain.tld
+
+This delivers mail to the recipient, and sends a copy of the mail to the
+address that produces automatic replies. The address can be serviced on a
+different machine, or it can be serviced locally by setting up a transport map
+entry that pipes all mail for autoreply.mydomain.tld into some script that
+sends an automatic reply back to the sender.
+
+DO NOT list autoreply.mydomain.tld in mydestination!
+
+    /etc/postfix/main.cf:
+        transport_maps = hash:/etc/postfix/transport
+
+    /etc/postfix/transport:
+        autoreply.mydomain.tld  autoreply:
+
+    /etc/postfix/master.cf:
+        # =============================================================
+        # service type  private unpriv  chroot  wakeup  maxproc command
+        #               (yes)   (yes)   (yes)   (never) (100)
+        # =============================================================
+        autoreply unix  -       n       n       -       -       pipe
+            flags= user=nobody argv=/path/to/autoreply $sender $mailbox
+
+This invokes /path/to/autoreply with the sender address and the user@domain.tld
+recipient address on the command line.
+
+For more information, see the pipe(8) manual page, and the comments in the
+Postfix master.cf file.
+
--- a/README_FILES/XCLIENT_README
+++ b/README_FILES/XCLIENT_README
@ -0,0 +1,199 @@
+PPoossttffiixx XXCCLLIIEENNTT HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhee XXCCLLIIEENNTT eexxtteennssiioonn ttoo SSMMTTPP
+
+When an SMTP server announces support for the XCLIENT command, an SMTP client
+may send information that overrides one or more client-related session
+attributes. The XCLIENT command targets the following problems:
+
+ 1. Access control tests. SMTP server access rules are difficult to verify when
+    decisions can be triggered only by remote clients. In order to facilitate
+    access rule testing, an authorized SMTP client test program needs the
+    ability to override the SMTP server's idea of the SMTP client hostname,
+    network address, and other client information, for the entire duration of
+    an SMTP session.
+
+ 2. Client software that downloads mail from an up-stream mail server and
+    injects it into a local MTA via SMTP. In order to take advantage of the
+    local MTA's SMTP server access rules, the client software needs the ability
+    to override the SMTP server's idea of the remote client name, client
+    address and other information. Such information can typically be extracted
+    from the up-stream mail server's Received: message header.
+
+ 3. Post-filter access control and logging. With Internet->filter->MTA style
+    content filter applications, the filter can be simplified if it can
+    delegate decisions concerning mail relay and other access control to the
+    MTA. This is especially useful when the filter acts as a transparent proxy
+    for SMTP commands. This requires that the filter can override the MTA's
+    idea of the SMTP client hostname, network address, and other information.
+
+XXCCLLIIEENNTT CCoommmmaanndd ssyynnttaaxx
+
+An example client-server conversation is given at the end of this document.
+
+In SMTP server EHLO replies, the keyword associated with this extension is
+XCLIENT. It is followed by the names of the attributes that the XCLIENT
+implementation supports.
+
+The XCLIENT command may be sent at any time, except in the middle of a mail
+delivery transaction (i.e. between MAIL and DOT, or MAIL and RSET). The XCLIENT
+command may be pipelined when the server supports ESMTP command pipelining. To
+avoid triggering spamware detectors, the command should be sent at the end of a
+command group.
+
+The syntax of XCLIENT requests is described below. Upper case and quoted
+strings specify terminals, lowercase strings specify meta terminals, and SP is
+whitespace. Although command and attribute names are shown in upper case, they
+are in fact case insensitive.
+
+    xclient-command = XCLIENT 1*( SP attribute-name"="attribute-value )
+
+    attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | LOGIN | DESTADDR |
+    DESTPORT )
+
+    attribute-value = xtext
+
+  * Attribute values are xtext encoded as per RFC 1891.
+
+  * The NAME attribute specifies a remote SMTP client hostname (not an SMTP
+    client address), [UNAVAILABLE] when client hostname lookup failed due to a
+    permanent error, or [TEMPUNAVAIL] when the lookup error condition was
+    transient.
+
+  * The ADDR attribute specifies a remote SMTP client numerical IPv4 network
+    address, an IPv6 address prefixed with IPV6:, or [UNAVAILABLE] when the
+    address information is unavailable. Address information is not enclosed
+    with [].
+
+  * The PORT attribute specifies a remote SMTP client TCP port number as a
+    decimal number, or [UNAVAILABLE] when the information is unavailable.
+
+  * The PROTO attribute specifies either SMTP or ESMTP.
+
+  * The DESTADDR attribute specifies a local SMTP server numerical IPv4 network
+    address, an IPv6 address prefixed with IPV6:, or [UNAVAILABLE] when the
+    address information is unavailable. Address information is not enclosed
+    with [].
+
+  * The DESTPORT attribute specifies a local SMTP server TCP port number as a
+    decimal number, or [UNAVAILABLE] when the information is unavailable.
+
+  * The HELO attribute specifies an SMTP HELO parameter value, or the value
+    [UNAVAILABLE] when the information is unavailable.
+
+  * The LOGIN attribute specifies a SASL login name, or the value [UNAVAILABLE]
+    when the information is unavailable.
+
+Note 1: syntactically valid NAME and HELO attribute-value elements can be up to
+255 characters long. The client must not send XCLIENT commands that exceed the
+512 character limit for SMTP commands. To avoid exceeding the limit the client
+should send the information in multiple XCLIENT commands; for example, send
+NAME and ADDR last, after HELO and PROTO. Once ADDR is sent, the client is
+usually no longer authorized to send XCLIENT commands.
+
+Note 2: [UNAVAILABLE], [TEMPUNAVAIL] and IPV6: may be specified in upper case,
+lower case or mixed case.
+
+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.
+
+XXCCLLIIEENNTT SSeerrvveerr rreessppoonnssee
+
+Upon receipt of a correctly formatted XCLIENT command, the server resets state
+to the initial SMTP greeting protocol stage. Depending on the outcome of
+optional access decisions, the server responds with 220 or with a suitable
+rejection code.
+
+For practical reasons it is not always possible to reset the complete server
+state to the initial SMTP greeting protocol stage:
+
+  * TLS session information may not be reset, because turning off TLS leaves
+    the connection in an undefined state. Consequently, the server may not
+    announce STARTTLS when TLS is already active, and access decisions may be
+    influenced by client certificate information that was received prior to the
+    XCLIENT command.
+
+  * The SMTP server must not reset attributes that were received with the last
+    XCLIENT command. This includes HELO or PROTO attributes.
+
+NOTE: Postfix implementations prior to version 2.3 do not jump back to the
+initial SMTP greeting protocol stage. These older implementations will not
+correctly simulate connection-level access decisions under some conditions.
+
+XXCCLLIIEENNTT sseerrvveerr rreeppllyy ccooddeess
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |CCooddee |MMeeaanniinngg                                                |
+    |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |220  |success                                                |
+    |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |421  |unable to proceed, disconnecting                       |
+    |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |501  |bad command parameter syntax                           |
+    |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |503  |mail transaction in progress                           |
+    |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |550  |insufficient authorization                             |
+    |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |other|connection rejected by connection-level access decision|
+    |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+XXCCLLIIEENNTT EExxaammppllee
+
+In the example, the client impersonates a mail originating system by passing
+all SMTP client information via the XCLIENT command. Information sent by the
+client is shown in bold font.
+
+    220 server.example.com ESMTP Postfix
+    EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+    250-server.example.com
+    250-PIPELINING
+    250-SIZE 10240000
+    250-VRFY
+    250-ETRN
+    250-XCLIENT NAME ADDR PROTO HELO
+    250 8BITMIME
+    XXCCLLIIEENNTT NNAAMMEE==ssppiikkee..ppoorrccuuppiinnee..oorrgg AADDDDRR==116688..110000..118899..22
+    220 server.example.com ESMTP Postfix
+    EEHHLLOO ssppiikkee..ppoorrccuuppiinnee..oorrgg
+    250-server.example.com
+    250-PIPELINING
+    250-SIZE 10240000
+    250-VRFY
+    250-ETRN
+    250-XCLIENT NAME ADDR PROTO HELO
+    250 8BITMIME
+    MMAAIILL FFRROOMM::<<wwiieettssee@@ppoorrccuuppiinnee..oorrgg>>
+    250 Ok
+    RRCCPPTT TTOO::<<uusseerr@@eexxaammppllee..ccoomm>>
+    250 Ok
+    DDAATTAA
+    354 End data with <CR><LF>.<CR><LF>
+    .. .. ..mmeessssaaggee ccoonntteenntt.. .. ..
+    ..
+    250 Ok: queued as 763402AAE6
+    QQUUIITT
+    221 Bye
+
+SSeeccuurriittyy
+
+The XCLIENT command changes audit trails and/or SMTP client access permissions.
+Use of this command must be restricted to authorized SMTP clients.
+
+SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg
+
+XCLIENT attributes persist until the end of an SMTP session. If one session is
+used to deliver mail on behalf of different SMTP clients, the XCLIENT
+attributes need to be reset as appropriate before each MAIL FROM command.
+
+RReeffeerreenncceess
+
+Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891,
+January 1996.
+
--- a/README_FILES/XFORWARD_README
+++ b/README_FILES/XFORWARD_README
@ -0,0 +1,179 @@
+PPoossttffiixx XXFFOORRWWAARRDD HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhee XXFFOORRWWAARRDD eexxtteennssiioonn ttoo SSMMTTPP
+
+When an SMTP server announces support for the XFORWARD command, an SMTP client
+may send information that overrides one or more client-related logging
+attributes. The XFORWARD command targets the following problem:
+
+  * Logging after SMTP-based content filter. With the deployment of Internet-
+    >MTA1->filter->MTA2 style content filter applications, the logging of
+    client and message identifying information changes when MTA1 gives the mail
+    to the content filter. To simplify the interpretation of MTA2 logging, it
+    would help if MTA1 could forward remote client and/or message identifying
+    information through the content filter to MTA2, so that the information
+    could be logged as part of mail handling transactions.
+
+This extension is implemented as a separate ESMTP command, and can be used to
+transmit client or message attributes incrementally. It is not implemented by
+passing additional parameters via the MAIL FROM command, because doing so would
+require extending the MAIL FROM command length limit by another 600 or more
+characters beyond the space that is already needed to support other extensions
+such as AUTH and DSN.
+
+XXFFOORRWWAARRDD CCoommmmaanndd ssyynnttaaxx
+
+An example of a client-server conversation is given at the end of this
+document.
+
+In SMTP server EHLO replies, the keyword associated with this extension is
+XFORWARD. The keyword is followed by the names of the attributes that the
+XFORWARD implementation supports.
+
+After receiving the server's announcement for XFORWARD support, the client may
+send XFORWARD requests at any time except in the middle of a mail delivery
+transaction (i.e. between MAIL and RSET or DOT). The command may be pipelined
+when the server supports ESMTP command pipelining.
+
+The syntax of XFORWARD requests is described below. Upper case and quoted
+strings specify terminals, lowercase strings specify meta terminals, and SP is
+whitespace. Although command and attribute names are shown in upper case, they
+are in fact case insensitive.
+
+    xforward-command = XFORWARD 1*( SP attribute-name"="attribute-value )
+
+    attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | IDENT | SOURCE )
+
+    attribute-value = xtext
+
+  * Attribute values are xtext encoded as per RFC 1891.
+
+  * The NAME attribute specifies the up-stream hostname, or [UNAVAILABLE] when
+    the information is unavailable. The hostname may be a non-DNS hostname.
+
+  * The ADDR attribute specifies the up-stream network address: a numerical
+    IPv4 network address, an IPv6 address prefixed with IPV6:, or [UNAVAILABLE]
+    when the address information is unavailable. Address information is not
+    enclosed with [].
+
+  * The PORT attribute specifies an up-stream client TCP port number in
+    decimal, or [UNAVAILABLE] when the information is unavailable.
+
+  * The PROTO attribute specifies the mail protocol for receiving mail from the
+    up-stream host. This may be an SMTP or non-SMTP protocol name of up to 64
+    characters, or [UNAVAILABLE] when the information is unavailable.
+
+  * The HELO attribute specifies the hostname that the up-stream host announced
+    itself with (not necessarily via the SMTP HELO command), or [UNAVAILABLE]
+    when the information is unavailable. The hostname may be a non-DNS
+    hostname.
+
+  * The IDENT attribute specifies a local message identifier on the up-stream
+    host, or [UNAVAILABLE] when the information is unavailable. The down-stream
+    MTA may log this information together with its own local message identifier
+    to facilitate message tracking across MTAs.
+
+  * The SOURCE attribute specifies LOCAL when the message was received from a
+    source that is local with respect to the up-stream host (for example, the
+    message originated from the up-stream host itself), REMOTE for all other
+    mail, or [UNAVAILABLE] when the information is unavailable. The down-stream
+    MTA may decide to enable features such as header munging or address
+    qualification with mail from local sources but not other sources.
+
+Note 1: an attribute-value element must not be longer than 255 characters
+(specific attributes may impose shorter lengths). After xtext decoding,
+attribute values must not contain control characters, non-ASCII characters,
+whitespace, or other characters that are special in message headers.
+
+Note 2: DNS hostnames can be up to 255 characters long. The XFORWARD client
+implementation must not send XFORWARD commands that exceed the 512 character
+limit for SMTP commands.
+
+Note 3: [UNAVAILABLE] may be specified in upper case, lower case or mixed case.
+
+Note 4: 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.
+
+XXFFOORRWWAARRDD SSeerrvveerr ooppeerraattiioonn
+
+The server maintains a set of XFORWARD attributes with forwarded information,
+in addition the current SMTP session attributes. Normally, all XFORWARD
+attributes are in the undefined state, and the server uses the current SMTP
+session attributes for logging purposes.
+
+Upon receipt of an initial XFORWARD command, the SMTP server initializes all
+XFORWARD attributes to [UNAVAILABLE]. With each valid XFORWARD command, the
+server updates XFORWARD attributes with the specified values.
+
+The server must not mix client attributes from XFORWARD with client attributes
+from the current SMTP session.
+
+At the end of each MAIL FROM transaction (i.e. RSET or DOT), the server resets
+all XFORWARD attributes to the undefined state, and is ready to receive another
+initial XFORWARD command.
+
+XXFFOORRWWAARRDD SSeerrvveerr rreeppllyy ccooddeess
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |CCooddee|MMeeaanniinngg                         |
+    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |250 |success                         |
+    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |421 |unable to proceed, disconnecting|
+    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |501 |bad command parameter syntax    |
+    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |503 |mail transaction in progress    |
+    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+    |550 |insufficient authorization      |
+    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+XXFFOORRWWAARRDD EExxaammppllee
+
+In the following example, information sent by the client is shown in bold font.
+
+    220 server.example.com ESMTP Postfix
+    EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+    250-server.example.com
+    250-PIPELINING
+    250-SIZE 10240000
+    250-VRFY
+    250-ETRN
+    250-XFORWARD NAME ADDR PROTO HELO
+    250 8BITMIME
+    XXFFOORRWWAARRDD NNAAMMEE==ssppiikkee..ppoorrccuuppiinnee..oorrgg AADDDDRR==116688..110000..118899..22 PPRROOTTOO==EESSMMTTPP
+    250 Ok
+    XXFFOORRWWAARRDD HHEELLOO==ssppiikkee..ppoorrccuuppiinnee..oorrgg
+    250 Ok
+    MMAAIILL FFRROOMM::<<wwiieettssee@@ppoorrccuuppiinnee..oorrgg>>
+    250 Ok
+    RRCCPPTT TTOO::<<uusseerr@@eexxaammppllee..ccoomm>>
+    250 Ok
+    DDAATTAA
+    354 End data with <CR><LF>.<CR><LF>
+    .. .. ..mmeessssaaggee ccoonntteenntt.. .. ..
+    ..
+    250 Ok: queued as 3CF6B2AAE8
+    QQUUIITT
+    221 Bye
+
+SSeeccuurriittyy
+
+The XFORWARD command changes audit trails. Use of this command must be
+restricted to authorized clients.
+
+SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg
+
+SMTP connection caching makes it possible to deliver multiple messages within
+the same SMTP session. The XFORWARD attributes are reset after the MAIL FROM
+transaction completes (after RSET or DOT), so there is no risk of information
+leakage.
+
+RReeffeerreenncceess
+
+Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891,
+January 1996.
+
--- a/200
+++ b/200
@ -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.
--- a/RELEASE_NOTES-1.0
+++ b/RELEASE_NOTES-1.0
@ -0,0 +1,746 @@
+This is the first official Postfix release that is not called BETA.
+May it help the people who cannot get BETA software past their
+management.
+
+Release 20010228 differs from snapshot 20010228 in that the virtual
+delivery agent and nqmgr queue manager are left out. That software
+will become part of the official release when it has not changed
+in a while.
+
+In the text below, incompatible changes are labeled with the Postfix
+version that introduced the change. If you upgrade from a later
+Postfix version, then you do not have to worry about that particular
+incompatibility.
+
+Major incompatible changes with release-20010228
+================================================
+
+[snapshot-20010225] POSTFIX NO LONGER RELAYS MAIL FOR CLIENTS IN
+THE ENTIRE CLASS A/B/C NETWORK. To get the old behavior, specify
+"mynetworks_style = class" in the main.cf file. The default
+(mynetworks_style = subnet) is to relay for clients in the local
+IP subnet. See conf/main.cf.
+
+[snapshot-20001005, snapshot-20010225] You must execute "postfix
+stop" before installing this release.  Some recommended parameter
+settings have changed, and a new entry must be added to the master.cf
+file before you can start Postfix again.
+
+1 - The recommended Postfix configuration no longer uses flat
+    directories for the "incoming" "active", "bounce", and "defer"
+    queue directories.  The "flush" directory for the new "flush"
+    service directory should not be flat either.
+
+    Upon start-up, Postfix checks if the hash_queue_names configuration
+    parameter is properly set up, and will add any queue directory
+    names that are missing.
+
+2 - In order to improve performance of one-to-one mail deliveries
+    the queue manager will now look at up to 10000 queue files
+    (was: 1000).  The default qmgr_message_active_limit setting
+    was changed accordingly.
+
+    If you have a non-default qmgr_message_active_limit in main.cf,
+    you may want adjust it.
+
+3 - The new "flush" service needs to be configured in master.cf.
+
+    Upon start-up, Postfix checks if the new "flush" service is
+    configured in the master.cf file, and will add an entry if it
+    is missing.
+
+Should you wish to back out to a previous Postfix release there is
+no need to undo the above queue configuration changes.
+
+[snapshot-20000921] The protocol between queue manager and delivery
+agents has changed.  This means that you cannot mix the Postfix
+queue manager or delivery agents with those of Postfix versions
+prior to 20000921. This change does not affect Postfix queue file
+formats.
+
+[snapshot-20000529] This release introduces an incompatible queue
+file format change ONLY when content filtering is enabled (see text
+in FILTER_README). Old Postfix queue files will work fine, but
+queue files with the new content filtering info will not work with
+Postfix versions before 20000529.  Postfix logs a warning and moves
+incompatible queue files to the "corrupt" mail queue subdirectory.
+
+Minor incompatible changes with release-20010228
+================================================
+
+[snapshot-20010225] The incoming and deferred queue directories
+are now hashed by default.  This improves the performance considerably
+under heavy load, at the cost of a small but noticeable slowdown
+when one runs "mailq" on an unloaded system.
+
+[snapshot-20010222] Postfix no longer automatically delivers
+recipients one at a time when their domain is listed in $mydestination.
+This change solves delivery performance problems with delivery via
+LMTP, with virus scanning, and with firewall relays that forward
+all mail for $mydestination to an inside host.
+
+The "one recipient at a time" delivery behavior is now controlled
+by the per-transport recipient limit (xxx_destination_recipient_limit,
+where xxx is the name of the delivery mechanism).  This parameter
+controls the number of recipients that can be sent in one delivery
+(surprise).
+
+The setting of the per-transport recipient limit also controls the
+meaning of the per-transport destination concurrency limit (named
+xxx_destination_concurrency_limit, where xxx is again the name of
+the delivery mechanism):
+
+ 1) When the per-transport recipient limit is 1 (i.e., send one
+    recipient per delivery), the per-transport destination concurrency
+    limit controls the number of simultaneous deliveries to the
+    same recipient.  This is the default behavior for delivery via
+    the Postfix local delivery agent.
+
+ 2) When the per-transport recipient limit is > 1 (i.e., send
+    multiple recipients per delivery), the per-transport destination
+    concurrency limit controls the number of simultaneous deliveries
+    to the same domain.  This is the default behavior for all other
+    Postfix delivery agents.
+
+[snapshot-20010128] The Postfix local delivery agent now enforces
+mailbox file size limits (default: mailbox_size_limit = 51200000).
+This limit affects all file write access by the local delivery
+agent or by a process run by the local delivery agent. The purpose
+of this parameter is to act as a safety for run-away software. It
+cannot be a substitute for a file quota management system. Specify
+a limit of 0 to disable.
+
+[snapshot-20010128] REJECT in header/body_checks is now flagged as
+policy violation rather than bounce, for consistency in postmaster
+notifications.
+
+[snapshot-20010128] The default RBL (real-time blackhole lists)
+domain examples have been changed from *.vix.com to *.mail-abuse.org.
+
+[snapshot-20001210] Several interfaces of libutil and libglobal
+routines have changed.  This may break third-party code written
+for Postfix. In particular, the safe_open() routine has changed,
+the way the preferred locking method is specified in the sys_defs.h
+file, as well as all routines that perform file locking. When
+compiling third-party code written for Postfix, the incompatibilities
+will be detected by the compiler provided that #include file
+dependencies are properly maintained.
+
+[snapshot-20001210] When delivering to /file/name (as directed in
+an alias or .forward file), the local delivery agent now logs a
+warning when it is unable to create a /file/name.lock file. Mail
+is still delivered as before.
+
+[snapshot-20001210] The "sun_mailtool_compatibility" feature is
+going away (a compatibility mode that turns off kernel locks on
+mailbox files). It still works, but a warning is logged. Instead
+of using "sun_mailtool_compatibility", specify the mailbox locking
+strategy as "mailbox_delivery_lock = dotlock".
+
+[snapshot-20001210] The Postfix SMTP client now skips SMTP server
+replies that do not start with "CODE SPACE" or with "CODE HYPHEN"
+and flags them as protocol errors. Older Postfix SMTP clients
+silently treated "CODE TEXT" as "CODE SPACE TEXT", i.e. as a valid
+SMTP reply.
+
+[snapshot-20001121] On RedHat Linux 7.0, you must install the
+db3-devel RPM before you can compile the Postfix source code.
+
+[snapshot-20000924] The postmaster address in the "sorry" text at
+the top of bounced mail is now just postmaster, not postmaster@machine.
+The idea is to refer users to their own postmaster.
+
+[snapshot-20000921] The notation of [host:port] in transport tables
+etc. is going away but it is still supported. The preferred form
+is now [host]:port.  This change is necessary to support IPV6
+address forms which use ":" as part of a numeric IP address. In a
+future release, Postfix will log a warning when it encounters the
+[host:port] form.
+
+[snapshot-20000921] In mail headers, Errors-To:, Reply-To: and
+Return-Receipt:  addresses are now rewritten as a sender address
+(was: recipient).
+
+[snapshot-20000921] Postfix no longer inserts Sender: message
+headers.
+
+[snapshot-20000921] The queue manager now logs the original number
+of recipients when opening a queue file (example: from=<>, size=3502,
+nrcpt=1).
+
+[snapshot-20000921] The local delivery agent no longer appends a
+blank line to mail that is delivered to external command.
+
+[snapshot-20000921] The pipe delivery agent no longer appends a
+blank line when the F flag is specified (in the master.cf file).
+Specify the B flag if you need that blank line.
+
+[snapshot-20000507] As required by RFC 822, Postfix now inserts a
+generic destination message header when no destination header is
+present.  The text is specified via the undisclosed_recipients_header
+configuration parameter (default:  "To: undisclosed-recipients:;").
+
+[snapshot-20000507] The Postfix sendmail command treats a line with
+only `.' as the end of input, for the sake of sendmail compatibility.
+To disable this feature, specify the sendmail-compatible `-i' or
+`-oi' flags on the sendmail command line.
+
+[snapshot-20000507] For the sake of Sendmail compatibility, the
+Postfix SMTP client skips over SMTP servers that greet with a 4XX
+or 5XX reply code, treating them as unreachable servers.  To obtain
+prior behavior (4XX=retry, 5XX=bounce), specify "smtp_skip_4xx_greeting
+= no" and "smtp_skip_5xx_greeting = no".
+
+Major changes with release-20010228
+===================================
+
+Postfix produces DSN formatted bounced/delayed mail notifications.
+The human-readable text still exists, so that users will not have
+to be unnecessarily confused by all the ugliness of RFC 1894.  Full
+DSN support will be later.
+
+This release introduces full content filtering through an external
+process. This involves an incompatible change in queue file format.
+Mail is delivered to content filtering software via an existing
+mail delivery agent, and is re-injected into Postfix via an existing
+mail submission agent.  See examples in the FILTER_README file.
+Depending on how the filter is implemented, you can expect to lose
+a factor of 2 to 4 in delivery performance of SMTP transit mail,
+more if the content filtering software needs lots of CPU or memory.
+
+Specify "body_checks = regexp:/etc/postfix/body_checks" for a quick
+and dirty emergency content filter that looks at non-header lines
+one line at a time (including MIME headers inside the message body).
+Details in conf/sample-filter.cf.
+
+The header_checks and body_checks features can be used to strip
+out unwanted data. Specify IGNORE on the right-hand side and the
+data will disappear from the mail.
+
+Support for SASL (RFC 2554) authentication in the SMTP server and
+in the SMTP and LMTP clients. See the SASL_README file for more
+details. This file still needs better examples.
+
+Postfix now ships with an LMTP delivery agent that can deliver over
+local/remote TCP sockets and over local UNIX-domain sockets.  The
+LMTP_README file gives example, but still needs to be revised.
+
+Fast "ETRN" and "sendmail -qR".  Postfix maintains per-destination
+logfiles with information about what mail is queued for selected
+destinations.  See the file ETRN_README for details.
+
+The mailbox locking style is now fully configurable at runtime.
+The new configuration parameter is called "mailbox_delivery_lock".
+Depending on the operating system type, mailboxes can be locked
+with one or more of "flock", "fcntl" or "dotlock".  The command
+"postconf -l" shows the available locking styles.  The default
+mailbox locking style is system dependent.  This change affects
+all mailbox and all "/file/name" deliveries by the Postfix local
+delivery agent.
+
+Minor changes with release-20010228
+===================================
+
+You can now specify multiple SMTP destinations in the relayhost
+and fallback_relay configuration parameters. The destinations are
+tried in the specified order. Specify host or host:port (perform
+MX record lookups), [host] or [host]:port (no MX record lookups),
+[address] or [address]:port (numerical IP address).
+
+The "mailbox_transport" and "fallback_transport" parameters now
+understand the form "transport:nexthop", with suitable defaults
+when either transport or nexthop are omitted, just like in the
+Postfix transport map. This allows you to specify for example,
+"mailbox_transport = lmtp:unix:/file/name".
+
+The local_transport and default_transport configuration parameters
+can now be specified in transport:destination notation, just like
+the mailbox_transport and fallback_transport parameters.  The
+:destination part is optional.  However, these parameters take only
+one destination, unlike relayhost and fallback-relay which take
+any number of destinations.
+
+More general virtual domain support.  Postfix now supports both
+Sendmail-style virtual domains and Postfix-style virtual domains.
+Details and examples are given in the revised virtual manual page.
+
+- With Sendmail-style virtual domains, local users/aliases/mailing
+  lists are visible as localname@virtual.domain. This is convenient
+  if you want to host mailing lists under virtual domains.
+
+- With Postfix-style virtual domains, local users/aliases/mailing
+  lists are not visible as localname@virtual.domain. Each virtual
+  domain has its own separate name space.
+
+More general "soft bounce" feature.  Specify "soft_bounce = yes"
+in main.cf to prevent the SMTP server from bouncing mail while you
+are testing configurations. Until this release the SMTP server was
+not aware of soft bounces.
+
+Workarounds for non-standard RFC 2554 (AUTH command) implementations.
+Specify "broken_sasl_auth_clients = yes" to enable SMTP server
+support for old Microsoft client applications. The Postfix SMTP
+client supports non-standard RFC 2554 servers by default.
+
+All time-related configuration parameters now accept a one-letter
+suffix to indicate the time unit (s: second, m: minute, h: hour,
+d: day, w: week). The exceptions are the LDAP and MYSQL modules
+which are maintained separately.
+
+New "import_environment" and "export_environment" configuration
+parameters provide explicit control over what environment variables
+Postfix will import, and what environment variables Postfix will
+pass on to a non-Postfix process.
+
+In order to improve performance of one-to-one deliveries, Postfix
+by default now looks at up to 10000 messages at a time (was: 1000).
+
+Specify "syslog_facility = log_local1" etc. to separate the logging
+from multiple Postfix instances. However, a non-default logging
+facility takes effect only after process initialization. Errors
+during command-line parsing are still logged with the default syslog
+facility, as are errors while processing the main.cf file.
+
+Postfix now strips out Content-Length: headers in incoming mail to
+avoid confusion in mail user agents.
+
+Specify "require_home_directory = yes" to prevent mail from being
+delivered to a user whose home directory is not mounted. This
+feature is implemented by the Postfix local delivery agent.
+
+The pipe mailer has a size limit (size=nnn) command-line argument.
+
+The pipe delivery agent has a configurable end-of-line attribute.
+Specify "pipe ... eol=\r\n" for delivery mechanisms that require
+CRLF record delimiters. The eol attribute understands the following
+C-style escape sequences:  \a \b \f \n \r \t \v \nnn \\.
+
+In master.cf you can selectively override main.cf configuration
+parameters, for example: "smtpd -o myhostname=foo.com".
+
+In main.cf, specify "smtp_bind_address=x.x.x.x" to bind SMTP
+connections to a specific local interface. Or override the default
+setting in master.cf with "smtp -o smtp_bind_address=x.x.x.x".
+For now, you must specify a numeric IP address.
+
+Questionable feature: with "smtp_always_send_ehlo = yes", the SMTP
+client sends EHLO regardless of the content of the SMTP server's
+greeting.
+
+Specify "-d key" to postalias or postmap in order to remove one
+key. This still needs to be generalized to multi-key removal (e.g.,
+read keys from stdin).
+
+Comments in Postfix configuration files no longer contain troff
+formatting codes.  The text is now generated from prototype files
+in a new "proto" subdirectory.
+
+Major changes with postfix-19991231:
+====================================
+
+- It is now much more difficult to configure Postfix as an open
+relay. The SMTP server requires that "smtpd_recipient_restrictions"
+contains at least one restriction that by default refuses mail (as
+is the default).  There were too many accidents with changes to
+the UCE restrictions.
+
+- The relay_domains parameter no longer needs to contain $virtual_maps.
+
+- Overhauled FAQ (html/faq.html) with many more examples.
+
+- Updated UCE documentation (html/uce.html) with more examples.
+More UCE configuration examples in sample configuration files.
+
+- Several little improvements to the installation procedure:
+relative symlinks, configurable directory for scratch files so the
+installation can be done without write access to the build tree.
+
+- Updated LDAP client code (John Hensley).
+
+- Updated mysql client code (Scott Cotton).
+
+- The SMTP server now rejects mail for unknown users in virtual
+domains that are defined by Postfix virtual maps.
+
+- The SMTP server can reject mail for unknown local users.  Specify
+"local_recipient_maps = $alias_maps, unix:passwd.byname" if your
+local mail is delivered by a UNIX-style local delivery agent.  See
+example in conf/main.cf.
+
+- Use "disable_vrfy_command = yes" to disable the SMTP VRFY command.
+This prevents some forms of address harvesting.
+
+- The sendmail "-f" option now understands <user> and even understands
+forms with RFC 822-style comments.
+
+- New "qmgr_fudge_factor" parameter allows you to balance mailing
+list performance against response time for one-to-one mail.  The
+fudge factor controls what percentage of delivery resources Postfix
+will devote to one message.  With 100%, delivery of one message
+does not begin before delivery of the previous message is completed.
+This is good for list performance, bad for one-to-one mail. With
+10%, response time for one-to-one mail improves much, but list
+performance suffers: in the worst case, people near the start of a
+mailing list get a burst of postings today, while people near the
+end of the list get that same burst of postings a whole day later.
+
+- It is now relatively safe to configure 550 status codes for the
+main.cf unknown_address_reject_code or unknown_client_reject_code
+parameters.  The SMTP server now always sends a 450 (try again)
+reply code when an UCE restriction fails due to a soft DNS error,
+regardless of what main.cf specifies.
+
+- The RBL checks now show the content of TXT records (Simon J Mudd).
+
+- The Postfix SMTP server now understands a wider range of illegal
+address forms in MAIL FROM and RCPT TO commands. In order to disable
+illegal forms, specify "strict_rfc821_envelopes = yes". This also
+disables support for MAIL FROM and RCPT TO addresses without <>.
+
+- Per-client/helo/sender/recipient UCE restrictions (fully-recursive
+UCE restriction parser). See the RESTRICTION_CLASS file for details.
+
+- Use "postmap -q key" or "postalias -q key" for testing Postfix
+lookup tables or alias files.
+
+- Use "postconf -e name=value..." to edit the main.cf file.  This
+is easier and safer than editing the main.cf file by hand. The
+edits are done on a temporary copy that is renamed into place.
+
+- Use "postconf -m" to display all supported lookup table types
+(Scott Cotton).
+
+- New "permit_auth_destination" UCE restriction for finer-grained
+access control (Jesper Skriver).
+
+Incompatible changes with postfix-19990906
+==========================================
+
+- On systems that use user.lock files to protect system mailboxes
+against simultaneous updates, Postfix now uses /file/name.lock
+files while delivering to files specified in aliases/forward/include
+files. This is a no-op when the recipient lacks directory write
+permission.
+
+- The LDAP client code no longer looks up a name containing "*"
+because it could be abused.  See the LDAP_README file for how to
+restore previous behavior.
+
+- The Postfix to PCRE interface now expects PCRE version 2.08.
+Postfix is no longer compatible with PCRE versions prior to 2.06.
+
+Major changes with postfix-19990906
+===================================
+
+Several bugfixes, none related to security.  See the HISTORY file
+for a complete list of changes.
+
+- Postfix is now distributed under IBM Public License Version 1.0
+which does not carry the controversial termination clause. The new
+license does have a requirement that contributors make source code
+available.
+
+- INSTALL.sh install/upgrade procedure that replaces existing
+programs and shell scripts instead of overwriting them, and that
+leaves existing queue files and configuration files alone.
+
+- The ugly Delivered-To: header can now be turned off selectively.
+The default setting is:  "prepend_delivered_header = command, file,
+forward".  Turning off the Delivered-To:  header when forwarding
+mail is not recommended.
+
+- mysql client support by Scott Cotton and Joshua Marcus, Internet
+Consultants Group, Inc. See the file MYSQL_README for instructions.
+
+- reject_unauth_destination SMTP recipient restriction that rejects
+destinations not in $relay_domains. Unlike the check_relay_domains
+restriction, reject_unauth_destination ignores the client hostname.
+By Lamont Jones of Hewlett-Packard.
+
+- reject_unauth_pipelining SMTP *anything* restriction to stop mail
+from spammers that improperly use SMTP command pipelining to speed
+up their deliveries.
+
+- Postfix "sendmail" now issues a warning and drops privileges if
+installed set-uid root.
+
+- No more duplicate delivery when "postfix reload" is immediately
+followed by "sendmail -q".
+
+- No more "invalid argument" errors when a Postfix daemon opens a
+DB/DBM file while some other process is changing the file.
+
+- Portability to the Mac OS X Server, Reliant Unix, AIX 3.2.5 and
+Ultrix 4.3.
+
+Incompatible changes with postfix-19990601:
+===========================================
+
+- The SMTP server now delays all UCE restrictions until the RCPT
+TO, VRFY or ETRN command. This makes the restrictions more useful,
+because many SMTP clients do not expect negative responses earlier
+in the protocol.  In order to restore the old behavior, specify
+"smtpd_delay_reject = no" in /etc/postfix/main.cf.
+
+- The Postfix local delivery agent no longer automatically propagates
+address extensions to aliases/include/forward addresses.  Specify
+"propagate_unmatched_extensions = canonical, virtual, alias, forward,
+include" to restore the old behavior.
+
+- The Postfix local delivery agent no longer does $name expansion
+on words found in the mailbox_command configuration parameter. This
+makes it easier to specify shell syntax. See conf/main.cf.
+
+- The luser_relay syntax has changed. You can specify one address;
+it is subjected to $user, etc. expansions. See conf/main.cf.
+
+- File system reorganization: daemon executables are now in the
+libexec subdirectory, command executables in the bin subdirectory.
+The INSTALL instructions now recommend installing daemons and
+commands into separate directories.
+
+Major changes with postfix-19990601:
+=====================================
+
+- New USER, EXTENSION, LOCAL, DOMAIN and RECIPIENT environment
+variables for delivery to command (including mailbox_command) by
+the local delivery agent. As you might expect, the information is
+censored. The list of acceptable characters is specified with the
+command_expansion_filter configuration parameter.  Unacceptable
+characters are replaced by underscores. See html/local.8.html.
+
+- Specify "forward_path = /var/forward/$user" to avoid looking up
+.forward files in user home directories.  The default value is
+$home/.forward$recipient_delimiter$extension, $home/.forward.
+Initial code by Philip A.  Prindeville, Mirapoint, Inc., USA.
+
+- Conditional $name expansion in forward_path and luser_relay.
+Available names are: $user (bare user name) $shell (user login
+shell), $home (user home directory), $local (everything to the left
+of @), $extension (optional address extension), $domain (everything
+to the right of @), $recipient (the complete address) and
+$recipient_delimiter.  A simple $name expands as usual.  ${name?value}
+expands to value when $name is defined.  ${name:value} expands to
+value when $name is not defined. With ${name?value} and ${name:value},
+the value is subject to another iteration of $name expansion.
+
+- POSIX regular expression support, enabled by default on 4.4BSD,
+LINUX, HP-UX, and Solaris 2.5 and later. See conf/sample-regexp.cf.
+Initial code by Lamont Jones, Hewlett-Packard, borrowing heavily
+from the PCRE implementation by Andrew McNamara, connect.com.au
+Pty. Ltd., Australia.
+
+- Regular expression checks for message headers.  This requires
+support for POSIX or for PCRE regular expressions.  Specify
+"header_checks = regexp:/file/name" or "header_checks = pcre:/file/name",
+and specify "/^header-name:  badstuff/ REJECT" in the pattern file
+(patterns are case-insensitive by default).  Code by Lamont Jones,
+Hewlett-Packard.  It is to be expected that full content filtering
+will be delegated to an external command.
+
+- Regular expression support for all lookup tables, including access
+control (full mail addresses only), address rewriting (canonical/virtual,
+full mail addresses only) and transport tables (full domain names
+only).  However, regular expressions are not allowed for aliases,
+because that would open up security exposures.
+
+- Automatic detection of changes to DB or DBM lookup tables.  This
+eliminates the need to run "postfix reload" after each change to
+the SMTP access table, or to the canonical, virtual, transport or
+aliases tables.
+
+- New error mailer. Specify ".domain.name error:domain is undeliverable"
+in the transport table to bounce mail for entire domains.
+
+- No more Postfix lockups on Solaris (knock on wood). The code no
+longer uses Solaris UNIX-domain sockets, because they are still
+broken, even with Solaris 7.
+
+- Workaround for the Solaris mailtool, which keeps an exclusive
+kernel lock on the mailbox while its window is not iconified (specify
+"sun_mailtool_compatibility = yes" in main.cf).
+
+- Questionable workaround for Solaris, which reportedly loses
+long-lived exclusive locks that are held by the master daemon.
+
+- New reject_unknown_{sender,recipient}_domain restrictions for
+sender and recipient mail addresses that distinguish between soft
+errors (always 450) and hard errors (unknown_address_reject_code,
+default 450).
+
+- MIME-encapsulated bounce messages, making it easier to recover
+bounced mail. Initial implementation by Philip A.  Prindeville,
+Mirapoint, Inc., USA. Support for RFC 1892 (multipart/report) and
+RFC 1894 (DSN) will have to wait until Postfix internals have been
+revised to support RFC 1893.
+
+- Separately configurable "postmaster" addresses for single bounces
+(bounce_notice_recipient), double bounces (2bounce_notice_recipient),
+delayed mail (delay_notice_recipient), and for mailer error reports
+(error_notice_recipient). See conf/main.cf.
+
+- Questionable feature: specify "best_mx_transport = local" if
+this machine is the best MX host for domains not in mydestinations.
+
+Incompatible changes with postfix-19990317:
+===========================================
+
+- You MUST install the new version of /etc/postfix/postfix-script.
+
+- The pipe mailer "flags" syntax has changed. You now explicitly
+MUST specify the R flag in order to generate a Return-Path:  message
+header (as needed by, for example, cyrus).
+
+Major changes with postfix-19990317:
+====================================
+
+A detailed record of changes is given in the HISTORY file.
+
+- Less postmaster mail. Undeliverable bounce messages (double
+bounces) are now discarded. Specify "notify_classes = 2bounce..."
+to get copies of double bounces. Specify "notify_classes = bounce..."
+to get copies of normal and double bounces.
+
+- Improved LDAP client code by John Hensley of Merit Network, USA.
+See LDAP_README for details.
+
+- Perl-compatible regular expression support for lookup maps by
+Andrew McNamara, connect.com.au Pty. Ltd., Australia..  Example:
+"check_recipient_access pcre:/etc/postfix/sample-pcre.cf". Regular
+expressions provide a powerful tool not only for SMTP access control
+but also for address rewriting. See PCRE_README for details.
+
+- Automatic notification of delayed mail (disabled by default).
+With "delay_warning_time = 4", Postfix informs senders when mail
+has not been delivered after 4 hours. Initial version of the code
+by Daniel Eisenbud, University of California at Berkeley. In order
+to get postmaster copies of such warnings, specify "notify_classes
+= delay...".
+
+- More configurable local delivery: "mail_spool_directory" to
+specify the UNIX mail spool directory; "mailbox_transport" to
+delegate all mailbox delivery to, for example, cyrus, and
+"fallback_transport" to delegate delivery of only non-UNIX users.
+And all this without losing local aliases and local .forward
+processing.  See config/main.cf and config/master.cf.
+
+- Several changes to improve Postfix behavior under worst-case
+conditions (frequent Postfix restarts/reloads combined with lots
+if inbound mail, intermittent connectivity problems, SMTP servers
+that become comatose after receiving QUIT).
+
+- More NFS-friendly mailbox delivery. The local delivery agent
+now avoids using root privileges where possible.
+
+- For sites that do not receive mail at all, mydestination can now
+be an empty string. Be sure to set up a transport table entry to
+prevent mail from looping.
+
+- New "postsuper" utility to clean up stale files from Postfix
+queues.
+
+- Workaround for BSD select() collisions that cause performance
+problems on large BSD systems.
+
+- Several questionable but useful features to capture mail:
+"always_bcc = address" to capture a copy of every message that
+enters the system, and "luser_relay = address" to capture mail for
+unknown recipients (does not work when mailbox_transport or
+fallback_transport are being used).
+
+- Junk mail controls: new reject_non_fqdn_{hostname,sender,recipient}
+restrictions to reject non-FQDN arguments in HELO, MAIL FROM and
+RCPT TO commands, and stricter checking of numeric HELO arguments.
+
+- "fallback_relay" feature for sites that use DNS but that can't
+talk to the entire world. The fall-back relay gets the mail when
+a destination is not found in the DNS or when the destination is
+found but not reachable.
+
+- Several questionable controls that can help to keep mail going:
+specify "smtp_skip_4xx_greeting = yes" to skip SMTP servers that
+greet with 4XX, "ignore_mx_lookup_error = yes" to look up an A
+record when a DNS server does not respond to an MX query.
+
+Incompatible changes with postfix-beta-19990122-pl01:
+=====================================================
+
+None.
+
+Major changes with postfix-beta-19990122-pl01:
+==============================================
+
+- Restrict who may use ETRN and what domains may be specified.
+Example:  "smtpd_etrn_restrictions = permit_mynetworks, reject".
+
+- BIFF notifications.  For compatibility reasons this feature is
+on by default.  Specify "biff = no" in main.cf if your machine has
+lots of shell users.
+
+- With "soft_bounce = yes", defer delivery instead of bouncing
+mail. This is a safety net for configuration errors with delivery
+agents. It has no effect on errors in virtual maps, canonical maps,
+or in junk mail restrictions.
+
+- Specify "owner_request_special = no" to turn off special treatment
+of owner-foo and foo-request addresses.
+
+Incompatible changes with postfix-beta-19990122:
+================================================
+
+- The syntax of the transport table has changed. An entry like:
+
+	customer.org	smtp:[gateway.customer.org]
+
+  no longer forwards mail for anything.customer.org. For that you
+  need to specify:
+
+	customer.org	smtp:[gateway.customer.org]
+	.customer.org	smtp:[gateway.customer.org]
+
+  This change makes transport tables more compatible with
+  sendmail mailer tables.
+
+- The format of syslog records has changed. A client is now always
+logged as hostname[address]; the pickup daemon logs queue file uid
+and sender address.
+
+Major changes with postfix-beta-19990122:
+=========================================
+
+- Junk mail restrictions can now be postponed to the RCPT TO command.
+Specify: "smtpd_recipient_restrictions = reject_maps_rbl...".
+
+- More flexible interface for delivery to e.g., cyrus IMAP without
+need for PERL scripts to munge recipient addresses. In addition to
+$sender, $nexthop and $recipient, the pipe mailer now also supports
+$user, $extension and $mailbox.
+
+- New mail now has precedence over deferred mail, plus some other
+tweaks to make bulk mail go faster. But it ain't no cure for massive
+network outages.
+
+- Watchdog timer for systems that cause the Postfix queue manager
+to lock up, so it recovers without human intervention.
+
+- Delivery to qmail-style maildir files, which is good for NFS
+environments.  Specify "home_mailbox = Maildir/", or specify
+/file/name/ in aliases or in .forward files. The trailing / is
+required to turn on maildir delivery.
+
+- Incremental updates of aliases and maps. Specify "postmap -i
+mapname" and it will read new entries from stdin. 
+
+- Newaliases will now update more than one alias database.
+Specify the names with the main.cf "alias_database" parameter.
+
+- Address masquerading exceptions to prevent users from being
+masqueraded. Specify "masquerade_exceptions = root".
+
+- A pipelined SMTP client. Deliveries to Postfix, qmail, LSOFT,
+zmailer, and exim (once it's fixed) speed up by some 30% for short
+messages with one recipient, with more for multi-recipient mails.
+
+- Hook for local delivery to "|command" via the smrsh restricted
+shell, to restrict what commands may be used in .forward etc. files.
+Specify "local_command_shell = /some/where/smrsh -c".
--- a/RELEASE_NOTES-1.1
+++ b/RELEASE_NOTES-1.1
--- a/RELEASE_NOTES-2.0
+++ b/RELEASE_NOTES-2.0
@ -0,0 +1,853 @@
+==============================================================
+NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
+==============================================================
+Before upgrading from Postfix 1.1 you must stop Postfix ("postfix
+stop").  Some internal protocols have changed.  No mail will be
+lost if you fail to stop and restart Postfix, but Postfix won't be
+able to receive any new mail, either.
+==============================================================
+NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
+==============================================================
+
+In the text below, changes are labeled with the Postfix snapshot
+that introduced the change, and whether the change introduced a
+feature, an incompatibility, or whether the feature is obsolete.
+If you upgrade from a later Postfix version, then you do not have
+to worry about incompatibilities introduced in earlier versions.
+
+Official Postfix releases are called a.b.c where a=major release
+number, b=minor release number, c=patchlevel.  Snapshot releases
+are now called a.b.c-yyyymmdd where yyyymmdd is the release date
+(yyyy=year, mm=month, dd=day).  The mail_release_date configuration
+parameter contains the release date (both for official release and
+snapshot release).  Patches change the patchlevel and the release
+date. Snapshots change only the release date, unless they include
+the same bugfixes as a patch release.
+
+Major changes with Postfix version 2.0.0 (released 20021222, 20021223)
+======================================================================
+
+First comes the bad news - things that may break when you upgrade
+from Postfix 1.1. Then comes the good news - things that evolved
+in snapshots over the past year.
+
+For the release notes of Postfix 1.1 and earlier, see the
+RELEASE_NOTES-1.1 file.
+
+Unknown Recipients are now rejected by default
+==============================================
+
+[Incompatibility 20021209] The Postfix SMTP server now rejects mail
+for $mydestination domain recipients that it does not know about.
+This keeps undeliverable mail out of your queue.
+
+[Incompatibility 20021209] To avoid losing mail when upgrading from
+Postfix 1.1, you need to review the LOCAL_RECIPIENT_README file if
+one of the following is true:
+
+- You define $mydestination domain recipients in files other than
+  /etc/passwd or /etc/aliases.  For example, you define $mydestination
+  domain recipients in the $virtual_mailbox_maps files.
+- You run the Postfix SMTP server chrooted (see master.cf).
+- You redefined the local delivery agent in master.cf.
+- You redefined the "local_transport" setting in main.cf.
+- You use the mailbox_transport feature of the Postfix local delivery agent.
+- You use the fallback_transport feature of the Postfix local delivery agent.
+- You use the luser_relay feature of the Postfix local delivery agent.
+
+Name change of virtual domain tables
+====================================
+
+This release introduces separation of lookup tables for addresses
+and for domain names of virtual domains.
+
+[Incompat 20021209] the virtual_maps parameter is replaced by
+virtual_alias_maps (for address lookups) and virtual_alias_domains
+(for the names of what were formerly called "Postfix-style virtual
+domains").
+
+  For backwards compatibility with Postfix version 1.1, the new
+  virtual_alias_maps parameter defaults to $virtual_maps, and the
+  new virtual_alias_domains parameter defaults to $virtual_alias_maps.
+  This means that you can still keep all information about a domain
+  in one file, just like before.
+
+For details, see the virtual(5) and sample-virtual.cf files.
+
+[Incompat 20021209] the virtual_mailbox_maps parameter now has a
+companion parameter called virtual_mailbox_domains (for the names
+of domains served by the virtual delivery agent). virtual_mailbox_maps
+is now used for address lookups only.
+
+  For backwards compatibility with Postfix version 1.1,, the new
+  virtual_mailbox_domains parameter defaults to $virtual_mailbox_maps.
+  This means that you can still keep all information about a domain
+  in one file, just like before.
+
+For details, see the VIRTUAL_README file.
+
+[Incompat 20021209] If you use the "advanced content filter"
+technique, you MUST NOT override the virtual aliases and virtual
+mailbox settings in the SMTP server that receives mail from the
+content filter, or else mail for virtual recipients will be rejected
+with "User unknown".
+
+For details, see the FILTER_README file.
+
+Incompatible queue file format changes
+======================================
+
+[Incompat 20020527] Queue files created with the header/body_checks
+"FILTER" feature are not compatible with "postqueue -r" (move queue
+files back to the maildrop directory) of previous Postfix releases.
+
+[Incompat 20020512] Postfix queue files contain records that are
+incompatible with "postqueue -r" on all Postfix versions prior to
+1.1 and release candidates. This happens whenever the sender
+specifies MIME body type information via the SMTP `MAIL FROM'
+command, via the `sendmail -B' command line option, or via the
+Content-Transfer-Encoding:  message header.
+
+[Incompat 20020512] Postfix queue files may contain records that
+are incompatible with "postqueue -r" on previous 1.1 Postfix versions
+and release candidates. This happens whenever the sender specifies
+the MIME body type only via the Content-Transfer-Encoding:  message
+header, and not via `MAIL FROM' or `sendmail -B'.
+
+Features that are going away
+============================
+
+[Obsolete 20021209] Sendmail-style virtual domains are no longer
+documented.  This part of Postfix was too confusing.
+
+[Obsolete 20021209] The "reject_maps_rbl" restriction is going
+away. The SMTP server now logs a warning and suggests using the
+more flexible "reject_rbl_client" feature instead.
+
+[Obsolete 20021209] The "check_relay_domains" restriction is going
+away.  The SMTP server logs a warning and suggests using the more
+robust "reject_unauth_destination" instead. This means that Postfix 
+by default no longer grants relay permissions on the basis of the 
+client hostname, and that relay clients must be authorized via 
+other means such as permit_mynetworks.
+
+[Obsolete 20020917] In regexp lookup tables, the form /pattern1/!/pattern2/
+is going away. Use the cleaner and more flexible "if !/pattern2/..endif"
+form.  The old form still exists but is no longer documented, and
+causes a warning (suggesting to use the new format) to be logged.
+For details, see "man regexp_table".
+
+[Obsolete 20020819] The qmgr_site_hog_factor feature is gone (this
+would defer mail delivery for sites that occupy too much space in
+the active queue, and be a real performance drain due to excessive
+disk I/O).  The new qmgr_clog_warn_time feature (see below) provides
+more useful suggestions for dealing with Postfix congestion.
+
+[Obsolete 20020819] The "permit_naked_ip_address" restriction on
+HELO command syntax is unsafe when used with most smtpd_XXX_restrictions
+and will go away. Postfix logs a warning, suggesting to use
+"permit_mynetworks" instead.
+
+MIME support
+============
+
+[Feature 20020527] Postfix now has real MIME support. This improves
+content filtering efficiency and accuracy, and improves inter-operability
+with mail systems that cannot receive 8-bit mail. See conf/sample-mime.cf
+for details.
+
+[Feature 20020527] Postfix header_checks now properly recognize
+MIME headers in attachments. This is much more efficient than
+previous versions that recognized MIME headers via body_checks.
+MIME headers are now processed one multi-line header at a time,
+instead of one body line at a time.  To get the old behavior,
+specify "disable_mime_input_processing = yes".  More details in
+conf/sample-filter.cf.
+
+[Feature 20020527] Postfix now has three classes of header patterns:
+header_checks (for primary message headers except MIME headers),
+mime_header_checks (for MIME headers), and nested_header_checks
+(for headers of attached email messages except MIME headers).  By
+default, all headers are matched with header_checks.
+
+[Feature 20020527] The Postfix SMTP client will now convert 8BITMIME
+mail to 7BIT when delivering to an SMTP server that does not announce
+8BITMIME support.  To disable, specify "disable_mime_output_conversion
+= yes". However, this conversion is required by RFC standards.
+
+[Feature 20020528] Postfix can enforce specific aspects of the MIME
+standards while receiving mail.
+
+* Specify "strict_7bit_headers = yes" to disallow 8-bit characters
+  in message headers.  These are always illegal.
+
+* Specify "strict_8bitmime_body = yes" to block mail with 8-bit
+  content that is not properly labeled as 8-bit MIME. This blocks
+  mail from poorly written mail software, including (bounces from
+  qmail, bounces from Postfix before snapshot 20020514, and Majordomo
+  approval requests) that contain valid 8BITMIME mail.
+
+* Specify "strict_8bitmime = yes" to turn on both strict_7bit_headers
+  and strict_8bitmime_body.
+
+* Specify "strict_mime_encoding_domain = yes" to block mail from
+  poorly written mail software. More details in conf/sample-mime.cf.
+
+[Incompat 20020527] Postfix now rejects mail if the MIME multipart
+structure is nested more than mime_nesting_limit levels (default:
+100) when MIME input processing is enabled while receiving mail, or
+when Postfix is performing 8BITMIME to 7BIT conversion while
+delivering mail.
+
+[Incompat 20020527] Postfix now recognizes "name :" as a valid
+message header, but normalizes it to "name:" for consistency
+(actually, there is so much code in Postfix that would break with
+"name :" that there is little choice, except to not recognize "name
+:" headers).
+
+[Incompat 20020512] Postfix queue files contain records that are
+incompatible with "postqueue -r" on all Postfix versions prior to
+1.1 and release candidates. This happens whenever the sender
+specifies MIME body type information via the SMTP `MAIL FROM'
+command, via the `sendmail -B' command line option, or via the
+Content-Transfer-Encoding:  message header.
+
+[Incompat 20020512] Postfix queue files may contain records that
+are incompatible with "postqueue -r" on previous 1.1 Postfix versions
+and release candidates. This happens whenever the sender specifies
+the MIME body type only via the Content-Transfer-Encoding:  message
+header, and not via `MAIL FROM' or `sendmail -B'.
+
+[Feature 20020512] The Postfix SMTP and LMTP clients now properly
+pass on the MIME body type information (7BIT or 8BITMIME), provided
+that the sender properly specifies MIME body type information via
+the SMTP MAIL FROM command, via the sendmail -B command line option,
+or via MIME message headers. This includes mail that is returned
+as undeliverable.
+
+Improved performance
+====================
+
+[Incompat 20021209] The default queue directory hash_queue_depth
+setting is reduced to 1 level of subdirectories per Postfix queue.
+This improves "mailq" performance on most systems, but can result
+in poorer worst-case performance on systems with lots of mail in
+the queue.
+
+[Incompat 20021209] The Postfix SMTP client no longer expands CNAMEs
+in MAIL FROM or RCPT TO addresses (as permitted by RFC 2821). This
+eliminates one DNS lookup per sender and recipient, and can make
+a dramatic difference when sending mailing list mail via a relayhost.
+
+[Incompat 20021209] The Postfix installation procedure no longer
+sets the "chattr +S" bit on Linux queue directories. Wietse has
+gotten too annoyed with naive reviewers who complain about performance
+without having a clue of what they are comparing.
+
+[Feature 20021209] On mail gateway systems, separation of inbound
+mail relay traffic from outbound traffic. This eliminates a problem
+where inbound mail deliveries could become resource starved in the
+presence of a high volume of outbound mail.
+
+[Feature 20021013] The body_checks_size_limit parameter limits the
+amount of text per message body segment (or attachment, if you
+prefer to use that term) that is subjected to body_checks inspection.
+The default limit is 50 kbytes. This speeds up the processing of
+mail with large attachments.
+
+[Feature 20020917] Speedups of regexp table lookups by optimizing
+for the $number substitutions that are actually present in the
+right-hand side.  Based on a suggestion by Liviu Daia.
+
+[Feature 20020917] Speedups of regexp and pcre tables, using
+IF..ENDIF support. Based on an idea by Bert Driehuis.  To protect
+a block of patterns, use:
+
+    if /pattern1/
+    /pattern2/	result2
+    /pattern3/	result3
+    endif
+
+IF..ENDIF can nest. Don't specify blanks at the beginning of lines
+inside IF..ENDIF, because lines beginning with whitespace are
+appended to the previous line. More details about the syntax are
+given in the pcre_table(5) and regexp_table(5) manual pages.
+
+[Feature 20020717] The default timeout for establishing an SMTP
+connection has been reduced to 30 seconds, because many system
+TCP/IP stacks have an atrociously large default timeout value.
+
+[Feature 20020505] Finer control over Berkeley DB memory usage,
+The parameter "berkeley_db_create_buffer_size" (default:  16 MBytes)
+specifies the buffer size for the postmap and postalias commands.
+The parameter "berkeley_db_read_buffer_size" (default:  128 kBytes)
+specifies the buffer size for all other applications.  Specify
+"berkeley_db_read_buffer_size = 1048576" to get the old read buffer
+size. Contributed by Victor Duchovni. For more information, see
+the last paragraphs of the DB_README file.
+
+[Incompat 20021211] The default process limit is doubled from 50
+to 100. The default limits on the number of active queue files or
+recipients are doubled from 10000 to 20000. The default concurrency
+for parallel delivery to the same destination is doubled from 10
+to 20.
+
+Improved compatibility
+======================
+
+[Feature 20020527] The Postfix SMTP client will now convert 8BITMIME
+mail to 7BIT when delivering to an SMTP server that does not announce
+8BITMIME support.  To disable, specify "disable_mime_output_conversion
+= yes". However, this conversion is required by RFC standards.
+
+[Feature 20020512] The Postfix SMTP and LMTP clients now properly
+pass on the MIME body type information (7BIT or 8BITMIME), provided
+that the sender properly specifies MIME body type information via
+the SMTP MAIL FROM command, via the sendmail -B command line option,
+or via MIME message headers. This includes mail that is returned
+as undeliverable.
+
+[Incompat 20020326] The Postfix SMTP client now breaks message
+header or body lines that are longer than $smtp_line_length_limit
+characters (default:  990). Earlier Postfix versions broke lines
+at $line_length_limit characters (default: 2048). Postfix versions
+before 20010611 did not break long lines at all.  Reportedly, some
+mail servers refuse to receive mail with lines that exceed the 1000
+character limit that is specified by the SMTP standard.
+
+[Incompat 20020326] The Postfix SMTP client now breaks long message
+header or body lines by inserting <CR> <LF> <SPACE>.  Earlier
+Postfix versions broke long lines by inserting <CR> <LF> only. This
+broke MIME encapsulation, causing MIME attachments to "disappear"
+with Postfix versions after 20010611.
+
+[Incompat 20020326] Postfix now discards text when a logical message
+header exceeds $header_size_limit characters (default: 102400).
+Earlier Postfix versions would place excess text, and all following
+text, in the message body. The same thing was done when a physical
+header line exceeded $line_length_limit characters (default: 2048).
+Both behaviors broke MIME encapsulation, causing MIME attachments
+to "disappear" with all previous Postfix versions.
+
+[Incompat 20021015] The Postfix LMTP client no longer lowercases email
+addresses in MAIL FROM and RCPT TO commands.
+
+[Incompat 20021013] The default Linux kernel lock style for mailbox
+delivery is changed from flock() to fcntl(). This has no impact if
+your system uses procmail for local delivery, if you use maildir-style
+mailboxes, or when mailbox access software locks mailboxes with
+username.lock files (which is usually the case with non-maildir
+mailboxes).
+
+Address classes
+===============
+
+[Feature 20021209] This release introduces the concept of address
+domain classes, each having its own default mail delivery transport:
+
+  Destination matches      Default transport       Default name
+  ==============================================================
+  $mydestination or
+     $inet_interfaces      $local_transport        local
+  $virtual_alias_domains   (not applicable)        (not applicable)
+  $virtual_mailbox_domains $virtual_transport      virtual
+  $relay_domains           $relay_transport        relay
+  other                    $default_transport      smtp
+
+The benefits of these changes are:
+
+- You no longer need to specify all the virtual(8) domains in the
+  Postfix transport map. The virtual(8) delivery agent has
+  become a first-class citizen just like local(8) or smtp(8).
+
+- On mail gateway systems, separation of inbound mail relay traffic
+  from outbound traffic. This eliminates a problem where inbound
+  mail deliveries could become resource starved in the presence of
+  a high volume of outbound mail.
+
+- The SMTP server rejects unknown recipients in a more consistent
+  manner than was possible with previous Postfix versions.
+
+See the ADDRESS_CLASS_README file for a description of address
+classes, their benefits, and their incompatibilities.
+
+New relay transport in master.cf
+================================
+
+[Incompat 20021209] Postfix no longer defaults to the "smtp"
+transport for all non-local destinations.  In particular, Postfix
+now uses the "relay" mail delivery transport for delivery to domains
+matching $relay_domains.  This may affect your defer_transports
+settings.
+
+On mail gateway systems, this allows us to separate inbound mail
+relay traffic from outbound traffic, and thereby eliminate a problem
+where inbound mail deliveries could become resource starved in the
+presence of a high volume of outbound mail.
+
+[Incompat 20021209] This release adds a new "relay" service to the
+Postfix master.cf file. This is a clone of the "smtp" service.  If
+your Postfix is unable to connect to the "relay" service then you
+have not properly followed the installation procedure.
+
+Revision of RBL blacklisting code
+=================================
+
+[Feature 20020923] Complete rewrite of the RBL blacklisting code.
+The names of RBL restrictions are now based on a suggestion that
+was made by Liviu Daia in October 2001. See conf/sample-smtpd.cf
+or html/uce.html for details.
+
+[Feature 20020923] "reject_rbl_client rbl.domain.tld" for client
+IP address blacklisting. Based on code by LaMont Jones.  The old
+"reject_maps_rbl" is now implemented as a wrapper around the
+reject_rbl_client code, and logs a warning that "reject_maps_rbl"
+is going away. To upgrade, specify "reject_rbl_client domainname"
+once for each domain name that is listed in maps_rbl_domains.
+
+[Feature 20020923] "reject_rhsbl_sender rbl.domain.tld" for sender
+domain blacklisting. Also: reject_rhsbl_client and reject_rhsbl_recipient
+for client and recipient domain blacklisting.
+
+[Feature 20020923] "rbl_reply_maps" configuration parameter for
+lookup tables with template responses per RBL server. Based on code
+by LaMont Jones.  If no reply template is found the default template
+is used as specified with the default_rbl_reply configuration
+parameter.  The template responses support $name expansion of
+client, helo, sender, recipient and RBL related attributes.
+
+[Incompat 20020923] The default RBL "reject" server reply now
+includes an indication of *what* is being rejected: Client host,
+Helo command, Sender address, or Recipient address. This also
+changes the logfile format.
+
+[Feature 20020923] "smtpd_expansion_filter" configuration parameter
+to control what characters are allowed in the expansion of template
+RBL reply $name macros. Characters outside the allowed set are
+replaced by "_".
+
+More sophisticated handling of UCE-related DNS lookup errors
+============================================================
+
+[Feature 20020906] More sophisticated handling of UCE-related DNS
+lookup errors.  These cause Postfix to not give up so easily, so
+that some deliveries will not have to be deferred after all.
+
+[Feature 20020906] The SMTP server sets a defer_if_permit flag when
+an UCE reject restriction fails due to a temporary (DNS) problem,
+to prevent unwanted mail from slipping through.  The defer_if_permit
+flag is tested at the end of the ETRN and recipient restrictions.
+
+[Feature 20020906] A similar flag, defer_if_reject, is maintained
+to prevent mail from being rejected because a whitelist operation
+(such as permit_mx_backup) fails due to a temporary (DNS) problem.
+
+[Feature 20020906] The permit_mx_backup restriction is made more
+strict. With older versions, some DNS failures would cause mail to
+be accepted anyway, and some DNS failures would cause mail to be
+rejected by later restrictions in the same restriction list.  The
+improved version will defer delivery when Postfix could make the
+wrong decision.
+
+- After DNS lookup failure, permit_mx_backup will now accept the
+request if a subsequent restriction would cause the request to be
+accepted anyway, and will defer the request if a subsequent
+restriction would cause the request to be rejected.
+
+- After DNS lookup failure, reject_unknown_hostname (the hostname
+given in HELO/EHLO commands) reject_unknown_sender_domain and
+reject_unknown_recipient_domain will now reject the request if a
+subsequent restriction would cause the request to be rejected
+anyway, and will defer the request if a subsequent restriction
+would cause the request to be accepted.
+
+[Feature 20020906] Specify "smtpd_data_restrictions =
+reject_unauth_pipelining" to block mail from SMTP clients that send
+message content before Postfix has replied to the SMTP DATA command.
+
+Other UCE related changes
+=========================
+
+[Feature 20020717] The SMTP server reject_unknown_{sender,recipient}_domain
+etc.  restrictions now also attempt to look up AAAA (IPV6 address)
+records.
+
+[Incompat 20020513] In order to allow user@domain@domain addresses
+from untrusted systems, specify "allow_untrusted_routing = yes" in
+main.cf.  This opens opportunities for mail relay attacks when
+Postfix provides backup MX service for Sendmail systems.
+
+[Incompat 20020514] For safety reasons, the permit_mx_backup
+restriction no longer accepts mail for user@domain@domain. To
+recover the old behavior, specify "allow_untrusted_routing = yes"
+and live with the risk of becoming a relay victim.
+
+[Incompat 20020509] The Postfix SMTP server no longer honors OK
+access rules for user@domain@postfix-style.virtual.domain, to close
+a relaying loophole with postfix-style virtual domains that have
+@domain.name catch-all patterns.
+
+[Incompat 20020201] In Postfix SMTPD access tables, Postfix now
+uses <> as the default lookup key for the null address, in order
+to work around bugs in some Berkeley DB implementations. This
+behavior is controlled with the smtpd_null_access_lookup_key
+configuration parameter.
+
+Changes in transport table lookups
+==================================
+
+[Feature 20020610] user@domain address lookups in the transport
+map.  This feature also understands address extensions.  Transport
+maps still support lookup keys in the form of domain names, but
+only with non-regexp tables.  Specify mailer-daemon@my.host.name
+in order to match the null address. More in the transport(5) manual
+page.
+
+[Feature 20020505] Friendlier behavior of Postfix transport tables.
+There is a new "*" wildcard pattern that always matches.  The
+meaning of null delivery transport AND nexhop information field
+has changed to "do not modify": use the information that would be
+used if the transport table did not exist. This change makes it
+easier to route intranet mail (everything under my.domain) directly:
+you no longer need to specify explicit "local" transport table
+entries for every domain name that resolves to the local machine.
+For more information, including examples, see the updated transport(5)
+manual page.
+
+[Incompat 20020610] Regexp/PCRE-based transport maps now see the
+entire recipient address instead of only the destination domain
+name.
+
+[Incompat 20020505, 20021215] The meaning of null delivery transport
+and nexhop fields has changed incompatibly.
+
+- A null delivery transport AND nexthop information field means
+"do not modify": use the delivery transport or nexthop information
+that would be used if no transport table did not exist.
+
+- The delivery transport is not changed with a null delivery
+transport field and non-null nexthop field.
+
+- The nexthop is reset to the recipient domain with a non-null
+transport field and a null nexthop information field.
+
+Address manipulation changes
+============================
+
+[Incompat 20020717] Postfix no longer strips multiple '.' characters
+from the end of an email address or domain name. Only one '.' is
+tolerated.
+
+[Feature 20020717] The masquerade_domains feature now supports
+exceptions.  Prepend a ! character to a domain name in order to
+not strip its subdomain structure.  More information in
+conf/sample-rewrite.cf.
+
+[Feature 20020717] The Postfix virtual delivery agent supports
+catch-all entries (@domain.tld) in lookup tables. These match users
+that do not have a specific user@domain.tld entry. The virtual
+delivery agent now ignores address extensions (user+foo@domain.tld)
+when searching its lookup tables, but displays the extensions in
+Delivered-To:  message headers.
+
+[Feature 20020610] user@domain address lookups in the transport
+map.  This feature also understands address extensions.  Transport
+maps still support lookup keys in the form of domain names, but
+only with non-regexp tables.  Specify mailer-daemon@my.host.name
+in order to match the null address. More in the transport(5) manual
+page.
+
+[Incompat 20020610] Regexp/PCRE-based transport maps now see the
+entire recipient address instead of only the destination domain
+name.
+
+[Incompat 20020513] In order to allow user@domain@domain addresses
+from untrusted systems, specify "allow_untrusted_routing = yes" in
+main.cf.  This opens opportunities for mail relay attacks when
+Postfix provides backup MX service for Sendmail systems.
+
+[Incompat 20020509] The Postfix SMTP server no longer honors OK
+access rules for user@domain@postfix-style.virtual.domain, to close
+a relaying loophole with postfix-style virtual domains that have
+@domain.name catch-all patterns.
+
+[Incompat 20020509] The appearance of user@domain1@domain2 addresses
+has changed.  In mail headers, such addresses are now properly
+quoted as "user@domain1"@domain2. As a side effect, this quoted
+form is now also expected on the left-hand side of virtual and
+canonical lookup tables, but only by some of the Postfix components.
+For now, it is better not to use user@domain1@domain2 address forms
+on the left-hand side of lookup tables.
+
+Regular expression and PCRE related changes
+===========================================
+
+[Feature 20021209] Regular expression maps are now allowed with
+local delivery agent alias tables and with all virtual delivery
+agent lookup tables.  However, regular expression substitution of
+$1 etc.  is still forbidden for security reasons.
+
+[Obsolete 20020917] In regexp lookup tables, the form /pattern1/!/pattern2/
+is going away. Use the cleaner and more flexible "if !/pattern2/..endif"
+form.  The old form still exists but is no longer documented, and
+causes a warning (suggesting to use the new format) to be logged.
+
+[Incompat 20020610] Regexp/PCRE-based transport maps now see the
+entire recipient address instead of only the destination domain
+name.
+
+[Incompat 20020528] With PCRE pattern matching, the `.' metacharacter
+now matches all characters including newline characters. This makes
+PCRE pattern matching more convenient to use with multi-line message
+headers, and also makes PCRE more compatible with regexp pattern
+matching.  The pcre_table(5) manual page has been greatly revised.
+
+New mail "HOLD" action and "hold" queue
+=======================================
+
+[Feature 20020819] New "hold" queue for mail that should not be
+delivered.  "postsuper -h" puts mail on hold, and "postsuper -H"
+releases mail, moving mail that was "on hold" to the deferred queue.
+
+[Feature 20020821] HOLD and DISCARD actions in SMTPD access tables.
+As with the header/body version of the same, these actions apply
+to all recipients of the same queue file.
+
+[Feature 20020819] New header/body HOLD action that causes mail to
+be placed on the "hold" queue. Presently, all you can do with mail
+"on hold" is to examine it with postcat, to take it "off hold" with
+"postsuper -H", or to destroy it with "postsuper -d". See
+conf/sample-filter.cf.
+
+[Incompat 20020819] In mailq output, the queue ID is followed by
+the ! character when the message is in the "hold" queue (see below).
+This may break programs that process mailq output.
+
+Content filtering
+=================
+
+[Feature 20020823] Selective content filtering. In in SMTPD access
+tables, specify "FILTER transport:nexthop" for mail that needs
+filtering. More info about content filtering is in the Postfix
+FILTER_README file.  This feature overrides the main.cf content_filter
+setting. Presently, this applies to all the recipients of a queue
+file.
+
+[Feature 20020527] Selective content filtering. In header/body_check
+patterns, specify "FILTER transport:nexthop" for mail that needs
+filtering. This requires different cleanup servers before and after
+the filter, with header/body checks turned off in the second cleanup
+server.  More info about content filtering is in the Postfix
+FILTER_README file.  This feature overrides the main.cf content_filter
+setting. Presently, this applies to all the recipients of a queue
+file.
+
+[Feature 20020527] Postfix now has real MIME support. This improves
+content filtering efficiency and accuracy, and improves inter-operability
+with mail systems that cannot receive 8-bit mail. See conf/sample-mime.cf
+for details.
+
+[Feature 20020527] Postfix header_checks now properly recognize
+MIME headers in attachments. This is much more efficient than
+previous versions that recognized MIME headers via body_checks.
+MIME headers are now processed one multi-line header at a time,
+instead of one body line at a time.  To get the old behavior,
+specify "disable_mime_input_processing = yes".  More details in
+conf/sample-filter.cf.
+
+[Feature 20020527] Postfix now has three classes of header patterns:
+header_checks (for primary message headers except MIME headers),
+mime_header_checks (for MIME headers), and nested_header_checks
+(for headers of attached email messages except MIME headers).  By
+default, all headers are matched with header_checks.
+
+[Feature 20021013] The body_checks_size_limit parameter limits the
+amount of text per message body segment (or attachment, if you
+prefer to use that term) that is subjected to body_checks inspection.
+The default limit is 50 kbytes. This speeds up the processing of
+mail with large attachments.
+
+[Feature 20020917] Speedups of regexp table lookups by optimizing
+for the $number substitutions that are actually present in the
+right-hand side.  Based on a suggestion by Liviu Daia.
+
+[Feature 20020917] Speedups of regexp and pcre tables, using
+IF..ENDIF support. Based on an idea by Bert Driehuis.  To protect
+a block of patterns, use:
+
+    if /pattern1/
+    /pattern2/	result2
+    /pattern3/	result3
+    endif
+
+IF..ENDIF can nest. Don't specify blanks at the beginning of lines
+inside IF..ENDIF, because lines beginning with whitespace are
+appended to the previous line. More details about the syntax are
+given in the pcre_table(5) and regexp_table(5) manual pages.
+
+Postmap/postalias/newaliases changes
+====================================
+
+[Incompat 20020505] The postalias command now copies the source
+file read permissions to the result file when creating a table for
+the first time. Until now, the result file was created with default
+read permissions.  This change makes postalias more similar to
+postmap.
+
+[Incompat 20020505] The postalias and postmap commands now drop
+super-user privileges when processing a non-root source file. The
+file is now processed as the source file owner, and the owner must
+therefore have permission to update the result file. Specify the
+"-o" flag to get the old behavior (process non-root files with root
+privileges).
+
+[Incompat 20020122] When the postmap command creates a non-existent
+result file, the new file inherits the group/other read permissions
+of the source file.
+
+Assorted changes
+================
+
+[Feature 20021028] The local(8) and virtual(8) delivery agents now record
+the original recipient address in the X-Original-To: message header.
+This header can also be emitted by the pipe(8) delivery agent.
+
+[Incompat 20021028] With "domain in one mailbox", one message with
+multiple recipients is no longer delivered only once. It is now
+delivered as one copy for each original recipient, with the original
+recipient address listed in the X-Original-To: message header.
+
+[Feature 20021024] New proxy_interfaces parameter, for sites behind a
+network address translation gateway or other type of proxy. You
+should specify all the proxy network addresses here, to avoid avoid
+mail delivery loops.
+
+[Feature 20021013] Updated MacOS X support by Gerben Wierda. See
+the auxiliary/MacOSX directory.
+
+[Incompat 20021013] Subtle change in ${name?result} macro expansions:
+the expansion no longer happens when $name is an empty string. This
+probably makes more sense than the old behavior.
+
+[Incompat 20020917] The relayhost setting now behaves as documented,
+i.e. you can no longer specify multiple destinations.
+
+[Incompatibility 20021219] The use of the XVERP extension in the
+SMTP MAIL FROM command is now restricted to SMTP clients that match
+the hostnames, domains or networks listed with the authorized_verp_clients
+parameter (default:  $mynetworks).
+
+[Feature 20020819] When the Postfix local delivery agent detects
+a mail delivery loop (usually the result of mis-configured mail
+pickup software), the undeliverable mail is now sent to the mailing
+list owner instead of the envelope sender address (usually the
+original poster who has no guilt, and who cannot fix the problem).
+
+[Warning 20020819] The Postfix queue manager now warns when mail
+for some destination is piling up in the active queue, and suggests
+a variety of remedies to speed up delivery (increase per-destination
+concurrency limit, increase active queue size, use a separate
+delivery transport, increase per-transport process limit).  The
+qmgr_clog_warn_time parameter controls the time between warnings.
+To disable these warnings, specify "qmgr_clog_warn_time = 0".
+
+[Warning 20020717] The Postfix SMTP client now logs a warning when
+the same domain is listed in main.cf:mydestination as well as a
+Postfix-style virtual map. Such a mis-configuration may cause mail
+for users to be rejected with "user unknown".
+
+[Feature 20020331] A new smtp_helo_name parameter that specifies
+the hostname to be used in HELO or EHLO commands; this can be more
+convenient than changing the myhostname parameter setting.
+
+[Feature 20020331] Choice between multiple instances of internal
+services:  bounce, cleanup, defer, error, flush, pickup, queue,
+rewrite, showq.  This allows you to use different cleanup server
+settings for different SMTP server instances.  For example, specify
+in the master.cf file:
+
+    localhost:10025 ... smtpd -o cleanup_service_name=cleanup2 ...
+    cleanup2        ... cleanup -o header_checks= body_checks= ...
+
+Logfile format changes
+======================
+
+[Incompat 20021209] The Postfix SMTP client no longer expands CNAMEs
+in MAIL FROM addresses (as permitted by RFC 2821) before logging
+the recipient address.
+
+[Incompat 20021028] The Postfix SMTP server UCE reject etc. logging
+now includes the queue ID, the mail protocol (SMTP or ESMTP), and
+the hostname that was received with the HELO or EHLO command, if
+available.
+
+[Incompat 20021028] The Postfix header/body_checks logging now
+includes the mail protocol (SMTP, ESMTP, QMQP) and the hostname
+that was received with the SMTP HELO or EHLO command, if available.
+
+[Incompat 20021028] The Postfix status=sent/bounced/deferred logging
+now shows the original recipient address (as received before any
+address rewriting or aliasing).  The original recipient address is
+logged only when it differs from the final recipient address.
+
+[Incompat 20020923] The default RBL "reject" server reply now
+includes an indication of *what* is being rejected: Client host,
+Helo command, Sender address, or Recipient address. This also
+changes the logfile format.
+
+LDAP related changes
+====================
+
+[Incompat 20020819] LDAP API version 1 is no longer supported. The
+memory allocation and deallocation strategy has changed too much
+to maintain both version 1 and 2 at the same time.
+
+[Feature 20020513] Updated LDAP client module with better handling
+of dead LDAP servers, and with configurable filtering of query
+results.
+
+SASL related changes
+====================
+
+[Incompat 20020819] The smtpd_sasl_local_domain setting now defaults
+to the null string, rather than $myhostname. This seems to work
+better with Cyrus SASL version 2. This change may cause incompatibility
+with the saslpasswd2 command.
+
+[Feature 20020331] Support for the Cyrus SASL version 2 library,
+contributed by Jason Hoos. This adds some new functionality that
+was not available in Cyrus SASL version 1, and provides bit-rot
+insurance for the time when Cyrus SASL version 1 eventually stops
+working.
+
+Berkeley DB related changes
+===========================
+
+[Feature 20020505] Finer control over Berkeley DB memory usage,
+The parameter "berkeley_db_create_buffer_size" (default:  16 MBytes)
+specifies the buffer size for the postmap and postalias commands.
+The parameter "berkeley_db_read_buffer_size" (default:  256 kBytes)
+specifies the buffer size for all other applications.  Specify
+"berkeley_db_read_buffer_size = 1048576" to get the old read buffer
+size. For more information, see the last paragraphs of the DB_README
+file.
+
+[Incompat 20020201] In Postfix SMTPD access tables, Postfix now
+uses <> as the default lookup key for the null address, in order
+to work around bugs in some Berkeley DB implementations. This
+behavior is controlled with the smtpd_null_access_lookup_key
+configuration parameter.
+
+[Incompat 20020201] Postfix now detects if the run-time Berkeley
+DB library routines do not match the major version number of the
+compile-time include file that was used for compiling Postfix. The
+software issues a warning and aborts in case of a discrepancy. If
+it didn't, the software was certain to crash with a segmentation
+violation.
+
+Assorted workarounds
+====================
+
+[Incompat 20020201] On SCO 3.2 UNIX, the input rate flow control
+is now turned off by default, because of limitations in the SCO
+UNIX kernel.
--- a/RELEASE_NOTES-2.1
+++ b/RELEASE_NOTES-2.1
@ -0,0 +1,581 @@
+In the text below, incompatible changes are labeled with the Postfix
+snapshot that introduced the change. If you upgrade from a later
+Postfix version, then you do not have to worry about that particular
+incompatibility.
+
+The official Postfix release is called 2.1.x where 2=major release
+number, 1=minor release number, x=patchlevel.  Snapshot releases
+are called 2.2-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day).  The mail_release_date configuration parameter
+contains the release date (both for official release and snapshot
+release).  Patches are issued for the official release and change
+the patchlevel and the release date. Patches are never issued for
+snapshot releases.
+
+Major changes - critical
+------------------------
+
+If you run Postfix 2.0 or earlier then you must stop Postfix before
+upgrading. The master-child protocols have changed between Postfix
+1.1 and 2.0, and version 2.1 sometimes writes queue files that the
+2.0 and earlier queue managers complain about. If this happens move
+the files from the corrupt directory to the maildrop directory and
+give them another chance.
+
+[Incompat 20021119] The Postfix upgrade procedure will add two new
+services to your master.cf file: "trace" and "verify". These servers
+can run inside a chroot jail, have no interaction with users, and
+don't talk to the network.  If Postfix complains that "trace" and
+"verify" are not found, you made the error of copying your old
+Postfix configuration files over the new ones. Execute "postfix
+upgrade-configuration" to repair the Postfix configuration files.
+
+[Incompat 20040331] Support for the non-standard Errors-To:  message
+header is removed.  This also helps to stop potential attacks that
+rely on bouncing mail to a destination that is not directly reachable
+by the attacker. Specify "enable_errors_to = yes" to get the old
+behavior.
+
+Queue files written by Postfix 2.1 may contain information that
+is incompatible with older Postfix versions:
+
+[Incompat 20040120] Queue files creates with "sendmail -v" are no
+longer compatible with Postfix versions 2.0 and earlier. A new
+record type, "killed", was introduced in order to avoid repeated
+mail delivery reports from mail that could not be delivered due to
+a temporary error condition.
+
+[Incompat 20030125] This release adds a new queue file record type
+for the address specified in "REDIRECT user@domain" actions in
+access maps or header/body_checks. Queue files with these records
+will be rejected by older Postfix versions.
+
+[Feature 20040120] The new queue manager nqmgr has become the
+default qmgr queue manager. For a limited time the old queue manager
+remains available under the name oqmgr. The name nqmgr still works
+but will cause a warning to be logged.
+
+[Incompat 20040413] The Postfix SMTP server no longer accepts mail
+from or to an address ending in "@", including address forms that
+rewrite into an address that ends in "@"). Specify "resolve_null_domain
+= yes" to get the old behavior.
+
+[Incompat 20031226] Postfix no longer allows mail addresses with
+bare numeric IP addresses (user@1.2.3.4).  This is not configurable.
+The form user@[ipaddress] is still allowed.
+
+[Incompat 20031226] Bounce messages now have a separate queue life
+time.  This is controlled by the bounce_queue_lifetime parameter.
+
+[Incompat 20031019] The authorized_verp_clients parameter was
+renamed to smtpd_authorized_verp_clients, and the default value
+was changed to disable this feature. You now have to turn it on
+explicitly.
+
+Major changes - build environment
+---------------------------------
+
+[Incompat 20030112] The Postfix build procedure now uses the
+pcre-config utility (part of PCRE version 3) to find out the
+pathnames of the PCRE include file and object library, instead of
+probing /usr/include and/or /usr/lib. To build with PCRE version
+2 support you will have to specify pathnames as described in
+PCRE_README. To build without PCRE support, specify:  make Makefiles
+CCARGS="-DNO_PRCE".
+
+Major changes - documentation
+-----------------------------
+
+[Feature 20040331] Complete documentation rewrite. All parameters
+are now described in postconf(5), and all commands and daemons are
+shown in their proper context in the OVERVIEW document.
+- All documents come as HTML and ASCII text.
+- All HTML documents have hyperlinks for every parameter name,
+  for every Postfix manual page, and for every README file.  
+- All documents specify what feature is available in what release. 
+- The sample-*.cf configuration files no longer exist. The information
+  is now available in HTML documents, README files and UNIX man pages).
+- The mumble_table example configuration files no longer exist.
+
+[Incompat 20040413] The LMTP, Cyrus and Qmail related README files will
+not be included in the Postfix version 2.1 distribution. They will
+be made available via http://www.postfix.org/, and in Postfix 2.2
+snapshots.
+
+[Feature 20040413] You can install documentation in HTML format
+besides the README files.  Installation of README files is now
+optional.
+
+Major changes - access control
+------------------------------
+
+[Feature 20031215] Easier debugging of SMTPD access restrictions.
+The SMTP command "xclient name=xxx addr=yyy" changes Postfix's idea
+of the remote client name and address, so that you can pretend to
+connect from anywhere on the Internet.  Use of this command is
+restricted to clients that match the list of names or addresses
+specified with the smtpd_authorized_xclient_hosts parameter.  By
+default, XCLIENT is not accepted from anywhere.  More details are
+in the XCLIENT_README file.
+
+[Feature 20030715] Support for multi-valued RBL lookup results.
+For example, specify "reject_rbl_client foo.bar.tld=127.0.0.3" to
+reject clients that are listed with a "127.0.0.3" address record.
+More information is in the postconf(5) manual page.
+
+[Feature 20030917] New "check_{helo,sender,recipient}_{ns,mx}_access
+type:table" restrictions that apply the specified access table to
+the NS or MX hosts of the host/domain given in HELO, EHLO, MAIL
+FROM or RCPT TO commands. More information is in the postconf(5)
+manual page.
+
+This can be used to block mail from so-called spammer havens (all
+domains that are served by the same DNS server, all domains that
+resolve to the same MX host), from sender addresses that resolve
+to Verisign's wild-card mail responder, or from domains that claim
+to have mail servers in reserved networks such as 127.0.0.1.
+
+Note: OK actions are not allowed for security reasons.  Instead of
+OK, use DUNNO in order to exclude specific hosts from blacklists.
+If an OK result is found for an NS or MX host, Postfix rejects the
+SMTP command with "451 Server configuration error".
+
+[Feature 20040413] Support for a "WARN text..." feature in SMTPD
+access tables, just like the WARN feature in header/body_checks.
+
+[Feature 20040122] New "PREPEND headername: headervalue" action in
+Postfix access maps. Primarily intended for tagging mail by for
+example, an external SMTPD policy server. See access(5).
+
+[Feature 20040124] New "PREPEND text" action in Postfix header/body_checks
+maps. This action prepends a header or body line immediately before
+the line that triggers the action. See header_checks(5) for details.
+
+[Feature 20030125] New "REDIRECT user@domain" action for access
+maps and header/body_checks that overrides all the originally
+specified recipients of a message.  Wietse would never recommend
+that people use this to redirect (bounced) SPAM to the beneficiaries
+of an advertisement campaign. See access(5) and header_checks(5).
+
+[Feature 20031215] The reject_sender_login_mismatch feature (used
+with SASL authenticated logins) is now implemented in terms of more
+basic restrictions:  reject_unauth_sender_login_mismatch (reject
+mail when $sender_login_maps lists an owner for the sender address
+but the SMTP client is not SASL authenticated) and
+reject_auth_sender_login_mismatch (reject mail when the sender
+address is not owned by the SASL authenticated user). The
+sender_login_maps now support multiple owners per sender address.
+See postconf(5) for details.
+
+Major changes - address verification
+------------------------------------
+
+[Feature 20021119] Address verification blocks mail from or to
+addresses that are not deliverable.  This is turned on with the
+reject_unverified_sender UCE restriction. Addresses are verified
+by probing, that is, by sending mail that is not actually delivered
+(SMTP interruptus).  Detailed information is in the
+ADDRESS_VERIFICATION_README file.
+
+Address verification can follow a different route than ordinary
+mail, typically to avoid sending probes to a relay host.  To make
+this possible, the address resolver supports multiple personalities.
+For more detail see the ADDRESS_VERIFICATION_README file.
+
+New "sendmail -bv" option.  Postfix probes the specified recipient
+addresses without actually delivering mail, and sends back an email
+delivery report.  This is useful for testing address rewriting and
+address routing, and shows the final envelope and header addresses.
+This feature currently does not access or update the sender address
+verification database.
+
+Major changes - content inspection
+----------------------------------
+
+[Feature 20030704] The Postfix SMTP server can be configured to
+send all mail into a real-time content filter that inspects mail
+BEFORE it is queued.  See the SMTPD_PROXY_README file for details.
+
+[Feature 20031022] Improved logging by Postfix daemons behind an
+SMTP-based proxy filter. The logging now shows the remote client
+name and address, instead of localhost[127.0.0.1].  This uses the
+new SMTP command "XFORWARD addr=client-address name=client-hostname",
+which specifies remote client information for logging purposes.
+This command is restricted to clients that match the list of names
+or addresses specified with the smtpd_authorized_xforward_hosts
+parameter. By default, XFORWARD is not accepted from anywhere.
+For an example, see the SMTPD_PROXY_README file.
+
+[Feature 20030706] New receive_override_options parameter that
+eliminates the need for different cleanup service instances before
+and after an external content filter. One parameter controls what
+happens before or after the content filter: rejecting unknown
+recipients, canonical mapping, virtual alias expansion, masquerading,
+automatic BCC recipients and header/body checks. See postconf(5)
+for the fine details.
+
+[Feature 20040124] New "PREPEND text" action in Postfix header/body_checks
+maps. This action prepends a header or body line immediately before
+the line that triggers the action. See header_checks(5) for details.
+
+[Feature 20030125] New "REDIRECT user@domain" action for access maps
+and header/body_checks that overrides all the originally specified
+recipients of a message.  Wietse would never recommend that people
+use this to redirect (bounced) SPAM to the beneficiaries of an
+advertisement campaign. See header_checks(5) and access(5).
+
+[Incompat 20030915] In header/body_checks actions, the OK action
+is being phased out, and the DUNNO action is being phased in. Both
+actions still work and do the same thing, but hopefully DUNNO causes
+less confusion. See header_checks(5) for details.
+
+Major changes - policy delegation
+---------------------------------
+
+[Feature 20030715] Support for SMTP access policy delegation to an
+external server.  Greylisting and SPF are provided as examples.
+See the SMTPD_POLICY_README file for further information.
+
+Major changes - client rate limiting
+------------------------------------
+
+Note: this feature is not included with Postfix 2.1, but it is
+documented here so that the information will not be lost.
+
+[Feature 20031111] Preliminary defense against SMTP clients that
+hammer an SMTP server with too many connections.  By default, the
+number of simultaneous connections per client is limited to half
+the default process limit, and no limit is imposed on the number
+of successive connections per time unit that a client is allowed
+to make.
+
+The new anvil server maintains the connection statistics, and logs
+the maximum connection count and connection rate per client every
+anvil_status_update_time seconds (10 minutes), or when it terminates
+(when there is no work to be done, or when "postfix reload" was
+issued). Once you have an idea what the numbers look like, you can
+clamp down the limits for your system.
+
+The relevant main.cf configuration parameters are: smtpd_client-
+connection_count_limit for the number of simultaneous connections
+per client, and smtpd_client_connection_rate_limit for the number
+of successive connections per unit time and client. The time unit
+is specified with the anvil_rate_time_unit parameter, and is one
+minute by default.
+
+When Postfix rejects a client, it sends a 450 status code and
+disconnects, and logs a warning with the client name/address and
+the service name from master.cf. You can, for example, capture this
+information with a logfile watching program that updates a firewall
+rule (such a watcher program is not included with Postfix).
+
+To avoid rejecting authorized hosts, the smtpd_client_connection-
+limit_exceptions parameter takes a list of network/netmask expressions,
+hostnames or .domain names that are excluded from these restrictions.
+By default, all clients in $mynetworks are excluded; you will
+probably want to use a more restrictive setting.
+
+For further information, see:  smtpd(8) and anvil(8).
+
+Major changes - configuration management
+----------------------------------------
+
+[Feature 20040413] New postfix(1) command features: 
+
+- "postfix set-permissions" corrects Postfix file and directory
+   permissions and allows you to change mail_owner or setgid_group
+   settings after Postfix is installed.
+
+- "postfix upgrade-configuration" fixes Postfix systems after people
+   copy over their old configuration files after installing a new
+   Postfix system.
+
+See postfix(1) for details.
+
+[Incompat 20040120] The format of the postfix-files file has changed.
+There is a new type for hard links. With hard or symbolic link
+entries, the first field is now the destination pathname and the
+"owner" field is now the origin pathname, while "group" and
+"permissions" are ignored.
+
+Major changes - core functionality
+----------------------------------
+
+[Feature 20030704] New enable_original_recipient parameter (default:
+yes) to control whether Postfix keeps track of original recipient
+address information.  If this is turned off Postfix produces no
+X-Original-To: headers and ignores the original recipient when
+eliminating duplicates after virtual alias expansion. Code by Victor
+Duchovni.
+
+[Feature 20030417] Automatic BCC recipients depending on sender or
+recipient address.  The configuration parameters in question are
+"sender_bcc_maps" and "recipient_bcc_maps". See postconf(5).
+
+[Incompat 20030415] Too many people mess up their net/mask patterns,
+causing open mail relay problems. Postfix processes now abort when
+given a net/mask pattern with a non-zero host portion (for example,
+168.100.189.2/28), and suggest to specify the proper net/mask
+pattern instead (for example, 168.100.189.0/28).
+
+[Feature 20030415] Workaround for file system clock drift that
+caused Postfix to ignore new mail (this could happen with file
+systems mounted from a server).  Postfix now logs a warning and
+proceeds with only slightly reduced performance, instead of ignoring
+new mail.
+
+Major changes - database support
+--------------------------------
+
+Liviu Daia took the lead in a revision of the LDAP, MySQL and
+PostgreSQL clients.  Credits also go to Victor Duchovni and to
+Lamont Jones.
+
+[Feature 20030915] LDAP parameters can now be defined in external
+files.  Specify the LDAP maps in main.cf as
+	ldap:/path/to/ldap.cf
+and write the LDAP parameters in /path/to/ldap.cf, without the
+"ldapsource_" prefix.  This makes it possible to securely store
+bind passwords for plain auth outside of main.cf (which must be
+world readable).  The old syntax still works, for backwards
+compatibility. 
+
+[Feature 20030915] Support for LDAP URLs in the LDAP parameter
+"server_host", if Postfix is linked against OpenLDAP.  LDAP hosts,
+ports, and connection protocols to be used as LDAP sources can be
+specified as a blank-separated list of LDAP URLs in "server_host".
+As with OpenLDAP, specifying a port in a LDAP URL overrides
+"server_port".  Examples:
+    server_host = ldap://ldap.itd.umich.edu
+    server_host = ldaps://ldap.itd.umich.edu:636
+    server_host = ldapi://%2Fsome%2Fpath
+
+[Feature 20030915] The LDAP SSL scheme ldaps:// is available if
+OpenLDAP was compiled with SSL support.  New parameters "tls_ca_cert_dir",
+"tls_ca_cert_file", "tls_cert", "tls_key", "tls_require_cert",
+"tls_random_file", "tls_cipher_suite" control the certificates,
+source of random numbers, and cipher suites used for SSL connections.
+See LDAP_README for further information.
+
+[Feature 20030915] Support for STARTTLS command in LDAP, if Postfix
+is linked against OpenLDAP and OpenLDAP was compiled with SSL
+support.  STARTTLS is controlled by the "start_tls" parameter.
+The above parameters for certificates, source of random numbers,
+and cipher suites also apply.  See LDAP_README for further information.
+
+[Incompat 20030704] Support for client side LDAP caching is gone.
+OpenLDAP 2.1.13 and later no longer support it, and the feature
+never worked well.  Postfix now ignores cache controlling parameters
+in an LDAP configuration file and logs a warning.
+
+[Feature 20030415] PostgreSQL table lookups. Specify "pgsql:/file/name"
+where "/file/name" defines the database. See "man pgsql_table" for
+examples, and the PGSQL_README file for general information.
+
+Major changes - internals
+-------------------------
+
+[Incompat 20040120] The format of the postfix-files file has changed.
+There is a new type for hard links. With hard or symbolic link
+entries, the first field is now the destination pathname and the
+"owner" field is now the origin pathname, while "group" and
+"permissions" are ignored.
+
+[Incompat 20040120] The LDAP and SQL client source code is moved
+to the global directory in order to eliminate reversed dependencies.
+
+[Feature 20030606] Complete rewrite of the queue file record reading
+loops in the pickup, cleanup and in the queue manager daemons. This
+code had deteriorated over time.  The new code eliminates an old
+problem where the queue manager had to read most queue file records
+twice in the case of an alias/include file expansion with more than
+qmgr_message_recipient_limit recipients.
+
+[Feature 20030125] Code cleanup up of queue manager internals.
+Queue names are no longer mixed up with the next-hop destination,
+and the address resolver loop is now easier to understand.
+
+[Feature 20030104] Multi-server daemons (servers that accept
+simultaneous connections from multiple clients) will now stop
+accepting new connections after serving $max_use clients. This
+allows multi-server daemons to automatically restart even on busy
+mail systems.
+
+[Feature 20030104] Clients of multi-server daemons such as
+trivial-rewrite and the new proxymap service now automatically
+disconnect after $ipc_ttl seconds of activity (default: 1000s).
+This allows multi-server daemons to automatically restart even on
+busy mail systems.
+
+[Incompat 20021119] The file format of bounce/defer logfiles has
+changed from the old one-line ad-hoc format to a more structured
+multi-line format. For backwards compatibility, Postfix now creates
+bounce/defer logfile entries that contain both the old and the new
+format, so that you can go back to an older Postfix release without
+losing information.  Old Postfix versions will warn about malformed
+logfile entries, but should work properly. To disable backwards
+compatibility specify "backwards_bounce_logfile_compatibility =
+no" in main.cf.
+
+[Feature 20021119] Both "sendmail -bv" and "sendmail -v" use the
+new "trace" daemon that is automatically added to master.cf when
+you upgrade.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20040413] The postmap and postalias commands now report
+errors to syslogd in addition to reporting them to the standard
+error output. This makes logfile analysis easier.
+
+[Incompat 20031203] Many SMTPD "reject" logfile entries now show
+NOQUEUE instead of a queue ID.  This is because Postfix no longer
+creates a queue file before the SMTP server has received a valid
+recipient.
+
+Major changes - lookup table support
+------------------------------------
+
+[Feature 20030704] New CIDR-based lookup table, remotely based on
+code by Jozsef Kadlecsik.  For details and examples, see "man
+cidr_table".
+
+[Feature 20030704] The TCP-based table lookup protocol is finished.
+For details and examples, see "man tcp_table". This will allow you
+to implement your own greylisting, or to do your own open proxy
+tests before accepting mail. This table will not be included with
+Postfix 2.1 because the protocol is obsoleted by the policy delegation
+(see elsewhere in this document) which does a much better job.
+
+[Feature 20030704] Support for !/pattern/ (negative matches) in
+PCRE lookup tables by Victor Duchovni. See "man pcre_table" and
+"man regexp_table" for more.
+
+Major changes - resource control
+--------------------------------
+
+[Incompat 20031022] The Postfix SMTP server no longer accepts mail
+when the amount of free queue space is less than 1.5 times the
+message_size_limit value.
+
+Major changes - security
+------------------------
+
+[Incompat 20040413] The Postfix SMTP server no longer accepts mail
+from or to an address ending in "@", including address forms that
+rewrite into an address that ends in "@"). Specify "resolve_null_domain
+= yes" to get the old behavior.
+
+[Incompat 20040331] Support for the non-standard Errors-To:  message
+header is removed.  This also helps to stop potential attacks that
+rely on bouncing mail to a destination that is not directly reachable
+by the attacker. Specify ""enable_errors_to = yes" to get the old
+behavior.
+
+[Incompat 20040331] Tarpit delays are reduced. The Postfix SMTP
+server no longer delays responses until the client has made
+$smtpd_soft_error_limit errors, and the delay is fixed at
+$smtpd_error_sleep_time seconds.  Postfix still disconnects after
+$smtpd_hard_error_limit errors.
+
+[Incompat 20040120] The SMTP server can reject non-existent sender
+addresses in a local, virtual or relay domain; specify
+"reject_unlisted_sender=yes" in order to require that a sender
+address passes the same "user unknown" test as a recipient would
+have to pass. This is optional in Postfix 2.1, likely to be turned
+on by default in Postfix 2.2.
+
+[Incompat 20031226] Postfix no longer allows mail addresses with
+bare numeric IP addresses (user@1.2.3.4).  This is not configurable.
+The form user@[ipaddress] is still allowed.
+
+[Incompat 20030305] Postfix truncates non-address information in message
+address headers (comments, etc.) to 250 characters per address, in
+order to protect vulnerable Sendmail systems against exploitation
+of a remote buffer overflow problem (CERT advisory CA-2003-07).
+
+[Incompat 20030227] The smtpd_hard_error_limit and smtpd_soft_error_limit
+values now behave as documented, that is, smtpd_hard_error_limit=1
+causes Postfix to disconnect upon the first client error. Previously,
+there was an off-by-one error causing Postfix to change behavior
+after smtpd_hard/soft_error_limit+1 errors.
+
+Major changes - smtp client
+---------------------------
+
+[Incompat 20031223] The SMTP client now tries to connect to an
+alternate MX address when a delivery attempt fails **after the
+initial SMTP handshake**.  This includes both broken connections
+and 4XX SMTP replies.  To get the old behavior, specify
+"smtp_mx_session_limit = 1" in main.cf.
+
+[Feature 20031223] The SMTP client now tries to connect to an
+alternate MX address when a delivery attempt fails after the
+initial SMTP handshake.  This includes both broken connections
+and 4XX SMTP replies.
+
+As a benefit, fallback_relay now works as promised, not just for
+sessions that fail during the initial handshake.
+
+The new SMTP client connection management is controlled by two new
+configuration parameters:
+
+- smtp_mx_address_limit (default unlimited): the number of MX (mail
+  exchanger) IP addresses that can result from mail exchanger
+  lookups.
+
+- smtp_mx_session_limit (default 2):  the number of SMTP sessions
+  per delivery request before giving up or delivering to a fall-back
+  relay, ignoring IP addresses that fail to complete the SMTP
+  initial handshake.
+
+[Incompat 20031022] Postfix no longer retries delivery when no MX
+host has a valid A record, for compatibility with many other MTAs.
+This change is made in anticipation of a possible Verisign "wild-card
+MX record without A record" for unregistered domains. To get the
+old behavior, specify "smtp_defer_if_no_mx_address_found = yes".
+
+[Incompat 20031022] The Postfix SMTP client no longer looks in
+/etc/hosts by default.  To get the old behavior, specify
+"smtp_host_lookup = dns, native".
+
+[Feature 20030417] Support for sending mail to hosts not in the
+DNS, without having to turn off DNS lookups. The "smtp_host_lookup"
+parameter controls how the Postfix SMTP client looks up hosts.  In
+order to use /etc/hosts besides DNS, specify "smtp_host_lookup =
+dns, native". The default is to use DNS only.
+
+Major changes - user interface
+------------------------------
+
+[Incompat 20040418] The non-delivery report format has changed.
+The "sorry" message and the DSN formatted report now include the
+original recipient address, when that address is different from
+the final recipient address.  This makes it easier to diagnose some
+mail delivery problems that happen after mail forwarding.
+
+[Incompat 20031223] In mailq (queue listing) output, there no longer
+is space between a short queue ID and the "*" (delivery in progress)
+or ! (mail on hold) status indicator. This makes the output easier
+to parse.
+
+[Incompat 20030417] "sendmail -t" no longer complains when recipients
+are given on the command line. Instead, it now adds recipients from
+headers to the recipients from the command-line.
+
+[Incompat 20030126] The maildir file naming algorithm has changed
+according to an updated version of http://cr.yp.to/proto/maildir.html.
+The name is now TIME.VdevIinum.HOST
+
+[Incompat 20021119] The behavior of "sendmail -v" has changed. One
+-v option now produces one email report with the status of each
+recipient.  Multiple -v options behave as before: turn on verbose
+logging in the sendmail and postdrop commands.
+
+[Feature 20021119] New "sendmail -bv" option.  Postfix probes the
+specified recipient addresses without actually delivering mail,
+and sends back an email delivery report.  This is useful for testing
+address rewriting and address routing of both envelope and header
+addresses. This feature currently does not access or update the
+sender address verification database.
+
--- a/RELEASE_NOTES-2.10
+++ b/RELEASE_NOTES-2.10
@ -0,0 +1,268 @@
+The stable Postfix release is called postfix-2.10.x where 2=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-2.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 2.8 or earlier, read RELEASE_NOTES-2.9
+before proceeding.
+
+Major changes - laptop-friendliness
+-----------------------------------
+
+[Incompat 20120924] Postfix no longer uses FIFOs to emulate UNIX-domain
+sockets on Solaris 9 (Vintage 2002!) and later. If you install
+Postfix for the first time on an older Solaris system, edit the
+master.cf file and replace "unix" with "fifo" for the pickup and
+qmgr services.
+
+[Feature 20120924] the default master.cf file now uses "unix" instead
+of "fifo" for the pickup and qmgr services. This avoids periodic
+disk drive spin-up.
+
+Major changes - permit logging
+------------------------------
+
+[Feature 20120303] [Feature 20120303] New control for "permit"
+logging in smtpd_mumble_restrictions (by default, the SMTP server
+logs "reject" actions but not "permit" actions).  Specify
+"smtpd_log_access_permit_actions = static:all" to log all "permit"-style
+actions, or specify a list of explicit action names.  More details
+are in the postconf(5) manpage.  
+
+Major changes - postconf
+------------------------
+
+[Incompat 20121224] The postconf command produces more warnings:
+
+- An attempt to modify a read-only parameter (process_name, process_id)
+  in main.cf or master.cf.
+
+- An undefined $name in a parameter value in main.cf or master.cf
+  (except for backwards-compatibility parameters such as $virtual_maps).
+
+[Feature 20121224] The postconf command has been updated to make
+trouble-shooting (and support) easier. In summary, use "postconf
+-Mxf" and "postconf -nxf" to review master.cf and main.cf parameter
+settings with expanded parameter values.
+
+- "postconf -x" now expands $name in main.cf and master.cf parameter
+  values.
+
+- postconf warns about attempts to modify a read-only parameter
+  (process_name, process_id) in main.cf or master.cf.
+
+- postconf warns about an undefined $name in a parameter value in
+  main.cf or master.cf (except for backwards-compatibility parameters
+  such as $virtual_maps).
+
+[Feature 20121227]
+
+- "postconf -o name=value" overrides main.cf parameter settings.
+  This can be used, for example, to examine stress-dependent settings
+  with "postconf -x -o stress=yes".
+
+Major changes - postscreen
+--------------------------
+
+[Incompat 20121123] The postscreen deep protocol tests now log the
+last command before a protocol error ("UNIMPLEMENTED" when the last
+command is not implemented, "CONNECT" when there was no prior
+command). The changed logfile messages are:
+
+NON-SMTP COMMAND from [address]:port after command: text
+BARE NEWLINE from [address]:port after command
+COMMAND TIME LIMIT from [address]:port after command
+COMMAND COUNT LIMIT from [address]:port after command
+COMMAND LENGTH LIMIT from [address]:port after command
+
+Major changes - load-balancer support
+-------------------------------------
+
+[Incompat 20120625] The postscreen(8)-to-smtpd(8) protocol has
+changed.  To avoid "cannot receive connection attributes" warnings
+and dropped connections, execute the command "postfix reload". No
+mail will be lost as long as the remote SMTP client tries again
+later.
+
+[Feature 20120625] Support for upstream proxy agent in the postscreen(8)
+and smtpd(8) daemons.  To enable the haproxy protocol, specify one
+of the following:
+
+    postscreen_upstream_proxy_protocol = haproxy
+    smtpd_upstream_proxy_protocol = haproxy
+
+Note 1: smtpd_upstream_proxy_protocol can't be used in smtpd processes
+that are behind postscreen. Configure postscreen_upstream_proxy_protocol
+instead.
+
+Note 2: To use the nginx proxy with smtpd(8), enable the XCLIENT
+protocol with smtpd_authorized_xclient_hosts. This supports SASL
+authentication in the proxy agent (Postfix 2.9 and later).
+
+Major changes - relay safety
+----------------------------
+
+[Incompat 20130613] New smtpd_relay_restrictions parameter built-in
+default settings:
+
+    smtpd_relay_restrictions = 
+	permit_mynetworks 
+	permit_sasl_authenticated 
+	defer_unauth_destination
+
+This safety net prevents open relay problems due to mistakes
+with spam filter rules in smtpd_recipient_restrictions.
+
+If your site has a complex mail relay policy configured under
+smtpd_recipient_restrictions, this safety net may defer mail that
+Postfix should accept.
+
+To fix this safety net, take one of the following actions:
+
+- Set smtpd_relay_restrictions empty, and keep using the existing
+  mail relay authorization policy in smtpd_recipient_restrictions.
+
+- Copy the existing mail relay authorization policy from
+  smtpd_recipient_restrictions to smtpd_relay_restrictions.
+
+There is no need to change the value of smtpd_recipient_restrictions.
+
+[Feature 20130613] This version introduces the smtpd_relay_restrictions
+feature for mail relay control. The new built-in default settings
+are:
+
+    smtpd_relay_restrictions = 
+	permit_mynetworks 
+ 	permit_sasl_authenticated
+	defer_unauth_destination
+
+    smtpd_recipient_restrictions =
+	( optional spam blocking rules would go here )
+
+For comparison, this is the Postfix before 2.10 default:
+
+    smtpd_recipient_restrictions =
+	permit_mynetworks 
+	reject_unauth_destination
+	( optional spam blocking rules would go here )
+
+With Postfix versions before 2.10, the mail relay policy and spam
+blocking policy were combined under smtpd_recipient_restrictions,
+resulting in error-prone configuration.
+
+As of Postfix 2.10, the mail relay policy is preferably implemented
+with smtpd_relay_restrictions, so that a permissive spam blocking
+policy under smtpd_recipient_restrictions will not unexpectedly
+result in a permissive mail relay policy.
+
+As of Postfix 2.10.0 the smtpd_relay_restrictions parameter built-in
+default settings are:
+
+    smtpd_relay_restrictions =
+        permit_mynetworks
+        permit_sasl_authenticated
+        defer_unauth_destination
+
+If your site has a complex mail relay policy configured under
+smtpd_recipient_restrictions, this safety net may defer mail that
+Postfix should accept.
+
+To migrate from an earlier Postfix release with the least amount
+of pain:
+
+- Set smtpd_relay_restrictions empty, and keep using the existing
+  mail relay authorization policy in smtpd_recipient_restrictions.
+
+- There is no need to change the value of smtpd_recipient_restrictions.
+
+To take advantage of the new smtpd_relay_restrictions feature:
+
+- Copy the existing mail relay authorization policy from
+  smtpd_recipient_restrictions to smtpd_relay_restrictions.
+
+- There is no need to change the value of smtpd_recipient_restrictions.
+
+Major changes - start-up
+------------------------
+
+[Feature 20120306] New master "-w" option, to wait for master daemon
+process initialization to complete. This feature returns an error
+exit status if master daemon initialization fails, or if it does
+not complete in a reasonable amount of time. The exit status is
+used by "postfix start" to provide more accurate information to
+system start-up scripts.
+
+Major changes - tls
+-------------------
+
+[Incompat 20130203] Thanks to OpenSSL documentation, the Postfix
+2.9.0..2.9.5 SMTP client and server server used an incorrect procedure
+to compute TLS certificate PUBLIC-KEY fingerprints (these may be
+used in the check_ccert_access and in smtp_tls_policy_maps features).
+Support for certificate PUBLIC-KEY finger prints was introduced
+with Postfix 2.9; there is no known problem with the certificate
+fingerprint algorithms available since Postfix 2.2.
+
+Certificate PUBLIC-KEY finger prints may be used in the Postfix
+SMTP server (with "check_ccert_access") and in the Postfix SMTP
+client (with the "fingerprint" security level).  
+
+Specify "tls_legacy_public_key_fingerprints = yes" temporarily,
+pending a migration from configuration files with incorrect Postfix
+2.9.0..2.9.5 certificate PUBLIC-KEY finger prints, to the correct
+fingerprints used by Postfix 2.9.6 and later.
+
+To compute the correct PUBLIC-KEY finger prints:
+
+# 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
+
+# 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
+
+[Feature 20120422] This release adds support to turn off the TLSv1.1
+and TLSv1.2 protocols.  Introduced with OpenSSL version 1.0.1, these
+are known to cause inter-operability problems with for example
+hotmail.
+
+The radical workaround is to temporarily turn off problematic
+protocols globally:
+
+/etc/postfix/main.cf:
+    smtp_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
+    smtp_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
+
+    smtpd_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
+    smtpd_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
+
+However, it may be better to temporarily turn off problematic
+protocols for broken sites only:
+
+/etc/postfix/main.cf:
+    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+
+/etc/postfix/tls_policy:
+    example.com         may protocols=!SSLv2:!TLSv1.1:!TLSv1.2
+
+Important:
+
+- Note the use of ":" instead of comma or space. Also, note that
+  there is NO space around the "=" in "protocols=".
+
+- The smtp_tls_policy_maps lookup key must match the "next-hop"
+  destination that is given to the Postfix SMTP client. If you
+  override the next-hop destination with transport_maps, relayhost,
+  sender_dependent_relayhost_maps, or otherwise, you need to specify
+  the same destination for the smtp_tls_policy_maps lookup key.
--- a/RELEASE_NOTES-2.11
+++ b/RELEASE_NOTES-2.11
@ -0,0 +1,280 @@
+The stable Postfix release is called postfix-2.11.x where 2=major
+release number, 11=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-2.12-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 2.9 or earlier, read RELEASE_NOTES-2.10
+before proceeding.
+
+Major changes - tls
+-------------------
+
+[Documentation 20131218] The new FORWARD_SECRECY_README document
+conveniently presents all information about Postfix "perfect" forward
+secrecy support in one place: what forward secrecy is, how to tweak
+settings, and what you can expect to see when Postfix uses ciphers
+with forward secrecy.
+
+[Feature 20130602] Support for PKI-less TLS server certificate
+verification, where the CA public key or the server certificate is
+identified via DNSSEC lookup.
+
+This feature introduces new TLS security levels called "dane" and
+"dane-only" (DNS-based Authentication of Named Entities) that use
+DNSSEC to look up CA or server certificate information.  The details
+of DANE core protocols are still evolving, as are the details of
+how DANE should be used in the context of SMTP. Postfix implements
+what appears to be a "rational" subset of the DANE profiles that
+is suitable for SMTP.
+
+The problem with conventional PKI is that there are literally
+hundreds of organizations world-wide that can provide a certificate
+in anyone's name. There have been widely-published incidents in
+recent history where a certificate authority gave out an inappropriate
+certificate (e.g., a certificate in the name of Microsoft to someone
+who did not represent Microsoft), where a CA was compromised (e.g.,
+DigiNotar, Comodo), or where a CA made operational mistakes (e.g.,
+TURKTRUST).  Another concern is that a legitimate CA might be coerced
+to provide a certificate that allows its government to play
+man-in-the-middle on TLS traffic and observe the plaintext.
+
+Major changes - LMDB database support
+-------------------------------------
+
+LMDB is a memory-mapped database that was originally developed as
+part of OpenLDAP. The Postfix LMDB driver was originally contributed
+by Howard Chu, LMDB's creator.
+
+LMDB can be used for all Postfix lookup tables and caches.  It is
+the first persistent Postfix database that can be shared among
+multiple writers such as postscreen daemons (Postfix already supported
+shared non-persistent memcached caches).  See lmdb_table(5) and
+LMDB_README for further information, including how to access Postfix
+LMDB databases with non-Postfix programs.
+
+Postfix currently requires LMDB version 0.9.11 or later. The minimum
+version may change over time in the light of deployment experience.
+
+Major changes - postscreen whitelisting
+---------------------------------------
+
+[Feature 20130512] Allow a remote SMTP client to skip postscreen(8)
+tests based on its postscreen_dnsbl_sites score.
+
+Specify a negative "postscreen_dnsbl_whitelist_threshold" value to
+enable this feature.  When a client passes the threshold value
+without having failed other tests, all pending or disabled tests
+are flagged as completed.
+
+This feature can mitigate the email delays due to "after 220 greeting"
+protocol tests, which otherwise require that a client reconnects
+before it can deliver mail. Some providers such as Google don't
+retry from the same IP address. This can result in large email
+delivery delays.
+
+Major changes - recipient_delimiter
+-----------------------------------
+
+[Feature 20130405] The recipient_delimiter parameter can now specify
+a set of characters.  A user name is now separated from its address
+extension by the first character that matches the recipient_delimiter
+set.
+
+For example, specify "recipient_delimiter = +-" to support both the
+Postfix-style "+" and the qmail-style "-" extension delimiter.  
+
+As before, this implementation recognizes one delimiter character
+per email address, and one address extension per email address.
+
+Major changes - smtpd access control
+------------------------------------
+
+[Feature 20131031] The check_sasl_access feature can be used to
+block hijacked logins. Like other check_mumble_access features it
+queries a lookup table (in this case with the SASL login name), and
+it supports the same actions as any Postfix access(5) table.
+
+[Feature 20130924] The reject_known_sender_login_mismatch feature
+applies reject_sender_login_mismatch only to MAIL FROM addresses
+that are known in $smtpd_sender_login_maps.
+
+Major changes - MacOS X
+-----------------------
+
+[Feature 20130325] Full support for kqueue() event handling which
+scales better with large numbers of file handles, plus a workaround
+for timeout handling on file handles (such as /dev/urandom) that
+still do not correctly support poll().
+
+Major changes - master
+----------------------
+
+[Incompat 20131217] The master_service_disable parameter value
+syntax has changed: use "service/type" instead of "service.type".
+The new form is consistent with postconf(1) namespaces for master.cf.
+The old form is still supported to avoid breaking existing
+configurations.
+
+Major changes - milter
+----------------------
+
+[Feature 20131126] Support for ESMTP parameters "NOTIFY" and "ORCPT"
+in the SMFIR_ADDRCPT_PAR (add recipient with parameters) request.
+Credits: Andrew Ayer.
+
+Major changes - mysql
+---------------------
+
+[Feature 20131117] MySQL client support for option_file, option_group,
+tls_cert_file, tls_key_file, tls_CAfile, tls_CApath, tls_verify_cert.
+Credits: Gareth Palmer.
+
+Major changes - postconf
+------------------------
+
+[Feature 20131217] Support for advanced master.cf query and update
+operations.  This was implemented primarily to support automated
+system management tools.
+
+The goal is to make all Postfix master.cf details accessible as
+lists of "name=value" pairs, where the names are organized into
+structured name spaces.  This allows other programs to query
+information or request updates, without having to worry about the
+exact layout of master.cf files.
+
+Managing master.cf service attributes
+-------------------------------------
+
+First, an example that shows the smtp/inet service in the traditional
+form:
+
+    $ postconf -M smtp/inet
+    smtp       inet  n       -       n       -       -       smtpd
+
+Different variants of this command show different amounts of output.
+For example, "postconf -M smtp" enumerates all services that have
+a name "smtp" and any service type ("inet", "unix", etc.), and
+"postconf -M" enumerates all master.cf services.  
+
+General rule: each name component that is not present becomes a "*"
+wildcard.
+
+Coming back to the above example, the postconf -F option can now
+enumerate the smtp/inet service fields as follows:
+
+    $ postconf -F smtp/inet
+    smtp/inet/service = smtp
+    smtp/inet/type = inet
+    smtp/inet/private = n
+    smtp/inet/unprivileged = -
+    smtp/inet/chroot = n
+    smtp/inet/wakeup = -
+    smtp/inet/process_limit = -
+    smtp/inet/command = smtpd
+
+This form makes it very easy to change one field in master.cf.
+For example to turn on chroot on the smtp/inet service you use:
+
+    $ postconf -F smtp/inet/chroot=y
+    $ postfix reload
+
+Moreover, with "-F" you can specify "*" for service name or service
+type to get a wild-card match.  For example, to turn off chroot on
+all Postfix daemons, use this:
+
+    $ postconf -F '*/*/chroot=n'
+    $ postfix reload
+
+Managing master.cf service "-o parameter=value" settings
+--------------------------------------------------------
+
+For a second example, let's look at the submission service.  This
+service typically has multiple "-o parameter=value" overrides. First
+the traditional view:
+
+    $ postconf -Mf submission
+    submission inet  n       -       n       -       -       smtpd
+        -o smtpd_tls_security_level=encrypt
+        -o smtpd_sasl_auth_enable=yes
+        ...
+
+The postconf -P option can now enumerate these parameters as follows:
+
+    $ postconf -P submission
+    submission/inet/smtpd_sasl_auth_enable = yes
+    submission/inet/smtpd_tls_security_level = encrypt
+    ...
+
+Again, this form makes it very easy to modify one parameter
+setting. For example, to change the smtpd_tls_security_level setting
+for the submission/inet service:
+
+    $ postconf -P 'submission/inet/smtpd_tls_security_level=may'
+
+You can create or remove a parametername=parametervalue setting:
+
+Create:
+    $ postconf -P 'submission/inet/parametername=parametervalue'
+
+Remove:
+    $ postconf -PX submission/inet/parametername
+
+Finally, always execute "postfix reload" after updating master.cf.
+
+Managing master.cf service entries
+----------------------------------
+
+Finally, adding master.cf entries is possible, but currently this
+does not yet have "advanced" support. It can only be done at the
+level of the traditional master.cf file format.
+
+Suppose that you need to configure a Postfix SMTP client that will
+handle slow email deliveries.  To implement this you need to clone
+the smtp/unix service settings and create a new delay/unix service.
+
+First, you would enumerate the smtp/unix service like this:
+
+    $ postconf -M smtp/unix
+    smtp      unix  -       -       n       -       -       smtp
+
+Then you would copy those fields (except the first field) by hand
+to create the delay/unix service:
+
+    $ postconf -M delay/unix="delay   unix   -   -   n   -   -   smtp"
+
+To combine the above steps in one command:
+
+    $ postconf -M delay/unix="`postconf -M smtp/unix|awk '{$1 = "delay"}'`"
+
+This is perhaps not super-convenient for manual cloning, but it
+should be sufficient for programmatic configuration management.
+
+Again, always execute "postfix reload" after updating master.cf.
+
+Deleting or commenting out master.cf entries
+--------------------------------------------
+
+The -X (delete entry) and -# (comment out entry) options already
+exist for main.cf, and they now also work work for entire master.cf
+entries:
+
+Remove main.cf or master.cf entry:
+    $ postconf -X parametername
+    $ postconf -MX delay/unix
+
+Comment out main.cf or master.cf entry:
+    $ postconf -# parametername
+    $ postconf -M# delay/unix
+
+As with main.cf, there is no support to "undo" master.cf changes
+that are made with -X or -#.
+
+Again, always execute "postfix reload" after updating master.cf.
--- a/RELEASE_NOTES-2.2
+++ b/RELEASE_NOTES-2.2
@ -0,0 +1,443 @@
+The stable Postfix release is called postfix-2.2.x where 2=major
+release number, 2=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-2.3-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.
+
+Main changes with Postfix version 2.2
+-------------------------------------
+
+This is a summary of the changes. These and more are detailed in
+the following sections of this document.
+
+- TLS and IPv6 support are now built into Postfix, based on code
+from third-party patches.
+
+- Extended query interface for LDAP, MySQL and PostgreSQL with free
+form SQL queries, and domain filters to reduce unnecessary lookups.
+
+- SMTP client-side connection reuse. This can dramatically speed
+up deliveries to high-volume destinations that have some servers
+that respond, and some non-responding mail servers.
+
+- By default, Postfix no longer rewrites message headers in mail
+from remote clients. This includes masquerading, canonical mapping,
+replacing "!" and "%" by "@", and appending the local domain to
+incomplete addresses.  Thus, spam from poorly written software no
+longer looks like it came from a local user.
+
+- When your machine does not have its own domain name, Postfix can
+now replace your "home network" email address by your ISP account
+in outgoing SMTP mail, while leaving your email address unchanged
+when sending mail to someone on the local machine.
+
+- Compatibility workarounds: you can now selectively turn off ESMTP
+features such as AUTH or STARTTLS in the Postfix SMTP client or
+server, without having to "dumb down" other mail deliveries, and
+without having to use transport maps for outgoing mail.
+
+- Remote SMTP client resource control (the anvil server).  This
+allows you to limit the number of connections, or the number of
+MAIL FROM and RCPT TO commands that an SMTP client can send per
+unit time.
+
+- Support for CDB, SDBM and NIS+ databases is now built into Postfix
+(but the CDB and SDBM libraries are not).
+
+- New SMTP access control features, and more.
+
+Major changes - critical
+------------------------
+
+BEFORE upgrading from an older release you MUST stop Postfix, unless
+you're running a Postfix 2.2 snapshot release that already has
+Postfix 2.2 IPV6 and TLS support.
+
+AFTER upgrading from an older release DO NOT copy the old
+master.cf/main.cf files over the new files.  Instead, you MUST let
+the Postfix installation procedure update the existing configuration
+files with new service entries.
+
+[Incompat 20041118] The master-child protocol has changed.  The
+Postfix master daemon will log warnings about partial status updates
+if you don't stop and start Postfix.
+
+[Incompat 20041023, 20041009] The queue manager to delivery agent
+protocol has changed. Mail will remain queued if you do not restart
+the queue manager.
+
+[Incompat 20050111] The upgrade procedure adds the tlsmgr service
+to the master.cf file. This service entry is not compatible with
+the Postfix/TLS patch.
+
+[Feature 20040919] The upgrade procedure adds the discard service
+to the master.cf file.
+
+[Feature 20040720] The upgrade procedure adds the scache (shared
+connection cache) service to the master.cf file.
+
+Major changes - IPv6 support
+----------------------------
+
+[Feature 20050111] Postfix version 2.2 IP version 6 support based
+on the Postfix/IPv6 patch by Dean Strik and others.  IPv6 support
+is always compiled into Postfix on systems that have Postfix
+compatible IPv6 support. On other systems Postfix will simply use
+IP version 4 just like it did before. See the IPV6_README document
+for what systems are supported, and how to turn on IPv6 in main.cf.
+
+[Incompat 20050111] Postfix version 2.2 IPv6 support differs from
+the Postfix/IPv6 patch by Dean Strik in a few minor ways.
+
+- Network protocol support including DNS lookup is selected with
+the inet_protocols parameter instead of the inet_interfaces parameter.
+This is needed so that Postfix will not attempt to deliver mail via
+IPv6 when the system has no IPv6 connectivity.
+
+- The lmtp_bind_address6 feature was omitted. The Postfix LMTP
+client will be absorbed into the SMTP client, so there is no reason
+to keep adding features to the LMTP client.
+
+- The CIDR-based address matching code was rewritten.  The new
+behavior is believed to be closer to expectation. The results may
+be incompatible with that of the Postfix/IPv6 patch.
+
+[Incompat 20050117] The Postfix SMTP server now requires that IPv6
+addresses in SMTP commands are specified as [ipv6:ipv6address], as
+described in RFC 2821.
+
+Major changes - TLS support
+---------------------------
+
+[Feature 20041210] Postfix version 2.2 TLS support, based on the
+Postfix/TLS patch by Lutz Jaenicke.  TLS support is not compiled
+in by default.  For more information about Postfix 2.2 TLS support,
+see the TLS_README document.
+
+[Incompat 20041210] Postfix version 2.2 TLS support differs from
+the Postfix/TLS patch by Lutz Jaenicke in a few minor ways.
+
+- main.cf: Use btree instead of sdbm for TLS session cache databases.
+
+  Session caches are now accessed only by the tlsmgr(8) process,
+  so there are no concurrency issues. Although Postfix still has
+  an SDBM client, the SDBM library (1000 lines of code) is no longer
+  included with Postfix.
+
+  TLS session caches can use any database that can store objects
+  of several kbytes or more, and that implements the sequence
+  operation. In most cases, btree databases should be adequate.
+
+  NOTE: You cannot use dbm databases. TLS session objects are too
+  large.
+
+- master.cf: Specify unix instead of fifo for the tlsmgr service type.
+  This change is automatically made by the Postfix upgrade procedure.
+
+  The smtp(8) and smtpd(8) processes use a client-server protocol
+  in order to access the tlsmgr(8)'s pseudo-random number generation
+  (PRNG) pool, and in order to access the TLS session cache databases.
+  Such a protocol cannot be run across fifos.
+
+[Feature 20050209] The Postfix SMTP server policy delegation protocol
+now supplies TLS client certificate information after successful
+verification.  The new policy delegation protocol attribute names
+are ccert_subject, ccert_issuer and ccert_fingerprint.
+
+[Feature 20050208] New "check_ccert_maps maptype:mapname" feature
+to enforce access control based on hexadecimal client certificate
+fingerprints.
+
+Major changes - SMTP client connection cache
+--------------------------------------------
+
+[Feature 20040720] SMTP client-side connection caching. Instead of
+disconnecting immediately after a mail transaction, the Postfix
+SMTP client can save the open connection to the scache(8) connection
+cache daemon, so that any SMTP client process can reuse that session
+for another mail transaction.  See the CONNECTION_CACHE_README
+document for a description of configuration and implementation.
+
+This feature introduces the scache (connection cache) server, which
+is added to your master.cf file when you upgrade Postfix.
+
+[Feature 20040729] Opportunistic SMTP connection caching. When a
+destination has a high volume of mail in the active queue, SMTP
+connection caching is enabled automatically.  This is controlled
+with a new configuration parameter "smtp_connection_cache_on_demand"
+(default:  yes).
+
+[Feature 20040723] Per-destination SMTP connection caching. This
+is enabled with the smtp_connection_cache_destinations parameter.
+The parameter requires "bare" domain names or IP addresses without
+"[]" or TCP port, to avoid a syntax conflict between host:port and
+maptype:mapname entries.
+
+[Feature 20040721] The scache(8) connection cache manager logs cache
+hit and miss statistics every $connection_cache_status_update_time
+seconds (default: 600s).  It reports the hit and miss rates for
+lookups by domain, as well as for lookups by network address.
+
+Major changes - address rewriting
+---------------------------------
+
+[Feature 20050206] Support for address rewriting in outgoing SMTP
+mail (headers and envelopes). This is useful for sites that have a
+fantasy Internet domain name such as localdomain.local.  Mail
+addresses that use fantasy domain names are often rejected by mail
+servers.
+
+The smtp_generic_maps feature allows you to replace a local mail
+address (user@localdomain.local) by a valid Internet address
+(account@isp.example) when mail is sent across the Internet.  The
+feature has no effect on mail that is sent between accounts on the
+local machine. The syntax is described in generic(5) and a detailed
+example is in the STANDARD_CONFIGURATION_README document, the section
+titled "Postfix on hosts without a real Internet hostname".
+
+[Feature 20041023] By default, Postfix no longer rewrites message
+headers in mail from remote clients. This includes masquerading,
+canonical mapping, replacing "!" and "%" by "@", and appending the
+local domain to incomplete addresses.  Thus, spam from poorly written
+software no longer looks like it came from a local user.
+
+By default, Postfix rewrites message header addresses only when the
+client IP address matches the local machine's interface addresses,
+or when mail is submitted with the Postfix sendmail(1) command.
+
+Postfix rewrites message headers in mail from other clients only
+when the remote_header_rewrite_domain parameter specifies a domain
+name (such as "domain.invalid"); this domain is appended to incomplete
+addresses. Rewriting also includes masquerading, canonical mapping,
+and replacing "!" and "%" by "@".
+
+To get the behavior before Postfix 2.2 (always append Postfix's own
+domain to incomplete addresses in message headers, always subject
+message headers to canonical mapping, address masquerading, and
+always replace "!" and "%" by "@") specify:
+
+/etc/postfix/main.cf:
+    local_header_rewrite_clients = static:all
+
+If you must rewrite headers in mail from specific clients then you
+can specify, for example,
+
+/etc/postfix/main.cf:
+    local_header_rewrite_clients = permit_mynetworks,
+	permit_sasl_authenticated, permit_tls_clientcerts,
+	check_address_map hash:/etc/postfix/pop-before-smtp
+
+Postfix always appends local domain information to envelope addresses
+(as opposed to header addresses), because an unqualified envelope
+address is effectively local for the purpose of delivery, and for
+the purpose of replying to it.
+
+Full details are given in ADDRESS_REWRITING_README, and in the
+postconf(5) manual. For best results, point your browser at the
+ADDRESS_REWRITING_README.html file and navigate to the section
+titled " To rewrite message headers or not, or to label as invalid".
+
+[Incompat 20050212] When header address rewriting is enabled, Postfix
+now updates a message header only when at least one address in that
+header is modified.  Older Postfix versions first parse and then
+un-parse a header so that there may be subtle changes in formatting,
+such as the amount of whitespace between tokens.
+
+[Incompat 20050227] Postfix no longer changes message header labels.
+Thus, FROM: or CC: are no longer replaced by From: or Cc:.
+
+[Feature 20040827] Finer control over canonical mapping with
+canonical_classes, sender_canonical_classes and
+recipient_canonical_classes.  These specify one or more of
+envelope_sender, header_sender, envelope_recipient or header_recipient.
+The default settings are backwards compatible.
+
+Major changes - SMTP compatibility controls
+-------------------------------------------
+
+[Feature 20041218] Fine control for SMTP inter-operability problems,
+by discarding keywords that are sent or received with the EHLO
+handshake.  Typically one would discard "pipelining", "starttls",
+or "auth" to work around systems with a broken implementation.
+Specify a list of EHLO keywords with the smtp(d)_discard_ehlo_keywords
+parameters, or specify one or more lookup tables, indexed by remote
+network address, with the smtp(d)_discard_ehlo_keyword_address_maps
+parameters.
+
+Note: this feature only discards words from the EHLO conversation;
+it does not turn off the actual features in the SMTP server.
+
+Major changes - database support
+--------------------------------
+
+[Feature 20050209] Extended LDAP, MySQL and PgSQL query interface
+with free form SQL queries, the domain filter optimization that was
+already available with LDAP and more. This code was worked on by
+many people but Victor Duchovni took the lead. See the respective
+{LDAP,MYSQL,PGSQL}_README and {ldap,mysql,pgsql}_table documents.
+
+[Feature 20041210] You can now dump an entire database with the new
+postmap/postalias "-s" option. This works only for database types
+with Postfix sequence operator support: hash, btree, dbm, and sdbm.
+
+[Feature 20041208] Support for CDB databases by Michael Tokarev.
+This supports both Michael's tinycdb and Daniel Bernstein's cdb
+implementations, but neither of the two implementations is bundled
+with Postfix.
+
+[Feature 20041023] The NIS+ client by Geoff Gibbs is now part of
+the Postfix source tree. Details are given in the nisplus_table(5)
+manual page.
+
+[Feature 20040827] Easier use of the proxymap(8) service with the
+virtual(8) delivery agent. The virtual(8) delivery agent will
+silently open maps directly when those maps can't be proxied for
+security reasons.  This means you can now specify "virtual_mailbox_maps
+= proxy:mysql:whatever" without triggering a fatal error in the
+virtual(8) delivery agent.
+
+Major changes - remote SMTP client resource control
+---------------------------------------------------
+
+[Incompat 20041009] The smtpd_client_connection_limit_exceptions
+parameter is renamed to smtpd_client_event_limit_exceptions. Besides
+connections it now also applies to per-client message rate and
+recipient rate limits.
+
+[Feature 20041009] Per SMTP client message rate and recipient rate
+limits. These limit the number of MAIL FROM or RCPT TO requests
+regardless of whether or not Postfix would have accepted them
+otherwise. The user interface (smtpd_client_message_rate_limit and
+smtpd_client_recipient_rate_limit) is similar to that of the existing
+per SMTP client connection rate limit, and the same warnings apply:
+these features are to be used to stop abuse, and must not be used
+to regulate legitimate mail.  More details can be found in the
+postconf(5) manual.
+
+Major changes - remote SMTP client access control
+-------------------------------------------------
+
+[Feature 20050209] The Postfix SMTP server policy delegation protocol
+now supplies TLS client certificate information after successful
+verification.  The new policy delegation protocol attribute names
+are ccert_subject, ccert_issuer and ccert_fingerprint.
+
+[Feature 20050208] New "check_ccert_maps maptype:mapname" feature
+to enforce access control based on hexadecimal client certificate
+fingerprints.
+
+[Feature 20050203] New "permit_inet_interfaces" access restriction
+to allow access from local IP addresses only.  This is used for the
+default, purist, setting of local_header_rewrite_clients (rewrite
+only headers in mail from this machine).
+
+[Feature 20050203] New "sleep time-in-seconds" pseudo access
+restriction to block zombie clients with reject_unauthorized_pipelining
+before the Postfix SMTP server sends the SMTP greeting. See postconf(5)
+for example. This feature is not available the stable Postfix 2.2
+release, but it is documented here so that it will not get lost.
+
+[Feature 20041118] New "smtpd_end_of_data_restrictions" feature
+that is invoked after the client terminates the SMTP DATA command.
+The syntax is the same as with "smtpd_data_restrictions".  In the
+SMTPD policy delegation request, the message size is the actual
+byte count of the message content, instead of the message size
+announced by the client in the MAIL FROM command.
+
+Major changes - SASL authentication
+-----------------------------------
+
+[Feature 20040827] Better SMTP client control over the use of SASL
+mechanisms. New smtp_sasl_mechanism_filter mechanism to shorten the
+list of SASL mechanisms from a remote server to just those that the
+local SASL library can actually use.
+
+Major changes - header/body patterns
+------------------------------------
+
+[Feature 20050205] REPLACE action in header_checks and body_checks,
+to replace a message header or body line.  See header_checks(5) for
+details.
+
+Major changes - local delivery
+------------------------------
+
+[Feature 20040621] Control over the working directory when executing
+an external command.  With the pipe(8) mailer, specify directory=pathname,
+and with local(8) specify "command_execution_directory = expression"
+where "expression" is subject to $home etc. macro expansion. The
+result of macro expansion is restricted by the set of characters
+specified with execution_directory_expansion_filter.
+
+Major changes - mail delivery attributes
+----------------------------------------
+
+[Feature 20041218] More client attributes for delivery to command
+with the local(8) and pipe(8) delivery agents: client_hostname,
+client_address, client_protocol, client_helo, sasl_method, sasl_sender,
+and sasl_username.  With local(8), attribute names must be specified
+in upper case.
+
+Major changes - package creation
+--------------------------------
+
+[Feature 20050203] To create a ready-to-install package for
+distribution to other systems you can now use "make package" or
+"make non-interactive-package", instead of invoking the internal
+postfix-install script by hand. See the PACKAGE_README file for
+details.
+
+Major changes - performance
+---------------------------
+
+[Incompat 20050117] Only the deferred and defer queue directories
+are now hashed by default, instead of eight queue directories.  This
+may speed up Postfix boot time on low-traffic systems without
+compromising performance under high load too much. Hashing must be
+turned on for the defer and deferred queue directories, because
+those directories contain lots of files when undeliverable mail is
+backing up.
+
+[Incompat 20040720] The default SMTP/LMTP timeouts for sending RSET
+are reduced to 20s.
+
+Major changes - miscellaneous
+-----------------------------
+
+[Feature 20050203] Safety: Postfix no longer tries to send mail to
+the fallback_relay when the local machine is MX host for the mail
+destination. See the postconf(5) description of the fallback_relay
+feature for details.
+
+[Incompat 20041023] Support for the non-standard Errors-To: return
+addresses is now removed from Postfix.  It was already disabled by
+default with Postfix version 2.1. Since Errors-To: is non-standard,
+there was no guarantee that it would have the desired effect with
+other MTAs.
+
+[Feature 20040919] A new discard(8) mail delivery agent that makes
+throwing away mail easier and more efficient. It's the Postfix
+equivalent of /dev/null for mail deliveries. On the mail receiving
+side, Postfix already has a /dev/null equivalent in the form of the
+DISCARD action in access maps and header_body_checks.
+
+[Feature 20040919] Access control for local mail submission, for
+listing the queue, and for flushing the queue. These features are
+controlled with authorized_submit_users, authorized_mailq_users,
+and with authorized_flush_users, respectively. The last two controls
+are always permitted for the super-user and for the mail system
+owner.  More information is in the postconf(5) manual.
+
+[Incompat 20040829] When no recipients are specified on the command
+line or via the -t option, the Postfix sendmail command terminates
+with status EX_USAGE and produces an error message instead of
+accepting the mail first and bouncing it later. This gives more
+direct feedback in case of a common client configuration error.
+
--- a/RELEASE_NOTES-2.3
+++ b/RELEASE_NOTES-2.3
@ -0,0 +1,761 @@
+The stable Postfix release is called postfix-2.3.x where 2=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-2.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.
+
+Critical notes
+--------------
+
+See RELEASE_NOTES_2.2 if you upgrade from Postfix 2.1 or earlier.
+
+Some Postfix internal protocols have changed.  You need to "postfix
+reload" or restart Postfix, otherwise many servers will log warning
+messages like "unexpected attribute xxx" or "problem talking to
+service yyy", and mail will not be delivered.
+
+The Sendmail-compatible Milter support introduces three new queue
+file record types. As long as you leave this feature turned off,
+you can still go back to Postfix version 2.2 without losing mail
+that was received by Postfix 2.3.
+
+Major changes - DNS lookups
+---------------------------
+
+[Incompat 20050726] Name server replies that contain a malformed
+hostname are now flagged as permanent errors instead of transient
+errors. This change works around a questionable proposal to use
+syntactically invalid hostnames in MX records.
+
+Major changes - DSN
+-------------------
+
+[Feature 20050615] DSN support as described in RFC 3461 .. RFC 3464.
+This gives senders control over successful and failed delivery
+notifications.  DSN involves extra parameters to the SMTP "MAIL
+FROM" and "RCPT TO" commands, as well as extra Postfix sendmail
+command line options for mail submission.
+
+See DSN_README for details. Some implementation notes can be found
+in implementation-notes/DSN.
+
+[Incompat 20050615] The new DSN support conflicts with VERP support.
+For Sendmail compatibility, Postfix now uses the sendmail -V command
+line option for DSN.  To request VERP style delivery, you must now
+specify -XV instead of -V.  The Postfix sendmail command will
+recognize if you try to use -V for VERP-style delivery.  It will
+usually do the right thing, and remind you of the new syntax.
+
+[Incompat 20050828] Postfix no longer sends DSN SUCCESS notification
+after virtual alias expansions when the cleanup server rejects the
+content or size of mail that was submitted with the Postfix sendmail
+command, mail that was forwarded with the local(8) delivery agent,
+or mail that was re-queued with "postsuper -r". Since all the
+recipients are reported as failed, the SUCCESS notification seems
+redundant.
+
+Major changes - LMTP client
+---------------------------
+
+See the "SASL authentication" and "TLS" sections for changes related
+to SASL authentication and TLS support, respectively.
+
+[Feature 20051208] The SMTP client now implements the LMTP protocol.
+Most but not all smtp_xxx parameters now have an lmtp_xxx equivalent.
+This means there are lot of new LMTP features, including support
+for TLS and for the shared connection cache. See the "SMTP client"
+section for details.
+
+[Incompat 20051208] The LMTP client now reports the server as
+"myhostname[/path/name]".  With the real server hostname in delivery
+status reports, the information will be more useful.
+
+Major changes - Milter support
+------------------------------
+
+[Feature 20060515] Milter (mail filter) application support,
+compatible with Sendmail version 8.13.6 and earlier. This allows
+you to run a large number of plug-ins to reject unwanted mail, and
+to sign mail with for example domain keys. All Milter functions are
+implemented except replacing the message body, which will be added
+later. Milters are before-queue filters, so they don't change the
+queue ID.
+
+See the MILTER_README document for a discussion of how to use Milter
+support with Postfix, and limitations of the current implementation.
+
+The Sendmail-compatible Milter support introduces three new queue
+file record types. As long as you leave this feature turned off,
+you can still go back to Postfix version 2.2 without losing mail
+that was received by Postfix 2.3.
+
+[Incompat 20060515] Milter support introduces new logfile event
+types: milter-reject, milter-discard and milter-hold, that identify
+actions from Milter applications. This may affect logfile processing
+software.
+
+Major changes - SASL authentication
+-----------------------------------
+
+[Feature 20051220] Plug-in support for SASL authentication in the
+SMTP server and in the SMTP/LMTP client. With this, Postfix can
+support multiple SASL implementations without source code patches.
+Some distributors may even make SASL support a run-time linking
+option, just like they already do with Postfix lookup tables.
+
+Hints and tips for plug-in developers are in the xsasl/README file.
+
+For backwards compatibility the default plug-in type is Cyrus SASL,
+so everything should behave like it did before. Some error messages
+are slightly different, but these are generally improvements.
+
+The "postconf -a" command shows what plug-in implementations are
+available for the SMTP server, and "postconf -A" does the same for
+the SMTP/LMTP client.  Plug-in implementations are selected with
+the smtpd_sasl_type, smtp_sasl_type and lmtp_sasl_type configuration
+parameters.
+
+Other new configuration parameters are smtpd_sasl_path, smtp_sasl_path
+and lmtp_sasl_path. These are better left alone; they are introduced
+for the convenience of other SASL implementations.
+
+[Feature 20051222] Dovecot SASL support (SMTP server only). Details
+can be found in the SASL_README document.
+
+[Incompat 20051220] The Postfix-with-Cyrus-SASL build procedure has
+changed. You now need to specify -DUSE_CYRUS_SASL in addition to
+-DUSE_SASL_AUTH or else you end up without any Cyrus SASL support.
+The error messages are:
+
+    unsupported SASL server implementation: cyrus
+    unsupported SASL client implementation: cyrus
+
+[Feature 20051125] This snapshot adds support for sender-dependent
+ISP accounts.
+
+- Sender-dependent smarthost lookup tables.  The maps are searched
+  with the sender address and with the sender @domain.  The result
+  overrides the global relayhost setting, but otherwise has identical
+  behavior. See the postconf(5) manual page for more details.
+
+  Example:
+    /etc/postfix/main.cf:
+	sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
+
+- Sender-dependent SASL authentication support. This disables SMTP
+  connection caching to ensure that mail from different senders
+  will use the correct authentication credentials. The SMTP SASL
+  password file is first searched by sender address, and then by
+  the remote domain and hostname as usual.
+
+  Example:
+    /etc/postfix/main.cf:
+	smtp_sasl_auth_enable = yes
+	smtp_sender_dependent_authentication = yes
+	smtp_sasl_password_maps = hash:/etc/postfix/sasl_pass
+
+[Incompat 20060707] The SMTP/LMTP client now defers delivery when
+a SASL password exists but the server does not announce support for
+SASL authentication.  This can happen with servers that announce
+SASL support only when TLS is turned on.  When an opportunistic TLS
+handshake fails, Postfix >= 2.3 retries delivery in plaintext, and
+the remote server rejects mail from the unauthenticated client.
+Specify "smtp_sasl_auth_enforce = no" to deliver mail anyway.
+
+Major changes - SMTP client
+---------------------------
+
+See the "SASL authentication" and "TLS" sections for changes related
+to SASL authentication and TLS support, respectively.
+
+[Feature 20051208] The SMTP client now implements the LMTP protocol.
+Most but not all smtp_xxx parameters now have an lmtp_xxx equivalent.
+This means there are lot of new LMTP features, including support
+for TLS and for the shared connection cache.
+
+[Incompat 20060112] The Postfix SMTP/LMTP client by default no
+longer allows DNS CNAME records to override the server hostname
+that is used for logging, SASL password lookup, TLS policy selection
+and TLS server certificate verification. Specify
+"smtp_cname_overrides_servername = yes" to get the old behavior.
+
+[Incompat 20060103] The Postfix SMTP/LMTP client no longer defers
+mail delivery when it receives a malformed SMTP server reply in a
+session with command pipelining.  When helpful warnings are enabled,
+it will suggest that command pipelining be disabled for the affected
+destination.
+
+[Incompat 20051208] The fallback_relay feature is renamed to
+smtp_fallback_relay, to make clear that the combined SMTP/LMTP
+client uses this setting only for SMTP deliveries. The old name
+still works.
+
+[Incompat 20051106] The relay=... logging has changed and now
+includes the remote SMTP server port number as hostname[hostaddr]:port.
+
+[Incompat 20051026] The smtp_connection_cache_reuse_limit parameter
+(which limits the number of deliveries per SMTP connection) is
+replaced by the new smtp_connection_reuse_time_limit parameter (the
+time after which a connection is no longer stored into the connection
+cache).
+
+[Feature 20051026] This snapshot addresses a performance stability
+problem with remote SMTP servers. The problem is not specific to
+Postfix: it can happen when any MTA sends large amounts of SMTP
+email to a site that has multiple MX hosts. The insight that led
+to the solution, as well as an initial implementation, are due to
+Victor Duchovni.
+
+The problem starts when one of a set of MX hosts becomes slower
+than the rest.  Even though SMTP clients connect to fast and slow
+MX hosts with equal probability, the slow MX host ends up with more
+simultaneous inbound connections than the faster MX hosts, because
+the slow MX host needs more time to serve each client request.
+
+The slow MX host becomes a connection attractor.  If one MX host
+becomes N times slower than the rest, it dominates mail delivery
+latency unless there are more than N fast MX hosts to counter the
+effect. And if the number of MX hosts is smaller than N, the mail
+delivery latency becomes effectively that of the slowest MX host
+divided by the total number of MX hosts.
+
+The solution uses connection caching in a way that differs from
+Postfix 2.2.  By limiting the amount of time during which a connection
+can be used repeatedly (instead of limiting the number of deliveries
+over that connection), Postfix not only restores fairness in the
+distribution of simultaneous connections across a set of MX hosts,
+it also favors deliveries over connections that perform well, which
+is exactly what we want.
+
+The smtp_connection_reuse_time_limit feature implements the connection
+reuse time limit as discussed above.  It limits the amount of time
+after which an SMTP connection is no longer stored into the connection
+cache. The default limit, 300s, can result in a huge number of
+deliveries over a single connection.
+
+This solution will be complete when Postfix logging is updated to
+include information about the number of times that a connection was
+used. This information is needed to diagnose inter-operability
+problems with servers that exhibit bugs when they receive multiple
+messages over the same connection.
+
+[Incompat 20050627] The Postfix SMTP client no longer applies the
+smtp_mx_session_limit to non-permanent errors during the TCP, SMTP,
+HELO or TLS handshake.  Previous versions did that only with TCP
+and SMTP handshake errors.
+
+[Incompat 20050622] The Postfix SMTP client by default limits the
+number of MX server addresses to smtp_mx_address_limit=5. Previously
+this limit was disabled by default. The new limit prevents Postfix
+from spending lots of time trying to connect to lots of bogus MX
+servers.
+
+Major changes - SMTP server
+---------------------------
+
+See the "SASL authentication" and "TLS" sections for changes related
+to SASL authentication and TLS support, respectively.
+
+[Feature 20051222] To accept the non-compliant user@ipaddress form,
+specify "resolve_numeric_domain = yes".  Postfix will deliver the
+mail to user@[ipaddress] instead.
+
+[Incompat 20051202] The Postfix SMTP server now refuses to receive
+mail from the network if it isn't running with postfix mail_owner
+privileges.  This prevents surprises when, for example, "sendmail
+-bs" is configured to run as root from xinetd.
+
+[Incompat 20051121] Although the permit_mx_backup feature still
+accepts mail for authorized destinations (see permit_mx_backup for
+definition), with all other destinations it now requires that the
+local MTA is listed as non-primary MX server. This prevents mail
+loop problems when someone points their primary MX record at a
+Postfix system.
+
+[Feature 20051011] Optional suppression of remote SMTP client
+hostname lookup and hostname verification. Specify "smtpd_peername_lookup
+= no" to eliminate DNS lookup latencies, but do so only under extreme
+conditions, as it makes Postfix logging less informative.
+
+[Feature 20050724] SMTPD Access control based on the existence of
+an address->name mapping, with reject_unknown_reverse_client_hostname.
+There is no corresponding access table lookup feature, because the
+name is not validated in any way (except that it has proper syntax).
+
+Several confusing SMTPD access restrictions were renamed:
+
+    reject_unknown_client -> reject_unknown_client_hostname,
+    reject_unknown_hostname -> reject_unknown_helo_hostname,
+    reject_invalid_hostname -> reject_invalid_helo_hostname,
+    reject_non_fqdn_hostname -> reject_non_fqdn_helo_hostname.
+
+The old names are still recognized and documented.
+
+Major changes - TLS
+-------------------
+
+Major revisions were made to Postfix TLS support; see TLS_README
+for the details. For backwards compatibility, the old TLS policy
+user interface will be kept intact for a few releases so that sites
+can upgrade Postfix without being forced to use a different TLS
+policy mechanism.
+
+[Feature 20060614] New concept: TLS security levels ("none", "may",
+"encrypt", "verify" or "secure") in the Postfix SMTP client.  You
+can specify the TLS security level via the smtp_tls_security_level
+parameter.  This is more convenient than controlling TLS with the
+multiple smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername,
+parameters.
+
+[Feature 20060709] TLS security levels ("none", "may", "encrypt")
+in the Postfix SMTP server. You specify the security level with the
+smtpd_tls_security_level parameter. This overrides the multiple
+smtpd_use_tls and smtpd_enforce_tls parameters.  When one of the
+unimplemented "verify" or "secure" levels is specified, the Postfix
+SMTP server logs a warning and uses "encrypt" instead.
+
+[Feature 20060123] A new per-site TLS policy mechanism for the
+Postfix SMTP client that supports the new TLS security levels,
+and that eliminates DNS spoofing attacks more effectively.
+
+[Feature 20060626] Both the Postfix SMTP client and server can be
+configured without a client or server certificate. An SMTP server
+without certificate can use only anonymous ciphers, and will not
+inter-operate with most clients.
+
+The Postfix SMTP server supports anonymous ciphers when 1) no client
+certificates are requested or required, and 2) the administrator
+has not excluded the "aNULL" OpenSSL cipher type with the
+smtpd_tls_exclude_ciphers parameter.
+
+The Postfix SMTP client supports anonymous ciphers when 1) no server
+certificate is required and 2) the administrator has not excluded
+the "aNULL" OpenSSL cipher type with the smtp_tls_exclude_ciphers
+parameter.
+
+[Incompat 20060707] The SMTPD policy client now encodes the
+ccert_subject and ccert_issuer attributes as xtext. Some characters
+are represented by +XX, where XX is the two-digit hexadecimal
+representation of the character value.
+
+[Feature 20060614] The smtpd_tls_protocols parameter restricts the
+list of TLS protocols supported by the SMTP server.  This is
+recommended for use with MSA configurations only.  It should not
+be used with MX hosts that receive mail from the Internet, as it
+reduces inter-operability.
+
+[Incompat 20060614] The smtp_tls_cipherlist parameter only applies
+when TLS is mandatory.  It is ignored with opportunistic TLS sessions.
+
+[Incompat 20060614] At (lmtp|smtp|smtpd)_tls_loglevel >= 2, Postfix
+now also logs TLS session cache activity. Use level 2 and higher
+for debugging only; use levels 0 or 1 as production settings.
+
+[Incompat 20060207] The Postfix SMTP server no longer complains
+when TLS support is not compiled in while permit_tls_clientcerts,
+permit_tls_all_clientcerts, or check_ccert_access are specified in
+main.cf. These features now are effectively ignored.  However, the
+reject_plaintext_session feature is not ignored and will reject
+plain-text mail.
+
+[Feature 20060123] Some obscure behavior was eliminated from the
+smtp_tls_per_site feature, without changes to the user interface.
+Some Postfix internals had to be re-structured for the new TLS
+policy mechanism; for this, smtp_tls_per_site had to be re-implemented.
+The obscure behavior was found during compatibility testing.
+
+[Feature 20051011] Optional protection against SMTP clients that
+hammer the server with too many new (i.e. uncached) SMTP-over-TLS
+sessions. Cached sessions are much less expensive in terms of CPU
+cycles. Use the smtpd_client_new_tls_session_rate_limit parameter
+to specify a limit that is at least the inbound client concurrency
+limit, or else you may deny legitimate service requests.
+
+Major changes - VERP
+--------------------
+
+[Incompat 20050615] The new DSN support conflicts with VERP support.
+For Sendmail compatibility, Postfix now uses the sendmail -V command
+line option for DSN.  In order to request VERP style delivery, you
+must now specify -XV instead of -V.  The Postfix sendmail command
+will recognize if you try to use -V for VERP-style delivery.  It
+will do the right thing and will remind you of the new syntax.
+
+Major changes - XCLIENT and XFORWARD
+------------------------------------
+
+[Incompat 20060611] The SMTP server XCLIENT implementation has
+changed. The SMTP server now resets state to the initial server
+greeting stage, immediately before the EHLO/HELO greeting.  This
+was needed to correctly simulate the effect of connection-level
+access restrictions.  Without this change, XCLIENT would not work
+at all with Milter applications.
+
+[Incompat 20060611] The SMTP server XCLIENT and XFORWARD commands
+now expect that attributes are xtext encoded (RFC 1891). For backwards
+compatibility they will also accept unencoded attribute values. The
+XFORWARD client code in the SMTP client and in the SMTPD_PROXY
+client now always encode attribute values. This change will have a
+visible effect only for malformed hostname and helo parameter values.
+
+For more details, see the XCLIENT_README and XFORWARD_README
+documents.
+
+Major changes - address manipulation
+------------------------------------
+
+[Incompat 20060123] Postfix now preserves uppercase information
+while mapping addresses with canonical, virtual, relocated or generic
+maps; this happens even with $number substitutions in regular
+expression maps. However, the local(8) and virtual(8) delivery
+agents still fold addresses to lower case.
+
+As a side effect, Postfix now also does a better job at being case
+insensitive where it should be, for example while searching per-host
+TLS policies or SASL passwords.
+
+By default, Postfix now folds the search string to lowercase only
+with tables that have fixed-case lookup fields such as btree:,
+hash:, dbm:, ldap:, or *sql:. The search string is no longer case
+folded with tables whose lookup fields can match both upper or lower
+case, such as regexp:, pcre:, or cidr:.
+
+For safety reasons, Postfix no longer allows $number substitution
+in regexp: or pcre: transport tables or per-sender relayhost tables.
+
+Major changes - bounce message templates
+----------------------------------------
+
+[Feature 20051113] Configurable bounce messages, based on a format
+that was developed by Nicolas Riendeau. The file with templates is
+specified with the bounce_template_file parameter. Details are in
+the bounce(5) manual page, and examples of the built-in templates
+can be found in $config_directory/bounce.cf.default. The template
+for the default bounce message looks like this:
+
+    failure_template = <<EOF
+    Charset: us-ascii
+    From: MAILER-DAEMON (Mail Delivery System)
+    Subject: Undelivered Mail Returned to Sender
+    Postmaster-Subject: Postmaster Copy: Undelivered Mail
+
+    This is the $mail_name program at host $myhostname.
+
+    I'm sorry to have to inform you that your message could not
+    be delivered to one or more recipients. It's attached below.
+
+    For further assistance, please send mail to <postmaster>
+
+    If you do so, please include this problem report. You can
+    delete your own text from the attached returned message.
+
+                            The $mail_name program
+    EOF
+
+Major changes - built-in filters
+--------------------------------
+
+[Feature 20050828] Configurable filters to reject or remove unwanted
+characters in email content. The message_reject_characters and
+message_strip_characters parameters understand the usual C-like
+escape sequences: \a \b \f \n \r \t \v \ddd (up to three octal
+digits) and \\.
+
+[Incompat 20050828] When a header/body_checks rule or when
+message_reject_characters rejects mail that was submitted with the
+Postfix sendmail command (or re-queued with "postsuper -r"), the
+returned message is now limited to just the message headers, to
+avoid the risk of exposure to harmful content in the message body
+or attachments.
+
+Major changes - database support
+--------------------------------
+
+[Incompat 20060611] The PostgreSQL client was updated after the
+PostgreSQL developers made major database API changes in response
+to SQL injection problems.  This breaks support for PGSQL versions
+prior to 8.1.4, 8.0.8, 7.4.13, and 7.3.15. Support for these requires
+major code changes which are not possible in the time that is left
+for completing the Postfix 2.3 stable release.
+
+Major changes - enhanced status codes
+-------------------------------------
+
+[Feature 20050328] This release introduces support for RFC 3463
+enhanced status codes.  For example, status code 5.1.1 means
+"recipient unknown". Postfix recognizes enhanced status codes in
+remote server replies, generates enhanced status codes while handling
+email, and reports enhanced status codes in non-delivery notifications.
+This improves the user experience with mail clients that translate
+enhanced status codes into text in the user's own language.
+
+You can, but don't have to, specify RFC 3463 enhanced status codes
+in the output from commands that receive mail from a pipe. If a
+command terminates with non-zero exit status, and an enhanced status
+code is present at the beginning of the command output, then that
+status code takes precedence over the non-zero exit status.
+
+You can, but don't have to, specify RFC 3463 enhanced status codes
+in Postfix access maps, header/body_checks REJECT actions, or in
+RBL replies.  For example:
+
+    REJECT 5.7.1 You can't go here from there
+
+The status 5.7.1 means "no authorization, message refused", and is
+the default for access maps, header/body_checks REJECT actions, and
+for RBL replies.
+
+[Feature 20050328] If you specify your own enhanced status code,
+the Postfix SMTP server will automatically change a leading '5'
+digit (hard error) into '4' where appropriate.  This is needed, for
+example, with soft_bounce=yes.
+
+[Feature 20050510] This release improves usability of enhanced
+status codes in Postfix access tables, RBL reply templates and in
+transport maps that use the error(8) delivery agent.
+
+- When the SMTP server rejects a sender address, it transforms a
+  recipient DSN status (e.g., 4.1.1-4.1.6) into the corresponding
+  sender DSN status, and vice versa.
+
+- When the SMTP server rejects non-address information (such as the
+  HELO command parameter or the client hostname/address), it
+  transforms a sender or recipient DSN status into a generic
+  non-address DSN status (e.g., 4.0.0).
+
+These transformations are needed when the same access table or RBL
+reply template are used for client, helo, sender, or recipient
+restrictions; or when the same error(8) mailer information is used
+for both senders and recipients.
+
+Major changes - local alias expansion
+-------------------------------------
+
+[Incompat 20051011] The Postfix local(8) delivery agent no longer
+updates its idea of the Delivered-To: address while it expands
+aliases or .forward files. With deeply nested aliases or .forward
+files, this can greatly reduce the number of queue files and cleanup
+process instances. To get the earlier behavior, specify
+"frozen_delivered_to = no".
+
+The frozen_delivered_to feature can help to alleviate a long-standing
+problem with multiple deliveries to recipients that are listed
+multiple times in a hierarchy of nested aliases. For this to work,
+only the top-level alias should have an owner- alias, and none of
+the subordinate aliases.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20060515] Milter support introduces new logfile event
+types: milter-reject, milter-discard and milter-hold, that identify
+actions from Milter applications. This may affect logfile processing
+software.
+
+[Incompat 20051106] The relay=... logging has changed and now
+includes the remote SMTP server port number as hostname[hostaddr]:port.
+
+[Incompat 20060112] The Postfix SMTP/LMTP client by default no
+longer allows DNS CNAME records to override the server hostname
+that is used for logging, SASL password lookup, TLS policy selection
+and TLS server certificate verification. Specify
+"smtp_cname_overrides_servername = yes" to get the old behavior.
+
+[Incompat 20051105] All delay logging now has sub-second resolution,
+including the over-all "delay=nnn" logging.  A patch is available
+for pflogsumm (pflogsumm-conn-delays-dsn-patch). The qshape script
+has been updated (auxiliary/qshape/qshape.pl).
+
+[Feature 20051103] This release makes a beginning with a series of
+new attributes in Postfix logfile records.
+
+- Better insight into the nature of performance bottle necks, with
+  detailed logging of delays in various stages of message delivery.
+  Postfix logs additional delay information as "delays=a/b/c/d"
+  where a=time before queue manager, including message transmission;
+  b=time in queue manager; c=connection setup time including DNS,
+  HELO and TLS; d=message transmission time.
+
+- Logging of the connection reuse count when SMTP connections are
+  used for more than one message delivery.  This information is
+  needed because Postfix can now reuse connections hundreds of times
+  or more. Logging of the connection reuse count can help to diagnose
+  inter-operability problems with servers that suffer from memory
+  leaks or other resource leaks.
+
+At this point the Postfix logging for a recipient looks like this:
+
+    Nov  3 16:04:31 myname postfix/smtp[30840]: 19B6B2900FE:
+    to=<wietse@test.example.com>, orig_to=<wietse@test>,
+    relay=mail.example.com[1.2.3.4], conn_use=2, delay=0,
+    delays=0/0.01/0.05/0.1, dsn=2.0.0, status=sent (250 2.0.0 Ok)
+
+The following two logfile fields may or may not be present:
+
+    orig_to     This is omitted when the address did not change.
+    conn_use    This is omitted when a connection is used once.
+
+[Incompat 20050503] The format of some "warning:" messages in the
+maillog has changed so that they are easier to sort:
+
+- The logging now talks about "access table", instead of using three
+  different expressions "access table", "access map" and "SMTPD
+  access map" for the same thing.
+
+- "non-SMTP command" is now logged BEFORE the client name/address
+  and the offending client input, instead of at the end.
+
+[Incompat 20050328] The logging format has changed. Postfix delivery
+agents now log the RFC 3463 enhanced status code as "dsn=x.y.z"
+where y and z can be up to three digits each.
+
+[Incompat 20051208] The LMTP client now reports the server as
+"myhostname[/path/name]".  With the real server hostname in delivery
+status reports, the information will be more useful.
+
+Major changes - performance
+---------------------------
+
+[Incompat 20051105] All delay logging now has sub-second resolution,
+including the over-all "delay=nnn" logging.  A patch is available
+for pflogsumm (pflogsumm-conn-delays-dsn-patch). The qshape script
+has been updated (auxiliary/qshape/qshape.pl).
+
+[Incompat 20050622] The Postfix SMTP client by default limits the
+number of MX server addresses to smtp_mx_address_limit=5. Previously
+this limit was disabled by default. The new limit prevents Postfix
+from spending lots of time trying to connect to lots of bogus MX
+servers.
+
+[Feature 20051026] This snapshot addresses a performance stability
+problem with remote SMTP servers. The problem is not specific to
+Postfix: it can happen when any MTA sends large amounts of SMTP
+email to a site that has multiple MX hosts. The insight that led
+to the solution, as well as an initial implementation, are due to
+Victor Duchovni.
+
+The problem starts when one of a set of MX hosts becomes slower
+than the rest.  Even though SMTP clients connect to fast and slow
+MX hosts with equal probability, the slow MX host ends up with more
+simultaneous inbound connections than the faster MX hosts, because
+the slow MX host needs more time to serve each client request.
+
+The slow MX host becomes a connection attractor.  If one MX host
+becomes N times slower than the rest, it dominates mail delivery
+latency unless there are more than N fast MX hosts to counter the
+effect. And if the number of MX hosts is smaller than N, the mail
+delivery latency becomes effectively that of the slowest MX host
+divided by the total number of MX hosts.
+
+The solution uses connection caching in a way that differs from
+Postfix 2.2.  By limiting the amount of time during which a connection
+can be used repeatedly (instead of limiting the number of deliveries
+over that connection), Postfix not only restores fairness in the
+distribution of simultaneous connections across a set of MX hosts,
+it also favors deliveries over connections that perform well, which
+is exactly what we want.
+
+The smtp_connection_reuse_time_limit feature implements the connection
+reuse time limit as discussed above.  It limits the amount of time
+after which an SMTP connection is no longer stored into the connection
+cache. The default limit, 300s, can result in a huge number of
+deliveries over a single connection.
+
+This solution will be complete when Postfix logging is updated to
+include information about the number of times that a connection was
+used. This information is needed to diagnose inter-operability
+problems with servers that exhibit bugs when they receive multiple
+messages over the same connection.
+
+[Feature 20051011] Optional protection against SMTP clients that
+hammer the server with too many new (i.e. uncached) SMTP-over-TLS
+sessions. Cached sessions are much less expensive in terms of CPU
+cycles. Use the smtpd_client_new_tls_session_rate_limit parameter
+to specify a limit that is at least the inbound client concurrency
+limit, or else you may deny legitimate service requests.
+
+[Feature 20051011] Optional suppression of remote SMTP client
+hostname lookup and hostname verification. Specify "smtpd_peername_lookup
+= no" to eliminate DNS lookup latencies, but do so only under extreme
+conditions, as it makes Postfix logging less informative.
+
+Major changes - portability
+---------------------------
+
+[Incompat 20050716] Internal interfaces have changed; this may break
+third-party patches because the types of function arguments and of
+result values have changed.  The types of buffer lengths and offsets
+were changed from "int" or "unsigned int" (32 bit on 32-bit and
+LP64 systems) to "ssize_t" or "size_t" (64 bit on LP64 systems, 32
+bit on 32-bit systems).
+
+This change makes no difference in Postfix behavior on 32-bit
+systems. On LP64 systems, however, this change not only eliminates
+some obscure portability bugs, it also eliminates unnecessary
+conversions between 32/64 bit integer types, because many system
+library routines take "(s)size_t" arguments or return "(s)size_t"
+values.
+
+This change may break software on LP64 systems 1) when Postfix is
+linked with pre-compiled code that was compiled with old Postfix
+interface definitions and 2) when compiling Postfix source that was
+modified by a third-party patch: incorrect code will be generated
+when the patch passes the wrong integer argument type in contexts
+that disable automatic argument type conversions.  Examples of such
+contexts are formatting with printf-like arguments, and invoking
+functions that write Postfix request or reply attributes across
+inter-process communication channels.  Unfortunately, gcc reports
+"(unsigned) int" versus "(s)size_t" format string argument mis-matches
+only on LP64 systems.
+
+Major changes - safety
+----------------------
+
+[Incompat 20051121] Although the permit_mx_backup feature still
+accepts mail for authorized destinations (see permit_mx_backup for
+definition), with all other destinations it now requires that the
+local MTA is listed as non-primary MX. This prevents mail loop
+problems when someone points the primary MX record at a Postfix
+system.
+
+[Incompat 20051011] The Postfix local(8) delivery agent no longer
+updates its idea of the Delivered-To: address while it expands
+aliases or .forward files. With deeply nested aliases or .forward
+files, this can greatly reduce the number of queue files and cleanup
+process instances. To get the earlier behavior, specify
+"frozen_delivered_to = no".
+
+The frozen_delivered_to feature can help to alleviate a long-standing
+problem with multiple deliveries to recipients that are listed
+multiple times in a hierarchy of nested aliases. For this to work,
+only the top-level alias should have an owner- alias, and none of
+the subordinate aliases.
+
+[Incompat 20050828] When a header/body_checks rule or when
+message_reject_characters rejects mail that was submitted with the
+Postfix sendmail command (or re-queued with "postsuper -r"), the
+returned message is now limited to just the message headers, to
+avoid the risk of exposure to harmful content in the message body
+or attachments.
+
+[Incompat 20051202] The Postfix SMTP server now refuses to receive
+mail from the network if it isn't running with postfix mail_owner
+privileges.  This prevents surprises when, for example, "sendmail
+-bs" is configured to run as root from xinetd.
+
+[Incompat 20060123] For safety reasons, Postfix no longer allows
+$number substitution in regexp: or pcre: transport tables or
+per-sender relayhost tables.
+
+[Incompat 20060112] The Postfix SMTP/LMTP client by default no
+longer allows DNS CNAME records to override the server hostname
+that is used for logging, SASL password lookup, TLS policy selection
+and TLS server certificate verification. Specify
+"smtp_cname_overrides_servername = yes" to get the old behavior.
--- a/RELEASE_NOTES-2.4
+++ b/RELEASE_NOTES-2.4
@ -0,0 +1,198 @@
+The stable Postfix release is called postfix-2.4.x where 2=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-2.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.
+
+Major changes - critical
+------------------------
+
+See RELEASE_NOTES-2.3 if you upgrade from Postfix 2.2 or earlier.
+
+[Incompat 20070122] To take advantage of the new support for BSD
+kqueue, Linux epoll, or Solaris /dev/poll, you must restart (not
+reload) Postfix after upgrading from Postfix 2.3.
+
+[Incompat 20061209] If you upgrade Postfix without restarting, you
+MUST execute "postfix reload", otherwise the queue manager may log
+a warnings with:
+
+    warning: connect to transport retry: Connection refused
+
+[Incompat 20061209] The upgrade procedure adds a new "retry" service
+to the master.cf file.  If you make the mistake of copying old
+Postfix configuration files over the new files, the queue manager
+may log warnings with:
+
+    warning: connect to transport retry: Connection refused
+
+To fix your master.cf file, use "postfix upgrade-configuration"
+followed by "postfix reload".
+
+Major changes - safety
+----------------------
+
+[Incompat 20070222] As a safety measure, Postfix now by default
+creates mailbox dotlock files on all systems. This prevents problems
+with GNU POP3D which subverts kernel locking by creating a new
+mailbox file and deleting the old one.
+
+Major changes - Milter support
+------------------------------
+
+[Feature 20070121] The support for Milter header modification
+requests was revised.  With minimal change in the on-disk representation,
+the code was greatly simplified, and regression tests were updated
+to ensure that old errors were not re-introduced.  The queue file
+format is entirely backwards compatible with Postfix 2.3.
+
+[Feature 20070116] Support for Milter requests to replace the message
+body.  Postfix now implements all the header/body modification
+requests that are available with Sendmail 8.13.
+
+[Incompat 20070116] A new field is added to the queue file "size"
+record that specifies the message content length.  Postfix 2.3 and
+older Postfix 2.4 snapshots will ignore this field, and will report
+the message size as it was before the body was replaced.
+
+Major changes - TLS support
+---------------------------
+
+[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
+attributes (client ccert_subject, ccert_issuer) only after successful
+client certificate verification. The reason is that the certification
+verification status itself is not available in the policy request.
+
+[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
+fingerprint information even when the certificate itself was not
+verified.
+
+[Incompat 20061214] The remote SMTP client TLS certificate fingerprint
+can be used for access control even when the certificate itself was
+not verified.
+
+[Incompat 20061006] The format of SMTP server TLS session cache
+lookup keys has changed.  The lookup key now includes the master.cf
+service name.
+
+Major changes - performance
+---------------------------
+
+[Feature 20070212] Better support for systems that run thousands
+of Postfix processes.  Postfix now supports FreeBSD kqueue(2),
+Solaris poll(7d) and Linux epoll(4) as more scalable alternatives
+to the traditional select(2) system call, and uses poll(2) when
+examining a single file descriptor for readability or writability.
+These features are supported on sufficiently recent versions of
+FreeBSD, NetBSD, OpenBSD, Solaris and Linux; support for other
+systems will be added as evidence becomes available that usable
+implementations exist.
+
+[Incompat 20070201] Some default settings have been adjusted to
+better match contemporary requirements:
+
+- queue_run_delay and minimal_backoff_time were reduced from 1000s
+  to 300s so that deliveries are retried earlier after the first
+  failure.
+
+- ipc_idle was reduced from 100s to 5s, so that tlsmgr and scache
+  clients will more quickly release unused file handles.
+
+[Feature 20061209] Improved worst-case (old and new) queue manager
+performance when deferring or bouncing large amounts of mail. Instead
+of talking to the bounce or defer service synchronously, this work
+is now done in the background by the error or retry service.
+
+[Feature 20061209] Improved worst-case (new) queue manager performance
+when delivering multi-recipient mail. The queue manager now proactively
+reads recipients from the queue file, instead of waiting for the
+slowest deliveries to complete before reading in new recipients.
+This introduces two parameters: default_recipient_refill_limit (how
+many recipient slots to refill at a time) and
+default_recipient_refill_delay (how long to wait between refill
+operations). These two parameters act as defaults for optional
+per-transport settings.
+
+Major changes - delivery status notifications
+---------------------------------------------
+
+[Incompat 20061209] Small changes were made to the default bounce
+message templates, to prevent HTML-aware software from hiding or
+removing the text "<postmaster>", and producing misleading text.
+
+[Incompat 20060806] Postfix no longer announces its name in delivery
+status notifications.  Users believe that Wietse provides a free
+help desk service that solves all their email problems.
+
+Major changes - ETRN support
+----------------------------
+
+[Feature 20061217] More precise queue flushing with the ETRN,
+"postqueue -s site", and "sendmail -qRsite" commands, after
+minimization of race conditions.  New per-queue-file flushing with
+"postqueue -i queueid" and "sendmail -qIqueueid".
+
+Major changes - small office/home office support
+------------------------------------------------
+
+[Incompat 20061217] Postfix no longer requires a domain name. It
+uses "localdomain" as the default Internet domain name when no
+domain is specified via main.cf or via the machine's hostname.
+
+Major changes - SMTP access control
+-----------------------------------
+
+[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
+attributes (client ccert_subject, ccert_issuer) only after successful
+client certificate verification. The reason is that the certification
+verification status itself is not available in the policy request.
+
+[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
+fingerprint information even when the certificate itself was not
+verified.
+
+[Incompat 20061214] The remote SMTP client TLS certificate fingerprint
+can be used for
+access control even when the certificate itself was not verified.
+
+[Incompat 20061209] The Postfix installation procedure no longer
+updates main.cf with "unknown_local_recipient_reject_code = 450".
+Four years after the introduction of mandatory recipient validation,
+this transitional tool is no longer neeed.
+
+Major changes - workarounds
+---------------------------
+
+[Incompat 20070222] As a safety measure, Postfix now by default
+creates mailbox dotlock files on all systems. This prevents problems
+with GNU POP3D which subverts kernel locking by creating a new
+mailbox file and deleting the old one.
+
+[Feature 20061209] Better interoperability with non-conforming SMTP
+servers that reply and disconnect before Postfix has sent the
+complete message content.
+
+[Feature 20061209] Better support for queue file systems on file
+servers with drifting clocks. Clock skew can be a problem, because
+Postfix does not deliver mail until the local clock catches up with
+the queue file's last modification time stamp. On systems with
+usable futimes() or equivalent (Solaris, *BSD, MacOS, but not Linux),
+Postfix now always explicitly sets the queue file last modification
+time stamps while creating a queue file.  On systems without usable
+futimes() (Linux, and ancient versions of Solaris, SunOS and *BSD)
+Postfix keeps using the slower utime() system call to update queue
+file time stamps when the file system clock is off with respect to
+the local system clock, and logs a warning.
+
+[Feature 20061006] Individual CISCO PIX bug workarounds are now
+on/off configurable.  This introduces new parameters: smtp_pix_workarounds
+(default: disable_esmtp, delay_dotcrlf) and smtp_pix_workaround_maps
+(workarounds indexed by server IP address).  The default settings
+are backwards compatible.
--- a/RELEASE_NOTES-2.5
+++ b/RELEASE_NOTES-2.5
@ -0,0 +1,376 @@
+The stable Postfix release is called postfix-2.5.x where 2=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-2.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.
+
+Incompatibility with Postfix 2.3 and earlier
+--------------------------------------------
+
+If you upgrade from Postfix 2.3 or earlier, read RELEASE_NOTES-2.4
+before proceeding.
+
+Major changes - critical
+------------------------
+
+[Incompat 20071224] The protocol to send Milter information from
+smtpd(8) to cleanup(8) processes was cleaned up. If you use the
+Milter feature, and upgrade a live Postfix system, you may see an
+"unexpected record type" warning from a cleanup(8) server process.
+To prevent this, execute the command "postfix reload".  The
+incompatibility affects only systems that use the Milter feature.
+It does not cause loss of mail, just a minor delay until the remote
+SMTP client retries.
+
+[Incompat 20071212] The allow_min_user feature now applies to both
+sender and recipient addresses in SMTP commands. With earlier Postfix
+versions, only recipients were subject to the allow_min_user feature,
+and the restriction took effect at mail delivery time, causing mail
+to be bounced later instead of being rejected immediately.
+
+[Incompat 20071206] The "make install" and "make upgrade" procedures
+now create a Postfix-owned directory for Postfix-writable data files
+such as caches and random numbers. The location is specified with
+the "data_directory" parameter (default: "/var/lib/postfix"), and
+the ownership is specified with the "mail_owner" parameter.
+
+[Incompat 20071206] The tlsmgr(8) and verify(8) servers no longer
+use root privileges when opening the address_verify_map,
+*_tls_session_cache_database, and tls_random_exchange_name cache
+files.  This avoids a potential security loophole where the ownership
+of a file (or directory) does not match the trust level of the
+content of that file (or directory).
+
+[Incompat 20071206] The tlsmgr(8) and verify(8) cache files should
+now be stored as Postfix-owned files under the Postfix-owned
+data_directory.  As a migration aid, attempts to open these files
+under a non-Postfix directory are redirected to the Postfix-owned
+data_directory, and a warning is logged.
+
+This is an example of the warning messages:
+
+    Dec  6 12:56:22 bristle postfix/tlsmgr[7899]: warning: request
+	to update file /etc/postfix/prng_exch in non-postfix directory
+	/etc/postfix
+
+    Dec  6 12:56:22 bristle postfix/tlsmgr[7899]: warning: redirecting
+	the request to postfix-owned data_directory /var/lib/postfix
+
+If you wish to continue using a pre-existing tls_random_exchange_name
+or address_verify_map file, move it to the Postfix-owned data_directory
+and change ownership from root to Postfix (that is, change ownership
+to the account specified with the mail_owner configuration parameter).
+
+[Feature 20071205] The "make install" and "make upgrade" procedures
+now create a Postfix-owned directory for Postfix-writable data files
+such as caches and random numbers. The location is specified with
+the "data_directory" parameter (default: "/var/lib/postfix"), and
+the ownership is specified with the "mail_owner" parameter.
+
+[Incompat 20071203] The "make upgrade" procedure adds a new service
+"proxywrite" to the master.cf file, for read/write lookup table
+access. If you copy your old configuration file over the updated
+one, you may see warnings in the maillog file like this:
+
+   connect #xx to subsystem private/proxywrite: No such file or directory
+
+To recover, run "postfix upgrade-configuration" again.
+
+[Incompat 20070613] The pipe(8) delivery agent no longer allows
+delivery with the same group ID as the main.cf postdrop group.
+
+Major changes - malware defense
+-------------------------------
+
+[Feature 20080107] New "pass" service type in master.cf.  Written
+years ago, this allows future front-end daemons to accept all
+connections from the network, and to hand over connections from
+well-behaved clients to Postfix.  Since this feature uses file
+descriptor passing, it imposes no overhead once a connection is
+handed over to Postfix.  See master(5) for a few details.
+
+[Feature 20070911] Stress-adaptive behavior. When a "public" network
+service runs into an "all processes are busy" condition, the master(8)
+daemon logs a warning, restarts the service, and runs it with "-o
+stress=yes" on the command line (under normal conditions it runs
+the service with "-o stress=" on the command line).  This can be
+used to make main.cf parameter settings stress dependent, for
+example:
+
+/etc/postfix/main.cf:
+    smtpd_timeout = ${stress?10}${stress:300}
+    smtpd_hard_error_limit = ${stress?1}${stress:20}
+
+Translation: under conditions of stress, use an smtpd_timeout value
+of 10 seconds instead of 300, and use smtpd_hard_error_limit of 1
+instead of 20. The syntax is explained in the postconf(5) manpage.
+
+The STRESS_README file gives examples of how to mitigate flooding
+problems.
+
+Major changes - tls support
+---------------------------
+
+[Incompat 20080109] TLS logging output has changed to make it more
+useful. Existing logfile parser regular expressions may need
+adjustment.
+
+- More log entries include the "hostnamename[ipaddress]" of the
+  remote SMTP peer.
+
+- Certificate trust chain error reports show only the first
+  error certificate (closest to the trust chain root), and the
+  reporting is more human-readable for the most likely errors.
+
+- After the completion of the TLS handshake, the session is logged
+  with TLS loglevel >= 1 as either "Untrusted", "Trusted" or
+  "Verified" (SMTP client only).
+  - "Untrusted" means that the certificate trust chain is invalid,
+    or that the root CA is not trusted.
+  - "Trusted" means that the certificate trust chain is valid, and
+    that the root CA is trusted.
+  - "Verified" means that the certificate meets the SMTP client's
+    matching criteria for the destination:
+    - In the case of a destination name match, "Verified" also
+      implies "Trusted".
+    - In the case of a fingerprint match, CA trust is not applicable.
+
+- The logging of protocol states with TLS loglevel >= 2 no longer
+  reports bogus error conditions when OpenSSL asks Postfix to refill
+  (or flush) network I/O buffers.  This loglevel is for debugging
+  only; use 0 or 1 in production configurations.
+
+[Feature 20080109] The Postfix SMTP client has a new "fingerprint"
+security level.  This avoids dependencies on CAs, and relies entirely
+on bi-lateral exchange of public keys (really self-signed or private
+CA signed X.509 public key certificates). Scalability is clearly
+limited. For details, see the fingerprint discussion in TLS_README.
+
+[Feature 20080109] The Postfix SMTP server can now use SHA1 instead
+of MD5 to compute remote SMTP client certificate fingerprints. For
+backwards compatibility, the default algorithm is MD5.  For details,
+see the "smtpd_tls_fingerprint_digest" parameter in the postconf(5)
+manual.
+
+[Feature 20080109] The maximum certificate trust chain depth
+(verifydepth) is finally implemented in the Postfix TLS library.
+Previously, the parameter had no effect. The default depth was
+changed to 9 (the OpenSSL default) for backwards compatibility.
+
+If you have explicity limited the verification depth in main.cf,
+check that the configured limit meets your needs. See the
+"lmtp_tls_scert_verifydepth", "smtp_tls_scert_verifydepth" and
+"smtpd_tls_ccert_verifydepth" parameters in the postconf(5) manual.
+
+[Feature 20080109] The selection of SSL/TLS protocols for mandatory
+TLS can now use exclusion rather than inclusion. Either form is
+acceptable; see the "lmtp_tls_mandatory_protocols",
+"smtp_tls_mandatory_protocols" and "smtpd_tls_mandatory_protocols"
+parameters in the postconf(5) manual.
+
+Major changes - scheduler
+-------------------------
+
+[Feature 20071130] Revised queue manager with separate mechanisms
+for per-destination concurrency control and for dead destination
+detection.  The concurrency control supports less-than-1 feedback
+to allow for more gradual concurrency adjustments, and uses hysteresis
+to avoid rapid oscillations.  A destination is declared "dead" after
+a configurable number of pseudo-cohorts(*) reports connection or
+handshake failure.
+
+(*) A pseudo-cohort is a number of delivery requests equal to a
+    destination's delivery concurrency.
+
+The drawbacks of the old +/-1 feedback scheduler are a) overshoot
+due to exponential delivery concurrency growth with each pseudo-cohort(*)
+(5-10-20...); b) throttling down to zero concurrency after a single
+pseudo-cohort(*) failure. The latter was especially an issue with
+low-concurrency channels where a single failure could be sufficient
+to mark a destination as "dead", and suspend further deliveries.
+
+New configuration parameters: destination_concurrency_feedback_debug,
+default_destination_concurrency_positive_feedback,
+default_destination_concurrency_negative_feedback,
+default_destination_concurrency_failed_cohort_limit, as well as
+transport-specific versions of the same.
+
+The default parameter settings are backwards compatible with older
+Postfix versions. This may change after better defaults are field
+tested.
+
+The updated SCHEDULER_README document describes the theory behind
+the new concurrency scheduler, as well as Patrik Rak's preemptive
+job scheduler. See postconf(5) for more extensive descriptions of
+the configuration parameters.
+
+Major changes - small/home office
+---------------------------------
+
+[Feature 20080115] Preliminary SOHO_README document that combines
+bits and pieces from other document in one place, so that it is
+easier to find. This document describes the "mail sending" side
+only.
+
+[Feature 20071202] Output rate control in the queue manager. For
+example, specify "smtp_destination_rate_delay = 5m", to pause five
+minutes between message deliveries. More information in the postconf(5)
+manual under "default_destination_rate_delay".
+
+Major changes - smtp client
+---------------------------
+
+[Incompat 20080114] The Postfix SMTP client now by default defers
+mail after a remote SMTP server rejects a SASL authentication
+attempt.  Specify "smtp_sasl_auth_soft_bounce = no" for the old
+behavior.
+
+[Feature 20080114] The Postfix SMTP client can now avoid making
+repeated SASL login failures with the same server, username and
+password.  To enable this safety feature, specify for example
+"smtp_sasl_auth_cache_name = proxy:btree:/var/lib/postfix/sasl_auth_cache"
+(access through the proxy service is required). Instead of trying
+to SASL authenticate, the Postfix SMTP client defers or bounces
+mail as controlled with the new smtp_sasl_auth_soft_bounce configuration
+parameter.
+
+[Feature 20071111] Header/body checks are now available in the SMTP
+client, after the implementation was moved from the cleanup server
+to a library module.  The SMTP client provides only actions that
+don't change the message delivery time or destination: warn, replace,
+prepend, ignore, dunno, ok.
+
+[Incompat 20070614] By default, the Postfix Cyrus SASL client no
+longer sends a SASL authoriZation ID (authzid); it sends only the
+SASL authentiCation ID (authcid) plus the authcid's password. Specify
+"send_cyrus_sasl_authzid = yes" to get the old behavior.
+
+Major changes - smtp server
+---------------------------
+
+[Feature 20070724] Not really major. New support for RFC 3848
+(Received: headers with ESMTPS, ESMTPA, or ESMTPSA); updated SASL
+support according to RFC 4954, resulting in small changes to SMTP
+reply codes and (DSN) enhanced status codes.
+
+Major changes - milter
+----------------------
+
+[Incompat 20071224] The protocol to send Milter information from
+smtpd(8) to cleanup(8) processes was cleaned up. If you use the
+Milter feature, and upgrade a live Postfix system, you may see an
+"unexpected record type" warning from a cleanup(8) server process.
+To prevent this, execute the command "postfix reload".  The
+incompatibility affects only systems that use the Milter feature.
+It does not cause loss of mail, just a minor delay until the remote
+SMTP client retries.
+
+[Feature 20071221] Support for most of the Sendmail 8.14 Milter
+protocol features.
+
+To enable the new features specify "milter_protocol = 6" and link
+the filter application with a libmilter library from Sendmail 8.14
+or later.
+
+Sendmail 8.14 Milter features supported at this time:
+
+- NR_CONN, NR_HELO, NR_MAIL, NR_RCPT, NR_DATA, NR_UNKN, NR_HDR, 
+  NR_EOH, NR_BODY: The filter can tell Postfix that it won't reply
+  to some of the SMTP events that Postfix sends. This makes the      
+  protocol less chatty and improves performance.
+
+- SKIP: The filter can tell Postfix to skip sending the rest of    
+  the message body, which also improves performance.
+
+- HDR_LEADSPC: The filter can request that Postfix does not delete 
+  the first space character between header name and header value       
+  when sending a header to the filter, and that Postfix does not
+  insert a space character between header name and header value 
+  when receiving a header from the filter.  This fixes a limitation
+  in the old Milter protocol that can break DKIM and DK signatures.
+
+- SETSYMLIST: The filter can override one or more of the main.cf
+  milter_xxx_macros parameter settings.
+ 
+Sendmail 8.14 Milter features not supported at this time:
+
+- RCPT_REJ: report rejected recipients to the mail filter. 
+
+- CHGFROM: replace sender, with optional ESMTP command parameters.
+
+- ADDRCPT_PAR: add recipient, with optional ESMTP command parameters.
+
+It is unclear when (if ever) the missing features will be implemented.
+SMFIP_RCPT_REJ requires invasive changes in the SMTP server recipient
+processing and error handling.  SMFIR_CHGFROM and SMFIR_ADDRCPT_PAR
+require ESMTP command-line parsing in the cleanup server. Unfortunately,
+Sendmail's documentation does not specify what ESMTP options are
+supported, but only discusses examples of things that don't work.
+
+Major changes - address verification
+------------------------------------
+
+[Incompat 20070514] The default sender address for address verification
+probes was changed from "postmaster" to "double-bounce", so that
+the Postfix SMTP server no longer causes surprising behavior by
+excluding "postmaster" from SMTP server access controls.
+
+Major changes - ldap
+--------------------
+
+[Incompat 20071216] Due to an incompatible API change between
+OpenLDAP 2.0.11 and 2.0.12, an LDAP client compiled for OpenLDAP
+version <= 2.0.11 will refuse to work with an OpenLDAP library
+version >= 2.0.12 and vice versa.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20080109] TLS logging output has changed to make it more
+useful. Existing logfile parser regular expressions may need
+adjustment.
+
+- More log entries include the "hostnamename[ipaddress]" of the
+  remote SMTP peer.
+
+- Certificate trust chain error reports show only the first
+  error certificate (closest to the trust chain root), and the
+  reporting is more human-readable for the most likely errors.
+
+- After the completion of the TLS handshake, the session is logged
+  with TLS loglevel >= 1 as either "Untrusted", "Trusted" or
+  "Verified" (SMTP client only).
+  - "Untrusted" means that the certificate trust chain is invalid,
+    or that the root CA is not trusted.
+  - "Trusted" means that the certificate trust chain is valid, and
+    that the root CA is trusted.
+  - "Verified" means that the certificate meets the SMTP client's
+    matching criteria for the destination:
+    - In the case of a destination name match, "Verified" also
+      implies "Trusted".
+    - In the case of a fingerprint match, CA trust is not applicable.
+
+- The logging of protocol states with TLS loglevel >= 2 no longer
+  reports bogus error conditions when OpenSSL asks Postfix to refill
+  (or flush) network I/O buffers.  This loglevel is for debugging
+  only; use 0 or 1 in production configurations.
+
+[Incompat 20071216] The SMTP "transcript of session" email now
+includes the remote SMTP server TCP port number.
+
+Major changes - loop detection
+------------------------------
+
+[Incompat 20070422] [Incompat 20070422] When the pipe(8) delivery
+agent is configured to create the optional Delivered-To: header,
+it now first checks if that same header is already present in the
+message. If so, the message is returned as undeliverable. This test
+should have been included with Postfix 2.0 when Delivered-To: support
+was added to the pipe(8) delivery agent.
--- a/RELEASE_NOTES-2.6
+++ b/RELEASE_NOTES-2.6
@ -0,0 +1,300 @@
+The stable Postfix release is called postfix-2.6.x where 2=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-2.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 2.4 or earlier, read RELEASE_NOTES-2.5
+before proceeding.
+
+Major changes - multi-instance support
+--------------------------------------
+
+[Feature 20090121] Support for managing multiple Postfix instances.
+This can automatically apply your "postfix start" etc.  command to
+multiple Postfix instances, including upgrades to new Postfix
+versions.  Multi-instance support allows you to do the following
+and more:
+
+- Simplify post-queue content filter configuration by using separate
+  Postfix instances before and after the filter. This simplifies
+  trouble shooting and performance tuning.
+
+- Implement per-user content filters (or no filter) via transport
+  map lookups instead of content_filter settings. Mail for some
+  users can be sent directly from the before-filter instance to the
+  after-filter instance.
+
+- Test new configuration settings (on a different server IP address
+  or TCP port) without disturbing production instances.
+
+- Each additional Postfix instance uses a few files and directories,
+  plus memory for an extra master daemon and queue manager. The
+  pickup daemon is needed only if you use local submission or
+  "postsuper -r".
+
+Best of all, nothing changes when you use only one Postfix instance.
+
+The MULTI_INSTANCE_README file presents an introduction to
+multi-instance management. Multi-instance support is based on an
+API that is described in the postfix-wrapper(5) manual page.
+
+Major changes - milter support
+------------------------------
+
+[Feature 20090428] The following improvements have been made to the
+Milter implementation:
+
+- Improved compatibility of the {mail_addr} and {rcpt_addr} macros.
+
+- Support for the {mail_host}, {mail_mailer}, {rcpt_host} and
+{rcpt_mailer} macros.
+
+- Milter applications can now request rejected recipients with the
+SMFIP_RCPT_REJ feature. Rejected recipients are reported with
+{rcpt_mailer} = "error", {rcpt_host} = enhanced status code, and
+{rcpt_addr} = descriptive text. This feature requires "milter_protocol
+= 6" or higher (default as of Postfix 2.6).
+
+- Milters can now replace the envelope sender address with the
+SMFIR_CHGFROM request, and can add recipients with SMFIR_ADDRCPT_PAR.
+These implementations ignore ESMTP command parameters and log a
+warning message as follows:
+
+    warning: 100B22B3293: cleanup_chg_from: ignoring ESMTP arguments "whatever"
+    warning: 100B22B3293: cleanup_add_rcpt: ignoring ESMTP arguments "whatever"
+
+[Incompat 20090428] The default milter_protocol setting is increased
+from 2 to 6; this enables all available features up to and including
+Sendmail 8.14.0.  The new milter_protocol setting may break
+compatibility with older Milter libraries or applications, and may
+cause Postfix to log warning messages such as:
+
+    warning: milter inet:host:port: can't read packet header: Unknown error : 0
+
+    warning: milter inet:host:port: can't read packet header: Success
+
+    warning: milter inet:host:port: can't read SMFIC_DATA reply
+    packet header: No such file or directory
+
+To restore compatibility, specify "milter_protocol = 2" in main.cf.
+
+Major changes - security
+------------------------
+
+[Incompat 20080726] When a mailbox file is not owned by its recipient,
+the local and virtual delivery agents now log a warning and defer
+delivery.  Specify "strict_mailbox_ownership = no" to ignore such
+ownership discrepancies.
+
+Major changes - smtp server
+---------------------------
+
+[Feature 20080212] check_reverse_client_hostname_access, to make
+access decisions based on the unverified client hostname.  For
+safety reasons an OK result is not allowed.
+
+[Feature 20090210] With "reject_tempfail_action = defer", the Postfix
+SMTP server immediately replies with a 4xx status after some temporary
+error, instead of executing an implicit "defer_if_permit" action.
+
+[Feature 20090215] The Postfix SMTP server automatically hangs up
+after replying with "521". This makes overload handling more
+effective.  See also RFC 1846 for prior art on this topic.
+
+[Feature 20090228] The Postfix SMTP server maintains a per-session
+"improper command pipelining detected" flag. This flag can be tested
+at any time with reject_unauth_pipelining, and is raised whenever
+a client command is followed by unexpected commands or message
+content. The Postfix SMTP server logs the first command pipelining
+transgression as "improper command pipelining after <command> from
+<hostname>[<hostaddress>]".
+
+[Feature 20090212] Stress-dependent behavior is enabled by default.
+Under conditions of overload, smtpd_timeout is reduced from 300s
+to 10s, smtpd_hard_error_limit is reduced from 20 to 1, and
+smtpd_junk_command_limit is reduced from 100 to 1. This will reduce
+the impact of overload for most legitimate mail.
+
+[Feature 20080629] The Postfix SMTP server's SASL authentication
+was re-structured.  With "smtpd_tls_auth_only = yes", SASL support
+is now activated only after a successful TLS handshake. Earlier
+Postfix SMTP server versions could complain about unavailable SASL
+mechanisms during the plaintext phase of the SMTP protocol.
+
+[Incompat 20080510] In the policy delegation protocol, certificate
+common name attributes are now xtext encoded UTF-8. The xtext decoded
+attributes may contain any UTF-8 value except non-printable ASCII
+characters.
+
+Major changes - performance
+---------------------------
+
+[Feature 20090215] The Postfix SMTP server automatically hangs up
+after replying with "521". This makes overload handling more
+effective.  See also RFC 1846 for prior art on this topic.
+
+[Feature 20090212] Stress-dependent behavior is enabled by default.
+Under conditions of overload, smtpd_timeout is reduced from 300s
+to 10s, smtpd_hard_error_limit is reduced from 20 to 1, and
+smtpd_junk_command_limit is reduced from 100 to 1. This will reduce
+the negative impact of server overload for most legitimate mail.
+
+[Feature 20090109] Specify "tcp_windowsize = 65535" (or less) to
+work around routers with broken TCP window scaling implementations.
+This is perhaps more convenient than collecting tcpdump output and
+tuning kernel parameters by hand.  With Postfix TCP servers (smtpd(8),
+qmqpd(8)), this feature is implemented by the Postfix master(8)
+daemon.
+
+To change this parameter without stopping Postfix, you need to first
+terminate all Postfix TCP servers:
+
+    # postconf -e master_service_disable=inet
+    # postfix reload
+
+This immediately terminates all processes that accept network
+connections.  Then you enable Postfix TCP servers with the updated
+tcp_windowsize setting:
+
+    # postconf -e tcp_windowsize=65535 master_service_disable=
+    # postfix reload
+
+If you skip these steps with a running Postfix system, then the
+tcp_windowsize change will work only for Postfix TCP clients (smtp(8),
+lmtp(8)).
+
+Of course you can also do "postfix stop" and "postfix start",
+but that is more disruptive.
+
+Major changes - tls
+-------------------
+
+[Incompat 20090428] The Postfix SMTP client(!) no longer tries to
+use the obsolete SSLv2 protocol by default, as this may prevent the
+use of modern SSL features.  Lack of SSLv2 support should never be
+a problem, since SSLv3 was defined in 1996, and TLSv1 in 1999. You
+can undo the change by specifying empty main.cf values for
+smtp_tls_protocols and lmtp_tls_protocols. The Postfix SMTP server
+maintains SSLv2 support for backwards compatibility with ancient
+clients.
+
+[Feature 20081010] Controls for the protocols and ciphers that
+Postfix will use with opportunistic TLS. The smtp_tls_protocols,
+smtp_tls_ciphers, and equivalent parameters for lmtp and smtpd
+provide global settings; the SMTP client TLS policy table provides
+ciphers and protocols settings for specific peers.  Code by Victor
+Duchovni. Details are given in the TLS_README and postconf(5)
+documents.
+
+[Feature 20081108] Elliptic curve support. This requires OpenSSL
+version 0.9.9 or later.
+
+Major changes - address verification
+------------------------------------
+
+[Incompat 20080428] Postfix SMTP server replies for address
+verification have changed.  unverified_recipient_reject_code and
+unverified_sender_reject_code now handle "5XX" rejects only. The
+"4XX" rejects are now controlled with unverified_sender_defer_code
+and unverified_recipient_defer_code.
+
+[Feature 20080428] Finer control over the way Postfix reports address
+verification failures to remote SMTP clients.
+
+- unverified_sender/recipient_defer_code: the numerical Postfix
+  SMTP server reply code when address verification failed due
+  to some temporary error.
+
+- unverified_sender/recipient_reject_reason: fixed text that Postfix
+  will send to the remote SMTP client, instead of sending actual
+  address verification details.
+
+Major changes - dsn
+-------------------
+
+[Feature 20090307] New "lmtp_assume_final = yes" flag to send correct
+DSN "success" notifications when LMTP delivery is "final" as opposed
+to delivery into a content filter.
+
+Major changes - file organization
+---------------------------------
+
+[Incompat 20080207] According to discussions on the mailing list,
+too many people are breaking newly installed Postfix by overwriting
+the new /etc/postfix files with versions from an older release, and
+end up with a broken configuration that cannot repair itself. For
+this reason, postfix-script, postfix-files and post-install are
+moved away from /etc/postfix to $daemon_directory.
+
+Major changes - header rewriting
+--------------------------------
+
+[Incompat 20090330] Postfix now adds (Resent-) From:, Date:,
+Message-ID: or To: headers only when clients match
+$local_header_rewrite_clients.  Specify "always_add_missing_headers
+= yes" for backwards compatibility.  Adding such headers can break
+DKIM signatures that cover headers that are not present. For
+compatibility with existing logfile processing software, Postfix
+will log ``message-id=<>'' for messages without Message-Id header.
+
+Major changes - lmtp client
+---------------------------
+
+[Feature 20090307] New "lmtp_assume_final = yes" flag to send correct
+DSN "success" notifications when LMTP delivery is "final" as opposed
+to delivery into a content filter.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20090330] Postfix now adds (Resent-) From:, Date:,
+Message-ID: or To: headers only when clients match
+$local_header_rewrite_clients.  Specify "always_add_missing_headers
+= yes" for backwards compatibility.  Adding such headers can break
+DKIM signatures that cover headers that are not present.
+
+This changes the appearance of Postfix logging: to preserve
+compatibility with existing logfile processing software, Postfix
+will log ``message-id=<>'' for messages without Message-Id header.
+
+Major changes - mime
+--------------------
+
+[Feature 20080324] When the "postmap -q -" command reads lookup
+keys from standard input, it now understands RFC822 and MIME message
+format.  Specify -h or -b to use headers or body lines as lookup
+keys, and specify -hm or -bm to simulate header_checks or body_checks.
+
+Major changes - miscellaneous
+-----------------------------
+
+[Feature 20090109] Support to selectively disable master(8) listener
+ports by service type or by service name + type. Specify a list of
+service types ("inet", "unix", "fifo", or "pass") or "name.type"
+tuples, where "name" is the first field of a master.cf entry and
+"type" is a service type. Examples: to turn off the main SMTP
+listener port, use "master_service_disable = smtp.inet"; to turn
+off all TCP/IP listeners, use "master_service_disable = inet".
+Changing this parameter requires "postfix reload".
+
+Major changes - sasl
+--------------------
+
+[Feature 20090418] The Postfix SMTP server passes more information
+to the Dovecot authentication server: the "TLS is active" flag, the
+server IP address, and the client IP address.
+
+[Feature 20080629] The Postfix SMTP server's SASL authentication
+was re-structured.  With "smtpd_tls_auth_only = yes", SASL support
+is now activated only after a successful TLS handshake. Earlier
+Postfix SMTP server versions could complain about unavailable SASL
+mechanisms during the plaintext phase of the SMTP protocol.
+
--- a/RELEASE_NOTES-2.7
+++ b/RELEASE_NOTES-2.7
@ -0,0 +1,175 @@
+The stable Postfix release is called postfix-2.7.x where 2=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-2.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 2.5 or earlier, read RELEASE_NOTES-2.6
+before proceeding.
+
+Major changes - performance
+---------------------------
+
+[Feature 20100101] Periodic cache cleanup for the verify(8) cache
+database. The time between cache cleanup runs is controlled with
+the address_verify_cache_cleanup_interval (default: 12h) parameter.
+Cache cleanup increases the database access latency, so this should
+not be run more often than necessary.
+
+[Feature 20091109] Improved before-queue filter performance.  With
+"smtpd_proxy_options = speed_adjust", the Postfix SMTP server
+receives the entire message before it connects to a before-queue
+content filter. This means you can run more SMTP server processes
+with the same number of running content filter processes, and thus,
+handle more mail. This feature is off by default until it is proven
+to create no new problems.
+
+This addresses a concern of people in Europe who want to reject all
+bad mail with a before-queue filter. The alternative, an after-queue
+filter, means they would have to discard bad mail (which is illegal)
+or bounce bad mail (which violates good network citizenship).
+
+NOTE 1: When this feature is turned on, a filter cannot selectively
+reject recipients of a multi-recipient message.  It is OK to reject
+all recipients of the same multi-recipient message, as is deferring
+or accepting all recipients of the same multi-recipient message.
+
+NOTE 2: This feature increases the minimum amount of free queue
+space by $message_size_limit. The extra space is needed to save the
+message to a temporary file.
+
+To keep the performance overhead low, the same temporary file is
+reused with successive mail transactions (the file is of course
+truncated before reuse, so there is no information leakage).
+
+Major changes - sender reputation
+---------------------------------
+
+[Feature 20100117] The FILTER action in access maps or header/body_checks
+now supports sender reputation schemes that dynamically choose the
+SMTP source IP address. Typically, mail is split into classes, and
+all mail in class X is sent out from an SMTP client IP address that
+is reserved for class X.
+
+This is implemented by specifying FILTER actions with empty next-hop
+destinations in access maps or header/body_checks, and by configuring
+in master.cf one Postfix SMTP client for each SMTP source IP address,
+where each client has its own "-o myhostname" and "-o smtp_bind_address"
+settings.
+
+[Feature 20091209] sender_dependent_default_transport_maps, a
+per-sender override for default_transport. The original motivation
+is to use different output channels (with different source IP
+addresses) for different sender addresses, in order to keep their
+IP-based reputations separate from each other.
+
+The result value syntax is that of default_transport, not transport_maps.
+Thus, sender_dependent_default_transport_maps does not support the
+special transport_maps result value syntax for null transport, null
+nexthop, or null email address.
+
+This feature makes sender_dependent_relayhost_maps pretty much
+redundant (though sender_dependent_relayhost_maps will often be
+easier to use because that is the only thing people want to override).
+
+Major changes - address verification
+------------------------------------
+
+[Incompat 20100101] The verify(8) service now uses a persistent
+cache by default (address_verify_map = btree:$data_directory/verify_cache).
+To disable, specify "address_verify_map =" in main.cf.
+
+When periodic cache cleanup is enabled (the default), the verify(8)
+server now requires that the cache database supports the "delete"
+and "sequence" operations.  To disable periodic cache cleanup specify
+a zero address_verify_cache_cleanup_interval value.
+
+[Feature 20100101] Periodic cache cleanup for the verify(8) cache
+database. The time between cache cleanup runs is controlled with
+the address_verify_cache_cleanup_interval (default: 12h) parameter.
+Cache cleanup increases the database access latency, so this should
+not be run more often than necessary.
+
+Major changes - content filter
+------------------------------
+
+[Incompat 20100117] The meaning of an empty filter next-hop destination
+has changed (for example, "content_filter = foo:" or "FILTER foo:").
+Postfix now uses the recipient domain, instead of using $myhostname
+as in Postfix 2.6 and earlier.  To restore the old behavior specify
+"default_filter_nexthop = $myhostname", or specify a non-empty
+next-hop content filter destination.
+
+This compatibility option is not needed with SMTP-based content
+filters, because these always have an explicit next-hop destination.
+
+With pipe-based filters that specify no next-hop destination, the
+compatibility option restores the FIFO order of deliveries. Without
+the compatibility option, the delivery order for filters without
+next-hop destination changes to round-robin domain selection.
+
+[Feature 20100117] The FILTER action in access maps or header/body_checks
+now supports sender reputation schemes that dynamically choose the
+SMTP source IP address. Typically, mail is split into classes, and
+all mail in class X is sent out from an SMTP client IP address that
+is reserved for class X.
+
+This is implemented by specifying FILTER actions with empty next-hop
+destinations in access maps or header/body_checks, and by configuring
+in master.cf one Postfix SMTP client for each SMTP source IP address,
+where each client has its own "-o myhostname" and "-o smtp_bind_address"
+settings.
+
+[Feature 20091109] Improved before-queue filter performance.  With
+"smtpd_proxy_options = speed_adjust", the Postfix SMTP server
+receives the entire message before it connects to a before-queue
+content filter. This means you can run more SMTP server processes
+with the same number of running content filter processes, and thus,
+handle more mail. This feature is off by default until it is proven
+to create no new problems.
+
+This addresses a concern of people in Europe who want to reject all
+bad mail with a before-queue filter. The alternative, an after-queue
+filter, means they would have to discard bad mail (which is illegal)
+or bounce bad mail (which violates good network citizenship).
+
+NOTE 1: When this feature is turned on, a filter cannot selectively
+reject recipients of a multi-recipient message.  It is OK to reject
+all recipients of the same multi-recipient message, as is deferring
+or accepting all recipients of the same multi-recipient message.
+
+NOTE 2: This feature increases the minimum amount of free queue
+space by $message_size_limit. The extra space is needed to save the
+message to a temporary file.
+
+To keep the performance overhead low, the same temporary file is
+reused with successive mail transactions (the file is of course
+truncated before reuse, so there is no information leakage).
+
+Major changes - milter
+----------------------
+
+[Feature 20090606] Support for header checks on Milter-generated
+message headers.  This can be used, for example, to control mail
+flow with Milter-generated headers that carry indicators for badness
+or goodness. For details, see the postconf(5) section for
+"milter_header_checks". Currently, all header_checks features are
+implemented except PREPEND.  
+
+Major changes - multi-instance support
+--------------------------------------
+
+[Incompat 20090606] The "postmulti -e destroy" command no longer
+attempts to remove files that are created AFTER "postmulti -e
+create".  It still works as expected immediately after creating an
+instance by mistake.  Trying to automatically remove other files
+is too risky because Postfix-owned directories are by design not
+trusted.
+
--- a/RELEASE_NOTES-2.8
+++ b/RELEASE_NOTES-2.8
@ -0,0 +1,383 @@
+The stable Postfix release is called postfix-2.8.x where 2=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-2.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 2.6 or earlier, read RELEASE_NOTES-2.7
+before proceeding.
+
+Major changes - restart Postfix
+-------------------------------
+
+If you upgrade from Postfix 2.6 or earlier, you must execute "postfix
+stop" and "postfix start" before you can use the postscreen(8)
+daemon.  This is needed because the Postfix 2.6 "pass" master service
+type did not work reliably on some systems.
+
+If you upgrade from Postfix 2.7, or from Postfix 2.8 before July
+25, 2010, you must execute "postfix reload" (or "postfix stop"
+followed by "postfix start"). This is needed because the queue
+manager to delivery agent protocol has changed. Failure to do this
+results in repeated logging of warnings with:
+
+    warning: unexpected attribute rewrite_context ...
+
+If the warning does not go away after restarting Postfix, examine
+the output from this command:
+
+    strings -af /usr/libexec/postfix/* | grep mail_version=
+
+(where /usr/libexec/postfix is the value of main.cf:daemon_directory)
+and update the executables that have a version string that differs
+from the other programs.
+
+Major changes - DNSBL/DNSWL support
+-----------------------------------
+
+[Feature 20101126] Support for address patterns in DNS blacklist
+and whitelist lookup results.
+
+For example, "reject_rbl_client example.com=127.0.0.[2;4;6..8]"
+will reject clients when the lookup result is 127.0.0.2, 127.0.0.4,
+127.0.0.6, 127.0.0.7, or 127.0.0.8.
+
+The setting "postscreen_dnsbl_sites = example.com=127.0.0.[2;4;6..8]"
+rejects the same clients.
+
+An IPv4 address pattern has four fields separated by ".".  Each
+field is either a decimal number, or a sequence inside "[]" that
+contains one or more ";"-separated decimal numbers or number..number
+ranges.
+
+Thus, any pattern field can be a sequence inside "[]", but a "[]"
+sequence cannot span multiple address fields, and a pattern field
+cannot contain both a number and a "[]" sequence at the same time.
+
+This means that the pattern 1.2.[3.4] is not valid (the sequence
+[3.4] cannot span two address fields) and the pattern 1.2.3.3[6..9]
+is also not valid (the last field cannot be both number 3 and
+sequence [6..9] at the same time).
+
+The syntax for IPv4 patterns is as follows:
+
+v4pattern = v4field "." v4field "." v4field "." v4field
+v4field = v4octet | "[" v4sequence "]"
+v4octet = any decimal number in the range 0 through 255
+v4sequence = v4seq_member | v4sequence ";" v4seq_member
+v4seq_member = v4octet | v4octet ".." v4octet
+
+[Feature 20101105] The Postfix SMTP server now supports DNS-based
+whitelisting with several safety features: permit_dnswl_client
+whitelists a client by IP address, and permit_rhswl_client whitelists
+a client by its hostname.  These features use the same syntax as
+reject_rbl_client and reject_rhsbl_client, respectively. The main
+difference is that they return PERMIT instead of REJECT.
+
+Whitelisting is primarily a tool to reduce the false positive rate
+of DNS blocklist lookups.  Client name whitelisting should not be
+used to make exceptions to access rules. The reason is that client
+name lookup can fail unpredictably due to some temporary outage.
+
+For safety reasons, permit_dnswl_client and permit_rhswl_client are
+silently ignored when they would override reject_unauth_destination.
+Also for safety reasons, the result is DEFER_IF_REJECT when DNS
+whitelist lookup fails (this result will be made configurable).
+
+Major changes - sqlite support
+------------------------------
+
+[Feature 20100617] Support for read-only sqlite database access,
+with code by Axel Steiner and documentation by Jesus Garcia Crespo.
+See SQLITE_README and sqlite_table(5) for details.
+
+Major changes - Milter support
+-------------------------------
+
+[Incompat 20101103] Postfix now requests default delivery status
+notifications when adding a recipient with the Milter smfi_addrcpt
+action, instead of "never notify" as with Postfix automatically-added
+recipients (always_bcc and sender/recipient_bcc_maps).
+
+Major changes - alias expansion
+-------------------------------
+
+[Incompat 20101202] Postfix now reports a temporary delivery error
+when the result of virtual alias expansion would exceed the
+virtual_alias_recursion_limit or virtual_alias_expansion_limit.
+Previously, Postfix would silently drop the excess recipients and
+deliver the message.
+
+[Incompat 20101006] To avoid repeated delivery to mailing lists
+with pathological nested alias configurations, the local(8) delivery
+agent now keeps the owner-alias attribute of a parent alias, when
+delivering mail to a child alias that does not have its own owner
+alias.
+
+With this change, local addresses from that child alias will be
+written to a new queue file, and a temporary error with one local
+address will no longer result in repeated delivery to other mailing
+list members.  Specify "reset_owner_alias = yes" for the older,
+more fragile, behavior.
+
+The postconf(5) manpage entry for "reset_owner_alias" has more
+background information on this issue.
+
+Major changes - dns lookup
+--------------------------
+
+[Incompat 20100827] The Postfix SMTP client no longer appends the
+local domain when looking up a DNS name without ".".  Specify
+"smtp_dns_resolver_options = res_defnames" to get the old behavior,
+which may produce unexpected results.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20100728] The format of the "postfix/smtpd[pid]: queueid:
+client=host[addr]" logfile record has changed. When available, the
+before-filter client information and the before-filter queue ID are
+now appended to the end of the record.
+
+[Feature 20100728] Improved message tracking across SMTP-based
+content filters.  The logging example below is from an after-filter
+SMTP server. Here, 951F692462F is a before-filter queue ID,
+hades.porcupine.org is a before-filter SMTP client, while 6B4A9924782
+is the after-filter queue ID, and localhost[127.0.0.1] is the
+SMTP-based content filter that sends mail into the after-filter
+SMTP server.
+
+    postfix/smtpd[4074]: 6B4A9924782: 
+	client=localhost[127.0.0.1],
+	orig_queue_id=951F692462F
+	orig_client=hades.porcupine.org[168.100.189.10]
+
+Major changes - reply footer
+----------------------------
+
+[Feature 20110105] The SMTP server now supports contact information
+that is appended to "reject" responses. This includes SMTP server
+responses that aren't logged to the maillog file, such as responses
+to syntax errors, or unsupported commands.
+
+Example:
+   smtpd_reject_footer = For assistance, call 800-555-0101.
+
+Server response:
+   550-5.5.1 <user@example> Recipient address rejected: User unknown
+   550 5.5.1 For assistance, call 800-555-0101.
+
+This feature supports macro expansion ($client_address, $localtime,
+etc.), as documented in the postconf(5) manpage.
+
+This feature is also supported as postscreen_reject_footer using
+the same setting as smtpd_reject_footer by default.
+
+Major changes - rfc compliance
+------------------------------
+
+[Incompat 20101206] Postfix by default no longer adds a "To:
+undisclosed-recipients:;" header when no recipient specified in the
+message header.  The Internet mail RFCs have supported messages
+without recipient header for almost 10 years now.
+
+For backwards compatibility, specify:
+
+/etc/postfix/main.cf
+   undisclosed_recipients_header = To: undisclosed-recipients:;
+
+Note: both the ":" and ";" are required.
+
+Major changes - tls support
+---------------------------
+
+[Incompat 20110102] The Postfix SMTP server now always re-computes
+the SASL mechanism list after successful completion of the STARTTLS
+command. Earlier versions only re-computed the mechanism list when
+the values of smtp_sasl_tls_security_options and smtp_sasl_security_options
+differ.  This could produce incorrect results, because the Dovecot
+authentication server may change responses when the SMTP session
+is encrypted.
+
+[Incompat 20110102] The smtpd_starttls_timeout default value is now
+stress-dependent.  By default, TLS negotiations must now complete
+under overload in 10s instead of 300s.
+
+[Feature 20101223] The new 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. See postconf(5) and
+TLS_README for details.
+
+With "tls_preempt_cipherlist = yes" the Postfix SMTP server will
+choose its most preferred cipher that is supported (offered) by the
+client. This can lead to a more secure or performant cipher choice,
+but may also introduce interoperability problems when a client
+announces support for a cipher that does not work.  See postconf(5)
+and TLS_README for details.
+
+[Feature 20101217] The lower-level code in the TLS engine was
+simplified by removing an unnecessary layer of data copying. OpenSSL
+now writes directly to the network. The difference in performance
+should be hardly noticeable.
+
+[Incompat 20100610] Postfix no longer appends the system-supplied
+default CA certificates to the lists specified with *_tls_CAfile
+or with *_tls_CApath. This prevents third-party certificates from
+getting mail relay permission with the permit_tls_all_clientcerts
+feature.
+
+Unfortunately this change may cause compatibility problems when
+configurations rely on certificate verification for other purposes.
+Specify "tls_append_default_CA = yes" for backwards compatibility.
+
+Major changes - postscreen
+--------------------------
+
+See html/POSTSCREEN_README.html for an introduction to postscreen
+(or the text version, README_FILES/POSTSCREEN_README). The text
+below summarizes milestones in reverse chronological order.
+
+[Incompat 20110111] The postscreen_access_list feature replaces the
+postscreen_whitelist_networks and postscreen_blacklist_networks
+features. Reason: CIDR-style access maps are some 100x faster than
+the code that implemented the postscreen_white/blacklist_networks
+support.  CIDR maps can match about 100 million CIDR patterns/second
+on a modern CPU, which is not blindingly fast but adequate for the
+near future.
+
+[Feature 20110102] STARTTLS support for the postscreen(8) daemon.
+This is implemented by a new tlsproxy(8) daemon that you will need
+to enable in master.cf (see POSTSCREEN_README for instructions).
+tlsproxy(8) implements its own tlsproxy_mumble versions of TLS-related
+smtpd_mumble parameters. This leaves no confusion about which
+parameters will affect tlsproxy(8) behavior, but it adds another
+25 parameters to the documentation.
+
+[Incompat 20100912] If your DNSBL queries have a "secret" in the
+domain name, you must now 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.spamhaus.org    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.
+
+[Incompat 20100912] The postscreen "continue" action is now called
+"ignore".  The old name is still supported but no longer documented.
+
+[Incompat 20100912] The postscreen_hangup_action parameter was
+removed. Postscreen now always behaves as if "postscreen_hangup_action
+= drop".
+
+[Incompat 20100912] The postscreen_cache_retention_time default was
+increased from 1d to 7d, to avoid deleting results from expensive
+deep SMTP protocol tests too quickly.
+
+[Feature 20100912] SMTP protocol engine for deep protocol tests,
+and for logging the helo/sender/recipient information when postscreen
+rejects an attempt to deliver mail.
+
+The postscreen SMTP protocol engine implements a number of deep
+protocol tests and defers or rejects all attempts to deliver mail.
+The first test detects unauthorized SMTP command pipelining (an
+SMTP client sends multiple commands, instead of sending one command
+and waiting for the server response); a second deep protocol test
+implements the Postfix SMTP server's smtpd_forbidden_commands feature
+(a client sends commands such as CONNECT, GET, POST); and a third
+deep protocol test detects spambots that send SMTP commands that
+end in newline instead of carriage-return/newline.  Real spambots
+rarely make this mistake, but poorly-written software often does.
+
+Deep protocol tests are disabled by default, because the built-in
+SMTP engine cannot not hand off the "live" connection from a good
+SMTP client to a Postfix SMTP server process. To work around this,
+postscreen(8) defers attempts to deliver mail with a 4XX status,
+and waits for the client to disconnect. The next time a good client
+connects, it will be allowed to talk to a Postfix SMTP server process
+to deliver mail.
+
+[Feature 20100830] Postscreen DNSBL support is extended with optional
+fixed-string filters, with optional integral weight factors, and
+with an adjustable threshold to block SMTP clients with DNSBL score
+>= that threshold. Reply filters will be implemented later.
+
+The updated postscreen configuration syntax is:
+
+    postscreen_dnsbl_sites = domain[=ipaddr][*weight] ...
+    postscreen_dnsbl_threshold = score
+
+Elements inside [] are optional, ipaddr is an IPv4 address, and
+weight and score are integral numbers. The [] are not part of the
+postscreen_dnsbl_sites input.  By default, weight and score are
+equal to 1, and entries without filter will match any non-error
+DNSBL reply.  Use a negative weight value for whitelisting.
+
+Examples:
+
+To use example.com as a high-confidence blocklist, and to block
+mail with example.net and example.org only when both agree, use:
+
+    postscreen_dnsbl_threshold = 2
+    postscreen_dnsbl_sites = example.com*2, example.net, example.org
+
+To filter only DNSBL replies containing 127.0.0.4, use:
+
+    postscreen_dnsbl_sites = example.com=127.0.0.4
+
+See also postconf(5) for the fine details.
+
+[Incompat 20100101] When periodic cache cleanup is enabled (the
+default), the postscreen(8) server now requires that the cache
+database supports the "delete" and "sequence" operations.  To disable
+periodic cache cleanup specify a zero postscreen_cache_cleanup_interval
+value.
+
+[Feature 20100101] Periodic cache cleanup for the postscreen(8)
+cache database. The time between cache cleanup runs is controlled
+with the postscreen_cache_cleanup_interval (default: 12h) parameter.
+Cache cleanup increases the database access latency, so this should
+not be run more often than necessary.
+
+In addition, the postscreen_cache_retention_time (default: 1d)
+parameter specifies how long to keep an expired entry in the cache.
+This prevents a client from being logged as "NEW" after its record
+expired only a little while ago.
+
+[Feature 20091008] Prototype postscreen(8) server that runs a number
+of time-consuming checks in parallel for all incoming SMTP connections,
+before clients are allowed to talk to a real Postfix SMTP server.
+It detects clients that start talking too soon, or clients that
+appear on DNS blocklists, or clients that hang up without sending
+any command.
+
+By doing these checks in a single postscreen(8) process, Postfix
+can avoid wasting one SMTP server process per connection. A side
+benefit of postscreen(8)'s DNSBL lookups is that DNS records are
+already cached before the Postfix SMTP server looks them up later.
+
+postscreen(8) maintains a temporary whitelist of positive decisions.
+Once an SMTP client is whitelisted, it is immediately forwarded to
+a real Postfix SMTP server process without further checking.
+
+By default, the program logs only statistics, and it does not run
+any checks on clients in mynetworks (primarily, to avoid problems
+with buggy SMTP implementations in network appliances).  The logging
+function alone is already useful for research.
+
--- a/RELEASE_NOTES-2.9
+++ b/RELEASE_NOTES-2.9
@ -0,0 +1,352 @@
+The stable Postfix release is called postfix-2.9.x where 2=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-2.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 2.7 or earlier, read RELEASE_NOTES-2.8
+before proceeding.
+
+Major changes - critical
+------------------------
+
+[Incompat 20110321] You need to "postfix reload" after upgrade from
+snapshot 20110320 or earlier.  The hash_queue_names algorithm was
+changed to provide better performance with long queue IDs.
+
+[Incompat 20110313] Use "postfix reload" after "make upgrade" on a
+running Postfix system. This is needed because the protocol between
+postscreen(8) and dnsblog(8) has changed.
+
+Major changes - library API
+---------------------------
+
+[Incompat 20110130] The VSTREAM error flags are now split into
+separate read and write error flags. As a result of this change,
+all programs that use Postfix VSTREAMs MUST be recompiled.
+
+Major changes - compatibility
+-----------------------------
+
+[Incompat 20111012] For consistency with the SMTP standard, the
+(client-side) smtp_line_length_limit default value was increased
+from 990 characters to 999 (i.e. 1000 characters including <CR><LF>).
+Specify "smtp_line_length_limit = 990" to restore historical Postfix
+behavior.
+
+[Incompat 20111012] To simplify integration with third-party
+applications, the Postfix sendmail command now always transforms
+all input lines ending in <CR><LF> into UNIX format (lines ending
+in <LF>). Specify "sendmail_fix_line_endings = strict" to restore
+historical Postfix behavior (i.e. convert all input lines ending
+in <CR><LF> only if the first line ends in <CR><LF>).
+
+[Incompat 20111106] To work around broken remote SMTP servers, the
+Postfix SMTP client by default no longer appends the "AUTH=<>"
+option to the MAIL FROM command.  Specify "smtp_send_dummy_mail_auth
+= yes" to restore the old behavior.
+
+Major changes - gradual degradation
+-----------------------------------
+
+[Incompat 20120114] Logfile-based alerting systems may need to be
+updated to look for "error" messages in addition to "fatal" messages.
+Specify "daemon_table_open_error_is_fatal = yes" to get the historical
+behavior (immediate termination with "fatal" message).
+
+[Feature 20120114] Instead of terminating immediately with a "fatal"
+message when a database file can't be opened, a Postfix daemon
+program now logs an "error" message, and continues execution with
+reduced functionality.  For the sake of sanity, the number of
+"errors" over the life of a process is limited to 13.
+
+Features that don't depend on the unavailable table will continue
+to work; attempts to use features that depend on the table will
+fail, and will be logged with a "warning" message.
+
+[Feature 20120108] Instead of terminating with a fatal error, the
+LDAP, *SQL and memcache clients now handle table lookup errors in
+the "domain" feature, instead of terminating with a fatal error.
+
+[Feature 20120102] Degrade gradually when some or all network
+protocols specified with inet_protocols are unavailable, instead
+of terminating with a fatal error. This eliminates build errors on
+non-standard systems where opening an IPv4 socket results in an
+error, and on non-standard systems where opening an IPv6 socket
+results in an error. In the worst case, the master daemon will log
+a message that it disables all type "inet" services. This will still
+allow local submission and local delivery.
+
+[Feature 20111222] Instead of terminating with a fatal error, the
+Postfix SMTP server now handles errors with database lookups in
+mynetworks, TLS client certificate tables, debug_peer_list,
+smtpd_client_event_limit_exceptions, permit_mx_backup_networks and
+local_header_rewrite_clients, and reports "server local data error"
+or "temporary lookup error".
+
+[Feature 20111229] Instead of terminating with a fatal error, the
+trivial-rewrite server now handles errors with database lookups in
+virtual_alias_domains, relay_domains, virtual_mailbox_domains.  This
+means fewer occasions where trivial-rewrite clients (such as the
+SMTP server) will appear to hang.
+
+Major changes - long queue IDs
+------------------------------
+
+Postfix 2.9 introduces support for non-repeating queue IDs (also
+used as queue file names). These names are encoded in a mix of upper
+case, lower case and decimal digit characters.  Long queue IDs are
+disabled by default to avoid breaking tools that parse logfiles and
+that expect queue IDs with the smaller [A-F0-9] character set.
+
+[Incompat 20110320] If you enable support for long queue file names,
+you need to be aware that these file names are not compatible with
+Postfix <= 2.8.  If you must migrate back to Postfix <= 2.8, you
+must first convert all long queue file names into short names,
+otherwise the old Postfix version will complain.
+
+The conversion procedure before migration to Postfix <= 2.8 is:
+
+    # postfix stop
+    # postconf enable_long_queue_ids=no
+    # postsuper
+
+Run the postsuper command repeatedly until it no longer reports
+queue file name changes.
+
+[Feature 20110320] Support for long, non-repeating, queue IDs (queue
+file names).  The benefit of non-repeating names is simpler logfile
+analysis, and easier queue migration (if you don't merge different
+queues, there is no need to run "postsuper" to change queue file
+names that don't match their message file inode number).
+
+Specify "enable_long_queue_ids = yes" to enable the feature. This
+does not change the names of existing queue files. See postconf(5)
+or postconf.5.html#enable_long_queue_ids for a detailed description
+of the differences with the old short queue IDs.
+
+This changes new Postfix queue IDs from the short form 0FCEE9247A9
+into the longer form 3Ps0FS1Zhtz1PFjb, and changes new Message-ID
+header values from YYMMDDHHMMSS.queueid@myhostname into the shorter
+form queueid@myhostname.
+
+Major changes - memcache
+------------------------
+
+[Feature 20111209] memcache lookup and update support. This provides
+a way to share postscreen(8) or verify(8) caches between Postfix
+instances.  See MEMCACHE_README and memcache_table(5) for details
+and limitations.
+
+[Feature 20111213] Support for a persistent backup database in the
+memcache client.  The memcache client updates the memcache whenever
+it looks up or modifies information in the persistent database.
+
+Major changes - postconf
+------------------------
+
+The postconf command was restructured - it now warns about unused
+parameter name=value settings in main.cf or master.cf (likely to
+be mistakes), it now understands "dynamic" parameter names such as
+parameters whose name depends on the name of a master.cf entry, and
+it can display main.cf and master.cf in a more user-friendly format.
+
+[Feature 20120117] support for legacy database parameter names
+(main.cf parameter names that are generated by prepending a suffix
+to the database name).
+
+[Feature 20111118] The "postconf -M" (display master.cf) command
+now supports filtering.  For example, specify "postconf -M inet"
+to display only services that listen on the network.
+
+[Feature 20111113] postconf support to warn about unused "name=value"
+entries in main.cf, and about unused "-o name=value" entries in
+master.cf.  This should help to eliminate common errors with mis-typed
+names.
+
+[Feature 20111108] postconf support for parameter names that are
+generated automatically from master.cf entries (delivery agents,
+spawn services), and for parameter names that are defined with
+main.cf smtpd_restriction_classes.
+
+[Feature 20111106] "postconf -M" support to print master.cf entries,
+and "postconf -f" support to fold long main.cf or master.cf lines
+for human readability.
+
+Major changes - trickle defense
+-------------------------------
+
+[Feature 20110212] Support for per-record deadlines.  These change
+the behavior of Postfix timeout parameters, from a time limit per
+read or write system call, to a time limit to send or receive a
+complete record (an SMTP command line, SMTP response line, SMTP
+message content line, or TLS protocol message).  This limits the
+impact from hostile peers that trickle data one byte at a time.
+
+The new configuration parameters and their default settings are:
+smtpd_per_record_deadline (normal: no, overload: yes),
+smtp_per_record_deadline (no), and lmtp_per_record_deadline (no).
+
+Note: when per-record deadlines are enabled, a short time limit may
+cause problems with TLS over very slow network connections.  The
+reason is that a TLS protocol message can be up to 16 kbytes long
+(with TLSv1), and that an entire TLS protocol message must be sent
+or received within the per-record deadline.
+
+Per-record deadlines were introduced with postscreen(8) in Postfix
+2.8. This program does not receive mail, and therefore it has no
+problems with TLS over slow connections.
+
+Major changes - postscreen
+--------------------------
+
+[Feature 20111211] The proxymap(8) server can now be used to share
+postscreen(8) or verify(8) caches between Postfix instances.  Support
+for proxymap-over-TCP, to share a Postfix database between hosts,
+is expected to be completed in the Postfix 2.10 development cycle.
+
+[Feature 20111209] memcache lookup and update support. This provides
+a way to share postscreen(8) or verify(8) caches between Postfix
+instances.  
+
+[Feature 20110228] postscreen(8) support to force remote SMTP clients
+to implement proper MX lookup policy.  By listening on both primary
+and backup MX addresses, postscreen(8) can deny the temporary
+whitelist status to clients that connect only to backup MX hosts,
+and prevent them from talking to a Postfix SMTP server process.
+
+Example: when 1.2.3.4 is a local backup IP address, specify
+"postscreen_whitelist_interfaces = !1.2.3.4 static:all".
+
+Major changes - tls
+-------------------
+
+[Incompat 20111205] Postfix now logs the result of successful TLS
+negotiation with TLS logging levels of 0. See the smtp_tls_loglevel
+and smtpd_tls_loglevel descriptions in the postconf(5) manpage for
+other minor differences.
+
+[Feature 20111205] Support for TLS public key fingerprint matching
+in the Postfix SMTP client (in smtp_tls_policy_maps) and server (in
+check_ccert access maps).  Public key fingerprints are inherently
+more specific than fingerprints over the entire certificate.
+
+[Feature 20111205] Revision of Postfix TLS logging. The main
+difference is that Postfix now logs the result of successful TLS
+negotiation with TLS logging levels of 0.  See the smtp_tls_loglevel
+and smtpd_tls_loglevel descriptions in the postconf(5) manpage for
+other minor differences.
+
+Major changes - sasl authentication
+-----------------------------------
+
+[Incompat 20111218] To support external SASL authentication, e.g.,
+in an NGINX proxy daemon, the Postfix SMTP server now always checks
+the smtpd_sender_login_maps table, even without having
+"smtpd_sasl_auth_enable = yes" in main.cf.
+
+[Feature 20111218] Support for external SASL authentication via the
+XCLIENT command.  This is used to accept SASL authentication from
+an SMTP proxy such as NGINX. This support works even without having
+to specify "smtpd_sasl_auth_enable = yes" in main.cf.
+
+[Incompat 20111106] To work around broken remote SMTP servers, the
+Postfix SMTP client by default no longer appends the "AUTH=<>"
+option to the MAIL FROM command.  Specify "smtp_send_dummy_mail_auth
+= yes" to restore the old behavior.
+
+Major changes - large file support
+----------------------------------
+
+[Feature 20110219] Postfix now uses long integers for message_size_limit,
+mailbox_size_limit and virtual_mailbox_limit. On LP64 systems (64-bit
+long and pointer, but 32-bit integer), these limits can now exceed
+2GB.
+
+Major changes - ipv6
+--------------------
+
+[Incompat 20110918] The following changes were made in default
+settings, in preparation for general availability of IPv6:
+
+- The default inet_protocols value is now "all" instead of "ipv4",
+  meaning use both IPv4 and IPv6.  
+
+  To avoid an unexpected loss of performance for sites without
+  global IPv6 connectivity, the commands "make upgrade" and "postfix
+  upgrade-configuration" now append "inet_protocols = ipv4" to
+  main.cf when no explicit inet_protocols setting is already present.
+  This workaround will be removed in a future release.
+
+- The default smtp_address_preference value is now "any" instead
+  of "ipv6", meaning choose randomly between IPv6 and IPv4. With
+  this the Postfix SMTP client will have more success delivering
+  mail to sites that have problematic IPv6 configurations.
+
+Major changes - address verification
+------------------------------------
+
+[Feature 20111211] The proxymap(8) server can now be used to share
+postscreen(8) or verify(8) caches between Postfix instances.  Support
+for proxymap-over-TCP, to share a Postfix database between hosts,
+is expected to be completed in the Postfix 2.10 development cycle.
+
+[Feature 20111209] memcache lookup and update support. This provides
+a way to share postscreen(8) or verify(8) caches between Postfix
+instances.  
+
+[Feature 20111203] Support for time-dependent sender addresses
+of address verification probes. The default address, double-bounce,
+may end up on spammer blacklists. Although Postfix discards mail
+for this address, such mail still uses up network bandwidth and
+server resources. Specify an address_verify_sender_ttl value of
+several hours or more to frustrate address harvesting.
+
+Major changes - session transcript notification
+-----------------------------------------------
+
+[Incompat 20120114] By default the Postfix SMTP server no longer
+reports transcripts of sessions where a client command is rejected
+because a lookup table is unavailable. Postfix now implements gradual
+degradation, for example, the SMTP server keeps running instead of
+terminating with a fatal error. This change in error handling would
+result in a very large number of "transcript of session" email
+notifications when an LDAP or *SQL server goes down).
+
+To receive such reports, add the new "data" class to the notify_classes
+parameter value. The reports will be sent to the error_notice_recipient
+address as before.  This class is also used by the Postfix SMTP
+client to report about sessions that fail because a table is
+unavailable.
+
+Major changes - logging
+----------------------------------------
+
+[Incompat 20120114] Logfile-based alerting systems may need to be
+updated to look for "error" messages in addition to "fatal" messages.
+Specify "daemon_table_open_error_is_fatal = yes" to get the historical
+behavior (immediate termination with "fatal" message).
+
+[Incompat 20111214] Logfile-based analysis tools may need to be
+updated. The submission and smtps examples in the sample master.cf
+file were updated to make their logging easier to distinguish.
+
+See the source file pflogsumm_quickfix.txt for a "quick fix".
+
+[Incompat 20111205] Postfix now logs the result of successful TLS
+negotiation with TLS logging levels of 0. See the smtp_tls_loglevel
+and smtpd_tls_loglevel descriptions in the postconf(5) manpage for
+other minor differences.
+
+[Incompat 20110219] The Postfix SMTP and QMQP servers now log
+"hostname X does not resolve to address Y", when a "reverse hostname"
+lookup result does not resolve to the client IP address. Until now
+these servers logged "Y: hostname X verification failed" or "Y:
+address not listed for hostname X" which people found confusing.
--- a/RELEASE_NOTES-3.0
+++ b/RELEASE_NOTES-3.0
@ -0,0 +1,628 @@
+The stable Postfix release is called postfix-3.0.x where 3=major
+release number, 0=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.1-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 2.10 or earlier, read RELEASE_NOTES-2.11
+before proceeding.
+
+Notes for distribution maintainers
+----------------------------------
+
+* New backwards-compatibility safety net.
+
+With NEW Postfix installs, you MUST install a main.cf file with
+the setting "compatibility_level = 2". See conf/main.cf for an
+example.
+
+With UPGRADES of existing Postfix systems, you MUST NOT change the
+main.cf compatibility_level setting, nor add this setting if it
+does not exist.
+
+Several Postfix default settings have changed with Postfix 3.0.  To
+avoid massive frustration with existing Postfix installations,
+Postfix 3.0 comes with a safety net that forces Postfix to keep
+running with backwards-compatible main.cf and master.cf default
+settings. This safety net depends on the main.cf compatibility_level
+setting (default: 0). Details are in COMPATIBILITY_README.
+
+* New Postfix build system.
+
+The Postfix build/install procedure has changed to support Postfix
+dynamically-linked libraries and database plugins. These must not
+be "shared" with non-Postfix programs, and therefore must not be
+installed in a public directory.
+
+To avoid massive frustration due to broken patches, PLEASE BUILD
+POSTFIX FIRST WITHOUT APPLYING ANY PATCHES.  Follow the INSTALL
+instructions (see "Building with Postfix dynamically-linked libraries
+and database plugins"), and see how things work and what the
+dynamically-linked libraries, database plugin, and configuration
+files look like.  Then, go ahead and perform your platform-specific
+customizations. The INSTALL section "Tips for distribution maintainers"
+has further suggestions.
+
+Major changes - critical
+------------------------
+
+[Incompat 20140714] After upgrading Postfix, "postfix reload" (or
+start/stop) is required. Several Postfix-internal protocols have
+been extended to support SMTPUTF8. Failure to reload or restart
+will result in mail staying queued, while Postfix daemons log
+warning messages about unexpected attributes.
+
+Major changes - default settings
+--------------------------------
+
+[Incompat 20141009] The default settings have changed for relay_domains
+(new: empty, old: $mydestination) and mynetworks_style (new: host,
+old: subnet).  However the backwards-compatibility safety net will
+prevent these changes from taking effect, giving the system
+administrator the option to make an old default setting permanent
+in main.cf or to adopt the new default setting, before turning off
+backwards compatibility. See COMPATIBILITY_README for details.
+
+[Incompat 20141001] A new backwards-compatibility safety net forces
+Postfix to run with backwards-compatible main.cf and master.cf
+default settings after an upgrade to a newer but incompatible Postfix
+version. See COMPATIBILITY_README for details.
+
+While the backwards-compatible default settings are in effect,
+Postfix logs what services or what email would be affected by the
+incompatible change. Based on this the administrator can make some
+backwards-compatibility settings permanent in main.cf or master.cf,
+before turning off backwards compatibility.
+
+See postconf.5.html#compatibility_level for details.
+
+[Incompat 20141001] The default settings
+have changed for append_dot_mydomain (new: no.  old: yes), master.cf
+chroot (new: n, old: y), and smtputf8 (new: yes, old: no).
+
+Major changes - access control
+------------------------------
+
+[Feature 20141119] Support for BCC actions in header/body_checks
+and milter_header_checks.  There is no limit on the number of BCC
+actions that may be specified, other than the implicit limit due
+to finite storage. BCC support will not be implemented in Postfix
+delivery agent header/body_checks.
+
+It works in the same way as always_bcc and sender/recipient_bcc_maps:
+there can be only one address per action, recipients are added with
+the NOTIFY=NONE delivery status notification option, and duplicate
+recipients are ignored (with the same delivery status notification
+options).
+
+[Incompat 20141009] The default settings have changed for relay_domains
+(new: empty, old: $mydestination) and mynetworks_style (new: host,
+old: subnet).  However the backwards-compatibility safety net will
+prevent these changes from taking effect, giving the system
+administrator the option to make an old default setting permanent
+in main.cf or to adopt the new default setting, before turning off
+backwards compatibility. See COMPATIBILITY_README for details.
+
+[Feature 20140618] New INFO action in access(5) tables, for consistency
+with header/body_checks.
+
+[Feature 20140620] New check_xxx_a_access (for xxx in client,
+reverse_client, helo, sender, recipient) implements access control
+on all A and AAAA IP addresses for respectively the client hostname,
+helo parameter, sender domain or recipient domain. This complements
+the existing check_xxx_mx_access and check_xxx_ns_access features.
+
+Major changes - address rewriting
+---------------------------------
+
+[Incompat 20141001] The default settings have changed for
+append_dot_mydomain (new: no.  old: yes), master.cf chroot (new:
+n, old: y), and smtputf8 (new: yes, old: no).
+
+Major changes - address verification
+------------------------------------
+
+[Feature 20141227] The new smtp_address_verify_target parameter
+(default: rcpt) specifies what protocol stage decides if a recipient
+is valid. Specify "data" for servers that reject invalid recipients
+in response to the DATA command.
+
+Major changes - database support
+--------------------------------
+
+[Feature 20140512] Support for Berkeley DB version 6.
+
+[Feature 20140618] The "randmap" lookup table performs random
+selection. This may be used to implement load balancing, for example:
+
+/etc/postfix/transport:
+    # Deliver my own domain as usual.
+    example.com :
+    .example.com :
+
+/etc/postfix/main.cf:
+    transport_maps = 
+        # Deliver my own domain as usual.
+        hash:/etc/postfix/transport 
+        # Deliver other domains via randomly-selected relayhosts
+        randmap:{smtp:smtp0.example.com, smtp:smtp1.example.com}
+
+A variant of this can randomly select SMTP clients with different
+smtp_bind_address settings.
+
+To implement different weights, specify lookup results multiple
+times. For example, to choose smtp:smtp1.example.com twice as often
+as smtp:smtp0.example.com, specify smtp:smtp1.example.com twice.
+
+A future version may support randmap:/path/to/file to load a list
+of results from file.
+
+[Feature 20140618] As the name suggests, the "pipemap" table
+implements a pipeline of lookup tables. The name of the table
+specifies the pipeline as a sequence of tables. For example, the
+following prevents SMTP mail to system accounts that have "nologin"
+as their login shell:
+
+    /etc/postfix/main.cf:
+        local_recipient_maps = 
+            pipemap:{unix:passwd.byname, pcre:/etc/postfix/no-nologin.pcre}
+            alias_maps
+
+    /etc/postfix/no-nologin.pcre:
+        !/nologin/      whatever
+
+Each "pipemap:" query is given to the first table. Each table
+lookup result becomes the query for the next table in the pipeline,
+and the last table produces the final result.  When any table lookup
+produces no result, the entire pipeline produces no result.
+
+A future version may support pipemap:/path/to/file to load a list
+of lookup tables from file.
+
+[Feature 20140924] Support for unionmap, with the same syntax as
+pipemap.  This sends a query to all tables, and concatenates non-empty
+results, separated by comma.
+
+[Feature 20131121] The "static" lookup table now supports whitespace
+when invoked as "static:{ text with whitespace }", so that it can
+be used, for example, at the end of smtpd_mumble_restrictions as
+"check_mumble_access static:{reject text...}".
+
+[Feature 20141126] "inline:{key=value, { key = text with comma/space}}"
+avoids the need to create a database for just a few entries.
+
+Major changes - delivery status notifications
+---------------------------------------------
+
+[Feature 20140321] Delivery status filter support, to replace the
+delivery status codes and explanatory text of successful or
+unsuccessful deliveries by Postfix mail delivery agents.
+
+This was originally implemented for sites that want to turn certain
+soft delivery errors into hard delivery errors, but it can also be
+used to censor out information from delivery confirmation reports.
+
+This feature is implemented as a filter that replaces the three-number
+enhanced status code and descriptive text in Postfix delivery agent
+success, bounce, or defer messages. Note: this will not override
+"soft_bounce=yes", and this will not change a successful delivery
+status into an unsuccessful status or vice versa.
+
+The first example turns specific soft TLS errors into hard
+errors, by overriding the first number in the enhanced status code.
+
+/etc/postfix/main.cf:
+    smtp_delivery_status_filter = pcre:/etc/postfix/smtp_dsn_filter
+
+/etc/postfix/smtp_dsn_filter:
+    /^4(\.\d+\.\d+ TLS is required, but host \S+ refused to start TLS: .+)/ 5$1
+    /^4(\.\d+\.\d+ TLS is required, but was not offered by host .+)/ 5$1
+
+The second example removes the destination command name and file
+name from local(8) successful delivery reports, so that they will
+not be reported when a sender requests confirmation of delivery.
+
+/etc/postfix/main.cf:
+    local_delivery_status_filter = pcre:/etc/postfix/local_dsn_filter
+
+/etc/postfix/local_dsn_filter:
+    /^(2\S+ delivered to file).+/    $1
+    /^(2\S+ delivered to command).+/ $1
+
+This feature is supported in the lmtp(8), local(8), pipe(8), smtp(8)
+and virtual(8) delivery agents. That is, all delivery agents that
+actually deliver mail.  It will not be implemented in the error and
+retry pseudo-delivery agents.
+
+The new main.cf parameters and default values are:
+
+    default_delivery_status_filter =
+    lmtp_delivery_status_filter = $default_delivery_status_filter
+    local_delivery_status_filter = $default_delivery_status_filter
+    pipe_delivery_status_filter = $default_delivery_status_filter
+    smtp_delivery_status_filter = $default_delivery_status_filter
+    virtual_delivery_status_filter = $default_delivery_status_filter
+
+See the postconf(5) manpage for more details.
+
+[Incompat 20140618] The pipe(8) delivery agent will now log a limited
+amount of command output upon successful delivery, and will report
+that output in "SUCCESS" delivery status reports. This is another
+good reason to disable inbound DSN requests at the Internet perimeter.
+
+[Feature 20140907] With "confirm_delay_cleared = yes", Postfix
+informs the sender when delayed mail leaves the queue (this is in
+addition to the delay_warning_time feature that warns when mail is
+still queued).  This feature is disabled by default, because it can
+result in a sudden burst of notifications when the queue drains at
+the end of a prolonged network outage.
+
+Major changes - dns
+-------------------
+
+[Feature 20141128] Support for DNS server reply filters in the
+Postfix SMTP/LMTP client and SMTP server. This helps to work around
+mail delivery problems with sites that have incorrect DNS information.
+Note: this has no effect on the implicit DNS lookups that are made
+by nsswitch.conf or equivalent mechanisms.
+
+This feature renders each lookup result as one line of text in
+standard zone-file format as shown below. The class field is always
+"IN", the preference field exists only for MX records, the names
+of hosts, domains, etc. end in ".", and those names are in ASCII
+form (xn--mumble form for internationalized domain names).
+
+    name         ttl   class type preference value
+    ---------------------------------------------------------
+    postfix.org. 86400 IN    MX   10         mail.cloud9.net.
+
+Typically, one would match this text with a regexp: or pcre: table.
+When a match is found, the table lookup result specifies an action.
+By default, the table query and the action name are case-insensitive.
+Currently, only the IGNORE action is implemented.
+
+For safety reasons, Postfix logs a warning or defers mail delivery
+when a DNS reply filter removes all lookup results from a successful
+query.
+
+The Postfix SMTP/LMTP client uses the smtp_dns_reply_filter and
+lmtp_dns_reply_filter features only for Postfix SMTP client lookups
+of MX, A, and AAAAA records to locate a remote SMTP or LMTP server,
+including lookups that implement the features reject_unverified_sender
+and reject_unverified_recipient. The filters are not used for lookups
+made through nsswitch.conf and similar mechanisms.
+
+The Postfix SMTP server uses the smtpd_dns_reply_filter feature
+only for Postfix SMTP server lookups of MX, A, AAAAA, and TXT records
+to implement the features reject_unknown_helo_hostname,
+reject_unknown_sender_domain, reject_unknown_recipient_domain,
+reject_rbl_*, and reject_rhsbl_*. The filter is not used for lookups
+made through nsswitch.conf and similar mechanisms, such as lookups
+of the remote SMTP client name.
+
+[Feature 20141126] Nullmx support (MX records with a null hostname).
+This change affects error messages only.  The Postfix SMTP client
+already bounced mail for such domains, and the Postfix SMTP server
+already rejected such domains with reject_unknown_sender/recipient_domain.
+This feature introduces a new SMTP server configuration parameter
+nullmx_reject_code (default: 556).
+
+Major changes - dynamic linking
+-------------------------------
+
+[Feature 20140530] Support to build Postfix with Postfix
+dynamically-linked libraries, and with dynamically-loadable database
+clients. These MUST NOT be used by non-Postfix programs. Postfix
+dynamically-linked libraries introduce minor runtime overhead and
+result in smaller Postfix executable files. Dynamically-loadable
+database clients are useful when you distribute or install pre-compiled
+packages.  Postfix 3.0 supports dynamic loading for CDB, LDAP, LMDB,
+MYSQL, PCRE, PGSQL, SDBM, and SQLITE database clients.
+
+This implementation is based on Debian code by LaMont Jones, initially
+ported by Viktor Dukhovni. Currently, support exists for recent
+versions of Linux, FreeBSD, MacOS X, and for the ancient Solaris 9.
+
+To support Postfix dynamically-linked libraries and dynamically-loadable
+database clients, the Postfix build procedure had to be changed
+(specifically, the files makedefs and Makefile.in, and the files
+postfix-install and post-install that install or update Postfix).
+
+[Incompat 20140530] The Postfix 3.0 build procedure expects that
+you specify database library dependencies with variables named
+AUXLIBS_CDB, AUXLIBS_LDAP, etc.  With Postfix 3.0 and later, the
+old AUXLIBS variable still supports building a statically-loaded
+CDB etc.  database client, but only the new AUXLIBS_CDB etc. variables
+support building a dynamically-loaded or statically-loaded CDB etc.
+database client.  See CDB_README, LDAP_README, etc. for details.
+
+Failure to follow this advice will defeat the purpose of dynamic
+database client loading. Every Postfix executable file will have
+database library dependencies. And that was exactly what dynamic
+database client loading was meant to avoid.
+
+Major changes - future proofing
+-------------------------------
+
+[Cleanup 20141224] The changes described here have no visible effect
+on Postfix behavior, but they make Postfix code easier to maintain,
+and therefore make new functionality easier to add.
+
+* Compile-time argument typechecks of non-printf/scanf-like variadic
+  function argument lists.
+
+* Deprecating the use of "char *" for non-text purposes such as
+  memory allocation and pointers to application context for call-back
+  functions. This dates from long-past days before void * became
+  universally available.
+
+* Replace integer types for counters and sizes with size_t or ssize_t
+  equivalents.  This eliminates some wasteful 64<->32bit conversions
+  on 64-bit systems.
+
+Major changes - installation pathnames
+--------------------------------------
+
+[Incompat 20140625] For compliance with file system policies, some
+non-executable files have been moved from $daemon_directory to the
+directory specified with the new meta_directory configuration
+parameter which has the same default value as the config_directory
+parameter. This change affects non-executable files that are shared
+between multiple Postfix instances such as postfix-files, dynamicmaps.cf,
+and multi-instance template files.
+
+For backwards compatibility with Postfix 2.6 .. 2.11, specify
+"meta_directory = $daemon_directory" in main.cf before installing
+or upgrading Postfix, or specify "meta_directory = /path/name" on
+the "make makefiles", "make install" or "make upgrade" command line.
+
+Major changes - milter
+----------------------
+
+[Feature 20140928] Support for per-Milter settings that override
+main.cf parameters.  For details see the section "Advanced policy
+client configuration" in the SMTPD_POLICY_README document.
+
+Here is an example that uses both old and new syntax:
+
+    smtpd_milters = { inet:127.0.0.1:port1, default_action=accept, ... },
+        inet:127.0.0.1:port2, ...
+
+The supported attribute names are: command_timeout, connect_timeout,
+content_timeout, default_action, and protocol. These have the same
+names as the corresponding main.cf parameters, without the "milter_"
+prefix.
+
+The per-milter settings are specified as attribute=value pairs
+separated by comma or space; specify { name = value } to allow
+spaces around the "=" or within an attribute value.
+
+[Feature 20141018] DMARC compatibility: when a Milter inserts a
+header ABOVE Postfix's own Received: header, Postfix no longer
+exposes its own Received: header to Milters (violating protocol)
+and Postfix no longer hides the Milter-inserted header from Milters
+(wtf).
+
+Major changes - parameter syntax
+--------------------------------
+
+[Feature 20140921] In preparation for configurable mail headers and
+logging, new main.cf support for if-then-else expressions:
+
+    ${name?{text1}:{text2}}
+
+and for logical expressions: 
+
+    ${{text1}=={text2}?{text3}:{text4}}
+    ${{text1}!={text2}?{text3}:{text4}}
+
+Whitespace before and after {text} is ignored. This can help to
+make complex expressions more readable.  See the postconf(5) manpage
+for further details.
+
+[Feature 20140928] Support for whitespace in daemon command-line
+arguments. For details, see the "Command name + arguments" section
+in the master(5) manpage.  Example:
+
+    smtpd -o { parameter = value containing whitespace } ...
+
+The { ... } form is also available for non-option command-line
+arguments in master.cf, for example:
+
+    pipe ... argv=command { argument containing whitespace } ...
+
+In both cases, whitespace immediately after "{" and before "}"
+is ignored.
+
+[Feature 20141005] Postfix import_environment and export_environment
+now allow "{ name=value }" to protect whitespace in attribute values.
+
+[Feature 20141006] The new message_drop_header parameter replaces
+a hard-coded table that specifies what message headers the cleanup
+daemon will remove.  The list of supported header names covers RFC
+5321, 5322, MIME RFCs, and some historical names.
+
+Major changes - pipe daemon
+---------------------------
+
+[Incompat 20140618] The pipe(8) delivery agent will now log a limited
+amount of command output upon successful delivery, and will report
+that output in "SUCCESS" delivery status reports. This is another
+good reason to disable inbound DSN requests at the Internet perimeter.
+
+Major changes - policy client
+-----------------------------
+
+[Feature 20140703] This release introduces three new configuration
+parameters that control error recovery for failed SMTPD policy
+requests.
+
+  * smtpd_policy_service_default_action (default: 451 4.3.5 Server
+    configuration problem): The default action when an SMTPD policy
+    service request fails.
+
+  * smtpd_policy_service_try_limit (default: 2): The maximal number
+    of attempts to send an SMTPD policy service request before
+    giving up. This must be a number greater than zero.
+
+  * smtpd_policy_service_retry_delay (default: 1s): The delay between
+    attempts to resend a failed SMTPD policy service request. This
+    must be a number greater than zero.
+
+See postconf(5) for details and limitations.
+
+[Feature 20140928] Support for per-policy service settings that
+override main.cf parameters.  For details see the section "Different
+settings for different Milter applications" in the MILTER_README
+document.
+
+Here is an example that uses both old and new syntax:
+
+smtpd_recipient_restrictions = ...
+    check_policy_service { inet:127.0.0.1:port3, default_action=DUNNO }
+    check_policy_service inet:127.0.0.1:port4
+    ...
+
+The per-policy service settings are specified as attribute=value pairs
+separated by comma or space; specify { name = value } to allow
+spaces around the "=" or within an attribute value.
+
+The supported attribute names are: default_action, max_idle, max_ttl,
+request_limit, retry_delay, timeout, try_limit. These have the same
+names as the corresponding main.cf parameters, without the
+"smtpd_policy_service_" prefix.
+
+[Feature 20140505] A client port attribute was added to the policy
+delegation protocol.
+
+[Feature 20140630] New smtpd_policy_service_request_limit feature to
+limit the number of requests per Postfix SMTP server policy connection.
+This is a workaround to avoid error-recovery delays with policy
+servers that cannot maintain a persistent connection.
+
+Major changes - position-independent executables
+------------------------------------------------
+
+[Feature 20150205] Preliminary support for building position-independent
+executables (PIE), tested on Fedora Core 20, Ubuntu 14.04, FreeBSD
+9 and 10, and NetBSD 6. Specify:
+
+$ make makefiles pie=yes ...other arguments...
+
+On some systems, PIE is used by the ASLR exploit mitigation technique
+(ASLR = Address-Space Layout Randomization). Whether specifying
+"pie=yes" has any effect at all depends on the compiler.  Reportedly,
+some compilers always produce PIE executables.
+
+Major changes - postscreen
+--------------------------
+
+[Feature 20140501] Configurable time limit (postscreen_dnsbl_timeout)
+for DNSBL or DNSWL lookups. This is separate from the timeouts in
+the dnsblog(8) daemon which are controlled by system resolver(3)
+routines.
+
+Major changes - session fingerprint
+-----------------------------------
+
+[Feature 20140801] The Postfix SMTP server now logs at the end of
+a session how many times an SMTP command was successfully invoked,
+followed by the total number of invocations if some invocations
+were unsuccessful.
+
+This logging will enough to diagnose many problems without using
+verbose logging or network sniffer.
+
+    Normal session, no TLS:
+        disconnect from name[addr] ehlo=1 mail=1 rcpt=1 data=1 quit=1
+
+    Normal session. with TLS:
+        disconnect from name[addr] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1
+
+    All recipients rejected, no ESMTP command pipelining:
+        disconnect from name[addr] ehlo=1 mail=1 rcpt=0/1 quit=1
+
+    All recipients rejected, with ESMTP command pipelining:
+        disconnect from name[addr] ehlo=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1
+
+    Password guessing bot, hangs up without QUIT:
+        disconnect from name[addr] ehlo=1 auth=0/1
+
+    Mis-configured client trying to use TLS wrappermode on port 587:
+        disconnect from name[addr] unknown=0/1
+
+Logfile analyzers can trigger on the presence of "/". It indicates
+that Postfix rejected at least one command.
+
+[Feature 20150118] As a late addition, the SMTP server now also
+logs the total number of commands (as "commands=x/y") even when the
+client did not send any commands. This helps logfile analyzers to
+recognize sessions without commands.
+
+Major changes - smtp client
+---------------------------
+
+[Feature 20141227] The new smtp_address_verify_target parameter
+(default: rcpt) determines what protocol stage decides if a recipient
+is valid. Specify "data" for servers that reject recipients after
+the DATA command.
+
+Major changes - smtputf8
+------------------------
+
+[Incompat 20141001] The default settings have changed for
+append_dot_mydomain (new: no, old: yes), master.cf chroot (new:
+n, old: y), and smtputf8 (new: yes, old: no).
+
+[Incompat 20140714] After upgrading Postfix, "postfix reload" (or
+start/stop) is required. Several Postfix-internal protocols have
+been extended to support SMTPUTF8. Failure to reload or restart
+will result in mail staying queued, while Postfix daemons log
+warning messages about unexpected attributes.
+
+[Feature 20140715] Support for Email Address Internationalization
+(EAI) as defined in RFC 6531..6533. This supports UTF-8 in SMTP/LMTP
+sender addresses, recipient addresses, and message header values.
+The implementation is based on initial work by Arnt Gulbrandsen
+that was funded by CNNIC.
+
+See SMTPUTF8_README for a description of Postfix SMTPUTF8 support.
+
+[Feature 20150112] UTF-8 Casefolding support for Postfix lookup
+tables and matchlists (mydestination, relay_domains, etc.).  This
+is enabled only with "smtpuf8 = yes".
+
+[Feature 20150112] With smtputf8_enable=yes, SMTP commands with
+UTF-8 syntax errors are rejected, table lookup results with invalid
+UTF-8 syntax are handled as configuration errors, and UTF-8 syntax
+errors in policy server replies result in execution of the policy
+server's default action.
+
+Major changes - tls support
+---------------------------
+
+(see "Major changes - delivery status notifications" above for
+turning 4XX soft errors into 5XX bounces when a remote SMTP server
+does not offer STARTTLS support).
+
+[Feature 20140209] the Postfix SMTP client now also falls back to
+plaintext when TLS fails AFTER the TLS protocol handshake.
+
+[Feature 20140218] The Postfix SMTP client now requires that a queue
+file is older than $minimal_backoff_time, before falling back from
+failed TLS to plaintext (both during or after the TLS handshake).
+
+[Feature 20141021] Per IETF TLS WG consensus, the tls_session_ticket_cipher
+default setting was changed from aes-128-cbc to aes-256-cbc.
+
+[Feature 20150116] TLS wrappermode support in the Postfix smtp(8)
+client (new smtp_tls_wrappermode parameter) and in posttls-finger(1)
+(new -w option). There still is life in that deprecated protocol,
+and people should not have to jump hoops with stunnel.
--- a/RELEASE_NOTES-3.1
+++ b/RELEASE_NOTES-3.1
@ -0,0 +1,186 @@
+This is the Postfix 3.1 (stable) release.
+
+The stable Postfix release is called postfix-3.1.x where 3=major
+release number, 1=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.2-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 2.11 or earlier, read RELEASE_NOTES-3.0
+before proceeding.
+
+Major changes - address verification safety
+-------------------------------------------
+
+[Feature 20151227] The new address_verify_pending_request_limit
+parameter introduces a safety limit for the number of address
+verification probes in the active queue.  The default limit is 1/4
+of the active queue maximum size. The queue manager enforces the
+limit by tempfailing probe messages that exceed the limit. This
+design avoids dependencies on global counters that get out of sync
+after a process or system crash.
+
+Tempfailing verify requests is not as bad as one might think.  The
+Postfix verify cache proactively updates active addresses weeks
+before they expire. The address_verify_pending_request_limit affects
+only unknown addresses, and inactive addresses that have expired
+from the address verify cache (by default, after 31 days).
+
+Major changes - json support
+----------------------------
+
+[Feature 20151129] Machine-readable, JSON-formatted queue listing
+with "postqueue -j" (no "mailq" equivalent).  The output is a stream
+of JSON objects, one per queue file.  To simplify parsing, each
+JSON object is formatted as one text line followed by one newline
+character. See the postqueue(1) manpage for a detailed description
+of the output format.
+
+Major changes - milter support
+------------------------------
+
+[Feature 20150523] The milter_macro_defaults feature provides an
+optional list of macro name=value pairs. These specify default
+values for Milter macros when no value is available from the SMTP
+session context.
+
+For example, with "milter_macro_defaults = auth_type=TLS", the
+Postfix SMTP server will send an auth_type of "TLS" to a Milter,
+unless the remote client authenticates with SASL.
+
+This feature was originally implemented for a submission service
+that may authenticate clients with a TLS certificate, without having
+to make changes to the code that implements TLS support.
+
+Major changes - output rate control
+-----------------------------------
+
+[Feature 20150710] Destination-independent delivery rate delay
+
+Support to enforce a destination-independent delay between email
+deliveries.  The following example inserts 20 seconds of delay
+between all deliveries with the SMTP transport, limiting the delivery
+rate to at most three messages per minute.
+
+/etc/postfix/main.cf:
+    smtp_transport_rate_delay = 20s
+
+For details, see the description of default_transport_rate_delay
+and transport_transport_rate_delay in the postconf(5) manpage.
+
+Major changes - postscreen dnsbl
+--------------------------------
+
+[Feature 20150710] postscreen support for the TTL of DNSBL and DNSWL
+lookup results
+
+Historically, the default setting "postscreen_dnsbl_ttl = 1h" assumes
+that a "not found" result from a DNSBL server will be valid for one
+hour.  This may have been adequate five years ago when postscreen
+was first implemented, but nowadays, that one hour can result in
+missed opportunities to block new spambots.
+
+To address this, postscreen now respects the TTL of DNSBL "not
+found" replies, as well as the TTL of DNSWL replies (both "found"
+and "not found").  The TTL for a "not found" reply is determined
+according to RFC 2308 (the TTL of an SOA record in the reply).
+
+Support for DNSBL or DNSWL reply TTL values is controlled by two
+configuration parameters:
+
+postscreen_dnsbl_min_ttl (default: 60 seconds).
+
+    This parameter specifies a minimum for the amount of time that
+    a DNSBL or DNSWL result will be cached in the postscreen_cache_map.
+    This prevents an excessive number of postscreen cache updates
+    when a DNSBL or DNSWL server specifies a very small reply TTL.
+
+postscreen_dnsbl_max_ttl (default: $postscreen_dnsbl_ttl or 1 hour)
+
+    This parameter specifies a maximum for the amount of time that
+    a DNSBL or DNSWL result will be cached in the postscreen_cache_map.
+    This prevents cache pollution when a DNSBL or DNSWL server
+    specifies a very large reply TTL.
+
+The postscreen_dnsbl_ttl parameter is now obsolete, and has become
+the default value for the new postscreen_dnsbl_max_ttl parameter.
+
+Major changes - sasl auth safety
+--------------------------------
+
+[Feature 20151031] New "smtpd_client_auth_rate_limit" feature, to
+enforce an optional rate limit on AUTH commands per SMTP client IP
+address.  Similar to other smtpd_client_*_rate_limit features, this
+enforces a limit on the number of requests per $anvil_rate_time_unit.
+
+Major changes - smtpd policy
+----------------------------
+
+[Feature 20150913] New SMTPD policy service attribute "policy_context",
+with a corresponding "smtpd_policy_service_policy_context" configuration
+parameter.  Originally, this was implemented to share the same SMTPD
+policy service endpoint among multiple check_policy_service clients.
+
+Major changes - tls
+-------------------
+
+[Feature 20160207] A new "postfix tls" command to quickly enable
+opportunistic TLS in the Postfix SMTP client or server, and to
+manage SMTP server keys and certificates, including certificate
+signing requests and TLSA DNS records for DANE. See the postfix-tls(1)
+manpage for a detailed description.
+
+[Feature 20160103] The Postfix SMTP client by default enables DANE
+policies when an MX host has a (DNSSEC) secure TLSA DNS record,
+even if the MX DNS record was obtained with insecure lookups.  The
+existence of a secure TLSA record implies that the host wants to
+talk TLS and not plaintext. For details see the
+smtp_tls_dane_insecure_mx_policy configuration parameter.
+
+[Incompat 20150721] As of the middle of 2015, all supported Postfix
+releases no longer enable "export" grade ciphers for opportunistic
+TLS, and no longer use the deprecated SSLv2 and SSLv3 protocols for
+mandatory or opportunistic TLS.
+
+These changes are very unlikely to cause problems with server-to-server
+communication over the Internet, but they may result in interoperability
+problems with ancient client or server implementations on internal
+networks.  To address this problem, you can revert the changes with:
+
+Postfix SMTP client settings:
+
+    lmtp_tls_ciphers = export
+    smtp_tls_ciphers = export
+    lmtp_tls_protocols = !SSLv2
+    smtp_tls_protocols = !SSLv2
+    lmtp_tls_mandatory_protocols = !SSLv2
+    smtp_tls_mandatory_protocols = !SSLv2
+
+Postfix SMTP server settings:
+
+    smtpd_tls_ciphers = export
+    smtpd_tls_protocols =
+    smtpd_tls_mandatory_protocols = !SSLv2
+
+These settings, if put in main.cf, affect all Postfix SMTP client
+or server communication, which may be undesirable. To be more
+selective, use "-o name=value" parameter overrides on specific
+services in master.cf. Execute the command "postfix reload" to make
+the changes effective.
+
+[Incompat 20150719] The default Diffie-Hellman non-export prime was
+updated from 1024 to 2048 bits, because SMTP clients are starting
+to reject TLS handshakes with primes smaller than 2048 bits.
+
+Historically, this prime size is not negotiable, and each site needs
+to determine which prime size works best for the majority of its
+clients. See FORWARD_SECRECY_README for some hints in the quick-start
+section.
+
--- a/RELEASE_NOTES-3.2
+++ b/RELEASE_NOTES-3.2
@ -0,0 +1,180 @@
+This is the Postfix 3.2 (stable) release.
+
+The stable Postfix release is called postfix-3.2.x where 3=major
+release number, 2=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;
+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.0 or earlier, read RELEASE_NOTES-3.1
+before proceeding.
+
+Invisible changes
+-----------------
+
+In addition to the visible changes described below, there is an
+ongoing overhaul of low-level code. With each change come updated
+tests to ensure that future changes will not 'break' compatibility
+with past behavior.
+
+Major changes - address mapping
+-------------------------------
+
+[Feature 20170128] Postfix 3.2 fixes the handling of address
+extensions with email addresses that contain spaces. For example,
+the virtual_alias_maps, canonical_maps, and smtp_generic_maps
+features now correctly propagate an address extension from "aa
+bb+ext"@example.com to "cc dd+ext"@other.example, instead of
+producing broken output.
+
+Major changes - header/body_checks
+----------------------------------
+
+[Feature 20161008] "PASS" and "STRIP" actions in header/body_checks.
+"STRIP" is similar to "IGNORE" but also logs the action, and "PASS"
+disables header, body, and Milter inspection for the remainder of
+the message content.  Contributed by Hobbit.
+
+Major changes - log analysis
+----------------------------
+
+[Feature 20160330] The collate.pl script by Viktor Dukhovni for
+grouping Postfix logfile records into "sessions" based on queue ID
+and process ID information. It's in the auxiliary/collate directory
+of the Postfix source tree.
+
+Major changes - maps support
+----------------------------
+
+[Feature 20160527] Postfix 3.2 cidr tables support if/endif and
+negation (by prepending ! to a pattern), just like regexp and pcre
+tables.  The primarily purpose is to improve readability of complex
+tables. See the cidr_table(5) manpage for syntax details.
+
+[Incompat 20160925] In the Postfix MySQL database client, the default
+option_group value has changed to "client", to enable reading of
+"client" option group settings in the MySQL options file. This fixes
+a "not found" problem with Postfix queries that contain UTF8-encoded
+non-ASCII text.  Specify an empty option_group value (option_group
+=) to get backwards-compatible behavior.
+
+[Feature 20161217] Stored-procedure support for MySQL databases.
+Contributed by John Fawcett. See mysql_table(5) for instructions.
+
+[Feature 20170128] The postmap command, and the inline: and texthash:
+maps now support spaces in left-hand field of the lookup table
+"source text". Use double quotes (") around a left-hand field that
+contains spaces, and use backslash (\) to protect embedded quotes
+in a left-hand field. There is no change in the processing of the
+right-hand field.
+
+Major changes - milter support
+------------------------------
+
+[Feature 20160611] The Postfix SMTP server local IP address and
+port are available in the policy delegation protocol (attribute
+names: server_address, server_port), in the Milter protocol (macro
+names: {daemon_addr}, {daemon_port}), and in the XCLIENT protocol
+(attribute names: DESTADDR, DESTPORT).
+
+[Feature 20161024] smtpd_milter_maps support for per-client Milter
+configuration that overrides smtpd_milters, and that has the same
+syntax. A lookup result of "DISABLE" turns off Milter support. See
+MILTER_README.html for details.
+
+Major changes - policy delegation
+---------------------------------
+
+[Feature 20160611] The Postfix SMTP server local IP address and
+port are available in the policy delegation protocol (attribute
+names: server_address, server_port), in the Milter protocol (macro
+names: {daemon_addr}, {daemon_port}), and in the XCLIENT protocol
+(attribute names: DESTADDR, DESTPORT).
+
+Major changes - postqueue
+-------------------------
+
+[Incompat 20170129] The postqueue command no longer forces all
+message arrival times to be reported in UTC. To get the old behavior,
+set TZ=UTC in main.cf:import_environment (this override is not
+recommended, as it affects all Postfix utities and daemons).
+
+Major changes - safety
+----------------------
+
+[Incompat 20161227] For safety reasons, the sendmail -C option must
+specify an authorized directory: the default configuration directory,
+a directory that is listed in the default main.cf file with
+alternate_config_directories or multi_instance_directories, or the
+command must be invoked with root privileges (UID 0 and EUID 0).
+This mitigates a recurring problem with the PHP mail() function.
+
+Major changes - sasl
+--------------------
+
+[Feature 20160625] The Postfix SMTP server now passes remote client
+and local server network address and port information to the Cyrus
+SASL library. Build with ``make makefiles "CCARGS=$CCARGS
+-DNO_IP_CYRUS_SASL_AUTH"'' for backwards compatibility.
+
+Major changes - smtputf8
+------------------------
+
+[Feature 20161103] Postfix 3.2 disables the 'transitional' compatibility
+between the IDNA2003 and IDNA2008 standards for internationalized
+domain names (domain names beyond the limits of US-ASCII).
+
+This change makes Postfix behavior consistent with contemporary web
+browsers. It affects the handling of some corner cases such as
+German sz and Greek zeta. See http://unicode.org/cldr/utility/idna.jsp
+for more examples.
+
+Specify "enable_idna2003_compatibility = yes" to restore historical
+behavior (but keep in mind that the rest of the world may not make
+that same choice).
+
+Major changes - tls
+-------------------
+
+[Feature 20160828] Fixes for deprecated OpenSSL 1.1.0 API features,
+so that Postfix will build without depending on backwards-compatibility
+support.
+
+[Incompat 20161204] Postfix 3.2 removes tentative features that
+were implemented before the DANE spec was finalized:
+
+- Support for certificate usage PKIX-EE(1),
+
+- The ability to disable digest agility (Postfix now behaves as if
+  "tls_dane_digest_agility = on"), and
+
+- The ability to disable support for "TLSA 2 [01] [12]" records
+  that specify the digest of a trust anchor (Postfix now behaves
+  as if "tls_dane_trust_anchor_digest_enable = yes).
+
+[Feature 20161217] Postfix 3.2 enables elliptic curve negotiation
+with OpenSSL >= 1.0.2.  This changes the default smtpd_tls_eecdh_grade
+setting to "auto", and introduces a new parameter tls_eecdh_auto_curves
+with the names of curves that may be negotiated.
+
+The default tls_eecdh_auto_curves setting is determined at compile
+time, and depends on the Postfix and OpenSSL versions.  At runtime,
+Postfix will skip curve names that aren't supported by the OpenSSL
+library.
+
+Major changes - xclient
+-----------------------
+
+[Feature 20160611] The Postfix SMTP server local IP address and
+port are available in the policy delegation protocol (attribute
+names: server_address, server_port), in the Milter protocol (macro
+names: {daemon_addr}, {daemon_port}), and in the XCLIENT protocol
+(attribute names: DESTADDR, DESTPORT).
+
--- a/RELEASE_NOTES-3.3
+++ b/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.
+
--- a/RELEASE_NOTES-3.4
+++ b/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.
+
--- a/RELEASE_NOTES-3.5
+++ b/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.
--- a/RELEASE_NOTES-3.6
+++ b/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.
--- a/RELEASE_NOTES-3.7
+++ b/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.
+
--- a/Show more
+++ b/Show more