From: Wietse Venema
Date: Sun, 2 Jan 2022 05:00:00 +0000 (-0500)
Subject: postfix-3.7-20220102
X-Git-Tag: v3.7.0-RC1~4
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=275a4b815e2b2116344c9597b7366ce2795a30f4;p=thirdparty%2Fpostfix.git
postfix-3.7-20220102
---
diff --git a/postfix/HISTORY b/postfix/HISTORY
index 14dece592..73ab7d767 100644
--- a/postfix/HISTORY
+++ b/postfix/HISTORY
@@ -25930,6 +25930,13 @@ Apologies for any names omitted.
Regression prevention: copied a queue file record typecheck
from the pickup daemon. Files: *qmgr/qmgr_message.c.
+20211115
+
+ Bugfix (introduced: 20210708): duplicate bounce_notice_recipient
+ entries in postconf output. The fix to send SMTP session
+ transcripts to bounce_notice_recipient was incomplete.
+ Reported by Vincent Lefevre. File: smtpd/smtpd.c.
+
20211127
Feature: support for the pcre2 library (the legacy pcre
@@ -25968,3 +25975,192 @@ Apologies for any names omitted.
automatically authorize proxied maps inside pipemap (example:
pipemap:{proxy:maptype:mapname, ...}) or inside unionmap. Problem
reported by Mirko Vogt. Files: proxymap/proxymap.c.
+
+20211218
+
+ Typo fixes based on automated scans of C source code comments.
+ Verified that the .o files have not changed. Files:
+ bounce/bounce_notify_util.c, cleanup/cleanup_api.c,
+ cleanup/cleanup_message.c, dns/dns_lookup.c, flush/flush.c,
+ global/compat_level.c, global/db_common.c,
+ global/deliver_request.c, global/dict_ldap.c, global/dict_sqlite.c,
+ global/dynamicmaps.c, global/mail_conf_time.c, global/mail_copy.c,
+ global/mail_params.h, global/mail_proto.h, global/memcache_proto.c,
+ global/normalize_mailhost_addr.c, global/quote_822_local.c,
+ global/test_main.c, global/verify.c, global/verify_sender_addr.c,
+ local/unknown.c, master/dgram_server.c, master/event_server.c,
+ master/multi_server.c, master/single_server.c,
+ master/trigger_server.c, oqmgr/qmgr_entry.c,
+ postconf/postconf_dbms.c, postconf/postconf_master.c,
+ postconf/postconf_user.c, postdrop/postdrop.c, postmap/postmap.c,
+ postmulti/postmulti.c, postqueue/showq_compat.c,
+ postscreen/postscreen_smtpd.c, postscreen/postscreen_starttls.c,
+ posttls-finger/posttls-finger.c, proxymap/proxymap.c,
+ qmgr/qmgr_entry.c, qmqpd/qmqpd_peer.c, smtp/smtp.h,
+ smtp/smtp_proto.c, smtpd/smtpd_check.c, smtpd/smtpd_peer.c,
+ tls/tls_certkey.c, tls/tls_client.c, tls/tls_fprint.c,
+ tls/tls_misc.c, tls/tls_server.c, tlsmgr/tlsmgr.c,
+ tlsproxy/tlsproxy.c, trivial-rewrite/resolve.c,
+ trivial-rewrite/transport.c, trivial-rewrite/trivial-rewrite.c,
+ util/argv.c, util/dict_cache.c, util/dict_cdb.c, util/dict_file.c,
+ util/dict_random.c, util/dict_random.h, util/dict_thash.c,
+ util/dup2_pass_on_exec.c, util/edit_file.c, util/extpar.c,
+ util/gccw.c, util/mac_expand.c, util/mac_expand.h,
+ util/myaddrinfo.c, util/name_mask.c, util/sane_link.c,
+ util/sane_rename.c, util/unix_dgram_connect.c,
+ util/unix_dgram_listen.c, util/unix_pass_fd_fix.c,
+ util/vstring.c, xsasl/xsasl_dovecot_server.c.
+
+ Typo fixes based on automated scans of other files. Files:
+ auxiliary/qshape/qshape.pl, conf/post-install,
+ conf/postmulti-script, makedefs, postfix-install,
+ proto/postconf.proto, TLS_ACKNOWLEDGEMENTS, TLS_CHANGES.
+
+ Documentation: added a note to the cidr_table manpage that
+ with an inline CIDR map, "$" needs to be specified as "$$"
+ to avoid $name expansion surprises. File: proto/cidr_table.
+
+20211220
+
+ Bugfix (introduced: Postfix 2.5): off-by-one error while writing
+ a string terminator. This code had passed all memory corruption
+ tests, presumably because it wrote over an alignment padding byte,
+ or over an adjacent character byte that was never read. Reported
+ by Robert Siemer. Files: *qmgr/qmgr_feedback.c.
+
+ Typo fixes from Raf, based on manual inspection. Verified
+ that the .o files have not changed. Files: conf/main.cf,
+ mantools/postlink, proto/ADDRESS_REWRITING_README.html,
+ proto/BACKSCATTER_README.html,
+ proto/BASIC_CONFIGURATION_README.html, proto/BDAT_README.html,
+ proto/BUILTIN_FILTER_README.html, proto/COMPATIBILITY_README.html,
+ proto/CONNECTION_CACHE_README.html, proto/DATABASE_README.html,
+ proto/DEBUG_README.html, proto/FORWARD_SECRECY_README.html,
+ proto/INSTALL.html, proto/IPV6_README.html, proto/LDAP_README.html,
+ proto/LINUX_README.html, proto/MAILLOG_README.html,
+ proto/MILTER_README.html, proto/MULTI_INSTANCE_README.html,
+ proto/MYSQL_README.html, proto/POSTSCREEN_3_5_README.html,
+ proto/POSTSCREEN_README.html, proto/QSHAPE_README.html,
+ proto/SASL_README.html, proto/SCHEDULER_README.html,
+ proto/SMTPD_ACCESS_README.html, proto/SMTPD_POLICY_README.html,
+ proto/SMTPD_PROXY_README.html, proto/SMTPUTF8_README.html,
+ proto/SQLITE_README.html, proto/STANDARD_CONFIGURATION_README.html,
+ proto/STRESS_README.html, proto/TLS_LEGACY_README.html,
+ proto/TLS_README.html, proto/TUNING_README.html,
+ proto/VIRTUAL_README.html, proto/access, proto/canonical,
+ proto/generic, proto/ldap_table, proto/master, proto/mysql_table,
+ proto/pgsql_table, proto/postconf.proto, proto/relocated,
+ proto/sqlite_table, proto/transport, proto/virtual,
+ global/mail_version.h, local/local.c, pipe/pipe.c,
+ postalias/postalias.c, postconf/postconf.c, postfix/postfix.c,
+ postmap/postmap.c, postmulti/postmulti.c,
+ posttls-finger/posttls-finger.c, sendmail/sendmail.c,
+ smtpstone/smtp-sink.c, tlsproxy/tlsproxy.c,
+ trivial-rewrite/trivial-rewrite.c, virtual/virtual.c.
+
+20211221
+
+ Documentation: reverted some postconf(5) changes from
+ "Specify a non-zero time value" to "Specify a non-negative
+ time value". File: proto/postconf.proto.
+
+ Documentation: reverted "destination concurrency limit" to
+ "destination recipient limit". File: proto/SCHEDULER_README.html.
+
+ Documentation: rephrased conditional $name expositions for
+ forward_path and command_execution_directory. File:
+ local/local.c.
+
+ Documentation: added Postfix 3.0 syntax to postconf(5)
+ descriptions of command_execution_directory, default_rbl_reply,
+ forward_path, luser_relay, recipient_delimiter. File:
+ proto/postconf.proto.
+
+ Documentation: updated descriptions of smtpd_error_sleep_time
+ and smtpd_soft_error_limit. File: proto/postconf.proto.
+
+ Fixed non-UTF8 quotes in TLS_CHANGES that caused nvi to
+ truncate the file.
+
+ Fixed a remaining typo in util/load_lib.c.
+
+20211222
+
+ Added a top-level 'make typo-check' target to automate
+ the typo checks (this only works on Wietse's development
+ system, because it depends on specific implementations of
+ spell and lynx). Files: Makefile.in, mantools/comment.c,
+ mantools/deroff, mantools/check-double-cc,
+ mantools/check-double-install-proto-text,
+ mantools/check-double-proto-html, mantools/check-spell-cc,
+ mantools/check-spell-install-proto-text,
+ mantools/check-spell-proto-html, proto/stop, proto/stop.double-cc,
+ proto/stop.double-install-proto-text, proto/stop.double-proto-html,
+ proto/stop.spell-cc, proto/stop.spell-proto-html.
+
+ Cleanup: manpages don't need \' - that causes groff to emit
+ non-ASCII text (depending on the locale). Christian Goettsche.
+ Files: sendmail/sendmail.c, spawn/spawn.c.
+
+20211223
+
+ Report unsupported usage. Do not link Postfix database
+ plugins against libpostfix-util or libpostfix-global. This
+ introduces false build dependencies. File: makedefs.
+
+ Report unsupported usage. Do not build with LD_LIBRARY_PATH.
+ File: makedefs.
+
+ Documented the implementation-dependent mailbox_size_limit
+ and message_size_limit maximal values. File: proto/postconf.proto.
+
+ Cleanup: make typo-check tests portable across differernt
+ spellcheck implementations. Files: proto/stop.spell-proto-html,
+ proto/stop.spell-cc.
+
+ Cleanup: added missing parameters to the mantools/postlink
+ script, based on output from the mantools/check-postlink
+ script.
+
+ Cleanup: added missing _maps parameter names to the
+ proxy_read_maps default value, based on output from the
+ mantools/missing-proxy-read-maps script.
+ File: global/mail_params.h.
+
+ Sanity: added LANG=C to the typo-check scripts to get
+ consistent output. Files: mantools/check-spell-proto-html,
+ mantools/check-spell-install-proto-text, mantools/check-spell-cc,
+ mantools/check-double-proto-html,
+ mantools/check-double-install-proto-text, mantools/check-double-cc.
+
+20211224
+
+ Cleanup: some compilter complains about indentation in a
+ multiline macro. File: util/dict_db.c.
+
+20211231
+
+ Cleanup: informative error message after failure to connect
+ to 'dovecot' socket. File: src/xsasl/xsasl_dovecot_server.c.
+
+20220101
+
+ Cleanup: AppArmor may return EPERM for permission errors.
+ This could result in a false "mail system is down" error
+ message from the postqueue command. File: postqueue/postqueue.c.
+
+202220102
+
+ Cleanup: log the reason why the postqueue command thinks
+ that the mail system is down, in case some security software
+ or kernel bug emits a weird error. File: postqueue/postqueue.c.
+
+ Robustness: randomize the initial state of Postfix in-memory
+ hash tables, to defend against 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 service. Other
+ tables with attacker-chosen lookup keys are limited in size.
+ The fix is cheap, and therefore implemented for all Postfix
+ in-memory hash tables. Problem reported by Pascal Junod.
+ File: util/htable.c.
diff --git a/postfix/INSTALL b/postfix/INSTALL
index 28a7e68a3..4ab046d40 100644
--- a/postfix/INSTALL
+++ b/postfix/INSTALL
@@ -331,7 +331,7 @@ install" or "make upgrade".
# make upgrade meta_directory=/usr/libexec/postfix ...
# make install meta_directory=/usr/libexec/postfix ...
-As with the command "make makefiles, the command "make install/upgrade
+As with the command "make makefiles", the command "make install/upgrade
name=value..." will replace the string MAIL_VERSION at the end of a
configuration parameter value with the Postfix release version. Do not try to
specify something like $mail_version on this command line. This produces
@@ -1088,6 +1088,7 @@ Finally, build the indexed aliases file with one of the following commands:
# newaliases
# sendmail -bi
+ # postalias /etc/aliases (pathname is system dependent!)
11 - To chroot or not to chroot
diff --git a/postfix/Makefile.in b/postfix/Makefile.in
index 65e7911d3..b2ad1842a 100644
--- a/postfix/Makefile.in
+++ b/postfix/Makefile.in
@@ -1,5 +1,5 @@
# To test with valgrind:
-# make -i tests VALGRIND="valgrind --tool=memcheck --log-file=/some/where.%p"
+# 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)'
@@ -114,7 +114,26 @@ manpages:
(set -e; echo "[$$i]"; cd $$i; $(MAKE) -f Makefile.in $(OPTS) MAKELEVEL=) || exit 1; \
done =
+ 2) when Postfix should forward mail from only the local machine.
- * Specify "mynetworks_style = subnet" (the default) when Postfix should
- forward mail from SMTP clients in the same IP subnetworks as the local
- machine. On Linux, this works correctly only with interfaces specified with
- the "ifconfig" command.
+ * Specify "mynetworks_style = subnet" (the default when compatibility_level <
+ 2) when Postfix should forward mail from SMTP clients in the same IP
+ subnetworks as the local machine. On Linux, this works correctly only with
+ interfaces specified with the "ifconfig" or "ip" command.
* Specify "mynetworks_style = class" when Postfix should forward mail from
SMTP clients in the same IP class A/B/C networks as the local machine.
diff --git a/postfix/README_FILES/BDAT_README b/postfix/README_FILES/BDAT_README
index 124880409..6ed565ccd 100644
--- a/postfix/README_FILES/BDAT_README
+++ b/postfix/README_FILES/BDAT_README
@@ -119,6 +119,6 @@ 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, is
-it a useless restriction that Postfix will not enforce.
+response. But as this text does not appear in RFC 3030 which defines BDAT, it
+is a useless restriction that Postfix will not enforce.
diff --git a/postfix/README_FILES/BUILTIN_FILTER_README b/postfix/README_FILES/BUILTIN_FILTER_README
index 5ed04169d..2ce639df5 100644
--- a/postfix/README_FILES/BUILTIN_FILTER_README
+++ b/postfix/README_FILES/BUILTIN_FILTER_README
@@ -300,9 +300,9 @@ CCoonnffiigguurriinngg hheeaaddeerr//bbooddyy cchheecc
The following information applies to Postfix 2.1. Earlier Postfix versions do
not support the receive_override_options feature.
-If you are MX service provider and want to apply disable head/body checks for
-some domains, you can configure ONE Postfix instance with multiple SMTP server
-IP addresses in master.cf. Each address provides a different service.
+If you are an MX service provider and want to enable header/body checks only
+for some domains, you can configure ONE Postfix instance with multiple SMTP
+server IP addresses in master.cf. Each address provides a different service.
/etc/postfix.master.cf:
# =================================================================
diff --git a/postfix/README_FILES/COMPATIBILITY_README b/postfix/README_FILES/COMPATIBILITY_README
index 112063a62..55182b7f6 100644
--- a/postfix/README_FILES/COMPATIBILITY_README
+++ b/postfix/README_FILES/COMPATIBILITY_README
@@ -156,7 +156,7 @@ UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee dd
The mynetworks_style default value has changed from "subnet" to "host". This
parameter is used to implement the "permit_mynetworks" feature. The change
-could in unexpected 'access denied' errors after Postfix is updated from an
+could cause unexpected 'access denied' errors after Postfix is updated from an
older version. The backwards-compatibility safety net is designed to prevent
such surprises.
diff --git a/postfix/README_FILES/CONNECTION_CACHE_README b/postfix/README_FILES/CONNECTION_CACHE_README
index e1a0f07df..f578fb7d1 100644
--- a/postfix/README_FILES/CONNECTION_CACHE_README
+++ b/postfix/README_FILES/CONNECTION_CACHE_README
@@ -113,7 +113,7 @@ mail delivery request. Meanwhile, any smtp(8) client process can ask the scache
The connection cache can be searched by destination domain name (the right-hand
side of the recipient address) and by the IP address of the host at the other
end of the connection. This allows Postfix to reuse a connection even when the
-remote host is mail server for domains with different names.
+remote host is a mail server for domains with different names.
CCoonnnneeccttiioonn ccaacchhee ccoonnffiigguurraattiioonn
diff --git a/postfix/README_FILES/DATABASE_README b/postfix/README_FILES/DATABASE_README
index 99e10a755..3fd88c3e6 100644
--- a/postfix/README_FILES/DATABASE_README
+++ b/postfix/README_FILES/DATABASE_README
@@ -58,7 +58,7 @@ With some tables, however, Postfix needs to know only if the lookup key exists.
Any non-empty lookup result value may be used here: the lookup result is not
used. Examples are the local_recipient_maps that determine what local
recipients Postfix accepts in mail from the network, the mydestination
-parameter that specifies what domains Postfix delivers locally, or the
+parameter that specifies what domains Postfix delivers locally for, or the
mynetworks parameter that specifies the IP addresses of trusted clients or
client networks. Technically, these are lists, not tables. Despite the
difference, Postfix lists are described here because they use the same
@@ -221,8 +221,8 @@ To find out what database types your Postfix system supports, use the "ppooss
to create a database file for just a few fixed elements. See also the
static: map type.
iinntteerrnnaall
- A non-shared, in-memory hash table. Its content are lost when a process
- terminates.
+ A non-shared, in-memory hash table. Its contents are lost when a
+ process terminates.
llmmddbb
OpenLDAP LMDB database. This is available only on systems with support
for LMDB databases. Public database files are created with the postmap
diff --git a/postfix/README_FILES/DEBUG_README b/postfix/README_FILES/DEBUG_README
index a277d9663..3a895c743 100644
--- a/postfix/README_FILES/DEBUG_README
+++ b/postfix/README_FILES/DEBUG_README
@@ -386,12 +386,12 @@ When reporting a problem, be sure to include the following information.
o "ppoossttccoonnff --MMff" (Postfix 2.9 or later).
- * Better, provide output from the ppoossttffiinnggeerr tool. This can be found at http:
- //ftp.wl0.org/SOURCES/postfinger.
+ * Better, provide output from the ppoossttffiinnggeerr tool. This can be found at
+ https://github.com/ford--prefect/postfinger.
* If the problem is SASL related, consider including the output from the
- ssaassllffiinnggeerr tool. This can be found at http://postfix.state-of-mind.de/
- patrick.koetter/saslfinger/.
+ ssaassllffiinnggeerr tool. This can be found at https://packages.debian.org/
+ search?keywords=sasl2-bin.
* If the problem is about too much mail in the queue, consider including
output from the qqsshhaappee tool, as described in the QSHAPE_README file.
diff --git a/postfix/README_FILES/FORWARD_SECRECY_README b/postfix/README_FILES/FORWARD_SECRECY_README
index 4615b89c1..3eb707cc8 100644
--- a/postfix/README_FILES/FORWARD_SECRECY_README
+++ b/postfix/README_FILES/FORWARD_SECRECY_README
@@ -121,7 +121,7 @@ Exchange servers and is not recommended for now.
EEDDHH SSeerrvveerr ssuuppppoorrtt
-Postfix >= 2.2 support 1024-bit-prime EDH out of the box, with no additional
+Postfix >= 2.2 supports 1024-bit-prime EDH out of the box, with no additional
configuration, but you may want to override the default prime to be 2048 bits
long, and you may want to regenerate your primes periodically. See the quick-
start section for details. With Postfix >= 3.1 the out of the box (compiled-in)
@@ -153,7 +153,7 @@ recommended configuration to work around this issue.
EEEECCDDHH SSeerrvveerr ssuuppppoorrtt
-Postfix >= 2.6 support NIST P-256 EECDH when built with OpenSSL >= 1.0.0. When
+Postfix >= 2.6 supports NIST P-256 EECDH when built with OpenSSL >= 1.0.0. When
the remote SMTP client also supports EECDH and implements the P-256 curve,
forward secrecy just works.
@@ -412,7 +412,7 @@ with one of these prefixes. This pattern is likely to persist until some new
key-exchange mechanism is invented that also supports forward secrecy.
The actual key length and raw algorithm key length are generally the same with
-non-export ciphers, but may they differ for the legacy export ciphers where the
+non-export ciphers, but they may differ for the legacy export ciphers where the
actual key is artificially shortened.
Starting with TLS 1.3 the cipher name no longer contains enough information to
diff --git a/postfix/README_FILES/INSTALL b/postfix/README_FILES/INSTALL
index ae822b935..e9d4f0695 100644
--- a/postfix/README_FILES/INSTALL
+++ b/postfix/README_FILES/INSTALL
@@ -331,7 +331,7 @@ install" or "make upgrade".
# make upgrade meta_directory=/usr/libexec/postfix ...
# make install meta_directory=/usr/libexec/postfix ...
-As with the command "make makefiles, the command "make install/upgrade
+As with the command "make makefiles", the command "make install/upgrade
name=value..." will replace the string MAIL_VERSION at the end of a
configuration parameter value with the Postfix release version. Do not try to
specify something like $mail_version on this command line. This produces
@@ -1088,6 +1088,7 @@ Finally, build the indexed aliases file with one of the following commands:
# newaliases
# sendmail -bi
+ # postalias /etc/aliases (pathname is system dependent!)
1111 -- TToo cchhrroooott oorr nnoott ttoo cchhrroooott
diff --git a/postfix/README_FILES/IPV6_README b/postfix/README_FILES/IPV6_README
index df6ad7ac2..a29560c47 100644
--- a/postfix/README_FILES/IPV6_README
+++ b/postfix/README_FILES/IPV6_README
@@ -98,7 +98,7 @@ configuration work with Postfix.
mynetworks = 127.0.0.0/8 168.100.189.0/28 [::1]/128 [fe80::]/10 [2001:
240:587::]/64
- If you did specify the mynetworks parameter value in main.cf, you need
+ If you did specify the mynetworks parameter value in main.cf, you need to
update the mynetworks value to include the IPv6 networks the system is in.
Be sure to specify IPv6 address information inside "[]", like this:
diff --git a/postfix/README_FILES/LDAP_README b/postfix/README_FILES/LDAP_README
index a6cb84e5e..eeef565a6 100644
--- a/postfix/README_FILES/LDAP_README
+++ b/postfix/README_FILES/LDAP_README
@@ -394,7 +394,7 @@ NNootteess aanndd tthhiinnggss ttoo tthhiinnkk aabboouu
query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")
(maildrop="*:*")(maildrop="*/*"))))
- * And for that matter, even for aliases, you may not want users able to
+ * And for that matter, even for aliases, you may not want users to be able to
specify their maildrops as programs, includes, etc. This might be
particularly pertinent on a "sealed" server where they don't have local
UNIX accounts, but exist only in LDAP and Cyrus. You might allow the fun
diff --git a/postfix/README_FILES/LINUX_README b/postfix/README_FILES/LINUX_README
index a8569c7bb..6330278a1 100644
--- a/postfix/README_FILES/LINUX_README
+++ b/postfix/README_FILES/LINUX_README
@@ -4,10 +4,10 @@ PPoossttffiixx aanndd LLiinnuuxx
HHoosstt llooookkuupp iissssuueess
-By default Linux /etc/hosts lookups do not support multiple IP address per
+By default Linux /etc/hosts lookups do not support multiple IP addresses per
hostname. This causes warnings from the Postfix SMTP server that "hostname XXX
does not resolve to address YYY", and is especially a problem with hosts that
-have both IPv4 and IPv6 addresses. To fix, turn on support for multiple IP
+have both IPv4 and IPv6 addresses. To fix this, turn on support for multiple IP
addresses:
/etc/host.conf:
@@ -42,7 +42,7 @@ file for further information.
PPrrooccmmaaiill iissssuueess
-On RedHat Linux 7.1 and later pprrooccmmaaiill no longer has permission to write the
+On RedHat Linux 7.1 and later pprrooccmmaaiill no longer has permission to write to the
mail spool directory. Workaround:
# chmod 1777 /var/spool/mail
diff --git a/postfix/README_FILES/MAILLOG_README b/postfix/README_FILES/MAILLOG_README
index d0849bb73..ec63b96fe 100644
--- a/postfix/README_FILES/MAILLOG_README
+++ b/postfix/README_FILES/MAILLOG_README
@@ -73,7 +73,7 @@ implements the following steps:
Notes:
- * This command will not rotate a logfile with pathname under the /dev
+ * 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.
@@ -86,7 +86,7 @@ Background:
as well as non-daemon programs for local mail submission or Postfix
management.
- * Logging to Postfix logfile or stdout requires the Postfix postlogd(8)
+ * 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.
diff --git a/postfix/README_FILES/MILTER_README b/postfix/README_FILES/MILTER_README
index 6cdea837d..9e866d4cc 100644
--- a/postfix/README_FILES/MILTER_README
+++ b/postfix/README_FILES/MILTER_README
@@ -163,7 +163,7 @@ The general syntax for listening sockets is as follows:
Connect to the local UNIX-domain server that is bound to the specified
pathname. If the smtpd(8) or cleanup(8) process runs chrooted, an
absolute pathname is interpreted relative to the Postfix queue
- directory.
+ directory. On many systems, llooccaall is a synonym for uunniixx
iinneett::host::port
Connect to the specified TCP port on the specified local or remote
@@ -507,7 +507,7 @@ queue ID, sender, or recipient).
To force a macro to be sent even when its value has not been updated, you may
specify macro default values with the milter_macro_defaults parameter. Specify
zero or more name=value pairs separated by comma or whitespace; you may even
-specify macro names that Postfix does know about!
+specify macro names that Postfix does not know about!
WWoorrkkaarroouunnddss
diff --git a/postfix/README_FILES/MULTI_INSTANCE_README b/postfix/README_FILES/MULTI_INSTANCE_README
index 7e930f25c..1f261f6c0 100644
--- a/postfix/README_FILES/MULTI_INSTANCE_README
+++ b/postfix/README_FILES/MULTI_INSTANCE_README
@@ -196,7 +196,7 @@ running "make"), then start and test the null-client:
testing
EOF
-The test message should be delivered the members of the "mtaadmin" address
+The test message should be delivered to the members of the "mtaadmin" address
group (or whatever address group you choose) with the following headers:
From: mtaadmin+root=mta1@example.com
@@ -294,7 +294,7 @@ injection SMTP service. Typical additions include:
smtpd_relay_restrictions =
smtpd_recipient_restrictions = permit_mynetworks, reject
- # Tolerate occasional high latency in the content filter.
+ # Tolerate occasional high latency in the content filter.
#
smtpd_timeout = 1200s
diff --git a/postfix/README_FILES/MYSQL_README b/postfix/README_FILES/MYSQL_README
index c6633a918..5a728fb06 100644
--- a/postfix/README_FILES/MYSQL_README
+++ b/postfix/README_FILES/MYSQL_README
@@ -29,7 +29,6 @@ The Postfix MySQL client utilizes the mysql client library, which can be
obtained from:
http://www.mysql.com/downloads/
- http://sourceforge.net/projects/mysql/
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
@@ -132,5 +131,5 @@ CCrreeddiittss
configuration feature.
* Liviu Daia with further refinements from Jose Luis Tallon and Victor
Duchovni developed the common query, result_format, domain and
- expansion_limit interface for LDAP, MySQL and PosgreSQL.
+ expansion_limit interface for LDAP, MySQL and PostgreSQL.
diff --git a/postfix/README_FILES/POSTSCREEN_3_5_README b/postfix/README_FILES/POSTSCREEN_3_5_README
index 4fb3d896b..ab67800be 100644
--- a/postfix/README_FILES/POSTSCREEN_3_5_README
+++ b/postfix/README_FILES/POSTSCREEN_3_5_README
@@ -195,9 +195,9 @@ weaker anti-spam policies than primary MX hosts).
introduce a common point of failure.
* First, configure the host to listen on both primary and backup MX
- addresses. Use the appropriate ifconfig command for the local operating
- system, or update the appropriate configuration files and "refresh" the
- network protocol stack.
+ addresses. Use the appropriate ifconfig or ip command for the local
+ operating system, or update the appropriate configuration files and
+ "refresh" the network protocol stack.
Second, configure Postfix to listen on the new IP address (this step is
needed when you have specified inet_interfaces in main.cf).
@@ -642,8 +642,9 @@ Notes:
* Some postscreen(8) configuration parameters implement stress-dependent
behavior. This is supported only when the default value is stress-dependent
(that is, "postconf -d parametername" output shows "parametername = $
- {stress?something}${stress:something}"). Other parameters always evaluate
- as if the stress value is the empty string.
+ {stress?something}${stress:something}" or "parametername = ${stress?
+ {something}:{something}}"). Other parameters always evaluate as if the
+ stress value is the empty string.
* See "Tests before the 220 SMTP server greeting" for details about the
logging from these postscreen(8) tests.
diff --git a/postfix/README_FILES/POSTSCREEN_README b/postfix/README_FILES/POSTSCREEN_README
index d4399043b..9467e68f6 100644
--- a/postfix/README_FILES/POSTSCREEN_README
+++ b/postfix/README_FILES/POSTSCREEN_README
@@ -202,9 +202,9 @@ weaker anti-spam policies than primary MX hosts).
introduce a common point of failure.
* First, configure the host to listen on both primary and backup MX
- addresses. Use the appropriate ifconfig command for the local operating
- system, or update the appropriate configuration files and "refresh" the
- network protocol stack.
+ addresses. Use the appropriate ifconfig or ip command for the local
+ operating system, or update the appropriate configuration files and
+ "refresh" the network protocol stack.
Second, configure Postfix to listen on the new IP address (this step is
needed when you have specified inet_interfaces in main.cf).
@@ -652,8 +652,9 @@ Notes:
* Some postscreen(8) configuration parameters implement stress-dependent
behavior. This is supported only when the default value is stress-dependent
(that is, "postconf -d parametername" output shows "parametername = $
- {stress?something}${stress:something}"). Other parameters always evaluate
- as if the stress value is the empty string.
+ {stress?something}${stress:something}" or "parametername = ${stress?
+ {something}:{something}}"). Other parameters always evaluate as if the
+ stress value is the empty string.
* See "Tests before the 220 SMTP server greeting" for details about the
logging from these postscreen(8) tests.
diff --git a/postfix/README_FILES/QSHAPE_README b/postfix/README_FILES/QSHAPE_README
index 311797a6f..eba722e13 100644
--- a/postfix/README_FILES/QSHAPE_README
+++ b/postfix/README_FILES/QSHAPE_README
@@ -68,11 +68,11 @@ sender domain distribution for captured spam in the "hold" queue:
When the output is a terminal intermediate results showing the top 20 domains
(-n option) are displayed after every 1000 messages (-N option) and the final
output also shows only the top 20 domains. This makes qshape useful even when
-the deferred queue is very large and it may otherwise take prohibitively long
-to read the entire deferred queue.
+the "deferred" queue is very large and it may otherwise take prohibitively long
+to read the entire "deferred" queue.
-By default, qshape shows statistics for the union of both the incoming and
-active queues which are the most relevant queues to look at when analyzing
+By default, qshape shows statistics for the union of both the "incoming" and
+"active" queues which are the most relevant queues to look at when analyzing
performance.
One can request an alternate list of queues:
@@ -80,8 +80,8 @@ One can request an alternate list of queues:
$ qshape deferred
$ qshape incoming active deferred
-this will show the age distribution of the deferred queue or the union of the
-incoming active and deferred queues.
+this will show the age distribution of the "deferred" queue or the union of the
+"incoming", "active" and "deferred" queues.
Command line options control the number of display "buckets", the age limit for
the smallest bucket, display of parent domain counts and so on. The "-h" option
@@ -96,16 +96,16 @@ recipient counts, approximately when a burst of mail started, and when it
stopped.
The problem destinations or sender domains appear near the top left corner of
-the output table. Remember that the active queue can accommodate up to 20000
+the output table. Remember that the "active" queue can accommodate up to 20000
($qmgr_message_active_limit) messages. To check whether this limit has been
reached, use:
$ qshape -s active (show sender statistics)
-If the total sender count is below 20000 the active queue is not yet saturated,
-any high volume sender domains show near the top of the output.
+If the total sender count is below 20000 the "active" queue is not yet
+saturated, any high volume sender domains show near the top of the output.
-With oqmgr(8) the active queue is also limited to at most 20000 recipient
+With oqmgr(8) the "active" queue is also limited to at most 20000 recipient
addresses ($qmgr_message_recipient_limit). To check for exhaustion of this
limit use:
@@ -142,19 +142,19 @@ forget to include the top 10 or 20 lines of qshape(1) output.
EExxaammppllee 11:: HHeeaalltthhyy qquueeuuee
-When looking at just the incoming and active queues, under normal conditions
-(no congestion) the incoming and active queues are nearly empty. Mail leaves
-the system almost as quickly as it comes in or is deferred without congestion
-in the active queue.
+When looking at just the "incoming" and "active" queues, under normal
+conditions (no congestion) the "incoming" and "active" queues are nearly empty.
+Mail leaves the system almost as quickly as it comes in or is deferred without
+congestion in the "active" queue.
- $ qshape (show incoming and active queue status)
+ $ qshape (show "incoming" and "active" queue status)
T 5 10 20 40 80 160 320 640 1280 1280+
TOTAL 5 0 0 0 1 0 0 0 1 1 2
meri.uwasa.fi 5 0 0 0 1 0 0 0 1 1 2
-If one looks at the two queues separately, the incoming queue is empty or
-perhaps briefly has one or two messages, while the active queue holds more
+If one looks at the two queues separately, the "incoming" queue is empty or
+perhaps briefly has one or two messages, while the "active" queue holds more
messages and for a somewhat longer time:
$ qshape incoming
@@ -173,8 +173,8 @@ EExxaammppllee 22:: DDeeffeerrrreedd qquueeuuee ffuulll
This is from a server where recipient validation is not yet available for some
of the hosted domains. Dictionary attacks on the unvalidated domains result in
bounce backscatter. The bounces dominate the queue, but with proper tuning they
-do not saturate the incoming or active queues. The high volume of deferred mail
-is not a direct cause for alarm.
+do not saturate the "incoming" or "active" queues. The high volume of deferred
+mail is not a direct cause for alarm.
$ qshape deferred | head
@@ -192,8 +192,8 @@ is not a direct cause for alarm.
The domains shown are mostly bulk-mailers and all the volume is the tail end of
the time distribution, showing that short term arrival rates are moderate.
Larger numbers and lower message ages are more indicative of current trouble.
-Old mail still going nowhere is largely harmless so long as the active and
-incoming queues are short. We can also see that the groups.msn.com
+Old mail still going nowhere is largely harmless so long as the "active" and
+"incoming" queues are short. We can also see that the groups.msn.com
undeliverables are low rate steady stream rather than a concentrated dictionary
attack that is now over.
@@ -215,7 +215,7 @@ messages are bounces.
EExxaammppllee 33:: CCoonnggeessttiioonn iinn tthhee aaccttiivvee qquueeuuee
This example is taken from a Feb 2004 discussion on the Postfix Users list.
-Congestion was reported with the active and incoming queues large and not
+Congestion was reported with the "active" and "incoming" queues large and not
shrinking despite very large delivery agent process limits. The thread is
archived at: http://groups.google.com/
groups?threadm=c0b7js$2r65$1@FreeBSD.csie.NCTU.edu.tw and http://
@@ -224,7 +224,7 @@ archives.neohapsis.com/archives/postfix/2004-02/thread.html#1371
Using an older version of qshape(1) it was quickly determined that all the
messages were for just a few destinations:
- $ qshape (show incoming and active queue status)
+ $ qshape (show "incoming" and "active" queue status)
T A 5 10 20 40 80 160 320 320+
TOTAL 11775 9996 0 0 1 1 42 94 221 1420
@@ -232,10 +232,10 @@ messages were for just a few destinations:
lists.sourceforge.net 2313 2313 0 0 0 0 0 0 0 0
gzd.gotdns.com 102 0 0 0 0 0 0 0 2 100
-The "A" column showed the count of messages in the active queue, and the
-numbered columns showed totals for the deferred queue. At 10000 messages
-(Postfix 1.x active queue size limit) the active queue is full. The incoming
-was growing rapidly.
+The "A" column showed the count of messages in the "active" queue, and the
+numbered columns showed totals for the "deferred" queue. At 10000 messages
+(Postfix 1.x "active" queue size limit) the "active" queue is full. The
+"incoming" queue was growing rapidly.
With the trouble destinations clearly identified, the administrator quickly
found and fixed the problem. It is substantially harder to glean the same
@@ -246,7 +246,7 @@ by looking at the queue one message at a time.
EExxaammppllee 44:: HHiigghh vvoolluummee ddeessttiinnaattiioonn bbaacckklloogg
When a site you send a lot of email to is down or slow, mail messages will
-rapidly build up in the deferred queue, or worse, in the active queue. The
+rapidly build up in the "deferred" queue, or worse, in the "active" queue. The
qshape output will show large numbers for the destination domain in all age
buckets that overlap the starting time of the problem:
@@ -258,14 +258,14 @@ buckets that overlap the starting time of the problem:
...
Here the "highvolume.com" destination is continuing to accumulate deferred
-mail. The incoming and active queues are fine, but the deferred queue started
-growing some time between 1 and 2 hours ago and continues to grow.
+mail. The "incoming" and "active" queues are fine, but the "deferred" queue
+started growing some time between 1 and 2 hours ago and continues to grow.
If the high volume destination is not down, but is instead slow, one might see
-similar congestion in the active queue. Active queue congestion is a greater
-cause for alarm; one might need to take measures to ensure that the mail is
-deferred instead or even add an access(5) rule asking the sender to try again
-later.
+similar congestion in the "active" queue. "Active" queue congestion is a
+greater cause for alarm; one might need to take measures to ensure that the
+mail is deferred instead or even add an access(5) rule asking the sender to try
+again later.
If a high volume destination exhibits frequent bursts of consecutive
connections refused by all MX hosts or "421 Server busy errors", it is possible
@@ -456,7 +456,7 @@ Congestion in this queue is indicative of an excessive local message submission
rate or perhaps excessive CPU consumption in the cleanup(8) service due to
excessive body_checks, or (Postfix >= 2.3) high latency milters.
-Note, that once the active queue is full, the cleanup service will attempt to
+Note, that once the "active" queue is full, the cleanup service will attempt to
slow down message injection by pausing $in_flow_delay for each message. In this
case "maildrop" queue congestion may be a consequence of congestion downstream,
rather than a problem in its own right.
@@ -504,18 +504,18 @@ and notifies the queue manager of new mail arrival. The queue manager ignores
incomplete queue files whose mode is 0600, as these are still being written by
cleanup.
-The queue manager scans the incoming queue bringing any new mail into the
-"active" queue if the active queue resource limits have not been exceeded. By
-default, the active queue accommodates at most 20000 messages. Once the active
-queue message limit is reached, the queue manager stops scanning the incoming
-(and deferred, see below) queue.
+The queue manager scans the "incoming" queue bringing any new mail into the
+"active" queue if the "active" queue resource limits have not been exceeded. By
+default, the "active" queue accommodates at most 20000 messages. Once the
+"active" queue message limit is reached, the queue manager stops scanning the
+"incoming" queue (and the "deferred" queue, see below).
-Under normal conditions the incoming queue is nearly empty (has only mode 0600
-files), with the queue manager able to import new messages into the active
-queue as soon as they become available.
+Under normal conditions the "incoming" queue is nearly empty (has only mode
+0600 files), with the queue manager able to import new messages into the
+"active" queue as soon as they become available.
-The incoming queue grows when the message input rate spikes above the rate at
-which the queue manager can import messages into the active queue. The main
+The "incoming" queue grows when the message input rate spikes above the rate at
+which the queue manager can import messages into the "active" queue. The main
factors slowing down the queue manager are disk I/O and lookup queries to the
trivial-rewrite service. If the queue manager is routinely not keeping up,
consider not using "slow" lookup services (MySQL, LDAP, ...) for transport
@@ -540,8 +540,8 @@ but is not strong enough to deflect an excessive input rate from many sources
at the same time.
If a server is being hammered from multiple directions, consider raising the
-in_flow_delay to 10 seconds, but only if the incoming queue is growing even
-while the active queue is not full and the trivial-rewrite service is using a
+in_flow_delay to 10 seconds, but only if the "incoming" queue is growing even
+while the "active" queue is not full and the trivial-rewrite service is using a
fast transport lookup mechanism.
TThhee ""aaccttiivvee"" qquueeuuee
@@ -549,8 +549,8 @@ TThhee ""aaccttiivvee"" qquueeuuee
The queue manager is a delivery agent scheduler; it works to ensure fast and
fair delivery of mail to all destinations within designated resource limits.
-The active queue is somewhat analogous to an operating system's process run
-queue. Messages in the active queue are ready to be sent (runnable), but are
+The "active" queue is somewhat analogous to an operating system's process run
+queue. Messages in the "active" queue are ready to be sent (runnable), but are
not necessarily in the process of being sent (running).
While most Postfix administrators think of the "active" queue as a directory on
@@ -562,9 +562,9 @@ below) do not occupy memory; they are safely stored on disk waiting for their
turn to be processed. The envelope information for messages in the "active"
queue is managed in memory, allowing the queue manager to do global scheduling,
allocating available delivery agent processes to an appropriate message in the
-active queue.
+"active" queue.
-Within the active queue, (multi-recipient) messages are broken up into groups
+Within the "active" queue, (multi-recipient) messages are broken up into groups
of recipients that share the same transport/nexthop combination; the group size
is capped by the transport's recipient concurrency limit.
@@ -577,14 +577,14 @@ per-recipient concurrency limits rather than per-domain concurrency limits.
Per-recipient limits are appropriate when performing final delivery to
mailboxes rather than when relaying to a remote server.
-Congestion occurs in the active queue when one or more destinations drain
+Congestion occurs in the "active" queue when one or more destinations drain
slower than the corresponding message input rate.
-Input into the active queue comes both from new mail in the "incoming" queue,
+Input into the "active" queue comes both from new mail in the "incoming" queue,
and retries of mail in the "deferred" queue. Should the "deferred" queue get
really large, retries of old mail can dominate the arrival rate of new mail.
Systems with more CPU, faster disks and more network bandwidth can deal with
-larger deferred queues, but as a rule of thumb the deferred queue scales to
+larger "deferred" queues, but as a rule of thumb the "deferred" queue scales to
somewhere between 100,000 and 1,000,000 messages with good performance unlikely
above that "limit". Systems with queues this large should typically stop
accepting new mail, or put the backlog "on hold" until the underlying issue is
@@ -592,14 +592,14 @@ fixed (provided that there is enough capacity to handle just the new mail).
When a destination is down for some time, the queue manager will mark it dead,
and immediately defer all mail for the destination without trying to assign it
-to a delivery agent. In this case the messages will quickly leave the active
-queue and end up in the deferred queue (with Postfix < 2.4, this is done
+to a delivery agent. In this case the messages will quickly leave the "active"
+queue and end up in the "deferred" queue (with Postfix < 2.4, this is done
directly by the queue manager, with Postfix >= 2.4 this is done via the "retry"
delivery agent).
When the destination is instead simply slow, or there is a problem causing an
-excessive arrival rate the active queue will grow and will become dominated by
-mail to the congested destination.
+excessive arrival rate the "active" queue will grow and will become dominated
+by mail to the congested destination.
The only way to reduce congestion is to either reduce the input rate or
increase the throughput. Increasing the throughput requires either increasing
@@ -635,7 +635,7 @@ per second.
The best way to avoid bottlenecks when one or more MX hosts is non-responsive
is to use connection caching. Connection caching was introduced with Postfix
2.2 and is by default enabled on demand for destinations with a backlog of mail
-in the active queue. When connection caching is in effect for a particular
+in the "active" queue. When connection caching is in effect for a particular
destination, established connections are re-used to send additional messages,
this reduces the number of connections made per message delivery and maintains
good throughput even in the face of partial unavailability of the destination's
@@ -664,73 +664,75 @@ a separate delivery agent pool to these destinations and allows separate tuning
of timeouts and concurrency limits.
Another common cause of congestion is unwarranted flushing of the entire
-deferred queue. The deferred queue holds messages that are likely to fail to be
-delivered and are also likely to be slow to fail delivery (time out). As a
-result the most common reaction to a large deferred queue (flush it!) is more
-than likely counter-productive, and typically makes the congestion worse. Do
-not flush the deferred queue unless you expect that most of its content has
-recently become deliverable (e.g. relayhost back up after an outage)!
+"deferred" queue. The "deferred" queue holds messages that are likely to fail
+to be delivered and are also likely to be slow to fail delivery (time out). As
+a result the most common reaction to a large "deferred" queue (flush it!) is
+more than likely counter-productive, and typically makes the congestion worse.
+Do not flush the "deferred" queue unless you expect that most of its content
+has recently become deliverable (e.g. relayhost back up after an outage)!
Note that whenever the queue manager is restarted, there may already be
-messages in the active queue directory, but the "real" active queue in memory
-is empty. In order to recover the in-memory state, the queue manager moves all
-the active queue messages back into the incoming queue, and then uses its
-normal incoming queue scan to refill the active queue. The process of moving
-all the messages back and forth, redoing transport table (trivial-rewrite(8)
-resolve service) lookups, and re-importing the messages back into memory is
-expensive. At all costs, avoid frequent restarts of the queue manager (e.g. via
-frequent execution of "postfix reload").
+messages in the "active" queue directory, but the "real" "active" queue in
+memory is empty. In order to recover the in-memory state, the queue manager
+moves all the "active" queue messages back into the "incoming" queue, and then
+uses its normal "incoming" queue scan to refill the "active" queue. The process
+of moving all the messages back and forth, redoing transport table (trivial-
+rewrite(8) resolve service) lookups, and re-importing the messages back into
+memory is expensive. At all costs, avoid frequent restarts of the queue manager
+(e.g. via frequent execution of "postfix reload").
TThhee ""ddeeffeerrrreedd"" qquueeuuee
When all the deliverable recipients for a message are delivered, and for some
recipients delivery failed for a transient reason (it might succeed later), the
-message is placed in the deferred queue.
+message is placed in the "deferred" queue.
-The queue manager scans the deferred queue periodically. The scan interval is
-controlled by the queue_run_delay parameter. While a deferred queue scan is in
-progress, if an incoming queue scan is also in progress (ideally these are
-brief since the incoming queue should be short), the queue manager alternates
+The queue manager scans the "deferred" queue periodically. The scan interval is
+controlled by the queue_run_delay parameter. While a "deferred" queue scan is
+in progress, if an "incoming" queue scan is also in progress (ideally these are
+brief since the "incoming" queue should be short), the queue manager alternates
between looking for messages in the "incoming" queue and in the "deferred"
-queue. This "round-robin" strategy prevents starvation of either the incoming
-or the deferred queues.
+queue. This "round-robin" strategy prevents starvation of either the "incoming"
+or the "deferred" queues.
-Each deferred queue scan only brings a fraction of the deferred queue back into
-the active queue for a retry. This is because each message in the deferred
-queue is assigned a "cool-off" time when it is deferred. This is done by time-
-warping the modification time of the queue file into the future. The queue file
-is not eligible for a retry if its modification time is not yet reached.
+Each "deferred" queue scan only brings a fraction of the "deferred" queue back
+into the "active" queue for a retry. This is because each message in the
+"deferred" queue is assigned a "cool-off" time when it is deferred. This is
+done by time-warping the modification time of the queue file into the future.
+The queue file is not eligible for a retry if its modification time is not yet
+reached.
The "cool-off" time is at least $minimal_backoff_time and at most
$maximal_backoff_time. The next retry time is set by doubling the message's age
in the queue, and adjusting up or down to lie within the limits. This means
that young messages are initially retried more often than old messages.
-If a high volume site routinely has large deferred queues, it may be useful to
-adjust the queue_run_delay, minimal_backoff_time and maximal_backoff_time to
+If a high volume site routinely has large "deferred" queues, it may be useful
+to adjust the queue_run_delay, minimal_backoff_time and maximal_backoff_time to
provide short enough delays on first failure (Postfix >= 2.4 has a sensibly low
minimal backoff time by default), with perhaps longer delays after multiple
failures, to reduce the retransmission rate of old messages and thereby reduce
-the quantity of previously deferred mail in the active queue. If you want a
+the quantity of previously deferred mail in the "active" queue. If you want a
really low minimal_backoff_time, you may also want to lower queue_run_delay,
but understand that more frequent scans will increase the demand for disk I/O.
-One common cause of large deferred queues is failure to validate recipients at
-the SMTP input stage. Since spammers routinely launch dictionary attacks from
-unrepliable sender addresses, the bounces for invalid recipient addresses clog
-the deferred queue (and at high volumes proportionally clog the active queue).
-Recipient validation is strongly recommended through use of the
+One common cause of large "deferred" queues is failure to validate recipients
+at the SMTP input stage. Since spammers routinely launch dictionary attacks
+from unrepliable sender addresses, the bounces for invalid recipient addresses
+clog the "deferred" queue (and at high volumes proportionally clog the "active"
+queue). Recipient validation is strongly recommended through use of the
local_recipient_maps and relay_recipient_maps parameters. Even when bounces
drain quickly they inundate innocent victims of forgery with unwanted email. To
avoid this, do not accept mail for invalid recipients.
When a host with lots of deferred mail is down for some time, it is possible
-for the entire deferred queue to reach its retry time simultaneously. This can
-lead to a very full active queue once the host comes back up. The phenomenon
-can repeat approximately every maximal_backoff_time seconds if the messages are
-again deferred after a brief burst of congestion. Perhaps, a future Postfix
-release will add a random offset to the retry time (or use a combination of
-strategies) to reduce the odds of repeated complete deferred queue flushes.
+for the entire "deferred" queue to reach its retry time simultaneously. This
+can lead to a very full "active" queue once the host comes back up. The
+phenomenon can repeat approximately every maximal_backoff_time seconds if the
+messages are again deferred after a brief burst of congestion. Perhaps, a
+future Postfix release will add a random offset to the retry time (or use a
+combination of strategies) to reduce the odds of repeated complete "deferred"
+queue flushes.
CCrreeddiittss
diff --git a/postfix/README_FILES/SASL_README b/postfix/README_FILES/SASL_README
index 0feebc7f5..94a377eab 100644
--- a/postfix/README_FILES/SASL_README
+++ b/postfix/README_FILES/SASL_README
@@ -558,8 +558,8 @@ The following is a summary of applicable smtpd.conf file entries:
Specify ldapdb to enable the plugin.
ldapdb_uri
- Specify either ldapi:// for to connect over a UNIX-domain socket, ldap:
- // for an unencrypted TCP connection or ldaps:// for an encrypted TCP
+ Specify either ldapi:// to connect over a UNIX-domain socket, ldap:/
+ / for an unencrypted TCP connection, or ldaps:// for an encrypted TCP
connection.
ldapdb_id
@@ -1134,14 +1134,14 @@ final resort.
single MySQL database, and configure different Postfix queries to extract
the appropriate information.
- * Specify dbm instead of hash if your system uses dbm files instead of db
+ * Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
files. To find out what lookup tables Postfix supports, use the command
- "postconf -m".
+ "ppoossttccoonnff --mm".
- * Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change
+ * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change
the sasl_passwd table.
- * Execute the command "postmap /etc/postfix/sender_relay" whenever you change
+ * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//sseennddeerr__rreellaayy" whenever you change
the sender_relay table.
PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm pprrooppeerrttiieess
@@ -1296,7 +1296,7 @@ NNoottee
Postfix configuration a little more convenient because you don't have to
specify the SASL plug-in type in the Postfix main.cf file (but this may
cause surprises when you switch to a later Postfix version that is built
- with the default SASL type of sasl).
+ with the default SASL type of cyrus).
* If you also want support for LDAP or TLS (or for Cyrus SASL), you need to
merge their CCARGS and AUXLIBS options into the above command line; see the
diff --git a/postfix/README_FILES/SCHEDULER_README b/postfix/README_FILES/SCHEDULER_README
index a6f7702ff..448ee0a79 100644
--- a/postfix/README_FILES/SCHEDULER_README
+++ b/postfix/README_FILES/SCHEDULER_README
@@ -496,7 +496,7 @@ This document is divided into sections as follows:
TThhee ssttrruuccttuurreess uusseedd bbyy nnqqmmggrr
Let's start by recapitulating the structures and terms used when referring to
-queue manager and how it operates. Many of these are partially described
+the queue manager and how it operates. Many of these are partially described
elsewhere, but it is nice to have a coherent overview in one place:
* Each message structure represents one mail message which Postfix is to
@@ -512,8 +512,8 @@ elsewhere, but it is nice to have a coherent overview in one place:
set of queues (describing the destinations it shall talk to) and jobs
(referencing the messages it shall deliver).
- * Each transport queue (not to be confused with the on-disk active queue or
- incoming queue) groups everything what is going be delivered to given
+ * Each transport queue (not to be confused with the on-disk "active" queue or
+ "incoming" queue) groups everything what is going be delivered to given
destination (aka nexthop) by its transport. Each queue belongs to one
transport, so each destination may be referred to by several queues, one
for each transport. Each queue maintains a list of all recipient entries
@@ -547,17 +547,17 @@ description above anytime you'll feel you have lost a sense what is what.
WWhhaatt hhaappppeennss wwhheenn nnqqmmggrr ppiicckkss uupp tthhee mmeessssaaggee
-Whenever nqmgr moves a queue file into the active queue, the following happens:
-It reads all necessary information from the queue file as oqmgr does, and also
-reads as many recipients as possible - more on that later, for now let's just
-pretend it always reads all recipients.
+Whenever nqmgr moves a queue file into the "active" queue, the following
+happens: It reads all necessary information from the queue file as oqmgr does,
+and also reads as many recipients as possible - more on that later, for now
+let's just pretend it always reads all recipients.
Then it resolves the recipients as oqmgr does, which means obtaining (address,
nexthop, transport) triple for each recipient. For each triple, it finds the
transport; if it does not exist yet, it instantiates it (unless it's dead).
-Within the transport, it finds the destination queue for given nexthop; if it
-does not exist yet, it instantiates it (unless it's dead). The triple is then
-bound to given destination queue. This happens in qmgr_resolve() and is
+Within the transport, it finds the destination queue for the given nexthop; if
+it does not exist yet, it instantiates it (unless it's dead). The triple is
+then bound to given destination queue. This happens in qmgr_resolve() and is
basically the same as in oqmgr.
Then for each triple which was bound to some queue (and thus transport), the
@@ -566,19 +566,19 @@ context; if it does not exist yet, it instantiates it. Within the job, it finds
the peer which represents the bound destination queue within this jobs context;
if it does not exist yet, it instantiates it. Finally, it stores the address
from the resolved triple to the recipient entry which is appended to both the
-queue entry list and the peer entry list. The addresses for same nexthop are
-batched in the entries up to recipient_concurrency limit for that transport.
-This happens in qmgr_assign() and apart from that it operates with job and peer
-structures it is basically the same as in oqmgr.
+queue entry list and the peer entry list. The addresses for the same nexthop
+are batched in the entries up to the transport_destination_recipient_limit for
+that transport. This happens in qmgr_message_assign(), and apart from that it
+operates with job and peer structures, it is basically the same as in oqmgr.
When the job is instantiated, it is enqueued on the transport's job list based
on the time its message was picked up by nqmgr. For first batch of recipients
this means it is appended to the end of the job list, but the ordering of the
job list by the enqueue time is important as we will see shortly.
-[Now you should have pretty good idea what is the state of the nqmgr after
-couple of messages was picked up, what is the relation between all those job,
-peer, queue and entry structures.]
+[Now you should have a pretty good idea what the state of the nqmgr is after a
+couple of messages were picked up, and what the relation is between all those
+job, peer, queue and entry structures.]
HHooww tthhee eennttrryy sseelleeccttiioonn wwoorrkkss
@@ -606,9 +606,9 @@ job list is by default kept in the order the message was picked up by the
nqmgr. So by default we get the top-level round-robin transport, and within
each transport we get the FIFO message delivery. The round-robin of the peers
by the destination is perhaps of little importance in most real-life cases
-(unless the recipient_concurrency limit is reached, in one job there is only
-one peer structure for each destination), but theoretically it makes sure that
-even within single jobs, destinations are treated fairly.
+(unless the transport_destination_recipient_limit is reached, in one job there
+is only one peer structure for each destination), but theoretically it makes
+sure that even within single jobs, destinations are treated fairly.
[By now you should have a feeling you really know how the scheduler works,
except for the preemption, under ideal conditions - that is, no recipient
@@ -661,14 +661,14 @@ with more than one recipient? Say if we have one four-recipient mail followed
by two two-recipient mails?
The simple answer would be to use delivery sequence 12121313. But the problem
-is that this does not scale well. Imagine you have mail with thousand
-recipients followed by mail with hundred recipients. It is tempting to suggest
-the delivery sequence like 121212...., but alas! Imagine there arrives another
-mail with say ten recipients. But there are no free slots anymore, so it can't
-slip by, not even if it had just only one recipients. It will be stuck until
+is that this does not scale well. Imagine you have mail with a thousand
+recipients followed by mail with a hundred recipients. It is tempting to
+suggest the delivery sequence like 121212...., but alas! Imagine there arrives
+another mail with say ten recipients. But there are no free slots anymore, so
+it can't slip by, not even if it had only one recipient. It will be stuck until
the hundred-recipient mail is delivered, which really sucks.
-So, it becomes obvious that while inflating the message to get free slots is
+So, it becomes obvious that while inflating the message to get free slots is a
great idea, one has to be really careful of how the free slots are assigned,
otherwise one might corner himself. So, how does nqmgr really use the free
slots?
@@ -689,30 +689,30 @@ slots, and then we could preempt it and sneak in the ten-recipient mail... Wait
wait wait! Could we? Aren't we overinflating the original one thousand
recipient mail?
-Well, despite it looks so at the first glance, another trick will allow us to
-answer "no, we are not!". If we had said that we will inflate the delivery time
-twice at maximum, and then we consider every other slot as a free slot, then we
-would overinflate in case of the recursive preemption. BUT! The trick is that
-if we use only every n-th slot as a free slot for n>2, there is always some
-worst inflation factor which we can guarantee not to be breached, even if we
-apply the algorithm recursively. To be precise, if for every k>1 normally used
-slots we accumulate one free delivery slot, than the inflation factor is not
-worse than k/(k-1) no matter how many recursive preemptions happen. And it's
-not worse than (k+1)/k if only non-recursive preemption happens. Now, having
-got through the theory and the related math, let's see how nqmgr implements
-this.
+Well, despite the fact that it looks so at the first glance, another trick will
+allow us to answer "no, we are not!". If we had said that we will inflate the
+delivery time twice at maximum, and then we consider every other slot as a free
+slot, then we would overinflate in case of the recursive preemption. BUT! The
+trick is that if we use only every n-th slot as a free slot for n>2, there is
+always some worst inflation factor which we can guarantee not to be breached,
+even if we apply the algorithm recursively. To be precise, if for every k>1
+normally used slots we accumulate one free delivery slot, than the inflation
+factor is not worse than k/(k-1) no matter how many recursive preemptions
+happen. And it's not worse than (k+1)/k if only non-recursive preemption
+happens. Now, having got through the theory and the related math, let's see how
+nqmgr implements this.
Each job has so called "available delivery slot" counter. Each transport has a
transport_delivery_slot_cost parameter, which defaults to
default_delivery_slot_cost parameter which is set to 5 by default. This is the
k from the paragraph above. Each time k entries of the job are selected for
delivery, this counter is incremented by one. Once there are some slots
-accumulated, job which requires no more than that number of slots to be fully
+accumulated, a job which requires no more than that number of slots to be fully
delivered can preempt this job.
[Well, the truth is, the counter is incremented every time an entry is selected
-and it is divided by k when it is used. But for the understanding it's good
-enough to use the above approximation of the truth.]
+and it is divided by k when it is used. But to understand, it's good enough to
+use the above approximation of the truth.]
OK, so now we know the conditions which must be satisfied so one job can
preempt another one. But what job gets preempted, how do we choose what job
@@ -720,11 +720,11 @@ preempts it if there are several valid candidates, and when does all this
exactly happen?
The answer for the first part is simple. The job whose entry was selected the
-last time is so called current job. Normally, it is the first job on the
+last time is the so called current job. Normally, it is the first job on the
scheduler's job list, but destination concurrency limits may change this as we
will see later. It is always only the current job which may get preempted.
-Now for the second part. The current job has certain amount of recipient
+Now for the second part. The current job has a certain amount of recipient
entries, and as such may accumulate at maximum some amount of available
delivery slots. It might have already accumulated some, and perhaps even
already used some when it was preempted before (remember a job can be preempted
@@ -737,22 +737,22 @@ The answer is - the one with maximum enqueue_time/recipient_entry_count. That
is, the older the job is, the more we should try to deliver it in order to get
best message delivery rates. These rates are of course subject to how many
recipients the message has, therefore the division by the recipient (entry)
-count. No one shall be surprised that message with n recipients takes n times
-longer to deliver than message with one recipient.
+count. No one shall be surprised that a message with n recipients takes n times
+longer to deliver than a message with one recipient.
Now let's recap the previous two paragraphs. Isn't it too complicated? Why
don't the candidates come only among the jobs which can be delivered within the
number of slots the current job already accumulated? Why do we need to estimate
how much it has yet to accumulate? If you found out the answer, congratulate
yourself. If we did it this simple way, we would always choose the candidate
-with least recipient entries. If there were enough single recipient mails
+with the fewest recipient entries. If there were enough single recipient mails
coming in, they would always slip by the bulk mail as soon as possible, and the
-two and more recipients mail would never get a chance, no matter how long they
+two or more recipients mail would never get a chance, no matter how long they
have been sitting around in the job list.
-This candidate selection has interesting implication - that when we choose the
-best candidate for preemption (this is done in qmgr_choose_candidate()), it may
-happen that we may not use it for preemption immediately. This leads to an
+This candidate selection has an interesting implication - that when we choose
+the best candidate for preemption (this is done in qmgr_choose_candidate()), it
+may happen that we may not use it for preemption immediately. This leads to an
answer to the last part of the original question - when does the preemption
happen?
@@ -760,23 +760,23 @@ The preemption attempt happens every time next transport's recipient entry is
to be chosen for delivery. To avoid needless overhead, the preemption is not
attempted if the current job could never accumulate more than
transport_minimum_delivery_slots (defaults to default_minimum_delivery_slots
-which defaults to 3). If there is already enough accumulated slots to preempt
+which defaults to 3). If there are already enough accumulated slots to preempt
the current job by the chosen best candidate, it is done immediately. This
basically means that the candidate is moved in front of the current job on the
scheduler's job list and decreasing the accumulated slot counter by the amount
-used by the candidate. If there is not enough slots... well, I could say that
+used by the candidate. If there are not enough slots... well, I could say that
nothing happens and the another preemption is attempted the next time. But
that's not the complete truth.
The truth is that it turns out that it is not really necessary to wait until
the jobs counter accumulates all the delivery slots in advance. Say we have
ten-recipient mail followed by two two-recipient mails. If the preemption
-happened when enough delivery slot accumulate (assuming slot cost 2), the
+happened when enough delivery slots accumulate (assuming slot cost 2), the
delivery sequence becomes 11112211113311. Now what would we get if we would
wait only for 50% of the necessary slots to accumulate and we promise we would
wait for the remaining 50% later, after we get back to the preempted job? If we
-use such slot loan, the delivery sequence becomes 11221111331111. As we can
-see, it makes it no considerably worse for the delivery of the ten-recipient
+use such a slot loan, the delivery sequence becomes 11221111331111. As we can
+see, it makes it not considerably worse for the delivery of the ten-recipient
mail, but it allows the small messages to be delivered sooner.
The concept of these slot loans is where the transport_delivery_slot_discount
@@ -787,11 +787,11 @@ many percent (resp. how many slots) one "gets in advance", when the number of
slots required to deliver the best candidate is compared with the number of
slots the current slot had accumulated so far.
-And it pretty much concludes this chapter.
+And that pretty much concludes this chapter.
[Now you should have a feeling that you pretty much understand the scheduler
-and the preemption, or at least that you will have it after you read the last
-chapter couple more times. You shall clearly see the job list and the
+and the preemption, or at least that you will have after you read the last
+chapter a couple more times. You shall clearly see the job list and the
preemption happening at its head, in ideal delivery conditions. The feeling of
understanding shall last until you start wondering what happens if some of the
jobs are blocked, which you might eventually figure out correctly from what had
@@ -805,17 +805,18 @@ The nqmgr uses the same algorithm for destination concurrency control as oqmgr.
Now what happens when the destination limits are reached and no more entries
for that destination may be selected by the scheduler?
-From user's point of view it is all simple. If some of the peers of a job can't
-be selected, those peers are simply skipped by the entry selection algorithm
-(the pseudo-code described before) and only the selectable ones are used. If
-none of the peers may be selected, the job is declared a "blocker job". Blocker
-jobs are skipped by the entry selection algorithm and they are also excluded
-from the candidates for preemption of current job. Thus the scheduler
-effectively behaves as if the blocker jobs didn't exist on the job list at all.
-As soon as at least one of the peers of a blocker job becomes unblocked (that
-is, the delivery agent handling the delivery of the recipient entry for given
-destination successfully finishes), the job's blocker status is removed and the
-job again participates in all further scheduler actions normally.
+From the user's point of view it is all simple. If some of the peers of a job
+can't be selected, those peers are simply skipped by the entry selection
+algorithm (the pseudo-code described before) and only the selectable ones are
+used. If none of the peers may be selected, the job is declared a "blocker
+job". Blocker jobs are skipped by the entry selection algorithm and they are
+also excluded from the candidates for preemption of the current job. Thus the
+scheduler effectively behaves as if the blocker jobs didn't exist on the job
+list at all. As soon as at least one of the peers of a blocker job becomes
+unblocked (that is, the delivery agent handling the delivery of the recipient
+entry for the given destination successfully finishes), the job's blocker
+status is removed and the job again participates in all further scheduler
+actions normally.
So the summary is that the users don't really have to be concerned about the
interaction of the destination limits and scheduling algorithm. It works well
@@ -844,8 +845,8 @@ are selected, and once they are all selected, job 1 continues.
As we see, it's all very clean and straightforward. Now how does this change
because of blockers?
-The answer is: a lot. Any job may become blocker job at any time, and also
-become normal job again at any time. This has several important implications:
+The answer is: a lot. Any job may become a blocker job at any time, and also
+become a normal job again at any time. This has several important implications:
1. The jobs may be completed in arbitrary order. For example, in the example
above, if the current job 7 becomes blocked, the next job 4 may complete
@@ -854,7 +855,7 @@ become normal job again at any time. This has several important implications:
completed and only after that 4 becomes unblocked and is completed... You
get the idea.
- [Interesting side note: even when jobs are delivered out of order, from
+ [Interesting side note: even when jobs are delivered out of order, from a
single destination's point of view the jobs are still delivered in the
expected order (that is, FIFO unless there was some preemption involved).
This is because whenever a destination queue becomes unblocked (the
@@ -885,7 +886,7 @@ the point 3) example: jobs 7 and 8 preempt job 4, now job 8 becomes blocked
too, then job 4 completes. Tricky, huh?
If I illustrate the relations after the above mentioned examples (but those in
-point 1)), the situation would look like this:
+point 1), the situation would look like this:
v- parent
@@ -900,11 +901,11 @@ point 1)), the situation would look like this:
Now how does nqmgr deal with all these complicated relations?
Well, it maintains them all as described, but fortunately, all these relations
-are necessary only for purposes of proper counting of available delivery slots.
-For purposes of ordering the jobs for entry selection, the original rule still
-applies: "the job preempting the current job is moved in front of the current
-job on the job list". So for entry selection purposes, the job relations remain
-as simple as this:
+are necessary only for the purpose of proper counting of available delivery
+slots. For the purpose of ordering the jobs for entry selection, the original
+rule still applies: "the job preempting the current job is moved in front of
+the current job on the job list". So for entry selection purposes, the job
+relations remain as simple as this:
7--8--1--2--6--3--5--.. <- scheduler's job list order
@@ -916,8 +917,8 @@ introduction to the problem domain. Otherwise I suggest you just forget about
all this and stick with the user's point of view: the blocker jobs are simply
ignored.
-[By now, you should have a feeling that there is more things going under the
-hood than you ever wanted to know. You decide that forgetting about this
+[By now, you should have a feeling that there are more things going on under
+the hood than you ever wanted to know. You decide that forgetting about this
chapter is the best you can do for the sake of your mind's health and you
basically stick with the idea how the scheduler works in ideal conditions, when
there are no blockers, which is good enough.]
@@ -925,25 +926,25 @@ there are no blockers, which is good enough.]
DDeeaalliinngg wwiitthh mmeemmoorryy rreessoouurrccee lliimmiittss
When discussing the nqmgr scheduler, we have so far assumed that all recipients
-of all messages in the active queue are completely read into the memory. This
-is simply not true. There is an upper bound on the amount of memory the nqmgr
-may use, and therefore it must impose some limits on the information it may
-store in the memory at any given time.
+of all messages in the "active" queue are completely read into memory. This is
+simply not true. There is an upper bound on the amount of memory the nqmgr may
+use, and therefore it must impose some limits on the information it may store
+in memory at any given time.
First of all, not all messages may be read in-core at once. At any time, only
qmgr_message_active_limit messages may be read in-core at maximum. When read
-into memory, the messages are picked from the incoming and deferred message
-queues and moved to the active queue (incoming having priority), so if there is
-more than qmgr_message_active_limit messages queued in the active queue, the
-rest will have to wait until (some of) the messages in the active queue are
+into memory, the messages are picked from the "incoming" and "deferred" queues
+and moved to the "active" queue (incoming having priority), so if there are
+more than qmgr_message_active_limit messages queued in the "active" queue, the
+rest will have to wait until (some of) the messages in the "active" queue are
completely delivered (or deferred).
Even with the limited amount of in-core messages, there is another limit which
-must be imposed in order to avoid memory exhaustion. Each message may contain
-huge amount of recipients (tens or hundreds of thousands are not uncommon), so
-if nqmgr read all recipients of all messages in the active queue, it may easily
-run out of memory. Therefore there must be some upper bound on the amount of
-message recipients which are read into the memory at the same time.
+must be imposed in order to avoid memory exhaustion. Each message may contain a
+huge number of recipients (tens or hundreds of thousands are not uncommon), so
+if nqmgr read all recipients of all messages in the "active" queue, it may
+easily run out of memory. Therefore there must be some upper bound on the
+amount of message recipients which are read into memory at the same time.
Before discussing how exactly nqmgr implements the recipient limits, let's see
how the sole existence of the limits themselves affects the nqmgr and its
@@ -951,7 +952,7 @@ scheduler.
The message limit is straightforward - it just limits the size of the lookahead
the nqmgr's scheduler has when choosing which message can preempt the current
-one. Messages not in the active queue simply are not considered at all.
+one. Messages not in the "active" queue are simply not considered at all.
The recipient limit complicates more things. First of all, the message reading
code must support reading the recipients in batches, which among other things
@@ -967,14 +968,14 @@ file, the scheduler can't operate with exact counts of recipient entries. With
unread recipients, it is not clear how many recipient entries there will be, as
they are subject to per-destination grouping. It is not even clear to what
transports (and thus jobs) the recipients will be assigned. And with messages
-coming from the deferred queue, it is not even clear how many unread recipients
-are still to be delivered. This all means that the scheduler must use only
-estimates of how many recipients entries there will be. Fortunately, it is
-possible to estimate the minimum and maximum correctly, so the scheduler can
-always err on the safe side. Obviously, the better the estimates, the better
-results, so it is best when we are able to read all recipients in-core and turn
-the estimates into exact counts, or at least try to read as many as possible to
-make the estimates as accurate as possible.
+coming from the "deferred" queue, it is not even clear how many unread
+recipients are still to be delivered. This all means that the scheduler must
+use only estimates of how many recipients entries there will be. Fortunately,
+it is possible to estimate the minimum and maximum correctly, so the scheduler
+can always err on the safe side. Obviously, the better the estimates, the
+better the results, so it is best when we are able to read all recipients in-
+core and turn the estimates into exact counts, or at least try to read as many
+as possible to make the estimates as accurate as possible.
The third complication is that it is no longer true that the scheduler is done
with a job once all of its in-core recipients are delivered. It is possible
@@ -987,9 +988,9 @@ And finally, the fourth complication is that the nqmgr code must somehow impose
the recipient limit itself. Now how does it achieve it?
Perhaps the easiest solution would be to say that each message may have at
-maximum X recipients stored in-core, but such solution would be poor for
+maximum X recipients stored in-core, but such a solution would be poor for
several reasons. With reasonable qmgr_message_active_limit values, the X would
-have to be quite low to maintain reasonable memory footprint. And with low X
+have to be quite low to maintain a reasonable memory footprint. And with low X
lots of things would not work well. The nqmgr would have problems to use the
transport_destination_recipient_limit efficiently. The scheduler's preemption
would be suboptimal as the recipient count estimates would be inaccurate. The
@@ -997,28 +998,28 @@ message queue file would have to be accessed many times to read in more
recipients again and again.
Therefore it seems reasonable to have a solution which does not use a limit
-imposed on per-message basis, but which maintains a pool of available recipient
-slots, which can be shared among all messages in the most efficient manner. And
-as we do not want separate transports to compete for resources whenever
-possible, it seems appropriate to maintain such recipient pool for each
-transport separately. This is the general idea, now how does it work in
+imposed on a per-message basis, but which maintains a pool of available
+recipient slots, which can be shared among all messages in the most efficient
+manner. And as we do not want separate transports to compete for resources
+whenever possible, it seems appropriate to maintain such a recipient pool for
+each transport separately. This is the general idea, now how does it work in
practice?
-First we have to solve little chicken-and-egg problem. If we want to use the
-per-transport recipient pools, we first need to know to what transport(s) is
-the message assigned. But we will find that out only after we read in the
-recipients first. So it is obvious that we first have to read in some
-recipients, use them to find out to what transports is the message to be
-assigned, and only after that we can use the per-transport recipient pools.
+First we have to solve a little chicken-and-egg problem. If we want to use the
+per-transport recipient pools, we first need to know to what transport(s) the
+message is assigned. But we will find that out only after we first read in the
+recipients. So it is obvious that we first have to read in some recipients, use
+them to find out to what transports the message is to be assigned, and only
+after that can we use the per-transport recipient pools.
Now how many recipients shall we read for the first time? This is what
qmgr_message_recipient_minimum and qmgr_message_recipient_limit values control.
The qmgr_message_recipient_minimum value specifies how many recipients of each
-message we will read for the first time, no matter what. It is necessary to
-read at least one recipient before we can assign the message to a transport and
-create the first job. However, reading only qmgr_message_recipient_minimum
-recipients even if there are only few messages with few recipients in-core
-would be wasteful. Therefore if there is less than qmgr_message_recipient_limit
+message we will read the first time, no matter what. It is necessary to read at
+least one recipient before we can assign the message to a transport and create
+the first job. However, reading only qmgr_message_recipient_minimum recipients
+even if there are only few messages with few recipients in-core would be
+wasteful. Therefore if there are fewer than qmgr_message_recipient_limit
recipients in-core so far, the first batch of recipients may be larger than
qmgr_message_recipient_minimum - as large as is required to reach the
qmgr_message_recipient_limit limit.
@@ -1033,12 +1034,12 @@ recipient batch may be as large as the sum of all recipient slots of all jobs
of the message permits (plus the qmgr_message_recipient_minimum amount which
always applies).
-For example, if a message has three jobs, first with 1 recipient still in-core
-and 4 recipient slots, second with 5 recipient in-core and 5 recipient slots,
-and third with 2 recipients in-core and 0 recipient slots, it has 1+5+2=7
-recipients in-core and 4+5+0=9 jobs' recipients slots in total. This means that
-we could immediately read 2+qmgr_message_recipient_minimum more recipients of
-that message in core.
+For example, if a message has three jobs, the first with 1 recipient still in-
+core and 4 recipient slots, the second with 5 recipients in-core and 5
+recipient slots, and the third with 2 recipients in-core and 0 recipient slots,
+it has 1+5+2=8 recipients in-core and 4+5+0=9 jobs' recipients slots in total.
+This means that we could immediately read 2+qmgr_message_recipient_minimum more
+recipients of that message in core.
The above example illustrates several things which might be worth mentioning
explicitly: first, note that although the per-transport slots are assigned to
@@ -1067,17 +1068,17 @@ job list does.
More specifically, each time a job is created and appended to the job list, it
gets all unused recipient slots from its transport's pool. It keeps them until
all recipients of its message are read. When this happens, all unused recipient
-slots are transferred to the next job (which is now in fact now first such job)
+slots are transferred to the next job (which is now in fact the first such job)
on the job list which still has some recipients unread, or eventually back to
-the transport pool if there is no such job. Such transfer then also happens
+the transport pool if there is no such job. Such a transfer then also happens
whenever a recipient entry of that job is delivered.
There is also a scenario when a job is not appended to the end of the job list
-(for example it was created as a result of second or later recipient batch).
+(for example it was created as a result of a second or later recipient batch).
Then it works exactly as above, except that if it was put in front of the first
unread job (that is, the job of a message which still has some unread
-recipients in queue file), that job is first forced to return all of its unused
-recipient slots to the transport pool.
+recipients in the queue file), that job is first forced to return all of its
+unused recipient slots to the transport pool.
The algorithm just described leads to the following state: The first unread job
on the job list always gets all the remaining recipient slots of that transport
@@ -1087,22 +1088,22 @@ maximum as many slots as they still have recipients in-core (the maximum is
there because of the sponsoring mentioned before) and the jobs after this job
get nothing from the transport recipient pool (unless they got something before
and then the first unread job was created and enqueued in front of them later -
-in such case the also get at maximum as many slots as they have recipients in-
-core).
-
-Things work fine in such state for most of the time, because the current job is
-either completely read in-core or has as much recipient slots as there are, but
-there is one situation which we still have to take care of specially. Imagine
-if the current job is preempted by some unread job from the job list and there
-are no more recipient slots available, so this new current job could read only
-batches of qmgr_message_recipient_minimum recipients at a time. This would
-really degrade performance. For this reason, each transport has extra pool of
-transport_extra_recipient_limit recipient slots, dedicated exactly for this
-situation. Each time an unread job preempts the current job, it gets half of
-the remaining recipient slots from the normal pool and this extra pool.
+in such a case, they also get at maximum as many slots as they have recipients
+in-core).
+
+Things work fine in such a state for most of the time, because the current job
+is either completely read in-core or has as many recipient slots as there are,
+but there is one situation which we still have to take care of specially.
+Imagine if the current job is preempted by some unread job from the job list
+and there are no more recipient slots available, so this new current job could
+read only batches of qmgr_message_recipient_minimum recipients at a time. This
+would really degrade performance. For this reason, each transport has an extra
+pool of transport_extra_recipient_limit recipient slots, dedicated exactly for
+this situation. Each time an unread job preempts the current job, it gets half
+of the remaining recipient slots from the normal pool and this extra pool.
And that's it. It sure does sound pretty complicated, but fortunately most
-people don't really have to care how exactly it works as long as it works.
+people don't really have to care exactly how it works as long as it works.
Perhaps the only important things to know for most people are the following
upper bound formulas:
@@ -1126,14 +1127,14 @@ The total amount of recipients in core is
where the sum is over all used transports.
-And this terribly complicated chapter concludes the documentation of nqmgr
+And this terribly complicated chapter concludes the documentation of the nqmgr
scheduler.
[By now you should theoretically know the nqmgr scheduler inside out. In
practice, you still hope that you will never have to really understand the last
or last two chapters completely, and fortunately most people really won't.
Understanding how the scheduler works in ideal conditions is more than good
-enough for vast majority of users.]
+enough for the vast majority of users.]
CCrreeddiittss
diff --git a/postfix/README_FILES/SMTPD_ACCESS_README b/postfix/README_FILES/SMTPD_ACCESS_README
index a4d7c208a..7477a3685 100644
--- a/postfix/README_FILES/SMTPD_ACCESS_README
+++ b/postfix/README_FILES/SMTPD_ACCESS_README
@@ -160,8 +160,9 @@ Each restriction list is evaluated from left to right until some restriction
produces a result of PERMIT, REJECT or DEFER (try again later). The end of each
list is equivalent to a PERMIT result. By placing a PERMIT restriction before a
REJECT restriction you can make exceptions for specific clients or users. This
-is called allowlisting; the fourth example above allows mail from local
-networks but otherwise rejects mail to arbitrary destinations.
+is called allowlisting; the smtpd_relay_restrictions example above allows mail
+from local networks, and from SASL authenticated clients, but otherwise rejects
+mail to arbitrary destinations.
The table below summarizes the purpose of each SMTP access restriction list.
All lists use the exact same syntax; they differ only in the time of evaluation
diff --git a/postfix/README_FILES/SMTPD_POLICY_README b/postfix/README_FILES/SMTPD_POLICY_README
index 6386b0ec5..291fa5c87 100644
--- a/postfix/README_FILES/SMTPD_POLICY_README
+++ b/postfix/README_FILES/SMTPD_POLICY_README
@@ -201,7 +201,7 @@ The first example specifies that the policy server listens on a TCP socket at
127.0.0.1 port 9998. The second example specifies an absolute pathname of a
UNIX-domain socket. The third example specifies a pathname relative to the
Postfix queue directory; use this for policy servers that are spawned by the
-Postfix master daemon.
+Postfix master daemon. On many systems, "local" is a synonym for "unix".
To create a policy service that listens on a UNIX-domain socket called
"policy", and that runs under control of the Postfix spawn(8) daemon, you would
@@ -240,7 +240,7 @@ NOTES:
* Line 11: this increases the time that a policy server process may run to
3600 seconds. The default time limit of 1000 seconds is too short; the
- policy daemon needs to run long as the SMTP server process that talks to
+ policy daemon needs to run as long as the SMTP server process that talks to
it. See the spawn(8) manpage for more information about the
transport_time_limit parameter.
@@ -432,8 +432,8 @@ Notes:
* Line 6: this increases the time that a greylist server process may run to
3600 seconds. The default time limit of 1000 seconds is too short; the
- greylist daemon needs to run long as the SMTP server process that talks to
- it. See the spawn(8) manpage for more information about the
+ greylist daemon needs to run as long as the SMTP server process that talks
+ to it. See the spawn(8) manpage for more information about the
transport_time_limit parameter.
* Line 9: reject_unauth_destination is not needed here if the mail relay
@@ -470,8 +470,9 @@ GGrreeyylliissttiinngg mmaaiill ffrroomm ffrreeqquueen
It is relatively safe to turn on greylisting for specific domains that often
appear in forged email. At some point in cyberspace/time a list of frequently
-forged MAIL FROM domains could be found at http://www.monkeys.com/anti-spam/
-filtering/sender-domain-validate.in.
+forged MAIL FROM domains could be found at https://web.archive.org/web/
+20080526153208/http://www.monkeys.com/anti-spam/filtering/sender-domain-
+validate.in.
1 /etc/postfix/main.cf:
2 smtpd_recipient_restrictions =
diff --git a/postfix/README_FILES/SMTPD_PROXY_README b/postfix/README_FILES/SMTPD_PROXY_README
index f2cd530d4..a3707ea4c 100644
--- a/postfix/README_FILES/SMTPD_PROXY_README
+++ b/postfix/README_FILES/SMTPD_PROXY_README
@@ -102,8 +102,9 @@ From then on mail is processed as usual.
The content filter itself is not described here. You can use any filter that is
SMTP enabled. For non-SMTP capable content filtering software, Bennett Todd's
-SMTP proxy implements a nice Perl-based framework. See: http://
-bent.latency.net/smtpprox/ or https://github.com/jnorell/smtpprox.
+SMTP proxy implements a nice Perl-based framework. See: https://
+web.archive.org/web/20151022025756/http://bent.latency.net/smtpprox/ or https:/
+/github.com/jnorell/smtpprox/
Postfix
Postfix filter on SMTP server Postfix Postfix
@@ -197,9 +198,9 @@ The after-filter SMTP server is a new master.cf entry:
By default, the filter has 100 seconds to do its work. If it takes longer then
Postfix gives up and reports an error to the remote SMTP client. You can
-increase this time limit (see configuration parameter section below) but doing
-so is pointless because you can't control when the remote SMTP client times
-out.
+increase this time limit (see the "Configuration parameters" section below) but
+doing so is pointless because you can't control when the remote SMTP client
+times out.
CCoonnffiigguurraattiioonn ppaarraammeetteerrss
diff --git a/postfix/README_FILES/SMTPUTF8_README b/postfix/README_FILES/SMTPUTF8_README
index 5496a3b0d..9e7970e72 100644
--- a/postfix/README_FILES/SMTPUTF8_README
+++ b/postfix/README_FILES/SMTPUTF8_README
@@ -173,7 +173,7 @@ This section applies only to systems that have SMTPUTF8 support turned on
For compatibility with pre-SMTPUTF8 environments, Postfix does not
automatically set the "SMTPUTF8 requested" flag on messages from non-SMTPUTF8
-clients that contain an UTF-8 header value or UTF-8 address localpart. This
+clients that contain a UTF-8 header value or UTF-8 address localpart. This
would make such messages undeliverable to non-SMTPUTF8 servers, and could be a
barrier to SMTPUTF8 adoption.
diff --git a/postfix/README_FILES/SOHO_README b/postfix/README_FILES/SOHO_README
index 3804b9da2..bbba7c210 100644
--- a/postfix/README_FILES/SOHO_README
+++ b/postfix/README_FILES/SOHO_README
@@ -73,8 +73,8 @@ addresses by valid Internet addresses. This mapping happens ONLY when mail
leaves the machine; not when you send mail between users on the same machine.
The following example presents additional configuration. You need to combine
-this with basic configuration information as discussed the first half of this
-document.
+this with basic configuration information as discussed in the first half of
+this document.
1 /etc/postfix/main.cf:
2 smtp_generic_maps = hash:/etc/postfix/generic
@@ -109,8 +109,8 @@ fantasy addresses, including mail to local fantasy addresses that don't have a
valid Internet address of their own.
The following example presents additional configuration. You need to combine
-this with basic configuration information as discussed the first half of this
-document.
+this with basic configuration information as discussed in the first half of
+this document.
1 /etc/postfix/main.cf:
2 myhostname = hostname.localdomain
@@ -276,13 +276,13 @@ final resort.
single MySQL database, and configure different Postfix queries to extract
the appropriate information.
- * Specify dbm instead of hash if your system uses dbm files instead of db
+ * Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
files. To find out what lookup tables Postfix supports, use the command
- "postconf -m".
+ "ppoossttccoonnff --mm".
- * Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change
+ * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change
the sasl_passwd table.
- * Execute the command "postmap /etc/postfix/sender_relay" whenever you change
+ * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//sseennddeerr__rreellaayy" whenever you change
the sender_relay table.
diff --git a/postfix/README_FILES/SQLITE_README b/postfix/README_FILES/SQLITE_README
index 3fb9757c5..7f668dea4 100644
--- a/postfix/README_FILES/SQLITE_README
+++ b/postfix/README_FILES/SQLITE_README
@@ -65,12 +65,6 @@ dbpath = /some/path/to/sqlite_database
# See sqlite_table(5) for details.
query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
-AAddddiittiioonnaall nnootteess
-
-The SQLite configuration interface setup allows for multiple sqlite databases:
-you can use one for a virtual table, one for an access table, and one for an
-aliases table if you want.
-
CCrreeddiittss
SQLite support was added with Postfix version 2.8.
diff --git a/postfix/README_FILES/STANDARD_CONFIGURATION_README b/postfix/README_FILES/STANDARD_CONFIGURATION_README
index ceb18fce8..ca188fe2b 100644
--- a/postfix/README_FILES/STANDARD_CONFIGURATION_README
+++ b/postfix/README_FILES/STANDARD_CONFIGURATION_README
@@ -113,7 +113,7 @@ As usual, the examples show only parameters that are not left at their default
settings.
First we present the non-mailhost configuration, because it is the simpler one.
-This machine sends mail as "user@example.com" and is final destination for
+This machine sends mail as "user@example.com" and is the final destination for
"user@hostname.example.com".
1 /etc/postfix/main.cf:
@@ -135,8 +135,8 @@ Translation:
below, "Postfix behind a firewall".
Next we present the mailhost configuration. This machine sends mail as
-"user@example.com" and is final destination for "user@hostname.example.com" as
-well as "user@example.com".
+"user@example.com" and is the final destination for "user@hostname.example.com"
+as well as "user@example.com".
1 DNS:
2 example.com IN MX 10 mailhost.example.com.
@@ -238,7 +238,7 @@ Translation:
literals matching $inet_interfaces or $proxy_interfaces are deemed local.
So "localpart@[a.d.d.r]" can be matched as simply "localpart" in canonical
(5) and virtual(5). This avoids the need to specify firewall IP addresses
- into Postfix configuration files.
+ in Postfix configuration files.
The last part of the solution does the email forwarding, which is the real
purpose of the firewall email function.
@@ -348,8 +348,8 @@ Note: this example requires Postfix version 2.0 and later. To find out what
Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
The following example presents additional configuration. You need to combine
-this with basic configuration information as discussed the first half of this
-document.
+this with basic configuration information as discussed in the first half of
+this document.
1 /etc/postfix/main.cf:
2 transport_maps = hash:/etc/postfix/transport
@@ -386,7 +386,8 @@ transport table.
CCoonnffiigguurriinngg PPoossttffiixx aass pprriimmaarryy oorr bbaacckkuupp MMXX hhoosstt ffoorr aa rreemmoottee ssiittee
This section presents additional configuration. You need to combine this with
-basic configuration information as discussed the first half of this document.
+basic configuration information as discussed in the first half of this
+document.
When your system is SECONDARY MX host for a remote site this is all you need:
@@ -472,7 +473,8 @@ This section applies to dialup connections that are down most of the time. For
dialup connections that are up 24x7, see the local area network section above.
This section presents additional configuration. You need to combine this with
-basic configuration information as discussed the first half of this document.
+basic configuration information as discussed in the first half of this
+document.
If you do not have your own hostname and IP address (usually with dialup, cable
TV or DSL connections) then you should also study the section on "Postfix on
@@ -553,8 +555,8 @@ addresses by valid Internet addresses. This mapping happens ONLY when mail
leaves the machine; not when you send mail between users on the same machine.
The following example presents additional configuration. You need to combine
-this with basic configuration information as discussed the first half of this
-document.
+this with basic configuration information as discussed in the first half of
+this document.
1 /etc/postfix/main.cf:
2 smtp_generic_maps = hash:/etc/postfix/generic
@@ -589,8 +591,8 @@ fantasy addresses, including mail to local fantasy addresses that don't have a
valid Internet address of their own.
The following example presents additional configuration. You need to combine
-this with basic configuration information as discussed the first half of this
-document.
+this with basic configuration information as discussed in the first half of
+this document.
1 /etc/postfix/main.cf:
2 myhostname = hostname.localdomain
diff --git a/postfix/README_FILES/STRESS_README b/postfix/README_FILES/STRESS_README
index 79d113a55..8edc148e4 100644
--- a/postfix/README_FILES/STRESS_README
+++ b/postfix/README_FILES/STRESS_README
@@ -410,7 +410,7 @@ OOtthheerr mmeeaassuurreess ttoo ooffff--llooaadd zzoom
The postscreen(8) daemon, introduced with Postfix 2.8, provides additional
protection against mail server overload. One postscreen(8) process handles
-multiple inbound SMTP connections, and decides which clients may to talk to a
+multiple inbound SMTP connections, and decides which clients may talk to a
Postfix SMTP server process. By keeping spambots away, postscreen(8) leaves
more SMTP server processes available for legitimate clients, and delays the
onset of server overload conditions.
diff --git a/postfix/README_FILES/TLS_LEGACY_README b/postfix/README_FILES/TLS_LEGACY_README
index 1a18bc531..f4dae6b00 100644
--- a/postfix/README_FILES/TLS_LEGACY_README
+++ b/postfix/README_FILES/TLS_LEGACY_README
@@ -126,7 +126,7 @@ SSeerrvveerr--ssiiddee cceerrttiiffiiccaattee aanndd p
In order to use TLS, the Postfix SMTP server needs a certificate and a private
key. Both must be in "pem" format. The private key must not be encrypted,
-meaning: the key must be accessible without password. Both certificate and
+meaning: the key must be accessible without a password. Both certificate and
private key may be in the same file.
Both RSA and DSA certificates are supported. Typically you will only have RSA
@@ -147,7 +147,7 @@ with:
% ccaatt sseerrvveerr__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> sseerrvveerr..ppeemm
-A Postfix SMTP server certificate supplied here must be usable as SSL server
+A Postfix SMTP server certificate supplied here must be usable as an SSL server
certificate and hence pass the "openssl verify -purpose sslserver ..." test.
A client that trusts the root CA has a local copy of the root CA certificate,
@@ -410,8 +410,8 @@ server access control:
The permit_tls_all_clientcerts feature must be used with caution, because it
can result in too many access permissions. Use this feature only if a special
-CA issues the client certificates, and only if this CA is listed as trusted CA.
-If other CAs are trusted, any owner of a valid client certificate would be
+CA issues the client certificates, and only if this CA is listed as a trusted
+CA. If other CAs are trusted, any owner of a valid client certificate would be
authorized. The permit_tls_all_clientcerts feature can be practical for a
specially created email relay server.
@@ -447,9 +447,9 @@ Example:
SSeerrvveerr--ssiiddee cciipphheerr ccoonnttrroollss
To influence the Postfix SMTP server cipher selection scheme, you can give
-cipherlist string. A detailed description would go to far here; please refer to
-the OpenSSL documentation. If you don't know what to do with it, simply don't
-touch it and leave the (openssl-)compiled in default!
+cipherlist string. A detailed description would go too far here; please refer
+to the OpenSSL documentation. If you don't know what to do with it, simply
+don't touch it and leave the (openssl-)compiled in default!
DO NOT USE " to enclose the string, specify just the string!!!
@@ -520,8 +520,8 @@ time, in which case the cipher used determines which certificate is presented.
It is possible for the Postfix SMTP client to use the same key/certificate pair
as the Postfix SMTP server. If a certificate is to be presented, it must be in
"pem" format. The private key must not be encrypted, meaning: it must be
-accessible without password. Both parts (certificate and private key) may be in
-the same file.
+accessible without a password. Both parts (certificate and private key) may be
+in the same file.
In order for remote SMTP servers to verify the Postfix SMTP client
certificates, the CA certificate (in case of a certificate chain, all CA
@@ -534,7 +534,7 @@ with:
% ccaatt cclliieenntt__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> cclliieenntt..ppeemm
-A Postfix SMTP client certificate supplied here must be usable as SSL client
+A Postfix SMTP client certificate supplied here must be usable as an SSL client
certificate and hence pass the "openssl verify -purpose sslclient ..." test.
A server that trusts the root CA has a local copy of the root CA certificate,
@@ -780,9 +780,9 @@ summarized as follows:
"smtp_use_tls = yes".
* When both hostname and next-hop destination lookups produce a result, the
- more specific per-site policy (NONE, MUST, etc) overrides the less specific
- one (MAY), and the more secure per-site policy (MUST, etc) overrides the
- less secure one (NONE).
+ more specific per-site policy (NONE, MUST, etc.) overrides the less
+ specific one (MAY), and the more secure per-site policy (MUST, etc.)
+ overrides the less secure one (NONE).
* After the per-site policy lookups are combined, the result generally
overrides the global policy. The exception is the less specific MMAAYY per-
@@ -827,7 +827,7 @@ Example:
example.org NONE
# TLS should not be used with the host smtp.example.com.
- smtp.example.com NONE
+ [smtp.example.com] NONE
DDiissccoovveerriinngg sseerrvveerrss tthhaatt ssuuppppoorrtt TTLLSS
@@ -862,9 +862,9 @@ Example:
CClliieenntt--ssiiddee cciipphheerr ccoonnttrroollss
To influence the Postfix SMTP client cipher selection scheme, you can give
-cipherlist string. A detailed description would go to far here; please refer to
-the OpenSSL documentation. If you don't know what to do with it, simply don't
-touch it and leave the (openssl-)compiled in default!
+cipherlist string. A detailed description would go too far here; please refer
+to the OpenSSL documentation. If you don't know what to do with it, simply
+don't touch it and leave the (openssl-)compiled in default!
DO NOT USE " to enclose the string, specify just the string!!!
@@ -1071,7 +1071,7 @@ Please differentiate when possible between:
* Problems in the TLS code:
* Problems in vanilla Postfix:
-CCoommppaattiibbiilliittyy wwiitthh PPoossttffiixx <<22..22 TTLLSS ssuuppppoorrtt
+CCoommppaattiibbiilliittyy wwiitthh PPoossttffiixx << 22..22 TTLLSS ssuuppppoorrtt
Postfix version 2.2 TLS support is based on the Postfix/TLS patch by Lutz
Ja"nicke, but differs in a few minor ways.
diff --git a/postfix/README_FILES/TLS_README b/postfix/README_FILES/TLS_README
index 315d9fbf6..12ef62f37 100644
--- a/postfix/README_FILES/TLS_README
+++ b/postfix/README_FILES/TLS_README
@@ -12,7 +12,7 @@ NOTE: By turning on TLS support in Postfix, you not only get the ability to
encrypt mail and to authenticate remote SMTP clients or servers. You also turn
on hundreds of thousands of lines of OpenSSL library code. Assuming that
OpenSSL is written as carefully as Wietse's own code, every 1000 lines
-introduce one additional bug into Postfix.
+introduces one additional bug into Postfix.
Topics covered in this document:
@@ -121,7 +121,7 @@ To verify the Postfix SMTP server certificate, the remote SMTP client must
receive the issuing CA certificates via the TLS handshake or via public-key
infrastructure. This means that the Postfix server public-key certificate file
must include the server certificate first, then the issuing CA(s) (bottom-up
-order). The Postfix SMTP server certificate must be usable as SSL server
+order). The Postfix SMTP server certificate must be usable as an SSL server
certificate and hence pass the "openssl verify -purpose sslserver ..." test.
The examples that follow show how to create a server certificate file. We
@@ -178,7 +178,8 @@ and any additional issuer certificates. A single file can hold multiple (key,
cert, [chain]) sequences, one per algorithm. It is typically simpler to keep
the chain for each algorithm in its own file. Most users are likely to deploy
just a single RSA chain, but with OpenSSL 1.1.1, it is possible to deploy up to
-five chains, one each for RSA, ECDSA, ED25519, ED448 and even the obsolete DSA.
+five chains, one each for RSA, ECDSA, ED25519, ED448, and even the obsolete
+DSA.
# Postfix >= 3.4. Preferred configuration interface. Each file
# starts with the private key, followed by the corresponding
@@ -554,8 +555,8 @@ their use in this context, though not recommended, is still likely safe.
The permit_tls_all_clientcerts feature must be used with caution, because it
can result in too many access permissions. Use this feature only if a special
-CA issues the client certificates, and only if this CA is listed as trusted CA.
-If other CAs are trusted, any owner of a valid client certificate would be
+CA issues the client certificates, and only if this CA is listed as a trusted
+CA. If other CAs are trusted, any owner of a valid client certificate would be
authorized. The permit_tls_all_clientcerts feature can be practical for a
specially created email relay server.
@@ -1404,8 +1405,8 @@ which certificate is presented.
It is possible for the Postfix SMTP client to use the same key/certificate pair
as the Postfix SMTP server. If a certificate is to be presented, it must be in
"PEM" format. The private key must not be encrypted, meaning: it must be
-accessible without password. Both parts (certificate and private key) may be in
-the same file.
+accessible without a password. Both parts (certificate and private key) may be
+in the same file.
With OpenSSL 1.1.1 and Postfix >= 3.4 it is also possible to configure Ed25519
and Ed448 certificates. Rather than add two more pairs of key and certificate
@@ -1426,7 +1427,7 @@ user create the client.pem file with:
# uummaasskk 007777
# ccaatt cclliieenntt__kkeeyy..ppeemm cclliieenntt__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> cchhaaiinn..ppeemm
-A Postfix SMTP client certificate supplied here must be usable as SSL client
+A Postfix SMTP client certificate supplied here must be usable as an SSL client
certificate and hence pass the "openssl verify -purpose sslclient ..." test.
A server that trusts the root CA has a local copy of the root CA certificate,
@@ -1443,7 +1444,8 @@ and any additional issuer certificates. A single file can hold multiple (key,
cert, [chain]) sequences, one per algorithm. It is typically simpler to keep
the chain for each algorithm in its own file. Most users are likely to deploy
at most a single RSA chain, but with OpenSSL 1.1.1, it is possible to deploy up
-five chains, one each for RSA, ECDSA, ED25519, ED448 and even the obsolete DSA.
+five chains, one each for RSA, ECDSA, ED25519, ED448, and even the obsolete
+DSA.
# Postfix >= 3.4. Preferred configuration interface. Each file
# starts with the private key, followed by the corresponding
@@ -1782,14 +1784,15 @@ vveerriiffyy
files.
sseeccuurree
Secure certificate verification. Mail is delivered only if the TLS
- handshake succeeds, if the remote SMTP server certificate can be validated
- (not expired or revoked, and signed by a trusted Certification Authority),
- and if the server certificate name matches the optional "match" attribute
- (or the main.cf smtp_tls_secure_cert_match parameter value when no optional
- "match" attribute is specified). With Postfix >= 2.11 the "tafile"
- attribute optionally modifies trust chain verification in the same manner
- as the "smtp_tls_trust_anchor_file" parameter. The "tafile" attribute may
- be specified multiple times to load multiple trust-anchor files.
+ handshake succeeds, and DNS forgery resistant remote SMTP certificate
+ verification succeeds (not expired or revoked, and signed by a trusted
+ Certification Authority), and if the server certificate name matches the
+ optional "match" attribute (or the main.cf smtp_tls_secure_cert_match
+ parameter value when no optional "match" attribute is specified). With
+ Postfix >= 2.11 the "tafile" attribute optionally modifies trust chain
+ verification in the same manner as the "smtp_tls_trust_anchor_file"
+ parameter. The "tafile" attribute may be specified multiple times to load
+ multiple trust-anchor files.
Notes:
* The "match" attribute is especially useful to verify TLS certificates for
@@ -2174,7 +2177,7 @@ authentication. This is sufficient for testing, and for exchanging email with
sites that you have no trust relationship with. For real authentication you
need also enable DNSSEC record signing for your domain and publish TLSA records
and/or your Postfix public key certificate needs to be signed by a recognized
-Certification Authority. To authenticate the certificates of remote host you
+Certification Authority. To authenticate the certificates of a remote host you
need a DNSSEC-validating local resolver and to enable DANE authentication and/
or configure the Postfix SMTP client with a list of public key certificates of
Certification Authorities, but make sure to read about the limitations of the
@@ -2392,7 +2395,7 @@ PPrriivvaattee CCeerrttiiffiiccaattiioonn AAuutthhoorr
Often servers that perform TLS client authentication will issue the
required certificates signed by their own CA. If you configure the client
certificate and key incorrectly, you will be unable to send mail to sites
- that request client certificate, but don't require them from all clients.
+ that request a client certificate, but don't require them from all clients.
/etc/postfix/main.cf:
smtp_tls_CAfile = /etc/postfix/cacert.pem
diff --git a/postfix/README_FILES/TUNING_README b/postfix/README_FILES/TUNING_README
index c1176617a..10801646c 100644
--- a/postfix/README_FILES/TUNING_README
+++ b/postfix/README_FILES/TUNING_README
@@ -285,9 +285,8 @@ than the default 20) simultaneous connections, especially if the gateway
forwards to multiple MX hosts. When all MX hosts are up and accepting
connections in a timely fashion, throughput will be high. If any MX host is
down and completely unresponsive, the average connection latency rises to at
-least 1/N * $smtp_connection_timeout, if there are N MX hosts. This limits
-throughput to at most the destination concurrency * N /
-$smtp_connection_timeout.
+least 1/N * $smtp_connect_timeout, if there are N MX hosts. This limits
+throughput to at most the destination concurrency * N / $smtp_connect_timeout.
For example, with a destination concurrency of 100 and 2 MX hosts, each host
will handle up to 50 simultaneous connections. If one MX host is down and the
@@ -298,10 +297,10 @@ low as 5s or even 1s can be used to prevent congestion when one or more, but
not all MX hosts are down.
If necessary, set a higher transport_destination_concurrency_limit (in main.cf
-since this is a queue manager parameter) and a lower smtp_connection_timeout
-(with a "-o" override in master.cf since this parameter has no per-transport
-name) for the relay transport and any transports dedicated for specific high
-volume destinations.
+since this is a queue manager parameter) and a lower smtp_connect_timeout (with
+a "-o" override in master.cf since this parameter has no per-transport name)
+for the relay transport and any transports dedicated for specific high volume
+destinations.
TTuunniinngg tthhee nnuummbbeerr ooff rreecciippiieennttss ppeerr ddeelliivveerryy
diff --git a/postfix/README_FILES/VIRTUAL_README b/postfix/README_FILES/VIRTUAL_README
index 6f470eeb7..e693a0ceb 100644
--- a/postfix/README_FILES/VIRTUAL_README
+++ b/postfix/README_FILES/VIRTUAL_README
@@ -27,14 +27,14 @@ The following topics are covered:
CCaannoonniiccaall vveerrssuuss hhoosstteedd vveerrssuuss ootthheerr ddoommaaiinnss
-Most Postfix systems are ffiinnaall ddeessttiinnaattiioonn for only a few domain names. These
-include the hostnames and [the IP addresses] of the machine that Postfix runs
-on, and sometimes also include the parent domain of the hostname. The remainder
-of this document will refer to these domains as the canonical domains. They are
-usually implemented with the Postfix local domain address class, as defined in
-the ADDRESS_CLASS_README file.
-
-Besides the canonical domains, Postfix can be configured to be ffiinnaall
+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
@@ -49,8 +49,8 @@ implemented with the relay domain address class, as defined in the
ADDRESS_CLASS_README file.
Finally, Postfix can be configured as a transit host for sending mail across
-the internet. Obviously, Postfix is not final destination for such mail. This
-function is available only for authorized clients and/or users, and is
+the internet. Obviously, Postfix is not the final destination for such mail.
+This function is available only for authorized clients and/or users, and is
implemented by the default domain address class, as defined in the
ADDRESS_CLASS_README file.
diff --git a/postfix/TLS_ACKNOWLEDGEMENTS b/postfix/TLS_ACKNOWLEDGEMENTS
index 93c93d5b2..6cf435448 100644
--- a/postfix/TLS_ACKNOWLEDGEMENTS
+++ b/postfix/TLS_ACKNOWLEDGEMENTS
@@ -1,5 +1,5 @@
- Walcir Fontanini
- * tested on Solaris 2.5 and and reported missing "snprintf()"
+ * tested on Solaris 2.5 and reported missing "snprintf()"
-> was fixed in pfixtls-0.1.2
* contributed the script to add fingerprints
contributed/fp.csh
diff --git a/postfix/TLS_CHANGES b/postfix/TLS_CHANGES
index 62a529e6a..1abe0ff15 100644
--- a/postfix/TLS_CHANGES
+++ b/postfix/TLS_CHANGES
@@ -1940,7 +1940,7 @@
- Updated configuration information:
* As of OpenSSL 0.9.4, certificate chain verification is not sufficient,
since the certificate purpose is not checked, so I recommend to add
- all intermediate CAs the the list of CAs and stay with a verification
+ all intermediate CAs the list of CAs and stay with a verification
depth of 1.
Work is in progress for 0.9.5.
- Stepped up to the just released new patchlevel postfix-19990906-pl09.
@@ -2070,7 +2070,7 @@
1999/10/09
- Set an absolut maximum length of 32 for the IDs used for session caching.
- This matches the default in OpenSSL, but I don´t want to see surprises
+ This matches the default in OpenSSL, but I don't want to see surprises
when somebody sometimes will run into a longer session id.
1999/10/05 == Released 0.4.0 ==
@@ -2107,11 +2107,11 @@
to computer sience students.
1999/09/28
- - I cannot use the mod_ssl way for session caching and I don´t want to
- spend an extra "gcache" daemon as ApacheSSL does. So I follow Wietse´s
+ - I cannot use the mod_ssl way for session caching and I don't want to
+ spend an extra "gcache" daemon as ApacheSSL does. So I follow Wietse's
idea realized for his mail queues and create hash level based subdirectory
structures. The good thing: I can cannibalize the mail_queue code.
- The bad thing: there is a path length of 100 chars fix coded in Wietse´s
+ The bad thing: there is a path length of 100 chars fix coded in Wietse's
routines. It does hold for 32byte session ideas.
Status: can save sessions to disk and recall them (server side).
@@ -2119,8 +2119,8 @@
- Created new call backs for external session caching for the server side.
In a first step, they can print out the session ids for the newly created
session and when recalling a session.
- As the OpenSSL documentation on this is pretty sparse, Ben Laurie´s
- ApacheSSL code is very helpful, Ralph Engelschall´s Mod_SSL code for
+ As the OpenSSL documentation on this is pretty sparse, Ben Laurie's
+ ApacheSSL code is very helpful, Ralph Engelschall's Mod_SSL code for
session caching is far more complicated.
1999/09/23 == Released 0.3.10 ==
@@ -2146,7 +2146,7 @@
SSL_CTX_set_session_id_context() call was missing. To find this, I
had to trace through the OpenSSL library and when I finally found it
in ssl/ssl_sess.c, there was an appropriate comment about this. I however
- have to find out why I didn´t receive the appropriate error message...
+ have to find out why I didn't receive the appropriate error message...
- This bug was hidden during the first developing stages, as the shutdown
sequence was not working correct, so the session was not cached.
@@ -2181,7 +2181,7 @@
1999/09/09 == Released 0.3.6 ==
1999/09/09
- - Added a missing ´#ifdef HAS_SSL #endif´ in smtp_connect.c.
+ - Added a missing '#ifdef HAS_SSL #endif' in smtp_connect.c.
Noted by Jeff Johnson .
- HINT:
On 1999/09/06 a new "stable" version of postfix was released.
@@ -2357,7 +2357,7 @@
1999/04/14
- Ported from OpenSSL the BIO_callback functions to dump out the negotiation
and transmission for debugging purposes. The functions are triggered
- by the the new loglevels 3 and 4.
+ by the new loglevels 3 and 4.
- Call SSL_free() to get rid of the SSL connection structure not used
anymore.
diff --git a/postfix/WISHLIST b/postfix/WISHLIST
index 701d0c7cd..6a817c495 100644
--- a/postfix/WISHLIST
+++ b/postfix/WISHLIST
@@ -1,18 +1,22 @@
Wish list:
- Factor out the new get_nested_dict_name() function from
- proxymap.c, make it a library function, and reuse it in
- postconf_dbms.c.
+ Things to do before the stable release:
+
+ make typo-check, HTML validator check,
+ mantools/missing-proxy-read-maps, mantools/check-postlink.
- Convert the proxymap protol into "server speaks first".
+ Disable -DSNAPSHOT and -DNONPROD in makedefs.
Fix code that still uses "long" for data_size and data_offset,
and that uses "%ld" in sscanf().
- A smart query service for live Postfix tables that outputs JSON?
+ For consistent naming (tlsproxy_client_mumble <> smtp_tls_mumble),
+ rename tlsproxy_client_level to tlsproxy_client_security_level,
+ and tlsproxy_client_policy to tlsproxy_client_policy_maps.
+ This requires backwards-compatible defaults and documentation
+ updates.
- proxy_read_maps needs a dedicated matcher that looks
- inside pipemap:{}. Maybe steal some code from postconf.
+ A smart query service for live Postfix tables that outputs JSON?
Add a pointer to
http://mmogilvi.users.sourceforge.net/software/oauthbearer.html
@@ -124,13 +128,6 @@ Wish list:
Replace ad-hoc code for pipe(8) flags handling, with
infrastructure that was built for smtp(8).
- Things to do before the stable release:
-
- Spell-check, double-word check, HTML validator check,
- mantools/missing-proxy-read-maps check.
-
- Disable -DSNAPSHOT and -DNONPROD in makedefs.
-
Move map descriptions from postconf(1) to DATABASE_README
and point there. The text in DATABASE_README is less complete
than that in postconf(1).
diff --git a/postfix/auxiliary/qshape/qshape.pl b/postfix/auxiliary/qshape/qshape.pl
index 2ad88e179..366521601 100755
--- a/postfix/auxiliary/qshape/qshape.pl
+++ b/postfix/auxiliary/qshape/qshape.pl
@@ -138,7 +138,7 @@ do {
"The 's' option shows sender domain counts.\n".
"The 'p' option shows address counts by for parent domains.\n".
"Parent domains are shown with a leading '.' before the domain name.\n".
- "Parent domains are only shown if the the domain is not a TLD, and at\n".
+ "Parent domains are only shown if the domain is not a TLD, and at\n".
"least (default 5) subdomains are shown in the output.\n\n".
"The bucket age ranges in units of minutes are\n".
diff --git a/postfix/conf/access b/postfix/conf/access
index 257339bfb..97892eb73 100644
--- a/postfix/conf/access
+++ b/postfix/conf/access
@@ -31,7 +31,7 @@
#
# Alternatively, the table can be provided as a regu-
# lar-expression map where patterns are given as regular
-# expressions, or lookups can be directed to TCP-based
+# expressions, or lookups can be directed to a TCP-based
# server. In those cases, the lookups are done in a slightly
# different way as described below under "REGULAR EXPRESSION
# TABLES" or "TCP-BASED TABLES".
@@ -232,7 +232,7 @@
#
# DEFER_IF_PERMIT optional text...
# Defer the request if some later restriction would
-# result in a an explicit or implicit PERMIT action.
+# result in an explicit or implicit PERMIT action.
# Reply with "$access_map_defer_code 4.7.1 optional
# text..." when the optional text is specified, oth-
# erwise reply with a generic error response message.
diff --git a/postfix/conf/canonical b/postfix/conf/canonical
index 9881f4ef8..4957fcc4f 100644
--- a/postfix/conf/canonical
+++ b/postfix/conf/canonical
@@ -29,7 +29,7 @@
#
# Alternatively, the table can be provided as a regu-
# lar-expression map where patterns are given as regular
-# expressions, or lookups can be directed to TCP-based
+# expressions, or lookups can be directed to a TCP-based
# server. In those cases, the lookups are done in a slightly
# different way as described below under "REGULAR EXPRESSION
# TABLES" or "TCP-BASED TABLES".
@@ -252,8 +252,8 @@
#
# masquerade_exceptions (empty)
# Optional list of user names that are not subjected
-# to address masquerading, even when their address
-# matches $masquerade_domains.
+# to address masquerading, even when their addresses
+# match $masquerade_domains.
#
# mydestination ($myhostname, localhost.$mydomain, local-
# host)
diff --git a/postfix/conf/generic b/postfix/conf/generic
index 9d293683a..f371eb9a5 100644
--- a/postfix/conf/generic
+++ b/postfix/conf/generic
@@ -42,8 +42,8 @@
#
# Alternatively, the table can be provided as a regu-
# lar-expression map where patterns are given as regular
-# expressions, or lookups can be directed to TCP-based
-# server. In those case, the lookups are done in a slightly
+# expressions, or lookups can be directed to a TCP-based
+# server. In those cases, the lookups are done in a slightly
# different way as described below under "REGULAR EXPRESSION
# TABLES" or "TCP-BASED TABLES".
#
@@ -140,8 +140,8 @@
# This section describes how the table lookups change when
# lookups are directed to a TCP-based server. For a descrip-
# tion of the TCP client/server lookup protocol, see tcp_ta-
-# ble(5). This feature is not available up to and including
-# Postfix version 2.4.
+# ble(5). This feature is available in Postfix 2.5 and
+# later.
#
# Each lookup operation uses the entire address once. Thus,
# user@domain mail addresses are not broken up into their
@@ -180,40 +180,42 @@
# The text below provides only a parameter summary. See
# postconf(5) for more details including examples.
#
-# smtp_generic_maps
-# Address mapping lookup table for envelope and
-# header sender and recipient addresses while deliv-
-# ering mail via SMTP.
+# smtp_generic_maps (empty)
+# Optional lookup tables that perform address rewrit-
+# ing in the Postfix SMTP client, typically to trans-
+# form a locally valid address into a globally valid
+# address when sending mail across the Internet.
#
-# propagate_unmatched_extensions
-# A list of address rewriting or forwarding mecha-
-# nisms that propagate an address extension from the
-# original address to the result. Specify zero or
-# more of canonical, virtual, alias, forward,
-# include, or generic.
+# propagate_unmatched_extensions (canonical, virtual)
+# What address lookup tables copy an address exten-
+# sion from the lookup key to the lookup result.
#
# Other parameters of interest:
#
-# inet_interfaces
-# The network interface addresses that this system
-# receives mail on. You need to stop and start Post-
-# fix when this parameter changes.
-#
-# proxy_interfaces
-# Other interfaces that this machine receives mail on
-# by way of a proxy agent or network address transla-
-# tor.
-#
-# mydestination
-# List of domains that this mail system considers
-# local.
-#
-# myorigin
-# The domain that is appended to locally-posted mail.
-#
-# owner_request_special
-# Give special treatment to owner-xxx and xxx-request
-# addresses.
+# inet_interfaces (all)
+# The network interface addresses that this mail sys-
+# tem receives mail on.
+#
+# proxy_interfaces (empty)
+# The network interface addresses that this mail sys-
+# tem receives mail on by way of a proxy or network
+# address translation unit.
+#
+# mydestination ($myhostname, localhost.$mydomain, local-
+# host)
+# The list of domains that are delivered via the
+# $local_transport mail delivery transport.
+#
+# myorigin ($myhostname)
+# The domain name that locally-posted mail appears to
+# come from, and that locally posted mail is deliv-
+# ered to.
+#
+# owner_request_special (yes)
+# Enable special treatment for owner-listname entries
+# in the aliases(5) file, and don't split owner-list-
+# name and listname-request address localparts when
+# the recipient_delimiter is set to "-".
#
# SEE ALSO
# postmap(1), Postfix lookup table manager
diff --git a/postfix/conf/main.cf b/postfix/conf/main.cf
index 562e4dfc3..47de43463 100644
--- a/postfix/conf/main.cf
+++ b/postfix/conf/main.cf
@@ -31,7 +31,7 @@
#
# The level below is what should be used with new (not upgrade) installs.
#
-compatibility_level = 3.6
+compatibility_level = 3.7
# SOFT BOUNCE
#
@@ -251,11 +251,14 @@ unknown_local_recipient_reject_code = 550
# You can specify the list of "trusted" network addresses by hand
# or you can let Postfix do it for you (which is the default).
#
-# By default (mynetworks_style = subnet), Postfix "trusts" SMTP
-# clients in the same IP subnetworks as the local machine.
-# On Linux, this works correctly only with interfaces specified
-# with the "ifconfig" command.
+# By default (mynetworks_style = host), Postfix "trusts" only
+# the local machine.
#
+# Specify "mynetworks_style = subnet" when Postfix should "trust"
+# SMTP clients in the same IP subnetworks as the local machine.
+# On Linux, this works correctly only with interfaces specified
+# with the "ifconfig" or "ip" command.
+#
# Specify "mynetworks_style = class" when Postfix should "trust" SMTP
# clients in the same IP class A/B/C networks as the local machine.
# Don't do this with a dialup site - it would cause Postfix to "trust"
@@ -285,14 +288,16 @@ unknown_local_recipient_reject_code = 550
#mynetworks = hash:/etc/postfix/network_table
# The relay_domains parameter restricts what destinations this system will
-# relay mail to. See the smtpd_recipient_restrictions description in
-# postconf(5) for detailed information.
+# relay mail to. See the smtpd_relay_restrictions and
+# smtpd_recipient_restrictions descriptions in postconf(5) for detailed
+# information.
#
# By default, Postfix relays mail
-# - from "trusted" clients (IP address matches $mynetworks) to any destination,
+# - from "trusted" clients (IP address matches $mynetworks, or is
+# SASL authenticated) to any destination,
# - from "untrusted" clients to destinations that match $relay_domains or
# subdomains thereof, except addresses with sender-specified routing.
-# The default relay_domains value is $mydestination.
+# The default relay_domains value is empty.
#
# In addition to the above, the Postfix SMTP server by default accepts mail
# that Postfix is final destination for:
@@ -312,7 +317,7 @@ unknown_local_recipient_reject_code = 550
# list this system as their primary or backup MX host. See the
# permit_mx_backup restriction description in postconf(5).
#
-#relay_domains = $mydestination
+#relay_domains =
# INTERNET OR INTRANET
diff --git a/postfix/conf/post-install b/postfix/conf/post-install
index 975266b8b..2a7d99b9a 100644
--- a/postfix/conf/post-install
+++ b/postfix/conf/post-install
@@ -144,7 +144,7 @@
# should not be in the command search path of any users.
# .IP command_directory
# The directory for Postfix administrative commands. This
-# directory should be in the command search path of adminstrative users.
+# directory should be in the command search path of administrative users.
# .IP queue_directory
# The directory for Postfix queues.
# .IP data_directory
diff --git a/postfix/conf/postmulti-script b/postfix/conf/postmulti-script
index 934228d16..1b3175540 100644
--- a/postfix/conf/postmulti-script
+++ b/postfix/conf/postmulti-script
@@ -16,7 +16,7 @@ umask 022
# daemon_directory - From primary instance
# meta_directory - From primary instance
# shlib_directory - From primary instance
-# config_directroy - config_directory of target instance
+# config_directory - config_directory of target instance
# queue_directory - queue_directory of target instance
# data_directory - data_directory of target instance
#
diff --git a/postfix/conf/relocated b/postfix/conf/relocated
index e50edfd18..90f63ecf2 100644
--- a/postfix/conf/relocated
+++ b/postfix/conf/relocated
@@ -24,7 +24,7 @@
#
# Alternatively, the table can be provided as a regu-
# lar-expression map where patterns are given as regular
-# expressions, or lookups can be directed to TCP-based
+# expressions, or lookups can be directed to a TCP-based
# server. In those case, the lookups are done in a slightly
# different way as described below under "REGULAR EXPRESSION
# TABLES" or "TCP-BASED TABLES".
@@ -86,66 +86,68 @@
# description of regular expression lookup table syntax, see
# regexp_table(5) or pcre_table(5). For a description of the
# TCP client/server table lookup protocol, see tcp_table(5).
-# This feature is not available up to and including Postfix
-# version 2.4.
+# This feature is available in Postfix 2.5 and later.
#
-# Each pattern is a regular expression that is applied to
+# Each pattern is a regular expression that is applied to
# the entire address being looked up. Thus, user@domain mail
-# addresses are not broken up into their user and @domain
+# addresses are not broken up into their user and @domain
# constituent parts, nor is user+foo broken up into user and
# foo.
#
-# Patterns are applied in the order as specified in the ta-
-# ble, until a pattern is found that matches the search
+# Patterns are applied in the order as specified in the ta-
+# ble, until a pattern is found that matches the search
# string.
#
-# Results are the same as with indexed file lookups, with
-# the additional feature that parenthesized substrings from
+# Results are the same as with indexed file lookups, with
+# the additional feature that parenthesized substrings from
# the pattern can be interpolated as $1, $2 and so on.
#
# TCP-BASED TABLES
-# This section describes how the table lookups change when
+# This section describes how the table lookups change when
# lookups are directed to a TCP-based server. For a descrip-
# tion of the TCP client/server lookup protocol, see tcp_ta-
-# ble(5). This feature is not available up to and including
-# Postfix version 2.4.
+# ble(5). This feature is available in Postfix 2.5 and
+# later.
#
# Each lookup operation uses the entire address once. Thus,
-# user@domain mail addresses are not broken up into their
+# user@domain mail addresses are not broken up into their
# user and @domain constituent parts, nor is user+foo broken
# up into user and foo.
#
# Results are the same as with indexed file lookups.
#
# BUGS
-# The table format does not understand quoting conventions.
+# The table format does not understand quoting conventions.
#
# CONFIGURATION PARAMETERS
-# The following main.cf parameters are especially relevant.
-# The text below provides only a parameter summary. See
+# The following main.cf parameters are especially relevant.
+# The text below provides only a parameter summary. See
# postconf(5) for more details including examples.
#
-# relocated_maps
-# List of lookup tables for relocated users or sites.
+# relocated_maps (empty)
+# Optional lookup tables with new contact information
+# for users or domains that no longer exist.
#
# Other parameters of interest:
#
-# inet_interfaces
-# The network interface addresses that this system
-# receives mail on. You need to stop and start Post-
-# fix when this parameter changes.
+# inet_interfaces (all)
+# The network interface addresses that this mail sys-
+# tem receives mail on.
#
-# mydestination
-# List of domains that this mail system considers
-# local.
+# mydestination ($myhostname, localhost.$mydomain, local-
+# host)
+# The list of domains that are delivered via the
+# $local_transport mail delivery transport.
#
-# myorigin
-# The domain that is appended to locally-posted mail.
+# myorigin ($myhostname)
+# The domain name that locally-posted mail appears to
+# come from, and that locally posted mail is deliv-
+# ered to.
#
-# proxy_interfaces
-# Other interfaces that this machine receives mail on
-# by way of a proxy agent or network address transla-
-# tor.
+# proxy_interfaces (empty)
+# The network interface addresses that this mail sys-
+# tem receives mail on by way of a proxy or network
+# address translation unit.
#
# SEE ALSO
# trivial-rewrite(8), address resolver
@@ -153,13 +155,13 @@
# postconf(5), configuration parameters
#
# README FILES
-# Use "postconf readme_directory" or "postconf html_direc-
+# Use "postconf readme_directory" or "postconf html_direc-
# tory" to locate this information.
# DATABASE_README, Postfix lookup table overview
# ADDRESS_REWRITING_README, address rewriting guide
#
# LICENSE
-# The Secure Mailer license must be distributed with this
+# The Secure Mailer license must be distributed with this
# software.
#
# AUTHOR(S)
diff --git a/postfix/conf/transport b/postfix/conf/transport
index 1dcd787bc..bad773951 100644
--- a/postfix/conf/transport
+++ b/postfix/conf/transport
@@ -61,7 +61,7 @@
#
# Alternatively, the table can be provided as a regu-
# lar-expression map where patterns are given as regular
-# expressions, or lookups can be directed to TCP-based
+# expressions, or lookups can be directed to a TCP-based
# server. In those case, the lookups are done in a slightly
# different way as described below under "REGULAR EXPRESSION
# TABLES" or "TCP-BASED TABLES".
diff --git a/postfix/conf/virtual b/postfix/conf/virtual
index da9cd655c..96390fee8 100644
--- a/postfix/conf/virtual
+++ b/postfix/conf/virtual
@@ -51,7 +51,7 @@
#
# Alternatively, the table can be provided as a regu-
# lar-expression map where patterns are given as regular
-# expressions, or lookups can be directed to TCP-based
+# expressions, or lookups can be directed to a TCP-based
# server. In those case, the lookups are done in a slightly
# different way as described below under "REGULAR EXPRESSION
# TABLES" or "TCP-BASED TABLES".
@@ -99,8 +99,8 @@
# tination, or when it is listed in $inet_interfaces
# or $proxy_interfaces.
#
-# This functionality overlaps with functionality of
-# the local aliases(5) database. The difference is
+# This functionality overlaps with the functionality
+# of the local aliases(5) database. The difference is
# that virtual(5) mapping can be applied to non-local
# addresses.
#
@@ -155,7 +155,7 @@
#
# The propagate_unmatched_extensions parameter controls
# whether an unmatched address extension (+foo) is propa-
-# gated to the result of table lookup.
+# gated to the result of a table lookup.
#
# VIRTUAL ALIAS DOMAINS
# Besides virtual aliases, the virtual alias table can also
@@ -232,8 +232,8 @@
# This section describes how the table lookups change when
# lookups are directed to a TCP-based server. For a descrip-
# tion of the TCP client/server lookup protocol, see tcp_ta-
-# ble(5). This feature is not available up to and including
-# Postfix version 2.4.
+# ble(5). This feature is available in Postfix 2.5 and
+# later.
#
# Each lookup operation uses the entire address once. Thus,
# user@domain mail addresses are not broken up into their
@@ -254,11 +254,11 @@
# virtual_alias_maps ($virtual_maps)
# Optional lookup tables that alias specific mail
# addresses or domains to other local or remote
-# address.
+# addresses.
#
# virtual_alias_domains ($virtual_alias_maps)
-# Postfix is final destination for the specified list
-# of virtual alias domains, that is, domains for
+# Postfix is the final destination for the specified
+# list of virtual alias domains, that is, domains for
# which all addresses are aliased to addresses in
# other local or remote domains.
#
diff --git a/postfix/html/ADDRESS_REWRITING_README.html b/postfix/html/ADDRESS_REWRITING_README.html
index a20b50962..a2d83188c 100644
--- a/postfix/html/ADDRESS_REWRITING_README.html
+++ b/postfix/html/ADDRESS_REWRITING_README.html
@@ -493,8 +493,8 @@ document.
Rewrite "user@host" to "user@host.$mydomain"
This feature is controlled by the boolean append_dot_mydomain
-parameter (default: yes). The purpose is to get consistent treatment
-of different forms of the same hostname.
+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
diff --git a/postfix/html/BACKSCATTER_README.html b/postfix/html/BACKSCATTER_README.html
index 85effce37..f4e26edde 100644
--- a/postfix/html/BACKSCATTER_README.html
+++ b/postfix/html/BACKSCATTER_README.html
@@ -302,7 +302,7 @@ 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 to exclude their Message-ID
+
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
@@ -382,7 +382,8 @@ above techniques to recognize forgeries.
because there is a lot of variation in report formats. The following
is only a small example of message header patterns. For a large
collection of header and body patterns that recognize virus
-notification email, see http://www.dkuug.dk/keld/virus/
+notification email, see
+https://web.archive.org/web/20100317123907/http://std.dkuug.dk/keld/virus/
or http://www.t29.dk/antiantivirus.txt.
diff --git a/postfix/html/BASIC_CONFIGURATION_README.html b/postfix/html/BASIC_CONFIGURATION_README.html
index e206c04a6..ccede706f 100644
--- a/postfix/html/BASIC_CONFIGURATION_README.html
+++ b/postfix/html/BASIC_CONFIGURATION_README.html
@@ -264,7 +264,7 @@ 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 = host" setting may be too friendly.
+then the "mynetworks_style = subnet" setting may be too friendly.
Examples (specify only one of the following):
@@ -286,13 +286,15 @@ parameter value.
--
Specify "mynetworks_style = host" when Postfix should
-forward mail from only the local machine.
+ -
Specify "mynetworks_style = host" (the default when
+compatibility_level ≥ 2) when Postfix should forward mail from
+only the local machine.
- -
Specify "mynetworks_style = subnet" (the default) when
-Postfix should forward mail from SMTP clients in the same IP
-subnetworks as the local machine. On Linux, this works correctly
-only with interfaces specified with the "ifconfig" command.
+ -
Specify "mynetworks_style = subnet" (the default when
+compatibility_level < 2) when Postfix should forward mail from
+SMTP clients in the same IP subnetworks as the local machine.
+On Linux, this works correctly only with interfaces specified
+with the "ifconfig" or "ip" command.
-
Specify "mynetworks_style = class" when Postfix should
forward mail from SMTP clients in the same IP class A/B/C networks
diff --git a/postfix/html/BDAT_README.html b/postfix/html/BDAT_README.html
index 56532fc30..3cc1daf83 100644
--- a/postfix/html/BDAT_README.html
+++ b/postfix/html/BDAT_README.html
@@ -170,7 +170,7 @@ 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, is it a useless restriction
+appear in RFC 3030 which defines BDAT, it is a useless restriction
that Postfix will not enforce.