_destination_concurrency_positive_feedback,
+ _destination_concurrency_failed_cohort_limit.
+
+ Files: global/mail_params.h, *qmgr/qmgr.c, *qmgr/qmgr_transport.c,
+ *qmgr/qmgr_queue.c, *qmgr/qmgr_feedback.c, postconf/auto.awk.
+
+20071202
+
+ Feature: output rate control. For example, specify
+ "smtp_destination_rate_delay = 5m" to insert a five-minute
+ delay between deliveries. This was an opportunity to define
+ the mutually exclusive states that a queue can have, and
+ to detect invalid transitions. This will make adding new
+ features code easier. Files: *qmgr/qmgr_transport.c,
+ *qmgr/qmgr_queue.c, *qmgr/qmgr_entry.c.
+
+ Bugfix (introduced Postfix 2.2): don't update the back-to-back
+ delivery time stamp while deferring mail. File: *qmgr/qmgr_entry.c.
+
+20071203
+
+ Feature: support for read-write tables in the proxymap
+ service. This is implemented with a separate master.cf entry
+ named "proxywrite" that should run with process limit of 1
+ if you want to update Berkeley DB like tables. This feature
+ requires that tables be authorized with the proxy_write_maps
+ configuration parameter. Files: global/dict_procy.[hc],
+ proxymap/proxymap.c.
+
+ Human factors: the postmap and postalias commands now produce
+ nicer diagnostics when asked to do something with a proxied
+ map that they can't do. Files: postmap/postmap.c,
+ postalias/postalias.c.
+
+ Bugfix: the proxymap client didn't properly propagate user
+ options to the proxymap server. File: util/dict.h.
+
+ Workaround: force synchronous updates in the proxymap server
+ so that maps will be in a consistent state between updates.
+ File: proxymap/proxymap.c.
+
+ Bugfix: an empty rate-limited queue wasn't removed after
+ timer expiry. Files: *qmgr/qmgr_queue.c.
+
+20071204
+
+ Use different sockets for proxymap (read-only) and proxywrite
+ (read-write) services in the proxy: client. Victor Duchovni.
+ File: global/dict_proxy.c.
+
+ Feature: proxymap delete support by Victor Duchovni. Files:
+ global/dict_proxy.c, proxymap/proxymap.c.
+
+ Feature: proxymap delete support. Files: postmap/postmap.c
+ postalias/postalias.c.
+
+ Cleanup: the Postfix sendmail command did not include the
+ user (name/uid) information in all error messages. File:
+ sendmail/sendmail.c.
+
+ Feature: data_directory configuration parameter for
+ Postfix-writable data such as caches and random numbers.
+ Files: postfix-install, conf/postfix-files.
+
+20071206
+
+ Security: tlsmgr(8) and verify(8) no longer use root
+ privileges when opening their cache files. This avoids a
+ potential security loophole where the ownership of a file
+ (or directory) does not match the trust level of the content
+ of that file (or directory). See RELEASE_NOTES for how to
+ use pre-existing data. Files: util/set_eugid.[hc],
+ tlsmgr/tlsmgr.c, verify/verify.c.
+
+ Compatibility: as a migration tool, redirect attempts by
+ tlsmgr(8) or verify(8) to open files in non-Postfix directories
+ to the Postfix-owned data_directory. File: global/data_redirect.c.
+
+ Lots of pathname fixes in the examples of TLS_README and
+ postconf(5); -lm library screw-up in queue manager Makefiles.
+
+20071207
+
+ Cleanup: pathname fixes in documentation; unnecessary queue
+ scan in the queue manager rate limiter; inverse square root
+ feedback in the queue manager concurrency scheduler. Files:
+ mantools/postlink, proto/TLS_README.html, *qmgr/qmgr_queue.c.
+
+ All changes up to this point should be ready for Postfix 2.5.
+
+ Documentation: updated nqmgr preemptive scheduler documentation
+ by Patrik Rak. File: proto/SCHEDULER_README.html.
+
+20071211
+
+ Bugfix (introduced 19980315): the "write" equivalent of
+ bugfix 20030104. File: util/vstream.c.
+
+20071212
+
+ Feature: "stress=" or "stress=yes" attribute in the SMTPD
+ policy delegation protocol. File: smtp/smtpd_check.c.
+
+ Cleanup: allow_min_user now rejects recipients (and senders)
+ starting with '-' at SMTP session time. To make this possible
+ the feature was moved from qmgr(8) to trivial-rewrite(8).
+ Files: *qmgr/qmgr_message.c, trivial-rewrite/resolve.c.
+
+20071213:
+
+ Cleanup: the queue manager and SMTP client now distinguish
+ between connection cache store and retrieve hints. Once the
+ queue manager enables connection caching (store and load)
+ hints on a per-destination queue, it keeps sending connection
+ cache retrieve hints to the delivery agent even after it
+ stops sending connection cache store hints. This prevents
+ the SMTP client from making a new connection without checking
+ the connection cache first. Victor Duchovni. Files:
+ *qmgr/qmgr_entry.c, smtp/smtp_connect.c.
+
+ Bugfix (introduced Postfix 2.3): the SMTP client never
+ marked corrupt files as corrupt. Victor Duchovni. File:
+ smtp/smtp_proto.c.
+
+ Cleanup: the SMTP client won't mark a destination as
+ unavailable when at least one SMTP session was completed
+ without connect or handshake error. Victor Duchovni. Files:
+ smtp/smtp_connect.c, smtp/smtp_session.c, smtp/smtp_proto.c,
+ smtp/smtp_trouble.c.
+
+20071215
+
+ Documentation and code cleanup. Files: global/deliver_request.h,
+ *qmgr/qmgr_entry.c, smtp/smtp_connect.c,
+ proto/SCHEDULER_README.html.
+
+ Bugfix (introduced snapshot 20071006): qmqpd ignored the
+ qmqpd_client_port_logging parameter setting. File:
+ qmqpd/qmqpd.c.
+
+20071216
+
+ Cleanup: show the remote SMTP server port in verbose logging,
+ warnings and postmaster notices. Still don't show the port
+ in delivery status notifications. Files: smtp/smtp_chat.c,
+ smtp/smtp_sasl_glue.c, smtp/smtp_sasl_proto.c.
+
+ The "tls_require_cert" is now compatible with OpenLDAP 2.1
+ and later. Victor Duchovni. Files: proto/ldap_table,
+ global/dict_ldap.c.
+
+20071218
+
+ Cleanup: removed the "#ifdef USE_LIBMILTER_INCLUDES"
+ dependencies on system-installed Milter protocol include
+ files. Verified that the object code has not changed. File:
+ milter/milter8.c.
+
+ Sanity check: idiot filter to detect attempts to use the
+ same database file for different TLS session caches. File:
+ tlsmgr/tlsmgr.c.
+
+ Cleanup: updated the spell check stoplist and the spell
+ check script. Files: mantools/spell, proto/stop.
+
+ Cleanup: replaced documentation references to xxgdb by ddd.
+ The xxgdb program hasn't been updated in more than 10 years.
+ Files: proto/postconf.proto, conf/main.cf.
+
+20071219-20
+
+ Feature: support for all new Sendmail 8.14 Milter features
+ except SMFIR_SKIP (skip further events of this type),
+ SMFIP_RCPT_REJ (report rejected recipients to the mail
+ filter), SMFIR_CHGFROM (replace sender, with optional ESMTP
+ command parameters), and SMFIR_ADDRCPT_PAR (add recipient,
+ with optional ESMTP command parameters). Files: milter/milters.c,
+ milter/milter8.c, milter/test-milter.c, cleanup/cleanup_milter.c.
+
+20071221
+
+ Feature: support for Sendmail 8.14 Milter SMFIR_SKIP (skip
+ further events of this type). Files: milter/milter8.c,
+ milter/test-milter.c.
+
+ Cleanup: don't try sending HELO after a 421 EHLO reply.
+ File: smtp/smtp_proto.c.
+
+20071221-nonprod
+
+ Using 20071221 as reference point.
+
+ Cleanup: Simplified TLS library cipher and protocol API to
+ just pass string-valued properties to tls_client_init() and
+ tls_client_start(). The client is now agnostic of the
+ mechanics of cipher management internal to the library. The
+ main.cf parameters used internally in the library are now
+ loaded by the library, not the caller. Files:
+ src/smtp/lmtp_params.c, src/smtp/smtp.c, src/smtp/smtp.h,
+ src/smtp/smtp_params.c, src/smtp/smtp_proto.c,
+ src/smtp/smtp_session.c, src/smtpd/smtpd.c, src/tls/tls.h,
+ src/tls/tls_client.c, src/tls/tls_level.c, src/tls/tls_misc.c,
+ src/tls/tls_server.c, src/tls/tls_session.c, src/tls/tls_verify.c
+ and src/tlsmgr/tlsmgr.c
+
+ Cleanup: Client session lookup key "salting" is now handled
+ internally in the tls library. Files: src/tls/tls_client.c
+
+ Cleanup: Cipher state is cached, and only updated when
+ necessary. Files: src/tls/tls_misc.c
+
+ Feature: Extended the syntax of protocol selection to allow
+ exclusions as well as inclusions. Files: src/tls/tls_misc.c
+
+ Cleanup: Updated default verification depth to match reality:
+ default is 9 in OpenSSL and we don't yet override it. When
+ we do (soon), the default will match previous behavior.
+ Files: src/global/mail_params.h
+
+ Bugfix: Reference to obsolete "pfixtls" code won't compile
+ inside #ifdef for OpenSSL <= 0.9.5a. Using an OpenSSL release
+ that old has not been tested for some time, but may now
+ work. Files: src/tls/tls_bio_ops.c.
+
+ Replaced "void *" TLS library application handles by explicit
+ pointer types, while hiding data structure implementation
+ details from the TLS library users. Files: tls/tls_client.c,
+ tls/tls_server.c, smtp/smtp.c, smtpd/smtpd.c.
+
+ The TLS library no longer modifies VSTRINGs passed in by
+ the caller. Where possible, information is passed as "const"
+ from application to library. Files: smtp/smtp_proto.c,
+ tls/tls_client.c.
+
+20071227-nonprod
+
+ Replaced explicit initialization of props structures by
+ emulating function calls with named parameter lists. Files:
+ tls/tls.h, smtp/smtp.c, smtp/smtp_proto.c, smtpd/smtpd.c.
+
+20071222
+
+ Further polishing of the Milter code and logging. File:
+ milter/milter8.c.
+
+20071123
+
+ Further polishing of the Milter code. With SETSYMLIST, each
+ Milter can now update its own macros instead of clobbering
+ the global copy that is shared with other Milters. Also an
+ opportunity to clean up some ad-hoc code for sending macro
+ lists from smtpd(8) to cleanup(8). Files: milter/milter.c,
+ milter/milter8.c, milter/milter_macros.c.
+
+20071224
+
+ Further polishing of the Milter code. Eliminated unnecessary
+ steps from the initial smtpd/cleanup Milter handshake. Files:
+ milter/milter.c, milter/milter8.c, milter/milter_macros.c.
+
+ Cleanup: name_code(3) and name_mask(3) now support read-only
+ tables. Files: util/name_code.[hc], util/name_mask.[hc].
+
+20071227
+
+ Cleanup: further refinements of the Milter code, allowing
+ for multiple macro overrides. The code is now ready for
+ serious testing. File: milter/milter8.c.
+
+20071229
+
+ Bugfix: the Milter client did not replace the Postfix-specific
+ form for unknown host names by the Sendmail-specific form.
+ File: milter/milter8.c.
+
+ Cleanup: when a cleanup milter reports a problem don't log
+ generic "4.3.0 Sevice unavailable", but log the text for
+ the actual error. File: cleanup/cleanup_milter.c.
+
+20080102-nonprod
+
+ SMTP client fingerprint security level support and configurable
+ fingerprint digest algorithm. Victor Duchovni. Files:
+ smtp/lmtp_params.c, smtp/smtp.c, smtp/smtp.h,
+ src/smtp/smtp_params.c, src/smtp/smtp_proto.c,
+ src/smtp/smtp_session.c, tls/tls_client.c, tls/tls_level.c,
+ tls/tls_verify.c.
+
+20080103-nonprod
+
+ Missed "invalid TLS configuration" patch for SMTP client.
+ Victor Duchovni. File: smtp/smtp_proto.c.
+
+ SMTP server configurable fingerprint digest algorithm.
+ Victor Duchovni. Files: smtpd/smtpd.c, tls/tls.h,
+ tls/tls_server.c, tls/tls_verify.c.
+
+20080104-nonprod
+
+ Cleanup: finally implemented certificate verification depth
+ limit parameters. Prior to Postfix 2.5 these were ignored.
+ For backwards compatibility, the default verification depth
+ limit is now 9, the OpenSSL default. Victor Duchovni. Files:
+ src/tls/tls_client.c, src/tls/tls_server.c, src/tls/tls_verify.c.
+
+ Robustness: Avoid possibility of NULL pointer issues in
+ application code that checks certificate names, by providing
+ "empty string" values when no data is available. Victor
+ Duchovni. Files: src/tls/tls_verify.c, src/tls/tls_client.c,
+ src/tls/tls_server.c, src/smtpd/smtpd_check.c, src/smtpd/smtpd.c.
+
+ Cleanup: separation of TLS handshake from security level
+ enforcement. The library shakes hands; the application
+ decides if the resulting security is acceptable. Victor
+ Duchovni. Files: smtpd/smtpd.c, smtpd/smtpd_proto.c,
+ tls/tls_server.c, tls/tls_client.c, tls/tls_verify.c.
+
+ Robustness: more robust processing of ASN.1 string attributes
+ in x509v3 certificates, plus additional sanity checks (e.g.
+ embedded null characters). Victor Duchovni. File:
+ src/tls/tls_verify.c.
+
+20080104
+
+ Workaround: minor change to the Dovecot AUTH request to
+ prevent dovecot-auth memory wastage. Timo Sirainen. File:
+ xsasl/xsasl_dovecot_server.c.
+
+20080105-nonprod
+
+ Cleanup: renamed TLS-related symbols for consistency (always
+ include the init, start, stop prefix in the TLS library
+ function and data structure names; consistently distinguish
+ between per-application TLS state and per-session TLS state;
+ consistently use the fpt prefix for fingerprint related
+ variables and structure members; consistent use of monocase
+ typedef-ed names).
+
+20080106-nonprod
+
+ Cleanup: consistent use of and in examples;
+ instead of emphasizing new Postfix 2.5 behavior in reference
+ documentation, describe the new behavior as "current", with
+ historical behavior as a supplemental note.
+
+20080107
+
+ Feature: new "pass" service type (in addition to "inet",
+ "unix" and "fifo"). The "pass" service type supports
+ front-end daemons that accept all inbound connections and
+ that permit only well-behaved clients to talk to the MTA.
+ This service type had been sitting in the master daemon for
+ years but was disabled by default. Actual applications for
+ this will have to be developed later. Files: util/upass_connect.c,
+ util/upass_trigger.c.
+
+20080108
+
+ Cleanup: where possible, store data structures in read-only
+ memory. Besides the security advantage of no write access,
+ this also gives slightly better memory utilization when
+ many processes execute the same file. Files: pretty much
+ everything that has a static table, except for a few tables
+ in the benchmark tools with flags that are controlled by
+ command-line information.
+
+20080109
+
+ Cleanup: more read-only data. Files: everything that passes
+ around a HEADER_OPTS pointer.
+
+20080112
+
+ Safety: optional lookup table to prevent the Postfix SMTP
+ client from making repeated SASL login failures with the
+ same hostname, username and password. This introduces new
+ parameters: smtp_sasl_auth_cache_name, smtp_sasl_auth_cache_time.
+ Based on code by Keean Schupke. Files: smtp/smtp_sasl_glue.c,
+ smtp/smtp_sasl_auth_cache.c.
+
+ Safety: the Postfix SMTP client now by default defers mail
+ after the server rejects a SASL login attempt with a 535
+ status code. Specify "smtp_sasl_auth_soft_bounce = no" to
+ get the earlier behavior. Based on code by Keean Schupke.
+ Files: smtp/smtp_sasl_glue.c.
+
+20080114
+
+ Safety: the smtpd_client_new_tls_session_rate_limit setting
+ now also limits the number of failed TLS handshakes. This
+ limits the impact of broken configurations. File: smtpd/smtpd.c.
+
+20080115
+
+ Bugfix (introduced 20080112): Patrik Rak found two bugs
+ that largely canceled each other out, causing Postfix not
+ to complain about a missing "proxy:" prefix with the new
+ smtp_sasl_auth_cache_name parameter setting. File:
+ smtp/smtp_sasl_glue.c.
+
+ Documentation: new SOHO_README file for small/home offices.
+ The text is automatically generated from bits and pieces of
+ information that are scattered across other documents.
+ File: mantools/make_soho_readme.
+
+20080116
+
+ Bugfix (introduced 20080112): missing #ifdef for the SASL
+ login failure cache. File: smtp/smtp_sasl_auth_cache.h.
+
+20080123
+
+ Name fix: renamed the mumble_delivery_rate_delay parameter
+ to mumble_destination_rate_delay, because it really is a
+ per-destination feature. With this change we keep the option
+ of implementing a future per-transport rate delay.
+
+20080125
+
+ Bugfix (introduced 20071216): missing {} in the LDAP client
+ broke OpenLDAP TLS. The setting tls_require_cert=no was
+ further broken because Postfix used OpenLDAP incorrectly.
+ Victor Duchovni. This broke tls_require_cert=no File:
+ global/dict_ldap.c.
+
+20080126
+
+ Cleanup: the post-install script now requires that it is
+ invoked via the postfix(1) command. This was the intended
+ use since Postfix 2.1, but it was never enforced. The
+ documentation for package maintainers has been updated
+ accordingly. File: conf/post-install.
+
+20080130
+
+ Bugfix (introduced 20071204): wrong proxywrite process limit
+ in the default master.cf file. File: conf/master.cf.
+
+20080131
+
+ Bugfix (introduced 20080126): the new "do not execute
+ directly" test in post-install got broken during code
+ cleanup. File: conf/post-install.
+
+20080201
+
+ Workaround: undo the changes that require that post-install
+ is invoked via the postfix command, because this breaks
+ when "postfix start" is invoked with an obsolete postfix
+ command that doesn't export the new data_directory parameter.
+
+ Workaround: pick up a missing data_directory setting from
+ main.cf when "postfix start" is invoked with an obsolete
+ postfix command. File: conf/post-install.
+
+20080207
+
+ Cleanup: soft_bounce support for multi-line Milter replies.
+ File: src/milter/milter8.c.
+
+ Cleanup: preserve multi-line format of header/body Milter
+ replies. Files: cleanup/cleanup_milter.c, smtpd/smtpd.c.
+
+ Cleanup: multi-line support in SMTP server replies. File:
+ smtpd/smtpd_chat.c.
+
+ SAFETY: postfix-script, postfix-files and post-install are
+ moved away from /etc/postfix to $daemon_directory. There
+ were too many accidents where people clobbered these files
+ with versions from an older Postfix release and ended up
+ with an unusable Postfix setup. Files: postfix-install,
+ Makefile.in, postfix/postfix.c, conf/postfix-files,
+ conf/postfix-script, conf/post-install.
+
+20080212
+
+ Feature: check_reverse_client_hostname_access, to make
+ access decisions based on the unverified client hostname.
+ For safety reasons an OK result is not allowed. Noel Jones.
+ Files: smtpd/smtpd_check.c plus header files and documentation.
+
+20080215
+
+ Safety: break SASL loop in case both the SASL library and
+ the remote SMTP server are confused. File: smtp/smtp_sasl_glue.c.
+
+20080220
+
+ Safety: the master daemon now sets an exclusive lock on a
+ file $data_directory/master.lock, so that the data directory
+ can't be shared between multiple Postfix instances. This
+ would corrupt files that rely on single-writer updates
+ (examples: verify(8) cache, tlsmgr(8) caches, etc.). File:
+ master/master.c.
+
+20080226
+
+ Cleanup: the postfix command did not set argv[0] to a sane
+ value when invoking postfix-script. Reported by Victor
+ Duchovni. File: postfix/postfix.c.
+
+20080228
+
+ Bugfix: bounce(8) segfault on one-line template text.
+ Problem found by Sacha Chlytor. File: bounce/bounce_template.c.
+
+20080310
+
+ Safety: the SMTP server's Dovecot authentication client now
+ enforces the SASL mechanism output filter also on client
+ command input. File: src/xsasl/xsasl_dovecot_server.c.
+
+20080311
+
+ Bugfix (introduced 20070811): the MAIL and RCPT Milter
+ application call-backs no longer received {mail_addr} or
+ {rcpt_addr} information. Problem reported by Anton Yuzhaninov.
+ File: smtpd/smtpd.c.
+
+ Bugfix (introduced 20080207): "cleanup -v" panic because
+ the new "SMTP reply" request flag did not have a printable
+ name. File: global/cleanup_strflags.c.
+
+20080318
+
+ Human factors: the PCRE and regexp maps now give more
+ comprehensible error messages when people make the common
+ mistake of indenting if/endif blocks. Files: util/dict_pcre.c,
+ util/dict_regexp.c.
+
+20080324
+
+ Cleanup: the event_drain() function is now a proper event
+ processing loop. File: util/events.c
+
+ Feature: when the "postmap -q -" command reads lookup keys
+ from standard input, it now understands RFC822 and MIME
+ message format. Specify -h or -b to use headers or body
+ lines as lookup keys, and specify -hm or -bm to simulate
+ header_checks or body_checks. The postmap -h option (without
+ -m) will be compatible with a future postcat -h option.
+ File: postmap/postmap.c.
+
+20080411
+
+ Bugfix (introduced Postfix 2.0): after "warn_if_reject
+ reject_unlisted_recipient/sender", the SMTP server mistakenly
+ remembered that recipient/sender validation was already
+ done. File: smtpd/smtpd_check.c.
+
+ Bugfix (introduced Postfix 2.3): the queue manager would
+ initialize missing client logging attributes (from xforward)
+ with real client attributes. Fix: enable this backwards
+ compatibility feature only with queue files that don't
+ contain logging attributes. Problem reported by Liviu Daia.
+ Files *qmgr/qmgr_message.c.
+
+20080424
+
+ Cleanup: some warning messages said "regexp" or "regexp
+ map" instead of "pcre map". File: util/dict_pcre.c.
+
+20080426
+
+ Feature: finer control over address verification error
+ handling and amount of information disclosed in the SMTP
+ reject message. Parameters: unverified_recipient_defer_code,
+ unverified_recipient_reject_reason, unverified_sender_defer_code,
+ unverified_sender_reject_reason. If I don't do this properly,
+ then someone will do it anyway. File: src/smtpd/smtpd_check.c.
+
+20080428
+
+ Cleanup: the proxy_read_maps (Postfix 2.0) default setting
+ was not updated when adding sender/recipient_bcc_maps
+ (Postfix 2.1) and smtp/lmtp_generic_maps (Postfix 2.3).
+ File: global/mail_params.h.
+
+ Cleanup: the SMTP server's XFORWARD and XCLIENT support was
+ not updated when the smtpd_client_port_logging configuration
+ parameter was added. Code by Victor Duchovni. Files:
+ smtpd/smtpd.c, smtpd/smtpd_peer.c.
+
+20080508
+
+ Cleanup: delivery status notifications now prepend a
+ Return-Path: message header to the returned message.
+ File: bounce/bounce_notify_util.c.
+
+20080509
+
+ Bugfix: null-terminate CN comment string after sanitization.
+ File: smtpd/smtpd.c.
+
+20080510
+
+ Cleanup: when extracting peer and issuer common name from
+ TLS certificates, convert the result into UTF-8, and use
+ RFC 2047 encoding when logging these as Received: header
+ comment fields. Based remotely on code by Victor Duchovni.
+ Files: smtpd/smtpd.c, tls/tls_verify.c.
+
+20080511
+
+ Cleanup: the RFC 2047 encoding of RFC*822 comments is too
+ problematic. The text that explains the problems is as
+ long as the code itself. That is usually a good indication
+ that code is not ready for use. File: smtpd/smtpd.c.
+
+ Cleanup: block non-printable ASCII text in UTF8 encoded TLS
+ peer and issuer common names. File: tls/tls_verify.c.
+
+20080602
+
+ Workaround: avoid watchdog timeout in the local pickup
+ daemon when the cleanup server expands a very large virtual
+ alias list. Files: master/trigger_server.c, pickup/pickup.c.
+
+20080603
+
+ Workaround: avoid "bad address pattern" errors with non-address
+ patterns in namadr_list_match() calls. File: util/match_ops.c.
+
+ Feature: print fsstone elapsed time with sub-second time
+ resolution. Kenji Kikuchi. File: fsstone/fsstone.c.
+
+20080606
+
+ Bitrot: "make test" was broken due to recent changes in
+ code and due to recent changes at mail-abuse.org.
+
+20080618
+
+ Add a note to SMTP session transcript email messages that
+ other details may be found in the maillog file. Files:
+ smtpd/smtpd_chat.c, smtp/smtp_chat.c.
+
+20080620
+
+ Cleanup: with the "Before-queue content filter", RFC3848
+ information was not added to the headers. Carlos Velasco.
+ File smtpd/smtpd.c.
+
+20080621
+
+ Cleanup: include unread byte count in the SMTP server's "lost
+ connection after DATA (xx bytes)" logging. Files: smtpd/smtpd.c.
+
+20080629
+
+ Bugfix (introduced Postfix 2.2): multiple inconsistencies
+ in SASL support after introduction of TLS. The Postfix
+ SMTP server 1) complained about plain-text SASL configuration
+ details when SASL was forbidden for plain-text sessions,
+ and 2) ignored the smtpd_tls_auth_only parameter setting
+ when built without TLS support. Files: smtpd/smtpd.c,
+ smtpd/smtpd_check.c, smtpd/smtpd_sasl_glue.[hc],
+ smtpd/smtpd_state.c.
+
+ Some clarification about recipient address versus domain,
+ and recipients per message versus session. File:
+ proto/postconf.proto.
+
+ The description of SASL authentication attributes was
+ garbled. File: pipe/pipe.c.
+
+ Information: the master(8) server now logs the version
+ besides the configuration directory upon "postfix reload".
+ File: master/master.c.
+
+20080717
+
+ Cleanup: a poorly-implemented integer overflow check for
+ TCP MSS calculation had the unexpected effect that people
+ broke Postfix on LP64 systems while attempting to silence
+ a compiler warning. File: util/vstream_tweak.c.
+
+20080721
+
+ The cleanup server now rejects undisclosed_recipients_header
+ parameter values with invalid message header syntax.
+ File: cleanup/cleanup_message.c.
+
+20080725
+
+ Paranoia: defer delivery when a mailbox file is not owned
+ by the recipient. Sebastian Krahmer, SuSE. Files:
+ local/mailbox.c, virtual/mailbox.c.
+
+20080804
+
+ Bugfix: dangling pointer in vstring_sprintf_prepend().
+ File: util/vstring.c.
+
+20080814
+
+ Security: some systems have changed their link() semantics,
+ and will hardlink a symlink, contrary to POSIX and XPG4.
+ Sebastian Krahmer, SuSE. File: util/safe_open.c.
+
+ The solution introduces the following incompatible change:
+ when the target of mail delivery is a symlink, the parent
+ directory of that symlink must now be writable by root only
+ (in addition to the already existing requirement that the
+ symlink itself is owned by root). This change will break
+ legitimate configurations that deliver mail to a symbolic
+ link in a directory with less restrictive permissions.
+
+20080815
+
+ Feature: the milter_default_action parameter now accepts
+ the "quarantine" action. This works like "accept" but also
+ freezes the mail in the "hold" queue. File: milter/milter8.c.
+
+ Robustness: transition from setjmp()/longjmp() to the signal
+ mask saving/restoring versions sigsetjmp()/siglongjmp().
+ These functions have been around for 15 years, but they
+ have had bugs on supported platforms, so makedefs tests for
+ them. Files: makedefs, util/sys_defs.h, util/vstream.h.
+
+20080822
+
+ Cleanup: the proxymap_service_name and proxywrite_service_name
+ parameters make the proxymap service names configurable.
+ This paves the way for a future option where the proxymap
+ services are accessible via TCP so that they can be shared
+ among multiple Postfix hosts. File: global/dict_proxy.c.
+
+ Feature: MacOS X support for kqueue style event handling,
+ with workaround for broken MacOS X versions. Files:
+ util/sys_defs.h, makedefs.
+
+ Cleanup: the makedefs script now keeps its test programs
+ in a directory makedefs.d, instead of inlining them as
+ fragile "here documents". Files: makedefs, makedefs.d/*.
+
+20080823
+
+ Feature: IPv6 dns blocklist lookup. File: smtpd/smtpd_check.c.
+
+20080824
+
+ Cleanup: untangled the MacOS X version dependent sections
+ in the makedefs script, to make future updates easier. File:
+ makedefs.
+
+ Cleanup: don't log multiple Milter "hold" actions for the
+ same email message. File: cleanup/cleanup_milter.c.
+
+20080826
+
+ Cleanup: moving test programs from makedefs into a makedefs.d
+ directory brought more pain than gain.
+
+ Cleanup: untangled the Linux version dependent sections in
+ the makedefs script, to make future updates easier. File:
+ makedefs.
+
+ Documentation: MacOS process limit configuration by Quanah
+ Gibson-Mount. File: proto/TUNING_README.html.
+
+ Feature: smtp-sink -M option to terminate after receiving
+ a specified number of messages. Laurent Gentil. File:
+ smtpstone/smtp-sink.c.
+
+ Bugfix (introduced Postfix 2.4): epoll file descriptor leak.
+ With Postfix >= 2.4 on Linux >= 2.6, Postfix has an epoll
+ file descriptor leak when it executes non-Postfix commands
+ in, for example, user-controlled $HOME/.forward files. A
+ local user can access a leaked epoll file descriptor to
+ implement a denial of service attack on Postfix. Data
+ confidentiality and integrity are not affected. File:
+ util/events.c.
+
+20080903
+
+ Don't enable kqueue (which requires poll) support on
+ MacOS X. File: makedefs.
+
+ Cleanup: remove obsolete Rhapsody and MacOS targets from
+ makedefs.
+
+20080929
+
+ Workaround: don't log "file has 2 links" warnings when the
+ condition appears to be temporary. As kernels have evolved
+ from non-interruptible system calls towards fine-grained
+ locks, the showq command has become likely to observe a
+ file while the queue manager is in the middle of a rename
+ operation, when the file has links to both the old and new
+ name. File: global/mail_open_ok.c.
+
+ Workaround: don't loop forever when write() fails with a
+ persistent EAGAIN error on a writable file descriptor.
+ File: util/write_buf.c.
+
+20081003
+
+ Bugfix (introduced Postfix 2.1): when XFORWARD support was
+ introduced with Postfix 2.1, the specification failed to
+ clearly distinguish between missing and non-existent client
+ information. This ambiguity affected the implementation:
+ in $name expansions by delivery agents, unknown client
+ hostnames could became empty strings (as if a submission
+ was local), and local submissions could appear to originate
+ from an SMTP-based content filter. This was fixed with a
+ a minor semantic change to the XFORWARD protocol. Files:
+ smtpd/smtpd.c, qmqpd/qmqpd.c, smtp/smtp_proto.c,
+ cleanup/cleanup_envelope.c, proto/XFORWARD.html. Note: the
+ changes to propagate local submission details were undone
+ 20082012.
+
+ Feature: a DUNNO lookup result in per_sender_relayhost_maps
+ stops the search without replacing the next-hop destination.
+ File: trivial-rewrite/resolve.c.
+
+20081005
+
+ Bugfix: further refinements to the handling of missing or
+ non-existent remote client attributes. Files: smtpd/smtpd.c,
+ smtpd/smtpd.h.
+
+ Documentation: the XFORWARD specification of the ADDR
+ attribute did not agree with the actual on-the-wire protocol.
+ Since we can't change already existing deployments, the
+ spec has been updated. File: proto/XFORWARD_README.html.
+
+20081006
+
+ Bugfix: further refinements to the handling of remote client
+ attributes. Introduced a dummy "we have forwarded client
+ info" record, to eliminate the need for the backwards
+ incompatible queue file change that was introduced 20081003.
+ Files: smtpd/smtpd.c, cleanup/cleanup_envelope.c,
+ *qmgr/qmgr_message.c.
+
+ Security: hardened the proxymap client, in case it ever
+ ends up in a set-gid program. File: global/dict_proxy.c.
+
+20081007
+
+ Workaround: undo the proxymap client change. It broke
+ chrooted servers when they attempted to reconnect to the
+ proxy read/write service. File: global/dict_proxy.c.
+
+20081008
+
+ Safety: added checks that $queue_directory/pid is owned by
+ root, and that $queue_directory/saved is owned by $mail_owner.
+ File: conf/postfix-script.
+
+20081010
+
+ Feature: controls for opportunistic TLS protocols and
+ ciphers. The smtp_tls_protocols, smtp_tls_ciphers, and
+ equivalent parameters for lmtp and smtpd provide global
+ settings; the SMTP client TLS policy table provides ciphers
+ and protocols settings for specific peers. Code by Victor
+ Duchovni. Files: smtp/smtp.c, smtp/smtp_session.c, smtpd/smtpd.c
+ and documentation.
+
+20081012
+
+ Cleanup: simplify the 20081003 changes and don't try to
+ propagate local submission information through XFORWARD.
+ Files: smtpd/smtpd.c, qmqpd/qmqpd.c, smtp/smtp_proto.c,
+ cleanup/cleanup_envelope.c, proto/XFORWARD.html.
+
+20081015
+
+ Bugfix: GLIBC API version detection. Rob Foehl. File:
+ util/sys_defs.h.
+
+20081022
+
+ Documentation: removed inapplicable daemon_timeout reference
+ from qmgr(8), oqmgr(8), pickup(8). These daemons need to
+ use a much shorter watchdog timer.
+
+20081108
+
+ Feature: smtp_sasl_tls_verified_security_options is no
+ longer #ifdef SNAPSHOT.
+
+ Feature: elliptic curve support. This requires OpenSSL
+ version 0.9.9 or later. Victor Duchovni. Files: TLS_README,
+ smtpd/smtpd.c, smtp/smtp.c, tls/tls_dh.c, tls/tls_certkey.c,
+ tls/tls_server.c, tls/tls_client.c, tls/tls.h, tls/tls_misc.c.
+
+ Bugfix (introduced Postfix 2.5): the Postfix SMTP server
+ did not ask for a client certificate with "smtpd_tls_req_ccert
+ = yes". Reported by Rob Foehl. File: smtpd/smtpd.c.
+
+20081109
+
+ Cleanup: confusing names of variables. File: smtpd/smtpd.c.
+
+20081126
+
+ Documentation: pcre_table(5) incorrectly claimed that the
+ 'x' flag supports #comment after text. File: proto/pcre_table.
+
+20081202
+
+ Cleanup: vstream_bufstat() provides a more systematic
+ approach to get information about VSTREAM buffers. The
+ vstream_peek() function is now a backwards compatibility
+ wrapper. Files: util/vstream.[hc].
+
+ Cleanup: the SMTP server should warn about "lost connection
+ after QUIT" only when the "." reply was pipelined together
+ with the "QUIT" reply. File: smtpd/smtpd.c.
+
+ Cleanup: the SMTP client's code was duplicating buffer
+ management that was already done in the VSTREAM module.
+ File: smtp/smtp_proto.c.
+
+20081203
+
+ Cleanup: adjust the VSTREAM buffer strategy when reusing
+ an SMTP connection with a large TCP MSS value. File:
+ smtp/smtp_reuse.c.
+
+20081204
+
+ Cleanup: state the SMTP client PIPELINING implementation's
+ dependency on monotonic VSTREAM buffer size behavior, and
+ add some checks for boundary cases with VSTREAM buffer size
+ change requests. Files: util/vstream.c, smtp/smtp_proto.c.
+
+20081205
+
+ Fix 20081202 flush code. Victor Duchovni. File: smtpd/smtpd.c.
+
+ Safety: add another check to "postfix check", in this case
+ for group or other writable queue_directory. File:
+ conf/postfix-script.
+
+20081217
+
+ Debugging: ad-hoc code to log the TLS error stack after
+ VSTREAM read/write error. File: tls/tls_bio_ops.c. In a
+ better implementation, each I/O "object" would provide an
+ optional error reporting method (besides timed_read and
+ timed_write) that could be queried via the vstream module.
+
+20081222
+
+ Documentation: log the "*" pattern as the last transport
+ map lookup. File: proto/transport.
+
+20090103
+
+ Documentation: rewrote NFS_README, to clarify the support
+ status of Postfix and NFS, and to describe the NFS workarounds
+ that Postfix actually implements.
+
+20090106
+
+ Feature: "postconf -# parametername ..." to comment out
+ named parameter entries. Victor Duchovni. File:
+ postconf/postconf.c.
+
+20090107
+
+ Library: edit_file(3) module for cooperative editing of a
+ file. Inspired by the postconf command, this creates a new
+ version under a deterministic temporary name and renames
+ it into place. The implementation uses an open/lock/stat
+ protocol before updating the new file, and rename/unlock/close
+ afterwards. Based on pieces of code by Victor Duchovni,
+ with minor improvements by Wietse. Files: util/edit_file.[hc].
+
+ Cleanup: the postconf command now uses the edit_file(3)
+ module to manage collisions when multiple processes attempt
+ to update the main.cf file.
+
+20090108
+
+ Feature: master_service_disable parameter (default: empty)
+ to easily turn off/on master.cf services by type or by name
+ and type. For example, to turn off the main SMTP listener
+ use "master_service_disable = smtp.inet", and to turn off
+ all TCP/IP listeners use "master_service_disable = inet".
+ This immediately terminates all processes that provide the
+ specified services. The master_service_disable feature does
+ not distinguish services by their privacy property; some
+ day, clients will not need to specify that anymore. Files:
+ global/mail_params.h, master/master.c, master/master_vars.c,
+ master/master_ent.c.
+
+ Bugfix (introduced May 19, 1997): removing a parameter
+ setting from main.cf did not reset the parameter to its
+ default value. This was a problem only in the master daemon.
+ File: global/mail_conf.c, master/master_vars.c.
+
+20090109
+
+ Cleanup: "defer" action in access maps, and a corresponding
+ access_map_defer_code parameter. No idea what was behind
+ this omission. Files: global/mail_params.h, smtpd/smtpd.c,
+ smtpd/smtpd_check.c, proto/access.
+
+ Workaround: specify "tcp_windowsize = 65535" (or less) to
+ work around broken TCP window scaling implementations. This
+ is perhaps easier than collecting tcpdump output and tuning
+ kernel parameters by hand. See RELEASE_NOTES for how to
+ change this setting without stopping Postfix. Files:
+ util/inet_connect.c, inet_listen.c, global/mail_params.[hc].
+
+20090110
+
+ Cleanup: create separate code modules for TCP window size
+ handling, master.cf service name matching, and main.cf
+ change monitoring. Files: util/inet_windowsize.c,
+ global/match_service.c, master/master_watch.c.
+
+ Feature: TCP window size override for the Postfix SMTP/LMTP
+ client, and for the smtp-source and smtp-sink test programs.
+ Files: smtp/smtp_connect.c, smtpstone/smtp-source.c,
+ smtpstone/smtp-sink.c.
+
+20090114
+
+ Bugfix: VERP now uses the Postfix original recipient, if
+ available, because that is what the VERP consumer expects.
+ Files: *qmgr/qmgr_deliver.c, bounce/bounce_notify_verp.c.
+
+ Safety: extra check for broken third-party patches that
+ allow file size limit < message size limit. This can cause
+ mail to be stuck in the queue forever.
+
+ Invisible change, in preparation for multi-instance support.
+ Except for main.cf and master.cf, all files are optional
+ for non-default Postfix configuration directories. File:
+ conf/postfix-files.
+
+20090115
+
+ Cleanup: rewrote the 20090114 VERP bugfix, to replace code
+ that "works" by code that is "right". Files: *qmgr/qmgr_deliver.c,
+ bounce/bounce_notify_verp.c, global/verp_sender.c.
+
+20090118
+
+ Documentation: some URLs to enable/disable client-side TLS
+ jumped into the middle of an enumeration. File:
+ proto/TLS_README.html.
+
+20090119-21
+
+ Feature: multi-instance manager plug-in API. A sample
+ multi-instance manager with instructions is available as
+ $daemon_directory/postfix-wrapper. The plug-in API itself
+ is described in postfix-wrapper(5). Files: postfix/postfix.c,
+ global/mail_params.[hc], proto/postfix-wrapper,
+ conf/postfix-wrapper, conf/postfix-script, conf/postfix-files.
+
+ Support to check/update shared files only in the context
+ of the default Postfix instance. Files: conf/post-install,
+ conf/postfix-script.
+
+20090122
+
+ Refinements: the multi-instance manager always replaces
+ "start" by "check" when a Postfix instance is multi-instance
+ disabled, so that problems will still be reported; polish
+ documentation; delete unnecessary multi_instance_order
+ parameter. Files: conf/postfix-wrapper, proto/postfix-wrapper,
+ global/mail_params.[hc] and documentation.
+
+ Bugfix: the data_directory was not automatically created!
+ File: conf/postfix-files.
+
+20090123
+
+ More little fixes in the "trivial but useful" postfix-wrapper
+ including instructions. It's ready for testing in the field.
+ File: conf/postfix-wrapper.
+
+20090125
+
+ Documentation: more precise description of multi-instance
+ manager API, and minor edits of the example program. Files:
+ conf/postfix-wrapper, proto/postfix-wrapper.
+
+20090208
+
+ Cleanup: enable multi-instance shared-file logic only when
+ the instance is listed in multi_instance_directories. Files:
+ conf/post-install, conf/postfix-script.
+
+20090210
+
+ Feature: specify "reject_tempfail_action = defer" to
+ immediately defer a remote SMTP client request after a
+ reject-type restriction fails with a temporary error. Based
+ on code by Rob Foehl. File: smtpd/smtpd_check.c.
+
+ Feature: finer control of reject_tempfail_action with
+ unknown_address_tempfail_action, unverified_sender_tempfail_action
+ unverified_recipient_tempfail_action, and
+ unknown_helo_hostname_tempfail_action. See documentation
+ for details. File: smtpd/smtpd_check.c.
+
+20090211
+
+ Workaround: pass the SMTP server socket's local and remote
+ peer address information to the Dovecot authentication server.
+ This is incomplete code: it ignores XCLIENT server address
+ overrides. File: xsasl/xsasl_dovecot_server.c.
+
+20090212
+
+ Testing revealed that with mumble_tempfail_action=defer,
+ the "defer" action was ignored. Cause: the DEFER_IF_PERMIT[0-9]
+ macros lost the SMTPD_CHECK_REJECT result value. File:
+ smtpd/smtpd_check.c.
+
+ Feature: stress-dependent smtpd_timeout (normal: 300s,
+ overload: 10s), smtpd_hard_error_limit (normal: 20, overload:
+ 1) and smtpd_junk_command_limit (normal: 100, overload: 1).
+ Files: global/mail_params.h, global/mail_conf_nint.c,
+ master/*_server.c, smtpd/smtpd.c.
+
+20090213
+
+ Fine tuning: don't enforce smtpd_junk_command_limit for
+ XCLIENT and XFORWARD commands. These commands can be issued
+ only by authorized clients. File: src/smtpd/smtpd.c.
+
+20090215
+
+ Feature: the Postfix SMTP server hangs up after replying
+ with "521". This makes overload handling more effective.
+ See also RFC 1846. File: smtpd/smtpd.c.
+
+ Feature: postmulti mult-instance manager command, very
+ lightly tested. The MULTI_INSTANCE_README still needs to
+ be proofread. Originally by Victor Duchovni. Files:
+ src/postmulti/*, proto/MULTI_INSTANCE_README.html,
+ conf/postmulti-script.
+
+20090216-24
+
+ Cleanup: assorted code cleanups in postmulti. File:
+ src/postmulti/postmulti.c.
+
+20090223
+
+ Cleanup: multiple instances of the same global. Files:
+ util/inet_windowsize.c, util/inet_listen.c.
+
+20090228
+
+ Cleanup: the Postfix SMTP server now maintains a per-session
+ "improper command pipelining detected" flag. This flag can
+ be tested at any time with reject_unauth_pipelining, and
+ is raised whenever a client command is followed by unexpected
+ commands or message content. Files: smtpd/smtpd.c,
+ smtpd/smtpd_check.c.
+
+ Logging: the Postfix SMTP server now logs the first command
+ pipelining transgression as "improper command pipelining
+ after from []".
+
+ Cleanup: after DATA command failure, log "(approximately
+ XX bytes)" only if Postfix actually accepted the DATA
+ command. File: smtpd/smtpd.c.
+
+20090303
+
+ Cleanup: word smithing of "sendmail -bv" probe message.
+ File: sendmail/sendmail.c.
+
+ Cleanup: OpenLDAP now provides a sane solution for conflicts
+ with PAM ldap-over-tls. Victor Duchovni. File: global/dict_ldap.c.
+
+20090304
+
+ Cleanup: skip over suspended or throttled queues while
+ looking for delivery requests. File: *qmgr/qmgr_transport.c.
+
+20090305
+
+ Bugfix: in the "new queue manager", the _destination_rate_delay
+ code needed to postpone the job scheduler updates after
+ delivery completion, otherwise the scheduler could loop on
+ blocked jobs. Victor & Wietse. File: qmgr/qmgr_entry.c,
+ qmgr/qmgr_queue.c, qmgr/qmgr_job.c.
+
+ Cleanup: report a "queue file write error", instead of
+ passing though bogus 2xx replies from proxy filters to SMTP
+ clients. File: smtpd/smtpd_proxy.c.
+
+20090307
+
+ Cleanup: with "lmtp_assume_final = yes", the Postfix LMTP
+ delivery agent assumes that delivery is final when talking
+ to an LMTP server that announces no DSN support. Otherwise,
+ the Postfix LMTP delivery agent assumes that delivery is
+ "relayed", to maintain compatibility with simple LMTP-based
+ content filters. Based on code by Michel Sebastien, ATOS
+ Origin. File: smtp/smtp_rcpt.c.
+
+20090310
+
+ Bugfix: Postfix used mumble_concurrency_failed_cohort_limit
+ instead of mumble_destination_concurrency_failed_cohort_limit
+ as documented. File: global/mail_params.h.
+
+20090330
+
+ Cleanup: add (Resent-) From:, Date:, Message-ID: or To:
+ headers only when clients match $local_header_rewrite_clients.
+ Specify "always_add_missing_headers = yes" for backwards
+ compatibility. Adding such headers to remote mail can break
+ DKIM signatures that cover headers that are not present.
+ File: cleanup/cleanup_message.c.
+
+20090415
+
+ Workaround: to avoid unnecessary "fatal" delivery agent
+ exits, delivery agents retry getting a shared lock on a
+ queue file. This is necessary since the queue manager's
+ behavior was changed years ago to refill the in-memory
+ recipient list before it was completely empty. File:
+ global/deliver_request.c.
+
+ Documentation: updated STRESS_README.
+
+20090416
+
+ Workaround: some AWK implementations have a limit of 10
+ output files and lack a working close() function. It is too
+ much trouble to find out what systems have this limitation,
+ and where, if any, such systems store their XPG4-compatible
+ AWK program. So instead we generate a stream of here
+ documents and let the shell split the stream into files.
+ File: postconf/extract.awk.
+
+ Documentation: clarification of certificate file usage.
+ Victor Duchovni. Files: proto/postconf.proto,
+ proto/TLS_README.html.
+
+ Feature: pass a "TLS is active" flag to the server-side
+ SASL support. Based on code by Timo Sirainen, except that
+ the implementation uses an extensible API so that it will
+ be less painful to add more attributes in future Postfix
+ versions. Files: xsasl/xsasl.h, xsasl/xsasl_*server.c,
+ smtpd/smtpd_sasl_glue.c.
+
+20090417
+
+ Documentation: re-generate READMEs and manpages for updated
+ hyperlinks.
+
+ Documentation: missing hyperlinks and missing parameters
+ in manpages. File: mantools/postlink, mantools/check-postlink.
+
+20090418
+
+ Cleanup: use the extensible API to pass SMTP client address
+ information to the dovecot SASL plugin, and prepare for
+ passing server address information. Files: xsasl/xsasl.h,
+ xsasl/xsasl_dovecot_server.c, smtpd/smtpd_sasl_glue.c.
+
+ Same extensible API transformation for the SASL client-side
+ code to make future extensions less painful. Files:
+ xsasl/xsasl.h, xsasl/xsasl*client.c, smtp/smtp_sasl_glue.c.
+
+ More postlink fixes. File: mantools/postlink.
+
+20090419
+
+ Bugfix: don't re-enable SIGHUP if it is ignored in the
+ parent. This may cause random "Postfix integrity check
+ failed" errors at boot time (POSIX SIGHUP death), causing
+ Postfix not to start. We duplicate code from postdrop and
+ thus avoid past mistakes. File: postsuper/postsuper.c.
+
+ Robustness: don't re-enable SIGTERM if it is ignored in the
+ parent. Files: postsuper/postsuper.c, postdrop/postdrop.c.
+
+20090422
+
+ Undo delivery agent change 20090415. The queue manager never
+ locks a queue file to read additional recipients into memory,
+ so if a delivery agent runs into a locked file, then something
+ is seriously wrong. File: global/deliver_request.c.
+
+20090424
+
+ Compatibility: the Postfix SMTP client no longer uses the
+ obsolete SSLv2 by default for opportunistic encryption.
+ This has nothing to do with security (we're willing to send
+ plaintext over an unauthenticated connection) but with the
+ loss of advanced options that give better performance.
+ Victor Duchovni. Files: proto/postconf.proto, global/mail_params.h.
+
+20090426
+
+ Feature: more accurate support for Milter macros {mail_addr}
+ and {rcpt_addr}, and new support for Milter macros {mail_host},
+ {mail_mailer}, {rcpt_host}, and {rcpt_mailer}. Files:
+ milter/milter.[hc], smtpd/smtpd.[hc], smtpd/smtpd_milter.c,
+ smtpd/smtpd_resolve.c.
+
+ Feature: support to report rejected recipients to Milters
+ (SMFIP_RCPT_REJ). Postfix reports the event as decribed in
+ Sendmail 8.14.0 documentation: {rcpt_mailer} = "error",
+ {rcpt_host} = enhanced status code (e.g., "5.7.1"), and
+ {rcpt_addr} = reason to reject (e.g., "Relay access denied").
+ Files: milter/milter.[hc], milter/milter8.c, smtpd/smtpd.[hc],
+ smtpd/smtpd_milter.c.
+
+20090427
+
+ Feature: Milter support for replacing the envelope sender
+ and adding recipients (SMFIR_CHGFROM, SMFIR_ADDRCPT_PAR).
+ This support currently ignores ESMTP command parameters.
+ Files: milter/milter8.c, cleanup/cleanup_milter.c.
+
+20090428
+
+ Compatibility: to make all the new Milter features usable,
+ raise the default milter_protocol setting from 2 to 6.
+ This has been tested with a Sendmail 8.14 libmilter.
+ File: global/mail_params.h.
+
+ Bugfix: don't disable MIME parsing with smtp_header_checks,
+ smtp_mime_header_checks, smtp_nested_header_checks or with
+ smtp_body_checks. Bug reported by Victor. File: smtp/smtp_proto.c.
+
+ Code cleanups: respect VSTRING invariants by using VSTRING_RESET
+ and VSTRING_TERMINATE instead of directly groping the
+ underlying character buffer. Files: global/dsn_buf.c,
+ milter/milter8.c.
+
+20090507
+
+ main.cf:tls_random_source now defaults to /dev/arandom on
+ OpenBSD. This device was introduced before Postfix development
+ began. Files: util/sys_defs.h, global/mail_params.h.
+
+20090510
+
+ Code cleanups: while emulating SMTP client requests for
+ Milter applications, use user@domain form addresses as
+ required by the SMTP protocol, instead of bare usernames.
+ This avoids hard to debug errors from some Milter applications.
+ Files: cleanup/cleanup_envelope.c, cleanup/cleanup_extracted.c,
+ cleanup/cleanup_addr.c.
+
+20090511
+
+ Code cleanups: don't clobber -o command-line arguments so
+ that Linux people can debug daemon command lines more easily.
+ Files: master/*server.c.
+
+20090513
+
+ Code cleanups: better parsing of Postfix daemon "-o"
+ command-line options, with better error handling. Files:
+ master/*server.c.
+
+20090518
+
+ Documentation: missing dummy entries for lmtp_mumble_checks.
+ File: proto/postconf.proto.
+
+20090519
+
+ Bugfix (introduced: Postfix 2.3, but did not cause trouble
+ until 20090427). Queue file corruption with (smtpd_milters
+ or non_smtpd_milters) enabled, AND with delay_warning_time
+ enabled, AND with short envelope sender addresses (e.g.,
+ local submissions with bare usernames, but not bounces).
+ The queue file would be corrupted when the delay_warning_time
+ record was marked as "done" after sending the "your mail
+ is delayed" notice. File: qmgr/qmgr_message.c.
+
+20090522
+
+ Bugfix (introduced: Postfix 2.3). The cleanup server
+ rejected mail with records of type REC_TYPE_DRCP (recipient
+ deleted by Milter), but such records could be present in
+ mail re-submitted with "postsuper -r". Found during code
+ review. Files: global/record.h, cleanup/cleanup_envelope.c.
+
+20090524
+
+ Feature: new postcat options: -e (print envelope), -h (print
+ header), and -b (print body). Specify "postcat -bh" to
+ suppress information about envelope records, and "postcat
+ -h" to get the message header only. With large messages,
+ "postcat -h" is much faster than manually stripping the
+ message body from the output. File: postcat/postcat.c.
+
+20090528
+
+ Bugfix (introduced: Postfix 2.6 change 20080629): with
+ plaintext sessions, smtpd_tls_auth_only=yes caused spurious
+ warnings with reject_authenticated_sender_login_mismatch,
+ and broke reject_unauthenticated_sender_login_mismatch and
+ reject_sender_login_mismatch. Based on fix by Victor
+ Duchovni. File: smtpd/smtpd_check.c.
+
+20090603
+
+ Cleanup: Postfix 2.3 adopted a file descriptor passing
+ workaround for OpenBSD. This workaround was hard-coded for
+ all platforms because there were no have adverse effects.
+ This is no longer the case: OpenBSD is fixed, and NetBSD
+ does not like the workaround. We now default back to the
+ non-workaround code and turn on the workaround dynamically.
+ Files: util/unix_send_fd.c, unix_recv_fd.c, unix_pass_fd_fix.c.
+
+20090605
+
+ Portability: modern kernels below ancient user-land. File:
+ makedefs.
+
+20090606
+
+ Feature: post-Milter header checks, with all actions except
+ PREPEND. To enable, specify for example "milter_header_checks
+ = pcre:/path/to/file". Files: cleanup/cleanup_init.c,
+ cleanup/cleanup_milter.c, cleanup/cleanup_extracted.c,
+ cleanup/cleanup_state.c.
+
+ Bugfix: non-portable command pathname in postmulti-script.
+
+ Safety: "postmulti -e destroy" no longer attempts to remove
+ files that are created AFTER "postmulti -e create". Rationale:
+ by design, postfix queue/data directories are not trusted;
+ actions within those directory trees must not affect files
+ outside those those trees (e.g. by symlink race attacks).
+ We don't want to be nailed with a bunch of CVEs for unsafe
+ pathname handling. File: conf/postmulti-script.
+
+20090607
+
+ Cleanup: revise milter_header_checks action implementation,
+ and avoid redundant logging and work when milter_header_checks
+ and Milters make redundant or conflicting decisions. File:
+ cleanup_milter.c.
+
+20090614
+
+ Preliminary postscreen triage server for all inbound SMTP
+ connections. This is not a proxy: it rejects bad clients
+ and forwards the rest of the connections to a real Postfix
+ SMTP server. The initial version does a simple "friend or
+ foe" based on whether the client starts talking too soon.
+ Decisions are cached, so "good" clients have no overhead.
+ File: postscreen/postscreen.c.
+
+ Cleanup: more robust code for receiving file descriptors
+ via the "pass" master service protocol. File:
+ util/upass_listen.c.
+
+20090617
+
+ Temporary helper daemon that does parallel DNSBL lookups
+ for postscreen(8). It logs successful lookups to the maillog
+ file without blocking the client. postscreen(8) will use
+ the results in a later non-production version. To enable
+ DNSBL lookups, specify "postscreen_dnsbl_sites = name,
+ name, etc". and restart postscreen(8) with "postfix reload".
+ File: src/dnsblog/dnblog.c.
+
+20090618
+
+ postscreen(8) logging and actions are now documented in the
+ postscreen(8) manpage. When a client is listed in DNSBLs
+ specified with postscreen_dnsbl_sites, it is no longer
+ whitelisted. Instead the number of blocklist hits is logged.
+ File: postscreen/postscreen.c.
+
+20090619
+
+ postscreen(8) by default no longer immediately drops
+ connections. Specify "postscreen_greet_action = drop" and
+ "postscreen_hangup_action = drop" for the old behavior.
+ There is also a new postscreen_dnsbl_action parameter, for
+ completeness. File: postscreen/postscreen.c.
+
+20090708
+
+ Portability: FreeBSD 8 has closefrom(). File: uti/sys_defs.h.
+
+20090710
+
+ Bugfix (introduced Postfix 2.3): Postfix got out of sync
+ with a Milter application after the application sent a
+ "quarantine" request at end-of-message time. The milter
+ application would still be in the end-of-message state,
+ while Postfix would already be working on the next SMTP
+ event (typically, QUIT or MAIL FROM). Problem diagnosed
+ with help from Alban Deniz. File: milter/milter8.c.
+
+20090711-2
+
+ New "event_server" Postfix server framework. It is similar
+ to the "multi_server" framework but does not manage client
+ I/O events. This framework is suitable for servers such
+ as postscreen that have complex event management requirements.
+ File: master/event_server.c.
+
+ New event_fork() primitive to resume event processing in a
+ child process after it is created with fork(). This is
+ needed by postscreen to complete work-in-progress in the
+ background after "postfix reload". File: util/events.c.
+
+ Cleanup: postscreen migrated to the "event_server" framework.
+ File: postscreen/postscreen.c.
+
+20090712
+
+ Cleanup: ${multi_instance_name:postfix}${multi_instance_name
+ ?$multi_instance_name} garbage in Postfix logging is now
+ hopefully gone. File: global/mail_task.c.
+
+20090715
+
+ Documentation: as of Postfix 2.6, the reject_unauth_pipelining
+ feature can be used meaningfully at any protocol stage.
+ File: proto/postconf.proto.
+
+20090717
+
+ Cleanup: postscreen PREGREET detection now uses non-destructive
+ read, so that the real SMTP server can still receive the
+ HELO command (apparently some sites allow pregreeters to
+ talk to their servers). File: postscreen/postscreen.c.
+
+20090805
+
+ Bugfix: don't panic when an unexpected smtpd access map is
+ specified. File: smtpd/smtpd_check.c.
+
+20090918
+
+ Bugfix (introduced Postfix 2.3): with Milter RCPT TO replies
+ turned off, there was no automatic flush-before-read on the
+ smtpd-to-milter stream, because the read was done on the
+ cleanup-to-milter stream. Problem reported by Stephen Warren.
+ File: milter/milter8.c.
+
+20091005
+
+ Bugfix: core dump while printing error message for malformed
+ % sequence in LDAP, MySQL or PostgreSQL configuration.
+ File: global/db_common.c. Fix by Victor Duchovni.
+
+20091006
+
+ Feature: "postscreen_whitelist_networks = $mynetworks" (the
+ default) to avoid problems with buggy SMTP implementations
+ in network appliances. Note: this feature never uses the
+ remote SMTP client hostname. Files: global/addr_match_list.[hc],
+ postscreen/postscreen.c.
+
+ Feature: postscreen_blacklist_networks (default: empty) to
+ permanently blacklist hosts or networks. Address syntax is
+ as with mynetworks. Note: this feature never uses the remote
+ SMTP client hostname. File: postscreen/postscreen.c.
+
+ Feature: postscreen_blacklist_action (default: continue)
+ to control what happens with a permanently blacklisted
+ client. File: postscreen/postscreen.c.
+
+20091007
+
+ Feature: hostname-based check_client_{mx,ns}_access,
+ check_reverse_client_hostname_{mx,ns}_access (the client
+ IP address is not used). Rob Foehl. Files: smtpd/smtpd_check.c,
+ global/mail_params.h, proto/postconf.proto, mantools/postlink.
+
+20091008
+
+ Documentation: restructured the postscreen(8) manpage
+ as a sequence of tests. File: postscreen/postscreen.c.
+
+20091012
+
+ Bugfix: postmulti did not skip commands with -p. Luca
+ Berra. File: postmulti/postmulti.c.
+
+20091023
+
+ Feature: specify "smtpd_command_filter = pcre:/file/name"
+ to replace remote SMTP client commands before they are
+ executed by the Postfix SMTP server. This a last-resort
+ tool to fix inter-operability problems. See examples in
+ the postconf(5) manual page. File: smtpd/smtpd.c.
+
+20091026
+
+ Cleanup: changed parameter evaluation order so that the
+ multi_instance_wrapper parameter value is evaluated after
+ the command and daemon directory parameters. File:
+ global/mail_params.h.
+
+20091101
+
+ Performance: specify "smtpd_proxy_options = speed_adjust"
+ to receive an entire message before sending it through a
+ before-queue content filter. This reduces the number of
+ simultaneous content filtering processes, and thus, the
+ system memory requirements. Files: smtpd/smtpd.[hc],
+ smtpd/smtpd_proxy.[hc].
+
+20091103-4
+
+ Cleaned up the speed-adjust code, streamlined the error
+ handling, and updated documentation. Files: smtpd/smtpd.[hc],
+ smtpd/smtpd_proxy.[hc], proto/SMTPD_PROXY_README.html.
+
+20091105
+
+ Cleaning up after speed_adjust introduction: smtpd segfault
+ caused by an incomplete API change; refined the queue space
+ check; release scratch space immediately after delivering
+ mail to the before-queue filter. Files: smtpd.c, smtpd_proxy.c.
+
+20091110
+
+ Workaround: specify "smtp_tls_block_early_mail_reply = yes"
+ to detect a mail hijacking attack based on a TLS protocol
+ vulnerability (CVE-2009-3555). The attack involves prepending
+ malicious HELO/MAIL/RCPT/DATA commands to a Postfix SMTP
+ client TLS session. The attack would succeed with non-Postfix
+ SMTP servers that reply to the malicious commands after
+ negotiating the Postfix SMTP client TLS session. File:
+ smtp/smtp_proto.c.
+
+20091113
+
+ Workaround: skip interfaces without netmask, to avoid
+ segfaults (reported by Dmitry Karasik). Don't supply a dummy
+ null netmask, as that would turn Postfix into an open relay
+ (mynetworks = 0.0.0.0/0). File: util/inet_addr_local.c.
+
+ Bugfix: forgot to flush output to the smtpd_proxy speed-adjust
+ buffer before truncating the file. Reported by Mark Martinec,
+ fix by Victor Duchovni. File: smtpd/smtpd_proxy.c.
+
+20091114
+
+ Feature: specify "smtp_reply_filter = pcre:/file/name" to
+ replace remote SMTP server reply lines before they are
+ parsed by the Postfix SMTP client. This a last-resort tool
+ to fix inter-operability problems. See examples in the
+ postconf(5) manual page. File: smtp/smtp_chat.c.
+
+ Safety: don't send postmaster notifications to report
+ problems delivering (possible) postmaster notifications.
+ File: smtp/smtp_connect.c.
+
+20091121
+
+ Feature: sender_dependent_default_transport_maps, to override
+ the default transport in a sender-dependent manner. This
+ is not a transport_maps override, and therefore it does not
+ use the transport_maps syntax for null transport, null
+ nexthop, or null email address.
+
+20091127
+
+ Usability: the Postfix SMTP client now logs a warning that
+ wrappermode TLS is not supported, when configured to connect
+ to port smtps/465. File: smtp/smtp_connect.c.
+
+20091203
+
+ Safety: the postscreen daemon logs a warning when table
+ lookup is slow. Slow lookups cause postscreen to fall behind,
+ and worse, to catch up in bursts, which results in overload
+ elsewhere. File: postscreen/postscreen.c.
+
+20091206
+
+ Feature: by popular demand, the Postfix SMTP server now
+ logs the before-queue content filter's end-of-message
+ accept/reject response. File: smtpd/smtpd.c.
+
+20091209
+
+ Portability: as the result of continuous improvement,
+ Berkeley DB no longer allows fork-then-close. File:
+ postscreen/postscreen.c.
+
+ Bugfix: sender_dependent_relayhost_maps did not reject an
+ empty lookup result, and did not recognize lookup errors,
+ thus treating errors as "not found". Problem found during
+ code maintenance. File: trivial-rewrite/resolve.c.
+
+ Cleanup: the postscreen daemon now applies the permanent
+ whitelist first. It is a safety feature that prevents mail
+ from being blocked. File: postscreeb/postscreen.c.
+
+20091224
+
+ Bugfix (introduced 20041215): dict_dbm_sequence() did not
+ release the shared lock when the end of the sequence was
+ reached. File: util/dict_dbm.c.
+
+20091227
+
+ Cleanup: postscreen and verify periodic cache cleanup
+ (default: 12 hours after the previous cache cleanup run).
+ This is based on a new dict_cache(3) module that implements
+ a generalized version of the tlsmgr(8) cache maintenance
+ code. Once the new dict_cache(3) code is burned in, the
+ tlsmgr(8) will be migrated to it. See the RELEASE_NOTES for
+ user interface details. Files: util/htable.[hc], util/dict_ht.c,
+ util/dict_cache.[hc], postscreen/postscreen.c, verify/verify.c.
+
+ Bugfix: the event handler starved I/O events when a timer
+ call-back routine scheduled a zero-delay timer request.
+ This bug was exposed when adding the new dict_cache(3)
+ module for cache expiration. File: util/events.c.
+
+20091228
+
+ Cleanup: postscreen and verify periodic cache cleanup is
+ now optional (specify a null time interval between cache
+ cleanup runs).
+
+20091229
+
+ Cleanup: the address_verify_poll_count default parameter
+ value is now stress-dependent, so that the Postfix SMTP
+ server will not wait (up to 6 seconds) for the address
+ verification result. File: global/mail_params.h.
+
+ Final solution for the I/O event starvation problem when a
+ timer call-back schedules a zero-delay timer request. File:
+ util/events.c.
+
+20091231
+
+ Cleanup: the non-shared, in-memory hash table is now
+ accessible as the "internal:" map type. This simplifies
+ code by eliminating some special cases. Files: util/dict_ht.c,
+ util/dict_open.c, and documentation.
+
+20100101
+
+ Bugfix: the mantools/postlink script applied hyperlinks
+ for the "virtual:" transport to "/etc/postfix/virtual:".
+ Symptom reported by Christoph Anton Mitterer.
+
+20100102
+
+ Workaround: don't report bogus Berkeley DB close errors as
+ fatal errors. All operations before close are already error
+ checked, so the data is known to be safe. File: util/dict_db.c.
+
+20100107
+
+ Documentation: the access(5) manual page did not document
+ the "send 521 and disconnect" behavior in the Postfix SMTP
+ server (introduced with Postfix 2.6). File: proto/access.
+
+ Bugfix: the pickup daemon did not discard messages that
+ were requeued after all recipients were delivered (or
+ bounced), and the cleanup server tried to bounce such
+ messages. Files: pickup/pickup.c, global/cleanup_user.h.
+
+ Future proofing: redundant code in postdrop to reject a
+ submission without recipient record. File: postdrop/postdrop.c.
+
+20100109
+
+ Cleanup: "postcat -q" will now access files in the "saved"
+ queue directory (for corrupted queue files). As before, the
+ "postsuper" command will not, to avoid suddenly deleting
+ such files. Files: global/mail_queue.h postcat/postcat.c.
+
+20100113
+
+ Cleanup: don't supply the "-o stress" command-line option
+ with a single-process service. File: master/master_ent.c.
+
+20100115
+
+ Bugfix: the valid_hostname() fuction did not set the
+ "non-numeric" flag after encountering the '-' character.
+ Reported by Jan Schampera. File: util/valid_hostname.c.
+
+20100116
+
+ Documentation: the content_filter and FILTER features never
+ supported the special cases of transport_maps. References
+ to transport_maps syntax are now removed from content filter
+ discussions. Files: proto/postconf.proto, proto/FILTER_README.
+
+ Workaround: as of Postfix 2.3 the VRFY command did not allow
+ a mailbox address inside <>, which broke expectations. RFC
+ 2821 (and 5321) is vague about the VRFY request format, but
+ spends lots of text on the reply format. File: smtpd/smtpd.c.
+
+20100117
+
+ Cleanup: when a content_filter parameter or FILTER command
+ specifies an empty next-hop destination, the queue manager
+ now uses the recipient domain instead of $myhostname. Specify
+ "default_filter_nexthop = $myhostname" for compatibility
+ with Postfix 2.6 and earlier, or specify a non-empty next-hop
+ filter destination. Files: *qmgr/qmgr_message.c proto/access,
+ proto/header_checks, proto/postconf.proto, proto/FILTER_README.
+
+20100120
+
+ Cleanup: detect illegal pipelining after HELO, EHLO. File:
+ smtpd/smtpd.c.
+
+20100128
+
+ Documentation: streamlined the decriptions of protocol and
+ cipher tweaks. Victor Duchovni. Files: proto/TLS_README,
+ proto/postconf.proto.
+
+20100131
+
+ Documentation: the address verification database is now
+ persistent by default. This, combined with the now default
+ stress-dependent configuration, improves the performance
+ limits and simplifies database maintenance. Files:
+ proto/ADDRESS_VERIFICATION_README, verify/verify.c.
+
+ Cleanup: undo the proxymap and trivial-rewrite max_idle=1s
+ override that was introduced with Postfix 2.3. It did not
+ help to retire long-lived proxymap or trivial-rewrite
+ processes on busy servers, and worsened performance on
+ low-traffic servers. The reduced ipc_ttl value (introduced
+ with Postfix 2.4) already solves the problem of retiring
+ long-lived proxymap or trivial-rewrite processes. Files:
+ proxymap/proxymap.c, trivial-rewrite/trivial-rewrite.c.
+
+20100202
+
+ Documentation: major revision of SASL_README with many
+ details on how to configure Cyrus SASL internals. Patrick
+ Koetter. File: proto/SASL_README.html
+
+20100204
+
+ Feature: added "forward_secrecy" option for Cyrus SASL.
+ File: xsasl/xsasl_cyrus_security.c.
+
+20100206
+
+ Bugfix (from day zero): the local delivery agent returned
+ undeliverable mail to the envelope sender instead of the
+ owner- alias, when delivering to command or file. This
+ reuses the workaround that was implemented to report a
+ Delivered-To: loop. Files: local/file.c, local/command.c,
+ local/recipient.c, local/bounce_workaround.c.
+
+20100209
+
+ The tcp_table(5) interface is now part of the stable release.
+ The last protocol change was in Postfix 2.1. File:
+ util/dict_open.c.
+
+20100305
+
+ Feature: reject_rhsbl_reverse_client, to reject a remote
+ SMTP client based on its unverified reverse hostname. Code
+ by Noel Jones. Files: smtpd/smtpd_check.c, proto/postconf.proto.
+
+ Feature: smtp_address_preference (default: ipv6) to control
+ the order in which the Postfix SMTP client will connect to
+ a destination that has IPv6 and IPv4 addresses with equal
+ MX preference. Files: global/mail_params.h, smtp/smtp.c,
+ smtp/smtp_params.c, smtp/smtp_addr.c, dns/dns_rr.c,
+ and documentation.
+
+20100321
+
+ Feature: allow Milter applications to use a lower protocol
+ version than the version that Postfix is configured for.
+ Based on an idea by Kouhei Sutou. File: milter/milter8.c.
+
+20100322
+
+ Bugfix (introduced 20100305) the new smtp_address_preference
+ feature was not tested with LMTP support. Problem reported
+ by Stefan Foerster. File: smtp/smtp.c.
+
+20100407
+
+ Bugfix (introduced 20100305): reject_rhsbl_reverse_client
+ was skipped if the forward-confirmed reverse DNS (FCRDNS)
+ remote SMTP client hostname was "unknown". Victor Duchovni.
+ File: smtpd/smtpd_check.c.
+
+20100422
+
+ Workaround (introduced: postfix-19990906 a.k.a. Postfix
+ 0.8.0). The Postfix local delivery agent did not properly
+ distinguish between "address has no extension" and "address
+ has an extension, but the extension is invalid". In both
+ cases it would run only the full recipient local-part through
+ the alias maps. Instead, it now drops the faulty extension
+ from the recipient address local-part (it would be too
+ error-prone to replace all tests for "no extension" by tests
+ for "no valid extension". File: local/recipient.c.
+
+20100430
+
+ Feature: customized hard/soft reject responses by Jason
+ Parsons. File: smtpstone/smtp-sink.c.
+
+20100515
+
+ Bugfix (introduced Postfix 2.6): the Postfix SMTP client
+ XFORWARD implementation did not skip "unknown" SMTP client
+ attributes, causing a syntax error when sending a PORT
+ attribute. Reported by Victor Duchovni. File: smtp/smtp_proto.c.
+
+20100526
+
+ Cleanup: a unit-test driver was not updated after an internal
+ API change. Vesa-Matti J Kari File: milter/milter.c.
+
+20100529
+
+ Portability: OpenSSL 1.0.0 changes the priority of anonymous
+ cyphers. Victor Duchovni. Files: postconf.proto,
+ global/mail_params.h, tls/tls_certkey.c, tls/tls_client.c,
+ tls/tls_dh.c, tls/tls_server.c.
+
+ Portability: Mac OS 10.6.3 requires
+ instead of . Files: makedefs, util/sys_defs.h,
+ dns/dns.h.
+
+20100531
+
+ Robustness: skip LDAP queries with non-UTF-8 search strings
+ (in anticipation of UTF8SMTP support). File: global/dict_ldap.c.
+
+ Strict UTF-8 validator per RFC 3629. File: util/valid_utf8_string.c.
+
+20100601
+
+ Cleanup: Postfix LDAP client support for RFC 2255 LDAP URLs.
+ Victor Duchovni. Files: proto/ldap_table global/dict_ldap.c.
+
+ Safety: Postfix processes log a warning when a matchlist
+ has a #comment at the end of a line (for example mynetworks
+ or relay_domains). File: util/match_list.c.
+
+ Portability: Berkeley DB 5.x has the same API as Berkeley
+ DB 4.1 and later. File: util/dict_db.c.
+
+20100610
+
+ Bugfix (introduced Postfix 2.2): Postfix no longer appends
+ the system default CA certificates to the lists specified
+ with *_tls_CAfile or with *_tls_CApath. This prevents
+ third-party certificates from getting mail relay permission
+ with the permit_tls_all_clientcerts feature. Unfortunately
+ this may cause compatibility problems with configurations
+ that rely on certificate verification for other purposes.
+ To get the old behavior, specify "tls_append_default_CA =
+ yes". Files: tls/tls_certkey.c, tls/tls_misc.c,
+ global/mail_params.h. proto/postconf.proto, mantools/postlink.
+
+20100615
+
+ Cleanup: the master no longer logs "process P killed with
+ signal S" when it shuts down a running service (for example,
+ the service is removed from master.cf, or the service is
+ disabled via the main.cf master_service_disable parameter).
+ File: master/master_spawn.c.
+
+20100617
+
+ Feature: read-only sqlite support based on code by Axel
+ Steiner and documentation by Jesus Garcia Crespo. Files:
+ conf/postfix-files, mantools/postlink, proto/DATABASE_README.html,
+ proto/Makefile.in, proto/INSTALL.html, proto/mysql_table,
+ proto/pgsql_table, proto/sqlite_table, proto/SQLITE_README.html,
+ global/Makefile.in, global/mail_dict.c, global/dict_sqlite.c,
+ global/dict_sqlite.h, postconf/postconf.c, postfix/postfix.c.
+
+20100618
+
+ Cleanup: SQLite read-only driver and documentation. Files:
+ global/dict_sqlite.c, proto/mysql_table, proto/SQLITE_README.html.
+
+20100707
+
+ Completed the 20100610 bugfix. File: tls/tls_misc.c.
+
+20100714
+
+ Compatibility with Postfix < 2.3: fix 20061207 was incomplete
+ (undoing the change to bounce instead of defer after
+ pipe-to-command delivery fails with a signal). Fix by Thomas
+ Arnett. File: global/pipe_command.c.
+
+20100715
+
+ Convenience: "postconf name=value ..." is now equivalent to
+ "postconf -e name=value ...". File: postconf/postconf.c.
+
+20100724
+
+ Feature: INFO header/body_checks action for non-warning
+ messages (for example, to log all Milter-inserted headers).
+ File: global/header_body_checks.c, proto/header_checks.
+
+ Cleanup: after-filter Postfix SMTP servers now log before-filter
+ queue IDs. For this, the XFORWARD protocol was extended
+ with an IDENT attribute for the before-filter queue ID.
+ This code was started in Postfix 2.1, but it was never
+ finished due to time constraints. Files: smtpd/smtpd.[hc]
+ smtpd/smtpd_proxy.c, smtpd/smtpd_sasl_proto.c,
+ *qmgr/qmgr_messsage.c, *qmgr/qmgr_deliver.c,
+ global/deliver_request.[hc], global/mail_proto.h,
+ global/deliver_pass.c, smtp/smtp_proto.c.
+
+20100727
+
+ Bugfix: the milter_header_checks parser provided only the
+ actions that change the message flow (reject, filter,
+ discard, redirect) but disabled the non-flow actions (warn,
+ replace, prepend, ignore, dunno, ok). File:
+ cleanup/cleanup_milter.c.
+
+20100827
+
+ Performance: fix for poor smtpd_proxy_filter TCP performance
+ over loopback (127.0.0.1) connections. Problem reported by
+ Mark Martinec. Files: smtpd/smtpd_proxy.c.
+
+ Bugfix: the Postfix SMTP client no longer appends the local
+ domain when looking up a DNS name without ".". Specify
+ "smtp_dns_resolver_options = res_defnames" to get the old
+ behavior, which can produce unexpected results. Files:
+ smtp/smtp.c, smtp/smtp_params.c, smtp/smtp_addr.c.
+
+20100828
+
+ Refactoring: postscreen source code broken up into multiple
+ files, and identifiers updated to match changes in their
+ purpose. This will be the baseline for adding support for
+ DNSBL weighting, then a dummy engine to collect forensic
+ evidence with the option of future protocol checks. Files:
+ postscreen/*.[hc], Makefile.in.
+
+20100829
+
+ Postscreen DNSBL support for optional fixed-string filters
+ and optional integral weight factors (use negative weights
+ for whitelisting). See RELEASE_NOTES and postconf(5) for
+ details. Files: postscreen/postscreen_dnsbl.c,
+ proto/postconf.proto, mantools.postlink, global/mail_params.h.
+
+ Incompatibility: the postscreen-to-dnsblog protocol was
+ changed to support DNSBL query result filters. Use "postfix
+ reload" after installing the new version otherwise the
+ dnsblog(8) server may complain.
+
+20100830
+
+ Polished the postscreen documentation and comments to clarify
+ the user interface and implementation. No code changes.
+
+20100831-910
+
+ Restructured postscreen and added support for a dummy SMTP
+ protocol engine. This engine logs rejected attempts to
+ deliver mail with helo/sender/recipient information, and
+ implements deep protocol tests. The first deep protocol
+ test is for command pipelining, where a client sends multiple
+ commands instead of waiting for the server to respond to
+ each command. The second one implements the Postfix SMTP
+ server's smtpd_forbidden_commands feature. Files:
+ postscreen/*.[hc]. See RELEASE_NOTES, postconf(5) and
+ postscreen(8) for incompatibilities, features, and configuration
+ parameters.
+
+20100910
+
+ Feature: boolean configuration parameters with string-valued
+ defaults, so that they can be subject to macro expansions.
+ This was needed to make some postscreen parameter defaults
+ to the values of the corresponding smtpd parameters. Files:
+ global/mail_conf.h, global/mail_conf_nbool.c,
+ master/event_server.c, master/mail_server.h, master/multi_server.c,
+ master/single_server.c, master/trigger_server.c,
+ postconf/extract.awk, postconf/postconf.c.
+
+20100911
+
+ Feature: texthash read-only database. This is similar to
+ hash: files, except that you don't need to run the postmap(1)
+ command before you can use the file, and that it does not
+ detect changes after the file is read. All information is
+ read into memory. Files: util/dict_open.c, util/dict_thash.[hc],
+ proto/DATABASE_README.html, postconf/postconf.c
+
+20100912
+
+ Feature: bare newline detection in postscreen. Real spambots
+ don't make this mistake anymore, but poorly-written software
+ still does. File: postscreen/smtpd.c.
+
+ Documentation: POSTSCREEN_README including instructions for
+ turning postscreen(8) on without blocking mail, and more.
+ Trimmed the text in the postscreen(8) manpage. File:
+ proto/POSTSCREEN_README.html, postscreen/postscreen.c.
+
+20100914
+
+ Cleanup: the "postscreen_greet_wait" delay now ends as soon
+ as both the pregreet and DNSBL tests complete (the postscreen
+ documentation mentions in history/credits that the program
+ started as a crude prototype). The default postscreen_dnsbl_ttl
+ caching time is now reduced to 1h from 24h, allowing
+ postscreen to catch up on DNSBL updates more quickly. If
+ this increases the database update frequency too much then
+ we'll need to make dnsbl result non-cachable. Files:
+ postscreen/postscreen_dnsbl.c, global/mail_params.h.
+
+20100915
+
+ Bugfix (introduced 20100914): missing precondition for
+ call-back notification. File: postscreen/postscreen_dnsbl.c.
+
+ Bugfix (introduced 20100914): the "postscreen_greet_wait"
+ delay speedup worked only for DNSBL listed sites. File:
+ postscreen/postscreen_dnsbl.c.
+
+ Workaround: better handling of pregreeting spambots. The
+ postscreen built-in SMTP engine no longer sends a 220 banner
+ to a client that falls into the pregreet trap. This eliminates
+ many "NON-SMTP COMMAND" records in postscreen logging, as
+ the SMTP client and server no longer get out of sync. It
+ also results in better logging of sender/recipient information.
+ File: postscreen/postscreen_smtpd.c.
+
+20100916
+
+ Cleanup: postscreen now uses the first responding DNSBL
+ name in the "5.7.1 Service unavailable" reply, instead of
+ the last responding one. File: postscreen/postscreen_dnsbl.c.
+
+ Cleanup: the 20100914 "postscreen_greet_wait" speedup did
+ not happen as often as it should, because some older code
+ still turned on PREGREET tests gratuitously, causing a full
+ greet-wait delay. File: postscreen/postscreen_tests.c.
+
+ Cleanup: to avoid "address in use" problems, postscreen now
+ closes the listening socket after "postfix stop". It also
+ closes the socket after "postfix reload" but that does not
+ hurt. Files: master/event_server.c, master/multi_server.c.
+
+ Cleanup: postscreen now logs CONNECT and DISCONNECT events.
+ Files: postscreen/postscreen.c, postscreen/postscreen_misc.c.
+
+20100917
+
+ Bugfix: cut-and-paste error. Postscreen used pregreet_ttl
+ instead of dnsbnl_ttl. File: postscreen/postscreen_early.c.
+
+20100920
+
+ Cleanup: minor cleanups and invisible fixes. Files:
+ postscreen/postscreen_misc.c, postscreen/postscreen.h,
+ postscreen/postscreen_tests.c.
+
+ Feature: preliminary postscreen penalty mechanism. Basic
+ idea: when a client exceeds some threshold, don't allow it
+ to pass any tests until the penalty expires. Penalties
+ provide a way to slow down clients without blocking mail
+ permanently. Files: postscreen/postscreen_misc.c,
+ postscreen/postscreen_tests.c, postscreen/postscreen.c.
+
+ A first application of the postscreen penalty mechanism
+ triggers on clients that make brief connections to find out
+ if the mail server is up. With "postscreen_early_hangup_penalty
+ = 600" they will disqualify themselves for 10 minutes.
+ Unfortunately, this behavior is used by legitimate bulk
+ mail services. This application was removed 20101103. The
+ penalty mechanism itself is left in place as #ifdef NONPROD.
+
+20100923
+
+ Cleanup: renamed MUMBLE_FLAG_MUMBLE aggregates to
+ MUMBLE_MASK_MUMBLE for consistency with other Postfix code.
+ Files: postscreen/*.[hc].
+
+20100930
+
+ Cleanup: flag PIPELINING errors with NOOP and VRFY. File:
+ smtpd/smtpd.c.
+
+20101006
+
+ Bugfix (introduced: 20100914) dangling pointer when a client
+ makes N > 1 simultaneous connections and closes M < N
+ connections before postscreen has delivered the DNSBL score
+ to the corresponding pseudothreads. In practice the pointer
+ will refer to a block of 0xff bytes; the program terminates
+ with a segmentation violation, and is restarted immediately
+ by the master daemon. Files: postscreen/postscreen_early.c,
+ postscreen/postscreen_dnsbl.c.
+
+ Cleanup: avoid repeated delivery to mailing list members
+ with pathological nested alias configurations. The local(8)
+ delivery agent now keeps the owner-alias attribute of the
+ parent alias, when delivering mail to a child alias that
+ does not have its own owner alias. With this change, local
+ addresses from that child alias will be written to a new
+ queue file, and a temporary error with one local address
+ will no longer result in repeated delivery to other mailing
+ list members. Specify "reset_owner_alias = yes" for the
+ older behavior. File: local/alias.c.
+
+20101007
+
+ Bugfix (introduced: 2100923): duplicate "PASS OLD" logging.
+ File: postscreen/postscreen_misc.c.
+
+20101008
+
+ Cleanup: dnsblog now logs "addr X listed by domain Y as Z"
+ instead of "addr X blocked by domain Y as Z", because the
+ service may be used for whitelist lookups. File:
+ dnsblog/dnsblog.c.
+
+20101023
+
+ Cleanup: don't apply reject_rhsbl_helo to non-domain forms
+ such as network addresses. This would cause false positives
+ with dbl.spamhaus.org. File: smtpd/smtpd_check.c.
+
+20101103
+
+ Cleanup: new qmgr_ipc_timeout parameter (default: 60s) to
+ override the system-wide ipc_timeout setting (default:
+ 3600s). The shorter timeout allows the queue manager to
+ reset a deadlocked IPC connection before the watchdog timer
+ goes off. Files: *qmgr/qmgr.c.
+
+ Cleanup: new qmgr_daemon_timeout parameter (default: 1000s)
+ to make the hard-coded 1000s watchdog timeout configurable.
+ Files: *qmgr/qmgr.c.
+
+ Cleanup: request default DSN notification when adding a
+ recipient with smfi_addrcpt, instead of requesting "never
+ notify" as with Postfix automatically-added BCC recipients.
+ Files: cleanup/cleanup_addr.c, cleanup/cleanup.h,
+ cleanup/cleanup_milter.c.
+
+20101105
+
+ Feature: DNS whitelist support in the Postfix SMTP server.
+ permit_dnswl_client whitelists a client by IP address, and
+ permit_rhswl_client whitelists a client by its hostname.
+ The syntax is the same as reject_rbl_client etc., but the
+ result is PERMIT instead of REJECT. For safety reasons,
+ permit_xxx_client are silently ignored when they would
+ override reject_unauth_destination. The result is
+ DEFER_IF_REJECT when DNSWL lookup fails. The implementation
+ is based on a design documented by Noel Jones (August 2010).
+ File: smtpd/smtpd_check.c.
+
+20101108
+
+ Workaround: strip off IPv6 datalink suffix from peer address
+ to avoid problems with strict address checking code. Files:
+ smtpd/smtpd_peer.c, qmqpd/qmqpd_peer.c.
+
+20101114
+
+ Robustness: postscreen(8) now implements a time limit on
+ reading an entire command, instead of a time limit for
+ reading individual characters. File: postscreen/postscreen_smtpd.c.
+
+20101023
+
+ Cleanup: don't apply reject_rhsbl_helo to non-domain forms
+ such as network addresses. This would cause false positives
+ with dbl.spamhaus.org. File: smtpd/smtpd_check.c.
+
+20101117
+
+ Bugfix: the "421" reply after Milter error was overruled
+ by Postfix 1.1 code that replied with "503" for RFC 2821
+ compliance. We now make an exception for "final" replies,
+ as permitted by RFC. Solution by Victor Duchovni. File:
+ smtpd/smtpd.c.
+
+20101124-6
+
+ Feature: pattern matching for DNSWL/DNSBL responses. For
+ example, with "reject_rbl_client example.com=d.d.d.d", each
+ "d" can now be a pattern inside "[]" that contains one or
+ more comma-separated decimal numbers or number..number
+ ranges. Files: smtpd/smtpd_check.c, postscreen/postscreen_dnsbl.c,
+ util/ip_match.c, util/ip_match.h.
+
+20101126
+
+ Cleanup: don't log "blocked using example.com=127.0.0.1",
+ just log the domain name. File: smtpd/smtpd_check.c.
+
+20101129
+
+ Cleanup: postscreen_client_connection_count_limit (default:
+ $smtpd_client_connection_count_limit) to limit the number
+ of connections from the same IP address to the postscreen(8)
+ daemon. Files: postscreen/postscreen.c, postscreen/postscreen.h,
+ postscreen/postscreen_state.c.
+
+20101130
+
+ Cleanup: all postscreen(8) logging now reports the client
+ as [address]:port. This requires an update of tools that
+ process postscreen logging. Files: postscreen/*.c,
+ proto/POSTSCREEN_README.html.
+
+ Cleanup: polishing recent documentation and code. Files:
+ postscreen/postscreen_dnsbl.c, util/ip_match.c.
+
+20101201
+
+ Bugfix (introduced 20101129): broken default value for
+ postscreen_client_connection_count_limit if the
+ smtpd_client_connection_count_limit parameter was left at
+ its default. File: postscreen/postscreen.c.
+
+ Workaround: BSD-ish mkdir() ignores the effective GID
+ and copies group ownership from the parent directory.
+ File: util/make_dirs.c.
+
+20101202
+
+ Feature: the LDAP client can now authenticate to LDAP servers
+ via SASL. This is tested with SASL GSSAPI and Kerberos 5.
+ Original code by Quanah Gibson-Mount adapted by Victor
+ Duchovni. Files: global/dict_ldap.c, proto/LDAP_README.html,
+ proto/ldap_table.
+
+ Cleanup: the cleanup server now reports a temporary delivery
+ error when it reaches the virtual_alias_expansion_limit or
+ virtual_alias_recursion_limit. Previously, it would silently
+ ignore the excess recipients and deliver the message. File:
+ cleanup/cleanup_map1n.c.
+
+20101205
+
+ Cleanup: sache_clnt_create() had an unnecessary data
+ dependency on the non-library var_scache_service variable,
+ causing problems with shared library builds. Instead, it
+ should use its service argument (which has the same value).
+ File: global/scache.c.
+
+ Cleanup: pipe_command.c had an unnecessary data dependency
+ on the non-library var_command_maxtime variable, causing
+ problems with shared library builds. The dependency was not
+ necessary because the callers already specify an explicit
+ time limit. File: global/pipe_command.c.
+
+20101206
+
+ Bugfix (introduced 20101205): postscreen hung up due to
+ incorrect output error test. File: postscreen/postscreen_send.c.
+
+20101207
+
+ Cleanup: the undisclosed_recipients_header default value
+ is now the empty string. The Internet mail RFCs have supported
+ messages without recipient header for almost 10 years now.
+ File: global/mail_params.h.
+
+ Cleanup: use strtol() instead of sscanf() for consistent
+ handling of out-of-range numbers. Files: global/cfg_parser.c,
+ global/conv_time.c, global/mail_conf_int.c,
+ global/mail_conf_long.c, global/mail_conf_nint.c.
+
+20101217
+
+ Cleanup: eliminated the code that copied TLS protocol
+ messages between the OpenSSL TLS engine and the network.
+ This change hopefully simplifies the TLS library enough
+ that it can be used in an event-driven TLS proxy in front
+ of postscreen. Files: tls/tls_bio.c, tls/tls_server.c,
+ tls/tls_client.c.
+
+ This change eliminates an obscure bug where the SMTP server
+ would wait for another $smtpd_timeout seconds after sending
+ the "421 Error: timeout exceeded" message to the client.
+
+20101221
+
+ Cleanup: simplified the VSTREAM "large buffer" support by
+ dropping the Postfix 2.4 "binary compatibility" requirement.
+ Files: util/vstream.c, util/vstream.h.
+
+20101222
+
+ Cleanup: the SMTP client PIPELINING code did not account
+ for TLS protocol overhead. This could (only in theory)
+ result in deadlock when the remote SMTP server announces a
+ very small receive window after the client and server have
+ synchronized their SMTP state. Victor Duchovni. File:
+ smtp/smtp_proto.c.
+
+20101223
+
+ Feature: with "tls_preempt_cipherlist = yes" the Postfix
+ SMTP server will preempt the remote SMTP client's cipher
+ preference order. This requires OpenSSL 0.9.7 and later.
+ Victor Duchovni. Files: src/smtpd/smtpd.c, src/tls/tls_server.c,
+ proto/TLS_README.html, proto/postconf.proto.
+
+ Future proofing: specify "tls_disable_workarounds = a list
+ or bit-mask of OpenSSL bug work-arounds to disable". This
+ may become necessary when a bug workaround is found to cause
+ problems (security or interoperability). Victor Duchovni.
+ Files: tls/tls_misc.c, proto/TLS_README.html, proto/postconf.proto.
+
+ Infrastructure: extended name_mask module feature set with
+ extensive documentation and 32-bit regression tests. Victor
+ and Wietse. File: util/name_mask.[hc].
+
+20101224
+
+ Cleanup: sanitized the name_mask API so that errors will be
+ ignored only upon explicit request. Files: util/name_mask.[hc],
+ src/global/ehlo_mask.c, src/smtp/smtp_proto.c,
+ src/util/name_mask.c, src/xsasl/xsasl_dovecot_server.c.
+
+ Cleanup: more TLS overhead horrors for the SMTP client's
+ PIPELINING engine. Wietse and Victor. File: smtp/smtp_proto.c.
+
+20101226
+
+ Cleanup: the SMTP client logic for pipelining the "." and
+ "QUIT" commands was bogus - the pipelining engine could not
+ know how much unacknowledged data is pending in the local
+ TCP stack. We now ignore the buffer check for sending
+ "QUIT" after ".". Wietse and Victor. File: smtp/smtp_proto.c.
+
+20110101
+
+ Cleanup: the Postfix SMTP server now always refreshes the
+ SASL authentication mechanism list after STARTTLS. Some
+ Dovecot versions may change their responses when they know
+ that the SMTP connection is encrypted. File: smtpd/smtpd.c.
+
+ Cleanup: the smtpd_starttls_timeout default value is now
+ stress-dependent. Files: global/mail_params.h,
+ proto/postconf.proto.
+
+ Compatibility: postscreen_discard_ehlo_keyword(s|maps)
+ support for compatibility with smtpd_discard_ehlo_keyword(s|maps).
+ Files: postscreen/postscreen_smtpd.c.
+
+20110102
+
+ Feature: STARTTLS support for the postscreen(8) daemon.
+ With early testing feedback from Victor Duchovni and Ralf
+ Hildebrandt. Files: postscreen/postscreen_smtpd,
+ postscreen/postscreen_starttls.c.
+
+ Feature: event-driven tlsproxy(8) daemon that translates
+ TLS <=> plaintext for postscreen(8). One tlsproxy(8) process
+ can translate traffic for multiple remote SMTP clients.
+ With early testing feedback from Victor Duchovni and Christian
+ Roessner. Files: util/nbbio.[hc], tlsproxy/*.[hc],
+ postscreen/postscreen_starttlsd.c, postscreen/postscreen_smtpd.c.
+
+20110103
+
+ Cleanup: missing tls_level support in tlsproxy (it has no
+ way to send plaintext, but perhaps an informative error
+ message is in order anyway). File: tlsproxy/tlsproxy.c.
+
+ Cleanup: simplified the handling of throttled output (i.e.
+ output that can't be sent because the receiver tries to be
+ nasty). File: postscreen/postscreen_send.c.
+
+20110104
+
+ Feature: add contact information to each SMTP server reject
+ message. For example, "smtpd_reject_footer = call 800-555-0101
+ for assistance", with macro expansion and with multi-line
+ support. Files: global/mail_params.h, mantools/postlink,
+ proto/postconf.proto, smtpd/smtpd.c, smtpd/smtpd_chat.c,
+ smtpd/smtpd_expand.[hc], util/mac_expand.[hc].
+
+20110105
+
+ Cleanup: the forest of TLS-related booleans was shrunk.
+ Victor Duchovni. Files: smtpd/smtpd.c, postscreen/postscreen.c,
+ postscreen/postscreen_smtpd.c, tlsproxy/tlsproxy.c.
+
+ Non-production: tlsproxy support in the Postfix SMTP server
+ for stress testing of the tlsproxy daemon (#ifdef TLSPROXY).
+ Seen from outside, Postfix works just as if it has TLS
+ support built into in smtpd(8). Files: smtpd/smtpd.c,
+ tls/tls_proxy*.[hc], tlsproxy/tlsproxy.c, util/vstream.[hc].
+
+ Bugfix (introduced with the Postfix TLS patch): discard
+ plaintext following the STARTTLS command or response. This
+ matters only for the minority of SMTP clients that actually
+ verify server certificates. Files: smtpd/smtpd.c,
+ smtp/smtp_proto.c.
+
+20110106
+
+ Non-production: cleaned up the tlsproxy support in the
+ Postfix SMTP server for stress testing of the tlsproxy
+ daemon (still #ifdef TLSPROXY). File: smtpd/smtpd.c.
+
+20110107
+
+ Cleanup: smtpd_reject_contact_information is renamed to
+ smtpd_reject_footer, because it can be used for non-contact
+ information.
+
+ Compatibility: postscreen_reject_footer support for
+ compatibility with smtpd_reject_footer. Files:
+ global/smtp_reply_footer.[hc], global/mail_conf.[hc],
+ postscreen/postscreen_expand.c, postscreen/postscreen_send.c,
+ postscreen/postscreen.c, smtpd/smtpd_chat.c.
+
+ Compatibility: postscreen_command_filter support for
+ compatibility with smtpd_command_filter. Files:
+ postscreen/postscreen_dict.c, postscreen/postscreen_smtpd.c
+
+20110108
+
+ Cleanup: postscreen(8) now displays control characters in
+ PREGREET responses as C-style \letter escapes, instead of
+ "?". File: postscreen/postscreen_early.c.
+
+20110109
+
+ Cleanup: Solaris support for "pass" (file descriptor passing
+ based) services in master.cf. This was needed by postscreen(8).
+ Also, renamed upass_xxx.c to unix_pass_xxx.c. One-character
+ prefixes are too short. Removed upass_connect.c because it
+ was useless code. Files: util/stream_pass_connect.c,
+ util/unix_pass_listen.c, util/unix_pass_trigger.c.
+
+ Bugfix (introduced Postfix 2.4): on Solaris the Postfix
+ event engine was deaf for SIGHUP and SIGALRM signals after
+ the switch to /dev/poll. Symptoms were delayed "postfix
+ reload" response, and killed processes when the watchdog
+ timeout was less than max_idle. The fix is to set up SIGHUP
+ and SIGALRM handlers that write to a pipe, and to monitor
+ that pipe for read events via the Postfix event engine.
+ Files: master/master_sig.c, util/watchdog.c, util/sys_defs.h.
+
+20110111
+
+ Cleanup: replaced the postscreen(8) separate blacklist and
+ whitelist lookup tables by one postscreen_access_list table.
+ See postconf(5) and POSTSCREEN_README for examples. Files:
+ postscreen/postscreen_access.c, postscreen/postscreen.c,
+ proto/postconf.proto, proto/POSTSCREEN_README.html.
+
+20110112
+
+ Cleanup: suspend/resume logic for postscreen(8) SMTP sessions
+ that temporarily switch control to an external program such
+ as tlsproxy, or perhaps a future policy plugin. Files:
+ postscreen/postscreen_smtpd, postscreen/postscreen_starttls.c.
+
+20110113
+
+ Cleanup: ps_cache and psc_cache are now postscreen_cache.
+ There is no need for obscure name abbrevations. File:
+ src/global/mail_params.h.
+
+20110115
+
+ Workaround: malloc fuzz (safety margin for malloc requests).
+ Files: util/sys_defs.h, util/mymalloc.c.
+
+ Cleanup: dnsblog_service_name and tlsproxy_service_name are
+ now configurable, in case someone needs this. Files:
+ global/mail_params.h, postscreen/postscreen.c, mantools/postlink,
+ proto/postconf.proto.
+
+20110116
+
+ Cleanup: soft_bounce support for postscreen(8). Files:
+ postscreen/postscreen_smtpd.c, postscreen/postscreen_send.c.
+
+ Cleanup: for smtpd(8) compatibility, postscreen(8) now
+ strips deprecated route address prefixes from email addresses
+ (@here,@there:user@example becomes user@example). This is
+ primarily to make postscreen(8) logging more similar to
+ that of smtpd(8). File: postscreen/postscreen_smtpd.c.
+
+ Cleanup: documentation, in preparation for the Postfix 2.8
+ stable release.
+
+20110117
+
+ Bugfix (introduced Postfix alpha, or thereabouts): on HP-UX
+ the Postfix event engine was deaf for SIGALRM signals.
+ Symptoms were killed processes when the watchdog timeout
+ was less than max_idle. The fix is the same as Solaris fix
+ 20110109. Since we can't know what other systems need this,
+ the workaround is enabled by default. Files: util/sys_defs.h.
+
+ Cleanup: "smtpd_tls_eecdh_grade = strong" by default, instead
+ of snapshot-only. File: global/mail_params.h, proto/postconf.proto.
+
+ Cleanup: missing "#include " in util/watchdog.c.
+
+ Bugfix: when compiled without -DUSE_TLS, tlsproxy used the
+ wrong server skeleton (multi_server instead of event_server).
+ File: tlsproxy/tlsproxy.c.
+
+ Workaround: added a panic check for code that is mis-compiled
+ by the HP-UX compiler. File: postscreen/postscreen.c,
+ postscreen/postscreen.h, postscreen/postscreen_state.c.
+
+20110118
+
+ Bugfix: the tls_disable_workarounds word list only included
+ workarounds in SSL_OP_ALL. Problem report by Steve Jenkins,
+ problem fix by Victor Duchovni. File: tls/tls_misc.c.
+
+ Last-minute incompatible syntax change: Postfix now uses
+ ";" instead of "," to separate DNSBL/DNSWL address filter
+ fields inside "[]". The compatibility break is not an issue,
+ because the syntax never worked in main.cf. Problem reported
+ by Mark Martinec. Files: util/ip_match.c, util/ip_match.in,
+ util/ip_match.ref, proto/postconf.proto.
+
+ Cleanup: postscreen now monitors the AVERAGE latency of
+ table access, and complains at most once per minute. File:
+ postscreen/postscreen_dict.c.
+
+ Bugfix: support for the "dunno" command somehow disappeared
+ from the postscreen_access_list implementation. File:
+ postscreen/postscreen_access.c.
+
+20110123
+
+ Feature: read/write deadlines. Deadlines were introduced
+ with postscreen's dummy SMTP engine. In the Postfix SMTP
+ client and server, deadlines limit the total amount of time
+ to read or write one command line, one response line, or
+ one line of message content. This reduces the impact of
+ application exhaustion attacks that trickle data one byte
+ at a time. Files: util/vstream.[hc], global/smtp_stream.c.
+
+ Cleanup: remove #ifdef MIGRATION_WARNING transitional code
+ from postscreen. File: postscreen/postscreen.c.
+
+20110125
+
+ Cleaned up and finalized read/write deadline support. Once
+ this code has been fielded it can go into Postfix 2.8.1,
+ and made available as optional patch for earlier releases.
+ Further refinements have only dimishing returns and can
+ evolve in the 2.9 release cycle. File: util/vstream.c.
+
+20110128
+
+ Infrastructure: separate VSTREAM flags for read or write
+ errors. Files: util/vbuf.[hc], util/vstream.[hc].
+
+ Cleanup: after write error, the smtp_stream routines now
+ disable further network writes. This eliminates the need
+ for clumsy code to avoid unwanted I/O while shutting down
+ a TLS engine or closing a VSTREAM. File: util/smtp_stream.c.
+
+20110201
+
+ Cleanup: when verifying that the client_address->client_name
+ lookup result resolves to the client_address, request
+ hostname->address lookup with the same protocol family (IPv4
+ or IPv6) as the client_address. Files: util/myaddrinfo.[hc],
+ smtpd/smtpd_peer.c, qmqpd/qmqpd_peer.c.
+
+20110205
+
+ Infrastructure: vstream_peek_data() primitive to look ahead
+ at buffered input. Use vstream_peek() to find out how much,
+ and escape() for human presentation. Files: util/vstream.[hc].
+
+ Cleanup: smtpd(8) and postscreen(8) now log the input that
+ triggers an SMTP command pipelining violation. File:
+ postscreen/postscreen_smtpd.c, smtpd/smtpd.c.
+
+ Infrastructure: smtp_get() option to skip over input in
+ excess of the line length limit. Files: smtp/smtp_stream.[hc].
+
+ Cleanup: handle excessively-long client requests and server
+ responses more gracefully, i.e. without losing synchronization.
+ Files: smtpd/smtpd_chat.c, smtpd/smtpd_proxy.c, smtp/smtp_chat.c,
+ smtpstone/smtp-source.c.
+
+20110207
+
+ Bugfix (introduced Postfix 2.8): segfault with smtpd_tls_loglevel
+ >= 3. Files: tls/tls_server.c, tls.h, smtpd.c, tlsproxy.c.
+
+ Cleanup: read/write deadline support for single_server TLS
+ applications (i.e. smtpd(8), smtp(8)). File: tls/tls_bio_ops.c.
+
+20110212
+
+ Infrastructure: run-time switch for read/write deadline
+ support. Files: util/vstream.[hc], global/smtp_stream.[hc],
+ tls/tls_bio_ops.c.
+
+ Cleanup: configurable read/write deadline support with
+ smtpd_per_record_deadline (normal: "no", overload: "yes")
+ and smtp_per_record_deadline (default: "no"). Files:
+ global/mail_params.h, smtpd/smtpd.c, smtp/smtp.c,
+ smtp/smtp_proto.c, proto/postconf.proto, mantools/postlink.
+
+20110213
+
+ Workaround: the TLS library passes the same information via
+ different function arguments, and this same information is
+ maintained by different functions, so things get out of
+ step when code is updated. As of 20110212, tls_client_start()
+ needs to set the VSTREAM property of the TLS session object.
+ File: tls/tls_client.c.
+
+20110215
+
+ Human factors: the FCRDNS (forward-confirmed reverse DNS)
+ checking code now logs "hostname X does not resolve to
+ address Y", when a "reverse hostname" lookup result does
+ not resolve to the client IP address. Files: smtpd/smtpd_peer.c,
+ qmqpr/qmqpd_peer.c.
+
+20110216
+
+ Cleanup: don't log a "connection reset by peer" error when
+ postscreen(8) tries to send a server response. File:
+ postscreen/postscreen_send.c.
+
+20110218
+
+ Cleanup: Postfix now uses long integers for message_size_limit,
+ mailbox_size_limit and virtual_mailbox_limit. On LP64 (64-bit
+ long and pointer, but 32-bit integer) systems, these message
+ and mailbox limits can now exceed 2GB. Files: global/mail_params.c
+ global/mail_params.h local/local.c master/event_server.c
+ master/mail_server.h master/multi_server.c master/single_server.c
+ master/trigger_server.c virtual/virtual.c postconf/extract.awk
+ postconf/postconf.c.
+
+20110220
+
+ Cleanup: compiler gripe. File: util/vstream.c.
+
+20110223
+
+ Cleanup: Debian build tool gripe. File: smtpstone/smtp-sink.c.
+
+20110224
+
+ postscreen(8) support to enforce proper client MX lookup
+ policy. Some spambots connect first to a backup MX address
+ in the hope that the server has a weaker anti-spam policy.
+ By listening on both primary and backup MX addresses,
+ postscreen(8) can deny the temporary whitelist status to
+ clients that connect only to backup MX hosts, and prevent
+ them from talking to a Postfix SMTP server process.
+
+ For example, when 1.2.3.4 is a local backup IP address,
+ specify "postscreen_whitelist_interfaces = !1.2.3.4 static:all"
+ to disable dynamic whitelisting for clients that connect
+ (only) to the backup MX address. Files: mantools/postlink,
+ proto/postconf.proto, proto/POSTSCREEN_README.html,
+ global/mail_params.h, postscreen/postscreen.c,
+ postscreen/postscreen.h, postscreen/postscreen_state.c.
+
+20110225
+
+ Workaround (problem introduced with IPv6 support in Postfix
+ 2.2): the SMTP client did not support mail to [ipv6:ipv6addr].
+ Fix based on a patch by Gurusamy Sarathy (Sophos). File:
+ util/host_port.c and regression test files.
+
+20110227
+
+ Portability: FreeBSD closefrom() support time window. Sahil
+ Tandon. File: util/sys_defs.h.
+
+ Cleanup: each lookup table now has an owner status and UID
+ attributes for provenance purposes, even memory-resident
+ tables such as pcre, regexp and cidr. This fixes a problem
+ where local(8) ignored the non-root ownership of a regular
+ expression-based aliases(5) file. The table owner status
+ is TRUSTED (data straight from root-owned configuration
+ file), UNKNOWN (unauthenticated data from proxy or tcp) or
+ KNOWN (we actually have an owner UID). With most tables,
+ the owner UID is the file owner UID. With LDAP and *SQL,
+ the owner UID is the Postfix configuration file owner.
+ Files: src/util/dict_unix.c src/util/dict_thash.c
+ src/util/dict_static.c src/util/dict_sdbm.c src/util/dict_regexp.c
+ src/util/dict_pcre.c src/util/dict_nisplus.c src/util/dict_nis.c
+ src/util/dict_ni.c src/util/dict_ht.c src/util/dict_env.c
+ src/util/dict_dbm.c src/util/dict_db.c src/util/dict_cidr.c
+ src/util/dict_cdb.c src/util/dict_alloc.c src/util/dict.h
+ src/util/dict.c src/local/alias.c src/global/dict_sqlite.c
+ src/global/dict_pgsql.c src/global/dict_mysql.c
+ src/global/dict_ldap.c src/global/cfg_parser.h
+ src/global/cfg_parser.c.
+
+20110311
+
+ Feature: Base 32 encoder/decoder per RFC 4648. This code
+ was going to be used for long queue IDs, but plans were
+ changed. Files: src/util/base32_code.[hc].
+
+20110313
+
+ Bugfix (introduced Postfix 2.8): postscreen DNSBL scoring
+ error. When a client disconnected and then reconnected
+ before all DNSBL results for the earlier session arrived,
+ DNSBL results for the earlier session would be added to the
+ score for the later session. Problem report by Larry Vaden.
+ Files: dnsblog/dnsblog.c, postscreen/postscreen_dnsbl.c.
+
+ Cleanup: protocol description in dnsblog(8) manpage. File:
+ dnsblog/dnsblog.c.
+
+20110314
+
+ Portability: the SUN compiler had trouble with a pointer
+ expression of the form ``("text1" "text2") + constant'' so
+ we don't try to be so clever. Fix by Victor Duchovni. File:
+ global/mail_params.h.
+
+20110320
+
+ Feature: specify "enable_long_queue_ids = yes" to enable
+ support for non-repeating queue IDs (also used as queue
+ file names). These queue IDs encode the time and inode
+ number with a safe alphabet of the 52 characters 0-9B-Zb-z.
+ The alphabet excludes vowels (AEIOUaeiou) to avoid creating
+ real words. The queue ID format is: time in seconds, time
+ in microseconds, 'z', inode number (the inode number is
+ encoded without using the 'z' character of the safe alphabet).
+ Turning on long queue IDs changes the width of the first
+ output column of the mailq (postqueue -p) command, and
+ changes the appearance of Postfix Message-ID headers to
+ queueID@myhostname. Files: global/file_id.[hc],
+ global/safe_ultostr.[hc], global/mail_queue.[hc],
+ postsuper/postsuper.c, showq/showq.c
+
+20110321
+
+ Performance: with long queue file names, queue hashing now
+ produces the same result as with short names. Postfix uses
+ the hexadecimal representation of the file creation time
+ in microseconds, instead of the beginning of the file name
+ which changes once every year or so, a problem that was
+ reported by Victor Duchovni. The base 16 encoding gives
+ finer control over the number of directories than possible
+ with base 52 encoding. Files: global/mail_queue.[hc]. This
+ change requires "postfix reload".
+
+20110322
+
+ Cleanup: preserve the microseconds value when renaming
+ long->short or short->short queue file names. As a side
+ benefit, renaming long->short queue IDs will not change the
+ result from queue hashing. File: postsuper/postsuper.c.
+
+20110323
+
+ Bitrot: qshape regexp pattern for long queue file names.
+ Ralf Hildebrandt. File: auxiliary/qshape/qshape.pl.
+
+ Bitrot: text about queue ID reuse in the postsuper manpage.
+ File: postsuper/postsuper.c.
+
+20110328
+
+ Cleanup: don't log warnings about socket shutdown() errors
+ after a connection breaks. Postfix calls shutdown() to avoid
+ unnecessary socket write timeouts. This is only an optimization,
+ and failure is not critical. File: global/smtp_stream.c.
+
+20110411
+
+ Cleanup: postscreen(8) and verify(8) daemons now lock their
+ respective cache file exclusively upon open, to avoid massive
+ cache corruption by unsupported sharing. Files: util/dict.h,
+ util/dict_open.c, verify/verify.c, postscreen/postscreen.c.
+
+20110414
+
+ Bugfix (introduced with Postfix SASL patch 20000314): don't
+ reuse a server Cyrus SASL handle after authentication
+ failure. File: smtpd/smtpd_proto.c.
+
+20110418
+
+ Bugfix (introduced Postfix 2.3 and Postfix 2.7): the Milter
+ client reported some "file too large" errors as temporary
+ errors. Problem reported by Michael Tokarev. Files:
+ milter/milter8.c, cleanup/cleanup_milter.c.
+
+20110420
+
+ Performance: a high load of DSN success notification requests
+ could stall the queue manager. Solution: make the trace
+ client asynchronous, just like the bounce and defer clients.
+ Problem reported by Eduardo M. Stelmaszczyk of terra.com.br.
+ Files: global/abounce.[hc], *qmgr/qmgr_active.c (the
+ qmgr_active.c files are identical).
+
+20110421
+
+ Cleanup: updated abounce warning message, and added a safety
+ timeout to abounce() etc. requests. File: global/abounce.c.
+
+20110426
+
+ Bugfix (introduced in Postfix 1.1, duplicated in Postfix
+ 2.3, unrelated mistake in Postfix 2.7): the local(8) delivery
+ agent ignored table lookup errors in mailbox_command_maps,
+ mailbox_transport_maps, fallback_transport_maps and (while
+ bouncing mail to alias) alias owner lookup. Problem reported
+ by William Ono. Files: local/command.c, local/mailbox.c,
+ local/unknown.c, local/bounce_workaround.c.
+
+20110516
+
+ Update the warning when permit_naked_ip_address is used,
+ and add permit_sasl_authenticated to the list of suggested
+ alternatives. File: smtpd/smtpd_check.c.
+
+20110601
+
+ Bugfix (introduced Postfix 2.6 with master_service_disable)
+ loop control error when parsing a malformed master.cf file.
+ Found by Coverity. File: master/master_ent.c.
+
+20110602
+
+ Bugfix (introduced: Postfix 2.7): "sendmail -t" reported
+ "protocol error" after queue file write error. File:
+ postdrop/postdrop.c.
+
+20110605
+
+ Cleanup: removed the PSC_STATE_FLAG_CACHE_EXPIRED flag.
+ Nothing uses this anymore. Files: postscreen/postscreen.h,
+ postscreen/postscreen_state.c, postscreen/postscreen_tests.c.
+
+20110614
+
+ Linux kernel version 3 support. Linus Torvalds has reset
+ the counters for reasons not related to changes in code.
+ Files: makedefs, util/sys_defs.h.
+
+20110615
+
+ Workaround: some Spamhaus RHSBL rejects lookups with "No
+ IP queries" even if the name has an alphanumerical prefix.
+ We play safe, and skip both RHSBL and RHSWL queries for
+ names ending in a numerical suffix. File: smtpd/smtpd_check.c.
+
+20110624
+
+ Cleanup: added error checks for smtpd access primitives
+ that don't automatically terminate the program after table
+ lookup error: these primitives are permit_tls_clientcerts,
+ permit_tls_all_clientcerts, and check_address_map (the last
+ one is used in local_header_rewrite_clients only). File:
+ smtpd/smtpd_check.c.
+
+20110729
+
+ Workaround: some getpwnam() and getpwuid() implementations
+ cause mail to bounce ("user unknown") after LDAP etc. lookup
+ error. Postfix now uses POSIX getpwnam_r() and getpwuid_r()
+ where available. Initially, this workaround supports FreeBSD,
+ Solaris and Linux. Files: makedefs, util/sys_defs.h,
+ global/mypwd.[hc], local/alias.c, local/dotforward.c,
+ local/include.c, local/mailbox.c, local/recipient.c.
+
+20110731
+
+ MacOS X 10.5 supports POSIX getpwnam_r() and getpwuid_r()
+ (source: MacOS manpages at www.freebsd.org). If MacOS turns
+ out to make a false promise, then we will undo this change.
+ Files: makedefs, util/sys_defs.h.
+
+20110810
+
+ Cleanup: optimize an optimization to avoid uid->name lookup
+ when all users are authorized with authorized_submit_users,
+ authorized_mailq_users, authorized_flush_users. File:
+ global/user_acl.c.
+
+20110811
+
+ Workaround: report a {client_connections} Milter macro value
+ of zero instead of garbage, when the remote SMTP client is
+ not subject to any smtpd_client_* limits. Problem reported
+ by Christian Roessner. Files: smtpd/smtpd_state.c,
+ proto/MILTER_README.html.
+
+20110817
+
+ Cleanup: avoid misleading error messages after future code
+ change. The tls_bio_ops(3) module now returns non-zero errno
+ values only when requests fail due to a system-call error.
+ File: tls/tls_bio_ops.c.
+
+ Cleanup: TLS handshake error messages. The SMTP client and
+ server now report STARTTLS network errors as "connection
+ timed out", "connection reset by peer", etc., instead of
+ reporting TLS error number 0. Files: tls/tls_bio_ops.c,
+ tls/tls_server.c, tls/tls_client.c.
+
+20110818
+
+ Cleanup: VSTREAM-over-TLS error return values, for robustness
+ against future change. For consistency with VSTREAM internal
+ interfaces, the tls_stream(3) read/write routines now return
+ -1 instead of unspecified negative OpenSSL results. File:
+ tls/tls_stream.c.
+
+20110819
+
+ Cleanup: further TLS code cleanups, for robustness against
+ future change. Unexpected TLS errors are no longer silently
+ treated as ordinary errors, and one corner-case error in TLS
+ timeout handling was fixed before it could cause trouble.
+ File: tls/tls_bio_ops.c.
+
+20110821-24
+
+ Cleanup: simplified the TLS read/write deadline implementation,
+ and documented why this same simplification is not possible
+ higher-up, at the VSTREAM level. Files: tls/tls_bio_ops.c,
+ util/vstream.c.
+
+20110831
+
+ Bugfix: allow for Milters that send an SMTP server reply
+ without RFC 3463 enhanced status code. Reported by Vladimir
+ Vassiliev. File: milter/milter8.c.
+
+20110902
+
+ Cleanup: don't log vstream_tweak "connection reset by peer"
+ errors. File: util/vstream_tweak.c.
+
+20110904-7
+
+ Bugfix: master daemon panic with "master_spawn: at process
+ limit", when "postfix reload" reduces the process limit
+ from (a value larger than the current process count for
+ some service) to (a value <= the current process count),
+ and then a new connection is made to that service. This
+ structural solution centralizes the decision to monitor a
+ service port (or not). To improve robustness against future
+ code changes, it clarifies some of the internal dependencies
+ that exist inside the master daemon. Files: master/master.h,
+ master/master_avail.c, master/master_conf.c,
+ master/master_service.c, master/master_spawn.c.
+
+20110911
+
+ Debugging: report the request size when memory allocation
+ fails. File util/mymalloc.c.
+
+20110914
+
+ Incompatibility: the default inet_protocols value is now
+ "all" instead of "ipv4", meaning use both IPv4 and IPv6.
+ As a compatibility workaround for sites without global IPv6
+ connectivity, the commands "make upgrade" and "postfix
+ upgrade-configuration" append "inet_protocols = ipv4" to
+ main.cf when no explicit setting is present. This compatibility
+ workaround will be phased out in a future release. Files:
+ util/sys_defs.h, conf/post-install, proto/postconf.proto.
+
+ Incompatibility: the default smtp_address_preference value
+ is now "any" instead of "ipv6", meaning choose randomly
+ between IPv6 and IPv4. With this the Postfix SMTP client
+ will have more success delivering mail to sites that have
+ problematic IPv6 configurations. Files: global/mail_params.h,
+ proto/postconf.proto.
+
+20110918
+
+ Workaround for multiple ancient FreeBSD getsockopt() bugs
+ after non-blocking connect fails with 'host unreachable'
+ that resulted in a unreasonable memory allocation request.
+ File: util/vstream_tweak.c.
+
+20110921
+
+ Bugfix (introduced: Postfix 1.1): smtpd(8) did not sanitize
+ newline characters in cleanup(8) REJECT messages, causing
+ them to be sent out via SMTP as bare newline characters.
+ This happened when a REJECT pattern matched multi-line
+ header text. Discovered by Kevin Locke. File: smtpd/smtpd.c.
+
+20110922
+
+ Bugfix (introduced: Postfix 2.1): smtpd(8) sent multi-line
+ responses from a before-queue content filter as text with
+ bare instead of . Found during code maintenance.
+ File: smtpd/smtpd_proxy.c.
+
+20111011
+
+ Cleanup: for consistency with the SMTP standard, the
+ smtp_line_length_limit default value was increased from 990
+ characters to 998 (i.e. 1000 characters including ).
+ File: global/mail_params.h, proto/postconf.proto.
+
+ Cleanup: the Postfix sendmail command now always transforms
+ all input lines ending in into UNIX format (lines
+ ending in ). This simplifies integration with third-party
+ mail generating applications. Specify "sendmail_fix_line_endings
+ = strict" to restore historical Postfix behavior (i.e. convert
+ all input lines ending in only if the first input
+ line ends in ). Files: sendmail/sendmail.c,
+ global/mail_params.h, proto/postconf.proto.
+
+20111017
+
+ Cleanup: refined the heuristic that automagically transforms
+ legacy "sendmail -V" VERP requests into contemporary "sendmail
+ -XV" syntax. File: sendmail/sendmail.c.
+
+ Cleanup: when the cleanup daemon goes into discard mode,
+ don't get stuck when it runs onto milter file descriptor
+ information. File: cleanup/cleanup.c.
+
+20111020
+
+ EAI Future-proofing: don't apply strict_mime_encoding_domain
+ checks to unknown message subtypes such as message/global*.
+ File: global/mime_state.c.
+
+20111025
+
+ Bugfix (introduced: Postfix 2.8): postscreen sent non-compliant
+ SMTP responses (220- followed by 421) when it could not
+ hand off a connection to a real smtpd process, causing some
+ remote SMTP clients to bounce mail. The fix redirects the
+ client to the dummy SMTP engine which sends the 421 reply
+ at the first legitimate opportunity. Problem reported by
+ Ralf Hildebrandt. Files: postscreen/postscreen_send.c,
+ postscreen/postscreen_smtpd.c, postscreen/postscreen.h.
+
+20111102
+
+ Workaround: to improve inter-operability with broken remote
+ SMTP servers, the Postfix SMTP client by default no longer
+ appends the "AUTH=<>" option to the MAIL FROM command.
+ Specify "smtp_send_dummy_mail_auth = yes" to restore the
+ old behavior.
+
+20111106
+
+ Feature: "postconf -M" support to show Postfix's idea of
+ what is in the master.cf file. File: postconf/postconf.c.
+
+ Feature: postconf "-f" option to "nicely" format long lines
+ from main.cf or master.cf. File: postconf/postconf.c.
+
+20111108
+
+ Cleanup: postconf finally supports dynamic configuration
+ parameter names: parameters whose name depend on a mail
+ delivery transport or spawn service in master.cf, and
+ parameters whose names are specified with smtpd_restriction_classes
+ in main.cf. This adds 70 parameters to the "postconf" output,
+ more if additional mail delivery transports are defined in
+ master.cf. File: postconf/postconf.c.
+
+20111109
+
+ Cleanup: account for "," in smtpd_restriction_classes
+ value (Victor Duchovni). File: postconf/postconf.c.
+
+20111112
+
+ Cleanup: postconf finally warns about possible mis-typed
+ main.cf and master.cf parameter names (i.e. parameters that
+ aren't used anywhere), and it finally displays user-defined
+ main.cf parameters that *are* used. File: postconf/postconf.c.
+
+20111113
+
+ Portability: specify ``make makefiles "CCARGS=-DNO_NIS
+ ..."'' to build on systems without NIS support. Files:
+ makedefs, util/sys_defs.h.
+
+ Cleanup: documented the postconf algorithms and their
+ limitations, and added regression tests to speed up future
+ development. File: postconf/postconf.c
+
+20111117
+
+ Cleanup: postconf didn't "bless" type "inet" service names.
+
+ Cleanup: with pipelined sessions, smtp-sink flushed the
+ output too often. Reported by Mark Martinec. File:
+ smtpstone/smtp-sink.c.
+
+ Workaround: don't use IPv6 at build time. File: conf/main.cf.
+
+ Workaround: don't abort when IPv6 is present but busted.
+ File: util/inet_proto.c.
+
+ Portability: the Dovecot 2.0 authentication server supports
+ more socket types for its authentication server. File:
+ xsasl/xsasl_dovecot_server.c.
+
+ Documentation: the Dovecot 2.0 authentication server supports
+ communication over TCP sockets. Patrick Ben Koetter. File:
+ proto/SASL_README.html.
+
+20111118
+
+ Cleanup: "postconf -M" now supports filtering. For example,
+ "postconf -M inet" shows only services that listen on the
+ network, and "postconf -M smtp.unix" shows the SMTP delivery
+ agent. File: postconf.c.
+
+20111119
+
+ Cleanup: "postconf" commands in postfix-install needed to
+ be updated before master.cf was installed. Reported by
+ Sahil Tandon. File: postfix-install.
+
+20111120
+
+ Cleanup: support for parameter name spaces for master.cf
+ entries. With this, postconf should no longer log false
+ warnings for "-o user-defined-name=value" in master.cf. As
+ a benefit, it will warn for user-defined parameters with
+ "name=value" entries that are unused because they are hidden
+ by master.cf "-o name=value" entries with the same parameter
+ name. File: postconf/postconf.c.
+
+20111121
+
+ Cleanup: documentation fixes. File: postconf/postconf.c.
+
+ Cleanup: in postconf "main.cf management" mode, errors
+ opening master.cf are non-fatal. File: postconf/postconf.c.
+
+20111122
+
+ Documentation: examples to request VERP-style delivery at
+ SMTP time with the smtpd_command_filter feature. Files:
+ proto/VERP_README.html, proto/postconf.proto.
+
+ Feature: TLS certificate public-key fingerprint matching
+ (SMTP server and client), and TLS logging cleanup. Victor
+ Duchovni. Files: proto/SMTPD_POLICY_README.html,
+ proto/TLS_README.html, proto/postconf.proto, global/mail_proto.h,
+ smtpd/smtpd_check.c, tls/tls.h, tls/tls_client.c, tls/tls_misc.c,
+ tls/tls_proxy_print.c, tls/tls_proxy_scan.c, tls/tls_server.c,
+ tls/tls_stream.c, tls/tls_verify.c.
+
+ Documentation: complete list of "make makefiles" overrides.
+ File: proto/INSTALL.html.
+
+ Cleanup: postscreen now logs more than the first word of
+ non-SMTP commands. File: postscreen/postscreen_smtpd.c.
+
+20111124
+
+ Cleanup: eliminated false postconf "unused parameter"
+ warnings with legacy parameters such as $virtual_maps, and
+ with non-default parameter values for smtpd_expansion_filter
+ that can contain legitimate "$" without a macro name.
+
+ Cleanup: split postconf source into separate modules.
+ Files: postconf/postconf.c, postconf/postconf_builtin.c,
+ postconf/postconf_edit.c, postconf/postconf_main.c,
+ postconf/postconf_master.c, postconf/postconf_misc.c,
+ postconf/postconf_node.c, postconf/postconf_other.c,
+ postconf/postconf_service.c postconf/postconf_unused.c,
+ postconf/postconf_user.c, postconf/postconf.h.
+
+20111126
+
+ Bitrot: changes in error reporting to the under-documented
+ OpenLDAP API. Problem reported by Quanah Gibson-Mount. Fix
+ by Viktor Dukhovni. File: global/dict_ldap.c.
+
+ Cleanup: four-space indentation had become a tab character.
+ Files: postconf/postconf.h, postconf/test20.ref,
+ postconf/test21.ref.
+
+20111127
+
+ Cleanup: documented _suffix parameters that don't
+ show in postconf command output of earlier Postfix versions.
+ Files: proto/SMTPD_POLICY_README.html, proto/postconf.proto,
+ proto/SCHEDULER_README.html.
+
+ Cleanup: added the pipe(8) delivery agent to the list of
+ programs that implement transport_time_limit parameters.
+ File: postconf/postconf_service.c, postconf/test6.ref,
+ postconf/test22.ref.
+
+20111128
+
+ Feature: "postconf -C class,..." support to print parameters
+ in one or more classes (builtin= built-in parameter names,
+ service=service-defined parameter names, user=user-defined
+ parameter names). Files: postconf/postconf.c, postconf/postconf.h,
+ postconf_service.c, postconf/postconf_user.c.
+
+20111129
+
+ Cleanup: TLS logging level configuration. Files:
+ global/mail_params.h, smtp/lmtp_params.c, smtp/smtp.c,
+ smtp/smtp_params.c, smtp/smtp_proto.c, smtpd/smtpd.c,
+ tls/tls.h, tls/tls_client.c, tls/tls_misc.c, tls/tls_server.c,
+ tlsmgr/tlsmgr.c, tlsproxy/tlsproxy.c.
+
+20111203
+
+ Cleanup: time-dependent sender addresses of address
+ verification probes. Specify an address_verify_sender_ttl
+ value of several hours or more to frustrate address harvesting.
+ Files: global/verify_sender_addr.[hc], smtpd/smtpd.c,
+ smtpd/smtpd_check.c, verify/verify.c, proto/postconf.proto,
+ proto/ADDRESS_VERIFICATION_README.html.
+
+20111204
+
+ Cleanup: removed the log_level arguments from tls_client_start()
+ and tls_server_start() calls. This information is already
+ given to tls_client_init() and tls_server_init(). Files:
+ smtpd/smtpd.c, tlsproxy/tlsproxy.c, smtp/smtp_proto.c,
+ tls/tls.h, tls/tls_client.c, tls/tls_server.c, tls/tls_misc.c.
+
+20111205
+
+ Documentation: made the postconf(5) manpage more precise
+ in its use of "client" and "server"; reorganized the
+ TLS_README presentation of client configuration so that
+ most relevant information is presented earlier. Files:
+ proto/postconf.proto, proto/TLS_README.html.
+
+ Bugfix: tlsproxy(8) stored TLS sessions with a serverID of
+ "tlsproxy" instead of "smtpd", wasting an opportunity for
+ session reuse. File: tlsproxy/tlsproxy.c.
+
+20111206
+
+ Documentation: removed descriptions of Postfix < 2.3 user
+ interface from TLS_README. Users of earlier releases are
+ referred to TLS_LEGACY_README. File: proto/TLS_README.html.
+
+20111207
+
+ Cleanup: tlsproxy(8) now receives the session cache serverID
+ from its client (postscreen(8)). Files: global/mail_proto.h,
+ postscreen/postscreen_starttls.c, tlsproxy/tlsproxy.[hc],
+ tlsproxy_state.c.
+
+ Cleanup: the postscreen(8) daemon did not support a zero
+ cache cleanup interval. This is needed for memcache support.
+ File: postscreen/postscreen.c.
+
+ Bugfix (introduced: 20110227): null pointer bug while
+ updating dictionary owner attributes, after reading an empty
+ (database) configuration file. File: util/dict.c.
+
+20111208
+
+ Cleanup: db_common_parse_domain() could not be called without
+ preceding db_common_parse() call. Files: global/db_common.[hc].
+
+20111209
+
+ Feature: memcache client support. This implementation is
+ based on the under-documented libmemcache library, and
+ therefore supports only libmemcache version 1.4.0. Files:
+ conf/postfix-files, global/dict_memcache.[hc], global/mail_dict.c,
+ html/index.html, mantools/postlink, postconf/postconf.c,
+ postfix/postfix.c, proto/DATABASE_README.html,
+ proto/MEMCACHE_README.html, proto/memcache_table.
+
+20111209
+
+ Cleanup: support for scripted and manual database tests with
+ LDAP, *SQL, and memcache. Files: util/dict_test.c, util/dict.c,
+ global/mail_dict.c.
+
+ Workaround: apparently, some distributions use Postfix
+ shared libraries without proper so-number versioning. This
+ causes programs to fail mysteriously, after an update
+ replaces the Postfix library but not the program (someone
+ experienced this with an extra copy of the Postfix SMTP
+ server). Files: global/mail_version.[hc], master/*server.c,
+ master/master.c, src/postalias/postalias.c,
+ src/postdrop/postdrop.c, src/postfix/postfix.c,
+ src/postlog/postlog.c, src/postmap/postmap.c,
+ src/postmulti/postmulti.c, src/postqueue/postqueue.c,
+ src/postsuper/postsuper.c, src/sendmail/sendmail.c.
+
+20111211
+
+ Feature: first/next (sequence) support in the proxymap
+ protocol. This is needed for cache cleanup of a proxied
+ postscreen or verify persistent cache. Files:
+ global/dict_proxy.[hc], proxymap/proxymap.c.
+
+ Feature: memcache client support without libmemcache
+ dependencies. Files: global/memcache_proto.[hc],
+ global/dict_memcache.c.
+
+ Bugfix: missing lookup table entry and terminator, causing
+ proxymap(8) server segfault when postscreen(8) or verify(8)
+ attempted to access their cache via the proxymap(8) server.
+ This could never have worked anyway, because the Postfix
+ proxymap protocol did not support cache cleanup. File
+ util/dict.c.
+
+ Feature: support for persistent backup database in the
+ memcache client. The database can be shared with the proxymap
+ service, but it needs to be listed as "proxy:maptype:mapname"
+ in the proxy_read_maps or proxy_write_maps parameter value
+ (depending on whether the access is read-only or read-write).
+ Support for proxymap-over-tcp (proxy:maptype:mapname@host:port)
+ is under development. File: global/dict_memcache.c.
+
+20111214
+
+ Documentation: updated the submission and smtps examples
+ in the sample master.cf file, so that their logging is
+ easier to recognize. File: conf/master.cf.
+
+20111215
+
+ Documentation: use different hosts to separate MUA "port
+ 25" traffic from the "port 25" MX service. Files:
+ postscreen/postscreen.c, proto/POSTSCREEN_README.html.
+
+20111216
+
+ Cleanup: the proxymap client did not correctly propagate
+ the "open_lock" flag, causing the proxymap service to open
+ postscreen(8) and verify(8) caches twice, instead of once.
+ File: global/dict_proxy.c.
+
+ Cleanup: the verify and postscreen caches were not listed
+ as "authorized" for access via the proxywrite service. File:
+ global/mail_params.h.
+
+ Refactoring: the postscreen permanent access list code is
+ now a library module, so that it can be also used for remote
+ access to the proxymap server. Files: global/server_acl.[hc].
+
+ Hardening: read/write deadlines, to make the proxymap server
+ suitable for remote access. File: proxymap/proxymap.c.
+
+20111217
+
+ Cleanup: more orthogonal definition of when the proxymap
+ server can/cannot share a single map instance among multiple
+ requestors, and corresponding code cleanup in the proxymap
+ client and server. Files: util/dict.h, util/dict_test.c,
+ global/dict_proxy.c, proxymap/proxymap.c.
+
+ Human factors: the postscreen/verify cache manager now logs
+ the full database name including the proxy: prefix, to avoid
+ WTF surprises. File: util/dict_cache.c.
+
+20111218
+
+ Cleanup: more configurable memcache client error handling.
+ Files: global/dict_memcache.c, proto/memcache_table.
+
+ Feature: the Postfix SMTP server XCLIENT command now supports
+ the LOGIN attribute (e.g., login information from nginx).
+ Based on the nginx:xclient-login-patch from citrin.ru (Anton
+ Yuzhis). The patch was further enhanced to support SASL
+ login information everywhere in the Postfix SMTP server
+ without having to specify "smtpd_sasl_auth_enable = yes"
+ in main.cf. Files: smtpd.[hc], smtpd_sasl_glue.[hc],
+ smtpd_check.c, smtpd_sasl_proto.[hc], smtpd_state.c,
+ proto/XCLIENT_README.html.
+
+ Incompatibility: the Postfix SMTP server now always checks
+ the smtpd_sender_login_maps table, even without having
+ "smtpd_sasl_auth_enable = yes" in main.cf.
+
+20111219
+
+ Cleanup: the match_list-based primitives now provide an
+ option to return an error result instead of terminating the
+ process with a fatal error. Files: util/match_ops.[hc],
+ util/match_list.c, global/addr_list_match.c, domain_list.c,
+ string_list.c, namadr_list.c.
+
+ Cleanup: a "fail:" database type that reliably fails all
+ requests. The lookup table name specifies the internal error
+ result code. having this table facilitates a systematic
+ review of all Postfix table lookup error handling.
+
+ Cleanup: trivial-rewrite now "catches" errors with implicit
+ database lookups in virtual_alias_domains, relay_domains,
+ virtual_mailbox_domains, just like it already caught explicit
+ database lookup errors. This means there are fewer occasions
+ where trivial-rewrite clients will appear to hang. File:
+ trivial-rewrite/resolve.c.
+
+ Cleanup: a broken relay_domains table would cause many
+ Postfix processes to terminate with fatal error as they
+ initialized the flush() client (used by defer_append()
+ etc.). Postfix now logs a warning instead. File:
+ global/flush_clnt.c.
+
+ Cleanup: the Postfix SMTP server now "catches" errors with
+ implicit database lookups in mynetworks, TLS client certificate
+ tables, and local_header_rewrite_clients, and reports "server
+ configuration error" or "table lookup error" instead of
+ terminating with a fatal error. This is work in progress;
+ errors with opening a database may be covered later. Files:
+ smtpd/smtpd.c, smtpd/smtpd_check.c.
+
+20111220
+
+ Cleanup: the Postfix SMTP server now "catches" errors with
+ implicit database lookups in mynetworks, debug_peer_list,
+ smtpd_client_event_limit_exceptions, permit_mx_backup_networks.
+ This continues work started 20111219, and does not cover
+ errors with opening a database. Files: smtpd/smtpd.c,
+ smtpd/smtpd_checks.c, smtpd/smtpd_error.in, smtpd/smtpd_error.ref.
+
+ Cleanup: memory leak testing of error handling. File:
+ util/name_mask.c.
+
+20111222
+
+ Cleanup: memory leak testing of error handling. File:
+ util/name_mask.c.
+
+ Cleanup: simplified the match_list error reporting, thereby
+ reducing the footprint of the changes to "catch" errors
+ with implicit database lookups in mynetworks, and other
+ lists. Files: util/match_ops.[hc], util/match_list.c,
+ global/addr_list_match.c, domain_list.c, string_list.c,
+ namadr_list.c, trivial-rewrite/resolve.c, smtpd/smtpd.c,
+ smtpd/smtpd_check.c, global/flush_clnt.c, flush/flush.c.
+
+20111224
+
+ Cleanup: eliminated the global dict_errno variable that
+ made error reporting convenient but not necessarily precise.
+ This was a straightforward change except in the few modules
+ that propagate errors from one dictionary API to another:
+ dict_cache.c, dict_debug.c, maps.c, dict_memcache.c. Files:
+ src/cleanup/cleanup_map11.c, src/cleanup/cleanup_map1n.c,
+ src/global/addr_match_list.c, src/global/dict_ldap.c,
+ src/global/dict_memcache.c, src/global/dict_mysql.c,
+ src/global/dict_pgsql.c, src/global/dict_proxy.c,
+ src/global/dict_sqlite.c, src/global/domain_list.c,
+ src/global/flush_clnt.c, src/global/mail_addr_find.c,
+ src/global/mail_addr_map.c, src/global/maps.c, src/global/maps.h,
+ src/global/match_parent_style.h, src/global/namadr_list.c,
+ src/global/resolve_local.c, src/global/resolve_local.h,
+ src/global/server_acl.c, src/global/string_list.c,
+ src/local/alias.c, src/local/bounce_workaround.c,
+ src/local/mailbox.c, src/local/unknown.c, src/proxymap/proxymap.c,
+ src/qmqpd/qmqpd.c, src/smtp/smtp_map11.c, src/smtpd/smtpd_check.c,
+ src/trivial-rewrite/resolve.c, src/trivial-rewrite/transport.c,
+ src/util/dict.h, src/util/dict_alloc.c, src/util/dict_cache.c,
+ src/util/dict_cidr.c, src/util/dict_db.c, src/util/dict_debug.c,
+ src/util/dict_env.c, src/util/dict_fail.c, src/util/dict_ht.c,
+ src/util/dict_pcre.c, src/util/dict_regexp.c,
+ src/util/dict_static.c, src/util/dict_tcp.c, src/util/dict_test.c,
+ src/util/dict_thash.c, src/util/dict_unix.c, src/util/match_list.c,
+ src/util/match_list.h, src/util/match_ops.c, src/virtual/mailbox.c.
+
+20111226
+
+ Bugfix (introduced 20110426): after lookup error with
+ mailbox_transport_maps, mailbox_command_maps or
+ fallback_transport_maps, the local delivery agent did not
+ log the problem before deferring mail, and produced no defer
+ logfile record. Files: local/mailbox.c, local/unknown.c.
+
+20120102
+
+ Workaround: degrade gracefully when the network protocols
+ specified with inet_protocols are unavailable. Files:
+ global/mail_params.c, global/mynetworks.c, global/own_inet_addr.c
+ master/master_ent.c, master/master_vars.c, postscreen/postscreen.c,
+ qmqpd/qmqpd.c, smtp/smtp_connect.c, smtpd/smtpd.c,
+ util/inet_proto.c.
+
+20120107
+
+ Workaround: degrade gracefully when the "domain" feature
+ of LDAP, *SQL and memcache databases has a table lookup
+ problem. Files: global/db_common.c, global/dict_ldap.c,
+ global/dict*sql*.c, global/dict_memcache.c.
+
+ Cleanup: fixed memcache client error handling for things
+ that never happen. global/dict_memcache.c.
+
+ Future proofing: prepare postmap/postalias error logging
+ for future changes to database code. Files: postalias/postalias.c,
+ postmap/postmap.c.
+
+20120108
+
+ Cleanup: the postscreen(8) and verify(8) cache managers log
+ warnings at a reduced rate of one per second per cache
+ operation, to avoid logging large numbers of warnings about
+ a problem with low-value information. File: util/msg_rate_delay.c,
+ util/dict_cache.c.
+
+20120110
+
+ Cleanup: added logging for failed table lookups, and replaced
+ some "fatal" errors by warnings. Files: cleanup/cleanup_addr.c,
+ cleanup/cleanup_message.c, cleanup/cleanup_milter.c,
+ cleanup/cleanup_masquerade.c, global/header_body_checks.c,
+ global/smtp_stream.c, postscreen/postscreen_dnsbl.c,
+ postscreen/postscreen_smtpd.c, smtp/smtp_chat.c,
+ smtp/smtp_proto.c, smtp/smtp_sasl_auth_cache.c,
+ smtp/smtp_sasl_glue.c, smtp/smtp_session.c, smtp/smtp_trouble.c,
+ smtpd/smtpd.c, smtpd/smtpd_check.c.
+
+20120114
+
+ Cleanup: gradual degradation after database file open errors.
+ Instead of terminating immediately with a "fatal" error, a
+ Postfix daemon logs an error and continues execution with
+ reduced functionality. In other words, features that don't
+ depend on the unavailable table will keep working. However,
+ for the sake of sanity, the number of such errors over the
+ life of a process is limited to 13. Files:
+ src/global/cfg_parser.c, src/util/dict_thash.c,
+ src/util/dict_cidr.c, src/util/dict_nis.c, src/util/dict_nisplus.c,
+ src/global/dict_ldap.c, src/global/dict_mysql.c,
+ src/global/dict_pgsql.c, src/global/dict_sqlite.c,
+ src/postconf/postconf_main.c, src/global/mail_conf.c,
+ src/util/dict.h, src/util/dict.c, src/global/dict_memcache.c,
+ src/util/dict_tcp.c, src/util/dict_unix.c, src/util/dict_pcre.c,
+ src/util/dict_regexp.c, src/master/trigger_server.c,
+ src/master/single_server.c, src/master/multi_server.c,
+ src/master/event_server.c, src/util/dict_test.c,
+ src/util/dict_surrogate.c, src/util/dict_alloc.c, src/util/msg.c,
+ src/util/dict_cdb.c, src/util/dict_dbm.c, src/util/msg.h,
+ src/util/dict_db.c.
+
+ Incompatibility: the Postfix SMTP server no longer reports
+ transcripts of sessions where a client command is rejected
+ because a table is unavailable. To receive such reports,
+ add the new "data" class to the notify_classes parameter
+ value. The reports will be sent to the error_notice_recipient
+ address as before. This class is also used by the Postfix
+ SMTP client to report about sessions that fail because a
+ table is unavailable. Files: global/mail_error.[hc],
+ smtpd/smtpd_check.c, smtp/smtp_trouble.c.
+
+20120115
+
+ Fine tuning: SMTP server error messages. File: smtpd/smtpd.c.
+
+ Fine tuning: documentation. Files: proto/MEMCACHE_README.html.
+ proto/memcache_table.html.
+
+ Apply "gradual degradation" also when an unsupported database
+ *type* is specified. File: util/dict_open.c.
+
+ Cleanup: tiny memory leaks after surrogate database opens.
+ Files: util/dict_cidr.c, util/dict_db.c.
+
+20120117
+
+ Cleanup: support for legacy-style database configuration
+ where parameter names are generated by appending suffixes
+ to the database name. Files: postconf/postconf_dbms.c.
+
+ Other: build without Berkeley DB support (make makefiles
+ "CCARGS=$CCARGS -DNO_DB"). Files: makedefs, util/sys_defs.h,
+ proto/DB_README.html, proto/INSTALL.html.
+
+20120120
+
+ Compatibility: added file pflogsumm_quickfix.txt with quick
+ patches for pflogsumm that handle the new default master.cf
+ entries for the submission and smtps services.
+
+20120121
+
+ Cleanup: getopt(3) compatibility in the postconf(1) master.cf
+ parser. Process "--" as the end-of-options indicator, and
+ process "-oname=value" as "-o name=value". Files:
+ util/argv.[hc], postconf/postconf_master.cf,
+ postconf/postconf_user.c.
+
+20120122
+
+ Workaround: log a warning and suggested solution for common
+ stat()/fstat()/lstat() problems caused by 32-bit overflow.
+ This is a real stinker that causes Postfix to fail without
+ any prior warning. File: util/warn_stat.[hc], and everything
+ that directly calls stat(), fstat() or lstat().
+
+20120127
+
+ Bugfix (introduced: Postfix 2.8): the Postfix client sqlite
+ quoting routine returned the unquoted result instead of the
+ quoted text. The opportunities for misuse are limited,
+ because Postfix sqlite files are usually owned by root, and
+ Postfix daemons usually run with non-root privileges so
+ they can't corrupt the database. Problem reported by Rob
+ McGee (rob0). File: global/dict_sqlite.c.
+
+20120130
+
+ Bugfix (introduced: Postfix 2.3): the trace service did not
+ distinguish between DSN SUCCESS notifications for a non-bounce
+ or a bounce message. This code pre-dates DSN support and
+ should have been updated when it was re-purposed to handle
+ DSN SUCCESS notifications. Problem reported by Sabahattin
+ Gucukoglu. File: bounce/bounce_trace_service.c.
+
+20120202
+
+ Bugfix (introduced: Postfix 2.3): the "change header" milter
+ request could replace the wrong header. A long header name
+ could match a shorter one, because a length check was done
+ on the wrong string. Reported by Vladimir Vassiliev. File:
+ cleanup/cleanup_milter.c.
+
+20120214
+
+ Bugfix (introduced: Postfix 2.4): extraneous null assignment
+ caused core dump when postlog emitted the "usage" message.
+ Reported by Kant (fnord.hammer). File: postlog/postlog.c.
+
+20120217
+
+ Bugfix (introduced 20111219): sendmail -bs segfault, due
+ to a missing guard statement after an smtpd_check_rewrite()
+ call was moved closer to the command processor loop. Fix
+ by Bartek Szady. File: smtpd/smtpd.c.
+
+20120220
+
+ Cleanup: documentation of how to use only system-supplied
+ certificates with *CAfile and *CApath. File: proto/postconf.proto.
+
+ Cleanup: documentation of smtp_sasl_mechanism_filter. File:
+ proto/postconf.proto.
+
+20120222
+
+ Cleanup: when multiple DNSBLs block an SMTP client, the
+ postscreen "reject" message now gives credit to the DNSBL
+ with the largest weight, instead of the DNSBL that replies
+ first. File: postscreen/postscreeb_dnsbl.c.
+
+ Cleanup: memcache_table(5) manpage. File proto/memcache_table.
+
+20120225
+
+ Cleanup: eliminated the build-time Perl dependency. File:
+ bounce/annotate.sh.
+
+ Cleanup: when -DNO_DB support was added, the makedefs script
+ was not updated to skip the Linux Berkeley DB tests.
+
+ FreeBSD9 is now a supported platform. Files: makedefs,
+ util/sys_defs.h.
+
+20120226
+
+ Cleanup: documentation in postfix-install.
+
+20120229
+
+ Feature: smtpd_log_access_permit_actions to enable logging
+ of specific permit-like actions in Postfix SMTP server
+ access lists. Files: mantools/postlink, proto/postconf.proto,
+ global/mail_params.h, smtpd/smtpd.c, smtpd/smtpd_check.c.
+
+20120306
+
+ To improve the interaction with start-up scripts, "postfix
+ start" now waits for master daemon process initialization
+ to complete, and returns a non-zero exit status if daemon
+ initialization failed or if it did not complete in a
+ reasonable amount of time. This involves a new "-w" master
+ option. Files: conf/postfix-script, master/master.c,
+ master/master.h. master/master_monitor.c.
+
+20120307
+
+ postconf -X option to exclude parameters from main.cf
+ (require two-finger action, because this is irreversible).
+ Files: postconf/postconf.[hc], postconf/postconf_edit.c.
+
+20120317
+
+ Feature: Sendmail-style socketmap. Files: util/dict_sockmap.[hc],
+ util/netstring.[hc], proto/DATABASE_README.html,
+ postconf/postconf.c.
+
+20120330
+
+ Workaround: specify "\c" at the start of an smtp_reject_footer
+ template to suppress the line break between the reply text
+ and the footer text. Files: global/smtp_reply_footer.c,
+ proto/postconf.proto.
+
+20120401
+
+ Bugfix (introduced Postfix 2.6): irrelevant memory leak
+ that was introduced with postconf -#. File:
+ postconf/postconf_edit.c.
+
+ Bitrot: shut up useless warnings about Cyrus SASL call-back
+ function pointer type mis-matches. Files: xsasl/xsasl_cyrus.h,
+ xsasl/xsasl_cyrus_server.c, xsasl/xsasl_client.c.
+
+20120404
+
+ Cleanup: added smtpd_sender_login_maps to the default
+ proxy_read_maps value. Files: global/mail_params.h,
+ proxymap/proxymap.c.
+
+ Cleanup: weed out stale TODO's from the WISHLIST, and moved
+ some CYA text from WISHLIST into the code. Files: WISHLIST,
+ smtpd/smtpd_proxy.c.
+
+20120407
+
+ Bugfix (introduced: 20120330): don't replace
+ by when a reply footer starts
+ with \c and contains no \n. File: global/smtp_reply_footer.c.
+
+20120422
+
+ Bit-rot: OpenSSL 1.0.1 introduces new protocols. Update the
+ known TLS protocol list so that protocols can be turned off
+ selectively to work around implementation bugs. Based on
+ a patch by Victor Duchovni. Files: proto/TLS_README.html,
+ proto/postconf.proto, tls/tls.h, tls/tls_misc.c, tls/tls_client.c,
+ tls/tls_server.c.
+
+20120425
+
+ Workaround: bugs in 10-year old gcc versions break compilation
+ with #ifdef inside a macro invocation (NOT: definition).
+ Files: tls/tls.h, tls/tls_client.c, tls/tls_server.c.
+
+20120426
+
+ Bugfix (introduced Postfix 2.9): the postconf command flagged
+ parameters defined in master.cf as "unused" when they were
+ used only in main.cf. Problem reported by Michael Tokarev.
+ Files: postconf/postconf_user.c, postconf/test4b.ref,
+ postconf Makefile.in.
+
+20120513
+
+ Cleanup: report both the first and last line number when a
+ malformed main.cf entry spans multiple lines, instead of
+ reporting the last line number only. File: util/dict.c,
+ util/line_number.[hc].
+
+20120516
+
+ Workaround: apparently, FreeBSD 8.3 kqueue notifications
+ sometimes break when a dnsblog(8) process loses an accept()
+ race on a shared socket, resulting in repeated "connect to
+ private/dnsblog service: Connection refused" warnings. This
+ condition is unique to dnsblog(8). The postscreen(8) daemon
+ closes a postscreen-to-dnsblog connection as soon as it
+ receives a dnsblog(8) reply, resulting in hundreds or
+ thousands of connection requests per second. All other
+ multi-server daemons such as anvil(8) or proxymap(8) have
+ connection lifetimes ranging from 5s to 1000s depending on
+ server load. The workaround is for dnsblog to use the
+ single_server driver instead of the multi_server driver.
+ This one-line code change eliminates the accept() race
+ without any Postfix performance impact. Problem reported
+ by Sahil Tandon. File: dnsblog/dnsblog.c.
+
+ Logging: postscreen now logs a warning when a dnsblog(8)
+ request takes longer than the hard-coded time limit of 10s.
+ File: postscreen/postscreen_dnsbl.c.
+
+20120517
+
+ Workaround: to avoid crashes when the OpenSSL library is
+ updated without "postfix reload", the Postfix TLS session
+ cache ID now includes the OpenSSL library version number.
+ Note: this problem cannot be fixed in tlsmgr(8). Code by
+ Victor Duchovni. Files: tls/tls_server.c, tls_client.c.
+
+20120520
+
+ Bugfix (introduced Postfix 2.4): the event_drain() function
+ was comparing bitmasks incorrectly causing the program to
+ always wait for the full time limit. This error affected
+ the unused postkick command, but only after s/fifo/unix/
+ in master.cf. File: util/events.c.
+
+ Cleanup: laptop users have always been able to avoid
+ unnecessary disk spin-up by doing s/fifo/unix/ in master.cf
+ (this is currently not supported on Solaris systems).
+ However, to make this work reliably, the "postqueue -f"
+ command must wait until its requests have reached the pickup
+ and qmgr servers before closing the UNIX-domain request
+ sockets. Files: postqueue/postqueue.c, postqueue/Makefile.in.
+
+20120522
+
+ Robustness: set LC_ALL=C in post-install to avoid surprises
+ when parsing output from Postfix or non-Postfix commands.
+ File: postfix-install.
+
+20120611
+
+ Bugfix (introduced: 20031216-21): with soft_bounce=yes, the
+ SMTP client did not move on to the next MX host or fallback
+ relay after a 5xx reply. File: smtp/smtp_trouble.c.
+
+20120527-8
+
+ Infrastructure: limited support to shrink VSTREAM buffers.
+ The change takes place when reading from (a stream for the
+ first time | an empty buffer) or when writing to (a stream
+ for the first time | a full buffer). TODO: the change should
+ also happen after purging or flushing a buffer. File:
+ util/vstream.c.
+
+20120531-617
+
+ Feature: haproxy support in postscreen(8) and smtpd(8). To
+ enable, specify "smtpd_upstream_proxy_protocol = haproxy"
+ or "postscreen_upstream_proxy_protocol = haproxy". Files:
+ mantools/postlink, proto/postconf.proto, global/Makefile.in,
+ global/haproxy_srvr.c, global/haproxy_srvr.h, global/mail_params.h,
+ global/mail_proto.h, master/single_server.c, master/multi_server.c,
+ master/event_server.c, postscreen/Makefile.in,
+ postscreen/postscreen.c, postscreen/postscreen.h,
+ postscreen/postscreen_endpt.c, postscreen/postscreen_haproxy.c,
+ postscreen/postscreen_haproxy.h, postscreen/postscreen_send.c,
+ postscreen/postscreen_state.c, smtpd/Makefile.in, smtpd/smtpd.h,
+ smtpd/smtpd_peer.c, smtpd/smtpd_sasl_glue.c, smtpd/smtpd_haproxy.c,
+ util/Makefile.in, util/listen.h, util/recv_pass_attr.c,
+ util/stream_listen.c, util/sys_defs.h, util/unix_pass_listen.c.
+
+20120618
+
+ Cleanup: made the postscreen-to-smtpd haproxy attribute
+ transmission more robust for Solaris. Files: util/sys_defs.h,
+ util/connect.h, util/steam_listen.c, postscreen/postscreen_send.c.
+
+ Cleanup: simplified the "stream used" workaround. Files:
+ util/vstream.h, master/event_server.c, master/multi_server.c.
+
+20120621
+
+ Cleanup: simplified workarounds for Solaris streams versus
+ UNIX-domain sockets. Files: util/pass_accept.c (new),
+ util/pass_trigger.c (new), util/stream_pass_connect.c
+ (deleted), util/unix_pass_listen.c (deleted),
+ util/unix_pass_trigger.c (deleted), updated header files,
+ and replaced PASS_XXX macros by pass_xxx function calls.
+
+ Cleanup: don't clobber errno when logging a problem.
+ File util/msg_output.c.
+
+20120627
+
+ Bugfix (introduced: 20120531-617): in the postscreen module
+ for HAproxy sypport, a VSTREAM buffer size request was not
+ LP64-clean. File: postscreen/postscreen_haproxy.c.
+
+ Cleanup: avoid single-character reads in the postscreen
+ HAproxy module. File: postscreen/postscreen_haproxy.c.
+
+20120628
+
+ Workaround: heuristic to detect missing (ssize_t) type-cast
+ in VSTREAM buffer size requests. File: util/vstream.c.
+
+20120629
+
+ Workaround: "sendmail -bl" emulation. File: sendmail/sendmail.c.
+
+20120630
+
+ Cleanup: sub-optimal hash performance on systems where the
+ "char" type is signed. Files: util/htable.c, util/binhash.c.
+
+20120702
+
+ Bugfix (introduced: 19990127): the BIFF client leaked an
+ unprivileged UDP socket. Fix by Jaroslav Skarvada. File:
+ local/biff_notify.c.
+
+20120713
+
+ Bugfix (introduced: 20120527-8): infrastructure to specify
+ a smaller-than-default VSTREAM buffer, without the complex
+ run-time checks. File: util/vstream.c, vstream_tweak.c.
+
+20120714
+
+ Cleanup: semantics of requests to query or modify the VSTREAM
+ buffer size that will be used with the next read(2) or
+ write(2) operation. Files: util/vstream.c, util/vstream.h,
+ util/vstream_tweak.c.
+
+20120717
+
+ Documentation: update to RFC5321.
+
+20120730
+
+ Bugfix (introduced: 20000314): AUTH is not allowed after
+ MAIL. Timo Sirainen. Files: smtpd/smtpd.c, smtpd/smtpd.h,
+ smtpd/smtpd_sasl_proto.c.
+
+20120801
+
+ Documentation: point of what virtual_xxx parameters are
+ specific to the virtual(8) delivery agent, and will have
+ no effect when mail is delivered with a different program.
+ Files: proto/postconf.proto, proto/VIRTUAL_README.html.
+
+20120824
+
+ Feature: support for "sendmail -R hdrs|full". Jan Kundr?t.
+ File: sendmail/sendmail.c.
+
+20120902
+
+ Documentation: updated TUNING_README with new pointers to
+ the STRESS_README and POSTSCREEN_README documents. Miscellaneous
+ documentation clarifications based on postfix-users discussions.
+
+20120903
+
+ Bugfix (introduced 20120317): the socketmap client should
+ not share unrelated client endpoint handles. File:
+ util/dict_sockmap.c.
+
+20120907
+
+ Cleanup (for change 20120824): the DSN RET attribute should
+ not be stored once per recipient. It is a message property
+ just like DSN ENVID. File: sendmail/sendmail.c.
+
+20120911
+
+ Documentation: more explicit enumeration of what happens
+ when setting a per-destination recipient limit value to 1.
+ File: proto/postconf.proto.
+
+20120918
+
+ Documentation: clarified the bounce/queue_life-time parameter
+ descriptions. File: proto/postconf.proto.
+
+20120920
+
+ Documentation: the postscreen_whitelist_interfaces parameter
+ syntax was defined only by example. File: proto/postconf.proto.
+
+20120923
+
+ Infrastructure: cleaned up the support for database
+ lock-on-open. This is needed for databases that are not
+ multi-updater safe. Files: util/dict_alloc.c, util/dict.c,
+ util/dict_open.c, util/dict.h. tls/tls_scache.c.
+
+20120924
+
+ Documentation: some people are read-challenged distribute
+ their own incorrect understanding of master.cf syntax.
+ File: proto/master.
+
+ Cleanup: don't emulate UNIX-domain sockets over FIFOs on
+ Solaris systems less than 10 years old. This allows us to
+ globally s/fifo/unix/ in master.cf. Files: makedefs,
+ util/sys_defs.h.
+
+ Laptop-friendliness: avoid disk spin-up on idle systems by
+ s/fifo/unix/ in master.cf. Files: conf/master.cf.
+
+20120928-30
+
+ Feature: smtpd_relay_restrictions, proposed long ago by
+ Victor. The idea is to separate the mail relay policy from
+ the spam blocking policy, so that a permissive spam blocking
+ policy under smtpd_recipient_restrictions will no longer
+ unexpectedly result in a permissive mail relay policy.
+
+ This involves a change in default settings. Similar to the
+ way that local_recipient_maps was introduced, there is a
+ safety net that prevents unexpected mail bounces when a
+ site upgrades to Postfix 2.10 or later, and there is no
+ change in documented smtpd_recipient_restrictions behavior.
+ See the RELEASE_NOTES file for details. Files:
+ global/mail_params.h, smtpd/smtpd.c, smtpd/smtpd_check.c,
+ proto/postconf.proto, proto/SMTPD_ACCESS_README.html,
+ mantools/postlink, conf/post-install, RELEASE_NOTES.
+
+20120931-1001
+
+ Documentation: updated the remainder of the README files
+ and manual pages that discuss smtpd_recipient_restrictions.
+
+20121001
+
+ Cleanup: prepend 5.1.1 status code to "User unknown in
+ virtual alias table". File: trivial-rewrite/resolve.c.
+
+20121003
+
+ Bugfix: the postscreen_access_list feature was case-sensitive
+ in the first character of permit, reject, etc. Reported by
+ Francis Picabia. File: global/server_acl.c.
+
+20121009
+
+ Documentation: interaction between delay_warning_time,
+ notify_classes and delay_notice_recipient. File:
+ proto/postconf.proto.
+
+20101009
+
+ Human factors: log a warning that the postcat option -m
+ without -h or -b has no effect. File: postcat/postcat.c.
+
+20121010
+
+ Bugfix (introduced: Postfix 2.5): memory leak in program
+ initialization. Reported by Coverity. File: tls/tls_misc.c.
+
+ Bugfix (introduced: Postfix 2.3): memory leak in the unused
+ oqmgr program. Reported by Coverity. File: oqmgr/qmgr_message.c.
+
+20121011
+
+ Documentation: how to enable /etc/hosts multi-record lookups
+ with main.cf settings. File: proto/LINUX_README.html.
+
+ Documentation: clarified the postscreen-tlsproxy interface.
+ File: tlsproxy/tlsproxy.c.
+
+20121012
+
+ Documentation: a simpler null-client example. File:
+ proto/STANDARD_CONFIGURATION_README.html
+
+20121013
+
+ Cleanup: to compute the LDAP connection cache lookup key,
+ join the numeric fields with null, just like string fields.
+ Viktor Dukhovni. File: global/dict_ldap.c.
+
+20121015
+
+ Documentation: added section on regular-expression tables
+ to the aliases(5) manpage. File: proto/aliases.
+
+ Documentation: why "smtp_address_preference = any" is the
+ preferred setting. File: proto/postconf.proto.
+
+20121022
+
+ Bugfix (introduced 20101009) don't complain about stray -m
+ option if none of -[bhm] is specified. Ralf Hildebrandt.
+ File: postmap/postmap.c.
+
+20121029
+
+ Workaround: strip datalink suffix from IPv6 addresses
+ returned by the system getaddrinfo() routine. Such suffixes
+ mess up the default mynetworks value, host name/address
+ verification and possibly more. This change obsoletes the
+ 20101108 change that removes datalink suffixes in the SMTP
+ and QMQP servers. Files: util/myaddrinfo.c, smtpd/smtpd_peer.c,
+ qmqpd/qmqpd_peer.c.
+
+20121031
+
+ Bugfix: smtpd_relay_restrictions compatibility shim did not
+ detect "empty" value. Sahil Tandon. The same problem existed
+ with the inet_protocols shim. File: conf/post-install.
+
+20121105
+
+ Cleanup: the postscreen(8) "deep protocol" tests now log
+ the SMTP command that precedes a protocol violation. Files:
+ postscreen/postscreen_smtpd.c, proto/POSTSCREEN_README.html.
+
+ Bugfix (introduced: Postfix 1.1): wrong string termination
+ when handling an MBOX From_ line at the start of a message.
+ File: qmqpd/qmqpd.c.
+
+20121110
+
+ Cleanup: specify $(WARN) on the MacOS X compiler command
+ line to suppress "nested comment" and possibly other unwanted
+ warnings. Problem reported by Jim Reid. File: makedefs,
+ Makefile.in.
+
+20121119
+
+ Documentation: added a note that key_format is required
+ when postscreen(8) and verify(8) share the same memcache
+ (with different persistent backup databases, or course)
+ otherwise automatic cache cleanup breaks due to a name
+ collision for the "last cache cleanup" database record.
+ File: proto/memcache.
+
+20121122
+
+ Cleanup: the safety-check for smtpd_recipient_restrictions
+ and smtpd_relay_restrictions now detects permit before
+ reject. File: smtpd/smtpd_check.c.
+
+ Cleanup: the safety-check for smtpd_recipient_restrictions
+ and smtpd_relay_restrictions is no longer case-sensitive.
+ File: smtpd/smtpd_check.c.
+
+20121123
+
+ Cleanup: consistent escaping of commands in postscreen deep
+ protocol test logging. File: postscreen/postscreen_smtpd.c.
+
+20121124
+
+ Documentation: the bounce behavior for automatically-added
+ BCC recipients has changed with Postfix 2.3 when DSN support
+ was introduced. File: proto/postconf.proto.
+
+20121203
+
+ Documentation: added explicit example for -o name=value.
+ File: proto/master.
+
+20121210
+
+ Bugfix (introduced: Postfix 2.9) nesting count error while
+ stripping the optional [] around a DNS[BW]L address pattern.
+ This part of the code is not documented and had escaped
+ testing. Files: util/ip_match.c, util/ip_match.in,
+ util/ip_match.ref.
+
+20121215
+
+ Bugfix (introduced: 19980218, when recipient_delimiter
+ support was added): The error message for unknown local
+ users (or missing required aliases) should report the user
+ name instead of the full localpart which may contain an
+ address extension. Problem reported by Christian Holler.
+ File: local/unknown.c.
+
+20121221
+
+ Feature: "postconf -x" support to expand $name in main.cf
+ parameter values. Files: postconf/postconf_main.c,
+ postconf/postconf.h, postconf/postconf_node.c, postconf/postconf.c.
+
+20121222
+
+ Feature: postconf support to warn about an attempt to modify
+ a read-only parameter (process_name etc.) in main.cf or
+ master.cf. Files: postconf/postconf_readonly.c,
+ postconf/postconf_builtin.c.
+
+20121223
+
+ Feature: postconf support to warn about an undefined $name
+ in a parameter value in main.cf or master.cf (except for
+ backwards-compatibility parameters such as $virtual_maps)
+ Files: postconf/postconf_user.c, postconf_dbms.c,
+ postconf_builtin.c, util/dict_ht.c, util/htable.c.
+
+ Feature: "postconf -Mx" support to expand $name in master.cf
+ parameter values. Files: postconf/postconf_master.c,
+ postconf/postconf_lookup.c, postconf/postconf_main.c,
+ postconf/postconf.c.
+
+20121224
+
+ Feature: "postconf -Mn" support to print only master.cf
+ entries that have "-o name=value" parameter setttings.
+ Files: postconf/postconf_master.c.
+
+20121226
+
+ Miscellaneous cleanups of postconf internal APIs, identifiers
+ and comments. No changes in behavior.
+
+ Bugfix (omission in feature 20111203): the SMTP server only
+ supported time-dependent address-verification sender addresses
+ with RCPT TO but not with MAIL FROM. File: smtpd/smtpd.c.
+
+20121227
+
+ Feature: "postconf -o name=value" support to override main.cf
+ settings (for example, "postconf -x -o stress=whatever"
+ shows effective settings under overload). Files:
+ postconf/postconf.c, postconf/postconf_main.c.
+
+20121230
+
+ Cleanup: postconf(1) master.cf options parser. Files:
+ postconf/postconf_master.c, postconf/postconf_user.c.
+
+ Bugfix (omission in feature 20111106): the postconf(1)
+ master.cf options parser didn't support "clusters" of
+ command-line option letters. Files: postconf/postconf_master.c,
+ postconf/test40.ref.
+
+20130105
+
+ Undo a change made around 20121224, and always whitelist
+ configuration parameter names for legacy-style proxy:ldap:prefix
+ etc. lookup tables. Files: postconf/postconf_dbms.c,
+ postconf/test28.ref, postconf/test29.ref, postconf/Makefile.in.
+
+20130107
+
+ Factor out the master.cf line parser so that it can be
+ reused for "postconf -Me". File: postconf/postconf_master.c.
+
+20130113
+
+ Feature: master.cf attribute namespace. "postconf -F" shows
+ individual master.cf fields as "service/type/attribute =
+ value", where attribute is "service", "type", "private",
+ "unprivileged", "wakeup", "process_limit", or "command".
+
+20130121
+
+ Bugfix (introduced 20120307): the postconf -X option erased
+ other options. File: postconf/postconf.c.
+
+20130131
+
+ Bugfix: the local(8) delivery agent dereferenced a null
+ pointer while delivering to null command (for example, "|"
+ in a .forward file). Reported by Gilles Chehade.
+
+20130203
+
+ Bugfix: the undocumented OpenSSL X509_pubkey_digest()
+ function is unsuitable for computing certificate PUBLIC KEY
+ fingerprints. Postfix now provides a correct procedure
+ that accounts for the algorithm and parameters in addition
+ to the key data. Specify "tls_legacy_public_key_fingerprints
+ = yes" if you need backwards compatibility. Fix by Victor
+ Duchovni, BC added by Wietse. Files: tls/tls_verify.c,
+ tls/tls_misc.c, proto/TLS_README.html, global/mail_params.h.
+
+20130210
+
+ Bugfix: an error handler for smtp_tls_policy_maps lookups
+ was never invoked. File: smtp/smtp_session.c.
+
+20130212
+
+ Cleanup: logfile message formatting (X: subject_CN=X,
+ issuer_CN=X, fingerprint=X, pkey_fingerprint=X). File:
+ tls/tls_client.c.
+
+20130315
+
+ Feature: LMDB (memory-mapped persistent file) support by
+ Howard Chu. This implementation has unexpected failure modes
+ that don't exist with other Postfix databases, so don't
+ just yet abandon CDB. See LMDB_README for details. Files:
+ proto/postconf.proto, proto/LMDB_README.html,
+ proto/DATABASE_README.html, proto/INSTALL.html util/dict_lmdb.[hc],
+ util/dict_open.c, global/mkmap_lmdb.[hc], global/mkmap_open.c,
+ postconf/postconf.c.
+
+20130316
+
+ Cleanup: new Postfix dictionary API flag to control the use
+ of (LMDB) bulk database transactions. With this, LMDB
+ databases no longer fail to commit any transactions with
+ tlsmgr(8), and LMDB databases no longer perform glacially
+ slow with postmap -i/postalias -i. Files: util/dict.h,
+ util/dict_lmdb.c, postmap/postmap.c, postalias/postalias.c.
+
+20130317
+
+ Debugging: generalized setting of dictionary API flags.
+ File: util/dict.[hc], util/dict_test.c.
+
+ Robustness: Postfix programs can now recover from LMDB
+ "database full" errors without requiring human intervention.
+ When a program opens an LMDB file larger than lmdb_map_size/3,
+ it logs a warning and uses a larger size limit instead.
+ Files: util/dict_lmdb.c, proto/LMDB_README.html.
+
+20130318
+
+ Portability: botched #ifdef. File: util/dict_lmdb.c.
+
+20130319
+
+ Postfix support for LMDB databases is suspended due to the
+ existence of a hard limit (an "out of storage" failure mode
+ that cannot be resolved by increasing the database size).
+
+ Postfix may support LMDB again when it no longer limits the
+ size of Postfix transactions, whether the limit is built
+ into LMDB itself, or implicit by requiring an unbounded
+ amount of memory to handle a large transaction.
+
+20130322
+
+ Documentation: smtp_skip_5xx_greeting wording updated to
+ reflect text in RFC 2821, which appears to say that a 554
+ greeting is not a hard delivery error (note that RFC 2821
+ was published later than smtp_skip_5xx_greeting). File:
+ proto/postconf.proto.
+
+20130324
+
+ Workaround: MacOS 10.8 (Darwin 12) getrlimit(RLIMIT_NOFILE)
+ incorrectly reports that rlim_max, the hard limit on the
+ number of open files per process, is equal to RLIM_INFINITY
+ (i.e. no limit is enforced). In reality, setrlimit(RLIMIT_NOFILE)
+ rejects requests where rlim_cur, the current limit, contains
+ any value > kern.maxfilesperproc. Axel Luttgens. File:
+ util/open_limit.c.
+
+ Portability: MacOS 10.8 (Darwin 12) kqueue support works.
+ Axel Luttgens. Files: makedefs.
+
+20130324
+
+ Support for anonymous certificates. Viktor Dukhovni. File:
+ tls/tls_verify.c.
+
+ Feature: support for DNSSEC-validated lookups and TLSA
+ RRsets. Viktor Dukhovni. Files: dns/Makefile.in, dns/dns.h,
+ dns/dns_lookup.c, dns/dns_rr.c, dns/dns_strtype.c,
+ dns/test_dns_lookup.c,
+
+ Cleanup: the personality switch between "smtp" and "lmtp".
+ This streamlines the switch in the SMTP/LMTP protocol, DNS
+ MX lookups, and configuration parameter names in error
+ messages. Viktor Dukhovni. Files: smtp/smtp.c, smtp/smtp.h,
+ smtp/smtp_chat.c, smtp/smtp_connect.c, smtp/smtp_proto.c,
+ smtp/smtp_rcpt.c, smtp/smtp_sasl_glue.c, smtp/smtp_sasl_proto.c,
+ smtp/smtp_session.c, smtp/smtp_state.c.
+
+ Feature: replace disable_dns_lookups with smtp_dns_support_level,
+ enable secure DNSSEC lookups in the Postfix SMTP client,
+ and use the DNSSEC-validated remote SMTP server name to
+ select the SMTP and TLS policies. Viktor Dukhovni. Files:
+ dns/Makefile.in, dns/dns.h, dns/dns_lookup.c, dns/dns_rr.c,
+ dns/dns_strtype.c, dns/test_dns_lookup.c.
+
+20130325
+
+ Portability: on MacOS X, use kqueue() for event handling
+ but use select() instead of poll() for read/write timeouts
+ (with a workaround to handle file decriptors >=FD_SETSIZE).
+ Files: util/sys_defs.h, util/readable.c, util/writable.c,
+ util/read_wait.c, util/write_wait.c.
+
+ Portability: support for NetBSD 5.x, NetBSD 6.x and DragonFly
+ BSD. Viktor Dukhovni. Files: makedefs, util/sys_defs.h.
+
+20130326
+
+ Cleanup: new module that consolidates all system-dependent
+ code to enforce read/write timeouts. This includes a final
+ workaround for MacOS X that uses poll() first, and select()
+ if that fails. This makes their /dev/urandom workaround
+ unnecessary. Files: util/poll_fd.c, util/iostuff.h. Removed:
+ util/readable.c, util/writable.c, util/read_wait.c,
+ util/write_wait.c.
+
+ Cleanup: refactor TLS digest functions, improved signature
+ for TLS session cache. Viktor Dukhovni. Files: smtp/smtp.c,
+ smtp/smtp_proto.c, smtpd/smtpd.c, tls/Makefile.in, tls/tls.h,
+ tls/tls_client.c, tls/tls_fprint.c, tls/tls_level.c,
+ tls/tls_misc.c, tls/tls_server.c, tls/tls_verify.c,
+ tlsproxy/tlsproxy.c.
+
+20130327
+
+ Cleanup: final polish for MacOSX workarounds; replaced
+ #ifdef MacOSX by feature test as required by PORTING document.
+ Files: util/poll_fd.c, util/open_limit.c.
+
+ Export tls_fprint() and tls_digest_encode() for use in DANE.
+ Viktor Dukhovni. Files: tls/tls.h, tls/tls_fprint.c.
+
+20130331
+
+ Refactoring: TLS verification callback processing in
+ preparation for DANE support. Viktor Dukhovni. Files:
+ tls/tls.h, tls/tls_client.c, tls/tls_misc.c, tls/tls_verify.c.
+
+ Refactoring: split off SMTP client per-session TLS policy
+ data and code in preparation for DANE support. Viktor
+ Dukhovni. Files: smtp/Makefile.in, smtp/smtp.h,
+ smtp/smtp_connect.c, smtp/smtp_proto.c, smtp/smtp_reuse.c,
+ smtp/smtp_session.c, smtp/smtp_tls_sess.c.
+
+ Cleanup: "zero time limit" corner case in read_wait() and
+ write_wait() emulation. Files: util/poll_fd.c, util/iostuff.h.
+
+20130401
+
+ Refactoring: allow smtp_session_alloc() to fail gracefully
+ and report an error.
+
+20130403
+
+ Documentation: in smtpd.c, the comment that justifies the
+ 454 reply for "TLS unavailable" cited the wrong RFC.
+
+20130404
+
+ Human factors: warning when a main.cf parameter has multiple
+ entries with different values. File: util/dict.c.
+
+20130405
+
+ Feature: the recipient_delimiter parameter can now specify
+ a set of characters. A user name is now separated from its
+ address extension by the first character that matches the
+ recipient_delimiter set. Files: proto/postconf.proto,
+ src/global/mail_addr_find.c, src/global/mail_params.c,
+ src/global/split_addr.c, src/global/split_addr.h,
+ src/global/strip_addr.c, src/global/strip_addr.h,
+ src/global/strip_addr.ref, src/local/bounce_workaround.c,
+ src/local/local.c, src/local/local_expand.c, src/local/recipient.c,
+ src/local/resolve.c, src/oqmgr/qmgr_message.c, src/pipe/pipe.c,
+ src/qmgr/qmgr_message.c, src/smtpd/smtpd.c,
+ src/smtpd/smtpd_check.c, src/trivial-rewrite/transport.c,
+ src/trivial-rewrite/trivial-rewrite.c.
+
+ Feature: support for trust anchors, i.e. CA certificates
+ or public keys that will be used instead of conventional
+ root certificates, and revised fingerprint support. This
+ can be used by itself, and this provides support for an
+ upcoming DANE implementation. Victor Duchovni. Files:
+ mantools/postlink, proto/TLS_README.html, proto/postconf.proto,
+ global/mail_params.h, smtp/lmtp_params.c, smtp/smtp.c,
+ smtp/smtp.h, smtp/smtp_params.c, smtp/smtp_proto.c,
+ smtp/smtp_session.c, smtp/smtp_state.c, smtp/smtp_tls_sess.c,
+ tls/Makefile.in, tls/tls.h, tls/tls_client.c, tls/tls_dane.c,
+ tls/tls_fprint.c, tls/tls_misc.c, tls/tls_verify.c,
+ util/argv.c, util/argv.h.
+
+20130409
+
+ Documentation: pointers to other actions under "ACCEPT
+ ACTIONS" and "REJECT ACTIONS". File: proto/access.
+
+20130410
+
+ Cleanup: more uniform permutation in dns_rr() by Victor
+ Duchovni & Son. File: dns/dns_rr.c.
+
+20130411
+
+ Documentation: clarified text about result formats. Files:
+ proto/canonical, proto/virtual.
+
+20130414
+
+ Cleanup: the SMTP client connection management code now
+ maintains iterator state with a structure that contains
+ next-hop, host name, address, port and other information.
+ This iterator structure replaces random variables that were
+ updated by add-hoc code, and replaces random function
+ argument lists. The more structured approach is easier to
+ maintain and has already paid off by exposing opportunities
+ to improve SMTP connection cache usage. Wietse Venema.
+ Files: smtp/smtp.h, smtp/smtp_connect.c, smtp/smtp_session.c,
+ smtp_reuse.c.
+
+ Cleanup: eliminated minor false SMTP connection cache-sharing
+ problems due to mis-aligned lookup keys for caches and
+ lookup tables (for example some used the nexthop, and some
+ the domain name). Information that is used in more than
+ one lookup key is now generated by a centralized function.
+ This replaces ad-hoc code in random places that was
+ concatenating ad-hoc data to construct lookup keys. The
+ more structured approach is easier to maintain and makes
+ future cache-sharing issues easier to prevent. Wietse
+ Venema. Files: smtp/smtp.h, smtp/smtp_connect.c, smtp_reuse.c,
+ smtp_key.c, smtp_tls_sess.c.
+
+ Cleanup and fix of non-production code: the trust anchor-digest
+ code and smtp_sess_tls_required() function. Victor Duchovni.
+ Files: smtp/smtp_connect.c, smtp/smtp_proto.c,
+ smtp/smtp_tls_sess.c, tls/tls.h, tls/tls_client.c,
+ tls/tls_dane.c, tls/tls_level.c, tls/tls_verify.c.
+
+20130417
+
+ Cleanup and fix of non-production code: add the SASL
+ credentials or absence thereof to the connection cache
+ endpoint label; better reuse of SASL-authenticated connections
+ over UNIX-domains sockets, however unlikely these may be;
+ a first step towards refinement of connection cache lookup
+ by IP addres for plaintext or SASL-unauthenticated connections.
+ Files: smtp/smtp.h smtp/smtp_connect.c, smtp/smtp_reuse.c,
+ smtp/smtp_key.c, smtp/smtp_tls_sess.s.
+
+20130418
+
+ Cleanup: configurable field delimiter and optional "not
+ available" field place holder for cache and table lookup
+ keys; automatic base64 encoding for key fields that contain
+ these. Files: smtp/smtp_key,c, smtp/smtp_reuse.c,
+ smtp/smtp_proto.c, smtp/smtp_tls_sess.c.
+
+20130420-21
+
+ Documentation: "dane" TLS security level and parameters.
+ Viktor Dukhovni. Files: mantools/postlink, proto/TLS_README.html,
+ proto/postconf.proto.
+
+ Feature: implemented and enabled DNS-based DANE security
+ level. Viktor Dukhovni. Files: global/mail_params.h,
+ smtp/lmtp_params.c, smtp/smtp.c, smtp/smtp.h, smtp/smtp_params.c,
+ smtp/smtp_proto.c, smtp/smtp_tls_sess.c, tls/tls.h,
+ tls/tls_client.c, tls/tls_dane.c, tls/tls_fprint.c,
+ tls/tls_level.c, tls/tls_misc.c, util/Makefile.in,
+ util/ctable.c, util/ctable.h, util/timecmp.c, util/timecmp.h.
+
+ Cleanup: rename (unchanged) smtp_tls_sess.c to smtp_tls_policy.c.
+ Viktor Dukhovni. Files: smtp/Makefile.in, smtp/smtp_tls_policy.c,
+ smtp/smtp_tls_sess.c.
+
+ Portability: OpenSSL workarounds for versions before 0.9.7
+ are removed from the source code. Viktor Dukhovni. Files:
+ tls/tls.h, tls/tls_bio_ops.c, tls/tls_client.c.
+
+ Non-production fixes: when falling back from opportunistic
+ TLS to plaintext, don't modify the cached TLS policy "retry
+ as plaintext" and "level" members. Files: smtp/smtp_session.c.
+
+ Non-production fixes: move TLS policy lookup to the main
+ connection iterator loop, so that the policy is known before
+ attempting connection reuse and before SMTP connection
+ creation. Temporarily link session->tls to state->tls.
+ Files: smtp/smtp.h, smtp/smtp_connect.c, smtp/smtp_reuse.c,
+ smtp/smtp_tls_policy.c.
+
+20130422
+
+ Feature: smtptls-finger test program for SMTP over TLS.
+ Viktor Dukhovni. Files: Makefile.in, html/Makefile.in,
+ man/Makefile.in, mantools/postlink, posttls-finger/.indent.pro,
+ posttls-finger/Makefile.in, posttls-finger/posttls-finger.c,
+ posttls-finger/tlsmgrmem.c, posttls-finger/tlsmgrmem.h,
+ tls/tls.h, tls/tls_misc.c.
+
+20130423
+
+ Bugfix (introduced: Postfix 2.0): when myhostname is not
+ listed in mydestination, the trivial-rewrite resolver may
+ log "do not list in both mydestination
+ and ". The fix is
+ to re-resolve a domain-less address after adding $myhostname
+ as the surrogate domain, so that it pops out with the right
+ address-class label. Problem reported by Quanah Gibson-Mount.
+ File: trivial-rewrite/resolve.c.
+
+20130425
+
+ Non-production fixes: revert to using proxies (sender,
+ nexthop, hostname) to distinguish between different SASL
+ credentials for connections to the same IP address and port.
+ Files: smtp/smtp.h smtp/smtp_connect.c, smtp/smtp_key.c.
+
+ Non-production cleanup: documentation, identifiers. Viktor
+ Dukhovni. Files: proto/postconf.proto, src/dns/dns.h,
+ src/dns/dns_lookup.c, src/dns/dns_rr.c, src/dns/test_dns_lookup.c,
+ src/global/mail_proto.h, src/posttls-finger/posttls-finger.c,
+ src/smtp/smtp.h, src/smtp/smtp_addr.c, src/smtp/smtp_connect.c,
+ src/smtp/smtp_session.c, src/smtp/smtp_tls_policy.c,
+ src/smtpd/smtpd_check.c, src/tls/tls.h, src/tls/tls_client.c,
+ src/tls/tls_dane.c, src/tls/tls_fprint.c, src/tls/tls_misc.c,
+ src/tls/tls_proxy_clnt.c, src/tls/tls_proxy_print.c,
+ src/tls/tls_proxy_scan.c, src/tls/tls_server.c,
+ src/tls/tls_verify.c.
+
+20130426
+
+ Non-production fixes: refinement of SASL-dependent context
+ for connection-cache reuse, documentation. Viktor Dukhovni
+ and Wietse Venema. Files: smtp/smtp.h, smtp/smtp_key.c,
+ tls/tls_client.c.
+
+20130506
+
+ Non-production bugfix: macros must use distinct names for
+ temporary variables, to avoid name collision problems.
+ Problem report: Ralf Hildebrandt. Problem fix: Viktor
+ Dukhovni. File: smtp/smtp.h.
+
+ Non-production cleanup: simplified "dane" user interface,
+ replacing one "dane" security level plus multiple fall-back
+ options, with two "dane" security levels, one opportunistic
+ and one mandatory. Viktor Dukhovni. Files: proto/TLS_README.html,
+ proto/postconf.proto, mantools/postlink, proto/TLS_README.html,
+ proto/postconf.proto, global/mail_params.h,
+ posttls-finger/posttls-finger.c, smtp/lmtp_params.c,
+ smtp/smtp.c, smtp/smtp.h, smtp/smtp_params.c,
+ smtp/smtp_tls_policy.c, tls/tls.h, tls/tls_level.c.
+
+20130512
+
+ Feature: allow an SMTP client to skip postscreen(8) tests
+ before or after the 220 greeting, based on its DNSBL score.
+ Suggested by Rob McGee (/dev/rob0). Files: mantools/postlink,
+ proto/postconf.proto, global/mail_params.h,
+ postscreen/postscreen.c, postscreen/postscreen.h,
+ postscreen/postscreen_early.c, postscreen/postscreen_state.c,
+ postscreen/postscreen_tests.c.
+
+20130513
+
+ Bugfix (introduced: 20130512): postscreen logged no "PASS
+ NEW" event when the pregreet tests were turned off and the
+ postscreen_dnsbl_whitelist_treshold feature was turned on.
+ Reported by Rob McGee (/dev/rob0). Files: postscreen/postscreen.h,
+ postscreen/postscreen_early.c.
+
+ Bugfix (introduced: 20130512): postscreen panic because the
+ logic for dnsbl result retrieval was changed. Reported by
+ Noel Jones. File: postscreen/postscreen_early.c.
+
+20130517
+
+ Cleanup: just like the postscreen DNS block test will use
+ partial scores when some DNS lookup result is unavailable,
+ the postscreen_dnsbl_whitelist_treshold feature will now
+ use partial scores instead of ignoring them. File:
+ postscreen/postscreen_early.c.
+
+20130518
+
+ Bugfix (introduced: 1997): memory leak after error while
+ forwarding mail through the cleanup server. Viktor found
+ one, Wietse eliminated the rest. File: local/forward.c.
+
+ Feature: posttls-finger protocol and cipher grade selection
+ options. Leave protocol debug flags active across reconnects,
+ only suppress redundant logging of the certificate details.
+ Viktor Dukhovni. File: posttls-finger/posttls-finger.c.
+
+ Robustness: send SNI even when trying to reuse a DANE
+ session, because a new session may be negotiated anyway.
+ Viktor Dukhovni. File: tls/tls_client.c.
+
+ Cleanup: eliminate variable that is redundant with respect
+ to more authoritative state. Viktor Dukhovni. File:
+ posttls-finger/posttls-finger.c.
+
+ Feature: new tls_ssl_options parameter to enable OpenSSL
+ features (as opposed to tls_disable_workarounds which is
+ disables bug workarounds that are on by default). Viktor
+ Dukhovni. Files: proto/TLS_README.html, proto/postconf.proto,
+ src/global/mail_params.h, src/tls/tls.h, src/tls/tls_client.c,
+ src/tls/tls_misc.c.
+
+20130520
+
+ Documentation: removed resolve_null_domain from the list
+ of smtpd(8) parameters. File: smtpd/smtpd.c.
+
+20130523
+
+ Documentation: add cidr: and texthash: to the list of maps
+ that don't have automatic change detection. File:
+ proto/DATABASE_README.html.
+
+ Documentation: define the netmask format of CIDR maps.
+ File: proto/cidr_table.
+
+20130530
+
+ Cleanup: replace alloca() with mymalloc()/myfree() for
+ better error handling. Reported by Bill Parker. File:
+ util/dict_ni.c (does anyone still use this code?).
+
+20130531
+
+ Feature: tls_wildcard_matches_multiple_labels (default:
+ yes) to match multiple DNS labels with "*" in wildcard
+ certificates. Viktor Dukhovni. Files: proto/postconf.proto,
+ mantools/postlink, global/mail_params.h, tls/tls_client.c,
+ tls/tls_misc.c.
+
+20130607
+
+ Bugfix (DANE support): with multiple TLSA RR that carry "x
+ 0 0" certificates or "x 1 0" keys, Postfix failed to reset
+ the cert/key pointer before calling d2i_mumble(), causing
+ OpenSSL to clobber the previous cert or key. Viktor Dukhovni.
+ tls/tls_dane.c.
+
+ Robustness: check that TLSA-supplied certs have valid keys.
+ It is not clear whether that check is performed in d2i().
+ Viktor Dukhovni. tls/tls_dane.c.
+
+20130608
+
+ Cleanup (DANE support): be more explicit in the logging of
+ object digests. Viktor Dukhovni. tls/tls_dane.c.
+
+20100613
+
+ Workaround: unhelpful down-stream maintainers fail to install
+ the new smtpd_relay_restrictions safety net, causing breakage
+ that could have been avoided. We now hard-code the safety
+ net instead. Files: global/mail_params.h, conf/post-install,
+ RELEASE_NOTES_2.10.
+
+ Bugfix (DANE support): when TLSA records are insecure,
+ report that none are found. Viktor Dukhovni. Files:
+ posttls-finger/posttls-finger.c, smtp/smtp_tls_policy.c,
+ tls/tls_dane.c.
+
+20130615
+
+ TLS Interoperability: turn on SHA-2 digests by force. This
+ improves interoperability with clients and servers that
+ deploy SHA-2 digests without the required support for
+ TLSv1.2-style digest negotiation. Based on patch by Viktor
+ Dukhovni. Files: tls/tls_client.c, tls/tls_server.c.
+
+20130616
+
+ Workaround: The Postfix SMTP server TLS session cache was
+ broken because OpenSSL now enables session tickets by
+ default, resulting in different ticket encryption key for
+ each smtpd(8) process. the workaround turns off session
+ tickets. In 2.11 we'll enable session tickets properly.
+ Viktor Dukhovni. File: tls/tls_server.c.
+
+ Updated DANE support (trust in DNS instead of PKI). With
+ OpenSSL 1.0.2 (under development) trusted certificates don't
+ need to be self-signed roots. Otherwise we use an ephemeral
+ root certificate to sign the trust anchor. Viktor Dukhovni.
+ Files: posttls-finger/posttls-finger.c, smtp/smtp_proto.c,
+ smtp/smtp_tls_policy.c, tls/tls.h, tls/tls_client.c,
+ tls/tls_dane.c, tls/tls_fprint.c, tls/tls_misc.c,
+ tls/tls_verify.c.
+
+20130619
+
+ Documentation: troff lint. Patch by ES Raymond's bot. File:
+ proto/header_checks.
+
+ Cleanup: enforce smtpd_client_recipient_rate_limit for VRFY
+ commands. File: smtpd/smtpd.c.
+
+20130622
+
+ Bugfix: typo in the 20130613 smtpd_relay_restrictions default
+ setting. File: global/mail_params.h.
+
+20130623
+
+ Cleanup: configurable tlsmgr(8) service name. Files:
+ mantools/postlink, proto/postconf.proto, tls/tls_mgr.c,
+ tls/tls_misc.c, tlsproxy/tls-proxy.c, smtp/smtp.c,
+ smtpd/smtpd.c.
+
+20130629
+
+ Cleanup: documentation. Files: proto/CONNECTION_CACHE_README.html,
+ proto/SCHEDULER_README.html.
+
+20130708
+
+ Cleanup: postscreen_upstream_proxy_protocol setting. Files:
+ global/mail_params.h, postscreen/postscreen_endpt.c.
+
+20130709
+
+ Cleanup: qmgr documentation clarification by Patrik Rak.
+ Files: proto/SCHEDULER_README.html, qmgr/qmgr_job.c.
+
+ Cleanup: re-indented code. File: qmgr/qmgr_job.c.
+
+ Logging: minimal DNAME support. Viktor Dukhovni. dns/dns.h,
+ dns/dns_lookup.c, dns/dns_strtype.c, dns/test_dns_lookup.c.
+
+20130710
+
+ Workaround: smtp_connection_reuse_count_limit (default 0,
+ i.e. unlimited) for sites that must deal with hostile
+ connection reuse policies. The documentation comes with a
+ warning that this feature introduces a "fatal attractor"
+ failure mode. Files: global/mail_params.h, mantools/postlink,
+ proto/postconf.proto, smtp/smtp.c, smtp/smtp_params.c,
+ smtp/lmtp_params.c, smtp/smtp.h.
+
+ Workaround: FreeBSD9 nroff outputs ANSI escape sequences
+ instead of overstrike sequences. To make matters worse, it
+ uses the ESC[0m sequence sometimes for end-of-bold and
+ sometimes for end-of-italic. File: mantools/man2html.
+
+20130714
+
+ Cleanup: added smtpd_relay_restrictions entries to the
+ default master.cf file, so that main.cf settings won't
+ affect the submission and smtps services. Simon Matter.
+ File: conf/master.cf.
+
+20130728
+
+ Cleanup: wrong function name in error message. John Fawcett.
+ File: util/vstring_vstream.c.
+
+20130801
+
+ Cleanup: with ``make makefiles CCARGS="-DHAS_DB...'', the
+ makedefs script no longer tries to locate the Linux Berkeley
+ DB include and library files. Instead it assumes that the
+ locations are given on the command line, as shown in the
+ DB_README examples. Leo Baltus. File: makedefs.
+
+20130805
+
+ Documentation: clarified reject_non_fqdn_helo_hostname.
+ File: proto/postconf.proto.
+
+20130809
+
+ Cleanup: the lmdb_map_size parameter is now a long integer.
+ Howard Chu. Files: global/mail_params.[hc].
+
+20130815
+
+ Documentation: added pointer to Dovecot 2 configuration.
+ File: proto/SASL_README.html
+
+20130818
+
+ Update: LMDB client updated to LMDB 0.9.7, which hopefully
+ fixes the unrecoverable "transaction full" error. With a
+ new MDB_MAP_FULL workaround by Howard Chu that ensures that
+ postfix will make progress as long as the disk is not full.
+ File: util/dict_lmdb.c.
+
+20130822
+
+ The status of LMDB databases is "not recommended". Unlike
+ other Postfix databases, LMDB does not grow beyond a specified
+ limit even when the file system has room. This show-stopper
+ bug breaks applications whose requirements grow with load:
+ postscreen(8), greylisting, tlsmgr(8) and verify(8).
+
+20130825
+
+ Bitrot: Arrange for shared keys in SMTP server session
+ tickets. Otherwise, with clients that enable session
+ tickets, the SMTP session cache is per-process and largely
+ ineffective. Older releases should add SSL_OP_NO_TICKET
+ to the SSL options bit mask in the SMTP server only. The
+ session ticket key validity interval (sum of initial issuing
+ and retired key validation intervals) must not exceed the
+ SSL session lifetime. Otherwise, clients may send valid
+ tickets for expired sessions, which the OpenSSL server code
+ mishandles (does not send a replacement ticket, patch
+ pending...).
+
+ We set the session lifetime to 2 times the configured cache
+ lifetime which is also the ticket issuing and retired
+ validation lifetime, so ticketed sessions last 1 to 2 times
+ the configured session lifetime and never longer than a
+ session's expiration time.
+
+ Code by Viktor Dukhovni. Files: .indent.pro, mantools/postlink,
+ proto/TLS_README.html, proto/postconf.proto, global/mail_params.h,
+ posttls-finger/posttls-finger.c, posttls-finger/tlsmgrmem.c,
+ smtpd/smtpd.c, tls/tls.h, tls/tls_client.c, tls/tls_mgr.c,
+ tls/tls_mgr.h, tls/tls_scache.c, tls/tls_scache.h,
+ tls/tls_server.c, tlsmgr/tlsmgr.c, tlsproxy/tlsproxy.c.
+
+ Robustness: Search for TLSA RRs at the resolved server name
+ (rname) and failing that request server name (qname), and
+ use whichever was found as the TLSA base domain for certificate
+ matching.
+
+ When we find a DNSSEC validated MX RRset, and the initial
+ next-hop domain is a CNAME, include both the initial and
+ final (the one with the actual MX RRs) domains in the list
+ of valid server certificate names.
+
+ When we find no MX records, then the initial next-hop domain
+ is obtained securely from the recipient domain or transport
+ next-hop. Without MX records, this is a destination hostname,
+ so we should generally do a TLSA lookup. If however the
+ address lookup yields an insecure result, and its rname is
+ equal to its qname (no CNAMEs), we reasonably assume that
+ the its child "_port._tcp" sub-domain is likewise insecure
+ (security here would require DLV just for this sub-domain).
+ This allows us to skip futile TLSA queries for most non-MX
+ destinations (those that are in insecure zones and are not
+ CNAMEs). This heuristic can be disabled by setting the new
+ main.cf parameter smtp_tls_force_insecure_host_tlsa_lookup
+ to "yes", the default is "no".
+
+ Finally, with MX hostnames, if the MX RRset is secure, we
+ look for TLSA RRs at the qname only when the MX host is an
+ alias with an insecure rname. If both the qname and the
+ rname are secure, as before we prefer the rname, but when
+ nothing is found there, fall back to the qname.
+
+ Code by Viktor Dukhovni. Files: mantools/postlink,
+ proto/postconf.proto, src/global/mail_params.h,
+ src/posttls-finger/posttls-finger.c, src/smtp/lmtp_params.c,
+ src/smtp/smtp.c, src/smtp/smtp.h, src/smtp/smtp_addr.c,
+ src/smtp/smtp_addr.h, src/smtp/smtp_connect.c,
+ src/smtp/smtp_params.c, src/smtp/smtp_tls_policy.c,
+ src/tls/tls.h, src/tls/tls_dane.c.
+
+20130826
+
+ Documentation: re-ordered STRESS_README, now that all
+ supported releases have stress-adaptive behavior built in.
+ File: proto/STRESS_README.html.
+
+20130903
+
+ Cleanup: made the default_database_type compile-time
+ configurable. Files: util/sys_defs.h, makedefs, proto/INSTALL.
+
+20130916
+
+ Feature: reject_known_sender_login_mismatch, which applies
+ reject_sender_login_mismatch only to MAIL FROM addresses
+ that are known in $smtpd_sender_login_maps. Viktor & Wietse.
+ Files: mantools/postlink, proto/SASL_README.html,
+ proto/postconf.proto, global/mail_params.h, smtpd/smtpd_check.c.
+
+20130927
+
+ Cleanup: no more LMDB "database full" errors. Postfix now
+ requires LMDB >= 0.9.8 which supports on-the-fly database
+ resizing. When a database becomes full, its size limit is
+ automatically doubled, and other processes automatically
+ pick up the new database size limit. Files: util/dict.h,
+ util/dict_open.c, util/dict_alloc.c, util/dict_lmdb.c,
+ postmap/postmap.c, postalias/postalias.c, proto/LMDB_README.html,
+ proto/postconf.proto.
+
+20130928
+
+ Cleanup: the lmdb_max_readers property is now configurable.
+ This is a hard limit built into the OpenLDAP library that
+ causes requests to fail when the number of open read
+ transactions exceeds the limit. When this happens the LMDB
+ client logs an MDB_READERS_FULL warning and continues with
+ reduced performance. Files: util/dict_lmdb.c, util/dict_lmdb.h,
+ global/mail_params.h, global/mail_params.c, proto/postconf.proto,
+ proto/LMDB_README.html.
+
+20130929
+
+ Security violation: LMDB opens files with read/write access
+ for lock management purposes. This gives unprivileged
+ daemon processes read/write file handles for root-owned
+ files under /etc/postfix. This also breaks when a non-root
+ process needs to access a root-owned database. Even if
+ LMDB lock files were world-writable, and kept in a dedicated
+ directory, they would still violate the principle of least
+ privilege. For all these reasons, support to create LMDB
+ files is removed from the postmap and postalias commands.
+ LMDB files can still be created by unprivileged Postfix
+ daemon processes under the postfix-owned data_directory.
+ Files: proto/LMDB_README.html, global/mkmap.c.
+
+20131001
+
+ Cleanup: LMDB support is forbidden due to problems with
+ LMDB lock management. These problems hinder error recovery
+ in multi-programmed systems, and prohibit database sharing
+ between privileged writer processes and unprivileged reader
+ processes.
+
+20131009
+
+ Documentation: inet_protols description was not updated
+ when smtp_address_preference was added. File: proto/postconf.proto
+
+20131013
+
+ Documentation: why postscreen(8) uses hash-table lookups
+ instead of direct pointers to find the DNSBL lookup result
+ for a specific session. File: postscreen/postscreen_early.c.
+
+20131022
+
+ Cleanup: add more &code; to postconf2man. Someone has been
+ writing documentation without checking the result, File:
+ mantools/postconf2man.
+
+ Documentation: in the discard(8) manpage, the reason is not
+ a host or domain name. File: discard/discard.c.
+
+20131025
+
+ Documentation: specify the expected result format with
+ "list" tables. File: proto/DATABASE_README.html.
+
+20131026
+
+ Future proofing: API changes in the PCRE library. File:
+ util/dict_pcre.c.
+
+20131028
+
+ Feature: check_sasl_access to block hijacked logins. Files:
+ mantools/postlink, proto/postconf.proto, global/mail_params.h,
+ smtpd/smtpd_check.c, smtpd/smtpd_dsn_fix.h.
+
+20131029-31
+
+ Cleanup: slmdb(3) simplified LMDB API that hides recoverable
+ LMDB errors from applications so that they can focus on
+ their own job. Files: util/slmdb.[hc].
+
+ Cleanup: LMDB functionality restored, after elimination of
+ 1) world-writable lockfiles, 2) hard limits on the number
+ of concurrent readers, and 3) hard-coded database file inode
+ numbers in lockfiles that can prevent automatic crash
+ recovery. Files: proto/LMDB_README.html, proto/postconf.proto,
+ mantools/postlink, util/dict_lmdb.c.
+
+20131101
+
+ Cleanup: restore ability to build without LMDB support;
+ further slmdb API streamlining. Files: util/slmdb.[hc],
+ util/dict_lmdb.c.
+
+ Bugfix: uninitialized variable. File: util/slmdb.c.
+
+ Documentation: added SASL_README example for check_sasl_access.
+ File: proto/SASL_README.html.
+
+20131102-3
+
+ Security violation: by default, LMDB 0.9.9 writes uninitialized
+ heap memory to a world-readable database file, as chunks
+ of up to 4096 bytes. This is a huge memory disclosure
+ vulnerability: memory content that a program does not intend
+ to share ends up in a world-readable file. The content of
+ uninitialized heap memory depends on program execution
+ history. That history includes code execution in other
+ libraries that are linked into the program.
+
+ This is a problem whenever the user who writes the database
+ file differs from the user who reads the database file. For
+ example, a privileged writer and an unprivileged reader.
+ In the case of Postfix, the postmap(1) and postalias(1)
+ commands would leak uninitialized heap memory, as chunks
+ of up to 4096 bytes, from a root-privileged process that
+ writes to a database file, to unprivileged processes that
+ read from that database file.
+
+ To work around this problem the postmap(1) and postalias(1)
+ commands disable the use of malloc() in LMDB. However, that
+ does not address several disclosures of stack memory. Other
+ Postfix databases do not need this workaround: those databases
+ are maintained by Postfix daemon processes, and are accessible
+ only by the postfix user. File: util/dict_lmdb.c.
+
+20131102-3
+
+ Cleanup: expand TAB characters when generating documentation.
+ This was primarily an issue with non-HTML output, but it does
+ not hurt to do this also for HTML. Files: proto/Makefile.in,
+ proto/MULTI_INSTANCE_README.html.
+
+20131104
+
+ Feature: ${queue_id} macro support for the pipe(8) delivery
+ agent by Andreas Schulze. File: pipe/pipe.c.
+
+20131107
+
+ Cleanup: after 16 years the SKIP() and TRIM() macros were
+ triggering compiler warnings. Files: global/mail_params.c,
+ smtpstone/smtp-sink.c, util/mac_parse.c, util/split_nameval.c.
+
+20131110
+
+ Bugfix (introduced Oct 26 1997): don't clobber errno before
+ expanding %m. File: util/vbuf_print.c.
+
+20131114
+
+ Cleanup: LMDB >= 0.9.10 does not need the MDB_WRITEMAP
+ workaround to avoid heap memory information leaks. File:
+ util/dict_lmdb.c.
+
+20131114
+
+ Cleanup: Coverity found a harmless memory leak in the
+ postconf master.cf parser. Reported by Christos Zoulas,
+ NetBSD. File: postconf/postconf_master.c.
+
+ Cleanup: graceful degradation after database open() error.
+ Several instances of that code introduced a harmless memory
+ leak, and Coverity complained about one of them (Christos
+ Zoulas, NetBSD). Instead of adding random code in random
+ places, restructured dict_foo_open() routines with consistent
+ code to dispose of memory or file handles. Files: dict_thash.c,
+ dict_sockmap.c, dict_regexp.c, dict_pcre.c, dict_lmdb.c,
+ dict_dbm.c, dict_cidr.c, dict_cdb.c.
+
+ Cleanup: warning message after canonical/virtal/etc.
+ table lookup error. Files: cleanup/cleanup_addr.c,
+ cleanup/cleanup_map11.c, cleanup/cleanup_map1n.c,
+ cleanup/cleanup_masquerade.c, cleanup/cleanup_message.c,
+ cleanup/cleanup_milter.c.
+
+20131116
+
+ Feature: MySQL client support for option_file, option_group,
+ tls_cert_file, tls_key_file, tls_CAfile, tls_CApath,
+ tls_verify_cert. See mysql_table(5). Code by Gareth Palmer.
+ Files: proto/mysql_table, global/dict_mysql.c.
+
+ Cleanup: DANE support. Keep the attributes of TA certificates
+ obtained via "IN TLSA 2 0 X" RRs, while continuing to only
+ use the key from "IN TLSA 2 1 X" RRs. This means in the
+ "2 0 X" case that we re-sign the TA certificate in place,
+ rather than synthesize a vanilla cert around just the key.
+ Viktor Dukhovni. File: tls/tls_dane.c.
+
+ Bugfix: posttls-finger parsing of destination and optional
+ match values. Viktor Dukhovni. File:
+ posttls-finger/posttls-finger.c.
+
+ Cleanup: When wrap_signed is false (OpenSSL 1.0.2 some day),
+ we don't have to sign trust anchors, and don't generate a
+ key to do so. Thus don't attempt to re-sign trust-anchor
+ certificates (IN TLSA 2 0 X) in this case. Viktor Dukhovni.
+ File: tls/tls_dane.c.
+
+ Feature: configurable DANE digest algorithm priority. Use
+ only the most-preferred, shared, digest algorithm for any
+ give (usage, selector) combination. Viktor Dukhovni.
+ mantools/postlink, proto/postconf.proto, global/mail_params.h,
+ tls/tls_dane.c, tls/tls_misc.c.
+
+ Bugfix: FreeBSD nroff workaround messed up. File:
+ mantools/postlink.
+
+20131118
+
+ Cleanup: FreeBSD nroff workaround. Files: man/Makefile.in,
+ proto/Makefile.in.
+
+ Cleanup: the smtpd_proxy_filter client now sends QUIT before
+ closing the connection to a content filter. Files:
+ smtpd/smtpd_proxy.c, smtpd/smtpd.c.
+
+ Portability: C99 va_copy() compatibility, in case some
+ implementation does not permit multiple va_start() calls
+ on the same argument list. Files: global/memcache_proto.c,
+ milter/milter8.c, smtpstone/smtp-source.c, util/attr_clnt.c,
+ util/concatenate.c, util/dict_surrogate.c, util/netstring.c,
+ util/compat_va_copy.h.
+
+ Cleanup: comment formatting. Viktor Dukhovni. File: dns/dns.h.
+
+ Cleanup: removed redundant sort operation. Viktor Dukhovni.
+ File: tls/tls_dane.c.
+
+20131119
+
+ Feature: a Postfix LMDB database can now be used as shared
+ persistent cache with multiple postscreen(8) or verify(8)
+ daemons (but not both), without the need for a shared
+ proxymap server. Files: util/dict.h, util/dict_alloc.c,
+ util/dict_open.c, util/dict_lmdb.c.
+
+ Internal: DNS client support to report reply RCODE information,
+ in addition to the simplified DNS_NOTFOUND, DNS_RETRY etc.
+ Portability note: this requires the C99 __VA_ARGS__ feature.
+ Files: dns/dns.h. dns/dns_lookup.c, dns/test_dns_lookup.c.
+
+20131120
+
+ Cleanup: reduced the code footprint for the LMDB < 0.9.10
+ heap-to-file information leak workaround, and simplified
+ the implementation to "good enough". Files: util/dict.h,
+ util/dict.c, util/dict_lmdb.c, postalias/postalias.c,
+ postmap/postmap.c.
+
+ Cleanup: reduced the code footprint for the handling of
+ multi-writer safe maps. A map only needs to assert that it
+ is multi-writer safe, and the rest just happens. Files:
+ util/dict.h, util/dict_open.c, util/dict_lmdb.c,
+ global/dict_memcache.c.
+
+ Cleanup: Postfix daemons no longer restart when a multi-writer
+ safe map is updated. File: util/dict.c.
+
+ Documentation: sharing an LMDB cache between multiple
+ verify(8) or postscreen(8) servers (but not both). Files:
+ proto/ADDRESS_VERIFICATION_README.html,
+ proto/POSTSCREEN_README.html.
+
+ Cleanup: improve suppression of TLSA lookups in insecure
+ zones. This is now applied not only to non-MX destinations,
+ but also to each MX record. Viktor Dukhovni. Files:
+ src/posttls-finger/posttls-finger.c, src/smtp/smtp_tls_policy.c,
+ src/tls/tls.h, src/tls/tls_dane.c.
+
+ Workaround: increased the 5s connection timeout to 30s.
+ Viktor Dukhovni. File: posttls-finger/posttls-finger.c.
+
+20131121
+
+ Documentation: new socketmap_table(5) and lmdb_table(5)
+ manpages. Files: mantools/postlink, conf/postfix-files,
+ html/Makefile.in, man/Makefile.in, proto/DATABASE_README.html,
+ postconf/postconf.c, proto/socketmap_table, proto/lmdb_table.
+
+20131122
+
+ Documentation: missing database hyperlinks, refined text
+ about partial lookup keys. Files: mantools/postlink,
+ proto/DATABASE_README.html, proto/lmdb_table,
+ proto/socketmap_table.
+
+20131123
+
+ Feature: support for NOTIFY parameter in the Milter
+ SMFIR_ADDRCPT_PAR request. Contributed by by Andrew Ayer.
+ Wietse added support for ORCPT. Files: cleanup/cleanup.h,
+ cleanup/cleanup_milter.c, cleanup/cleanup_state.c,
+ global/xtext.c, global/xtext.h, milter/test-milter.c.
+
+20131122
+
+ Feature: "postconf -Fe service/type/attribute = value" edits
+ master.cf attribute values. The -e is optional. Example:
+ use "postconf -F "*/*/chroot = n" to turn off chroot on all
+ master.cf services. Files: postconf/postconf.h,
+ postconf/postconf.c, postconf/postcof_master.c,
+ postconf/postconf_edit.c.
+
+20131124
+
+ Cleanup: remove extra blank line from ccformat output,
+ making it compatible with the script that Wietse actually
+ uses (this line was part of a test to detect file truncation,
+ but it is now obsolete). File: mantools/ccformat.
+
+ Feature: master.cf parameter namespace. "postconf -P" shows
+ master.cf parameter settings as "service/type/parameter =
+ value". This is applicable only to parameter settings in
+ master.cf. Files: postconf/postconf.h, postconf/postconf.c,
+ postconf/postcof_master.c, postconf/postconf_print.c.
+
+ Incompatibility: the master_service_disable syntax has
+ changed: use "service/type" instead of "service.type". The
+ new form is consistent with master.cf parameter namespaces.
+ The old form is still supported to avoid breaking existing
+ configurations. Files: global/master_service.c,
+ master/master_ent.c.
+
+20131125
+
+ Feature: change, add or delete "-o parameter=value" setting
+ in master.cf. Examples: "postconf -P smtp/inet/parameter=value"
+ (add or modify "-o name=value" setting) and "postconf -P
+ smtp/inet/parameter" (delete "-o parameter=value" setting).
+ Files: util/argv.[hc], postconf/postconf.h,
+ postconf/postconf_edit.c, postconf_master.c.
+
+20131126
+
+ Cleanup: Leave SSLv3 enabled with DANE. Viktor Dukhovni.
+ Files: proto/TLS_README.html proto/postconf.proto
+ tls/tls_client.c.
+
+ Cleanup: DANE support: Drop support for usage 0. It SHOULD
+ NOT be supported in DANE with SMTP, and we already don't
+ support digest TLSA RRs in this case, while full content
+ TLSA RRs are not recommended for DNS bloat reasons. Viktor
+ Dukhovni. Files: proto/postconf.proto src/global/mail_params.h
+ src/smtp/smtp.c src/tls/tls_dane.c src/tls/tls_misc.c.
+
+ Feature: TLS support: Support future digest algorithms
+ without re-compilation. Viktor Dukhovni. Files: .indent.pro
+ proto/postconf.proto src/tls/tls_dane.c.
+
+ Feature: DNS support: New configurable digest agility.
+ Viktor Dukhovni. Files: .indent.pro proto/TLS_README.html
+ proto/postconf.proto src/global/mail_params.h src/tls/tls_dane.c
+ src/tls/tls_misc.c.
+
+20131127
+
+ Bugfix (introduced: 20090106): the postconf '-#' option
+ erased prior options. File: postconf/postconf.c.
+
+20131129
+
+ Bugfix: Makefile example in MULTI_INSTANCE_README. Viktor
+ Dukhovni. File: proto/MULTI_INSTANCE_README.html.
+
+20131130
+
+ Cleanup: simplify fingerprint security level implementation
+ in new DANE code. Viktor Dukhovni. Files: src/tls/tls.h
+ src/smtp/smtp_tls_policy.c src/tls/tls_dane.c
+ src/posttls-finger/posttls-finger.c.
+
+20131209
+
+ Cleanup: safe_strtoul() did not report an error for empty
+ or all-space input (the code to report this was in the wrong
+ place). This was not a problem as long as safe_strtoul()
+ was used only for output from safe_ultostr(). Files:
+ global/safe_ultostr.c, global/safe_ultostr.in,
+ global/safe_ultostr.ref.
+
+20131210
+
+ Documentation: updated description of SSL protocol controls.
+ In particular, enabled protocols are part of a contiguous
+ range. Viktor Dukhovni. Files: proto/TLS_README.html,
+ proto/postconf.proto.
+
+ Bugfix: DANE support: handle OpenSSL memory allocation
+ error. Viktor Dukhovni. File: tls/tls_dane.c.
+
+ Cleanup: LMDB_README was not installed. File: conf/postfix-files.
+
+20131214
+
+ Portability: on some platforms posttls-finger now requires
+ explicitly linking libdl. File: posttls-finger/Makefile.in.
+
+ Cleanup: DANE support: extension gymnastics. Viktor Dukhovni.
+ File: tls/tls_dane.c.
+
+ Bugfix: DANE support: the wrap_cert() and wrap_key() calls
+ should never fail, but some callers ignored the return
+ value. The only failure is for lack of memory, so we use
+ msg_fatal() internally and change wrap_cert() and wrap_key()
+ to return void. Viktor Dukhovni. File: tls/tls_dane.c.
+
+ Bugfix: DANE support: avoid making DANE certificates with
+ replaced public-keys appear as if they were self-signed.
+ Viktor Dukhovni. File: tls/tls_dane.c.
+
+ Cleanup: DANE support: simplify grow_chain() to always apply
+ trust consistently. Viktor Dukhovni. File: tls/tls_dane.c.
+
+ Bugfix: DANE support: backport fixes from OpenSSL DANE
+ testing. Discard errors generated by raw TA key signature
+ checks. Record the tadepth as zero with self-signed depth
+ 0 TAs. Robustness: Though it should never happen, don't
+ update the tadepth if already set. Viktor Dukhovni. Files:
+ tls/tls_dane.c, tls/tls_server.c.
+
+20131215
+
+ Cleanup: OpenSSL "const" declarations have changed over
+ time. Viktor Dukhovni. Files: src/tls/tls.h, src/tls/tls_client.c,
+ src/tls/tls_dane.c, src/tls/tls_server.c.
+
+20131216
+
+ Cleanup: TLS support. Eliminate calls of deprecated functions
+ before they are removed from OpenSSL. CRYPTO_thread_id is
+ deprecated and we don't need it. Replace the deprecated
+ ERR_remove_state() call with ERR_remove_thread_state(), and
+ use RSA_generate_key_ex(). Viktor Dukhovni. Files:
+ posttls-finger/posttls-finger.c, tls/tls_misc.c, tls/tls_rsa.c.
+
+ Cleanup: DANE support: Reduce #ifdef clutter to improve
+ redability and maintability. Viktor Dukhovni. File:
+ tls/tls_dane.c.
+
+ Future proofing: Tolerate disappearance of named bug-workaround
+ bits without invalidating user configurations. When support
+ for a bug workaround is removed from OpenSSL, the corresponding
+ bit is defined as zero (i.e. NOOP) intstead of causing
+ programs to break. Viktor Dukhovni. File: tls/tls_misc.c.
+
+20131217
+
+ Portability: RSA_generate_key_ex() is not available on all
+ supported platforms, so this change is made conditional.
+ Enforce that this function will be used only for creating
+ a 512-bit ephemeral RSA key. Viktor Dukhovni. File:
+ tls/tls_rsa.c.
+
+20131218
+
+ Documentation: new document FORWARD_SECRECY_README that
+ describes how different versions of Postfix >= 2.2 implement
+ "perfect" forward secrecy. Viktor Dukhovni. File:
+ proto/FORWARD_SECRECY_README.html, proto/Makefile.in,
+ conf/postfix-files, html/index.html.
+
+20131219
+
+ Cleanup: renamed postconf(1) internal identifiers according
+ to a consistent scheme, to avoid future name conflicts as
+ Postfix evolves. This is a no-feature change. Files:
+ postconf/*.[hc], postconf/extract.awk.
+
+ Documentation: linearized the order of exposition in
+ FORWARD_SECRECY_README. File: proto/FORWARD_SECRECY_README.html.
+
+20131220
+
+ Bugfix: DANE support: segfault. Viktor Dukhovni. File:
+ tls/tls_dane.c.
+
+ Documentation: typo in SASL_README. Patrick Ben Koetter.
+ File: proto/SASL_README.html.
+
+ Documentation: increased the *.[0-9].html manpage width
+ from the historical 65 columns to the more contemporary 78
+ columns, and future-proofed the pattern that eliminates
+ redundant text from the "README FILES" section. Files:
+ mantools/postlink, mantools/man2html, man/Makefile.in.
+
+ Documentation: misc manual page cleanups. Files:
+ postconf/postconf.c, postmulti/postmulti.c.
+
+20131221
+
+ Testbed: TLS support. Viktor Dukhovni. Files: tls/Makefile.in,
+ tls/tls_dane.c, tls/tls_dane.sh, tls/tls_mgr.c, .indent.pro.
+
+ Documentation: added section on how to verify that forward
+ secrecy works. File: proto/FORWARD_SECRECY_README.html.
+
+20131222
+
+ Documentation: forward secrecy, with feedback from Adam
+ Shostack. Viktor Dukhovni and Wietse Venema. File:
+ proto/FORWARD_SECRECY_README.html.
+
+20131224
+
+ Feature: smtpd_sasl_service (until now, this was hard-coded
+ internally as "smtp"). On request by Michal (sksoft.cz).
+ Files: global/mail_params.h, proto/postconf.proto,
+ mantools/postlink, smtpd/smtpd.c, smtpd/smtpd_sasl_glue.c.
+
+ Documentation: updated example to Dovecot version 2 syntax.
+ File: proto/SASL_README/html.
+
+20131228
+
+ Cleanup: DANE support: test script. Viktor Dukhovni. File
+ tls/tls_dane.sh.
+
+ Debugging: test driver for LMDB debugging and stress testing.
+ Shockingly, LMDB terminates the postscreen daemon without
+ logfile record. File: util/dict_cache.c.
+
+20140102
+
+ Bugfix: close the LMDB database cursor's read transaction
+ before writing with MDB_NOLOCK and before changing the
+ database memory map size. File: util/slmdb.c.
+
+20140103
+
+ Cleanup: eliminated data duplication from the new SMTP_ITERATOR
+ structure to the old SMTP_SESSION structure. The SMTP_ITERATOR
+ structure now maintains the sole copy. Files: smtp/smtp.h,
+ smtp_sasl_auth_cache.c, smtp_reuse.c, smtp_sasl_glue.c,
+ smtp_rcpt.c, smtp_session.c, smtp_chat.c, smtp_proto.c,
+ smtp_connect.c.
+
+20140104
+
+ Feature: support for optional configuration files
+ "$daemon-directory/postfix-files.d/*". These are processed
+ in sorted order after "$daemon-directory/postfix-files",
+ This avoids breaking "postfix set-permissions" etc. when a
+ Postfix distribution comes in multiple packages. File:
+ conf/post-install.
+
+20140107
+
+ Feature: LMDB 0.9.11 allows Postfix daemons to log an LMDB
+ error message, instead of falling out of the sky without
+ any notification. Files: util/slmdb.[hc], util/dict_lmdb.c.
+
+20140108
+
+ Bugfix: every Postfix LMDB transaction is now protected by
+ an external lock for its entire life time. File: util/slmdb.c.
+
+20140109
+
+ Cleanup: turn off DNSSEC lookup after CNAME redirection to
+ an insecure zone. This is an optimization for resolvers
+ that do not automatically resolve CNAME chains. Viktor
+ Dukhovni. File: dns/dns_lookup.c.
+
+ Cleanup: do not salt the SMTP TLS policy lookup cache key
+ with the DNSSEC status. The DNSSEC status will not change
+ when the same nexthop/host pair is looked up repeatedly.
+ Viktor Dukhovni. File: smtp/smtp_tls_policy.c.
+
+ Robustness: Suppress TLSA lookups only when the qname zone
+ is insecure, not just because the rname zone is insecure.
+ This requires an extra T_CNAME lookup for the qname, since
+ nameservers are often "too helpful" and report CNAME records
+ together with the CNAME targets. When the targets are
+ insecure the whole reply is marked as insecure. Viktor
+ Dukhovni. File: tls/tls_dane.c.
+
+ Cleanup: Unify/simplify reporting of configuration or other
+ conditions that prevent DANE security. Viktor Dukhovni.
+ Files: global/dsn_buf.[hc], tls/tls_dane.c, smtp/smtp_tls_policy.c.
+
+20140110-15
+
+ Miscellaneous documentation cleanups.
+
+20140116
+
+ Workaround: prepend "-I. -I../../include" to CCARGS, to
+ avoid name clashes with non-Postfix header files. File:
+ makedefs.
+
+20140125
+
+ Cleanup: assorted documentation glitches.
+
+20140209
+
+ Workaround: the Postfix SMTP client now also falls back to
+ plaintext when TLS fails after the TLS protocol handshake.
+ Files: smtp/smtp.h, smtp/smtp_connect.c, smtp/smtp_trouble.c.
+
+ Testbed: unsupported HANGUP access map action that drops
+ the connection without responding to the remote SMTP client.
+ File: smtpd/smtpd_check.c.
+
+20140214
+
+ Workaround: apparently some buggy kernels report WIFSTOPPED
+ events to the parent process (master daemon) instead of the
+ tracing process (e.g., gdb). File: master/master_spawn.c.
+
+20140218
+
+ Workaround: require that a queue file is older than
+ $minimal_backoff_time, before falling back from failed TLS
+ to plaintext (both during or after the TLS handshake).
+ Viktor Dukhovni. Files: smtp/smtp.h, smtp/smtp.c,
+ smtp/lmtp_params.c, smtp/smtp_params.c.
+
+20140220
+
+ Workaround: in case "minimal_backoff_time = $queue_run_delay".
+ Files: smtp/smtp.c, smtp/smtp_params.c, smtp/lmtp_params.c.
+
+ Cleanup: consolidate the code to log the start of a new
+ mail transaction in one place, so that code can easily be
+ added to log TLS status information in addition to the
+ existing client and SASL status information. Files:
+ smtpd/smtpd_sasl_proto.h, smtpd/smtpd_sasl_proto.c,
+ smtpd/smtpd.c.
+
+20140223
+
+ Workaround: when a session breaks after the TLS handshake,
+ do not fall back from TLS to plaintext when all recipients
+ were deferred or rejected during the TLS phase. Files:
+ smtp/smtp.h, smtp/smtp_rcpt.c.
+
+ Logging: the TLS client logged that an "Untrusted" TLS
+ connection was established instead of "Anonymous". Viktor
+ Dukhovni. File: tls/tls_client.c.
+
+ Documentation: new self-signed certificate example and
+ updated private CA example. File: proto/TLS_README.html.
+
+20140224
+
+ Bugfix (introduced: 20061106): when the "retry" transport
+ was added to Postfix, it was not given special status like
+ the "error" transport. The Postfix SMTP server did not defer
+ mail that resolves to the "retry" transport, and the
+ trivial-rewrite daemon would override the null nexthop
+ destination in "retry:" with the current nexthop destination.
+ Files: smtpd/smtpd_check.c, trivial-rewrite/transport.c.
+
+20140227
+
+ Bugfix: Enforce TLS when TLSA records exist, but all are
+ unusable; Don't leak dane handle when all TLSA records are
+ unusable. Viktor Dukhovni. File: smtp/smtp_tls_policy.c.
+
+ Cleanup: log TLS policy lookup errors as warnings. Viktor
+ Dukhovni. File: smtp/smtp_connect.c.
+
+20140316
+
+ Feature: preliminary support to change arbitrary hard
+ delivery errors into soft errors and vice versa, or to
+ replace the descriptive text of non-delivery notifications.
+ This was originally introduced for sites that want to bounce
+ mail when no remote SMTP server announces TLS support. New
+ parameters: {default,smtp,pipe,virtual}_bounce_defer_filter.
+ Files: proto/postconf.proto, mantools/postlink, global/bounce.[hc],
+ bounce/defer.[hc], global/ndr_filter.[hc], global/mail_params.[hc],
+ master/event_server.c, master/multi_server.c,
+ master/single_server.c, master/trigger_server.c, smtp/smtp.c,
+ pipe/pipe.c, virtual/virtual.c.
+
+20140317
+
+ Feature: local_bounce_defer_filter support. Files:
+ global/bounce.[hc], global/defer.[hc], local/command.c,
+ local/file.c, local/bounce_workaround.c, local/local.c,
+ global/mail_params.h, mantools/postlink.
+
+20140318
+
+ Refinement: don't throttle an SMTP destination when the new
+ smtp_bounce_defer_filter feature turns a soft bounce into
+ a hard bounce. File: smtp/smtp_trouble.c.
+
+20140320
+
+ Feature: support to replace successful delivery status code
+ and explanatory text. This can be used to to hide local
+ details such as destination commands or file names when a
+ remote sender requests confirmation of delivery. As of now
+ *_bounce_defer_filter is renamed into *_delivery_status_filter.
+ Files: global/bounce.c, global/bounce.h, global/defer.c,
+ global/defer.h, global/dsn_filter.c, global/dsn_filter.h,
+ global/mail_params.c, global/mail_params.h, global/sent.c,
+ local/local.c, master/event_server.c, master/multi_server.c,
+ master/single_server.c, master/trigger_server.c, pipe/pipe.c,
+ smtp/lmtp_params.c, smtp/smtp.c, smtp/smtp_params.c,
+ virtual/virtual.c, mantools/postlink.
+
+20140322
+
+ Cleanup: code comments and identifier names to reflect the
+ evolution from "NDR filter" to "delivery status filter".
+ Files: global/mail_params.h, smtp/smtp.c, global/dsn_filter.c,
+ global/dsn_filter.h, local/local.c, pipe/pipe.c,
+ smtp/lmtp_params.c, smtp/smtp_params.c, virtual/virtual.c,
+ global/bounce.c.
+
+20140323
+
+ Feature: initial merge of Debian-style dynamic linking.
+ Viktor Dukhovni.
+
+20140406
+
+ Bugfix: when testing session caching, stop reconnecting
+ after encountering a previously-used server (when the session
+ is re-used or not). Viktor Dukhovni. File:
+ posttls-finger/posttls-finger.c.
+
+ Feature: configurable TLS session-ticket cipher (default:
+ tls_session_ticket_cipher = aes-128-cbc). Viktor Dukhovni
+ and Wietse. Files: mantools/postlink, smtpd/smtpd.c,
+ proto/postconf.proto, global/mail_params.h, tls/tls_misc.c,
+ tls/tls_scache.h, tls/tls_server.c.
+
+20140416
+
+ Cleanup: replace "~0 << positive" with "~0U << positive"
+ even if we use only the lower bytes. Jeffrey Walton. File:
+ util/mask_addr.c.
+
+20140407
+
+ Documentation: the documentation for Postfix > 2.8 TLS
+ activity logging was incorrect. Loglevel 0 produces no
+ logging. Instead, information is logged only with loglevel
+ 1 or higher. Viktor Dukhovni. Files: proto/TLS_README.html,
+ proto/postconf.proto.
+
+20140501
+
+ Cleanup: postscreen_dnsbl_timeout parameter. Files:
+ mantools/postlink, proto/postconf.proto, global/mail_params.h,
+ postscreen/postscreen.c, postscreen/postscreen_dnsbl.c.
+
+ Cleanup: added table search order information to the
+ postconf(5) manpage. File: proto/postconf.proto.
+
+20140505
+
+ Cleanup: added a client port attribute to the policy
+ delegation protocol. Jernej Porenta. File: smtpd/smtpd_check.c.
+
+20140507
+
+ Bugfix (introduced: Postfix 2.11): with connection caching
+ enabled (the default), recipients could be given to the
+ wrong mail server. Root cause: due to an incorrect predicate,
+ the Postfix SMTP client could save and restore plaintext
+ connections that should not be cached, under nonsensical
+ lookup keys that did not distinguish by destination. Problem
+ reported by Sahil Tandon, predicate error found by Viktor,
+ redundant connection restore request eliminated by Wietse.
+ File: smtp/smtp_connect.c.
+
+ Cleanup: the macros that control SMTP connection reuse
+ poorly reflected their purpose. "DEAD" is replaced with
+ "FORBIDDEN" (no I/O allowed) and "BAD" is replaced with
+ "THROTTLED" (anything that causes the queue manager to back
+ off from some destination). Files: smtp.h, smtp_connect.c,
+ smtp_proto.c, smtp_trouble.c.
+
+ Cleanup: enable SMTP connection cache lookup by destination
+ name while a surge of mail dries up. File: smtp_connect.c.
+
+20140505
+
+ Bugfix: the postdrop authorized_submit_users feature requires
+ that lookup table support is initialized so that it can use
+ libglobal or dynamicmaps maps. File: postdrop/postdrop.c.
+
+ Cleanup: moved dynamicmaps initialization from parameter
+ inititialization (mail_conf_suck()) to dictionary initialization
+ (mail_dict_init()). A benefit of this is that dynamicmaps.cf
+ is no longer read by programs that don't use Postfix lookup
+ tables. Files: global/mail_conf.[hc], global/mail_dict.c.
+
+ Cleanup: move the mail_dict_init() call after the
+ mail_conf_read() or mail_params_init() call, to prepare for
+ a configurable dynamicmaps.cf directory. Files:
+ master/event_server.c, master/multi_server.c,
+ master/single_server.c, master/trigger_server.c.
+
+20140506
+
+ Cleanup: you can now specify "make makefiles parameter=value"
+ for selected compile-time parameter default overrides. The
+ old "make makefiles 'CCARGS=-DDEF_MUMBLE=\"mumble\"'"
+ approach remains supported. File: makedefs.
+
+20140508
+
+ Cleanup: dynamicmaps.cf is now installed into $daemon_directory
+ because the file is shared among Postfix instances just
+ like postfix-files and other files. Files: conf/dynamicmaps.cf,
+ Makefile.in, conf/postfix-files.
+
+ Cleanup: INSTALL is now plain ASCII instead of README format,
+ to avoid a chicken-and-egg problem (the instructions to
+ print/view README-format files are in the INSTALL file).
+
+ Documentation: updated INSTALL instructions and RELEASE_NOTES.
+
+20140512
+
+ Portability: Berkeley DB6 support. File: util/dict_db.c.
+
+20140514
+
+ Cleanup: replace #ifdef/endif containing hard-coded calls
+ of dynamicmaps functions with an extension mechanism that
+ dynamicmaps functions invoke instead. Files: util/dict.h,
+ util/dict_open.c, global/dynamicmaps.[hc], global/mkmap.h,
+ global/mkmap_open.c.
+
+20140515
+
+ Bugfix (introduced: 20140320): missing initialization.
+ Viktor Dukhovni. File pipe/pipe.c.
+
+ Cleanup: mkmap_open() now caches a dynamically-loaded
+ function. This is useful because postmap/postalias may open
+ the same database type multiple times. Files: global/mkmap.h,
+ global/mkmap_open.c.
+
+ Security: the dynamicmaps.cf file and its and shared-object
+ files must not be writable by non-root users. File:
+ global/dynamicmaps.c.
+
+20140517
+
+ Cleanup: dynamic linking and hooking. Files: util/dict.h,
+ util/load_lib.[hc], global/dynamicmaps.c.
+
+20140518
+
+ Preliminary "make plugins" support. Todo: macros to dynamically
+ remove pluggable maps from compile-time tables in dict_open.c
+ and mkmap_open.c, and from the OBJS lists in Makefile.in.
+
+20140522
+
+ Support for "make shared=yes" and "make dynamicmaps=yes".
+ New plugin_directory parameter for the location of the
+ dynamicmaps.cf file and for plugins with a relative pathname.
+ See RELEASE_NOTES and INSTALL for details. Files: postfix.c,
+ mail_params.[hc], dynamicmaps.c, mail_dict.c, makedefs,
+ postfix-files, dynamicmaps.cf, Makefile.in, util/Makefile.in,
+ global/Makefile.in, postlink, postconf.proto. INSTALL.html,
+ RELEASE_NOTES.
+
+20140523
+
+ Cleanup: don't install plugins for unsupported databases,
+ and don't make dynamicmaps.cf entries for them. Files:
+ makedefs, Makefile.in, util/Makefile.in, global/Makefile.in.
+
+ Cleanup: added support for symlinks where the "source" is
+ specified as a relative pathname. File: postfix-install.
+
+ Cleanup: moved instructions from RELEASE_NOTES to INSTALL
+ to avoid duplication. Files: RELEASE_NOTES, proto/INSTALL.html.
+
+ Cleanup: include unconditionally so that
+ dict_lmdb_map_size is always defined. Files: mail_params.c,
+ dict_test.c.
+
+ Cleanup: port for ancient Solaris9 revealed some non-portability.
+ Files: master/Makefile.in, makedefs, sys_defs.h.
+
+20140524
+
+ Cleanup: specify database library dependencies with variables
+ named AUXLIBS_CDB, AUXLIBS_LDAP, etc. The global AUXLIBS
+ variable is still supported, but the new variables are
+ required when building dynamically-loadable building database
+ plugins. Files: RELEASE_NOTES, INSTALL.html, CDB_README.html,
+ LDAP_README.html, LMDB_README.html, MYSQL_README.html,
+ PCRE_README.html, PGSQL_README.html, SQLITE_README.html,
+ makedefs, util/Makefile.in, global/Makefile.in.
+
+ Workaround: reportedly, MacOS can fail to move a symlink
+ with a relative target across file system boundaries, because
+ it examines the symlink with stat() instead of lstat().
+ Files: makedefs, Makefile.in.
+
+ Cleanup: use readlink to verify symlink target. File:
+ postfix-install.
+
+20140528
+
+ Cleanup: the configuration file dynamicmaps.cf will now
+ automatically include files under the directory dynamicmaps.cf.d,
+ just like the configuration file postfix-files will
+ automatically include files under the directory postfix-files.d.
+ See INSTALL section "Building with Postfix shared libraries
+ and database plugins". File: dynamicmaps.c.
+
+20140530
+
+ Cleanup: add shlib_directory and plugin_directory to the
+ postmulti-script list of shared parameters. Viktor Dukhovni.
+ File: postmulti-script.
+
+ Cleanup: to avoid "postfix set-permission" errors, don't
+ create postfix-files entries for non-existent database
+ plugins. Problem reported by Viktor. File: Makefile.in.
+
+ Bugfix: we can't use "mv" to replace a symlink-to-directory.
+ Instead we now create all symlinks in place. Unfortunately
+ the "ln -n" option is not universally implemented, so we
+ remove the old symlink first. Problem reported by Viktor.
+ File: postfix-install.
+
+20140603
+
+ Cleanup: use the OpenSSL session id accessor (available
+ since OpenSSL 0.9.8 or so) instead of groping a session
+ object directly. Viktor Dukhovni. File: tls_server.c.
+
+20140605
+
+ Feature: the pipe(8) daemon logs some command output after
+ successful delivery as "dsn=2.0.0, status=sent (delivered
+ via XXX service (YYY))" where XXX is the master.cf service
+ name, and YYY is command output. Files: pipe/command.c,
+ pipe.c.
+
+20140613
+
+ Feature: the "pipeline" table implements a table pipeline.
+ Example "pipeline:!type_1:name_1!...!type_n:name_n". The
+ ASCII character after "pipeline:" will be used as the
+ separator between the lookup tables that follow (do not use
+ space, ",", ":" or non-ASCII). Each "pipeline:" query is
+ given to the first table. Each lookup result becomes the
+ query for the next table in the pipeline, and the last table
+ produces the final result. When any table lookup produces
+ no result, the pipeline produces no result. Files:
+ dict_pipe.[hc], dict_open.c, postlink, DATABASE_README.html,
+ postconf.c.
+
+20140617
+
+ Feature: the "random" table performs random selection.
+ Example: "random:!result_1!...!result_n". Each table query
+ returns a random choice from the specified results. The
+ ASCII character after "random:" will be used as the separator
+ between the results that follow (do not use space, ",", ":"
+ or non-ASCII). Files: dict_random.[hc], dict_open.c,
+ postlink, DATABASE_README.html, postconf.c.
+
+20140618
+
+ Cleanup: INFO action in access(5) tables, for consistency
+ with header/body_checks. Viktor Dukhovni. Files:
+ smtpd/smtpd_check.c, proto/access.
+
+20140619
+
+ Cleanup: process LaMont Jones feedback for shared-library
+ and database-plugin builds. Changes: 1) move non-executable
+ files from $daemon_directory to the default $config_directory
+ (postfix-files*, dynamicmaps.cf*, main.cf.proto/master.cf.proto
+ for multi-instance support); 2) add foo.so -> foo.so.version
+ symlinks; 3) change $shlib_directory and $plugin_directory
+ defaults to /usr/lib/postfix to reduce sprawl. Files:
+ conf/main.cf.proto, conf/master.cf.proto, conf/postfix-files.proto,
+ conf/post-install, conf/postmulti-script, makedefs,
+ postfix-install, proto/INSTALL.html, global/dynamicmaps.c,
+ global/dynamicmaps.h, global/mail_dict.c, global/mail_params.h,
+ postmulti/postmulti.c.
+
+ Bugfix (introduced: 2001): qmqpd null pointer bug when it
+ logs a lost connection while not in a mail transaction.
+ Reported by Michal Adamek. File: qmqpd/qmqpd.c.
+
+ Cleanup: filter non-printable characters in X509 subject
+ or issuer names. Viktor Dukhovni. File: tls/tls_server.c.
+
+20140620
+
+ Cleanup: for compliance with file system policies, some
+ files have been moved from $daemon-directory to the directory
+ specified with the new meta_directory parameter which has
+ the same default value as config_directory. This change
+ affects non-executable files that are shared among multiple
+ Postfix instances, such as postfix-files, dynamicmaps.cf,
+ and multi-instance template files.
+
+ For backwards compatibility with Postfix 2.6..2.11, specify
+ "meta_directory = $daemon_directory" in main.cf before
+ installing Postfix, or specify "meta_directory = /path/name"
+ on the "make makefiles", "make install" or "make upgrade"
+ command line.
+
+ Files: Makefile.in, RELEASE_NOTES, conf/post-install,
+ conf/postfix-files.proto, conf/postmulti-script, makedefs,
+ mantools/postlink, postfix-install, proto/INSTALL.html,
+ proto/postconf.proto, global/mail_params.c, global/mail_params.h,
+ postfix/postfix.c, postmulti/postmulti.c.
+
+ Feature: check_xxx_a_access (for xxx in client, reverse_client,
+ helo, sender, recipient) implements access control on all
+ A and AAAA IP addresses for the client hostname, helo
+ parameter, sender domain or recipient domain. Some spam has
+ sender domains with the same IP address but different MX
+ hosts. Files: global/mail_params.h, smtpd/smtpd_check.c,
+ proto/postconf.proto.
+
+20140622
+
+ Cleanup: eliminated plugin_directory to reduce configuration
+ parameter sprawl. Files: Makefile.in, RELEASE_NOTES,
+ conf/post-install, conf/postfix-files.proto, conf/postfix-script,
+ conf/postmulti-script, makedefs, mantools/postlink,
+ postfix-install, proto/INSTALL.html, proto/postconf.proto,
+ global/Makefile.in, global/mail_dict.c, global/mail_params.c,
+ global/mail_params.h, global/mail_version.h, postfix/postfix.c,
+ postmulti/postmulti.c, smtpd/smtpd_check.c, util/Makefile.in.
+
+20140623
+
+ Cleanup: eliminated the use of Postfix release versions as
+ file name suffixes for shared libraries, database plugins
+ and dynamicmaps.cf. The shared-library version suffixes
+ were fighting against assumptions and conventions in run-time
+ linkers, including the assumption that ABIs are preserved
+ from one version to the next. The Postfix version can now
+ be embedded in the shlib_directory parameter. As this is
+ sufficient to permit upgrade of a running Postfix system
+ without risking that old binaries will link against newer
+ shared objects, we no longer need a version suffix for
+ dynamicmaps.cf. Files: Makefile.in, RELEASE_NOTES,
+ conf/postfix-files.proto, makedefs, proto/INSTALL.html,
+ proto/postconf.proto, global/mail_params.h, global/mail_version.h,
+
+20140624
+
+ Cleanup: the commands "make (makefiles|install|upgrade|package)
+ parameter=value" now replace the string MAIL_VERSION in a
+ configuration parameter value with the Postfix release
+ version. Unfortunately, the more obvious approach, a
+ parameter value with the unexpanded '$mail_version', produces
+ inconsistent results with different make implementations.
+ Files: makedefs, Makefile.in, postfix-install, proto/INSTALL.html,
+ proto/PACKAGE_README.html
+
+ Cleanup: postmulti now requires "postmulti -e init" before
+ accepting other multi-instance requests. Viktor Dukhovni.
+ File: conf/postmulti-script.
+
+20140625
+
+ Kludge: moved dict_db_cache_size away from dict_db.c in
+ preparation for Berkeley DB database plugin support (a
+ similar kludge was implemented for LMDB). Files:
+ util/dict_db.[hc], util/dict_test.c, global/mail_params.c.
+
+ Cleanup: don't leak build directory information via SHLIB_ENV
+ in makedefs.out. Files: Makefile.in, conf/postfix-files.
+
+20140626
+
+ Cleanup: construction debris. Files: Makefile.in,
+ conf/postfix-script.
+
+ Cleanup: replace the result of MAIL_VERSION expansion with
+ $mail_version in main.cf installation parameter settings,
+ to permit safe upgrade of a running mail system. File:
+ postfix-install.
+
+ Cleanup: replace the result of MAIL_VERSION expansion with
+ $mail_version in built-in default installation parameter
+ settings, for consistency with main.cf. File: makedefs,
+ postfix-install, conf/post-install.
+
+ Cleanup: removed $mail_version from the default shlib_directory
+ value. Files: global/mail_params.h, proto/INSTALL.html.
+
+ Cleanup: in postfix-script, use find instead of ls to
+ determine permissions or ownership, and group some checks
+ with "pathname/." and "pathname/*" into one. Downside:
+ more warnings will now have "/./" in the middle of a pathname.
+ File: conf/postfix-script.
+
+ Cleanup: need to evaluate mail_version before evaluating
+ parameters that may contain $mail_version. File:
+ global/mail_params.c.
+
+ Cleanup: the postmulti command now exercises the postconf
+ "-x" option to expand $parameter_name in secondary-instance
+ parameter values. File: postmulti/postmulti.c.
+
+ Cleanup: post-install also needed to replace the result of
+ MAIL_VERSION expansion with $mail_version, for the same
+ reasons as postfix-script. Viktor Dukhovni. File:
+ conf/post-install.
+
+20140627
+
+ Bugfix (introduced: 20140626) broken build and broken install
+ with default shlib_directory. Files: makedefs.
+
+ Bugfix (introduced: 20140627) "make install" stopped with
+ a bogus error when there was no real "make install name=value"
+ parameter override. Files: conf/post-install.
+
+ Cleanup: support MAIL_VERSION magic (see INSTALL) only at
+ the end of a parameter value. Files: proto/INSTALL.html
+ makedefs, postfix-install, conf/postfix-files.
+
+ Cleanup: use ${mail_version} as the MAIL_VERSION-unexpanded
+ form. Viktor Dukhovni. Files: makedefs, postfix-install,
+ conf/postfix-files.
+
+20140630
+
+ Cleanup: the pipeline and random lookup tables are now
+ called pipemap and randmap, respectively. These names are
+ more specific. The old names remain available, at least
+ temporarily. Files: util/dict_pipe.[hc], util/dict_random.[hc],
+ postconf/postconf.c, mantools/postlink, proto/DATABASE_README.html.
+
+ Feature: smtpd_policy_service_request_limit to limit the
+ number of requests per Postfix SMTP server policy connection.
+ This is a workaround to avoid error-recovery delays with
+ policy servers that cannot maintain a persistent connection.
+ Based on code by Markus Benning. Files: global/mail_params.h,
+ mantools/postlink, proto/SMTPD_POLICY_README.html,
+ proto/postconf.proto, smtpd/smtpd.c, smtpd/smtpd_check.c,
+ util/attr_clnt.[hc].
+
+20140701
+
+ Cleanup: documented how Postfix maintains dictionary
+ provenance. Provenance matters: for example, the owner UID
+ of an aliases(5) database file determines the execution
+ privileges for delivery to |command or /file/name. Refined
+ the algorithm that computes the provenance of a pipemap,
+ based on the provenance of its constituent lookup tables.
+ Files: util/dict.[hc], util/dict_pipe.c.
+
+ Cleanup: made mail_spool_directory configurable with "make
+ makefiles mail_spool_directory=/path/name". This allows
+ Postfix to be built without any pathnames that reference
+ system directories. This is useful for testing and sandboxing.
+ Files: global/mail_params.h, makedefs.
+
+ Cleanup: configurable attr_clnt(3) retry strategy (try limit
+ and retry delay). Files: util/attr_clnt.[hc].
+
+ Feature: control over SMTPD policy lookup error handling:
+ smtpd_policy_service_try_limit, smtpd_policy_service_retry_delay,
+ smtpd_policy_service_default_action determine how many times
+ to try to send a policy request before giving up, the delay
+ before resending a failed policy request, and a default
+ action when giving up. The defaults are backwards-compatible.
+ Files: global/mail_params.h, mantools/postlink,
+ proto/postconf.proto, smtpd/smtpd.c, smtpd/smtpd_check.c.
+
+20140709
+
+ Cleanup: bitrot in unused function. File: global/defer.c.
+
+ Cleanup: add SYSLIBS minus static libraries while building
+ Postfix shared-library objects. Files: makedefs, util/Makefile.in,
+ global/Makefile.in, dns/Makefile.in, master/Makefile.in/.
+
+20140708
+
+ Bugfix (introduced 20140701): did not restore jumpbuf while
+ evaluatingsmtpd_policy_service_default_action. Viktor
+ Dukhovni. File: smtpd/smtpd_check.c.
+
+ Feature: VERY PRELIMINARY support for SMTPUTF8 based on an
+ initial implementation by Arnt Gulbrandsen, funded by CNNIC.
+ This implements the syntax of SMTP commands and DSN delivery
+ status notifications. It does not address the problem that
+ the same domain name may show up in different forms: an
+ UTF8-encoded name with non-ASCII charaters, or an IDNA-encoded
+ (xn--mumble) name with ASCII-only characters. This means
+ that access policies, mydestination, virtual_*_domains and
+ relay_domans will have to understand both forms in order
+ to provide complete coverage. For now, SMTPUTF8 support
+ must not be enabled except for testing.
+
+20140710
+
+ Portability: add '-Wl,--enable-new-dtags' to the linker
+ command line with building with Postfix shared libraries
+ on Linux. Viktor Dukhovni. file: makedefs.
+
+20140711
+
+ Background: What is SMTPUTF8 autodetection? Postfix cannot
+ rely solely on the sender's declaration that a message
+ requires SMTPUTF8 support, because UTF8 may be introduced
+ during local processing (for example, the client hostname
+ in Postfix's Received: header, adding @$myorigin or .$mydomain
+ to an incomplete address, address rewriting, alias expansion,
+ automatic BCC recipients, local forwarding, and modifications
+ made by header checks or Milter applications). This means
+ that some form of autodetection is needed that a message
+ requires SMTPUTF8 support.
+
+ Cleanup: don't try to distinguish between UTF that is already
+ present in a message or envelope, and UTF8 that is introduced
+ during local processing (see above). Maintaining this
+ distinction is too problematic.
+
+ Cleanup: mailing list friendliness. Allow delivery of
+ SMTPUTF8 mail to non-SMTPUTF8 servers when a message has
+ no UTF8 headers, no UTF8 envelope sender, and when the
+ specific delivery request contains no UTF8 envelope recipient.
+ This is needed for mailing lists that may have a mix of
+ UTF8 and non-UTF8 subscriber addresses. File: global/smtputf8.h,
+ smtp/smtp_proto.c.
+
+ Cleanup: moved all SMTPUTF8 detection to the cleanup server,
+ so that it can apply equally to sendmail command-line
+ submission, forwarded mail, postmaster notifications,
+ delivery status notifications, mail received with the qmqpd
+ server, address verification probes, as well as UTF8
+ introduced during local processing (see above). Files:
+ cleanup/cleanup_out.c, cleanup/cleanup_addr.c.
+
+ Cleanup: store the SMTPUTF8 message (i.e. non-recipient)
+ flags in the first queue file record, so that the queue
+ manager can find the information without having to read
+ every queue file record. Files: cleanup/cleanup_final.c,
+ *qmgr/qmgr_message.c.
+
+20140713
+
+ Interoperability: new parameter smtputf8_autodetect_classes
+ for selective autodetection that a message requires UTF8SMTP
+ support. During the initial SMTPUTF8 rollout, this is limited
+ by default to Postfix sendmail command-line submissions and
+ address verification probes. Sites that introduce UTF8
+ during local processing (see above) will have to enable
+ SMTPUTF8 autodetection for all mail sources. This feature
+ shares infrastructure with the older internal_filter_classes
+ feature. Files: bounce/bounce_notify_service.c,
+ bounce/bounce_notify_verp.c, bounce/bounce_one_service.c,
+ bounce/bounce_trace_service.c, bounce/bounce_warn_service.c,
+ global/int_filt.c, global/mail_proto.h, global/smtputf8.c,
+ local/forward.c, pickup/pickup.c, qmqpd/qmqpd.c, smtp/smtp_chat.c,
+ smtpd/smtpd.c, smtpd/smtpd_chat.c, verify/verify.c.
+
+ Feature: preliminary message/global support. This does not
+ yet parse encoded message/global (such as message/global
+ sent through an non-8BITMIME system). Such mail cannot yet
+ be inspected with header_checks. File: global/mime_state.c.
+
+20140714
+
+ Cleanup: update the "smtputf8" delivery request flags when
+ VERP expansion causes an UTF8 recipient address to appear
+ in the envelope sender address. Files: *qmgr/qmgr_deliver.c.
+
+ Cleanup: emit the correct content transfer encoding name
+ when downgrading message/global as quoted-printable. File:
+ global/mime_state.c.
+
+ Cleanup: generate a bounce message with MIME type *global*
+ only when the original message requested SMTPUTF8 support.
+ File: bounce/bounce_notify_util.c.
+
+ Cleanup: propagate the "SMTPUTF8 support requested" flag
+ when bouncing a message or when forwarding a message through
+ a local alias or .forward file. Files: local/forward.c,
+ bounce/bounce_notify_util.c, src/global/post_mail.[hc], and
+ specify a dummy argument SMTPUTF8_FLAGS_NONE in all other
+ programs that programs that invoke post_mail_fopen*(),
+
+20140715
+
+ Cleanup: change extract_addr() API to indicate that an
+ address is parsed in SMTPUTF8 context. File: smtpd/smtpd.c.
+
+ Cleanup: shared-library build fixes. Viktor Dukhovni. Files:
+ makedefs, dns/Makefile.in, global/Makefile.in, master/Makefile.in,
+ tls/Makefile.in, util/Makefile.in.
+
+ First general release with SMTPUTF8 support; see RELEASE_NOTES
+ for an initial writeup. The last pre-SMTPUTF8 release is
+ snapshot 20140713.
+
+20140716
+
+ Paranoia: validate UTF8 before exposing it to libicuuc.
+ File: util/midna.c.
+
+ Typo: Postfix did not warn when smtputf8_enable=yes while
+ UTF-8 support is not compiled in. File: global/mail_params.c.
+
+ Cleanup: hard-coded GCC dependencies. Eray Aslan. File:
+ makedefs.
+
+20140717
+
+ Safety: manipulate unsigned characters while decoding.
+ Files: global/xtext.c, global/uxtext.c.
+
+ Infrastructure: ACE label to UTF-8 conversion. Files:
+ util/midna.[hc].
+
+ Infrastructure: macro expansion with printable() filter.
+ Files: util/mac_expand.[hc].
+
+ Feature: when expanding myhostname or mydomain in bounce
+ template messages, and smtputf8_enable=yes, convert ACE
+ (xn--mumble) labels into UTF-8. bounce/bounce_template.c.
+
+20140720
+
+ Cleanup: charset selection and content-transfer encoding
+ in bounce messages (work in progress). The proper solution
+ requires separate handling of the returned-message MIME
+ properties and of the (boiler-plate text, delivery status)
+ MIME properties. File: bounce/bounce_notify_util.c.
+
+20140722
+
+ Documentation: the TLS_README example for creating a
+ self-signed certificate was incomplete. Also, added
+ "smtp_tls_loglevel = 1" and "smtpd_tls_loglevel = 1" settings
+ to cookbook recipes, so that TLS handshake results will be
+ logged. Viktor Dukhovni. File: proto/TLS_README.html.
+
+ Documentation: update Perl MIME::Base64 example. File:
+ proto/SASL_README.html.
+
+ Documentation: update pointer to Bennett Todd's SMTP proxy.
+ File: proto/SMTPD_PROXY_README.html.
+
+20140725
+
+ Documentation: describe what features are controlled by
+ parent_domain_matches_subdomains, both in the description
+ of the controlled feature, and in the description of
+ parent_domain_matches_subdomains. File: proto/postconf.proto.
+
+ Cleanup: smtpd_client_event_limit_exceptions is now controlled
+ with parent_domain_matches_subdomains, with backwards-compatible
+ default (specify .example.com in order to match subdomains
+ of example.com). Files: smtpd/smtpd.c.
+
+ Documentation: SMTPUTF8_README, an updated version of text
+ that was originally part of the RELEASE_NOTES file. Files:
+ proto/SMTPUTF8_README.html, proto/Makefile.in, html/index.html.
+
+20140731
+
+ Feature: the Postfix SMTP server now logs at the end of a
+ session how many times each SMTP command was successfully
+ invoked, followed by the total number of invocations if it
+ is different. File: smtpd/smtpd.c.
+
+20140802
+
+ Workaround: detect mis-configuration where Postfix talks
+ to the Dovecot master socket instead of the Dovecot userdb
+ socket. Timo Sirainen. File: xsasl/xsasl_dovecot_server.c.
+
+20140904
+
+ Logging: the MySQL client now logs a warning when a match
+ against the "domain" list fails due to table lookup error
+ (the underlying mechanism already logs a warning, but it
+ has less context information). File: global/dict_mysql.c.
+
+20140907
+
+ Feature: with "confirm_delay_cleared = yes", Postfix informs
+ the sender when delayed mail leaves the queue. This can
+ result in a sudden burst of notifications at the end of a
+ prolonged network outage, and is therefore disabled by
+ default. Files: mantools/postlink, proto/postconf.proto,
+ global/deliver_request.h, global/mail_params.h, global/sent.c,
+ *qmgr/qmgr.c, *qmgr/qmgr_active.c, *qmgr/qmgr_message.c.
+
+20140908-14
+
+ Feature: for the first time in 17 years, support for
+ ${name?if-nonempty:if-empty} macro expressions, and for
+ logical expressions ${logical-expr?if-true:if-false}. In
+ preparation for configurable message headers and logging.
+ Files: util/mac_expand.c.
+
+20140914
+
+ Bugfix (introduced: 19971026): a zero precision value in
+ %.*s and $.s was implemented as if no precision
+ value was specified, i.e. print the entire string. This was
+ not harmful, it just looked weird. File: util/vbuf_print.c.
+
+20120917
+
+ Feature: RFC 7372 enhanced status code for unknown SMTP
+ client hostnames. File: smtpd/smtpd_check.c
+
+ Bugfix: the accept() calls in test progams escaped attention
+ when Postfix 2.2 was ported to IPv6. Problem found by Mark
+ Martinec. Files: smtpstone/smtp-sink.c, smtpstone/qmqp-sink.c.
+
+20140918
+
+ Cleanup: log a warning when the cleanup server detects too
+ many hops. smtpd(8) does not log any of the CLEANUP_STAT_XXX
+ results. The pickup server logs some because there is no
+ client to send the problem description to. This logic of
+ who logs what needs to be revisited. File:
+ cleanup/cleanup_message.c.
+
+20140919
+
+ Usability: randmap and pipemap syntax, for example,
+ pipemap:{type_1:name_1, ..., type_n:name_n}. This required
+ small updates to code that parses input into lookup table
+ names. Files: global/data_redirect.c, global/maps.c,
+ global/server_acl.c, postconf/postconf.c, postconf/postconf_dbms.c,
+ postconf/test58.ref, proto/DATABASE_README.html,
+ proxymap/proxymap.c, smtpd/smtpd_check.c, util/argv.h,
+ util/balpar.c, util/dict_pipe.c, util/dict_random.c,
+ util/match_list.c, util/mystrtok.c, util/argv_splitq.c,
+ util/stringops.h.
+
+ Cleanup: added PRINTFLIKE() to enable missing format string
+ checks. Files: bounce/bounce_template.h, global/memcache_proto.h,
+ global/dict_memcache, postconf/postconf.h, util/dict.h,
+ util/msg.h.
+
+20140920
+
+ Bugfix (introduced: 20080212): incorrect client name in
+ reject messages from check_reverse_client_hostname_access
+ and check_reverse_client_hostname_{a,mx,ns}_access. They
+ replied with the verified client name, instead of the name
+ that was rejected. Problem reported by Reindl Harald. File:
+ smtpd/smtpd_check.c.
+
+20140921
+
+ Cleanup: postconf code to determine the default mydomain
+ value had not evolved since 1997, while the rest of Postfix
+ changed in 2000. File: postconf/postconf-dbms.c.
+
+20140922
+
+ Cleanup: the confirm_delay_cleared feature now sends no
+ notification when the sender requests NOTIFY options that
+ do not include NOTIFY=DELAY. Files: global/deliver_request,h,
+ global/sent.c, *qmgr/qmgr_active.c, *qmgr/qmgr_message.c.
+
+ Bugfix (introduced: yesterday): missing print arguments.
+ File: postconf/postconf_dbms.c.
+
+ Cleanup: simplified "nested" lookup table checks.
+
+ Cleanup: replace stress-dependent main.cf defaults with the
+ ternary form: "${stress?{x}:{y}}" File: global/mail_params.h,
+ proto/postconf.proto, postscreen/postscreen.c (comments).
+
+20140923
+
+ Cleanup: dict_db and dict_lmdb global settings. Files:
+ global/mail_params.c, util/dict_open.c.
+
+ Feature: unionmap, based on contribution by Roel van Meer.
+ Files: mantools/postlink, postconf/postconf.c (manpage),
+ proto/DATABASE_README.html, util/dict_open.c, util/dict_union.[hc].
+
+20140924
+
+ Bugfix (introduced: 20060117): the escape function didn't
+ correctly convert non-ASCII. File: util/unescape.c.
+
+ Bugfix (introduced: 201407): missing conversions for non-ASCII
+ domain names in permit_mx_backup, check_mumble_{a,mx,ns}_access
+ and reject_unknown_{sender,recipient}_domain. Mark Martinec.
+ File: smtpd/smtpd_check.c.
+
+20140925
+
+ Cleanup: support for per-Milter settings, for example:
+ smtpd_milters = {inet:host:port, default_action=accept,
+ ...}. Specify the Milter endpoint address followed by zero
+ or more attribute=value pairs separated by comma or space.
+ The supported attributes are command_timeout, connect_timeout,
+ content_timeout, default_action, and protocol. These have
+ the same names as the corresponding main.cf parameters,
+ minus the "milter_" prefix. Files: global/mail_conf_over.c,
+ global/mail_conf_str.c, global/mail_conf_time.c,
+ global/mail_conf.h, milter/milters.c.
+
+20140927
+
+ Cleanup: specify { name = value } in per-Milter settings,
+ to support space around the "=" or comma/space within the
+ value. Files: global/attr_over.[hc].
+
+ Cleanup: "postconf -n" now only shows config_directory when
+ an override is in effect (environment, -c or -o).
+
+ Cleanup: support for master.cf arguments inside {}, to
+ protect arguments that contain whitespace. File:
+ master/master_ent.c, postconf/postconf_master.c,
+ postconf/test59.ref.
+
+ Cleanup: support for per-policy client settings, for example:
+ check_policy_service {inet:host:port, default_action=dunno,
+ timeout=50s, ...}. Specify the policy server endpoint address
+ followed by zero or more attribute=value pairs separated
+ by comma or space. Specify { name = value } for attributes
+ that contain whitespace; otherwise, space is not allowed
+ around the "=". The supported attributes are default_action,
+ max_idle, max_ttl, request_limit, retry_delay, timeout, and
+ try_limit. These have the same names as the corresponding
+ main.cf parameters, minus the "smtpd_policy_service_" prefix.
+ Files: global/mail_conf_int.c, global/mail_conf.h,
+ global/attr_override.[hc], smtpd/smtpd_check.c.
+
+20140928
+
+ Cleanup: extpar.c module to reduce code duplication. Files:
+ global/attr_override.c, master/master_ent.c, milter/milter.c,
+ postconf/postconf_dbms.c, postconf/postconf_master.c,
+ smtpd/smtpd_check.c, util/extpar.c, util/stringops.h.
+
+ Cleanup: the table-driven code for per-Milter and per-policy
+ overrides now updates stack-based variables, instead of
+ (ugh) statically-allocated variables. Files:
+ global/attr_override.[hc], smtpd/smtpd_check.c, milter/milter.c.
+
+ Documentation: added advanced configuration sections for
+ how to use per-Milter and per-policy settings. Files:
+ proto/SMTPD_POLICY_README.html, proto/MILTER_README.html.
+
+ Cleanup: force LANG=C to prevent groff from outputting
+ non-ASCII cruft into the HTML-ized manpages. Files:
+ html/Makefile.in, proto/Makefile.in, many HTML output files.
+
+20140929
+
+ Cleanup: the table-driven code for per-Milter and per-policy
+ overrides now updates arbitrary variables, so that it can
+ also be used for, say, TLS policies. Files:
+ global/attr_override.[hc], smtpd/smtpd_check.c, milter/milter.c.
+
+ Documentation: support for "{ argument with whitespace }"
+ in master(5) and pipe(8). Files: proto/master, src/pipe/pipe.c.
+
+ Documentation: in ADDRES_VERIFY_README, replaced "nearest
+ MTA" with "preferred MTA". The SMTP client was changed years
+ ago to try alternate MXes after a 4XX SMTP server response.
+ File: proto/ADDRES_VERIFY_README.html.
+
+20141001
+
+ Safety: backwards-compatibility safety net that forces
+ Postfix to run with backwards-compatible default settings
+ after an upgrade to a newer Postfix version. Postfix logs
+ all uses of those backwards-compatible default settings so
+ that the system administator can determine whether or not
+ some backwards-compatible default settings need to be made
+ permanent in main.cf or master.cf. All this is controlled
+ with a new compatibility_level parameter, default value 0.
+ Files: global/mail_params.[hc], trivial-rewrite/rewrite.c,
+ master/master_ent.c, smtpd/smtpd.c, postfix/postfix.c.
+
+ New defaults for master.cf chroot (n), append_dot_mydomain
+ (no) and smtputf8_enable (yes). File: global/mail_params.h,
+ global/mail_params.c, smtp/smtp.c (manpage), smtpd/smtpd.c
+ (manpage), trivial-rewrite/trivial-rewrite.c.
+
+ Simple relational expression evaluator so that main.cf
+ defaults can be made dependent on comparisons with the
+ compatibility_level parameter value. File: util/mac_expand.c.
+
+ Bugfix: do not reset the mail transaction after receiving
+ a non-ASCII recipient. File: smtpd/smtpd.c.
+
+20141002
+
+ Cleanup: moved the details of BC safety-net messages from
+ RELEASE_NOTES to postconf(5) manpage, and changed the wording
+ of the BC messages. Files: RELEASE_NOTES, proto/postconf.proto,
+ master/master_ent.c, smtpd/smtpd.c, trivial-rewrite/rewrite.c.
+
+20141003
+
+ Workaround: kludge for multiple paragraphs of text in
+ indented paragraphs. Files: mantools/postconf2html,
+ mantools/postconf2man, proto/Makefile.in, proto/postconf.proto
+
+20141005
+
+ Cleanup: CHARSET_COMMA_SP, CHARSET_SPACE and CHARSET_BRACE
+ to prepare for the elimination of ad-hoc string constants.
+ File: util/sys_defs.h.
+
+ Cleanup: allow "{ name=value }" to protect whitespace in
+ import_environment and export_environment. Files:
+ proto/postconf.proto, global/mail_parm_split.c, global
+ /mail_parm_split.h, global/mail_stream.c, local/command.c,
+ master/master.c, pipe/pipe.c, postdrop/postdrop.c,
+ postfix/postfix.c, postmulti/postmulti.c, postqueue/postqueue.c,
+ spawn/spawn.c.
+
+20141006
+
+ Backwards compatibility: log a helpful message when "localhost"
+ is missing from mydestination. Files: trivial_rewrite/rewrite.c,
+ trivial_rewrite/resolve.c, trivial-rewrite/trivial-rewrite.h,
+ proto/postconf.proto.
+
+ Cleanup: message_drop_header for configurable header dropping
+ (default: bcc, content-length, resent-bcc, return-path).
+ The list of supported header names covers RFC 5321, 5322,
+ MIME RFCs, and some historical names. File: global/header_opts.c,
+ global/mail_params.[hc], cleanup/cleanup.c (manpage),
+ proto/postconf.proto, mantools/postlink.
+
+20141008
+
+ New defaults: "relayhost=" and "mynetworks_style = host",
+ plus a backwards-compatibility safety net that warns when
+ the change in defaults could result in rejection of mail
+ (with mynetworks_style this requires that Postfix evaluates
+ both old and new default values). Files: proto/postconf.proto,
+ global/flush_clnt.c, global/mail_params.c, global/mail_params.h,
+ global/mynetworks.c, global/mynetworks.h, global/server_acl.c,
+ postconf/postconf_builtin.c, smtpd/smtpd.c, smtpd/smtpd_check.c.
+
+20141009
+
+ Documentation: moved the gory details from postconf(5) to
+ a new COMPATIBILITY_README document. Files: proto/postconf.proto,
+ proto/COMPATIBILITY_README.html html/index.html.
+
+ Documentation: update the conf/main.cf compatibility_level
+ setting for new Postfix installs, and updated a reminder
+ in mail_params.h.
+
+20141010
+
+ Cleanup: make "const char myname[]" declarations static.
+ global/attr_override.c, global/bounce.c, global/dsn_filter.c,
+ global/dynamicmaps.c, global/mkmap_open.c, global/smtputf8.c,
+ smtp/smtp_key.c, smtpd/smtpd_check.c, util/dict_pipe.c,
+ util/dict_union.c, util/mac_expand.c, util/midna.c,
+ util/valid_utf8_hostname.c.
+
+ Documentation: summarize the user-specified "make makefiles"
+ settings at the top of makedefs.out. This file now has so
+ many internal variables that people would get lost.
+
+20141011
+
+ Cleanup: replaced cryptic macros X_SMTP() and SMTP_X() with
+ more descripive names: LMTP_SMTP_SUFFIX() and VAR_LMTP_SMTP().
+ Files: smtp/smtp.c, smtp/smtp.h, smtp/smtp_chat.c,
+ smtp/smtp_connect.c, smtp/smtp_proto.c, smtp/smtp_sasl_glue.c,
+ smtp/smtp_sasl_proto.c, smtp/smtp_tls_policy.c.
+
+20141012
+
+ Cleanup: missing format-string checks. Files: master/master_ent.c,
+ posttls-finger/posttls-finger.c, smtpd/smtpd_proxy.c.
+
+ Bugfix (introduced: Postfix 2.3): the PREPEND access/policy
+ action added headers ABOVE Postfix's own Received: header,
+ exposing Postfix's own Received: header to Milters (protocol
+ violation) and hiding the PREPENDed header from Milters.
+ The latter caused problems for DMARC implementations with
+ SPF policy plus DKIM Milter. PREPENDed headers are now
+ added BELOW Postfix's own Received: header and remain visible
+ to Milters. File: smtpd/smtpd.c.
+
+20141013
+
+ Cleanup: configuration file line numbers in error/warning
+ messages could point to comment lines before or after the
+ problem. Files: util/readlline.[hc], master/master_ent.c,
+ postalias/postalias.c, postmap/postmap.c, util/dict.c,
+ util/dict_cidr.c, util/dict_pcre.e, util/dict_regexp.c,
+ util/dict_thash.c, postconf/postconf_master.c.
+
+20141014
+
+ Portability: Darwin 11.x needs to link with -lresolv. Viktor
+ Dukhovni. File: makedefs.
+
+ Documentation: ICU (unicode) library package names. File:
+ proto/SMTPUTF*_README.html.
+
+20141015
+
+ Cleanup: master.cf line number reporting made more consistent
+ with similar code elsewhere. File: master/master_ent.c.
+
+ Backed out SMTP client TLS fallback due to multiple problems.
+
+20141018
+
+ Bugfix (introduced: Postfix 2.3): when a Milter inserted a
+ header ABOVE Postfix's own Received: header, Postfix would
+ expose its own Received: header to Milters (violating
+ protocol) and hide the Milter-inserted header from Milters
+ (wtf). Files: cleanup/cleanup.h, cleanup/cleanup_message.c,
+ cleanup/cleanup_state.c, milter/milter.[hc], milter/milter8.c.
+
+ Cleanup: revert the workaround that places headers inserted
+ with PREPEND actions or policy requests BELOW Postfix's own
+ Received: message header. File: smtpd/smtpd.c.
+
+20141019
+
+ Cleanup: replace dozens and dozens of ad-hoc string constants
+ with CHARS_SPACE, CHARS_COMMA_SP, and CHARS_BRACE. Files:
+ 52, too many files to mention here.
+
+ Bugfix: the recently-introduced randmap, pipemap, and
+ unionmap did not check for all possible forms of "empty
+ list". Files: util/dict_random.c, util/dict_pipe.c,
+ util/dict_union.c.
+
+ Documentation: word smithing. File: proto/master.
+
+ Cleanup: the last remaining remnants of the withdrawn
+ smtp_tls_fallback_level feature. Files: mantools/postlink,
+ global/mail_params.h.
+
+20141021
+
+ Per IETF TLS WG consensus, the tls_session_ticket_cipher
+ default setting was changed from aes-128-cbc to aes-256-cbc.
+ Take that, you quantum computer attackers! Viktor Dukhovni.
+ Files: proto/postconf.proto, global/mail_params.h.
+
+20141024
+
+ Cleanup: added $smtpd_mumble_restrictions to the proxy_read_maps
+ default setting. File: global/mail_params.h.
+
+ Documentation: different header/body checks for MX service
+ and SMTP submissions. File: proto/BUILTIN_FILTER_README.html.
+
+ Cleanup: don't send "bare" original recipient in SMTP DSN
+ attributes. File: cleanup/cleanup_addr.c.
+
+ Feature: smtp-sink -N option to suppress DSN announcement.
+ File: smtpstone/smtp-sink.c.
+
+20141025
+
+ Bugfix (introduced: Postfix 2,11): core dump when
+ smtp_policy_maps specifies an invalid TLS level. Viktor
+ Dukhovni. File: smtp/smtp_tls_policy.c.
+
+20141103
+
+ Logging: when a connection is closed, log the request counts
+ for unimplemented STARTTLS or AUTH commands separately,
+ instead of logging such commands as "unknown". File:
+ smtpd/smtpd.c.
+
+20141106
+
+ Cleanup: set errno to ETIMEDOUT after postscreen handshake
+ timeout event, so that warnings report the correct error.
+ File: tlsproxy/tlsproxy.c.
+
+20141112
+
+ Documentation: 24 identical typos. File: proto/postconf.proto.
+
+ Workaround: support space after "MAIL FROM:" and "RCPT TO:"
+ in smtpd_command_filter examples. Reportedly, cashedge.com's
+ software (used by banks) needs this (source: Claus Assmann).
+ File: proto/postconf.proto.
+
+20141117
+
+ Cleanup: use ~0U instead of (unsigned) -1. Based on
+ complaints from the BEAM static analyzer. Files:
+ global/mynetworks.c, postconf/postconf.c, util/cidr_match.c.
+
+ Cleanup: forgot the "do" in "do { stuff } while (0)" macros.
+ Luckily, this had caused no problem. Based on complaints
+ from the BEAM static analyzer. Files: util/dict_cdb.c,
+ util/dict_dbm.c, util/dict_lmdb.c, util/dict_pcre.c,
+ util/dict_regexp.c, util/dict_sockmap.c, util/dict_thash.c.
+
+ Bugfix (introduced: Postfix 2.9): lockfile descriptor leak
+ after error. Based on complaints from the BEAM static
+ analyzer. File: util/dict_db.c.
+
+ Bugfix (introduced: Postfix 1.1): don't "set" the null byte
+ element in the base64 and base32 decoding maps. Based on
+ complaints from the BEAM static analyzer. Files: util/base64_code,
+ util/base32_code.c.
+
+ Cleanup: don't exit(0) after failing to run showq(8). Based
+ on complaints from the BEAM static analyzer. File:
+ postqueue/postqueue.c.
+
+ Bugfix: memory leak when getaddrinfo() returns a result
+ that is neither IPv4 nor IPv6. Based on complaints from
+ the BEAM static analyzer. File: smtp/smtp_addr.c.
+
+ Cleanup: use more meaningful name for global variable so
+ that it isn't shadowed by a local variable. Based on
+ complaints from the BEAM static analyzer. smtpstone/smtp-sink.c.
+
+20141119
+
+ Cleanup: base64 test driver. File: base64_code.c.
+
+ Cleanup: make the CONST_CHAR_STAR typedef project-wide.
+ Files: global/attr_override.h, util/sys_defs.h.
+
+ Feature: BCC action in header/body_checks and milter_header_checks.
+ Files: proto/header_checks, cleanup/cleanup.h,
+ cleanup/cleanup_extracted.c, cleanup/cleanup_message.c,
+ cleanup/cleanup_milter.c, cleanup/cleanup_milter.in16a,
+ cleanup/cleanup_milter.ref16a1, cleanup/cleanup_milter.ref16a2,
+ cleanup/cleanup_milter.reg16a, cleanup/cleanup_state.c,
+ cleanup/test-queue-file16, global/attr_override.h,
+ global/cleanup_strflags.c, global/cleanup_user.h,
+ util/sys_defs.h.
+
+ Cleanup: don't write back-to-back queue file pointer records
+ when the "add recipient" action was a NOOP (e.g., because
+ the recipient was a duplicate). File: cleanup/cleanup_milter.c.
+
+20141120
+
+ Documentation: COMPATIBILITY_README now has "purpose of
+ this document" section, plus a separate section for turning
+ off the safety net. File: proto/COMPATIBILITY_README.html
+
+20131121
+
+ Cleanup: replace mua_mumble with msa_mumble in master.cf
+ submission and smtps service parameter overrides. File:
+ proto/BUILTIN_FILTER_README.html.
+
+ Feature: "static:{ text with whitespace }". This could be
+ used as check_mumble_access static:{reject text...} at the
+ end of smtpd_mumble_restrictions. Files: util/dict_static.c,
+ util/Makefile.in, util/dict_static_test.ref,
+ proto/DATABASE_README.html. postconf/postconf.c (manpage).
+
+20141126
+
+ Feature: "inline:{key=value, { key = text with comma/space}}"
+ avoids the need to create a database for just a few entries.
+ Files: util/dict_inline.[hc], mantools/postlink,
+ proto/DATABASE_README.html. postconf/postconf.c (manpage),
+ util/dict_inline.[hc], util/dict_open.c, util/Makefile.in,
+ util/dict_inline_test.ref.
+
+ Cleanup: report nullmx DNS records as "domain does not
+ accept mail", instead of "invalid DNS response". The Postfix
+ SMTP client already bounced mail for such domains, and the
+ Postfix SMTP server already rejected such domains with
+ reject_unknown_sender/recipient_domain. This introduces a
+ new SMTP server configuration parameter nullmx_reject_code
+ (default: 556). Files: src/dns/dns_lookup.[hc], dns/Makefile,in,
+ dns/nullmx_test.ref, src/smtp/smtp_addr.c, smtpd/smtpd_check.c,
+ smtpd/smtpd_check_nullmx.in, smtpd/smtpd_check_nullmx.ref,
+ mantools/postlink, proto/postconf.proto, smtpd/smtpd.c.
+
+ Cleanup: added some missing libdns tests: dns/Makefile,in,
+ dns/mxonly_test,ref, dns/nxdomain_test.ref
+
+ Cleanup: libglobal "make test" had suffered from bitrot.
+ Files: global/mime_state.c, global/header_body_checks.c.
+
+20141127
+
+ Feature: DNS reply filter, configured with smtp_dns_reply_filter,
+ smtpd_dns_reply_filter, and lmtp_dns_reply_filter. Files:
+ mantools/postlink, proto/postconf.proto, dns/dns.h,
+ dns/dns_lookup.c, dns/dns_rr_filter.c, dns/dns_strrecord.c,
+ dns/error.ref, dns/error.reg, dns/mxonly_test.ref, dns/no-a.ref,
+ dns/no-a.reg, dns/no-aaaa.ref, dns/no-aaaa.reg, dns/no-mx.ref,
+ dns/no-mx.reg, dns/nullmx_test.ref, dns/test_dns_lookup.c,
+ global/mail_params.h, smtp/lmtp_params.c, smtp/smtp.c,
+ smtp/smtp_addr.c, smtp/smtp_params.c, smtpd/smtpd.c,
+ smtpd/smtpd_check.c, smtpd/smtpd_dns_filter.{in,ref}.
+
+20141130
+
+ Cleanup: when searching multiple DNS record types for a
+ specific name, and not all queries return the same result
+ status, do not blindly return the last query's rcode and
+ diagnostic text. Instead, return rcode and text that is
+ consistent with the aggregate result status.
+
+ Cleanup: un-broke several smtpd regression tests (work in
+ progress, with three more to go). Files: smtpd/smtpd_check.c,
+ smtpd/smtpd_server.{in,ref}, smtpd/smtpd_exp.{in,ref}.
+ smtpd/smtpd_dnswl.{in,ref}.
+
+ Documentation: added note on Milter-signing bounces.
+
+20141201
+
+ Bugfix (introduced: 20141130): memory leak. File: dns_lookup.c.
+
+ Cleanup: un-broke several dns regression tests by sorting
+ getaddrinfo() results by address family. Files: dns/dns_rr_eq_sa.c,
+ dns/dns_rr_eq_sa.ref, dns/dns_sa_to_rr.c, dns/dns_sa_to_rr.ref.
+
+ Cleanup: missing #ifdef in smtpd_check test driver. File:
+ smtpd/smtpd_check.c.
+
+ Cleanup: fix google.com regexp in smtp_dns_reply_filter
+ example. Viktor Dukhovni. File: proto/postconf.proto.
+
+ Cleanup: in the ASCII form of DNS resource records, add
+ space after the TLSA match-type field. Viktor Dukhovni.
+ File: dns/dns_strrecord.c.
+
+20141202
+
+ Cleanup: to increase clarity. rename DNS result status from
+ DNS_UNAVAIL to DNS_NULLMX. If someone uses the same zero-length
+ name trick with some other resource type, then we will worry
+ about that later. Files: smtpd/smtpd_check.c, smtp/smtp_addr.c,
+ dns/dns.h, dns/dns_lookup.c.
+
+ Cleanup: eliminate TLS state duplication from state->tls
+ to session->tls. Viktor Dukhovni. Files: src/smtp/smtp.h,
+ src/smtp/smtp_connect.c, src/smtp/smtp_proto.c,
+ src/smtp/smtp_reuse.c, src/smtp/smtp_session.c.
+
+20141203
+
+ Feature: support to match UTF8 domain names against ASCII
+ names in TLS certificates. Viktor Dukhovni. Files:
+ posttls-finger/posttls-finger.c, tls/tls_client.c.
+
+20141206
+
+ Cleanup: use (char *) only for strings, not for data. The
+ "void *" type was not fully portable during initial Postfix
+ development, but we no longer have that problem. Also started
+ the migration of data structure sizes/counters to ssize_t/size_t
+ (the IBM Beam analyzer identified lots of unnecessary 64-bit
+ to 32-bit conversions). The transformation and verification
+ were mostly mechanical with manual supervision. Files:
+ anvil/anvil.c, bounce/bounce.c, bounce/bounce_notify_util.c,
+ bounce/bounce_template.c, bounce/bounce_templates.c,
+ cleanup/cleanup_message.c, cleanup/cleanup_region.c,
+ cleanup/cleanup_state.c, dns/dns_lookup.c, dns/dns_rr.c,
+ dns/dns_rr_eq_sa.c, dns/dns_rr_to_sa.c, dns/test_dns_lookup.c,
+ flush/flush.c, global/abounce.c, global/abounce.h,
+ global/been_here.c, global/bounce_log.c, global/clnt_stream.c,
+ global/db_common.c, global/deliver_request.c,
+ global/delivered_hdr.c, global/dict_ldap.c, global/dict_mysql.c,
+ global/dict_pgsql.c, global/dsn.c, global/dsn_buf.c,
+ global/dsn_filter.c, global/dynamicmaps.c,
+ global/header_body_checks.c, global/header_opts.c,
+ global/mail_addr_crunch.c, global/mail_stream.c,
+ global/mail_version.c, global/maps.c, global/mbox_open.c,
+ global/mime_state.c, global/mkmap_open.c, global/msg_stats_scan.c,
+ global/mypwd.c, global/post_mail.c, global/rcpt_buf.c,
+ global/recipient_list.c, global/scache_clnt.c,
+ global/scache_multi.c, global/scache_single.c,
+ global/smtp_reply_footer.c, global/smtp_reply_footer.h,
+ global/tok822_node.c, local/biff_notify.c, local/forward.c,
+ local/local_expand.c, local/unknown.c, master/event_server.c,
+ master/master.c, master/master_avail.c, master/master_ent.c,
+ master/master_monitor.c, master/master_proto.c,
+ master/master_sig.c, master/master_spawn.c, master/master_status.c,
+ master/master_vars.c, master/master_wakeup.c,
+ master/multi_server.c, master/single_server.c,
+ master/trigger_server.c, milter/milter.c, milter/milter8.c,
+ milter/milter_macros.c, oqmgr/qmgr.c, oqmgr/qmgr_active.c,
+ oqmgr/qmgr_deliver.c, oqmgr/qmgr_entry.c, oqmgr/qmgr_message.c,
+ oqmgr/qmgr_queue.c, oqmgr/qmgr_transport.c, pipe/pipe.c,
+ postalias/postalias.c, postconf/postconf.h,
+ postconf/postconf_builtin.c, postconf/postconf_edit.c,
+ postconf/postconf_lookup.c, postconf/postconf_main.c,
+ postconf/postconf_master.c, postconf/postconf_node.c,
+ postconf/postconf_service.c, postconf/postconf_user.c,
+ postmap/postmap.c, postmulti/postmulti.c, postscreen/postscreen.c,
+ postscreen/postscreen.h, postscreen/postscreen_dnsbl.c,
+ postscreen/postscreen_early.c, postscreen/postscreen_expand.c,
+ postscreen/postscreen_haproxy.c, postscreen/postscreen_send.c,
+ postscreen/postscreen_smtpd.c, postscreen/postscreen_starttls.c,
+ postscreen/postscreen_state.c, posttls-finger/posttls-finger.c,
+ posttls-finger/tlsmgrmem.c, proxymap/proxymap.c, qmgr/qmgr.c,
+ qmgr/qmgr_active.c, qmgr/qmgr_deliver.c, qmgr/qmgr_entry.c,
+ qmgr/qmgr_job.c, qmgr/qmgr_message.c, qmgr/qmgr_peer.c,
+ qmgr/qmgr_queue.c, qmgr/qmgr_transport.c, qmqpd/qmqpd_peer.c,
+ qmqpd/qmqpd_state.c, scache/scache.c, sendmail/sendmail.c,
+ showq/showq.c, smtp/smtp_chat.c, smtp/smtp_connect.c,
+ smtp/smtp_proto.c, smtp/smtp_reuse.c, smtp/smtp_session.c,
+ smtp/smtp_state.c, smtp/smtp_tls_policy.c, smtpd/smtpd.c,
+ smtpd/smtpd_chat.c, smtpd/smtpd_check.c, smtpd/smtpd_expand.c,
+ smtpd/smtpd_expand.h, smtpd/smtpd_peer.c, smtpd/smtpd_proxy.c,
+ smtpstone/qmqp-sink.c, smtpstone/qmqp-source.c,
+ smtpstone/smtp-sink.c, smtpstone/smtp-source.c, tls/tls_dane.c,
+ tls/tls_mgr.c, tls/tls_misc.c, tls/tls_prng_dev.c,
+ tls/tls_prng_egd.c, tls/tls_prng_exch.c, tls/tls_prng_file.c,
+ tls/tls_proxy_clnt.c, tls/tls_scache.c, tls/tls_server.c,
+ tlsmgr/tlsmgr.c, tlsproxy/tlsproxy.c, tlsproxy/tlsproxy_state.c,
+ trivial-rewrite/transport.c, trivial-rewrite/trivial-rewrite.c,
+ util/argv.c, util/attr_clnt.c, util/attr_print0.c,
+ util/attr_print64.c, util/attr_print_plain.c, util/attr_scan0.c,
+ util/attr_scan64.c, util/attr_scan_plain.c, util/auto_clnt.c,
+ util/binhash.c, util/binhash.h, util/ctable.c, util/ctable.h,
+ util/dict.c, util/dict.h, util/dict_alloc.c, util/dict_cache.c,
+ util/dict_cache.h, util/dict_cidr.c, util/dict_db.c,
+ util/dict_ht.c, util/dict_open.c, util/dict_pcre.c,
+ util/dict_regexp.c, util/dict_sockmap.c, util/dict_surrogate.c,
+ util/dict_thash.c, util/edit_file.c, util/events.c,
+ util/events.h, util/fifo_trigger.c, util/find_inet.c,
+ util/htable.c, util/htable.h, util/inet_addr_host.c,
+ util/inet_addr_list.c, util/inet_addr_local.c, util/inet_listen.c,
+ util/inet_proto.c, util/inet_trigger.c, util/inet_windowsize.c,
+ util/iostuff.h, util/line_wrap.c, util/line_wrap.h,
+ util/mac_expand.c, util/mac_expand.h, util/mac_parse.c,
+ util/mac_parse.h, util/match_list.c, util/msg_output.c,
+ util/mvect.c, util/myaddrinfo.c, util/myflock.c, util/mymalloc.c,
+ util/mymalloc.h, util/nbbio.c, util/nbbio.h, util/netstring.c,
+ util/nvtable.c, util/nvtable.h, util/pass_trigger.c,
+ util/sane_accept.c, util/sane_connect.c, util/scan_dir.c,
+ util/sock_addr.c, util/stream_trigger.c, util/sys_compat.c,
+ util/sys_defs.h, util/timecmp.c, util/timed_connect.c,
+ util/timed_write.c, util/unix_connect.c, util/unix_listen.c,
+ util/unix_recv_fd.c, util/unix_send_fd.c, util/unix_trigger.c,
+ util/vbuf.c, util/vbuf.h, util/vstream.c, util/vstream_tweak.c,
+ util/vstring.c, util/watchdog.c, verify/verify.c,
+ xsasl/xsasl_cyrus_client.c, xsasl/xsasl_cyrus_server.c,
+ xsasl/xsasl_dovecot_server.c.
+
+ Cleanup: removed unnecessary casts. File: global/cfg_parser.c.
+
+ Cleanup: dont cast away "const". File: global/dict_sqlite.c.
+
+20141208
+
+ Bugfix (introduced: 20141207): in new #ifdef, && should be
+ ||. File: smtpd.c.
+
+20141210
+
+ Cleanup: the "inline" table now supports case-insensitive
+ search, and an iterator. File: util/dict_inline.c.
+
+ Cleanup: minuscule memory leaks in graceful degradation
+ after lookup table open error. Files: util/dict_inline.c,
+ util/dict_static.c.
+
+20141211
+
+ Cleanup: memory leaks in unit-test driver programs (i.e.
+ code used only during development). Files:
+ cleanup/cleanup_milter.c, util/base64_code.c.
+
+ Bugfix (introduced 20141001): mac_expand() error message
+ with "??" due to dangling pointer. File: util/mac_expand.c.
+
+ Portability: unit-test driver programs. Files: util/myaddrinfo.c,
+ util/myaddrinfo.ref.
+
+ Portability: Clang support. Files: makedefs, util/sys_defs.h.
+
+ Portability: FreeBSD 10 support. Files: makedefs,
+ util/sys_defs.h.
+
+ Cleanup: in makedefs, the CC and WARN features are now
+ independent. File: makedefs.
+
+ Shut up some Clang format-string nags: util/events.c.
+
+ Cleanup: eliminated unnecessary 64->32bit (and back)
+ conversions on LP64 platforms. Files: util/htable.c,
+ util/binhash.c util/mvect.[hc], util/name_mask.c,
+ util/sane_time.c, util/unix_listen.c, util/unix_connect.c,
+ util/stringops.h, util/trimblanks.c, and dependent code in
+ smtpd/smtpd_token.c.
+
+ Cleanup: unused inet_proto_init() results. Files:
+ global/mail_params.c, postconf/postconf_builtin.c,
+ smtpstone/qmqp-sink.c, smtpstone/qmqp-source.c,
+ smtpstone/smtp-source.c/
+
+ Shut up some Clang nags about unused functions in network
+ interface API selection. File: util/inet_addr_local.c.
+
+ Portability: a historical compiler lacks printf-like
+ format-string checks for function pointers. Files: util/msg.h,
+ bounce/bounce_template.h.
+
+20141212
+
+ Shut up some Clang format-string nags: util/line_number.c,
+ sendmail/sendmail.c, smtpd/smtpd_proxy.c, smtp/smtp_sasl_proto.c.
+
+ Cleanup: eliminated unnecessary 64->32bit (and back)
+ conversions on LP64 platforms. Files: dict_memcache.c,
+ header_body_checks.[hc], log_adhoc.c, pipe_command.c,
+ record.[hc], smtp_reply_footer.c, split_addr.c.
+ cleanup/cleanup_milter.c, master/mail_server.h,
+ src/master/trigger_server.c, oqmgr/qmgr.c, qmgr/qmgr.c,
+ pickup/pickup.c.
+
+ Cleanup: nullmx SMTP reply codes 550 and 556, and enhanced
+ status codes X.1.10 and X.7.27. The nullmx SMTP reply codes
+ are no longer configurable. Files: global/mail_params.h,
+ smtpd/smtpd.c, smtpd/smtpd_check.c.
+
+ Portability: default table owner UID for testing. Files:
+ util/dict_alloc.c, util/dict_open.c.
+
+ Shut up Clang unused assignment nag: global/mail_queue.h.
+ sendmail/sendmail.c, smtpd/smtpd_proxy.c, smtp/smtp_sasl_proto.c.
+
+20141214
+
+ Bugfix (introduced: 20141212): typo in Clang function pointer
+ format check, making it a noop. Viktor Dukhovni. File:
+ util/sys_defs.h.
+
+ Maintainability: compile-time argument typechecking for
+ variadic attribute-value read/write functions. Files:
+ anvil/anvil.c, bounce/bounce.c, cleanup/cleanup.c,
+ dnsblog/dnsblog.c, flush/flush.c, global/abounce.c,
+ global/anvil_clnt.c, global/bounce.c, global/defer.c,
+ global/deliver_pass.c, global/deliver_request.c,
+ global/dict_proxy.c, global/dsb_scan.c, global/dsn_print.c,
+ global/flush_clnt.c, global/mail_command_client.c,
+ global/mail_stream.c, global/msg_stats_print.c,
+ global/msg_stats_scan.c, global/post_mail.c, global/rcpt_buf.c,
+ global/rcpt_print.c, global/resolve_clnt.c, global/rewrite_clnt.c,
+ global/scache_clnt.c, global/trace.c, global/verify_clnt.c,
+ local/forward.c, milter/milter.c, milter/milter8.c,
+ milter/milter_macros.c, oqmgr/qmgr_deliver.c, pickup/pickup.c,
+ postdrop/postdrop.c, postscreen/postscreen_dnsbl.c,
+ postscreen/postscreen_send.c, postscreen/postscreen_starttls.c,
+ proxymap/proxymap.c, qmgr/qmgr_deliver.c, qmqpd/qmqpd.c,
+ scache/scache.c, smtpd/smtpd.c, smtpd/smtpd_check.c,
+ tls/tls_mgr.c, tls/tls_proxy_clnt.c, tls/tls_proxy_print.c,
+ tls/tls_proxy_scan.c, tlsmgr/tlsmgr.c, tlsproxy/tlsproxy.c,
+ trivial-rewrite/resolve.c, trivial-rewrite/rewrite.c,
+ trivial-rewrite/trivial-rewrite.c, util/attr.h.
+
+20141217
+
+ Replaced compile-time argument typechecking based on inline
+ functions with an implementation based on ternary expressions
+ with unreachable assignments to dummy variables. This
+ should produce the exact same result as the approach based
+ on inline functions (which were standardized with C99).
+ Files: util/check_arg.h, util/attr.h, util/attr.c.
+
+20141221
+
+ Portability: proof-of-concept template for OpenBSD build
+ with shared libpostfix etc. libraries. File: makedefs.
+
+20141223
+
+ Cleanup: compile-time variadic argument type checking for
+ attribute-value APIs of vstream, vstream_popen, vstring,
+ pipe_command, spawn_command, attr_override, and mail_server
+ skeletons. Based on mostly automatic conversion and checking,
+ with a manual inspection of the remainder. Files:
+ anvil/anvil.c, bounce/bounce.c, cleanup/cleanup.c,
+ cleanup/cleanup_api.c, discard/discard.c, dnsblog/dnsblog.c,
+ error/error.c, flush/flush.c, global/attr_override.c,
+ global/attr_override.h, global/mail_connect.c, global/mail_queue.c,
+ global/mail_stream.c, global/mail_stream.h, global/pipe_command.c,
+ global/pipe_command.h, global/smtp_stream.c, global/timed_ipc.c,
+ local/command.c, local/local.c, master/event_server.c,
+ master/mail_server.h, master/multi_server.c,
+ master/single_server.c, milter/milter.c, milter/milter8.c,
+ oqmgr/qmgr.c, oqmgr/qmgr_transport.c, pickup/pickup.c,
+ pipe/pipe.c, postalias/postalias.c, postcat/postcat.c,
+ postdrop/postdrop.c, postmap/postmap.c, postscreen/postscreen.c,
+ postscreen/postscreen_dnsbl.c, postscreen/postscreen_haproxy.c,
+ postscreen/postscreen_starttls.c, posttls-finger/posttls-finger.c,
+ proxymap/proxymap.c, qmgr/qmgr.c, qmgr/qmgr_transport.c,
+ qmqpd/qmqpd.c, scache/scache.c, showq/showq.c, smtp/smtp.c,
+ smtpd/smtpd.c, smtpd/smtpd_check.c, smtpd/smtpd_proxy.c,
+ smtpstone/smtp-source.c, spawn/spawn.c, tls/tls_proxy_clnt.c,
+ tls/tls_stream.c, tlsmgr/tlsmgr.c, tlsproxy/tlsproxy.c,
+ trivial-rewrite/trivial-rewrite.c, util/auto_clnt.c,
+ util/ctable.c, util/dict_cache.c, util/dict_cache.h,
+ util/dict_lmdb.c, util/dict_tcp.c, util/netstring.c,
+ util/recv_pass_attr.c, util/slmdb.c, util/slmdb.h,
+ util/spawn_command.c, util/spawn_command.h, util/vstream.c,
+ util/vstream.h, util/vstream_popen.c, util/vstream_tweak.c,
+ util/vstring.c, util/vstring.h, verify/verify.c,
+ virtual/virtual.c, xsasl/xsasl_dovecot_server.c.
+
+20141224
+
+ Cleanup: the compile-time argument typechecks for attribute-value
+ APIs are now by default implemented with inline functions.
+ Compile with -DNO_INLINE to implement the argument typechecks
+ with ternary operators and unreachable assignments. Files:
+ util/check_arg.h and its consumers.
+
+20141226
+
+ NetBSD6/7 dynamic linking support. Viktor Dukhovni.
+
+ Cleanup: instead of making up new names, use a consistent
+ CA_ prefix for macros that implement compile-time argument
+ typechecks for non-protocol attribute-value APIs. This
+ transformation and its verification are mechanical.
+
+ Bugfix (introduced: Postfix 1.1, but latent before 3.0):
+ "postfix-install: daemon_directory: not found" error with
+ an ancient Solaris shell. Fixed by ALSO resetting IFS after
+ the end of a ``while IFS=foo command'' loop; counter to
+ expectation, the IFS reset in the loop body executed in a
+ child process. Background: some shells implement "IFS=foo
+ command" as a permanent IFS change; this was allowed by
+ standards at some point in time. File: postfix-install.
+
+20141227
+
+ Feature: smtp_address_verify_target (default: rcpt) that
+ determines what protocol stage decides if a recipient is
+ valid. Specify "data" for servers that reject recipients
+ after the DATA command. Files: mantools/postlink,
+ proto/postconf.proto, proto/ADDRESS_VERIFICATION_README.html,
+ global/mail_params.h, smtp/lmtp_params.c, smtp/smtp.c,
+ smtp/smtp.h, smtp/smtp_params.c, smtp/smtp_proto.c.
+
+20141228
+
+ Cleanup: the IDNA conversion routines now accept both ASCII
+ and UTF8 inputs. The functions als verify that either their
+ result is a valid ASCII domain name or that it converts
+ into a valid ASCII domain name. Files: util/midna.c,
+ util/midna_test.in, util/midna_test.ref.
+
+20141230
+
+ Cleanup: s/midna/midna_domain/ for better specificity,
+ because we also need functions that act only on the domain
+ portion of an email address. Files: bounce/bounce_template.c,
+ global/midna_adomain.c, posttls-finger/posttls-finger.c,
+ smtp/smtp_addr.c, smtpd/smtpd_check.c, tls/tls_client.c,
+ util/midna_domain.[hc], util/valid_utf8_hostname.c.
+
+ Infrastructure: function midna_adomain_to_utf8() (and
+ midna_adomain_to_ascii) to convert the domain portion of
+ an email address before table lookup. Files:
+ global/midna_adomain.[hc].
+
+20141230-20140109
+
+ What is described here is the result of four iterations to
+ deal with malformed UTF-8 without massively contaminating
+ every Postfix program with new error-handling code paths,
+ in particular without triggering fatal errors that didn't
+ happen before.
+
+ Infrastructure: function casefold() to support caseless
+ string comparison, primarily for table lookups. This function
+ supports two modes: case folding a la lowercase() for ASCII
+ byte values, and UTF-8 case folding. As recommended at
+ http://www.w3.org/International/wiki/Case_folding for
+ caseless string comparison, this uses the en_US locale to
+ avoid surprises. The implementatin handles the entire RFC
+ 3629 Unicode range (code points U+0000..U+10FFFF including
+ surrogates) and is chroot(2) safe. Files: casefold.c,
+ stringops.h.
+
+ Infrastructure: revised the midna_domain_to_ascii and
+ midna_domain_to_utf8 domain name conversion functions after
+ careful reading of the UTS #46 specification, and after
+ observing that ICU 4.8 library functions indeed implement
+ this spec, at least with default options. In particular,
+ midna_domain_to_utf8 takes an UTF-8 domain name and verifies
+ that its A-label form will pass the valid_hostname() test.
+ File: util/midna_domain.c.
+
+ Infrastructure: handle UTF-8 errors in lookup table keys
+ or values without massively contaminating every Postfix
+ program with new error-handling code paths, in particular
+ without triggering fatal errors that didn't happen before.
+ The lookup/update/delete functions log a warning and ignore
+ a request with a bad key (it cannot exist); the update
+ functions ignore a request to store a bad value (it cannot
+ exist); and the lookup function reports a bad value as a
+ configuration error (it should not exist, but there it is).
+ Table iterators still report all (key, value) pairs in a
+ table. Files: util/dict.h, util/dict_open.c, util/dict_utf8.c,
+ global/mkmap_open.c.
+
+ Note that with SMTPUTF8 turned on, each table-driven mechanism
+ (access, aliases, etc.) needs to make its own decision
+ whether UTF-8 syntax is required. We cannot blindly require
+ that everything has valid UTF-8 syntax. That would make
+ header/body_checks useless for content inspection, because
+ headers may be malformed and bodies may contain legitimate
+ binary content that isn't UTF-8.
+
+ Note that with SMTPUTF8 turned off, Postfix must remain
+ 8-bit clean as it always has been. Table operations must
+ not complain that something violates UTF-8 syntax rules.
+
+ UTF-8 sanitization in the Postfix SMTP server. With
+ smtputf8_enable=yes, SMTP commands with UTF-8 syntax errors
+ are rejected, table lookup results with invalid UTF-8 syntax
+ are handled as configuration errors, and UTF-8 syntax errors
+ in policy server replies result in execution of the policy
+ server's default action.
+
+20150102
+
+ Cleanup: propagate DICT_ERR_CONFIG through the proxymap
+ protocol. Files: global/dict_proxy.[hc], proxymap/proxymap.c.
+
+20150106
+
+ Robustness: don't segfault due to excessive recursion in
+ tok822_free_tree() after a faulty configuration runs into
+ the virtual_alias_recursion_limit. File: global/tok822_tree.c.
+
+20150109
+
+ Cleanup: the dict debug module now proxies dict flags.
+ File: util/dict_debug.c.
+
+ With "smtputf8_enable = yes", the postmap and postalias
+ commands now enable UTF-8 by default (use "-u" to disable)
+ with one exception: UTF-8 remains disabled for header/body_checks
+ emulation (use "-U" to enable). Files: postmap/postmap.c,
+ postalias/postalias.c.
+
+20150110
+
+ Cleanup: the "inline" and "texthash" implementations now
+ reuse the "internal" database instead of reinventing the
+ wheel. Files: util/dict_inline.c, util/dict_thash.c.
+
+ As a first step, with "smtputf8_enable = yes" all features
+ based on Postfix matchlists enable UTF-8 syntax checks and
+ UTF-8 casefolding for table patterns, but NOT YET for string
+ patterns. The list of features includes authorized_flush_users,
+ authorized_mailq_users, authorized_submit_users, debug_peer_list,
+ fast_flush_domains, mydestination, permit_mx_backup_networks,
+ qmqpd_authorized_clients, smtp_connection_cache_destinations,
+ smtpd_authorized_verp_clients, smtpd_authorized_xclient_hosts,
+ smtpd_authorized_xforward_hosts,
+ smtpd_client_event_limit_exceptions,
+ smtpd_log_access_permit_actions, smtpd_sasl_exceptions_networks,
+ the "domains" feature in ldap_table(5), memcache_table(5)
+ mysql_table(5), pgsql_table(5) and sqlite_table(5),
+ virtual_alias_domains, virtual_mailbox_domains.
+
+20150111
+
+ Cleanup: simplified the interposition layer that adds UTF-8
+ support to Postfix lookup tables. Files: util/dict_utf8.c.
+
+ With "smtputf8_enable = yes", Enable UTF-8 syntax checks
+ and UTF-8 casefolding for SMTP server access maps, alias_maps,
+ canonical_maps, fallback_transport_maps,
+ lmtp_tls_session_cache_database, local_recipient_maps,
+ mailbox_command_maps, mailbox_transport_maps, rbl_reply_maps,
+ recipient_bcc_maps, recipient_canonical_maps, relay_recipient_maps,
+ relocated_maps, sender_bcc_maps, sender_canonical_maps,
+ sender_dependent_relayhost_maps, sender_dependent_transport_maps,
+ smtp_generic_maps, smtp_sasl_auth_cache_name,
+ smtp_sasl_password_maps, smtp_tls_per_site, smtp_tls_policy_maps,
+ smtp_tls_session_cache_database, smtpd_sender_login_maps,
+ smtpd_tls_session_cache_database, transport_maps,
+ virtual_alias_maps, virtual_gid_maps, virtual_mailbox_maps,
+ virtual_uid_maps.
+
+20150112
+
+ Infrastructure: support for UTF-8 casefolding in match_lists.
+ Instead of using strcasecmp(), casefold all fixed-string
+ patterns during initialization, casefold a search string
+ at the beginning of the search, and use strcmp() for
+ comparison. Files: util/casefold.c util/dict.h, util/dict_utf8.c,
+ util/match_list.c, util/match_list.h, util/match_ops.c,
+ util/stringops.h, global/addr_match_list.c, global/domain_list.c,
+ global/namadr_list.c, global/string_list.c.
+
+20150113
+
+ Cleanup: show the configuration parameter name in error
+ messages while parsing or searching match_list-based features
+ such as mydestination, relay_domains and a few dozen more.
+ Files: cleanup/cleanup_init.c, flush/flush.c,
+ global/addr_match_list.c, global/debug_peer.c,
+ global/domain_list.c, global/flush_clnt.c,
+ global/match_parent_style.c, global/namadr_list.c,
+ global/resolve_local.c, global/string_list.c, global/user_acl.[hc],
+ postdrop/postdrop.c, postqueue/postqueue.c,
+ postscreen/postscreen.c, qmqpd/qmqpd.c, sendmail/sendmail.c.,
+ smtp/smtp.c, smtp/smtp_sasl_glue.c, smtpd/smtpd.c,
+ smtpd/smtpd_check.c, trivial-rewrite/resolve.c,
+ util/match_list.[hc], util/match_ops.c.
+
+ Cleanup: apply printable() to all bounce(8) service
+ string-valued protocol fields. File: bounce/bounce.c.
+
+ Apparenly the UCI 4.8 ucasemap_utf8FoldCase() function does
+ not complain about UTF-8 syntax errors, so we add our own
+ redundant check. File: util/casefold.c.
+
+20150115
+
+ Bitrot: prepare for future changes in OpenSSL. Viktor
+ Dukhovni. Files: tls/tls.h, tls/tls_dh.c, tls/tls_misc.c,
+ tls/tls_rsa.c, tls/tls_server.c.
+
+ Documentation: "avoid hash files here, use btree or lmdb
+ instead". File: proto/ADDRESS_VERIFICATION_README.html.
+
+ Safety: virtual_alias_address_length_limit (default: 1000)
+ to stop aliasing loops that exponentially increase the
+ address length with each iteration. Files: global/mail_params.h,
+ mantools/postlink, proto/postconf.proto, cleanup/cleanup.c,
+ cleanup/cleanup_init.c, cleanup/cleanup_map1n.c.
+
+20150116
+
+ TLS wrappermode in the Postfix smtp(8) client. This introduces
+ a new parameter "smtp_tls_wrappermode" (default: no). Files:
+ global/mail_params.h, mantools/postlink, proto/postconf.proto,
+ smtp/lmtp_params.c, smtp/smtp.[hc], smtp/smtp_connect.c,
+ smtp/smtp_params.c, smtp/smtp_proto.c.
+
+ TLS wrappermode in posttls-finger(1), and some DANE-related
+ cleanups. This introduces a new option "-w". Viktor Dukhovni.
+ Files: posttls-finger/posttls-finger.c, smtp/smtp_tls_policy.c,
+ tls/tls.h, tls/tls_client.c, tls/tls_fprint.c.
+
+20150117
+
+ Cleanup: missing " in \%s\" in postscreen(8) fatal error
+ messages. Iain Hibbert. File: postconf/postconf_master.c.
+
+20150118
+
+ Bugfix (introduced: 20140731): when a connection timed out
+ before any command was received, the Postfix SMTP server
+ "disconnect from" logging would show the content of the
+ last SMTP server response (421 4.4.2 $myhostname error:
+ timeout exceeded) instead of per-command statistics, because
+ there were no statistics to report. The Postfix SMTP server
+ now always logs the total number of commands (commands=x/y)
+ even when the client did not send any. This helps logfile
+ analyzers to recognize sessions without commands. File:
+ smtpd/smtpd.c.
+
+20150120
+
+ Bugfix (introduced: 20141230-20140109): do not reallocate
+ a dictionary handle after it is initialized. This breaks
+ CDB. Problem reported by Andreas Schulze. Files: util/dict.h,
+ util/dict_alloc.c, util/dict_utf8.c.
+
+ Cleanup: simplified the dict_utf8 wrapper implementation.
+ Files: util/dict.h, util/dict_alloc.c, util/dict_utf8.c.
+
+20150121
+
+ Cleanup: undo changes in check_mumble_access() that replaced
+ error handling with longjmp() calls. This could introduce
+ memory leaks in check_mumble_access() callers. Files:
+ smtpd/smtpd_check.c, smtpd/smtpd_error.ref.
+
+20150122
+
+ Cleanup: miscellaneous cruft, typos, comments, error messages.
+ proto/COMPATIBILITY_README.html, global/addr_match_list.c,
+ global/domain_list.c, global/namadr_list.c, global/string_list.c,
+ global/user_acl.c, postalias/postalias.c, postmap/postmap.c,
+ tls/tls_client.c, util/dict_alloc.c, util/dict_open.c,
+ util/match_list.c.
+
+20150124
+
+ Workaround: nroff has been improved so that "-" comes out as
+ some non-ASCII character, unlike HTML where it comes out
+ as itself. Andreas Schulze. This requires jumping a few
+ hops to generate HTML and nroff input from the same source
+ text. Files; mantools/srctoman, mantools/postconf2man.
+
+ Cleanup: UTF-8 support in masquerade_domains. File:
+ cleanup/cleanup_masquerade.c.
+
+20150125
+
+ Cleanup: simplified the casefold() API: no input-dependent
+ failure modes. Files: cleanup/cleanup_masquerade.c,
+ util/casefold.c, util/dict_utf8.c, util/match_list.c,
+ util/strcasecmp_utf8.c, util/stringops.h.
+
+ Cleanup: replaced str*casecmp() calls with UTF8-enabled
+ versions. Files: bounce/bounce.c, bounce/bounce_append_service.c,
+ bounce/bounce_notify_service.c, bounce/bounce_notify_verp.c,
+ bounce/bounce_one_service.c, bounce/bounce_trace_service.c,
+ bounce/bounce_warn_service.c, cleanup/cleanup_addr.c,
+ cleanup/cleanup_map11.c, cleanup/cleanup_map1n.c,
+ global/log_adhoc.c, global/mail_addr_find.c, global/mail_params.c,
+ global/split_addr.c, global/verify.c, global/verify_sender_addr.c,
+ local/alias.c, local/recipient.c, oqmgr/qmgr_message.c,
+ qmgr/qmgr_message.c, smtp/smtp_tls_policy.c, smtpd/smtpd_check.c,
+ smtpd/smtpd_milter.c, trivial-rewrite/resolve.c,
+ util/strcasecmp_utf8.c, util/stringops.h.
+
+20150126
+
+ Portability: added missing #ifdef STRCASECMP_IN_STRINGS_H
+ for platforms that require it. Files: dns/dns_rr_filter.c,
+ milter/milter8.c, posttls-finger/posttls-finger.c,
+ tls/tls_dane.c, tlsproxy/tlsproxy.c, util/dict_test.c.
+
+ Cleanup: replaced lowercase() calls with UTF-8-enabled
+ versions. Files: flush/flush.c, global/been_here.c,
+ global/delivered_hdr.c, global/fold_addr.c, global/fold_addr.h,
+ local/forward.c, local/recipient.c, pipe/pipe.c,
+ smtpd/smtpd_resolve.c, util/casefold.c, util/stringops.h,
+ virtual/recipient.c.
+
+20150127
+
+ Cleanup: simplified the 20150125 and 20150126 APIs, replacing
+ the most-common use cases with convenience macros that have
+ fewer arguments. Files: anything that implements or invokes
+ casefold*() or str*casecmp().
+
+ Documentation: missing words and typos. Matthew Selsky. Files:
+ proto/SMTPUTF8_README.html, util/dict_open.c, util/vstream.c.
+
+20150128
+
+ Bugfix: the ICU casemapping API can report success, while
+ producing output that is not null-terminated. But we can
+ deal with that. File: util/casefold.c.
+
+ Cleanup: unnecessary buffers. File: util/strcasecmp_utf8.c.
+
+ Cleanup: whitespace in source-code documentation has gotten
+ damaged through the years. Files: util/iostuff.h,
+ util/msg_vstream.h, util/msg_syslog.h, util/msg_output.h,
+ util/msg.h, util/inet_proto.c, trivial-rewrite/trivial-rewrite.c,
+ tls/tls.h, postconf/postconf.c, master/multi_server.c,
+ master/event_server.c, global/memcache_proto.h,
+ global/dict_mysql.c, global/dict_ldap.c, discard/discard.c,
+ error/error.c, global/dict_proxy.c, global/mail_conf_int.c,
+ global/match_parent_style.c, global/scache.c, global/scache.h,
+ qmgr/qmgr_entry.c, qmgr/qmgr_peer.c, smtp/smtp_rcpt.c,
+ smtpd/smtpd_peer.c, tls/tls_mgr.c, util/attr_scan0.c,
+ util/dict_tcp.c, util/hex_code.c, util/valid_hostname.c.
+
+ Cleanup: typos. Files: proto/socketmap_table, proto/mysql_table,
+ global/dict_mysql.c, proto/lmdb_table, smtpstone/smtp-sink.c,
+ posttls-finger/posttls-finger.c.
+
+ Bugfix: restart the Postfix SMTP server SASL client after
+ XCLIENT may have changed the client IP address. Matthew
+ Via. File: smtpd/smtpd.c.
+
+20150129
+
+ More whitespace in source-code comment regressions. Viktor
+ (mostly) and Wietse. smtpd/smtpd_proxy.c, util/format_tv.c,
+ util/line_wrap.c, util/slmdb.c, qmgr/qmgr_peer.c,
+ smtp/smtp_rcpt.c, smtpd/smtpd_peer.c, tls/tls_mgr.c,
+ trivial-rewrite/trivial-rewrite.c, util/attr_scan0.c,
+ util/dict_tcp.c, util/hex_code.c, util/valid_hostname.c,
+ discard/discard.c, error/error.c, global/dict_proxy.c,
+ global/mail_conf_int.c, global/match_parent_style.c,
+ global/scache.c, qmgr/qmgr_entry.c, global/dict_ldap.c,
+ global/dict_mysql.c, posttls-finger/posttls-finger.c,
+ smtp/smtp.c, tls/tls_certkey.c.
+
+ Cleanup: avoid hidden buffer allocation in casefold().
+ Files: local/forward.c, local/recipient.c, virtual/recipient.c.
+
+ Cleanup: HTML validator errors. Files: proto/postconf.proto,
+ proto/TLS_README.html, proto/MILTER_README.html.
+
+ Great rename from 2.12 to 3.0. Lots of files, 99% mechanical.
+
+ Cleanup: HTML entities in *roff manpage source. File:
+ mantools/fixman, proto/postconf.proto, smtpd/smtpd.c,
+ trivial-rewrite/trivial-rewrite.c.
+
+20150201
+
+ Usability: in error messages, print the CAfile and CApath
+ value in double quotes, to clue in people who specify quoted
+ pathnames in main.cf. Viktor Dukhovni. Files: tls/tls_certkey.c
+ and testing code in posttls-finger/posttls-finger.c.
+
+20150202
+
+ Cleanup: make posttls-finger -k/-K documentation consistent
+ with behavior. File: posttls-finger/posttls-finger.c.
+
+20150203
+
+ Cleanup: API minimization, by making some functions static.
+ Files: util/dict.h, util/dict_utf8.c.
+
+20150205
+
+ Preliminary feature: support for building position-independent
+ executables (PIE), tested on Fedora Core 20, Ubuntu 14.04,
+ FreeBSD 9 and 10, and NetBSD 6. See INSTALL section 4.3 for
+ details and limitations. Files: makedefs, proto/INSTALL.html,
+ RELEASE_NOTES-3.0.
+
+20150208
+
+ Cleanup: after many years, the access(5) map BCC action is
+ part of the stable release. Files: smtpd/smtpd_check.c,
+ proto/acces.
+
+20150210
+
+ Cleanup: socketmap documentation. File: proto/socketmap_table.
+
+20150211
+
+ Cleanup: strncasecmp_utf8() streamlining. Files: util/stringops.h,
+ util/allascii.c, util/strcasecmp_utf8.c.
+
+20150212
+
+ Cleanup: in code after reading main.cf, removed bogus guard
+ before re-evaluating the mail_task() syslog prefix. File:
+ postlog/postlog.c.
+
+20150214
+
+ Bugfix (introduced: Postfix 3.0): missing #ifdef USE_TLS
+ inside #ifdef USE_SASL_AUTH broke the build. Viktor Dukhovni.
+ File: smtpd/smtpd.c.
+
+ Cleanup: missing errno logging in bounce daemon clients.
+ This made troubleshooting significantly more difficult.
+ File: global/mail_command_client.c.
+
+20150216
+
+ Cleanup: documented that mail_connect() produces no errno
+ logging. The functions that call it should log the error
+ (and the majority does). File: global/mail_connect.c.
+
+ Cleanup: added errno logging after mail_connect() failure.
+ Files: global/post_mail.c, local/forward.c.
+
+ Cleanup: in code after reading main.cf, removed bogus guard
+ before re-evaluating the mail_task() syslog prefix. Files:
+ postalias/postalias.c, postdrop/postdrop.c, postmap/postmap.c,
+ postqueue/postqueue.c, postsuper/postsuper.c, sendmail/sendmail.c.
+
+20150218
+
+ Documentation: header/body_checks additional text about whether
+ an action stops further inspection of the input stream. File:
+ proto/header_checks.
+
+ Robustness: reject installation pathnames with whitespace.
+ File: postfix-install.
+
+20150217
+
+ Cleanup: missing include. File: util/allascii.c.
+
+20150221
+
+ Bugfix (introduced: Postfix 3.0): don't append '.' to the
+ DNS resource record value, when converting TXT records to
+ the string form that is used used by xxx_dns_reply_filter.
+ File: dns/dns_strrecord.c.
+
+20150313
+
+ Documentation: incorrect Postfix version number for
+ postscreen_dnsbl_timeout. Quanah Gibson-Mount. File:
+ postscreen/postscreen.c.
+
+20150320
+
+ Cleanup: better sorting order for the default tls_*_cipherlist
+ settings. OpenSSL does not order "ALL" quite right: some
+ MEDIUM ciphers (SEED and IDEA) sneak up above some 128-bit
+ HIGH ciphers. Also previously, when we prefer "aNULL" we
+ moved MEDIUM with aNULL above same bit-length HIGH but not
+ aNULL. Viktor Dukhovni. File: global/mail_params.h.
+
+20150324
+
+ Bugfix (introduced: Postfix 2.6): sender_dependent_relayhost_maps
+ ignored the relayhost setting in the case of a DUNNO lookup
+ result. It would use the recipient domain instead. Viktor
+ Dukhovni. Wietse took the pieces of code that enforce the
+ precedence of a sender-dependent relayhost, the global
+ relayhost, and the recipient domain, and put that code
+ together in once place so that it is easier to maintain.
+ File: trivial-rewrite/resolve.c.
+
+20150326
+
+ Feature: lmtp_fallback_relay, limited to TCP destinations
+ only. Viktor Dukhovni. Wietse updated the postlink, smtp.c,
+ and smtp-only files, and added a warning when lmtp_fallback_relay
+ is specified for a non-TCP destination. Files: mantools/postlink,
+ smtp/smtp.c, smtp/smtp-only, smtp/smtp_connect.c,
+ smtp/smtp_params.c, global/mail_params.h, proto/postconf.proto.
+
+20150328
+
+ Bugfix (introduced: Postfix 1.1.0): post-install expanded
+ macros in parameter values when trying to detect parameter
+ overrides, causing unnecessary main.cf updates during Postfix
+ start-up. Julian Reich, Viktor Dukhovni, and Wietse. File:
+ conf/post-install.
+
+20150330
+
+ Bitrot: prepare for future changes in OpenSSL API. Viktor
+ Dukhovni. File: tls_dane.c.
+
+ Safety: instead of bouncing mail, report a soft error when
+ SASL infrastucture breaks. Viktor Dukhovni, Emmanuel Fuste.
+ Files: smtpd/smtpd_sasl_glue.c, xsasl/xsasl.h,
+ xsasl/xsasl_cyrus_server.c, xsasl/xsasl_dovecot_server.c.
+
+20150401
+
+ Documentation: update the mydestination default value in
+ the stock main.cf file. File: conf/main.cf.
+
+20150404
+
+ Documentation: add "postconf -m" output to problem reports. File:
+ proto/DEBUG_README.html.
+
+20150418
+
+ Portability: use the icu-config utility to locate the ICU
+ include and library files. With this, Postfix builds out
+ of the box on MacOS X. File: makedefs.
+
+20150421
+
+ Bugfix (introduced: 19970309): reset errno before calling
+ readdir(), in order to distinguish between end-of-directory and
+ an error condition. File: scandir.c.
+
+20150426
+
+ Cleanup: when transmitting an attribute-value sequence
+ between Postfix processes, a hash table may now appear at
+ any position instead of only at the end. Files:
+ util/attr_scan{0,64,plain}.c, util/attr_print{0,64,plain}.c,
+ util/attr_scan{0,64,plain}.ref.
+
+ Feature: milter_macro_defaults, an optional list of macro
+ name=value pairs that specify default values for Milter
+ macros. When a macro is to be sent to a Milter application,
+ Postfix will send its default value when no value is available
+ from the mail delivery context. For example, with
+ "milter_macro_defaults = auth_type=TLS", Postfix will send
+ an auth_type of "TLS" unless a remote client authenticates
+ with SASL. Files: mantools/postlink, proto/MILTER_README.html,
+ proto/postconf.proto, cleanup/cleanup.c, cleanup/cleanup_init.c,
+ cleanup/cleanup_milter.c, global/mail_params.h, milter/milter.c,
+ milter/milter.h, smtpd/smtpd.c, smtpd/smtpd_milter.c.
+
+20150501
+
+ Support for Linux 4.*, and some simplification for future
+ makedefs files. Files: makedefs, util/sys_defs.h.
+
+20150502
+
+ Cleanup: updated the examples in MILTER_README. File:
+ proto/MILTER_README.html
+
+20150529
+
+ Support for DNS reply TTL values in dnsblog and postscreen.
+ Files: dnsblog/dnsblog.c, postscreen/postscreen_early.c,
+ postscreen/postscreen_dnsbl.c.
+
+20150607
+
+ Support for DNS reply TTL values for "not found" responses
+ (negative reply caching). The postscreen daemon needs this to
+ accurately whitelist an SMTP client that is not found on any
+ DNSBL. Files: dns/dns_lookup.c, dns/dns_strrecord.c, dns/dns.h,
+ dns/test_dns_lookup.c.
+
+20150615
+
+ Two new parameters to limit how long a DNSBL or DNSWL lookup
+ result remains valid: postscreen_dnsbl_max_ttl is an upper
+ limit for the TTL from a DNS query, and postscreen_dnsbl_min_ttl
+ is a lower limit. The old postscreen_dnsbl_ttl provides a
+ backwards-compatible default for postscreen_dnsbl_max_ttl.
+ Files: global/mail_params.h, postscreen/postscreen.c,
+ postscreen/postscreen_early.c, mantools/postlink,
+ proto/postconf.proto.
+
+20150616
+
+ Refinement: the postscreen daemon now computes two combined
+ DNS reply TTLs: one combined TTL for replies that the client
+ should be blocked, and one combined TTL for replies that the
+ client should be allowed. This is more conservative than
+ simply combining all reply TTLs into one number. File:
+ postscreen/postscreen_dnsbl.c.
+
+20150621
+
+ Feature: default_transport_rate_delay (and the transport-specific
+ *transport*_transport_rate_delay) to enforce a destination-
+ independent rate limit on deliveries. Files: mantools/postlink,
+ proto/postconf.proto, *qmgr/qmgr.h, *qmgr/qmgr_transport.c,
+ *qmgr/qmgr_deliver.c, *qmgr/qmgr.c.
+
+20150707
+
+ Workaround: some DNS servers reply with NXDOMAIN for type
+ NS queries with names that actually have an A record. This
+ broke check_mumble_ns_access. File: smtpd/smtpd_check.c.
+
+20150711
+
+ Workaround: conditional time default value can result in
+ multiple time unit suffixes. Files: global/conv_time.c
+ global/mail_conf_time.c.
+
+20150712
+
+ Cleanup: configurable workaround (dns_ncache_ttl_fix_enable)
+ in case some future libc change breaks a promise made by
+ current resolver(3) documentation. Files: global/mail_params.[hc].
+
+ Cleanup: removed unused libdns dependencies. No-one remembers
+ why they were introduced. Files: postscreen/Makefile.in,
+ qmqpd/Makefile.in, smtpd/Makefile.in, tlsmgr/Makefile.in.
+
+ Cleanup: code indentation. Viktor Dukhovni. File:
+ smtp/smtp_addr.c.
+
+ Workaround: With Solaris10, write_wait() hangs in poll()
+ until timeout, when invoked after peekfd() has received an
+ ECONNRESET error indication. This happens when a client
+ sends QUIT and closes the connection immediately. File:
+ util/peekfd.c.
+
+20150715
+
+ Security: updated default Diffie-Hellman export (512 bit)
+ primes and non-export (from 1024 to 2048 bit) primes, and
+ updated text on non-export DH primes. Viktor Dukhovni.
+ Files: tls/tls_dh.c, proto/FORWARD_SECRECY_README.html.
+
+20150718
+
+ Security: opportunistic TLS by default uses "medium" or
+ stronger ciphers instead of "export" or stronger. See the
+ RELEASE_NOTES file for how to get the old settings back.
+ Files: global/mail_params.h, proto/TLS_README.html,
+ proto/postconf.proto, and files derived from those.
+
+20150719
+
+ Security: Postfix TLS support by default no longer uses
+ SSLv2 or SSLv3. See the RELEASE_NOTES file for how to get
+ the old settings back. Files: global/mail_params.h,
+ proto/postconf.proto, and files derived from those.
+
+20150722
+
+ Cleanup: the COMPATIBILITY_README* files were not installed.
+ File: conf/postfix-files.
+
+20150726
+
+ Cleanup: some lost edits for the SASL_README file. File:
+ proto/SASL_README.html.
+
+20150816
+
+ Workaround: updated the 20150707 fix for DNS servers that
+ reply with NXDOMAIN for type NS queries instead of (NOERROR,
+ zero answers). File: smtpd/smtpd_check.c.
+
+20150829
+
+ Documentation: TLS session tickets are preferred over the
+ local server-side smtpd_tls_session_cache_database storage.
+ TLS session tickets are supported as of OpenSSL 0.9.8h (May
+ 2008). Files: mantools/postlink, proto/TLS_README.html,
+ proto/postconf.proto.
+
+20150831
+
+ Cleanup: obsolete comments in Makefile.init.
+
+20150903
+
+ Workaround: disable DNSSEC support for AIX 7x and earlier.
+ The AIX 6/7 resolver(5) API defines RES_USE_DNSSEC without
+ defining the "ad" bit. Viktor Dukhovni. Files: makedefs,
+ proto/INSTALL.html, dns/dns.h.
+
+20150912
+
+ Future-proofing and code cleanup: exploit GCC and Clang
+ "warn_unused_result" feature to flag missing error checks.
+ Files: util/sys_defs.h, util/attr.h, util/edit_file.h,
+ util/listen.h, util/lstat_as.h, util/mac_expand.h,
+ util/mac_parse.h, util/myaddrinfo.h, util/myflock.h,
+ util/sane_fsops.h, util/sane_socketpair.h, util/stat_as.h,
+ util/base32_code.h, util/base64_code.h, util/hex_code.h,
+ util/timed_wait.h, util/vstream.h, src/util/vstring_vstream.h.
+
+ Cleanup: incomplete error check. Found with WARN_UNUSED_RESULT
+ check. File: util/recv_pass_attr.c.
+
+ Future-proofing: added type mis-match detection for
+ ATTR_TYPE_FUNC function-pointer arguments. File: util/attr.h.
+
+ Cleanup: don't ignore seek-to-end-of-file errors. File:
+ global/record.c.
+
+ Cleanup: use vstream_fpurge() to purge VSTREAM buffers,
+ instead of calling vstream_fseek() and ignoring ESPIPE
+ errors. File: smtpstone/qmqp-sink.c.
+
+20150913
+
+ Feature: SMTPD policy service "policy_context" attribute
+ and smtpd_policy_service_policy_context main.cf parameter.
+ Originally, to share the same SMTPD policy service endpoint
+ among multiple check_policy_service clients. Markus Benning.
+ Files: mantools/postlink, proto/SMTPD_POLICY_README.html,
+ proto/postconf.proto, global/mail_params.h, global/mail_proto.h,
+ smtpd/smtpd.c, smtpd/smtpd_check.c.
+
+20150923
+
+ Bugfix (introduced: 20120531-617): the Postfix SMTP server
+ used a larger-than-1 VSTREAM buffer to read the HAProxy
+ connection hand-off information. This broke TLS wrappermode,
+ as the TLS helo packet would end up in the plaintext VSTREAM
+ buffer. Reported by Lukas Erlacher. File: smtpd/smtpd_haproxy.c.
+
+20150924
+
+ Cleanup (introduced: 20060510, exposed 20150912): eliminated
+ a harmless warning message "seek error after reading END
+ record: Illegal seek" from the cleanup server after a
+ check_sender_access DISCARD action. File: cleanup/cleanup.c.
+
+ Bugfix (introduced: 20090216-24): incorrect postmulti error
+ message. Reported by Patrik Koetter. Fix by Viktor Dukhovni.
+ File: postmulti/postmulti.c.
+
+ Workaround: don't create a new instance when the template
+ main.cf and master.cf files are missing, as happens on
+ Debian-like systems. Viktor Dukhovni. File: conf/postmulti-script.
+
+20150930
+
+ Bugfix (introduced: 20040124): Milter client panic while
+ adding a header, because the PREPEND action used the same
+ output function for header_checks and body_checks. Viktor
+ Dukhovni and Wietse. File: cleanup/cleanup_message.c.
+
+ Bugfix (introduced: 20031128): xtext_unquote() did not
+ propagate error reports from xtext_unquote_append(), causing
+ the decoder to return partial output, instead of rejecting
+ malformed input. Fix by Krzysztof Wojta. File: global/xtext.c.
+
+20151003
+
+ Bugfix (copied from xtext): uxtext_unquote() did not propagate
+ error reports from uxtext_unquote_append(), causing the
+ decoder to return partial output, instead of rejecting
+ malformed input. Found by searching the code for similar
+ error patterns as with xtext_unquote(). File: global/uxtext.c.
+
+ Cleanup: added missing "negative" unit tests. Files:
+ global/xtext.c, global/uxtext.c.
+
+20151004
+
+ Future proofing: use a real VSTRING in the 20150930 header
+ PREPEND fix. File: cleanup/cleanup_message.c.
+
+ Future proofing: make vstring_import() consistent with
+ vstring_alloc(). The alternative would be to remove the
+ function as it is unused and exists only for symmetry with
+ vstring_export(). File: usr/vstring.c.
+
+20151010
+
+ Cleanup: the 20150903 workaround for AIX DNSSEC used the
+ wrong name in #ifdef. File: dns/dns.h.
+
+20151011
+
+ Cleanup: in the PCRE client, turn fatal lookup errors into
+ warnings, and skip the failing pattern as in dict_regexp.c.
+ Also, fixed the error text when running into the matcher's
+ backtracking limit. File: util/dict_pcre.c.
diff --git a/INSTALL b/INSTALL
new file mode 100644
index 0000000..a174591
--- /dev/null
+++ b/INSTALL
@@ -0,0 +1,1148 @@
+Postfix Installation From Source Code
+
+-------------------------------------------------------------------------------
+
+1 - Purpose of this document
+
+If you are using a pre-compiled version of Postfix, you should start with
+BASIC_CONFIGURATION_README and the general documentation referenced by it.
+INSTALL is only a bootstrap document to get Postfix up and running from scratch
+with the minimal number of steps; it should not be considered part of the
+general documentation.
+
+This document describes how to build, install and configure a Postfix system so
+that it can do one of the following:
+
+ * Send mail only, without changing an existing Sendmail installation.
+ * Send and receive mail via a virtual host interface, still without any
+ change to an existing Sendmail installation.
+ * Run Postfix instead of Sendmail.
+
+Topics covered in this document:
+
+ 1. Purpose of this document
+ 2. Typographical conventions
+ 3. Documentation
+ 4. Building on a supported system
+ 5. Porting Postfix to an unsupported system
+ 6. Installing the software after successful compilation
+ 7. Configuring Postfix to send mail only
+ 8. Configuring Postfix to send and receive mail via virtual interface
+ 9. Running Postfix instead of Sendmail
+10. Mandatory configuration file edits
+11. To chroot or not to chroot
+12. Care and feeding of the Postfix system
+
+2 - Typographical conventions
+
+In the instructions below, a command written as
+
+ # command
+
+should be executed as the superuser.
+
+A command written as
+
+ $ command
+
+should be executed as an unprivileged user.
+
+3 - Documentation
+
+Documentation is available as README files (start with the file README_FILES/
+AAAREADME), as HTML web pages (point your browser to "html/index.html") and as
+UNIX-style manual pages.
+
+You should view the README files with a pager such as more(1) or less(1),
+because the files use backspace characters in order to produce bold font. To
+print a README file without backspace characters, use the col(1) command. For
+example:
+
+ $ col -bx =
+ 3.0)
+ * 4.4 - Building with Postfix dynamically-linked libraries and database
+ plugins (Postfix >= 3.0)
+ * 4.5 - Building with optional features
+ * 4.6 - Overriding built-in parameter default settings
+ * 4.7 - Overriding other compile-time features
+ * 4.8 - Support for thousands of processes
+ * 4.9 - Compiling Postfix, at last
+
+4.1 - Getting started
+
+On Solaris, the "make" command and other development utilities are in /usr/ccs/
+bin, so you MUST have /usr/ccs/bin in your command search path. If these files
+do not exist, you need to install the development packages first.
+
+If you need to build Postfix for multiple architectures from a single source-
+code tree, use the "lndir" command to build a shadow tree with symbolic links
+to the source files.
+
+If at any time in the build process you get messages like: "make: don't know
+how to ..." you should be able to recover by running the following command from
+the Postfix top-level directory:
+
+ $ make -f Makefile.init makefiles
+
+If you copied the Postfix source code after building it on another machine, it
+is a good idea to cd into the top-level directory and first do this:
+
+ $ make tidy
+
+This will get rid of any system dependencies left over from compiling the
+software elsewhere.
+
+4.2 - What compiler to use
+
+To build with GCC, or with the native compiler if people told me that is better
+for your system, just cd into the top-level Postfix directory of the source
+tree and type:
+
+ $ make
+
+To build with a non-default compiler, you need to specify the name of the
+compiler. Here are a few examples:
+
+ $ make makefiles CC=/opt/SUNWspro/bin/cc (Solaris)
+ $ make
+
+ $ make makefiles CC="/opt/ansic/bin/cc -Ae" (HP-UX)
+ $ make
+
+ $ make makefiles CC="purify cc"
+ $ make
+
+and so on. In some cases, optimization will be turned off automatically.
+
+4.3 - Building with Postfix position-independent executables (Postfix >= 3.0)
+
+On some systems Postfix can be built with Position-Independent Executables. PIE
+is used by the ASLR exploit mitigation technique (ASLR = Address-Space Layout
+Randomization):
+
+ $ make makefiles pie=yes ...other arguments...
+
+(Specify "make makefiles pie=no" to explicitly disable Postfix position-
+independent executable support).
+
+Postfix PIE support appears to work on Fedora Core 20, Ubuntu 14.04, FreeBSD 9
+and 10, and NetBSD 6 (all with the default system compilers).
+
+Whether the "pie=yes" above has any effect depends on the compiler. Some
+compilers always produce PIE executables, and some may even complain that the
+Postfix build option is redundant.
+
+4.4 - Building with Postfix dynamically-linked libraries and database plugins
+(Postfix >= 3.0)
+
+Postfix dynamically-linked library and database plugin support exists for
+recent versions of Linux, FreeBSD and MacOS X. Dynamically-linked library
+builds may become the default at some point in the future.
+
+Overview of topics:
+
+ * 4.4.1 Turning on Postfix dynamically-linked library support
+ * 4.4.2 Turning on Postfix database-plugin support
+ * 4.4.3 Customizing Postfix dynamically-linked libraries and database plugins
+ * 4.4.4 Tips for distribution maintainers
+
+Note: directories with Postfix dynamically-linked libraries or database plugins
+should contain only postfix-related files. Postfix dynamically-linked libraries
+and database plugins should not be installed in a "public" system directory
+such as /usr/lib or /usr/local/lib. Linking Postfix dynamically-linked library
+or database-plugin files into non-Postfix programs is not supported. Postfix
+dynamically-linked libraries and database plugins implement a Postfix-internal
+API that changes without maintaining compatibility.
+
+4.4.1 Turning on Postfix dynamically-linked library support
+
+Postfix can be built with Postfix dynamically-linked libraries (files typically
+named libpostfix-*.so). Postfix dynamically-linked libraries add minor run-time
+overhead and result in significantly-smaller Postfix executable files.
+
+Specify "shared=yes" on the "make makefiles" command line to build Postfix with
+dynamically-linked library support.
+
+ $ make makefiles shared=yes ...other arguments...
+ $ make
+
+(Specify "make makefiles shared=no" to explicitly disable Postfix dynamically-
+linked library support).
+
+This installs dynamically-linked libraries in $shlib_directory, typically /usr/
+lib/postfix or /usr/local/lib/postfix, with file names libpostfix-name.so,
+where the name is a source-code directory name such as "util" or "global".
+
+See section 4.4.3 "Customizing Postfix dynamically-linked libraries and
+database plugins" below for how to customize the Postfix dynamically-linked
+library location, including support to upgrade a running mail system safely.
+
+4.4.2 Turning on Postfix database-plugin support
+
+Additionally, Postfix can be built to support dynamic loading of Postfix
+database clients (database plugins) with the Debian-style dynamicmaps feature.
+Postfix 3.0 supports dynamic loading of cdb:, ldap:, lmdb:, mysql:, pcre:,
+pgsql:, sdbm:, and sqlite: database clients. Dynamic loading is useful when you
+distribute or install pre-compiled Postfix packages.
+
+Specify "dynamicmaps=yes" on the "make makefiles" command line to build Postfix
+with support to dynamically load Postfix database clients with the Debian-style
+dynamicmaps feature.
+
+ $ make makefiles dynamicmaps=yes ...other arguments...
+ $ make
+
+(Specify "make makefiles dynamicmaps=no" to explicitly disable Postfix
+database-plugin support).
+
+This implicitly enables dynamically-linked library support, installs the
+configuration file dynamicmaps.cf in $meta_directory (usually, /etc/postfix or
+/usr/local/etc/postfix), and installs database plugins in $shlib_directory (see
+above). Database plugins are named postfix-type.so where the type is a database
+type such as "cdb" or "ldap".
+
+ NOTE: The Postfix 3.0 build procedure expects that you specify database
+ library dependencies with variables named AUXLIBS_CDB, AUXLIBS_LDAP, etc.
+ With Postfix 3.0 and later, the old AUXLIBS variable still supports
+ building a statically-loaded database client, but only the new AUXLIBS_CDB
+ etc. variables support building a dynamically-loaded or statically-loaded
+ CDB etc. database client. See CDB_README, LDAP_README, etc. for details.
+
+ Failure to follow this advice will defeat the purpose of dynamic database
+ client loading. Every Postfix executable file will have database library
+ dependencies. And that was exactly what dynamic database client loading was
+ meant to avoid.
+
+See the next section for how to customize the location and version of Postfix
+database plugins and the location of the file dynamicmaps.cf.
+
+4.4.3 Customizing Postfix dynamically-linked libraries and database plugins
+
+Customizing build-time and run-time options for Postfix dynamically-linked
+libraries and database plugins
+
+The build-time environment variables SHLIB_CFLAGS, SHLIB_RPATH, and
+SHLIB_SUFFIX provide control over how Postfix libraries and plugins are
+compiled, linked, and named.
+
+ $ make makefiles SHLIB_CFLAGS=flags SHLIB_RPATH=rpath SHLIB_SUFFIX=suffix
+ ...other arguments...
+ $ make
+
+See section 4.7 "Overriding other compile-time features" below for details.
+
+Customizing the location of Postfix dynamically-linked libraries and database
+plugins
+
+As a reminder, the directories with Postfix dynamically-linked libraries or
+database plugins should contain only Postfix-related files. Linking these files
+into other programs is not supported.
+
+To override the default location of Postfix dynamically-linked libraries and
+database plugins specify, for example:
+
+ $ make makefiles shared=yes shlib_directory=/usr/local/lib/postfix ...
+
+If you intend to upgrade Postfix without stopping the mail system, then you
+should append the Postfix release version to the shlib_directory pathname, to
+eliminate the possibility that programs will link with dynamically-linked
+libraries or database plugins from the wrong Postfix version. For example:
+
+ $ make makefiles shared=yes \
+ shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+
+The command "make makefiles 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 inconsistent results with different versions of the make(1) command.
+
+You can change the shlib_directory setting after Postfix is built, with "make
+install" or "make upgrade". However, you may have to run ldconfig if you change
+shlib_directory after Postfix is built (the symptom is that Postfix programs
+fail because the run-time linker cannot find the files libpostfix-*.so). No
+ldconfig command is needed if you keep the files libpostfix-*.so in the
+compiled-in default $shlib_directory location.
+
+ # make upgrade shlib_directory=/usr/local/lib/postfix ...
+ # make install shlib_directory=/usr/local/lib/postfix ...
+
+To append the Postfix release version to the pathname if you intend to upgrade
+Postfix without stopping the mail system:
+
+ # make upgrade shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+ # make install shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+
+See also the comments above for appending MAIL_VERSION with the "make
+makefiles" command.
+
+Customizing the location of dynamicmaps.cf and other files
+
+The meta_directory parameter has the same default setting as the
+config_directory parameter, typically /etc/postfix or /usr/local/etc/postfix.
+
+You can override the default meta_directory location at compile time or after
+Postfix is built. To override the default location at compile time specify, for
+example:
+
+ % make makefiles meta_directory=/usr/libexec/postfix ...
+
+Here is a tip if you want to make a pathname dependent on the Postfix release
+version: the command "make makefiles 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 inconsistent results with different versions of the
+make(1) command.
+
+You can override the meta_directory setting after Postfix is built, with "make
+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
+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
+inconsistent results with different versions of the make(1) command.
+
+4.4.4 Tips for distribution maintainers
+
+ * The shlib_directory parameter setting also provides the default directory
+ for database plugin files with a relative pathname in the file
+ dynamicmaps.cf.
+
+ * The meta_directory parameter specifies the location of the files
+ dynamicmaps.cf, postfix-files, and some multi-instance template files. The
+ meta_directory parameter has the same default value as the config_directory
+ parameter (typically, /etc/postfix or /usr/local/etc/postfix). For
+ backwards compatibility with Postfix 2.6 .. 2.11, specify "meta_directory =
+ $daemon_directory" in main.cf before installing or upgrading Postfix, or
+ specify "meta_directory = /path/name" on the "make makefiles", "make
+ install" or "make upgrade" command line.
+
+ * The configuration file dynamicmaps.cf will automatically include files
+ under the directory dynamicmaps.cf.d, just like the configuration file
+ postfix-files will automatically include files under the directory postfix-
+ files.d. Thanks to this, you can install or deinstall a database plugin
+ package without having to edit postfix-files or dynamicmaps.cf. Instead,
+ you give that plugin its own configuration files dynamicmaps.cf.d and
+ postfix-files.d, and you add or remove those configuration files along with
+ the database plugin dynamically-linked object.
+
+ * Each configuration file under the directory dynamicmaps.cf.d must have the
+ same format as the configuration file dynamicmaps.cf. There is no
+ requirement that these configuration file *names* have a specific format.
+
+ * Each configuration file under the directory postfix-files.d must have the
+ same format as the configuration file postfix-files. There is no
+ requirement that these configuration file *names* have a specific format.
+
+4.5 - Building with optional features
+
+By default, Postfix builds as a mail system with relatively few bells and
+whistles. Support for third-party databases etc. must be configured when
+Postfix is compiled. The following documents describe how to build Postfix with
+support for optional features:
+
+ _____________________________________________________________
+ |Optional feature |Document |Availability|
+ |__________________________________|_____________|____________|
+ |Berkeley DB database |DB_README |Postfix 1.0 |
+ |__________________________________|_____________|____________|
+ |LMDB database |LMDB_README |Postfix 2.11|
+ |__________________________________|_____________|____________|
+ |LDAP database |LDAP_README |Postfix 1.0 |
+ |__________________________________|_____________|____________|
+ |MySQL database |MYSQL_README |Postfix 1.0 |
+ |__________________________________|_____________|____________|
+ |Perl compatible regular expression|PCRE_README |Postfix 1.0 |
+ |__________________________________|_____________|____________|
+ |PostgreSQL database |PGSQL_README |Postfix 2.0 |
+ |__________________________________|_____________|____________|
+ |SASL authentication |SASL_README |Postfix 1.0 |
+ |__________________________________|_____________|____________|
+ |SQLite database |SQLITE_README|Postfix 2.8 |
+ |__________________________________|_____________|____________|
+ |STARTTLS session encryption |TLS_README |Postfix 2.2 |
+ |__________________________________|_____________|____________|
+
+Note: IP version 6 support is compiled into Postfix on operating systems that
+have IPv6 support. See the IPV6_README file for details.
+
+4.6 - Overriding built-in parameter default settings
+
+4.6.1 - Postfix 3.0 and later
+
+All Postfix configuration parameters can be changed by editing a Postfix
+configuration file, except for one: the parameter that specifies the location
+of Postfix configuration files. In order to build Postfix with a configuration
+directory other than /etc/postfix, use:
+
+ $ make makefiles config_directory=/some/where ...other arguments...
+ $ make
+
+The command "make makefiles 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 inconsistent results with different versions of the
+make(1) command.
+
+Parameters whose defaults can be specified in this way are listed below. See
+the postconf(5) manpage for a description (command: "nroff -man man/man5/
+postconf.5 | less").
+
+ __________________________________________
+ |parameter name |typical default |
+ |_____________________|____________________|
+ |command_directory |/usr/sbin |
+ |_____________________|____________________|
+ |config_directory |/etc/postfix |
+ |_____________________|____________________|
+ |default_database_type|hash |
+ |_____________________|____________________|
+ |daemon_directory |/usr/libexec/postfix|
+ |_____________________|____________________|
+ |data_directory |/var/lib/postfix |
+ |_____________________|____________________|
+ |html_directory |no |
+ |_____________________|____________________|
+ |mail_spool_directory |/var/mail |
+ |_____________________|____________________|
+ |mailq_path |/usr/bin/mailq |
+ |_____________________|____________________|
+ |manpage_directory |/usr/local/man |
+ |_____________________|____________________|
+ |meta_directory |/etc/postfix |
+ |_____________________|____________________|
+ |newaliases_path |/usr/bin/newaliases |
+ |_____________________|____________________|
+ |queue_directory |/var/spool/postfix |
+ |_____________________|____________________|
+ |readme_directory |no |
+ |_____________________|____________________|
+ |sendmail_path |/usr/sbin/sendmail |
+ |_____________________|____________________|
+ |shlib_directory |/usr/lib/postfix |
+ |_____________________|____________________|
+
+4.6.2 - All Postfix versions
+
+All Postfix configuration parameters can be changed by editing a Postfix
+configuration file, except for one: the parameter that specifies the location
+of Postfix configuration files. In order to build Postfix with a configuration
+directory other than /etc/postfix, use:
+
+ $ make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/some/where\"'
+ $ make
+
+IMPORTANT: Be sure to get the quotes right. These details matter a lot.
+
+Parameters whose defaults can be specified in this way are listed below. See
+the postconf(5) manpage for a description (command: "nroff -man man/man5/
+postconf.5 | less").
+
+ ____________________________________________________________
+ |Macro name |default value for |typical default |
+ |_________________|_____________________|____________________|
+ |DEF_COMMAND_DIR |command_directory |/usr/sbin |
+ |_________________|_____________________|____________________|
+ |DEF_CONFIG_DIR |config_directory |/etc/postfix |
+ |_________________|_____________________|____________________|
+ |DEF_DB_TYPE |default_database_type|hash |
+ |_________________|_____________________|____________________|
+ |DEF_DAEMON_DIR |daemon_directory |/usr/libexec/postfix|
+ |_________________|_____________________|____________________|
+ |DEF_DATA_DIR |data_directory |/var/lib/postfix |
+ |_________________|_____________________|____________________|
+ |DEF_MAILQ_PATH |mailq_path |/usr/bin/mailq |
+ |_________________|_____________________|____________________|
+ |DEF_HTML_DIR |html_directory |no |
+ |_________________|_____________________|____________________|
+ |DEF_MANPAGE_DIR |manpage_directory |/usr/local/man |
+ |_________________|_____________________|____________________|
+ |DEF_NEWALIAS_PATH|newaliases_path |/usr/bin/newaliases |
+ |_________________|_____________________|____________________|
+ |DEF_QUEUE_DIR |queue_directory |/var/spool/postfix |
+ |_________________|_____________________|____________________|
+ |DEF_README_DIR |readme_directory |no |
+ |_________________|_____________________|____________________|
+ |DEF_SENDMAIL_PATH|sendmail_path |/usr/sbin/sendmail |
+ |_________________|_____________________|____________________|
+
+Note: the data_directory parameter (for caches and pseudo-random numbers) was
+introduced with Postfix version 2.5.
+
+4.7 - Overriding other compile-time features
+
+The general method to override Postfix compile-time features is as follows:
+
+ $ make makefiles name=value name=value...
+ $ make
+
+The following is an extensive list of names and values.
+
+ _____________________________________________________________________________
+|Name/Value |Description |
+|______________________________|______________________________________________|
+| |Specifies one or more non-default object |
+| |libraries. Postfix 3.0 and later specify some |
+| |of their database library dependencies with |
+|AUXLIBS="object_library..." |AUXLIBS_CDB, AUXLIBS_LDAP, AUXLIBS_LMDB, |
+| |AUXLIBS_MYSQL, AUXLIBS_PCRE, AUXLIBS_PGSQL, |
+| |AUXLIBS_SDBM, and AUXLIBS_SQLITE, |
+| |respectively. |
+|______________________________|______________________________________________|
+|CC=compiler_command |Specifies a non-default compiler. On many |
+| |systems, the default is gcc. |
+|______________________________|______________________________________________|
+| |Specifies non-default compiler arguments, for |
+|CCARGS="compiler_arguments..."|example, a non-default include directory. The |
+| |following directives turn off Postfix features|
+| |at compile time: |
+|______________________________|______________________________________________|
+|| |Do not build with Berkeley DB support. By |
+|| |default, Berkeley DB support is compiled in on|
+||-DNO_DB |platforms that are known to support this |
+|| |feature. If you override this, then you |
+|| |probably should also override DEF_DB_TYPE as |
+|| |described in section 4.6. |
+||_____________________________|______________________________________________|
+||-DNO_DNSSEC |Do not build with DNSSEC support, even if the |
+|| |resolver library appears to support it. |
+||_____________________________|______________________________________________|
+|| |Do not build with Solaris /dev/poll support. |
+||-DNO_DEVPOLL |By default, /dev/poll support is compiled in |
+|| |on Solaris versions that are known to support |
+|| |this feature. |
+||_____________________________|______________________________________________|
+|| |Do not build with Linux EPOLL support. By |
+||-DNO_EPOLL |default, EPOLL support is compiled in on |
+|| |platforms that are known to support this |
+|| |feature. |
+||_____________________________|______________________________________________|
+|| |Do not build with EAI (SMTPUTF8) support. By |
+||-DNO_EAI |default, EAI support is compiled in when the |
+|| |"icuuc" library and header files are found. |
+||_____________________________|______________________________________________|
+|| |Do not require support for C99 "inline" |
+||-DNO_INLINE |functions. Instead, implement argument |
+|| |typechecks for non-printf/scanf-like functions|
+|| |with ternary operators and unreachable code. |
+||_____________________________|______________________________________________|
+|| |Do not build with IPv6 support. By default, |
+|| |IPv6 support is compiled in on platforms that |
+||-DNO_IPV6 |are known to have IPv6 support. Note: this |
+|| |directive is for debugging and testing only. |
+|| |It is not guaranteed to work on all platforms.|
+||_____________________________|______________________________________________|
+|| |Do not build with FreeBSD / NetBSD / OpenBSD /|
+||-DNO_KQUEUE |MacOSX KQUEUE support. By default, KQUEUE |
+|| |support is compiled in on platforms that are |
+|| |known to support it. |
+||_____________________________|______________________________________________|
+|| |Do not build with NIS or NISPLUS support. NIS |
+||-DNO_NIS |is not available on some recent Linux |
+|| |distributions. |
+||_____________________________|______________________________________________|
+|| |Do not build with NISPLUS support. NISPLUS is |
+||-DNO_NISPLUS |not available on some recent Solaris |
+|| |distributions. |
+||_____________________________|______________________________________________|
+|| |Do not build with PCRE support. By default, |
+||-DNO_PCRE |PCRE support is compiled in when the pcre- |
+|| |config utility is installed. |
+||_____________________________|______________________________________________|
+|| |Disable support for POSIX getpwnam_r/ |
+||-DNO_POSIX_GETPW_R |getpwuid_r. By default Postfix uses these |
+|| |where they are known to be available. |
+||_____________________________|______________________________________________|
+|| |Use setjmp()/longjmp() instead of sigsetjmp()/|
+||-DNO_SIGSETJMP |siglongjmp(). By default, Postfix uses |
+|| |sigsetjmp()/siglongjmp() when they are known |
+|| |to be available. |
+||_____________________________|______________________________________________|
+| |Specifies a non-default compiler debugging |
+|DEBUG=debug_level |level. The default is "-g". Specify DEBUG= to |
+| |turn off debugging. |
+|______________________________|______________________________________________|
+| |Specifies a non-default optimization level. |
+|OPT=optimization_level |The default is "-O". Specify OPT= to turn off |
+| |optimization. |
+|______________________________|______________________________________________|
+| |Specifies non-default compiler options for |
+|SHLIB_CFLAGS=flags |building Postfix dynamically-linked libraries |
+| |and database plugins. The typical default is |
+| |"-fPIC". |
+|______________________________|______________________________________________|
+| |Specifies a non-default runpath for Postfix |
+|SHLIB_RPATH=rpath |dynamically-linked libraries. The typical |
+| |default is "'-Wl,-rpath,${SHLIB_DIR}'". |
+|______________________________|______________________________________________|
+| |Specifies a non-default suffix for Postfix |
+|SHLIB_SUFFIX=suffix |dynamically-linked libraries and database |
+| |plugins. The typical default is ".so". |
+|______________________________|______________________________________________|
+| |Specifies non-default compiler warning options|
+|WARN="warning_flags..." |for use when "make" is invoked in a source |
+| |subdirectory only. |
+|______________________________|______________________________________________|
+
+4.8 - Support for thousands of processes
+
+The number of connections that Postfix can manage simultaneously is limited by
+the number of processes that it can run. This number in turn is limited by the
+number of files and sockets that a single process can open. For example, the
+Postfix queue manager has a separate connection to each delivery process, and
+the anvil(8) server has one connection per smtpd(8) process.
+
+Postfix version 2.4 and later have no built-in limits on the number of open
+files or sockets, when compiled on systems that support one of the following:
+
+ * BSD kqueue(2) (FreeBSD 4.1, NetBSD 2.0, OpenBSD 2.9),
+ * Solaris 8 /dev/poll,
+ * Linux 2.6 epoll(4).
+
+With other Postfix versions or operating systems, the number of file
+descriptors per process is limited by the value of the FD_SETSIZE macro. If you
+expect to run more than 1000 mail delivery processes, you may need to override
+the definition of the FD_SETSIZE macro to make select() work correctly:
+
+ $ make makefiles CCARGS=-DFD_SETSIZE=2048
+
+Warning: the above has no effect on some Linux versions. Apparently, on these
+systems the FD_SETSIZE value can be changed only by using undocumented
+interfaces. Currently, that means including directly (which is
+not allowed) and overriding the __FD_SETSIZE macro. Beware, undocumented
+interfaces can change at any time and without warning.
+
+But wait, there is more: none of this will work unless the operating system is
+configured to handle thousands of connections. See the TUNING_README guide for
+examples of how to increase the number of open sockets or files.
+
+4.9 - Compiling Postfix, at last
+
+If the command
+
+ $ make
+
+is successful, then you can proceed to install Postfix (section 6).
+
+If the command produces compiler error messages, it may be time to search the
+web or to ask the postfix-users@postfix.org mailing list, but be sure to search
+the mailing list archives first. Some mailing list archives are linked from
+http://www.postfix.org/.
+
+5 - Porting Postfix to an unsupported system
+
+Each system type that Postfix knows is identified by a unique name. Examples:
+SUNOS5, FREEBSD4, and so on. When porting Postfix to a new system, the first
+step is to choose a SYSTEMTYPE name for the new system. You must use a name
+that includes at least the major version of the operating system (such as
+SUNOS4 or LINUX2), so that different releases of the same system can be
+supported without confusion.
+
+Add a case statement to the "makedefs" shell script in the source code top-
+level directory that recognizes the new system reliably, and that emits the
+right system-specific information. Be sure to make the code robust against user
+PATH settings; if the system offers multiple UNIX flavors (e.g. BSD and SYSV)
+be sure to build for the native flavor, instead of the emulated one.
+
+Add an "#ifdef SYSTEMTYPE" section to the central util/sys_defs.h include file.
+You may have to invent new feature macro names. Please choose sensible feature
+macro names such as HAS_DBM or FIONREAD_IN_SYS_FILIO_H.
+
+I strongly recommend against using "#ifdef SYSTEMTYPE" in individual source
+files. While this may look like the quickest solution, it will create a mess
+when newer versions of the same SYSTEMTYPE need to be supported. You're likely
+to end up placing "#ifdef" sections all over the source code again.
+
+6 - Installing the software after successful compilation
+
+This text describes how to install Postfix from source code. See the
+PACKAGE_README file if you are building a package for distribution to other
+systems.
+
+6.1 - Save existing Sendmail binaries
+
+IMPORTANT: if you are REPLACING an existing Sendmail installation with Postfix,
+you may need to keep the old sendmail program running for some time in order to
+flush the mail queue.
+
+ * Some systems implement a mail switch mechanism where different MTAs
+ (Postfix, Sendmail, etc.) can be installed at the same time, while only one
+ of them is actually being used. Examples of such switching mechanisms are
+ the FreeBSD mailwrapper(8) or the Linux mail switch. In this case you
+ should try to "flip" the switch to "Postfix" before installing Postfix.
+
+ * If your system has no mail switch mechanism, execute the following commands
+ (your sendmail, newaliases and mailq programs may be in a different place):
+
+ # mv /usr/sbin/sendmail /usr/sbin/sendmail.OFF
+ # mv /usr/bin/newaliases /usr/bin/newaliases.OFF
+ # mv /usr/bin/mailq /usr/bin/mailq.OFF
+ # chmod 755 /usr/sbin/sendmail.OFF /usr/bin/newaliases.OFF \
+ /usr/bin/mailq.OFF
+
+6.2 - Create account and groups
+
+Before you install Postfix for the first time you need to create an account and
+a group:
+
+ * Create a user account "postfix" with a user id and group id that are not
+ used by any other user account. Preferably, this is an account that no-one
+ can log into. The account does not need an executable login shell, and
+ needs no existing home directory. My password and group file entries look
+ like this:
+
+ /etc/passwd:
+ postfix:*:12345:12345:postfix:/no/where:/no/shell
+
+ /etc/group:
+ postfix:*:12345:
+
+ Note: there should be no whitespace before "postfix:".
+
+ * Create a group "postdrop" with a group id that is not used by any other
+ user account. Not even by the postfix user account. My group file entry
+ looks like:
+
+ /etc/group:
+ postdrop:*:54321:
+
+ Note: there should be no whitespace before "postdrop:".
+
+6.3 - Install Postfix
+
+To install or upgrade Postfix from compiled source code, run one of the
+following commands as the super-user:
+
+ # make install (interactive version, first time install)
+
+ # make upgrade (non-interactive version, for upgrades)
+
+ * The interactive version ("make install") asks for pathnames for Postfix
+ data and program files, and stores your preferences in the main.cf file. If
+ you don't want Postfix to overwrite non-Postfix "sendmail", "mailq" and
+ "newaliases" files, specify pathnames that end in ".postfix".
+
+ * The non-interactive version ("make upgrade") needs the /etc/postfix/main.cf
+ file from a previous installation. If the file does not exist, use
+ interactive installation ("make install") instead.
+
+ * If you specify name=value arguments on the "make install" or "make upgrade"
+ command line, then these will take precedence over compiled-in default
+ settings or main.cf settings.
+
+ 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 inconsistent results with different versions of
+ the make(1) command.
+
+6.4 - Configure Postfix
+
+Proceed to the section on how you wish to run Postfix on your particular
+machine:
+
+ * Send mail only, without changing an existing Sendmail installation (section
+ 7).
+
+ * Send and receive mail via a virtual host interface, still without any
+ change to an existing Sendmail installation (section 8).
+
+ * Run Postfix instead of Sendmail (section 9).
+
+7 - Configuring Postfix to send mail only
+
+If you are going to use Postfix to send mail only, there is no need to change
+your existing sendmail setup. Instead, set up your mail user agent so that it
+calls the Postfix sendmail program directly.
+
+Follow the instructions in the "Mandatory configuration file edits" in section
+10, and review the "To chroot or not to chroot" text in section 11.
+
+You MUST comment out the "smtp inet" entry in /etc/postfix/master.cf, in order
+to avoid conflicts with the real sendmail. Put a "#" character in front of the
+line that defines the smtpd service:
+
+ /etc/postfix/master.cf:
+ #smtp inet n - n - - smtpd
+
+Start the Postfix system:
+
+ # postfix start
+
+or, if you feel nostalgic, use the Postfix sendmail command:
+
+ # sendmail -bd -qwhatever
+
+and watch your maillog file for any error messages. The pathname is /var/log/
+maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
+pathname is defined in the /etc/syslog.conf file.
+
+ $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+Note: the most important error message is logged first. Later messages are not
+as useful.
+
+In order to inspect the mail queue, use one of the following commands:
+
+ $ mailq
+
+ $ sendmail -bp
+
+ $ postqueue -p
+
+See also the "Care and feeding" section 12 below.
+
+8 - Configuring Postfix to send and receive mail via virtual interface
+
+Alternatively, you can use the Postfix system to send AND receive mail while
+leaving your Sendmail setup intact, by running Postfix on a virtual interface
+address. Simply configure your mail user agent to directly invoke the Postfix
+sendmail program.
+
+To create a virtual network interface address, study your system ifconfig
+manual page. The command syntax could be any of:
+
+ # ifconfig le0:1 netmask up
+ # ifconfig en0 alias netmask 255.255.255.255
+
+In the /etc/postfix/main.cf file, I would specify
+
+ /etc/postfix/main.cf:
+ myhostname = virtual.host.tld
+ inet_interfaces = $myhostname
+ mydestination = $myhostname
+
+Follow the instructions in the "Mandatory configuration file edits" in section
+10, and review the "To chroot or not to chroot" text in section 11.
+
+Start the Postfix system:
+
+ # postfix start
+
+or, if you feel nostalgic, use the Postfix sendmail command:
+
+ # sendmail -bd -qwhatever
+
+and watch your maillog file for any error messages. The pathname is /var/log/
+maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
+pathname is defined in the /etc/syslog.conf file.
+
+ $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+Note: the most important error message is logged first. Later messages are not
+as useful.
+
+In order to inspect the mail queue, use one of the following commands:
+
+ $ mailq
+
+ $ sendmail -bp
+
+ $ postqueue -p
+
+See also the "Care and feeding" section 12 below.
+
+9 - Running Postfix instead of Sendmail
+
+Prior to installing Postfix you should save any existing sendmail program files
+as described in section 6. Be sure to keep the old sendmail running for at
+least a couple days to flush any unsent mail. To do so, stop the sendmail
+daemon and restart it as:
+
+ # /usr/sbin/sendmail.OFF -q
+
+Note: this is old sendmail syntax. Newer versions use separate processes for
+mail submission and for running the queue.
+
+After you have visited the "Mandatory configuration file edits" section below,
+you can start the Postfix system with:
+
+ # postfix start
+
+or, if you feel nostalgic, use the Postfix sendmail command:
+
+ # sendmail -bd -qwhatever
+
+and watch your maillog file for any error messages. The pathname is /var/log/
+maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
+pathname is defined in the /etc/syslog.conf file.
+
+ $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+Note: the most important error message is logged first. Later messages are not
+as useful.
+
+In order to inspect the mail queue, use one of the following commands:
+
+ $ mailq
+
+ $ sendmail -bp
+
+ $ postqueue -p
+
+See also the "Care and feeding" section 12 below.
+
+10 - Mandatory configuration file edits
+
+Note: the material covered in this section is covered in more detail in the
+BASIC_CONFIGURATION_README document. The information presented below is
+targeted at experienced system administrators.
+
+10.1 - Postfix configuration files
+
+By default, Postfix configuration files are in /etc/postfix. The two most
+important files are main.cf and master.cf; these files must be owned by root.
+Giving someone else write permission to main.cf or master.cf (or to their
+parent directories) means giving root privileges to that person.
+
+In /etc/postfix/main.cf, you will have to set up a minimal number of
+configuration parameters. Postfix configuration parameters resemble shell
+variables, with two important differences: the first one is that Postfix does
+not know about quotes like the UNIX shell does.
+
+You specify a configuration parameter as:
+
+ /etc/postfix/main.cf:
+ parameter = value
+
+and you use it by putting a "$" character in front of its name:
+
+ /etc/postfix/main.cf:
+ other_parameter = $parameter
+
+You can use $parameter before it is given a value (that is the second main
+difference with UNIX shell variables). The Postfix configuration language uses
+lazy evaluation, and does not look at a parameter value until it is needed at
+runtime.
+
+Whenever you make a change to the main.cf or master.cf file, execute the
+following command in order to refresh a running mail system:
+
+ # postfix reload
+
+10.2 - Default domain for unqualified addresses
+
+First of all, you must specify what domain will be appended to an unqualified
+address (i.e. an address without @domain.tld). The "myorigin" parameter
+defaults to the local hostname, but that is probably OK only for very small
+sites.
+
+Some examples (use only one):
+
+ /etc/postfix/main.cf:
+ myorigin = $myhostname (send mail as "user@$myhostname")
+ myorigin = $mydomain (send mail as "user@$mydomain")
+
+10.3 - What domains to receive locally
+
+Next you need to specify what mail addresses Postfix should deliver locally.
+
+Some examples (use only one):
+
+ /etc/postfix/main.cf:
+ mydestination = $myhostname, localhost.$mydomain, localhost
+ mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
+ mydestination = $myhostname
+
+The first example is appropriate for a workstation, the second is appropriate
+for the mailserver for an entire domain. The third example should be used when
+running on a virtual host interface.
+
+10.4 - Proxy/NAT interface addresses
+
+The proxy_interfaces parameter specifies all network addresses that Postfix
+receives mail on by way of a proxy or network address translation unit. You may
+specify symbolic hostnames instead of network addresses.
+
+IMPORTANT: You must specify your proxy/NAT external addresses when your system
+is a backup MX host for other domains, otherwise mail delivery loops will
+happen when the primary MX host is down.
+
+Example: host behind NAT box running a backup MX host.
+
+ /etc/postfix/main.cf:
+ proxy_interfaces = 1.2.3.4 (the proxy/NAT external network address)
+
+10.5 - What local clients to relay mail from
+
+If your machine is on an open network then you must specify what client IP
+addresses are authorized to relay their mail through your machine into the
+Internet. The default setting includes all subnetworks that the machine is
+attached to. This may give relay permission to too many clients. My own
+settings are:
+
+ /etc/postfix/main.cf:
+ mynetworks = 168.100.189.0/28, 127.0.0.0/8
+
+10.6 - What relay destinations to accept from strangers
+
+If your machine is on an open network then you must also specify whether
+Postfix will forward mail from strangers. The default setting will forward mail
+to all domains (and subdomains of) what is listed in $mydestination. This may
+give relay permission for too many destinations. Recommended settings (use only
+one):
+
+ /etc/postfix/main.cf:
+ relay_domains = (do not forward mail from strangers)
+ relay_domains = $mydomain (my domain and subdomains)
+ relay_domains = $mydomain, other.domain.tld, ...
+
+10.7 - Optional: configure a smart host for remote delivery
+
+If you're behind a firewall, you should set up a relayhost. If you can, specify
+the organizational domain name so that Postfix can use DNS lookups, and so that
+it can fall back to a secondary MX host when the primary MX host is down.
+Otherwise just specify a hard-coded hostname.
+
+Some examples (use only one):
+
+ /etc/postfix/main.cf:
+ relayhost = $mydomain
+ relayhost = [mail.$mydomain]
+
+The form enclosed with [] eliminates DNS MX lookups.
+
+By default, the SMTP client will do DNS lookups even when you specify a relay
+host. If your machine has no access to a DNS server, turn off SMTP client DNS
+lookups like this:
+
+ /etc/postfix/main.cf:
+ disable_dns_lookups = yes
+
+The STANDARD_CONFIGURATION_README file has more hints and tips for firewalled
+and/or dial-up networks.
+
+10.8 - Create the aliases database
+
+Postfix uses a Sendmail-compatible aliases(5) table to redirect mail for local
+(8) recipients. Typically, this information is kept in two files: in a text
+file /etc/aliases and in an indexed file /etc/aliases.db. The command "postconf
+alias_maps" will tell you the exact location of the text file.
+
+First, be sure to update the text file with aliases for root, postmaster and
+"postfix" that forward mail to a real person. Postfix has a sample aliases file
+/etc/postfix/aliases that you can adapt to local conditions.
+
+ /etc/aliases:
+ root: you
+ postmaster: root
+ postfix: root
+ bin: root
+ etcetera...
+
+Note: there should be no whitespace before the ":".
+
+Finally, build the indexed aliases file with one of the following commands:
+
+ # newaliases
+ # sendmail -bi
+
+11 - To chroot or not to chroot
+
+Postfix daemon processes can be configured (via master.cf) to run in a chroot
+jail. The processes run at a fixed low privilege and with access only to the
+Postfix queue directories (/var/spool/postfix). This provides a significant
+barrier against intrusion. The barrier is not impenetrable, but every little
+bit helps.
+
+With the exception of Postfix daemons that deliver mail locally and/or that
+execute non-Postfix commands, every Postfix daemon can run chrooted.
+
+Sites with high security requirements should consider to chroot all daemons
+that talk to the network: the smtp(8) and smtpd(8) processes, and perhaps also
+the lmtp(8) client. The author's own porcupine.org mail server runs all daemons
+chrooted that can be chrooted.
+
+The default /etc/postfix/master.cf file specifies that no Postfix daemon runs
+chrooted. In order to enable chroot operation, edit the file /etc/postfix/
+master.cf. Instructions are in the file.
+
+Note that a chrooted daemon resolves all filenames relative to the Postfix
+queue directory (/var/spool/postfix). For successful use of a chroot jail, most
+UNIX systems require you to bring in some files or device nodes. The examples/
+chroot-setup directory in the source code distribution has a collection of
+scripts that help you set up Postfix chroot environments on different operating
+systems.
+
+Additionally, you almost certainly need to configure syslogd so that it listens
+on a socket inside the Postfix queue directory. Examples for specific systems:
+
+FreeBSD:
+
+ # mkdir -p /var/spool/postfix/var/run
+ # syslogd -l /var/spool/postfix/var/run/log
+
+Linux, OpenBSD:
+
+ # mkdir -p /var/spool/postfix/dev
+ # syslogd -a /var/spool/postfix/dev/log
+
+12 - Care and feeding of the Postfix system
+
+Postfix daemon processes run in the background, and log problems and normal
+activity to the syslog daemon. The names of logfiles are specified in /etc/
+syslog.conf. At the very least you need something like:
+
+ /etc/syslog.conf:
+ mail.err /dev/console
+ mail.debug /var/log/maillog
+
+IMPORTANT: the syslogd will not create files. You must create them before
+(re)starting syslogd.
+
+IMPORTANT: on Linux you need to put a "-" character before the pathname, e.g.,
+-/var/log/maillog, otherwise the syslogd will use more system resources than
+Postfix does.
+
+Hopefully, the number of problems will be small, but it is a good idea to run
+every night before the syslog files are rotated:
+
+ # postfix check
+ # egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+ * The first line (postfix check) causes Postfix to report file permission/
+ ownership discrepancies.
+
+ * The second line looks for problem reports from the mail software, and
+ reports how effective the relay and junk mail access blocks are. This may
+ produce a lot of output. You will want to apply some postprocessing to
+ eliminate uninteresting information.
+
+The DEBUG_README document describes the meaning of the "warning" etc. labels in
+Postfix logging.
+
diff --git a/IPv6-ChangeLog b/IPv6-ChangeLog
new file mode 100644
index 0000000..ed55e64
--- /dev/null
+++ b/IPv6-ChangeLog
@@ -0,0 +1,483 @@
+ChangeLog for Dean Strik's IPv6 patch for Postfix. The patch is based on
+PLD's patch, which in turn seems to be based on KAME's. For more information:
+
+ http://www.ipnet6.org/postfix/
+
+---------------------------------------------------------------------
+
+Version 1.25 Postfix release 2.1.3
+ Postfix release 2.0.20
+ Postfix snapshot 2.2-20040616
+
+ Bugfix: Misplaced myfree() caused a small memory leak. Reported
+ by Christian von Roques.
+ File: util/match_ops.c
+
+ Removed the colon (:) from the characters XFORWARD replaces by
+ a question mark (IPv6 addresses looked like 2001?610?1108?5010??1
+ in logging). Reported by Philipp Morger.
+ File: smtpd/smtpd.c
+
+Version 1.24 Postfix release 2.1.1
+ Postfix release 2.0.20
+ Postfix snapshot 2.0.19-20040312
+ Postfix snapshot 2.2-20040504
+
+ Bugfix: Prefixlen non-null host portion validation (in CIDR maps
+ for example) yielded incorrect results sometimes because signed
+ arithmetic was used instead of unsigned.
+ File: util/match_ops.c
+
+ Patch correction: The TLS+IPv6 patch for Postfix 2.1.0 missed
+ the master.cf update (used for new installations). Added it
+ back.
+
+Version 1.23 Postfix release 2.1.0
+ Postfix release 2.0.20
+ Postfix snapshot 2.0.19-20040312
+
+ Patch fixes: Several code fixes to make the patch compile
+ and work correctly when compiled without IPv6 support.
+
+ Bugfix (Solaris only?): address family length was not updated
+ which could cause client hostname validation errors.
+ File: smtpd/smtpd_peer.c
+
+ Portability: added support for Darwin 7.3+. This may need
+ some further testing.
+
+ Cleanup: Restructure and redocument interface address
+ retrieval functions. (This reduced the number of preprocessor
+ statements from 99 to 93 ;)
+ File: util/inet_addr_local.c
+
+ Cleanup: make several explicit casts to have compilers shut
+ their pie holes about uninteresting things.
+
+Version 1.22 Postfix release 2.0.19
+ Postfix snapshot 2.0.19-20040312
+
+ Feature: Support "inet_interfaces = IPv4:all" and
+ "inet_interfaces = IPv6:all", to restrict postfix to use
+ either IPv4-only or IPv6-only. A more complete implementation
+ will be part of a future patch. (Slightly modified) patch by
+ Michal Ludvig, SuSE.
+ Files: util/interfaces_to_af.[ch], util/inet_addr_local.c,
+ global/own_inet_addr.c, global/wildcard_inet_addr.[ch],
+ master/master_ent.ch
+
+ Bugfix: In Postfix snapshots, a #define was misplaced with
+ the effect that IPv6 subnets were not included in auto-
+ generated $mynetworks (i.e., mynetworks not defined in main.cf,
+ when also mynetworks_style=subnet) on Linux 2.x systems.
+ File: utils/sys_defs.h
+
+Version 1.21a Postfix snapshots 2.0.18-2004{0122,0205,0209}
+ 2.0.19-20040312
+
+ TLS/snapshot version: Update TLS patch to 0.8.18-20040122.
+ Performed as a total repatch. 0.8.18 is cleaner with tls_*
+ variables if TLS is not actually compiled in.
+
+Version 1.21 Postfix releases 2.0.18 - 2.0.19
+ Postfix snapshot 2.0.16-20031231
+
+ Bugfix: The SMTP client could fail to setup a connection,
+ erroring with a bogus "getaddrinfo(...): hostname nor servname
+ provided" warning, because the wrong address was selected.
+ File: smtp/smtp_connect.c
+
+ Safety: in dynamically growing data structures, update the
+ length info after (instead of before) updating the data size.
+ File: util/inet_addr_list.c
+
+Version 1.20 Postfix release 2.0.16
+ Postfix snapshot 2.0.16-20031207
+
+ Bugfix: The SMTP client would abort when binding to specific
+ IPv6 addresses.
+ File: smtp/smtp_connect.c
+
+ Synchronisation/bugfix: LMTP source address binding is identical
+ to the SMTP source binding setup, avoiding the need for
+ lmtp_bind_address(6) if inet_interfaces is set to a single
+ host for an address family.
+ File: lmtp/lmtp_connect.c
+
+Version 1.19 Postfix release 2.0.16
+ Postfix snapshot 2.0.16-20031207
+
+ Bugfix: Synchronisation of TLS patches in snapshots of 1.18[ab]
+ was not complete, causing a crash of smtpd if used with the new
+ proxy agent.
+ File: smtpd/smtpd.c
+
+ Bugfix: SMTP source address binding based on a single hostname
+ in inet_interfaces did not work since the code counted IPv4 and
+ IPv6 addresses instead of only the used address family. Fixed,
+ thereby no longer requiring exact specification of
+ smtp_bind_address(6) in this case.
+ File: smtp/smtp_connect.c
+
+ Bugfix: The QMQP sink server did not compile correctly. This
+ program, part of smtpstone tools, is not compiled or installed
+ by default.
+ File: smtpstone/qmqp-sink.c
+
+ Bugfix: NI_WITHSCOPEID was not correctly defined everywhere,
+ which could result in EAI_BADFLAGS. Changed location of
+ definition to correct it.
+ Files: util/sys_defs.h, util/inet_addr_list.h
+
+Version 1.18b Postfix snapshot 2.0.16-20030921
+
+ IPv6 support: Added IPv6-enabled code to the new snapshot
+ check_*_{ns,mx}_access restrictions.
+ File: smtpd/smtpd_check.c
+
+Version 1.18a Postfix release 2.0.16
+
+ Update (TLS patches): Updated Lutz Jaenicke's TLS patch to
+ version 0.8.16. See pfixtls/ChangeLog for details.
+ Diff contributed by Tuomo Soini.
+
+ The TLS+IPv6 patch now contains the original TLS patch
+ documentation from Lutz Jaenicke.
+
+Version 1.18 Postfix releases 2.0.14 - 2.0.15
+ Postfix snapshot 2.0.14-20030812
+
+ Bugfix: Perform actual hostname verification in the SMTP
+ and QMTP servers. This was never supported in the IPv6
+ patch. Reported by Wolfgang S. Rupprecht.
+ Files: smtpd/smtpd_peer.c, qmqpd/qmqpd_peer.c
+
+ IPv6 address ranges using address/prefixlength (e.g. in
+ mynetworks and access maps) should be written as
+ [ipv6:addr:ess]/plen (e.g. [fec0:10:20::]/48). The old
+ supported syntax, [ipv6:addr:ess/plen] is deprecated and
+ support will be removed in a later version.
+ Thanks to Dr. Peter Bieringer and Pekka Savola for discussion.
+ Files: util/match_ops.c, global/mynetworks.c
+
+ Explicitly prefer IPv6 over IPv4 addresses when delivering
+ to a host when MX lookups are disabled when SMTP address
+ randomization is on (default).
+ File: smtp/smtp_addr.c
+
+ Compliance: write IPv6 address literals in mail headers
+ as [IPv6:addr] instead of [addr] as per RFC 2821:4.1.3
+ tagging requirement, for example [IPv6:fec0:10:20::1].
+ Pointed out by Dr. Peter Bieringer.
+ Files: smtpd/smtpd{,_peer,_state}.c, smtpd/smtpd.h
+
+Version 1.17 Postfix release 2.0.13, 2.0.14
+ Postfix snapshot 2.0.13-20030706, 2.0.14-20030812
+
+ Bugfix: Two memory allocation/deallocation bugs were
+ introduced in patch 1.16. The impact of these bugs could
+ be 'arbitrary' memory corruption.
+ File: util/match_ops.c
+
+Version 1.16 Postfix release 2.0.13
+ Postfix snapshot 2.0.13-20030706
+
+ Cleanup: rewrote match_ops.c. This rewrite is partly based on
+ patch by Takahiro Igarashi. The rewrite enables some better
+ handling of scoped addresses, and drops all GPL code from the
+ patch, easying license considerations. Also, allowed for
+ use of this code by the CIDR maps.
+ Files: util/match_ops.[ch]
+
+ Bugfix: correctly relay for scoped unicast addresses when
+ applicable. Until now, while Postfix was able to recognize
+ scoped addresses, it was not able to see e.g. fe80::10%fxp0
+ as local in mynetworks validation. KAME-only code.
+ (I've never heard of people using scoped addresses (think
+ link-local addresses) for mail relaying though...)
+ Files: util/inet_addr_list.[ch]
+
+ Feature (snapshot only): rewrote CIDR maps code to support
+ IPv6 addresses, using new match_ops code. Allow the use
+ of [::/0] since it allows one to easily disable further
+ checks for IPv6 addresses.
+ File: util/dict_cidr.c
+
+ Consistency: require IPv6 addresses in inet_interfaces to
+ be enclosed in square brackets.
+ File: util/inet_addr_host.c
+
+ Bugfix: (Linux2-only) A #define was misspelled. This could
+ lead to Postfix being unable to read the system's local IPv6
+ addresses (e.g. when using inet_interfaces).
+ Spotted by Jochen Friedrich.
+ File: util/sys_defs.h
+
+ Cleanup: require non-null host portion in CIDR /
+ prefixlength notations for IPv6 (was IPv4-only).
+
+Version 1.15a Postfix release 2.0.13
+
+ Update (TLS patches): Updated Lutz Jaenicke's TLS patch
+ to version 0.8.15. This version introduces new options
+ for managing SASL mechanisms. More information at:
+ http://www.aet.tu-cottbus.de/personen/jaenicke/pfixtls/
+ Diff contributed by Tuomo Soini.
+
+Version 1.15 Postfix release 2.0.12, 2.0.13
+ Postfix snapshot 2.0.12-20030621
+
+ Bugfix (TLS-snapshots only): a change in Postfix snapshot
+ 2.0.11-20030609 broke initialisation of TLS in smtpd,
+ causing TLS to both be unadvertised and unaccepted.
+ This was fixed again by reordering initialisation.
+ File: smtpd/smtpd.c
+
+ Update (TLS patches): Updated Lutz Jaenicke's TLS patch
+ to version 0.8.14. This version introduces a few fixes and
+ uses USE_SSL instead of HAS_SSL. More information at:
+ http://www.aet.tu-cottbus.de/personen/jaenicke/pfixtls/
+ Diff contributed by Tuomo Soini.
+
+ Bugfix (Postfix releases only - this was already added to
+ the snapshots in patch 1.14). KAME derived systems only.
+ Correctly decode scoped addresses, including network
+ interface specifiers.
+ File: util/inet_addr_local.c
+
+Version 1.14 Postfix releases 2.0.9, 2.0.10, 2.0.11, 2.0.12
+ Postfix snapshots 2.0.9-20030424, 2.0.10-20030521,
+ 2.0.11-20030609, 2.0.12-20030611
+
+ Patch change: made the patch available as an IPv6-only
+ patch (i.e., without the TLS code). This on popular
+ request by users and packagers.
+ A TLS+IPv6 version is still available of course.
+
+ Bugfix: correctly decode scoped addresses from now on
+ (KAME derived systems only). I think the original code
+ was written by Itojun, so I'm rather puzzled that it
+ didn't work...
+ File: util/inet_addr_local.c
+
+ Bugfix/portability: Recent KAME snapshots return both
+ TCP and SCTP address information on getaddrinfo() if
+ no protocol was specified. This causes the socket counts
+ to be wrong, confusing child processes.
+ Merged patch by JINMEI Tatuya of KAME to fix this.
+ Files: master/master.h, master/master_{ent,conf}.[ch],
+ util/inet_listen.c
+
+ Documentation: added an IPV6_README file to the patch.
+ This file contains the primary documentation. Also,
+ added a sample-ipv6.cf to describe the (currently few)
+ IPv6 related main.cf parameters.
+
+ Bugfix: the netmask structures for the *unsupported*
+ platforms (boldly assume /64) were added to the wrong
+ list (addresses instead of masks). This bug did not affect
+ any supported platform though.
+ File: util/inet_addr_local.c
+
+ Portability: added support for HP/Compaq Tru64Unix V5.1
+ and later. (compiled with CompaqCC only).
+ Thanks to Sten Spans for providing root access to an
+ IPv6-connected Tru64 testing machine.
+
+Version 1.13 Postfix releases 2.0.4 - 2.0.9
+ Postfix snapshots 2.0.3-20030126 - 2.0.7-20030319
+
+ Bugfix: Due to a missing storage pointer, DNS lookup
+ results in the permit_mx_backups code were not processed,
+ and smtpd would likely crash.
+ Thanks to Wouter de Jong for reporting the crashes.
+ File: smtpd/smtpd_check.c
+
+ Incompatible change: The addresses given to the parameters
+ smtp_bind_address6 and lmtp_bind_address6 now need to be
+ enclosed in square brackets for consistency.
+ Files: [ls]mtp/[ls]mtp_connect.c
+
+Version 1.12 Postfix releases 2.0.2, 2.0.3
+ Postfix snapshots 2.0.2-20030115, 2.0.3-20030126
+
+ Bugfix/workaround (Solaris): A simplified comparison
+ function for Solaris' qsort() function, would result
+ in corruption of network addresses in the SMTP client.
+ Fixed. Reported with possible fix by Edvard Tuinder.
+ File: smtp/smtp_addr.c
+
+Version 1.11 Postfix releases 2.0.0.x, 2.0.1, 2.0.2
+ Postfix snapshots 2.0.0-20030105, 2.0.1-20030112
+ 2.0.2-20030115
+
+ Bugfix (Solaris): Properly initialize lifconf structure
+ when requesting host interface addresses. If you get
+ warnings about SIOCGLIFCONF with earlier versions,
+ please upgrade.
+ File: util/inet_addr_local.c
+
+ Patch fix: fixed compilation errors in case the patch is
+ applied but built without IPv6 support (i.e., on unsupported
+ platforms).
+
+Version 1.10 Postfix snapshots 1.1.12-200212{19,21}
+ Postfix releases 2.0.0, 2.0.0.{1,2}
+ Postfix snapshots 2.0.0-20021223 - 2.0.0-20030101
+
+ 'Bugfix': don't show spurious warnings on Linux systems
+ about missing /proc/net/if_inet6 unless verbose mode
+ is enabled.
+ File: util/inet_addr_local.c
+
+ Bugfix: If unable to create a socket for a specific adress
+ in the SMTP client (e.g., when trying to create an IPv6
+ connection while the local host has no configured IPv6
+ addresses), then stop the attempt.
+ File: smtp/smtp_connect.c
+
+ Small bugfix: never query DNS for .
+ This syntax now correctly generates an error immediately.
+ File: global/resolve_local.c
+
+ Updated TLS patch to 0.8.12-1.1.12-20021219-0.9.6h, fixing
+ a bug with "sendmail -bs".
+
+Version 1.9 Postfix version 1.1.11-20021115
+ Postfix version 1.1.12-2002{1124,1209-1213}
+
+ Bugfix: with getifaddrs() code (*BSD, linux-USAGI), IPv4
+ netmasks were set to /32 effectively. Work around broken
+ netmask data structures (*BSD only perhaps).
+
+ Bugfix: same data corruption in another place created
+ entirely wrong IPv4 netmasks. Work around broken
+ SIOCGIFNETMASK structure.
+
+ New code was added for correct IPv6 netmasks. The original
+ code did not contain IPv6 netmask support at all!
+ For Solaris, use SIOCGLIF*; Linux: /proc/net/if_inet6.
+ Getifaddrs() support is used otherwise. This should cover
+ all supported systems. Other systems also work, prefix
+ length is always set to /64 then.
+
+ Since there are no classes (context: Class A, class B etc
+ networks) with IPv6, default to IPv6 subnet style if the
+ mynetworks style is 'class'. I recommend against this style
+ anyway.
+
+ Added support to display IPv6 nets mynetworks output.
+
+Version 1.8 Postfix version 1.1.11-200211{01,15}
+
+ An earlier author of the patch made a typo in the GAI_STRERROR()
+ macro, resulting in bogus error messages when checking for
+ PTR records. Fixed.
+
+ IPv4-mapped addresses in the smtpd are converted to true IPv4
+ addresses just after the connection has been made. This means
+ that all IPv4-mapped addresses are now logged as true IPv4
+ addresses. Hence beside RBL checks, also access maps now treat
+ IPv4-mapped addresses as native IPv4. Note that ::ffff:...
+ entries in your access tables will no longer work.
+
+ You can now specify IPv6 'parent' networks in your access maps,
+ e.g. to reject all mail from 3ffe:200:... nodes, add the line
+ 3ffe:200 REJECT
+ Use of trailing colons is discouraged because postmap will
+ warn about it possibly being an alias...
+ NOTE: I'll soon obsolete this again in favor of the more
+ common address/len notation. This was just so trivial to add
+ that it didn't hurt and I needed it :)
+
+ For easy reference, the version of the TLS/IPv6 patch can be
+ dynamically queried using the tls_ipv6_version variable.
+ This gives the short version (like, "1.8").
+
+ The service bind address for 'inet' sockets in master.cf (e.g.,
+ smtpd), must be enclosed in square brackets '[..]' for IPv6
+ addresses. The old style (without brackets) still works but is
+ unsupported and may be removed in the future. Example
+ [::1]:smtp inet n - n - - smtpd
+
+Version 1.7 Postfix version 1.1.11-20021029 - 1.1.11-20021101
+
+ Postfix' SMTP client performs randomization of MX addresses
+ when sending mail. This however could result in A records
+ being used before AAAA records. This has been corrected.
+
+ Note that from Postfix version 1.1.11-20021029 on, there is
+ a proxy_interfaces parameter. This has of course not been
+ ported to IPv6 addresses...
+
+Version 1.6 Postfix version 1.1.11-20020928
+
+ Added IPv6 support for backup_mx_networks feature; also the
+ behaviour when DNS lookups fail when checking whether the
+ local host is an MX for a domain conforms to the IPv4 case:
+ defer rather than allow.
+
+Version 1.5 Postfix version 1.1.11-20020917
+
+ I introduced two bugs when I rewrote my older LMTP IPv6 patch.
+ These bugs effectively rendered LMTP useless. Now fixed.
+ Bugs spotted by Kaj Niemi.
+
+ Now supports Solaris 8 and 9. Due to lack of testing equipment,
+ this has been only tested in production on Solaris 9, both
+ with gcc and the Sun Workshop Compiler.
+
+Version 1.4 Postfix version 1.1.11-20020822 - 1.1.11-20020917
+
+ OpenBSD (>=200003) and FreeBSD release 4 and up now use
+ getifaddrs(). This makes for cleaner code. The old code
+ seems to be bug-ridden anyway.
+
+ Got rid of some compiler warnings. Should be cleaner on
+ Alpha as well now. Thanks to Sten Spans for providing me
+ access to an Alpha running FreeBSD4.
+
+ Fixed an old bug in smtpd memory alloation if you compiled
+ without IPv6 support (the wrong buffer size was used. This
+ was harmless for IPv6-enabled compiles since the sizes were
+ equal then).
+
+ Added ChangeLog to the patch (as IPv6-ChangeLog) (this
+ was absent in 1.3 contrary to docs).
+
+Version 1.3 Postfix version 1.1.11-20020613 - 1.1.11-20020718
+
+ FYI: In postfix version 1.1.11-20020718, DNS lookups for
+ AAAA can be done natively. The code matches the code in
+ the patch (though the #ifdef changed from INET6 to T_AAAA).
+ This change causes the patch for 1.1.11-20020718 to be a
+ bit smaller.
+
+Version 1.2 Postfix version 1.1.11-20020613
+
+ Added IPv6 support for the LMTP client.
+
+ Added lmtp_bind_address and lmtp_bind_address6 parameters,
+ similar to those for smtp.
+
+ Added IPv6 support for the QMQP server.
+
+Version 1.1 Postfix version 1.1.11-20020602 - 1.1.11-20020613
+
+ Added parameter smtp_bind_address6. By using this parameter,
+ it is possible to bind to an IPv6 address, independently of
+ IPv4 address binding.
+
+ Lutz fixed a bug in his TLS patch regarding SASL. Incorporated.
+
+Version 1.0.x Postfix version 1.1.8-20020505 - 1.1.11-20020602
+
+ Patch derived from PLD's IPv6 patch for Postfix, revision 1.10
+ which applied to early Postfix snapshots 1.1.x. Updated this
+ patch to apply to 1.1.8-20020505.
+
+ Added compile-time checks for SS_LEN. Some Linux installations,
+ and maybe other systems, do define SA_LEN, but not SS_LEN.
+
+ Several updates of postfix snapshots.
+
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..45b9834
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,221 @@
+IBM PUBLIC LICENSE VERSION 1.0 - SECURE MAILER
+
+THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS IBM PUBLIC
+LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE
+PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
+
+1. DEFINITIONS
+
+"Contribution" means:
+ a) in the case of International Business Machines Corporation ("IBM"),
+ the Original Program, and
+ b) in the case of each Contributor,
+ i) changes to the Program, and
+ ii) additions to the Program;
+ where such changes and/or additions to the Program originate
+ from and are distributed by that particular Contributor.
+ A Contribution 'originates' from a Contributor if it was added
+ to the Program by such Contributor itself or anyone acting on
+ such Contributor's behalf.
+ Contributions do not include additions to the Program which:
+ (i) are separate modules of software distributed in conjunction
+ with the Program under their own license agreement, and
+ (ii) are not derivative works of the Program.
+
+"Contributor" means IBM and any other entity that distributes the Program.
+
+"Licensed Patents " mean patent claims licensable by a Contributor which
+are necessarily infringed by the use or sale of its Contribution alone
+or when combined with the Program.
+
+"Original Program" means the original version of the software accompanying
+this Agreement as released by IBM, including source code, object code
+and documentation, if any.
+
+"Program" means the Original Program and Contributions.
+
+"Recipient" means anyone who receives the Program under this Agreement,
+including all Contributors.
+
+2. GRANT OF RIGHTS
+
+ a) Subject to the terms of this Agreement, each Contributor hereby
+ grants Recipient a non-exclusive, worldwide, royalty-free copyright
+ license to reproduce, prepare derivative works of, publicly display,
+ publicly perform, distribute and sublicense the Contribution of such
+ Contributor, if any, and such derivative works, in source code and
+ object code form.
+
+ b) Subject to the terms of this Agreement, each Contributor hereby
+ grants Recipient a non-exclusive, worldwide, royalty-free patent
+ license under Licensed Patents to make, use, sell, offer to sell,
+ import and otherwise transfer the Contribution of such Contributor,
+ if any, in source code and object code form. This patent license
+ shall apply to the combination of the Contribution and the Program
+ if, at the time the Contribution is added by the Contributor, such
+ addition of the Contribution causes such combination to be covered
+ by the Licensed Patents. The patent license shall not apply to any
+ other combinations which include the Contribution. No hardware per
+ se is licensed hereunder.
+
+ c) Recipient understands that although each Contributor grants the
+ licenses to its Contributions set forth herein, no assurances are
+ provided by any Contributor that the Program does not infringe the
+ patent or other intellectual property rights of any other entity.
+ Each Contributor disclaims any liability to Recipient for claims
+ brought by any other entity based on infringement of intellectual
+ property rights or otherwise. As a condition to exercising the rights
+ and licenses granted hereunder, each Recipient hereby assumes sole
+ responsibility to secure any other intellectual property rights
+ needed, if any. For example, if a third party patent license
+ is required to allow Recipient to distribute the Program, it is
+ Recipient's responsibility to acquire that license before distributing
+ the Program.
+
+ d) Each Contributor represents that to its knowledge it has sufficient
+ copyright rights in its Contribution, if any, to grant the copyright
+ license set forth in this Agreement.
+
+3. REQUIREMENTS
+
+A Contributor may choose to distribute the Program in object code form
+under its own license agreement, provided that:
+ a) it complies with the terms and conditions of this Agreement; and
+ b) its license agreement:
+ i) effectively disclaims on behalf of all Contributors all
+ warranties and conditions, express and implied, including
+ warranties or conditions of title and non-infringement, and
+ implied warranties or conditions of merchantability and fitness
+ for a particular purpose;
+ ii) effectively excludes on behalf of all Contributors all
+ liability for damages, including direct, indirect, special,
+ incidental and consequential damages, such as lost profits;
+ iii) states that any provisions which differ from this Agreement
+ are offered by that Contributor alone and not by any other
+ party; and
+ iv) states that source code for the Program is available from
+ such Contributor, and informs licensees how to obtain it in a
+ reasonable manner on or through a medium customarily used for
+ software exchange.
+
+When the Program is made available in source code form:
+ a) it must be made available under this Agreement; and
+ b) a copy of this Agreement must be included with each copy of the
+ Program.
+
+Each Contributor must include the following in a conspicuous location
+in the Program:
+
+ Copyright (c) 1997,1998,1999, International Business Machines
+ Corporation and others. All Rights Reserved.
+
+In addition, each Contributor must identify itself as the originator of
+its Contribution, if any, in a manner that reasonably allows subsequent
+Recipients to identify the originator of the Contribution.
+
+4. COMMERCIAL DISTRIBUTION
+
+Commercial distributors of software may accept certain responsibilities
+with respect to end users, business partners and the like. While this
+license is intended to facilitate the commercial use of the Program, the
+Contributor who includes the Program in a commercial product offering
+should do so in a manner which does not create potential liability for
+other Contributors. Therefore, if a Contributor includes the Program in
+a commercial product offering, such Contributor ("Commercial Contributor")
+hereby agrees to defend and indemnify every other Contributor
+("Indemnified Contributor") against any losses, damages and costs
+(collectively "Losses") arising from claims, lawsuits and other legal
+actions brought by a third party against the Indemnified Contributor to
+the extent caused by the acts or omissions of such Commercial Contributor
+in connection with its distribution of the Program in a commercial
+product offering. The obligations in this section do not apply to any
+claims or Losses relating to any actual or alleged intellectual property
+infringement. In order to qualify, an Indemnified Contributor must:
+ a) promptly notify the Commercial Contributor in writing of such claim,
+and
+ b) allow the Commercial Contributor to control, and cooperate with
+ the Commercial Contributor in, the defense and any related
+ settlement negotiations. The Indemnified Contributor may
+ participate in any such claim at its own expense.
+
+For example, a Contributor might include the Program in a commercial
+product offering, Product X. That Contributor is then a Commercial
+Contributor. If that Commercial Contributor then makes performance
+claims, or offers warranties related to Product X, those performance
+claims and warranties are such Commercial Contributor's responsibility
+alone. Under this section, the Commercial Contributor would have to
+defend claims against the other Contributors related to those performance
+claims and warranties, and if a court requires any other Contributor to
+pay any damages as a result, the Commercial Contributor must pay those
+damages.
+
+5. NO WARRANTY
+
+EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED
+ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER
+EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR
+CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
+PARTICULAR PURPOSE. Each Recipient is solely responsible for determining
+the appropriateness of using and distributing the Program and assumes
+all risks associated with its exercise of rights under this Agreement,
+including but not limited to the risks and costs of program errors,
+compliance with applicable laws, damage to or loss of data, programs or
+equipment, and unavailability or interruption of operations.
+
+6. DISCLAIMER OF LIABILITY
+
+EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR
+ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING
+WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF
+LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION
+OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF
+ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+7. GENERAL
+
+If any provision of this Agreement is invalid or unenforceable under
+applicable law, it shall not affect the validity or enforceability of
+the remainder of the terms of this Agreement, and without further action
+by the parties hereto, such provision shall be reformed to the minimum
+extent necessary to make such provision valid and enforceable.
+
+If Recipient institutes patent litigation against a Contributor with
+respect to a patent applicable to software (including a cross-claim or
+counterclaim in a lawsuit), then any patent licenses granted by that
+Contributor to such Recipient under this Agreement shall terminate
+as of the date such litigation is filed. In addition, If Recipient
+institutes patent litigation against any entity (including a cross-claim
+or counterclaim in a lawsuit) alleging that the Program itself (excluding
+combinations of the Program with other software or hardware) infringes
+such Recipient's patent(s), then such Recipient's rights granted under
+Section 2(b) shall terminate as of the date such litigation is filed.
+
+All Recipient's rights under this Agreement shall terminate if it fails
+to comply with any of the material terms or conditions of this Agreement
+and does not cure such failure in a reasonable period of time after
+becoming aware of such noncompliance. If all Recipient's rights under
+this Agreement terminate, Recipient agrees to cease use and distribution
+of the Program as soon as reasonably practicable. However, Recipient's
+obligations under this Agreement and any licenses granted by Recipient
+relating to the Program shall continue and survive.
+
+IBM may publish new versions (including revisions) of this Agreement
+from time to time. Each new version of the Agreement will be given a
+distinguishing version number. The Program (including Contributions)
+may always be distributed subject to the version of the Agreement under
+which it was received. In addition, after a new version of the Agreement
+is published, Contributor may elect to distribute the Program (including
+its Contributions) under the new version. No one other than IBM has the
+right to modify this Agreement. Except as expressly stated in Sections
+2(a) and 2(b) above, Recipient receives no rights or licenses to the
+intellectual property of any Contributor under this Agreement, whether
+expressly, by implication, estoppel or otherwise. All rights in the
+Program not expressly granted under this Agreement are reserved.
+
+This Agreement is governed by the laws of the State of New York and the
+intellectual property laws of the United States of America. No party to
+this Agreement will bring a legal action under this Agreement more than
+one year after the cause of action arose. Each party waives its rights
+to a jury trial in any resulting litigation.
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..e2dd60a
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,216 @@
+# Do not edit -- this file documents how Postfix was built for your machine.
+#----------------------------------------------------------------
+# Start of summary of user-configurable 'make makefiles' options.
+# CCARGS=
+# AUXLIBS=
+# shared=
+# dynamicmaps=
+# pie=
+# End of summary of user-configurable 'make makefiles' options.
+#--------------------------------------------------------------
+# System-dependent settings and compiler/linker overrides.
+SYSTYPE = LINUX4
+_AR = ar
+ARFL = rv
+_RANLIB = ranlib
+SYSLIBS = -lpcre -ldb -lnsl -lresolv -ldl -Wl,-z,relro -lpthread -ldl -lm -L/usr/lib64 -licui18n -licuuc -licudata -lpthread -ldl -lm
+CC = gcc -I. -I../../include -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -I/usr/include -DHAS_PCRE -DSNAPSHOT -UUSE_DYNAMIC_LIBS -DDEF_SHLIB_DIR=\"no\" -UUSE_DYNAMIC_MAPS $(WARN)
+OPT = -O
+DEBUG = -g
+AWK = awk
+STRCASE =
+EXPORT = CCARGS='-I. -I../../include -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -I/usr/include -DHAS_PCRE -DSNAPSHOT -UUSE_DYNAMIC_LIBS -DDEF_SHLIB_DIR=\"no\" -UUSE_DYNAMIC_MAPS' OPT='-O' DEBUG='-g'
+WARN = -Wall -Wno-comment -Wformat -Wimplicit -Wmissing-prototypes \
+ -Wparentheses -Wstrict-prototypes -Wswitch -Wuninitialized \
+ -Wunused -Wno-missing-braces
+DEFINED_MAP_TYPES = pcre
+MAKE_FIX =
+# Switch between Postfix static and dynamically-linked libraries.
+AR = ar
+RANLIB = ranlib
+LIB_PREFIX =
+LIB_SUFFIX = .a
+SHLIB_CFLAGS =
+SHLIB_DIR = no
+SHLIB_ENV =
+SHLIB_LD = :
+SHLIB_SYSLIBS =
+SHLIB_RPATH =
+# Switch between dynamicmaps.cf plugins and hard-linked databases.
+NON_PLUGIN_MAP_OBJ = $(MAP_OBJ)
+PLUGIN_MAP_OBJ =
+PLUGIN_MAP_OBJ_UPDATE =
+PLUGIN_MAP_SO_MAKE =
+PLUGIN_MAP_SO_UPDATE =
+PLUGIN_LD =
+# Application-specific rules.
+SHELL = /bin/sh
+WARN = -Wmissing-prototypes -Wformat -Wno-comment
+OPTS = 'WARN=$(WARN)'
+DIRS = src/util src/global src/dns src/tls src/xsasl src/master src/milter \
+ src/postfix src/fsstone src/smtpstone \
+ src/sendmail src/error src/pickup src/cleanup src/smtpd src/local \
+ src/trivial-rewrite src/qmgr src/oqmgr src/smtp src/bounce \
+ src/pipe src/showq src/postalias src/postcat src/postconf src/postdrop \
+ src/postkick src/postlock src/postlog src/postmap src/postqueue \
+ src/postsuper src/qmqpd src/spawn src/flush src/verify \
+ src/virtual src/proxymap src/anvil src/scache src/discard src/tlsmgr \
+ src/postmulti src/postscreen src/dnsblog src/tlsproxy \
+ src/posttls-finger
+MANDIRS = proto man html
+LIBEXEC = libexec/post-install libexec/postfix-script libexec/postfix-wrapper \
+ libexec/postmulti-script libexec/post-install
+META = meta/main.cf.proto meta/master.cf.proto meta/postfix-files \
+ meta/makedefs.out $(PLUGINS)
+EXPAND = sed -e "s;\$${LIB_PREFIX};$(LIB_PREFIX);" \
+ -e "s;\$${LIB_SUFFIX};$(LIB_SUFFIX);"
+SHLIB_DIR_OVERRIDE = \
+ $${shlib_directory:-`$(SHLIB_ENV) bin/postconf -dhx shlib_directory`}
+
+default: update
+
+# While generating the top-level Makefile, we must get the PLUGIN_LD
+# setting directly from the latest makedefs.out result.
+
+makefiles Makefiles conf/makedefs.out:
+ (echo "# Do not edit -- this file documents how Postfix was built for your machine."; $(SHELL) makedefs) >makedefs.tmp
+ set +e; if cmp makedefs.tmp conf/makedefs.out; then rm makedefs.tmp; \
+ else mv makedefs.tmp conf/makedefs.out; fi >/dev/null 2>/dev/null
+ set -e; for i in $(DIRS); do \
+ (set -e; echo "[$$i]"; cd $$i; rm -f Makefile; \
+ $(MAKE) -f Makefile.in Makefile MAKELEVEL=) || exit 1; \
+ done
+ @set -- `grep '^PLUGIN_LD' conf/makedefs.out`; \
+ rm -f Makefile; (cat conf/makedefs.out; \
+ case "$$3" in \
+ ""|":") grep -v '^PLUGINS' Makefile.in;; \
+ *) cat Makefile.in;; \
+ esac) >Makefile
+
+update printfck tests root_tests:
+ set -e; for i in $(DIRS); do \
+ (set -e; echo "[$$i]"; cd $$i; $(MAKE) $(OPTS) $@ MAKELEVEL=) || exit 1; \
+ done
+
+update: $(META) $(LIBEXEC)
+
+libexec/post-install: conf/post-install
+ rm -f $@ && ln -f $? $@
+
+# Censor out build directory information.
+
+meta/makedefs.out: conf/makedefs.out
+ grep -v SHLIB_ENV $? > $@
+
+meta/postfix-files: conf/postfix-files conf/makedefs.out Makefile
+ rm -f $@
+ (if [ "${SHLIB_DIR}" = "no" -o "${SHLIB_DIR}" = "" ]; then \
+ sed -e '/^\$$shlib_directory/d' \
+ -e '/dynamicmaps.cf/d' conf/postfix-files; \
+ elif [ "${PLUGIN_LD}" = ":" -o "${PLUGIN_LD}" = "" ]; then \
+ sed -e '/dynamicmaps.cf/d' \
+ -e '/^\$$shlib_directory\/\$${LIB_PREFIX}/d' \
+ conf/postfix-files | $(EXPAND); \
+ else \
+ $(EXPAND) conf/postfix-files | awk -F: ' \
+ BEGIN { \
+ count = split("'"$(DEFINED_MAP_TYPES)"'", names, " "); \
+ for (n = 1; n <= count; n++) \
+ have["$$shlib_directory/$(LIB_PREFIX)" names[n] \
+ "$(LIB_SUFFIX)"] = 1; } \
+ /^[$$]shlib_directory.$(LIB_PREFIX)/ { \
+ if (have[$$1]) print; next } \
+ { print } \
+ '; \
+ fi) | case "$(MAKE_FIX)" in \
+ *) cat;; \
+ esac > $@
+
+libexec/postfix-script: conf/postfix-script
+ rm -f $@ && ln -f $? $@
+
+libexec/postfix-wrapper: conf/postfix-wrapper
+ rm -f $@ && ln -f $? $@
+
+meta/main.cf.proto: conf/main.cf
+ rm -f $@ && ln -f $? $@
+
+meta/master.cf.proto: conf/master.cf
+ rm -f $@ && ln -f $? $@
+
+libexec/postmulti-script: conf/postmulti-script
+ rm -f $@ && ln -f $? $@
+
+meta/dynamicmaps.cf: conf/dynamicmaps.cf Makefile
+ rm -f $@ && $(EXPAND) conf/dynamicmaps.cf | $(AWK) ' \
+ BEGIN { split("'"$(DEFINED_MAP_TYPES)"'", map_types); \
+ for (n in map_types) has_type[map_types[n]] = n } \
+ /^#/ { print } \
+ /^[a-z]/ { if (has_type[$$1]) print } \
+ ' >$@
+
+manpages:
+ set -e; for i in $(MANDIRS); do \
+ (set -e; echo "[$$i]"; cd $$i; $(MAKE) -f Makefile.in $(OPTS) MAKELEVEL=) || exit 1; \
+ done dynamicmaps=no or from
+# shared=yes<->shared=no.
+
+install: update
+ $(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+ postfix-install
+
+package: update
+ $(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+ postfix-install -package
+
+upgrade: update
+ $(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+ postfix-install -non-interactive
+
+
+non-interactive-package: update
+ $(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+ postfix-install -non-interactive -package
+
+depend clean:
+ set -e; for i in $(DIRS); do \
+ (set -e; echo "[$$i]"; cd $$i; $(MAKE) $@) || exit 1; \
+ done
+
+depend_update:
+ set -e; for i in $(DIRS); do \
+ (set -e; echo "[$$i]"; cd $$i; $(MAKE) depend && $(MAKE) $(OPTS) update) \
+ || exit 1; \
+ done
+
+tidy: clean
+ rm -f Makefile */Makefile src/*/Makefile
+ cp Makefile.init Makefile
+ rm -f README_FILES/RELEASE_NOTES
+ ln -s ../RELEASE_NOTES README_FILES
+ rm -f bin/[!CRS]* lib/[!CRS]* include/[!CRS]* libexec/[!CRS]* \
+ src/*/libpostfix-*.so src/*/libpostfix-*.dylib \
+ src/*/postfix-*.so src/*/postfix-*.dylib \
+ junk */junk */*/junk \
+ *core */*core */*/*core \
+ .nfs* */.nfs* */*/.nfs* \
+ .pure */.pure */*/.pure \
+ *.out */*.out */*/*.out \
+ *.tmp */*.tmp */*/*.tmp \
+ *.a */*.a */*/*.a \
+ *~ */*~ */*/*~ \
+ *- */*- */*/*- \
+ *.orig */*.orig */*/*.orig \
+ *.bak */*.bak */*/*.bak \
+ make.err */make.err */*/make.err \
+ *.gmon */*.gmon */*/*.gmon \
+ conf/main.cf.default conf/bounce.cf.default meta/*
+ find . -type s -print | xargs rm -f
+ find . -type d -print | xargs chmod 755
+ find . -type f -print | xargs chmod a+r
diff --git a/Makefile.in b/Makefile.in
new file mode 100644
index 0000000..47b1d69
--- /dev/null
+++ b/Makefile.in
@@ -0,0 +1,171 @@
+SHELL = /bin/sh
+WARN = -Wmissing-prototypes -Wformat -Wno-comment
+OPTS = 'WARN=$(WARN)'
+DIRS = src/util src/global src/dns src/tls src/xsasl src/master src/milter \
+ src/postfix src/fsstone src/smtpstone \
+ src/sendmail src/error src/pickup src/cleanup src/smtpd src/local \
+ src/trivial-rewrite src/qmgr src/oqmgr src/smtp src/bounce \
+ src/pipe src/showq src/postalias src/postcat src/postconf src/postdrop \
+ src/postkick src/postlock src/postlog src/postmap src/postqueue \
+ src/postsuper src/qmqpd src/spawn src/flush src/verify \
+ src/virtual src/proxymap src/anvil src/scache src/discard src/tlsmgr \
+ src/postmulti src/postscreen src/dnsblog src/tlsproxy \
+ src/posttls-finger
+MANDIRS = proto man html
+LIBEXEC = libexec/post-install libexec/postfix-script libexec/postfix-wrapper \
+ libexec/postmulti-script libexec/post-install
+PLUGINS = meta/dynamicmaps.cf
+META = meta/main.cf.proto meta/master.cf.proto meta/postfix-files \
+ meta/makedefs.out $(PLUGINS)
+EXPAND = sed -e "s;\$${LIB_PREFIX};$(LIB_PREFIX);" \
+ -e "s;\$${LIB_SUFFIX};$(LIB_SUFFIX);"
+SHLIB_DIR_OVERRIDE = \
+ $${shlib_directory:-`$(SHLIB_ENV) bin/postconf -dhx shlib_directory`}
+
+default: update
+
+# While generating the top-level Makefile, we must get the PLUGIN_LD
+# setting directly from the latest makedefs.out result.
+
+makefiles Makefiles conf/makedefs.out:
+ (echo "# Do not edit -- this file documents how Postfix was built for your machine."; $(SHELL) makedefs) >makedefs.tmp
+ set +e; if cmp makedefs.tmp conf/makedefs.out; then rm makedefs.tmp; \
+ else mv makedefs.tmp conf/makedefs.out; fi >/dev/null 2>/dev/null
+ set -e; for i in $(DIRS); do \
+ (set -e; echo "[$$i]"; cd $$i; rm -f Makefile; \
+ $(MAKE) -f Makefile.in Makefile MAKELEVEL=) || exit 1; \
+ done
+ @set -- `grep '^PLUGIN_LD' conf/makedefs.out`; \
+ rm -f Makefile; (cat conf/makedefs.out; \
+ case "$$3" in \
+ ""|":") grep -v '^PLUGINS' Makefile.in;; \
+ *) cat Makefile.in;; \
+ esac) >Makefile
+
+update printfck tests root_tests:
+ set -e; for i in $(DIRS); do \
+ (set -e; echo "[$$i]"; cd $$i; $(MAKE) $(OPTS) $@ MAKELEVEL=) || exit 1; \
+ done
+
+update: $(META) $(LIBEXEC)
+
+libexec/post-install: conf/post-install
+ rm -f $@ && ln -f $? $@
+
+# Censor out build directory information.
+
+meta/makedefs.out: conf/makedefs.out
+ grep -v SHLIB_ENV $? > $@
+
+meta/postfix-files: conf/postfix-files conf/makedefs.out Makefile
+ rm -f $@
+ (if [ "${SHLIB_DIR}" = "no" -o "${SHLIB_DIR}" = "" ]; then \
+ sed -e '/^\$$shlib_directory/d' \
+ -e '/dynamicmaps.cf/d' conf/postfix-files; \
+ elif [ "${PLUGIN_LD}" = ":" -o "${PLUGIN_LD}" = "" ]; then \
+ sed -e '/dynamicmaps.cf/d' \
+ -e '/^\$$shlib_directory\/\$${LIB_PREFIX}/d' \
+ conf/postfix-files | $(EXPAND); \
+ else \
+ $(EXPAND) conf/postfix-files | awk -F: ' \
+ BEGIN { \
+ count = split("'"$(DEFINED_MAP_TYPES)"'", names, " "); \
+ for (n = 1; n <= count; n++) \
+ have["$$shlib_directory/$(LIB_PREFIX)" names[n] \
+ "$(LIB_SUFFIX)"] = 1; } \
+ /^[$$]shlib_directory.$(LIB_PREFIX)/ { \
+ if (have[$$1]) print; next } \
+ { print } \
+ '; \
+ fi) | case "$(MAKE_FIX)" in \
+ *) cat;; \
+ esac > $@
+
+libexec/postfix-script: conf/postfix-script
+ rm -f $@ && ln -f $? $@
+
+libexec/postfix-wrapper: conf/postfix-wrapper
+ rm -f $@ && ln -f $? $@
+
+meta/main.cf.proto: conf/main.cf
+ rm -f $@ && ln -f $? $@
+
+meta/master.cf.proto: conf/master.cf
+ rm -f $@ && ln -f $? $@
+
+libexec/postmulti-script: conf/postmulti-script
+ rm -f $@ && ln -f $? $@
+
+meta/dynamicmaps.cf: conf/dynamicmaps.cf Makefile
+ rm -f $@ && $(EXPAND) conf/dynamicmaps.cf | $(AWK) ' \
+ BEGIN { split("'"$(DEFINED_MAP_TYPES)"'", map_types); \
+ for (n in map_types) has_type[map_types[n]] = n } \
+ /^#/ { print } \
+ /^[a-z]/ { if (has_type[$$1]) print } \
+ ' >$@
+
+manpages:
+ set -e; for i in $(MANDIRS); do \
+ (set -e; echo "[$$i]"; cd $$i; $(MAKE) -f Makefile.in $(OPTS) MAKELEVEL=) || exit 1; \
+ done dynamicmaps=no or from
+# shared=yes<->shared=no.
+
+install: update
+ $(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+ postfix-install
+
+package: update
+ $(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+ postfix-install -package
+
+upgrade: update
+ $(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+ postfix-install -non-interactive
+
+
+non-interactive-package: update
+ $(SHLIB_ENV) shlib_directory=$(SHLIB_DIR_OVERRIDE) $(SHELL) \
+ postfix-install -non-interactive -package
+
+depend clean:
+ set -e; for i in $(DIRS); do \
+ (set -e; echo "[$$i]"; cd $$i; $(MAKE) $@) || exit 1; \
+ done
+
+depend_update:
+ set -e; for i in $(DIRS); do \
+ (set -e; echo "[$$i]"; cd $$i; $(MAKE) depend && $(MAKE) $(OPTS) update) \
+ || exit 1; \
+ done
+
+tidy: clean
+ rm -f Makefile */Makefile src/*/Makefile
+ cp Makefile.init Makefile
+ rm -f README_FILES/RELEASE_NOTES
+ ln -s ../RELEASE_NOTES README_FILES
+ rm -f bin/[!CRS]* lib/[!CRS]* include/[!CRS]* libexec/[!CRS]* \
+ src/*/libpostfix-*.so src/*/libpostfix-*.dylib \
+ src/*/postfix-*.so src/*/postfix-*.dylib \
+ junk */junk */*/junk \
+ *core */*core */*/*core \
+ .nfs* */.nfs* */*/.nfs* \
+ .pure */.pure */*/.pure \
+ *.out */*.out */*/*.out \
+ *.tmp */*.tmp */*/*.tmp \
+ *.a */*.a */*/*.a \
+ *~ */*~ */*/*~ \
+ *- */*- */*/*- \
+ *.orig */*.orig */*/*.orig \
+ *.bak */*.bak */*/*.bak \
+ make.err */make.err */*/make.err \
+ *.gmon */*.gmon */*/*.gmon \
+ conf/main.cf.default conf/bounce.cf.default meta/*
+ find . -type s -print | xargs rm -f
+ find . -type d -print | xargs chmod 755
+ find . -type f -print | xargs chmod a+r
diff --git a/Makefile.init b/Makefile.init
new file mode 100644
index 0000000..bf0bad8
--- /dev/null
+++ b/Makefile.init
@@ -0,0 +1,22 @@
+# Usage:
+# make makefiles [name=value]...
+#
+# See makedefs for a descripton of available options.
+# Examples:
+#
+# make makefiles
+# make makefiles CC="purify cc"
+# make makefiles CC=cc OPT=
+#
+SHELL = /bin/sh
+
+default: update
+
+update depend printfck clean tidy depend_update: Makefiles
+ $(MAKE) MAKELEVEL= $@
+
+install upgrade:
+ @echo Please review the INSTALL instructions first.
+
+makefiles Makefiles:
+ $(MAKE) -f Makefile.in MAKELEVEL= Makefiles
diff --git a/PORTING b/PORTING
new file mode 100644
index 0000000..7a2d503
--- /dev/null
+++ b/PORTING
@@ -0,0 +1,24 @@
+In order to port software to a new platform:
+
+- Choose a SYSTEMTYPE name for the new system. You must use a name
+that includes at least the major version of the operating system
+(such as SUNOS4 or LINUX2), so that different releases of the same
+system can be supported without confusion.
+
+- Add a case statement to the "makedefs" shell script in the source
+code top-level directory that recognizes the new system reliably,
+and that emits the right system-specific information. Be sure to
+make the code robust against user PATH settings; if the system
+offers multiple UNIX flavors (e.g. BSD and SYSV) be sure to build
+for the native flavor, instead of the emulated one.
+
+- Add an "#ifdef SYSTEMTYPE" section to the central util/sys_defs.h
+include file. You may have to invent new feature macro names.
+Please choose sensible feature macro names such as HAS_DBM or
+FIONREAD_IN_SYS_FILIO_H.
+
+I strongly recommend against using "#ifdef SYSTEMTYPE" in individual
+source files. While this may look like the quickest solution, it
+will create a mess when newer versions of the same SYSTEMTYPE need
+to be supported. You're likely to end up placing "#ifdef" sections
+all over the source code again.
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..539f73f
--- /dev/null
+++ b/README.md
@@ -0,0 +1,10 @@
+# postfix.3.1
+# postfix.3.1
+# postfix.3.1
+# postfix.3.1
+# postfix.3.1
+# postfix.3.1
+# postfix.3.1
+# postfix.3.1
+# postfix.3.1
+# postfix.3.1
diff --git a/README_FILES/AAAREADME b/README_FILES/AAAREADME
new file mode 100644
index 0000000..d4e10f0
--- /dev/null
+++ b/README_FILES/AAAREADME
@@ -0,0 +1,85 @@
+ PPoossttffiixx DDooccuummeennttaattiioonn
+
+-------------------------------------------------------------------------------
+GGeenneerraall ccoonnffiigguurraattiioonn
+
+ * BASIC_CONFIGURATION_README: Basic configuration
+ * SOHO_README: Small/home office hints and tips
+ * STANDARD_CONFIGURATION_README: Standard configuration examples
+ * ADDRESS_REWRITING_README: Address rewriting
+ * VIRTUAL_README: Virtual domain hosting
+ * SASL_README: SASL Authentication
+ * TLS_README: TLS Encryption and authentication
+ * FORWARD_SECRECY_README: TLS Forward Secrecy
+ * IPV6_README: IP Version 6 Support
+ * IPV6_README: IP Version 6 Support
+ * SMTPUTF8_README: SMTPUTF8 Support
+ * COMPATIBILITY_README: Backwards-Compatibility Safety Net
+ * INSTALL: Installation from source code
+
+PPrroobblleemm ssoollvviinngg
+
+ * QSHAPE_README: Bottleneck analysis
+ * STRESS_README: Stress-dependent configuration
+ * TUNING_README: Performance tuning
+ * DEBUG_README: Debugging strategies
+
+CCoonntteenntt iinnssppeeccttiioonn
+
+ * CONTENT_INSPECTION_README: Content inspection overview
+ * BACKSCATTER_README: Stopping backscatter mail
+ * BUILTIN_FILTER_README: Built-in content inspection
+
+ * FILTER_README: After-queue content filter
+ * SMTPD_PROXY_README: Before-queue content filter
+ * MILTER_README: Before-queue Milter applications
+
+SSMMTTPP RReellaayy aanndd aacccceessss ccoonnttrrooll
+
+ * SMTPD_ACCESS_README: Relay/access control overview
+ * SMTPD_POLICY_README: Access policy delegation
+ * ADDRESS_VERIFICATION_README: Address verification
+ * RESTRICTION_CLASS_README: Per-client/user/etc. access
+ * POSTSCREEN_README: SMTP connection triage
+ * ETRN_README: ETRN Support
+ * UUCP_README: LAN connected via UUCP
+
+LLooookkuupp ttaabblleess ((ddaattaabbaasseess))
+
+ * DATABASE_README: Lookup table overview
+ * DB_README: Berkeley DB Howto
+ * CDB_README: CDB Howto
+ * LDAP_README: LDAP Howto
+ * LMDB_README: LMDB Howto
+ * MEMCACHE_README: Memcache Howto
+ * MYSQL_README: MySQL Howto
+ * PCRE_README: PCRE Howto
+ * PGSQL_README: PostgreSQL Howto
+ * SQLITE_README: SQLite Howto
+
+MMaaiilliinngg lliisstt ssuuppppoorrtt
+
+ * VERP_README: VERP Support
+
+SSppeecciiffiicc eennvviirroonnmmeennttss
+
+ * LINUX_README: Linux issues
+ * NFS_README: NFS issues
+
+OOtthheerr mmaaiill ddeelliivveerryy aaggeennttss
+
+ * MAILDROP_README: Maildrop
+
+OOtthheerr ttooppiiccss
+
+ * OVERVIEW: Architecture overview
+ * postconf(5): All main.cf parameters
+ * LOCAL_RECIPIENT_README: Rejecting Unknown Local Recipients
+ * ADDRESS_CLASS_README: Address Classes
+ * CONNECTION_CACHE_README: Connection cache howto
+ * DSN_README: Postfix DSN support
+ * PACKAGE_README: Guidelines for Package Builders
+ * SCHEDULER_README: Queue Scheduler
+ * XCLIENT_README: XCLIENT Command
+ * XFORWARD_README: XFORWARD Command
+
diff --git a/README_FILES/ADDRESS_CLASS_README b/README_FILES/ADDRESS_CLASS_README
new file mode 100644
index 0000000..2de5acc
--- /dev/null
+++ b/README_FILES/ADDRESS_CLASS_README
@@ -0,0 +1,201 @@
+PPoossttffiixx AAddddrreessss CCllaasssseess
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix version 2.0 introduces the concept of address classes. This is a way of
+grouping recipient addresses by their delivery method. The idea comes from
+discussions with Victor Duchovni. Although address classes introduced a few
+incompatibilities they also made it possible to improve the handling of hosted
+domains and of unknown recipients.
+
+This document provides information on the following topics:
+
+ * What are address classes good for?
+ * What address classes does Postfix implement?
+ * Improvements compared to Postfix 1.1
+ * Incompatibilities with Postfix 1.1
+
+WWhhaatt aarree aaddddrreessss ccllaasssseess ggoooodd ffoorr??
+
+Why should you care about address classes? This is how Postfix decides what
+mail to accept, and how to deliver it. In other words, address classes are very
+important for the operation of Postfix.
+
+An address class is defined by three items.
+
+ * The list of domains that are a member of the class: for example, all local
+ domains, or all relay domains.
+
+ * The default delivery transport. For example, the local, virtual or relay
+ delivery transport (delivery transports are defined in master.cf). This
+ helps to keep Postfix configurations simple, by avoiding the need for
+ explicit routing information in transport maps.
+
+ * The list of valid recipient addresses for that address class. The Postfix
+ SMTP server rejects invalid recipients with "User unknown in table". This helps to keep the Postfix queue free of
+ undeliverable MAILER-DAEMON messages.
+
+WWhhaatt aaddddrreessss ccllaasssseess ddooeess PPoossttffiixx iimmpplleemmeenntt??
+
+Initially the list of address classes is hard coded, but this is meant to
+become extensible. The summary below describes the main purpose of each class,
+and what the relevant configuration parameters are.
+
+The local domain class.
+
+ * Purpose: final delivery for traditional UNIX system accounts and
+ traditional Sendmail-style aliases. This is typically used for the
+ canonical domains of the machine. For a discussion of the difference
+ between canonical domains, hosted domains and other domains, see the
+ VIRTUAL_README file.
+
+ * Domain names are listed with the mydestination parameter. This domain class
+ also includes mail for user@[ipaddress] when the IP address is listed with
+ the inet_interfaces or proxy_interfaces parameters.
+
+ * Valid recipient addresses are listed with the local_recipient_maps
+ parameter, as described in LOCAL_RECIPIENT_README. The Postfix SMTP server
+ rejects invalid recipients with "User unknown in local recipient table". If
+ the local_recipient_maps parameter value is empty, then the Postfix SMTP
+ server accepts any address in the local domain class.
+
+ * The mail delivery transport is specified with the local_transport
+ parameter. The default value is llooccaall::$$mmyyhhoossttnnaammee for delivery with the
+ local(8) delivery agent.
+
+The virtual alias domain class.
+
+ * Purpose: hosted domains where each recipient address is aliased to a local
+ UNIX system account or to a remote address. A virtual alias example is
+ given in the VIRTUAL_README file.
+
+ * Domain names are listed in virtual_alias_domains. The default value is
+ $virtual_alias_maps for Postfix 1.1 compatibility.
+
+ * Valid recipient addresses are listed with the virtual_alias_maps parameter.
+ The Postfix SMTP server rejects invalid recipients with "User unknown in
+ virtual alias table". The default value is $virtual_maps for Postfix 1.1
+ compatibility.
+
+ * There is no mail delivery transport parameter. Every address must be
+ aliased to some other address.
+
+The virtual mailbox domain class.
+
+ * Purpose: final delivery for hosted domains where each recipient address can
+ have its own mailbox, and where users do not need to have a UNIX system
+ account. A virtual mailbox example is given in the VIRTUAL_README file.
+
+ * Domain names are listed with the virtual_mailbox_domains parameter. The
+ default value is $virtual_mailbox_maps for Postfix 1.1 compatibility.
+
+ * Valid recipient addresses are listed with the virtual_mailbox_maps
+ parameter. The Postfix SMTP server rejects invalid recipients with "User
+ unknown in virtual mailbox table". If this parameter value is empty, the
+ Postfix SMTP server accepts all recipients for domains listed in
+ $virtual_mailbox_domains.
+
+ * The mail delivery transport is specified with the virtual_transport
+ parameter. The default value is vviirrttuuaall for delivery with the virtual(8)
+ delivery agent.
+
+The relay domain class.
+
+ * Purpose: mail forwarding to remote destinations that list your system as
+ primary or backup MX host. For a discussion of the basic configuration
+ details, see the BASIC_CONFIGURATION_README document. For a discussion of
+ the difference between canonical domains, hosted domains and other domains,
+ see the VIRTUAL_README file.
+
+ * Domain names are listed with the relay_domains parameter.
+
+ * Valid recipient addresses are listed with the relay_recipient_maps
+ parameter. The Postfix SMTP server rejects invalid recipients with "User
+ unknown in relay recipient table". If this parameter value is empty, the
+ Postfix SMTP server accepts all recipients for domains listed with the
+ relay_domains parameter.
+
+ * The mail delivery transport is specified with the relay_transport
+ parameter. The default value is rreellaayy which is a clone of the smtp(8)
+ delivery agent.
+
+The default domain class.
+
+ * Purpose: mail forwarding to the Internet on behalf of authorized clients.
+ For a discussion of the basic configuration details, see the
+ BASIC_CONFIGURATION_README file. For a discussion of the difference between
+ canonical domains, hosted domains and other domains, see the VIRTUAL_README
+ file.
+
+ * This class has no destination domain table.
+
+ * This class has no valid recipient address table.
+
+ * The mail delivery transport is specified with the default_transport
+ parameter. The default value is ssmmttpp for delivery with the smtp(8) delivery
+ agent.
+
+IImmpprroovveemmeennttss ccoommppaarreedd ttoo PPoossttffiixx 11..11
+
+Postfix 2.0 address classes made the following improvements possible over
+earlier Postfix versions:
+
+ * You no longer need to specify all the virtual(8) mailbox domains in the
+ Postfix transport map. The virtual(8) delivery agent has become a first-
+ class citizen just like local(8) or smtp(8).
+
+ * On mail gateway systems, address classes provide separation of inbound mail
+ relay traffic ($relay_transport) from outbound traffic
+ ($default_transport). This eliminates a problem where inbound mail
+ deliveries could become resource starved in the presence of a high volume
+ of outbound mail.
+
+ * The SMTP server rejects unknown recipients in a more consistent manner than
+ was possible with Postfix version 1. This is needed to keep undeliverable
+ mail (and bounced undeliverable mail) out of the mail queue. This is
+ controlled by the smtpd_reject_unlisted_recipient configuration parameter.
+
+ * As of Postfix version 2.1, the SMTP server also rejects unknown sender
+ addresses (i.e. addresses that it would reject as unknown recipient
+ addresses). Sender "egress filtering" can help to slow down an email worm
+ explosion. This is controlled by the smtpd_reject_unlisted_sender
+ configuration parameter.
+
+IInnccoommppaattiibbiilliittiieess wwiitthh PPoossttffiixx 11..11
+
+Postfix 2.0 address classes introduce a few incompatible changes in documented
+behavior. In order to ease the transitions, new parameters have default values
+that are backwards compatible.
+
+ * The virtual_maps parameter is replaced by virtual_alias_maps (for address
+ lookups) and by virtual_alias_domains (for the names of what were formerly
+ called "Postfix-style virtual domains").
+
+ For backwards compatibility with Postfix version 1.1, the new
+ virtual_alias_maps parameter defaults to $virtual_maps, and the new
+ virtual_alias_domains parameter defaults to $virtual_alias_maps.
+
+ * The virtual_mailbox_maps parameter now has a companion parameter called
+ virtual_mailbox_domains (for the names of domains served by the virtual
+ delivery agent). The virtual_mailbox_maps parameter is now used for address
+ lookups only.
+
+ For backwards compatibility with Postfix version 1.1, the new
+ virtual_mailbox_domains parameter defaults to $virtual_mailbox_maps.
+
+ * Introduction of the relay_recipient_maps parameter. The Postfix SMTP server
+ can use this to block mail for relay recipients that don't exist. This list
+ is empty by default, which means accept any recipient.
+
+ * The local_recipient_maps feature is now turned on by default. The Postfix
+ SMTP server uses this to reject mail for unknown local recipients. See the
+ LOCAL_RECIPIENT_README file hints and tips.
+
+ * Introduction of the relay delivery transport in master.cf. This helps to
+ avoid mail delivery scheduling problems on inbound mail relays when there
+ is a lot of outbound mail, but may require that you update your
+ "defer_transports" setting.
+
diff --git a/README_FILES/ADDRESS_REWRITING_README b/README_FILES/ADDRESS_REWRITING_README
new file mode 100644
index 0000000..e1fcdee
--- /dev/null
+++ b/README_FILES/ADDRESS_REWRITING_README
@@ -0,0 +1,840 @@
+PPoossttffiixx AAddddrreessss RReewwrriittiinngg
+
+-------------------------------------------------------------------------------
+
+PPoossttffiixx aaddddrreessss rreewwrriittiinngg ppuurrppoossee
+
+Address rewriting is at the heart of the Postfix mail system. Postfix rewrites
+addresses for many different purposes. Some are merely cosmetic, and some are
+necessary to deliver correctly formatted mail to the correct destination.
+Examples of address rewriting in Postfix are:
+
+ * Transform an incomplete address into a complete address. For example,
+ transform "username" into "username@example.com", or transform
+ "username@hostname" into "username@hostname.example.com".
+
+ * Replace an address by an equivalent address. For example, replace
+ "username@example.com" by "firstname.lastname@example.com" when sending
+ mail, and do the reverse transformation when receiving mail.
+
+ * Replace an internal address by an external address. For example, replace
+ "username@localdomain.local" by "isp-account@isp.example" when sending mail
+ from a home computer to the Internet.
+
+ * Replace an address by multiple addresses. For example, replace the address
+ of an alias by the addresses listed under that alias.
+
+ * Determine how and where to deliver mail for a specific address. For
+ example, deliver mail for "username@example.com" with the smtp(8) delivery
+ agent, to the hosts that are listed in the DNS as the mail servers for the
+ domain "example.com".
+
+Although Postfix currently has no address rewriting language, it can do
+surprisingly powerful address manipulation via table lookup. Postfix typically
+uses lookup tables with fixed strings to map one address to one or multiple
+addresses, and typically uses regular expressions to map multiple addresses to
+one or multiple addresses. Fixed-string lookup tables may be in the form of
+local files, or in the form of NIS, LDAP or SQL databases. The DATABASE_README
+document gives an introduction to Postfix lookup tables.
+
+Topics covered in this document:
+
+ * To rewrite message headers or not, or to label as invalid
+ * Postfix address rewriting overview
+ * Address rewriting when mail is received
+
+ o Rewrite addresses to standard form
+ o Canonical address mapping
+ o Address masquerading
+ o Automatic BCC recipients
+ o Virtual aliasing
+
+ * Address rewriting when mail is delivered
+
+ o Resolve address to destination
+ o Mail transport switch
+ o Relocated users table
+
+ * Address rewriting with remote delivery
+
+ o Generic mapping for outgoing SMTP mail
+
+ * Address rewriting with local delivery
+
+ o Local alias database
+ o Local per-user .forward files
+ o Local catch-all address
+
+ * Debugging your address manipulations
+
+TToo rreewwrriittee mmeessssaaggee hheeaaddeerrss oorr nnoott,, oorr ttoo llaabbeell aass iinnvvaalliidd
+
+Postfix versions 2.1 and earlier always rewrite message header addresses, and
+append Postfix's own domain information to addresses that Postfix considers
+incomplete. While rewriting message header addresses is OK for mail with a
+local origin, it is undesirable for remote mail:
+
+ * Message header address rewriting is frowned upon by mail standards,
+ * Appending Postfix's own domain produces incorrect results with some
+ incomplete addresses,
+ * Appending Postfix's own domain sometimes creates the appearance that spam
+ is sent by local users.
+
+Postfix versions 2.2 give you the option to either not rewrite message headers
+from remote SMTP clients at all, or to label incomplete addresses in such
+message headers as invalid. Here is how it works:
+
+ * Postfix always rewrites message headers from local SMTP clients and from
+ the Postfix sendmail command, and appends its own domain to incomplete
+ addresses. The local_header_rewrite_clients parameter controls what SMTP
+ clients Postfix considers local (by default, only local network interface
+ addresses).
+ * Postfix never rewrites message header addresses from remote SMTP clients
+ when the remote_header_rewrite_domain parameter value is empty (the default
+ setting).
+ * Otherwise, Postfix rewrites message headers from remote SMTP clients, and
+ appends the remote_header_rewrite_domain value to incomplete addresses.
+ This feature can be used to append a reserved domain such as
+ "domain.invalid", so that incomplete addresses cannot be mistaken for local
+ addresses.
+
+PPoossttffiixx aaddddrreessss rreewwrriittiinngg oovveerrvviieeww
+
+The figure below zooms in on those parts of Postfix that are most involved with
+address rewriting activity. See the OVERVIEW document for an overview of the
+complete Postfix architecture. Names followed by a number are Postfix daemon
+programs, while unnumbered names represent Postfix queues or internal sources
+of mail messages.
+
+ trivial- trivial-
+ rewrite(8) rewrite(8)
+ (std form) (resolve)
+
+ ^ | ^ |
+ | v | v
+
+ smtpd(8) smtp(8)
+
+ qmqpd(8) >- cleanup(8) -> incoming -> active -> qmgr(8) -< lmtp(8)
+
+ pickup(8) local(8)
+
+ ^ ^ |
+ | | v
+
+ bounces
+ forwarding deferred
+ notices
+
+The table below summarizes all Postfix address manipulations. If you're reading
+this document for the first time, skip forward to "Address rewriting when mail
+is received". Once you've finished reading the remainder of this document, the
+table will help you to quickly find what you need.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |AAddddrreessss |SSccooppee |DDaaeemmoonn |GGlloobbaall ttuurrnn--oonn |SSeelleeccttiivvee ttuurrnn--ooffff ccoonnttrrooll |
+ |mmaanniippuullaattiioonn| | |ccoonnttrrooll | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Rewrite | |trivial-|append_at_myorigin, | |
+ |addresses to|all mail|rewrite |append_dot_mydomain,|local_header_rewrite_clients,|
+ |standard | |(8) |swap_bangpath, |remote_header_rewrite_domain |
+ |form | | |allow_percent_hack | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Canonical | |cleanup | |receive_override_options, |
+ |address |all mail|(8) |canonical_maps |local_header_rewrite_clients,|
+ |mapping | | | |remote_header_rewrite_domain |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Address | |cleanup | |receive_override_options, |
+ |masquerading|all mail|(8) |masquerade_domains |local_header_rewrite_clients,|
+ | | | | |remote_header_rewrite_domain |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Automatic | |cleanup |always_bcc, | |
+ |BCC |new mail|(8) |sender_bcc_maps, |receive_override_options |
+ |recipients | | |recipient_bcc_maps | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Virtual |all mail|cleanup |virtual_alias_maps |receive_override_options |
+ |aliasing | |(8) | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Resolve | |trivial-| | |
+ |address to |all mail|rewrite |none |none |
+ |destination | |(8) | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Mail | |trivial-| | |
+ |transport |all mail|rewrite |transport_maps |none |
+ |switch | |(8) | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Relocated | |trivial-| | |
+ |users table |all mail|rewrite |relocated_maps |none |
+ | | |(8) | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Generic |outgoing| | | |
+ |mapping |SMTP |smtp(8) |smtp_generic_maps |none |
+ |table |mail | | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Local alias |local | | | |
+ |database |mail |local(8)|alias_maps |none |
+ | |only | | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Local per- |local | | | |
+ |user |mail |local(8)|forward_path |none |
+ |.forward |only | | | |
+ |files | | | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Local catch-|local | | | |
+ |all address |mail |local(8)|luser_relay |none |
+ | |only | | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+AAddddrreessss rreewwrriittiinngg wwhheenn mmaaiill iiss rreecceeiivveedd
+
+The cleanup(8) server receives mail from outside of Postfix as well as mail
+from internal sources such as forwarded mail, undeliverable mail that is
+bounced to the sender, and postmaster notifications about problems with the
+mail system.
+
+The cleanup(8) server transforms the sender, recipients and message content
+into a standard form before writing it to an incoming queue file. The server
+cleans up sender and recipient addresses in message headers and in the
+envelope, adds missing message headers such as From: or Date: that are required
+by mail standards, and removes message headers such as Bcc: that should not be
+present. The cleanup(8) server delegates the more complex address manipulations
+to the trivial-rewrite(8) server as described later in this document.
+
+Address manipulations at this stage are:
+
+ * Rewrite addresses to standard form
+ * Canonical address mapping
+ * Address masquerading
+ * Automatic BCC recipients
+ * Virtual aliasing
+
+RReewwrriittee aaddddrreesssseess ttoo ssttaannddaarrdd ffoorrmm
+
+Before the cleanup(8) daemon runs an address through any address mapping lookup
+table, it first rewrites the address to the standard
+"user@fully.qualified.domain" form, by sending the address to the trivial-
+rewrite(8) daemon. The purpose of rewriting to standard form is to reduce the
+number of entries needed in lookup tables.
+
+The Postfix trivial-rewrite(8) daemon implements the following hard-coded
+address manipulations:
+
+ Rewrite "@hosta,@hostb:user@site" to "user@site"
+ In case you wonder what this is, the address form above is called a
+ route address, and specifies that mail for "user@site" be delivered via
+ "hosta" and "hostb". Usage of this form has been deprecated for a long
+ time. Postfix has no ability to handle route addresses, other than to
+ strip off the route part.
+
+ NOTE: Postfix versions 2.2 and later rewrite message headers from
+ remote SMTP clients only if the client matches the
+ local_header_rewrite_clients parameter, or if the
+ remote_header_rewrite_domain configuration parameter specifies a non-
+ empty value. To get the behavior before Postfix 2.2, specify
+ "local_header_rewrite_clients = static:all".
+
+ Rewrite "site!user" to "user@site"
+ This feature is controlled by the boolean swap_bangpath parameter
+ (default: yes). The purpose is to rewrite UUCP-style addresses to
+ domain style. This is useful only when you receive mail via UUCP, but
+ it probably does not hurt otherwise.
+
+ NOTE: Postfix versions 2.2 and later rewrite message headers from
+ remote SMTP clients only if the client matches the
+ local_header_rewrite_clients parameter, or if the
+ remote_header_rewrite_domain configuration parameter specifies a non-
+ empty value. To get the behavior before Postfix 2.2, specify
+ "local_header_rewrite_clients = static:all".
+
+ Rewrite "user%domain" to "user@domain"
+ This feature is controlled by the boolean allow_percent_hack parameter
+ (default: yes). Typically, this is used in order to deal with
+ monstrosities such as "user%domain@otherdomain".
+
+ NOTE: Postfix versions 2.2 and later rewrite message headers from
+ remote SMTP clients only if the client matches the
+ local_header_rewrite_clients parameter, or if the
+ remote_header_rewrite_domain configuration parameter specifies a non-
+ empty value. To get the behavior before Postfix 2.2, specify
+ "local_header_rewrite_clients = static:all".
+
+ Rewrite "user" to "user@$myorigin"
+ This feature is controlled by the boolean append_at_myorigin parameter
+ (default: yes). You should never turn off this feature, because a lot
+ of Postfix components expect that all addresses have the form
+ "user@domain".
+
+ NOTE: Postfix versions 2.2 and later rewrite message headers from
+ remote SMTP clients only if the client matches the
+ local_header_rewrite_clients parameter; otherwise they append the
+ domain name specified with the remote_header_rewrite_domain
+ configuration parameter, if one is specified. To get the behavior
+ before Postfix 2.2, specify "local_header_rewrite_clients = static:
+ all".
+
+ If your machine is not the main machine for $myorigin and you wish to
+ have some users delivered locally without going via that main machine,
+ make an entry in the virtual alias table that redirects
+ "user@$myorigin" to "user@$myhostname". See also the "delivering some
+ users locally" section in the STANDARD_CONFIGURATION_README document.
+
+ Rewrite "user@host" to "user@host.$mydomain"
+ This feature is controlled by the boolean append_dot_mydomain parameter
+ (default: yes). The purpose is to get consistent treatment of different
+ forms of the same hostname.
+
+ NOTE: Postfix versions 2.2 and later rewrite message headers from
+ remote SMTP clients only if the client matches the
+ local_header_rewrite_clients parameter; otherwise they append the
+ domain name specified with the remote_header_rewrite_domain
+ configuration parameter, if one is specified. To get the behavior
+ before Postfix 2.2, specify "local_header_rewrite_clients = static:
+ all".
+
+ Some will argue that rewriting "host" to "host.domain" is bad. That is
+ why it can be turned off. Others like the convenience of having
+ Postfix's own domain appended automatically.
+
+ Rewrite "user@site." to "user@site" (without the trailing dot).
+ A single trailing dot is silently removed. However, an address that
+ ends in multiple dots will be rejected as an invalid address.
+
+ NOTE: Postfix versions 2.2 and later rewrite message headers from
+ remote SMTP clients only if the client matches the
+ local_header_rewrite_clients parameter, or if the
+ remote_header_rewrite_domain configuration parameter specifies a non-
+ empty value. To get the behavior before Postfix 2.2, specify
+ "local_header_rewrite_clients = static:all".
+
+CCaannoonniiccaall aaddddrreessss mmaappppiinngg
+
+The cleanup(8) daemon uses the canonical(5) tables to rewrite addresses in
+message envelopes and in message headers. By default all header and envelope
+addresses are rewritten; this is controlled with the canonical_classes
+configuration parameter.
+
+NOTE: Postfix versions 2.2 and later rewrite message headers from remote SMTP
+clients only if the client matches the local_header_rewrite_clients parameter,
+or if the remote_header_rewrite_domain configuration parameter specifies a non-
+empty value. To get the behavior before Postfix 2.2, specify
+"local_header_rewrite_clients = static:all".
+
+Address rewriting is done for local and remote addresses. The mapping is useful
+to replace login names by "Firstname.Lastname" style addresses, or to clean up
+invalid domains in mail addresses produced by legacy mail systems.
+
+Canonical mapping is disabled by default. To enable, edit the canonical_maps
+parameter in the main.cf file and specify one or more lookup tables, separated
+by whitespace or commas.
+
+Example:
+
+ /etc/postfix/main.cf:
+ canonical_maps = hash:/etc/postfix/canonical
+
+ /etc/postfix/canonical:
+ wietse Wietse.Venema
+
+For static mappings as shown above, lookup tables such as hash:, ldap:, mysql:
+or pgsql: are sufficient. For dynamic mappings you can use regular expression
+tables. This requires that you become intimately familiar with the ideas
+expressed in regexp_table(5), pcre_table(5) and canonical(5).
+
+In addition to the canonical maps which are applied to both sender and
+recipient addresses, you can specify canonical maps that are applied only to
+sender addresses or to recipient addresses.
+
+Example:
+
+ /etc/postfix/main.cf:
+ sender_canonical_maps = hash:/etc/postfix/sender_canonical
+ recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
+
+The sender and recipient canonical maps are applied before the common canonical
+maps. The sender_canonical_classes and recipient_canonical_classes parameters
+control what addresses are subject to sender_canonical_maps and
+recipient_canonical_maps mappings, respectively.
+
+Sender-specific rewriting is useful when you want to rewrite ugly sender
+addresses to pretty ones, and still want to be able to send mail to the those
+ugly address without creating a mailer loop.
+
+Canonical mapping can be turned off selectively for mail received by smtpd(8),
+qmqpd(8), or pickup(8), by overriding main.cf settings in the master.cf file.
+This feature is available in Postfix version 2.1 and later.
+
+Example:
+
+ /etc/postfix/master.cf:
+ 127.0.0.1:10026 inet n - n - - smtpd
+ -o receive_override_options=no_address_mappings
+
+Note: do not specify whitespace around the "=" here.
+
+AAddddrreessss mmaassqquueerraaddiinngg
+
+Address masquerading is a method to hide hosts inside a domain behind their
+mail gateway, and to make it appear as if the mail comes from the gateway
+itself, instead of from individual machines.
+
+NOTE: Postfix versions 2.2 and later rewrite message headers from remote SMTP
+clients only if the client matches the local_header_rewrite_clients parameter,
+or if the remote_header_rewrite_domain configuration parameter specifies a non-
+empty value. To get the behavior before Postfix 2.2, specify
+"local_header_rewrite_clients = static:all".
+
+Address masquerading is disabled by default, and is implemented by the cleanup
+(8) server. To enable, edit the masquerade_domains parameter in the main.cf
+file and specify one or more domain names separated by whitespace or commas.
+When Postfix tries to masquerade a domain, it processes the list from left to
+right, and processing stops at the first match.
+
+Example:
+
+ /etc/postfix/main.cf:
+ masquerade_domains = foo.example.com example.com
+
+strips "any.thing.foo.example.com" to "foo.example.com", but strips
+"any.thing.else.example.com" to "example.com".
+
+A domain name prefixed with "!" means do not masquerade this domain or its
+subdomains:
+
+ /etc/postfix/main.cf:
+ masquerade_domains = !foo.example.com example.com
+
+does not change "any.thing.foo.example.com" and "foo.example.com", but strips
+"any.thing.else.example.com" to "example.com".
+
+The masquerade_exceptions configuration parameter specifies what user names
+should not be subjected to address masquerading. Specify one or more user names
+separated by whitespace or commas.
+
+Example:
+
+ /etc/postfix/main.cf:
+ masquerade_exceptions = root
+
+By default, Postfix makes no exceptions.
+
+Subtle point: by default, address masquerading is applied only to message
+headers and to envelope sender addresses, but not to envelope recipients. This
+allows you to use address masquerading on a mail gateway machine, while still
+being able to forward mail from outside to users on individual machines.
+
+In order to subject envelope recipient addresses to masquerading, too, specify
+(Postfix version 1.1 and later):
+
+ /etc/postfix/main.cf:
+ masquerade_classes = envelope_sender, envelope_recipient,
+ header_sender, header_recipient
+
+If you rewrite the envelope recipient like this, Postfix will no longer be able
+to send mail to individual machines.
+
+Address masquerading can be turned off selectively for mail received by smtpd
+(8), qmqpd(8), or pickup(8), by overriding main.cf settings in the master.cf
+file. This feature is available in Postfix version 2.1 and later.
+
+Example:
+
+ /etc/postfix/master.cf:
+ 127.0.0.1:10026 inet n - n - - smtpd
+ -o receive_override_options=no_address_mappings
+
+Note: do not specify whitespace around the "=" here.
+
+AAuuttoommaattiicc BBCCCC rreecciippiieennttss
+
+After applying the canonical and masquerade mappings, the cleanup(8) daemon can
+generate optional BCC (blind carbon-copy) recipients. Postfix provides three
+mechanisms:
+
+ always_bcc = address
+ Deliver a copy of all mail to the specified address. In Postfix
+ versions before 2.1, this feature is implemented by smtpd(8), qmqpd(8),
+ or pickup(8).
+ sender_bcc_maps = type:table
+ Search the specified "type:table" lookup table with the envelope sender
+ address for an automatic BCC address. This feature is available in
+ Postfix 2.1 and later.
+ recipient_bcc_maps = type:table
+ Search the specified "type:table" lookup table with the envelope
+ recipient address for an automatic BCC address. This feature is
+ available in Postfix 2.1 and later.
+
+Note: automatic BCC recipients are produced only for new mail. To avoid mailer
+loops, automatic BCC recipients are not generated for mail that Postfix
+forwards internally, nor for mail that Postfix generates itself.
+
+Automatic BCC recipients (including always_bcc) can be turned off selectively
+for mail received by smtpd(8), qmqpd(8), or pickup(8), by overriding main.cf
+settings in the master.cf file. This feature is available in Postfix version
+2.1 and later.
+
+Example:
+
+ /etc/postfix/master.cf:
+ 127.0.0.1:10026 inet n - n - - smtpd
+ -o receive_override_options=no_address_mappings
+
+Note: do not specify whitespace around the "=" here.
+
+VViirrttuuaall aalliiaassiinngg
+
+Before writing the recipients to the queue file, the cleanup(8) daemon uses the
+optional virtual(5) alias tables to redirect mail for recipients. The mapping
+affects only envelope recipient addresses; it has no effect on message headers
+or envelope sender addresses. Virtual alias lookups are useful to redirect mail
+for virtual alias domains to real user mailboxes, and to redirect mail for
+domains that no longer exist. Virtual alias lookups can also be used to
+transform " Firstname.Lastname " back into UNIX login names, although it seems
+that local aliases may be a more appropriate vehicle. See the VIRTUAL_README
+document for an overview of methods to host virtual domains with Postfix.
+
+Virtual aliasing is disabled by default. To enable, edit the virtual_alias_maps
+parameter in the main.cf file and specify one or more lookup tables, separated
+by whitespace or commas.
+
+Example:
+
+ /etc/postfix/main.cf:
+ virtual_alias_maps = hash:/etc/postfix/virtual
+
+ /etc/postfix/virtual:
+ Wietse.Venema wietse
+
+Addresses found in virtual alias maps are subjected to another iteration of
+virtual aliasing, but are not subjected to canonical mapping, in order to avoid
+loops.
+
+For static mappings as shown above, lookup tables such as hash:, ldap:, mysql:
+or pgsql: are sufficient. For dynamic mappings you can use regular expression
+tables. This requires that you become intimately familiar with the ideas
+expressed in regexp_table(5), pcre_table(5) and virtual(5).
+
+Virtual aliasing can be turned off selectively for mail received by smtpd(8),
+qmqpd(8), or pickup(8), by overriding main.cf settings in the master.cf file.
+This feature is available in Postfix version 2.1 and later.
+
+Example:
+
+ /etc/postfix/master.cf:
+ 127.0.0.1:10026 inet n - n - - smtpd
+ -o receive_override_options=no_address_mappings
+
+Note: do not specify whitespace around the "=" here.
+
+At this point the message is ready to be stored into the Postfix incoming
+queue.
+
+AAddddrreessss rreewwrriittiinngg wwhheenn mmaaiill iiss ddeelliivveerreedd
+
+The Postfix queue manager sorts mail according to its destination and gives it
+to Postfix delivery agents such as local(8), smtp(8), or lmtp(8). Just like the
+cleanup(8) server, the Postfix queue manager delegates the more complex address
+manipulations to the trivial-rewrite(8) server.
+
+Address manipulations at this stage are:
+
+ * Resolve address to destination
+ * Mail transport switch
+ * Relocated users table
+
+Each Postfix delivery agent tries to deliver the mail to its destination, while
+encapsulating the sender, recipients, and message content according to the
+rules of the SMTP, LMTP, etc. protocol. When mail cannot be delivered, it is
+either returned to the sender or moved to the deferred queue and tried again
+later.
+
+Address manipulations when mail is delivered via the smtp(8) delivery agent:
+
+ * Generic mapping for outgoing SMTP mail
+
+Address manipulations when mail is delivered via the local(8) delivery agent:
+
+ * Local alias database
+ * Local per-user .forward files
+ * Local catch-all address
+
+The remainder of this document presents each address manipulation step in more
+detail, with specific examples or with pointers to documentation with examples.
+
+RReessoollvvee aaddddrreessss ttoo ddeessttiinnaattiioonn
+
+The Postfix qmgr(8) queue manager selects new mail from the incoming queue or
+old mail from the deferred queue, and asks the trivial-rewrite(8) address
+rewriting and resolving daemon where it should be delivered.
+
+As of version 2.0, Postfix distinguishes four major address classes. Each class
+has its own list of domain names, and each class has its own default delivery
+method, as shown in the table below. See the ADDRESS_CLASS_README document for
+the fine details. Postfix versions before 2.0 only distinguish between local
+delivery and everything else.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |DDeessttiinnaattiioonn ddoommaaiinn lliisstt |DDeeffaauulltt ddeelliivveerryy mmeetthhoodd|AAvvaaiillaabbiilliittyy|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |$mydestination, $inet_interfaces,|$local_transport |Postfix 1.0 |
+ |$proxy_interfaces | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |$virtual_mailbox_domains |$virtual_transport |Postfix 2.0 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |$relay_domains |$relay_transport |Postfix 2.0 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |none |$default_transport |Postfix 1.0 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+
+MMaaiill ttrraannssppoorrtt sswwiittcchh
+
+Once the trivial-rewrite(8) daemon has determined a default delivery method it
+searches the optional transport(5) table for information that overrides the
+message destination and/or delivery method. Typical use of the transport(5)
+table is to send mail to a system that is not connected to the Internet, or to
+use a special SMTP client configuration for destinations that have special
+requirements. See, for example, the STANDARD_CONFIGURATION_README and
+UUCP_README documents, and the examples in the transport(5) manual page.
+
+Transport table lookups are disabled by default. To enable, edit the
+transport_maps parameter in the main.cf file and specify one or more lookup
+tables, separated by whitespace or commas.
+
+Example:
+
+ /etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+
+RReellooccaatteedd uusseerrss ttaabbllee
+
+Next, the trivial-rewrite(8) address rewriting and resolving daemon runs each
+recipient through the relocated(5) database. This table provides information on
+how to reach users that no longer have an account, or what to do with mail for
+entire domains that no longer exist. When mail is sent to an address that is
+listed in this table, the message is returned to the sender with an informative
+message.
+
+The relocated(5) database is searched after transport(5) table lookups, in
+anticipation of transport(5) tables that can replace one recipient address by a
+different one.
+
+Lookups of relocated users are disabled by default. To enable, edit the
+relocated_maps parameter in the main.cf file and specify one or more lookup
+tables, separated by whitespace or commas.
+
+Example:
+
+ /etc/postfix/main.cf:
+ relocated_maps = hash:/etc/postfix/relocated
+
+ /etc/postfix/relocated:
+ username@example.com otheruser@elsewhere.tld
+
+As of Postfix version 2, mail for a relocated user will be rejected by the SMTP
+server with the reason "user has moved to otheruser@elsewhere.tld". Older
+Postfix versions will receive the mail first, and then return it to the sender
+as undeliverable, with the same reason.
+
+GGeenneerriicc mmaappppiinngg ffoorr oouuttggooiinngg SSMMTTPP mmaaiill
+
+Some hosts have no valid Internet domain name, and instead use a name such as
+localdomain.local. This can be a problem when you want to send mail over the
+Internet, because many mail servers reject mail addresses with invalid domain
+names.
+
+With the smtp_generic_maps parameter you can specify generic(5) lookup tables
+that replace local mail addresses by valid Internet addresses when mail leaves
+the machine via SMTP. The generic(5) mapping replaces envelope and header
+addresses, and is non-recursive. It does not happen when you send mail between
+addresses on the local machine.
+
+This feature is available in Postfix version 2.2 and later.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_generic_maps = hash:/etc/postfix/generic
+
+ /etc/postfix/generic:
+ his@localdomain.local hisaccount@hisisp.example
+ her@localdomain.local heraccount@herisp.example
+ @localdomain.local hisaccount+local@hisisp.example
+
+When mail is sent to a remote host via SMTP, this replaces
+his@localdomain.local by his ISP mail address, replaces her@localdomain.local
+by her ISP mail address, and replaces other local addresses by his ISP account,
+with an address extension of +local (this example assumes that the ISP supports
+"+" style address extensions).
+
+LLooccaall aalliiaass ddaattaabbaassee
+
+When mail is to be delivered locally, the local(8) delivery agent runs each
+local recipient name through the aliases(5) database. The mapping does not
+affect addresses in message headers. Local aliases are typically used to
+implement distribution lists, or to direct mail for standard aliases such as
+postmaster to real people. The table can also be used to map
+"Firstname.Lastname" addresses to login names.
+
+Alias lookups are enabled by default. The default configuration depends on the
+operating system environment, but it is typically one of the following:
+
+ /etc/postfix/main.cf:
+ alias_maps = hash:/etc/aliases
+ alias_maps = dbm:/etc/aliases, nis:mail.aliases
+
+The pathname of the alias database file is controlled with the alias_database
+configuration parameter. The value is system dependent. Usually it is one of
+the following:
+
+ /etc/postfix/main.cf:
+ alias_database = hash:/etc/aliases (4.4BSD, LINUX)
+ alias_database = dbm:/etc/aliases (4.3BSD, SYSV<4)
+ alias_database = dbm:/etc/mail/aliases (SYSV4)
+
+An aliases(5) file can specify that mail should be delivered to a local file,
+or to a command that receives the message in the standard input stream. For
+security reasons, deliveries to command and file destinations are performed
+with the rights of the alias database owner. A default userid, default_privs,
+is used for deliveries to commands or files in "root"-owned aliases.
+
+LLooccaall ppeerr--uusseerr ..ffoorrwwaarrdd ffiilleess
+
+With delivery via the local(8) deliver agent, users can control their own mail
+delivery by specifying destinations in a file called .forward in their home
+directories. The syntax of these files is the same as with the local aliases(5)
+file, except that the left-hand side of the alias (lookup key and colon) are
+not present.
+
+LLooccaall ccaattcchh--aallll aaddddrreessss
+
+When the local(8) delivery agent finds that a message recipient does not exist,
+the message is normally returned to the sender ("user unknown"). Sometimes it
+is desirable to forward mail for non-existing recipients to another machine.
+For this purpose you can specify an alternative destination with the
+luser_relay configuration parameter.
+
+Alternatively, mail for non-existent recipients can be delegated to an entirely
+different message transport, as specified with the fallback_transport
+configuration parameter. For details, see the local(8) delivery agent
+documentation.
+
+Note: if you use the luser_relay feature in order to receive mail for non-UNIX
+accounts, then you must specify:
+
+ /etc/postfix/main.cf:
+ local_recipient_maps =
+
+(i.e. empty) in the main.cf file, otherwise the Postfix SMTP server will reject
+mail for non-UNIX accounts with "User unknown in local recipient table". See
+the LOCAL_RECIPIENT_README file for more information on this.
+
+luser_relay can specify one address. It is subjected to "$name" expansions.
+Examples:
+
+ $user@other.host
+ The bare username, without address extension, is prepended to
+ "@other.host". For example, mail for "username+foo" is sent to
+ "username@other.host".
+
+ $local@other.host
+ The entire original recipient localpart, including address extension,
+ is prepended to "@other.host". For example, mail for "username+foo" is
+ sent to "username+foo@other.host".
+
+ sysadmin+$user
+ The bare username, without address extension, is appended to
+ "sysadmin". For example, mail for "username+foo" is sent to
+ "sysadmin+username".
+
+ sysadmin+$local
+ The entire original recipient localpart, including address extension,
+ is appended to "sysadmin". For example, mail for "username+foo" is sent
+ to "sysadmin+username+foo".
+
+DDeebbuuggggiinngg yyoouurr aaddddrreessss mmaanniippuullaattiioonnss
+
+Postfix version 2.1 and later can produce mail delivery reports for debugging
+purposes. These reports not only show sender/recipient addresses after address
+rewriting and alias expansion or forwarding, they also show information about
+delivery to mailbox, delivery to non-Postfix command, responses from remote
+SMTP servers, and so on.
+
+Postfix can produce two types of mail delivery reports for debugging:
+
+ * What-if: report what would happen, but do not actually deliver mail. This
+ mode of operation is requested with:
+
+ $ //uussrr//ssbbiinn//sseennddmmaaiill --bbvv aaddddrreessss......
+ Mail Delivery Status Report will be mailed to .
+
+ * What happened: deliver mail and report successes and/or failures, including
+ replies from remote SMTP servers. This mode of operation is requested with:
+
+ $ //uussrr//ssbbiinn//sseennddmmaaiill --vv aaddddrreessss......
+ Mail Delivery Status Report will be mailed to .
+
+These reports contain information that is generated by Postfix delivery agents.
+Since these run as daemon processes and do not interact with users directly,
+the result is sent as mail to the sender of the test message. The format of
+these reports is practically identical to that of ordinary non-delivery
+notifications.
+
+As an example, below is the delivery report that is produced with the command
+"sendmail -bv postfix-users@postfix.org". The first part of the report contains
+human-readable text. In this case, mail would be delivered via mail.cloud9.net,
+and the SMTP server replies with "250 Ok". Other reports may show delivery to
+mailbox, or delivery to non-Postfix command.
+
+ Content-Description: Notification
+ Content-Type: text/plain
+
+ This is the mail system at host spike.porcupine.org.
+
+ Enclosed is the mail delivery report that you requested.
+
+ The mail system
+
+ : delivery via mail.cloud9.net[168.100.1.4]: 250
+ 2.1.5 Ok
+
+The second part of the report is in machine-readable form, and includes the
+following information:
+
+ * The envelope sender address (wietse@porcupine.org).
+ * The envelope recipient address (postfix-users@postfix.org). If the
+ recipient address was changed by Postfix then Postfix also includes the
+ original recipient address.
+ * The delivery status.
+
+Some details depend on Postfix version. The example below is for Postfix
+version 2.3 and later.
+
+ Content-Description: Delivery report
+ Content-Type: message/delivery-status
+
+ Reporting-MTA: dns; spike.porcupine.org
+ X-Postfix-Queue-ID: 84863BC0E5
+ X-Postfix-Sender: rfc822; wietse@porcupine.org
+ Arrival-Date: Sun, 26 Nov 2006 17:01:01 -0500 (EST)
+
+ Final-Recipient: rfc822; postfix-users@postfix.org
+ Action: deliverable
+ Status: 2.1.5
+ Remote-MTA: dns; mail.cloud9.net
+ Diagnostic-Code: smtp; 250 2.1.5 Ok
+
+The third part of the report contains the message that Postfix would have
+delivered, including From: and To: message headers, so that you can see any
+effects of address rewriting on those. Mail submitted with "sendmail -bv" has
+no body content so none is shown in the example below.
+
+ Content-Description: Message
+ Content-Type: message/rfc822
+
+ Received: by spike.porcupine.org (Postfix, from userid 1001)
+ id 84863BC0E5; Sun, 26 Nov 2006 17:01:01 -0500 (EST)
+ Subject: probe
+ To: postfix-users@postfix.org
+ Message-Id: <20061126220101.84863BC0E5@spike.porcupine.org>
+ Date: Sun, 26 Nov 2006 17:01:01 -0500 (EST)
+ From: wietse@porcupine.org (Wietse Venema)
+
diff --git a/README_FILES/ADDRESS_VERIFICATION_README b/README_FILES/ADDRESS_VERIFICATION_README
new file mode 100644
index 0000000..1374a8a
--- /dev/null
+++ b/README_FILES/ADDRESS_VERIFICATION_README
@@ -0,0 +1,442 @@
+PPoossttffiixx AAddddrreessss VVeerriiffiiccaattiioonn HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+WWAARRNNIINNGG
+
+Recipient address verification may cause an increased load on down-stream
+servers in the case of a dictionary attack or a flood of backscatter bounces.
+Sender address verification may cause your site to be blacklisted by some
+providers. See also the "Limitations" section below for more.
+
+WWhhaatt PPoossttffiixx aaddddrreessss vveerriiffiiccaattiioonn ccaann ddoo ffoorr yyoouu
+
+Address verification is a feature that allows the Postfix SMTP server to block
+a sender (MAIL FROM) or recipient (RCPT TO) address until the address has been
+verified to be deliverable.
+
+The technique has obvious uses to reject junk mail with an unreplyable sender
+address.
+
+The technique is also useful to block mail for undeliverable recipients, for
+example on a mail relay host that does not have a list of all the valid
+recipient addresses. This prevents undeliverable junk mail from entering the
+queue, so that Postfix doesn't have to waste resources trying to send MAILER-
+DAEMON messages back.
+
+This feature is available in Postfix version 2.1 and later.
+
+Topics covered in this document:
+
+ * How address verification works
+ * Limitations of address verification
+ * Recipient address verification
+ * Sender address verification for mail from frequently forged domains
+ * Sender address verification for all email
+ * Address verification database
+ * Managing the address verification database
+ * Controlling the routing of address verification probes
+ * Forced probe routing examples
+ * Limitations of forced probe routing
+
+HHooww aaddddrreessss vveerriiffiiccaattiioonn wwoorrkkss
+
+A Postfix MTA verifies a sender or recipient address by probing the preferred
+MTAs for that address, without actually delivering mail. The preferred MTAs
+could include the Postfix MTA itself, or some remote MTAs (SMTP interruptus).
+Probe messages are like normal mail, except that they are never delivered,
+deferred or bounced; probe messages are always discarded.
+
+
+ probe Postfix
+ message -> mail
+ queue
+ Postfix Postfix ->
+ Internet -> SMTP <-> verify
+ server server |
+ v
+
+ <- Postfix
+ probe <- delivery -> Local
+ status agents -> Remote
+ ^
+ |
+ v
+
+
+ Address
+ verification
+ database
+
+With Postfix address verification turned on, normal mail will suffer only a
+short delay of up to 6 seconds while an address is being verified for the first
+time. Once an address status is known, the status is cached and Postfix replies
+immediately.
+
+When verification takes too long the Postfix SMTP server defers the sender or
+recipient address with a 450 reply. Normal mail clients will connect again
+after some delay. The address verification delay is configurable with the
+main.cf address_verify_poll_count and address_verify_poll_delay parameters. See
+postconf(5) for details.
+
+LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffiiccaattiioonn
+
+ * Postfix assumes that a remote SMTP server will reject unknown addresses in
+ reply to the RCPT TO command. However, some sites report this in reply to
+ the DATA command. For such sites you may configure a workaround with the
+ smtp_address_verify_target parameter (Postfix 3.0 and later).
+
+ * When verifying a remote address, Postfix probes the preferred MTAs for that
+ address, without actually delivering mail. If a preferred MTA accepts the
+ address, then Postfix assumes that the address is deliverable. In reality,
+ mail for a remote address can bounce AFTER a preferred MTA accepts the
+ recipient address, or AFTER a preferred MTA accepts the message content.
+
+ * Some sites may blacklist you when you are probing them too often (a probe
+ is an SMTP session that does not deliver mail), or when you are probing
+ them too often for a non-existent address. This is one reason why you
+ should use sender address verification sparingly, if at all, when your site
+ receives lots of email.
+
+ * Normally, address verification probe messages follow the same path as
+ regular mail. However, some sites send mail to the Internet via an
+ intermediate relayhost; this breaks address verification. See below,
+ section "Controlling the routing of address verification probes", for how
+ to override mail routing and for possible limitations when you have to do
+ this.
+
+ * Postfix assumes that an address is undeliverable when a preferred MTA for
+ the address rejects the probe, regardless of the reason for rejection
+ (client rejected, HELO rejected, MAIL FROM rejected, etc.). Thus, Postfix
+ rejects an address when a preferred MTA for that address rejects mail from
+ your machine for any reason. This is not a limitation, but it is mentioned
+ here just in case people believe that it is a limitation.
+
+ * Unfortunately, some sites do not reject unknown addresses in reply to the
+ RCPT TO or DATA command, but instead report a delivery failure in response
+ to end of DATA after a message is transferred. Postfix address verification
+ does not work with such sites.
+
+ * By default, Postfix probe messages have a sender address "double-
+ bounce@$myorigin" (with Postfix versions before 2.5, the default is
+ "postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does
+ not reject mail for this address.
+
+ You can change the probe sender address into the null address
+ ("address_verify_sender ="). This is UNSAFE because address probes will
+ fail with mis-configured sites that reject MAIL FROM: <>, while probes from
+ "double-bounce@$myorigin" would succeed.
+
+ * The downside of using a non-empty sender address is that the address may
+ end op on spammer mailing lists. Although Postfix always discards mail to
+ the double-bounce address, this still results in wasted network bandwidth
+ and server capacity. To defeat address harvesting, Postfix 2.9 and later
+ support time-dependent sender addresses when you specify a non-zero
+ address_verify_sender_ttl value.
+
+RReecciippiieenntt aaddddrreessss vveerriiffiiccaattiioonn
+
+As mentioned earlier, recipient address verification is useful to block mail
+for undeliverable recipients on a mail relay host that does not have a list of
+all valid recipient addresses. This can help to prevent the mail queue from
+filling up with MAILER-DAEMON messages.
+
+Recipient address verification is relatively straightforward and there are no
+surprises. If a recipient probe fails, then Postfix rejects mail for the
+recipient address. If a recipient probe succeeds, then Postfix accepts mail for
+the recipient address. However, recipient address verification probes can
+increase the load on down-stream MTAs when you're being flooded by backscatter
+bounces, or when some spammer is mounting a dictionary attack.
+
+By default, address verification results are saved in a persistent database
+(Postfix version 2.7 and later; with earlier versions, specify the database in
+main.cf as described later). The persistent database helps to avoid probing the
+same address repeatedly.
+
+ /etc/postfix/main.cf:
+ smtpd_recipient_restrictions =
+ permit_mynetworks
+ # reject_unauth_destination is not needed here if the mail
+ # relay policy is specified under smtpd_relay_restrictions
+ # (available with Postfix 2.10 and later).
+ reject_unauth_destination
+ ...
+ reject_unknown_recipient_domain
+ reject_unverified_recipient
+ ...
+ # Postfix 2.6 and later privacy feature.
+ # unverified_recipient_reject_reason = Address lookup failed
+
+The "reject_unknown_recipient_domain" restriction blocks mail for non-existent
+domains. Putting this before "reject_unverified_recipient" avoids the overhead
+of generating unnecessary probe messages.
+
+The unverified_recipient_reject_code parameter (default 450) specifies the
+numerical Postfix SMTP server reply code when a recipient address is known to
+bounce. Change this setting into 550 when you trust Postfix's judgments.
+
+The following features are available in Postfix 2.6 and later.
+
+The unverified_recipient_defer_code parameter (default 450) specifies the
+numerical Postfix SMTP server reply code when a recipient address probe fails
+with some temporary error. Some sites insist on changing this into 250. NOTE:
+This change turns MX servers into backscatter sources when the load is high.
+
+The unverified_recipient_reject_reason parameter (default: empty) specifies
+fixed text that Postfix will send to remote SMTP clients, instead of sending
+actual address verification details. Do not specify the SMTP status code or
+enhanced status code.
+
+The unverified_recipient_tempfail_action parameter (default: defer_if_permit)
+specifies the Postfix SMTP server action when a recipient address verification
+probe fails with some temporary error.
+
+SSeennddeerr aaddddrreessss vveerriiffiiccaattiioonn ffoorr mmaaiill ffrroomm ffrreeqquueennttllyy ffoorrggeedd ddoommaaiinnss
+
+Only for very small sites, it is relatively safe to turn on sender address
+verification for specific domains that often appear in forged email.
+
+ /etc/postfix/main.cf:
+ smtpd_sender_restrictions = hash:/etc/postfix/sender_access
+ unverified_sender_reject_code = 550
+ # Postfix 2.6 and later.
+ # unverified_sender_defer_code = 250
+
+ # Default setting for Postfix 2.7 and later.
+ # Note 1: Be sure to read the "Caching" section below!
+ # Note 2: Avoid hash files here. Use btree or lmdb instead.
+ address_verify_map = btree:/var/lib/postfix/verify
+
+ /etc/postfix/sender_access:
+ # Don't do this when you handle lots of email.
+ aol.com reject_unverified_sender
+ hotmail.com reject_unverified_sender
+ bigfoot.com reject_unverified_sender
+ ... etcetera ...
+
+At some point in cyberspace/time, a list of frequently forged MAIL FROM domains
+could be found at http://www.monkeys.com/anti-spam/filtering/sender-domain-
+validate.in.
+
+NOTE: One of the first things you might want to do is to turn on sender address
+verification for all your own domains.
+
+SSeennddeerr aaddddrreessss vveerriiffiiccaattiioonn ffoorr aallll eemmaaiill
+
+Unfortunately, sender address verification cannot simply be turned on for all
+email - you are likely to lose legitimate mail from mis-configured systems. You
+almost certainly will have to set up white lists for specific addresses, or
+even for entire domains.
+
+To find out how sender address verification would affect your mail, specify
+"warn_if_reject reject_unverified_sender" so that you can see what mail would
+be blocked:
+
+ /etc/postfix/main.cf:
+ smtpd_sender_restrictions =
+ permit_mynetworks
+ ...
+ check_sender_access hash:/etc/postfix/sender_access
+ reject_unknown_sender_domain
+ warn_if_reject reject_unverified_sender
+ ...
+ # Postfix 2.6 and later.
+ # unverified_sender_reject_reason = Address verification failed
+
+ # Default setting for Postfix 2.7 and later.
+ # Note 1: Be sure to read the "Caching" section below!
+ # Note 2: Avoid hash files here. Use btree or lmdb instead.
+ address_verify_map = btree:/var/lib/postfix/verify
+
+This is also a good way to populate your cache with address verification
+results before you start to actually reject mail.
+
+The sender_access restriction is needed to whitelist domains or addresses that
+are known to be OK. Although Postfix will not mark a known-to-be-good address
+as bad after a probe fails, it is better to be safe than sorry.
+
+NOTE: You will have to whitelist sites such as securityfocus.com and other
+sites that operate mailing lists that use a different sender address for each
+posting (VERP). Such addresses pollute the address verification cache quickly,
+and generate unnecessary sender verification probes.
+
+ /etc/postfix/sender_access
+ securityfocus.com OK
+ ...
+
+The "reject_unknown_sender_domain" restriction blocks mail from non-existent
+domains. Putting this before "reject_unverified_sender" avoids the overhead of
+generating unnecessary probe messages.
+
+The unverified_sender_reject_code parameter (default 450) specifies the
+numerical Postfix server reply code when a sender address is known to bounce.
+Change this setting into 550 when you trust Postfix's judgments.
+
+The following features are available in Postfix 2.6 and later.
+
+The unverified_sender_defer_code parameter (default 450) specifies the
+numerical Postfix SMTP server reply code when a sender address verification
+probe fails with some temporary error. Specify a valid 2xx or 4xx code.
+
+The unverified_sender_reject_reason parameter (default: empty) specifies fixed
+text that Postfix will send to remote SMTP clients, instead of sending actual
+address verification details. Do not specify the SMTP status code or enhanced
+status code.
+
+The unverified_sender_tempfail_action parameter (default: defer_if_permit)
+specifies the Postfix SMTP server action when a sender address verification
+probe fails with some temporary error.
+
+AAddddrreessss vveerriiffiiccaattiioonn ddaattaabbaassee
+
+To improve performance, the Postfix verify(8) daemon can save address
+verification results to a persistent database. This is enabled by default with
+Postfix 2.7 and later. The address_verify_map (NOTE: singular) configuration
+parameter specifies persistent storage for sender or recipient address
+verification results. If you specify an empty value, all address verification
+results are lost after "postfix reload" or "postfix stop".
+
+ # Example 1: Default setting for Postfix 2.7 and later.
+ # Note: avoid hash files here. Use btree or lmdb instead.
+ /etc/postfix/main.cf:
+ address_verify_map = btree:$data_directory/verify_cache
+
+ # Example 2: Shared persistent lmdb: cache (Postfix 2.11 or later).
+ # Disable automatic cache cleanup in all Postfix instances except
+ # for one instance that will be responsible for cache cleanup.
+ /etc/postfix/main.cf:
+ address_verify_map = lmdb:$data_directory/verify_cache
+ # address_verify_cache_cleanup_interval = 0
+
+ # Example 3: Shared persistent btree: cache (Postfix 2.9 or later).
+ # Disable automatic cache cleanup in all Postfix instances except
+ # for one instance that will be responsible for cache cleanup.
+ /etc/postfix/main.cf:
+ address_verify_map = proxy:btree:$data_directory/verify_cache
+ # address_verify_cache_cleanup_interval = 0
+
+ # Example 4: Shared memory cache (requires Postfix 2.9 or later).
+ # Disable automatic cache cleanup in all Postfix instances.
+ # See memcache_table(5) for details.
+ /etc/postfix/main.cf:
+ address_verify_map = memcache:/etc/postfix/verify-memcache.cf
+ address_verify_cache_cleanup_interval = 0
+
+ # Example 5: Default setting for Postfix 2.6 and earlier.
+ # This uses non-persistent storage only.
+ /etc/postfix/main.cf:
+ address_verify_map =
+
+NOTE 1: The database file should be stored under a Postfix-owned directory,
+such as $data_directory.
+
+ As of version 2.5, Postfix no longer uses root privileges when opening this
+ file. To maintain backwards compatibility, an attempt to open the file
+ under a non-Postfix directory is redirected to the Postfix-owned
+ data_directory, and a warning is logged. If you wish to continue using a
+ pre-existing database file, change its file ownership to the account
+ specified with the mail_owner parameter, and either move the file to the
+ data_directory, or move it to some other Postfix-owned directory.
+
+NOTE 2: Do not put this file in a file system that may run out of space. When
+the address verification table gets corrupted the world comes to an end and YOU
+will have to MANUALLY fix things as described in the next section. Meanwhile,
+you will not receive mail via SMTP.
+
+NOTE 3: The verify(8) daemon will create a new database when none exists. It
+will open or create the file before entering the chroot jail.
+
+MMaannaaggiinngg tthhee aaddddrreessss vveerriiffiiccaattiioonn ddaattaabbaassee
+
+The verify(8) manual page describes parameters that control how long address
+verification results are cached before they need to be refreshed, and how long
+results can remain "unrefreshed" before they expire. Postfix uses different
+controls for positive results (address was accepted) and for negative results
+(address was rejected, or address verification failed for some other reason).
+
+The verify(8) daemon will periodically remove expired entries from the address
+verification database, and log the number of entries retained and dropped
+(Postfix versions 2.7 and later). A cleanup run is logged as "partial" when the
+daemon terminates early because of "postfix reload, "postfix stop", or because
+the daemon received no requests for $max_idle seconds. Postfix versions 2.6 and
+earlier do not implement automatic address verification database cleanup.
+There, the database is managed manually as described next.
+
+When the address verification database file becomes too big, or when it becomes
+corrupted, the solution is to manually rename or delete (NOT: truncate) the
+file and run "postfix reload". The verify(8) daemon will then create a new
+database file.
+
+CCoonnttrroolllliinngg tthhee rroouuttiinngg ooff aaddddrreessss vveerriiffiiccaattiioonn pprroobbeess
+
+By default, Postfix sends address verification probe messages via the same
+route as regular mail, because that normally produces the most accurate result.
+It's no good to verify a local address by connecting to your own SMTP port;
+that just triggers all kinds of mailer loop alarms. The same is true for any
+destination that your machine is best MX host for: hidden domains, virtual
+domains, etc.
+
+However, some sites have a complex infrastructure where mail is not sent
+directly to the Internet, but is instead given to an intermediate relayhost.
+This is a problem for address verification, because remote Internet addresses
+can be verified only when Postfix can access remote destinations directly.
+
+For this reason, Postfix allows you to override the routing parameters when it
+delivers an address verification probe message.
+
+First, the address_verify_relayhost parameter allows you to override the
+relayhost setting, and the address_verify_transport_maps parameter allows you
+to override the transport_maps setting. The
+address_verify_sender_dependent_relayhost_maps parameter does the same for
+sender-dependent relayhost selection.
+
+Second, each address class is given its own address verification version of the
+message delivery transport, as shown in the table below. Address classes are
+defined in the ADDRESS_CLASS_README file.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |DDoommaaiinn lliisstt |RReegguullaarr ttrraannssppoorrtt|VVeerriiffyy ttrraannssppoorrtt |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |mydestination |local_transport |address_verify_local_transport |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |virtual_alias_domains |(not applicable) |(not applicable) |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |virtual_mailbox_domains|virtual_transport|address_verify_virtual_transport|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |relay_domains |relay_transport |address_verify_relay_transport |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |(not applicable) |default_transport|address_verify_default_transport|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+By default, the parameters that control delivery of address probes have the
+same value as the parameters that control normal mail delivery.
+
+FFoorrcceedd pprroobbee rroouuttiinngg eexxaammpplleess
+
+In a typical scenario one would override the relayhost setting for address
+verification probes and leave everything else alone:
+
+ /etc/postfix/main.cf:
+ relayhost = $mydomain
+ address_verify_relayhost =
+ ...
+
+Sites behind a network address translation box might have to use a different
+SMTP client that sends the correct hostname information:
+
+ /etc/postfix/main.cf:
+ relayhost = $mydomain
+ address_verify_relayhost =
+ address_verify_default_transport = direct_smtp
+
+ /etc/postfix/master.cf:
+ direct_smtp .. .. .. .. .. .. .. .. .. smtp
+ -o smtp_helo_name=nat.box.tld
+
+LLiimmiittaattiioonnss ooff ffoorrcceedd pprroobbee rroouuttiinngg
+
+Inconsistencies can happen when probe messages don't follow the same path as
+regular mail. For example, a message can be accepted when it follows the
+regular route while an otherwise identical probe message is rejected when it
+follows the forced route. The opposite can happen, too, but is less likely.
+
diff --git a/README_FILES/BACKSCATTER_README b/README_FILES/BACKSCATTER_README
new file mode 100644
index 0000000..2870d11
--- /dev/null
+++ b/README_FILES/BACKSCATTER_README
@@ -0,0 +1,280 @@
+PPoossttffiixx BBaacckkssccaatttteerr HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document describes features that require Postfix version 2.0 or later.
+
+Topics covered in this document:
+
+ * What is backscatter mail?
+ * How do I block backscatter mail to random recipient addresses?
+ * How do I block backscatter mail to real recipient addresses?
+
+ o Blocking backscatter mail with forged mail server information
+ o Blocking backscatter mail with forged sender information
+ o Blocking backscatter mail with other forged information
+ o Blocking backscatter mail from virus scanners
+
+The examples use Perl Compatible Regular Expressions (Postfix pcre: tables),
+but also provide a translation to POSIX regular expressions (Postfix regexp:
+tables). PCRE is preferred primarily because the implementation is often
+faster.
+
+WWhhaatt iiss bbaacckkssccaatttteerr mmaaiill??
+
+When a spammer or worm sends mail with forged sender addresses, innocent sites
+are flooded with undeliverable mail notifications. This is called backscatter
+mail. With Postfix, you know that you're a backscatter victim when your logfile
+goes on and on like this:
+
+ Dec 4 04:30:09 hostname postfix/smtpd[58549]: NOQUEUE: reject:
+ RCPT from xxxxxxx[x.x.x.x]: 550 5.1.1 :
+ Recipient address rejected: User unknown; from=<>
+ to= proto=ESMTP helo=
+
+What you see are lots of "user unknown" errors with "from=<>". These are error
+reports from MAILER-DAEMONs elsewhere on the Internet, about email that was
+sent with a false sender address in your domain.
+
+HHooww ddoo II bblloocckk bbaacckkssccaatttteerr mmaaiill ttoo rraannddoomm rreecciippiieenntt aaddddrreesssseess??
+
+If your machine receives backscatter mail to random addresses, configure
+Postfix to reject all mail for non-existent recipients as described in the
+LOCAL_RECIPIENT_README and STANDARD_CONFIGURATION_README documentation.
+
+If your machine runs Postfix 2.0 and earlier, disable the "pause before reject"
+feature in the SMTP server. If your system is under stress then it should not
+waste time.
+
+ /etc/postfix/main.cf:
+ # Not needed with Postfix 2.1 and later.
+ smtpd_error_sleep_time = 0
+
+ # Not needed with Postfix 2.4 and later.
+ unknown_local_recipient_reject_code = 550
+
+HHooww ddoo II bblloocckk bbaacckkssccaatttteerr mmaaiill ttoo rreeaall rreecciippiieenntt aaddddrreesssseess??
+
+When backscatter mail passes the "unknown recipient" barrier, there still is no
+need to despair. Many mail systems are kind enough to attach the message
+headers of the undeliverable mail in the non-delivery notification. These
+message headers contain information that you can use to recognize and block
+forged mail.
+
+BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill wwiitthh ffoorrggeedd mmaaiill sseerrvveerr iinnffoorrmmaattiioonn
+
+Although my email address is "wietse@porcupine.org", all my mail systems
+announce themselves with the SMTP HELO command as "hostname.porcupine.org".
+Thus, if returned mail has a Received: message header like this:
+
+ Received: from porcupine.org ...
+
+Then I know that this is almost certainly forged mail (almost; see next section
+for the fly in the ointment). Mail that is really sent by my systems looks like
+this:
+
+ Received: from hostname.porcupine.org ...
+
+For the same reason the following message headers are very likely to be the
+result of forgery:
+
+ Received: from host.example.com ([1.2.3.4] helo=porcupine.org) ...
+ Received: from [1.2.3.4] (port=12345 helo=porcupine.org) ...
+ Received: from host.example.com (HELO porcupine.org) ...
+ Received: from host.example.com (EHLO porcupine.org) ...
+
+Some forgeries show up in the way that a mail server reports itself in
+Received: message headers. Keeping in mind that all my systems have a mail
+server name of hostname.porcupine.org, the following is definitely a forgery:
+
+ Received: by porcupine.org ...
+ Received: from host.example.com ( ... ) by porcupine.org ...
+
+Another frequent sign of forgery is the Message-ID: header. My systems produce
+a Message-ID: of . The following are forgeries,
+especially the first one:
+
+ Message-ID: <1cb479435d8eb9.2beb1.qmail@porcupine.org>
+ Message-ID:
+
+To block such backscatter I use header_checks and body_checks patterns like
+this:
+
+ /etc/postfix/main.cf:
+ header_checks = pcre:/etc/postfix/header_checks
+ body_checks = pcre:/etc/postfix/body_checks
+
+ /etc/postfix/header_checks:
+ # Do not indent the patterns between "if" and "endif".
+ if /^Received:/
+ /^Received: +from +(porcupine\.org) +/
+ reject forged client name in Received: header: $1
+ /^Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)
+ (porcupine\.org)\)/
+ reject forged client name in Received: header: $2
+ /^Received:.* +by +(porcupine\.org)\b/
+ reject forged mail server name in Received: header: $1
+ endif
+ /^Message-ID:.* ]*Received:/
+ /^[> ]*Received: +from +(porcupine\.org) /
+ reject forged client name in Received: header: $1
+ /^[> ]*Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)
+ (porcupine\.org)\)/
+ reject forged client name in Received: header: $2
+ /^[> ]*Received:.* +by +(porcupine\.org)\b/
+ reject forged mail server name in Received: header: $1
+ endif
+ /^[> ]*Message-ID:.* ]*Message-ID:.*@(porcupine\.org)/
+ reject forged domain name in Message-ID: header: $1
+
+Notes:
+
+ * The example uses pcre: tables mainly for speed; with minor modifications,
+ you can use regexp: tables as explained below.
+
+ * The example is simplified for educational purposes. In reality my patterns
+ list multiple domain names, as "(domain|domain|...)".
+
+ * The "\." matches "." literally. Without the "\", the "." would match any
+ character.
+
+ * The "\(" and "\)" match "(" and ")" literally. Without the "\", the "(" and
+ ")" would be grouping operators.
+
+ * The "\b" is used here to match the end of a word. If you use regexp:
+ tables, specify "[[:>:]]" (on some systems you should specify "\>" instead;
+ for details see your system documentation).
+
+ * The "if /pattern/" and "endif" eliminate unnecessary matching attempts. DO
+ NOT indent lines starting with /pattern/ between the "if" and "endif"!
+
+ * The two "Message-ID:.*
+
+ where example.com is the domain name part of the email address specified in
+ Outlook's account settings for the user. Since many users configure their
+ email addresses as username@example.com, messages with DSN turned on will
+ trigger the REJECT action in the previous section.
+
+ If you have such clients then you can to exclude their Message-ID strings
+ with the two "Message-ID:.* ]*(From|Return-Path):.*\b(user@domain\.tld)\b/
+ reject forged sender address in $1: header: $2
+
+Notes:
+
+ * The example uses pcre: tables mainly for speed; with minor modifications,
+ you can use regexp: tables as explained below.
+
+ * The example is simplified for educational purposes. In reality, my patterns
+ list multiple email addresses as "(user1@domain1\.tld|user2@domain2\.tld)".
+
+ * The two "\b" as used in "\b(user@domain\.tld)\b" match the beginning and
+ end of a word, respectively. If you use regexp: tables, specify "[[:<:]]
+ and [[:>:]]" (on some systems you should specify "\< and \>" instead; for
+ details see your system documentation).
+
+ * The "\." matches "." literally. Without the "\", the "." would match any
+ character.
+
+BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill wwiitthh ootthheerr ffoorrggeedd iinnffoorrmmaattiioonn
+
+Another sign of forgery can be found in the IP address that is recorded in
+Received: headers next to your HELO host or domain name. This information must
+be used with care, though. Some mail servers are behind a network address
+translator and never see the true client IP address.
+
+BBlloocckkiinngg bbaacckkssccaatttteerr mmaaiill ffrroomm vviirruuss ssccaannnneerrss
+
+With all the easily recognizable forgeries eliminated, there is one category of
+backscatter mail that remains, and that is notifications from virus scanner
+software. Unfortunately, some virus scanning software doesn't know that viruses
+forge sender addresses. To make matters worse, the software also doesn't know
+how to report a mail delivery problem, so that we cannot use the above
+techniques to recognize forgeries.
+
+Recognizing virus scanner mail is an error prone process, because there is a
+lot of variation in report formats. The following is only a small example of
+message header patterns. For a large collection of header and body patterns
+that recognize virus notification email, see http://www.dkuug.dk/keld/virus/ or
+http://www.t29.dk/antiantivirus.txt.
+
+ /etc/postfix/header_checks:
+ /^Subject: *Your email contains VIRUSES/ DISCARD virus notification
+ /^Content-Disposition:.*VIRUS1_DETECTED_AND_REMOVED/
+ DISCARD virus notification
+ /^Content-Disposition:.*VirusWarning.txt/ DISCARD virus notification
+
+Note: these documents haven't been updated since 2004, so they are useful only
+as a starting point.
+
+A plea to virus or spam scanner operators: please do not make the problem worse
+by sending return mail to forged sender addresses. You're only harassing
+innocent people. If you must return mail to the purported sender, please return
+the full message headers, so that the sender can filter out the obvious
+forgeries.
+
diff --git a/README_FILES/BASIC_CONFIGURATION_README b/README_FILES/BASIC_CONFIGURATION_README
new file mode 100644
index 0000000..d17cba9
--- /dev/null
+++ b/README_FILES/BASIC_CONFIGURATION_README
@@ -0,0 +1,487 @@
+PPoossttffiixx BBaassiicc CCoonnffiigguurraattiioonn
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix has several hundred configuration parameters that are controlled via
+the main.cf file. Fortunately, all parameters have sensible default values. In
+many cases, you need to configure only two or three parameters before you can
+start to play with the mail system. Here's a quick introduction to the syntax:
+
+ * Postfix configuration files
+
+The text below assumes that you already have Postfix installed on the system,
+either by compiling the source code yourself (as described in the INSTALL file)
+or by installing an already compiled version.
+
+This document covers basic Postfix configuration. Information about how to
+configure Postfix for specific applications such as mailhub, firewall or dial-
+up client can be found in the STANDARD_CONFIGURATION_README file. But don't go
+there until you already have covered the material presented below.
+
+The first parameters of interest specify the machine's identity and role in the
+network.
+
+ * What domain name to use in outbound mail
+
+ * What domains to receive mail for
+
+ * What clients to relay mail from
+
+ * What destinations to relay mail to
+
+ * What delivery method: direct or indirect
+
+The default values for many other configuration parameters are derived from
+just these.
+
+The next parameter of interest controls the amount of mail sent to the local
+postmaster:
+
+ * What trouble to report to the postmaster
+
+Be sure to set the following correctly if you're behind a proxy or network
+address translator, and you are running a backup MX host for some other domain:
+
+ * Proxy/NAT external network addresses
+
+Postfix daemon processes run in the background, and log problems and normal
+activity to the syslog daemon. Here are a few things that you need to be aware
+of:
+
+ * What you need to know about Postfix logging
+
+If your machine has unusual security requirements you may want to run Postfix
+daemon processes inside a chroot environment.
+
+ * Running Postfix daemon processes chrooted
+
+If you run Postfix on a virtual network interface, or if your machine runs
+other mailers on virtual interfaces, you'll have to look at the other
+parameters listed here as well:
+
+ * My own hostname
+
+ * My own domain name
+
+ * My own network addresses
+
+PPoossttffiixx ccoonnffiigguurraattiioonn ffiilleess
+
+By default, Postfix configuration files are in /etc/postfix. The two most
+important files are main.cf and master.cf; these files must be owned by root.
+Giving someone else write permission to main.cf or master.cf (or to their
+parent directories) means giving root privileges to that person.
+
+In /etc/postfix/main.cf you will have to set up a minimal number of
+configuration parameters. Postfix configuration parameters resemble shell
+variables, with two important differences: the first one is that Postfix does
+not know about quotes like the UNIX shell does.
+
+You specify a configuration parameter as:
+
+ /etc/postfix/main.cf:
+ parameter = value
+
+and you use it by putting a "$" character in front of its name:
+
+ /etc/postfix/main.cf:
+ other_parameter = $parameter
+
+You can use $parameter before it is given a value (that is the second main
+difference with UNIX shell variables). The Postfix configuration language uses
+lazy evaluation, and does not look at a parameter value until it is needed at
+runtime.
+
+Postfix uses database files for access control, address rewriting and other
+purposes. The DATABASE_README file gives an introduction to how Postfix works
+with Berkeley DB, LDAP or SQL and other types. Here is a common example of how
+Postfix invokes a database:
+
+ /etc/postfix/main.cf:
+ virtual_alias_maps = hash:/etc/postfix/virtual
+
+Whenever you make a change to the main.cf or master.cf file, execute the
+following command as root in order to refresh a running mail system:
+
+ # postfix reload
+
+WWhhaatt ddoommaaiinn nnaammee ttoo uussee iinn oouuttbboouunndd mmaaiill
+
+The myorigin parameter specifies the domain that appears in mail that is posted
+on this machine. The default is to use the local machine name, $myhostname,
+which defaults to the name of the machine. Unless you are running a really
+small site, you probably want to change that into $mydomain, which defaults to
+the parent domain of the machine name.
+
+For the sake of consistency between sender and recipient addresses, myorigin
+also specifies the domain name that is appended to an unqualified recipient
+address.
+
+Examples (specify only one of the following):
+
+ /etc/postfix/main.cf:
+ myorigin = $myhostname (default: send mail as "user@$myhostname")
+ myorigin = $mydomain (probably desirable: "user@$mydomain")
+
+WWhhaatt ddoommaaiinnss ttoo rreecceeiivvee mmaaiill ffoorr
+
+The mydestination parameter specifies what domains this machine will deliver
+locally, instead of forwarding to another machine. The default is to receive
+mail for the machine itself. See the VIRTUAL_README file for how to configure
+Postfix for hosted domains.
+
+You can specify zero or more domain names, "/file/name" patterns and/or "type:
+table" lookup tables (such as hash:, btree:, nis:, ldap:, or mysql:), separated
+by whitespace and/or commas. A "/file/name" pattern is replaced by its
+contents; "type:table" requests that a table lookup is done and merely tests
+for existence: the lookup result is ignored.
+
+IMPORTANT: If your machine is a mail server for its entire domain, you must
+list $mydomain as well.
+
+Example 1: default setting.
+
+ /etc/postfix/main.cf:
+ mydestination = $myhostname localhost.$mydomain localhost
+
+Example 2: domain-wide mail server.
+
+ /etc/postfix/main.cf:
+ mydestination = $myhostname localhost.$mydomain localhost $mydomain
+
+Example 3: host with multiple DNS A records.
+
+ /etc/postfix/main.cf:
+ mydestination = $myhostname localhost.$mydomain localhost
+ www.$mydomain ftp.$mydomain
+
+Caution: in order to avoid mail delivery loops, you must list all hostnames of
+the machine, including $myhostname, and localhost.$mydomain.
+
+WWhhaatt cclliieennttss ttoo rreellaayy mmaaiill ffrroomm
+
+By default, Postfix will forward mail from clients in authorized network blocks
+to any destination. Authorized networks are defined with the mynetworks
+configuration parameter. The default is to authorize all clients in the IP
+subnetworks that the local machine is attached to.
+
+Postfix can also be configured to relay mail from "mobile" clients that send
+mail from outside an authorized network block. This is explained in the
+SASL_README and TLS_README documents.
+
+IMPORTANT: If your machine is connected to a wide area network then your
+default mynetworks setting may be too friendly.
+
+Examples (specify only one of the following):
+
+ /etc/postfix/main.cf:
+ mynetworks_style = subnet (default: authorize subnetworks)
+ mynetworks_style = host (safe: authorize local machine only)
+ mynetworks = 127.0.0.0/8 (safe: authorize local machine only)
+ mynetworks = 127.0.0.0/8 168.100.189.2/32 (authorize local machine)
+
+You can specify the trusted networks in the main.cf file, or you can let
+Postfix do the work for you. The default is to let Postfix do the work. The
+result depends on the mynetworks_style parameter value.
+
+ * Specify "mynetworks_style = host" when Postfix should forward mail from
+ only the local machine.
+
+ * Specify "mynetworks_style = 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 = class" when Postfix should forward mail from
+ SMTP clients in the same IP class A/B/C networks as the local machine.
+ Don't do this with a dialup site - it would cause Postfix to "trust" your
+ entire provider's network. Instead, specify an explicit mynetworks list by
+ hand, as described below.
+
+Alternatively, you can specify the mynetworks list by hand, in which case
+Postfix ignores the mynetworks_style setting. To specify the list of trusted
+networks by hand, specify network blocks in CIDR (network/mask) notation, for
+example:
+
+ /etc/postfix/main.cf:
+ mynetworks = 168.100.189.0/28, 127.0.0.0/8
+
+You can also specify the absolute pathname of a pattern file instead of listing
+the patterns in the main.cf file.
+
+WWhhaatt ddeessttiinnaattiioonnss ttoo rreellaayy mmaaiill ttoo
+
+By default, Postfix will forward mail from strangers (clients outside
+authorized networks) to authorized remote destinations only. Authorized remote
+destinations are defined with the relay_domains configuration parameter. The
+default is to authorize all domains (and subdomains) of the domains listed with
+the mydestination parameter.
+
+Examples (specify only one of the following):
+
+ /etc/postfix/main.cf:
+ relay_domains = $mydestination (default)
+ relay_domains = (safe: never forward mail from strangers)
+ relay_domains = $mydomain (forward mail to my domain and subdomains)
+
+WWhhaatt ddeelliivveerryy mmeetthhoodd:: ddiirreecctt oorr iinnddiirreecctt
+
+By default, Postfix tries to deliver mail directly to the Internet. Depending
+on your local conditions this may not be possible or desirable. For example,
+your system may be turned off outside office hours, it may be behind a
+firewall, or it may be connected via a provider who does not allow direct mail
+to the Internet. In those cases you need to configure Postfix to deliver mail
+indirectly via a relay host.
+
+Examples (specify only one of the following):
+
+ /etc/postfix/main.cf:
+ relayhost = (default: direct delivery to Internet)
+ relayhost = $mydomain (deliver via local mailhub)
+ relayhost = [mail.$mydomain] (deliver via local mailhub)
+ relayhost = [mail.isp.tld] (deliver via provider mailhub)
+
+The form enclosed with [] eliminates DNS MX lookups. Don't worry if you don't
+know what that means. Just be sure to specify the [] around the mailhub
+hostname that your ISP gave to you, otherwise mail may be mis-delivered.
+
+The STANDARD_CONFIGURATION_README file has more hints and tips for firewalled
+and/or dial-up networks.
+
+WWhhaatt ttrroouubbllee ttoo rreeppoorrtt ttoo tthhee ppoossttmmaasstteerr
+
+You should set up a postmaster alias in the aliases(5) table that directs mail
+to a human person. The postmaster address is required to exist, so that people
+can report mail delivery problems. While you're updating the aliases(5) table,
+be sure to direct mail for the super-user to a human person too.
+
+ /etc/aliases:
+ postmaster: you
+ root: you
+
+Execute the command "newaliases" after changing the aliases file. Instead of /
+etc/aliases, your alias file may be located elsewhere. Use the command
+"postconf alias_maps" to find out.
+
+The Postfix system reports problems to the postmaster alias. You may not be
+interested in all types of trouble reports, so this reporting mechanism is
+configurable. The default is to report only serious problems (resource,
+software) to postmaster:
+
+Default setting:
+
+ /etc/postfix/main.cf:
+ notify_classes = resource, software
+
+The meaning of the classes is as follows:
+
+ bounce
+ Inform the postmaster of undeliverable mail. Either send the postmaster
+ a copy of undeliverable mail that is returned to the sender, or send a
+ transcript of the SMTP session when Postfix rejected mail. For privacy
+ reasons, the postmaster copy of undeliverable mail is truncated after
+ the original message headers. This implies "2bounce" (see below). See
+ also the luser_relay feature. The notification is sent to the address
+ specified with the bounce_notice_recipient configuration parameter
+ (default: postmaster).
+ 2bounce
+ When Postfix is unable to return undeliverable mail to the sender, send
+ it to the postmaster instead (without truncating the message after the
+ primary headers). The notification is sent to the address specified
+ with the 2bounce_notice_recipient configuration parameter (default:
+ postmaster).
+ delay
+ Inform the postmaster of delayed mail. In this case, the postmaster
+ receives message headers only. The notification is sent to the address
+ specified with the delay_notice_recipient configuration parameter
+ (default: postmaster).
+ policy
+ Inform the postmaster of client requests that were rejected because of
+ (UCE) policy restrictions. The postmaster receives a transcript of the
+ SMTP session. The notification is sent to the address specified with
+ the error_notice_recipient configuration parameter (default:
+ postmaster).
+ protocol
+ Inform the postmaster of protocol errors (client or server side) or
+ attempts by a client to execute unimplemented commands. The postmaster
+ receives a transcript of the SMTP session. The notification is sent to
+ the address specified with the error_notice_recipient configuration
+ parameter (default: postmaster).
+ resource
+ Inform the postmaster of mail not delivered due to resource problems
+ (for example, queue file write errors). The notification is sent to the
+ address specified with the error_notice_recipient configuration
+ parameter (default: postmaster).
+ software
+ Inform the postmaster of mail not delivered due to software problems.
+ The notification is sent to the address specified with the
+ error_notice_recipient configuration parameter (default: postmaster).
+
+PPrrooxxyy//NNAATT eexxtteerrnnaall nneettwwoorrkk aaddddrreesssseess
+
+Some mail servers are connected to the Internet via a network address
+translator (NAT) or proxy. This means that systems on the Internet connect to
+the address of the NAT or proxy, instead of connecting to the network address
+of the mail server. The NAT or proxy forwards the connection to the network
+address of the mail server, but Postfix does not know this.
+
+If you run a Postfix server behind a proxy or NAT, you need to configure the
+proxy_interfaces parameter and specify all the external proxy or NAT addresses
+that Postfix receives mail on. You may specify symbolic hostnames instead of
+network addresses.
+
+IMPORTANT: You must specify your proxy/NAT external addresses when your system
+is a backup MX host for other domains, otherwise mail delivery loops will
+happen when the primary MX host is down.
+
+Example: host behind NAT box running a backup MX host.
+
+ /etc/postfix/main.cf:
+ proxy_interfaces = 1.2.3.4 (the proxy/NAT external network address)
+
+WWhhaatt yyoouu nneeeedd ttoo kknnooww aabboouutt PPoossttffiixx llooggggiinngg
+
+Postfix daemon processes run in the background, and log problems and normal
+activity to the syslog daemon. The syslogd process sorts events by class and
+severity, and appends them to logfiles. The logging classes, levels and logfile
+names are usually specified in /etc/syslog.conf. At the very least you need
+something like:
+
+ /etc/syslog.conf:
+ mail.err /dev/console
+ mail.debug /var/log/maillog
+
+After changing the syslog.conf file, send a "HUP" signal to the syslogd
+process.
+
+IMPORTANT: many syslogd implementations will not create files. You must create
+files before (re)starting syslogd.
+
+IMPORTANT: on Linux you need to put a "-" character before the pathname, e.g.,
+-/var/log/maillog, otherwise the syslogd process will use more system resources
+than Postfix.
+
+Hopefully, the number of problems will be small, but it is a good idea to run
+every night before the syslog files are rotated:
+
+ # postfix check
+ # egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+ * The first line (postfix check) causes Postfix to report file permission/
+ ownership discrepancies.
+
+ * The second line looks for problem reports from the mail software, and
+ reports how effective the relay and junk mail access blocks are. This may
+ produce a lot of output. You will want to apply some postprocessing to
+ eliminate uninteresting information.
+
+The DEBUG_README document describes the meaning of the "warning" etc. labels in
+Postfix logging.
+
+RRuunnnniinngg PPoossttffiixx ddaaeemmoonn pprroocceesssseess cchhrrooootteedd
+
+Postfix daemon processes can be configured (via the master.cf file) to run in a
+chroot jail. The processes run at a fixed low privilege and with file system
+access limited to the Postfix queue directories (/var/spool/postfix). This
+provides a significant barrier against intrusion. The barrier is not
+impenetrable (chroot limits file system access only), but every little bit
+helps.
+
+With the exception of Postfix daemons that deliver mail locally and/or that
+execute non-Postfix commands, every Postfix daemon can run chrooted.
+
+Sites with high security requirements should consider to chroot all daemons
+that talk to the network: the smtp(8) and smtpd(8) processes, and perhaps also
+the lmtp(8) client. The author's own porcupine.org mail server runs all daemons
+chrooted that can be chrooted.
+
+The default /etc/postfix/master.cf file specifies that no Postfix daemon runs
+chrooted. In order to enable chroot operation, edit the file /etc/postfix/
+master.cf, and follow instructions in the file. When you're finished, execute
+"postfix reload" to make the change effective.
+
+Note that a chrooted daemon resolves all filenames relative to the Postfix
+queue directory (/var/spool/postfix). For successful use of a chroot jail, most
+UNIX systems require you to bring in some files or device nodes. The examples/
+chroot-setup directory in the source code distribution has a collection of
+scripts that help you set up Postfix chroot environments on different operating
+systems.
+
+Additionally, you almost certainly need to configure syslogd so that it listens
+on a socket inside the Postfix queue directory. Examples of syslogd command
+line options that achieve this for specific systems:
+
+FreeBSD: syslogd -l /var/spool/postfix/var/run/log
+
+Linux, OpenBSD: syslogd -a /var/spool/postfix/dev/log
+
+MMyy oowwnn hhoossttnnaammee
+
+The myhostname parameter specifies the fully-qualified domain name of the
+machine running the Postfix system. $myhostname appears as the default value in
+many other Postfix configuration parameters.
+
+By default, myhostname is set to the local machine name. If your local machine
+name is not in fully-qualified domain name form, or if you run Postfix on a
+virtual interface, you will have to specify the fully-qualified domain name
+that the mail system should use.
+
+Alternatively, if you specify mydomain in main.cf, then Postfix will use its
+value to generate a fully-qualified default value for the myhostname parameter.
+
+Examples (specify only one of the following):
+
+ /etc/postfix/main.cf:
+ myhostname = host.local.domain (machine name is not FQDN)
+ myhostname = host.virtual.domain (virtual interface)
+ myhostname = virtual.domain (virtual interface)
+
+MMyy oowwnn ddoommaaiinn nnaammee
+
+The mydomain parameter specifies the parent domain of $myhostname. By default,
+it is derived from $myhostname by stripping off the first part (unless the
+result would be a top-level domain).
+
+Conversely, if you specify mydomain in main.cf, then Postfix will use its value
+to generate a fully-qualified default value for the myhostname parameter.
+
+Examples (specify only one of the following):
+
+ /etc/postfix/main.cf:
+ mydomain = local.domain
+ mydomain = virtual.domain (virtual interface)
+
+MMyy oowwnn nneettwwoorrkk aaddddrreesssseess
+
+The inet_interfaces parameter specifies all network interface addresses that
+the Postfix system should listen on; mail addressed to "user@[network address]"
+will be delivered locally, as if it is addressed to a domain listed in
+$mydestination.
+
+You can override the inet_interfaces setting in the Postfix master.cf file by
+prepending an IP address to a server name.
+
+The default is to listen on all active interfaces. If you run mailers on
+virtual interfaces, you will have to specify what interfaces to listen on.
+
+IMPORTANT: If you run MTAs on virtual interfaces you must specify explicit
+inet_interfaces values for the MTA that receives mail for the machine itself:
+this MTA should never listen on the virtual interfaces or you would have a
+mailer loop when a virtual MTA is down.
+
+Example: default setting.
+
+ /etc/postfix/main.cf:
+ inet_interfaces = all
+
+Example: host running one or more virtual mailers. For each Postfix instance,
+specify only one of the following.
+
+ /etc/postfix/main.cf:
+ inet_interfaces = virtual.host.tld (virtual Postfix)
+ inet_interfaces = $myhostname localhost... (non-virtual Postfix)
+
+Note: you need to stop and start Postfix after changing this parameter.
+
diff --git a/README_FILES/BUILTIN_FILTER_README b/README_FILES/BUILTIN_FILTER_README
new file mode 100644
index 0000000..5ed0416
--- /dev/null
+++ b/README_FILES/BUILTIN_FILTER_README
@@ -0,0 +1,321 @@
+ PPoossttffiixx BBuuiilltt--iinn CCoonntteenntt IInnssppeeccttiioonn
+
+-------------------------------------------------------------------------------
+
+BBuuiilltt--iinn ccoonntteenntt iinnssppeeccttiioonn iinnttrroodduuccttiioonn
+
+Postfix supports a built-in filter mechanism that examines message header and
+message body content, one line at a time, before it is stored in the Postfix
+queue. The filter is usually implemented with POSIX or PCRE regular
+expressions, as described in the header_checks(5) manual page.
+
+The original purpose of the built-in filter is to stop an outbreak of specific
+email worms or viruses, and it does this job well. The filter has also helped
+to block bounced junk email, bounced email from worms or viruses, and
+notifications from virus detection systems. Information about this secondary
+application is given in the BACKSCATTER_README document.
+
+Because the built-in filter is optimized for stopping specific worms and virus
+outbreaks, it has limitations that make it NOT suitable for general junk email
+and virus detection. For that, you should use one of the external content
+inspection methods that are described in the FILTER_README, SMTPD_PROXY_README
+and MILTER_README documents.
+
+The following diagram gives an over-all picture of how Postfix built-in content
+inspection works:
+
+ Postmaster
+ notifications
+
+ |
+ v
+
+ Network or -> BBuuiilltt--iinn -> Postfix -> Delivery -> Network or
+ local users ffiilltteerr queue agents local mailbox
+
+ ^ |
+ | v
+
+ Undeliverable mail
+ Forwarded mail
+
+The picture makes clear that the filter works while Postfix is receiving new
+mail. This means that Postfix can reject mail from the network without having
+to return undeliverable mail to the originator address (which is often spoofed
+anyway). However, this ability comes at a price: if mail inspection takes too
+much time, then the remote client will time out, and the client may send the
+same message repeatedly.
+
+Topics covered by this document:
+
+ * What mail is subjected to header/body checks
+ * Limitations of Postfix header/body checks
+ * Preventing daily mail status reports from being blocked
+ * Configuring header/body checks for mail from outside users only
+ * Configuring different header/body checks for MX service and submission
+ service
+ * Configuring header/body checks for mail to some domains only
+
+WWhhaatt mmaaiill iiss ssuubbjjeecctteedd ttoo hheeaaddeerr//bbooddyy cchheecckkss
+
+Postfix header/body checks are implemented by the cleanup(8) server before it
+injects mail into the incoming queue. The diagram below zooms in on the cleanup
+(8) server, and shows that this server handles mail from many different
+sources. In order to keep the diagram readable, the sources of postmaster
+notifications are not shown, because they can be produced by many Postfix
+daemon processes.
+
+ bounce(8)
+ (undeliverable)
+
+ ssmmttppdd((88)) |
+ ((nneettwwoorrkk)) \ v
+
+ qqmmqqppdd((88)) -\ cleanup(8) -> incoming
+ ((nneettwwoorrkk)) -/ queue
+
+ ppiicckkuupp((88)) / ^
+ ((llooccaall)) |
+
+ local(8)
+ (forwarded)
+
+For efficiency reasons, only mail that enters from outside of Postfix is
+inspected with header/body checks. It would be inefficient to filter already
+filtered mail again, and it would be undesirable to block postmaster
+notifications. The table below summarizes what mail is and is not subject to
+header/body checks.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |MMeessssaaggee ttyyppee |SSoouurrccee |HHeeaaddeerr//bbooddyy cchheecckkss??|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Undeliverable mail|bounce(8)|No |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Network mail |smtpd(8) |Configurable |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Network mail |qmqpd(8) |Configurable |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Local submission |pickup(8)|Configurable |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Local forwarding |local(8) |No |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |Postmaster notice |many |No |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+How does Postfix decide what mail needs to be filtered? It would be clumsy to
+make the decision in the cleanup(8) server, as this program receives mail from
+so many different sources. Instead, header/body checks are requested by the
+source. Examples of how to turn off header/body checks for mail received with
+smtpd(8), qmqpd(8) or pickup(8) are given below under "Configuring header/body
+checks for mail from outside users only", "Configuring different header/body
+checks for MX service and submission service", and "Configuring header/body
+checks for mail to some domains only".
+
+LLiimmiittaattiioonnss ooff PPoossttffiixx hheeaaddeerr//bbooddyy cchheecckkss
+
+ * Header/body checks do not decode message headers or message body content.
+ For example, if text in the message body is BASE64 encoded (RFC 2045) then
+ your regular expressions will have to match the BASE64 encoded form.
+ Likewise, message headers with encoded non-ASCII characters (RFC 2047) need
+ to be matched in their encoded form.
+
+ * Header/body checks cannot filter on a combination of message headers or
+ body lines. Header/body checks examine content one message header at a
+ time, or one message body line at a time, and cannot carry a decision over
+ to the next message header or body line.
+
+ * Header/body checks cannot depend on the recipient of a message.
+
+ o One message can have multiple recipients, and all recipients of a
+ message receive the same treatment. Workarounds have been proposed that
+ involve selectively deferring some recipients of multi-recipient mail,
+ but that results in poor SMTP performance and does not work for non-
+ SMTP mail.
+
+ o Some sources of mail send the headers and content ahead of the
+ recipient information. It would be inefficient to buffer up an entire
+ message before deciding if it needs to be filtered, and it would be
+ clumsy to filter mail and to buffer up all the actions until it is
+ known whether those actions need to be executed.
+
+ * Despite warnings, some people try to use the built-in filter feature for
+ general junk email and/or virus blocking, using hundreds or even thousands
+ of regular expressions. This can result in catastrophic performance
+ failure. The symptoms are as follows:
+
+ o The cleanup(8) processes use up all available CPU time in order to
+ process the regular expressions, and/or they use up all available
+ memory so that the system begins to swap. This slows down all incoming
+ mail deliveries.
+
+ o As Postfix needs more and more time to receive an email message, the
+ number of simultaneous SMTP sessions increases to the point that the
+ SMTP server process limit is reached.
+
+ o While all SMTP server processes are waiting for the cleanup(8) servers
+ to finish, new SMTP clients have to wait until an SMTP server process
+ becomes available. This causes mail deliveries to time out before they
+ have even begun.
+
+ The remedy for this type of performance problem is simple: don't use
+ header/body checks for general junk email and/or virus blocking, and don't
+ filter mail before it is queued. When performance is a concern, use an
+ external content filter that runs after mail is queued, as described in the
+ FILTER_README document.
+
+PPrreevveennttiinngg ddaaiillyy mmaaiill ssttaattuuss rreeppoorrttss ffrroomm bbeeiinngg bblloocckkeedd
+
+The following is quoted from Jim Seymour's Pflogsumm FAQ at http://
+jimsun.linxnet.com/downloads/pflogsumm-faq.txt. Pflogsumm is a program that
+analyzes Postfix logs, including the logging from rejected mail. If these logs
+contain text that was rejected by Postfix body_checks patterns, then the
+logging is also likely to be rejected by those same body_checks patterns. This
+problem does not exist with header_checks patterns, because those are not
+applied to the text that is part of the mail status report.
+
+ You configure Postfix to do body checks, Postfix does its thing, Pflogsumm
+ reports it and Postfix catches the same string in the Pflogsumm report.
+ There are several solutions to this.
+
+ Wolfgang Zeikat contributed this:
+
+ #!/usr/bin/perl
+ use MIME::Lite;
+
+ ### Create a new message:
+ $msg = MIME::Lite->new(
+ From => 'your@send.er',
+ To => 'your@recipie.nt',
+ # Cc => 'some@other.com, some@more.com',
+ Subject => 'pflogsumm',
+ Date => `date`,
+ Type => 'text/plain',
+ Encoding => 'base64',
+ Path => '/tmp/pflogg',
+ );
+
+ $msg->send;
+
+ Where "/tmp/pflogg" is the output of Pflogsumm. This puts Pflogsumm's
+ output in a base64 MIME attachment.
+
+Note by Wietse: if you run this on a machine that is accessible by untrusted
+users, it is safer to store the Pflogsumm report in a directory that is not
+world writable.
+
+ In a follow-up to a thread in the postfix-users mailing list, Ralf
+ Hildebrandt noted:
+
+ "mpack does the same thing."
+
+And it does. Which tool one should use is a matter of preference.
+
+Other solutions involve additional body_checks rules that make exceptions for
+daily mail status reports, but this is not recommended. Such rules slow down
+all mail and complicate Postfix maintenance.
+
+CCoonnffiigguurriinngg hheeaaddeerr//bbooddyy cchheecckkss ffoorr mmaaiill ffrroomm oouuttssiiddee uusseerrss oonnllyy
+
+The following information applies to Postfix 2.1 and later. Earlier Postfix
+versions do not support the receive_override_options feature.
+
+The easiest approach is to configure ONE Postfix instance with multiple SMTP
+server IP addresses in master.cf:
+
+ * Two SMTP server IP addresses for mail from inside users only, with header/
+ body filtering turned off, and a local mail pickup service with header/body
+ filtering turned off.
+
+ /etc/postfix.master.cf:
+ # ==================================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # ==================================================================
+ 1.2.3.4:smtp inet n - n - - smtpd
+ -o receive_override_options=no_header_body_checks
+ 127.0.0.1:smtp inet n - n - - smtpd
+ -o receive_override_options=no_header_body_checks
+ pickup fifo n - n 60 1 pickup
+ -o receive_override_options=no_header_body_checks
+
+ * Add some firewall rule to prevent access to 1.2.3.4:smtp from the outside
+ world.
+
+ * One SMTP server address for mail from outside users with header/body
+ filtering turned on via main.cf.
+
+ /etc/postfix.master.cf:
+ # =================================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =================================================================
+ 1.2.3.5:smtp inet n - n - - smtpd
+
+CCoonnffiigguurriinngg ddiiffffeerreenntt hheeaaddeerr//bbooddyy cchheecckkss ffoorr MMXX sseerrvviiccee aanndd ssuubbmmiissssiioonn sseerrvviiccee
+
+If authorized user submissions require different header/body checks than mail
+from remote MTAs, then this is possible as long as you have separate mail
+streams for authorized users and for MX service.
+
+The example below assumes that authorized users connect to TCP port 587
+(submission) or 465 (smtps), and that remote MTAs connect to TCP port 25
+(smtp).
+
+First, we define a few "user-defined" parameters that will override settings
+for the submission and smtps services.
+
+ /etc/postfix/main.cf:
+ msa_cleanup_service_name = msa_cleanup
+ msa_header_checks = pcre:/etc/postfix/msa_header_checks
+ msa_body_checks = pcre:/etc/postfix/msa_body_checks
+
+Next, we define msa_cleanup as a dedicated cleanup service that will be used
+only by the submission and smtps services. This service uses the header_checks
+and body_checks overrides that were defined above.
+
+ /etc/postfix.master.cf:
+ # =================================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =================================================================
+ smtp inet n - n - - smtpd
+ msa_cleanup unix n - n - 0 cleanup
+ -o header_checks=$msa_header_checks
+ -o body_checks=$msa_body_checks
+ submission inet n - n - - smtpd
+ -o cleanup_service_name=$msa_cleanup_service_name
+ -o syslog_name=postfix/submission
+ ...[see sample master.cf file for more]...
+ smtps inet n - n - - smtpd
+ -o cleanup_service_name=$msa_cleanup_service_name
+ -o syslog_name=postfix/smtps
+ -o smtpd_tls_wrappermode=yes
+ ...[see sample master.cf file for more]...
+
+By keeping the "msa_xxx" parameter settings in main.cf, you keep your master.cf
+file simple, and you minimize the amount of duplication.
+
+CCoonnffiigguurriinngg hheeaaddeerr//bbooddyy cchheecckkss ffoorr mmaaiill ttoo ssoommee ddoommaaiinnss oonnllyy
+
+The following information applies to Postfix 2.1. Earlier Postfix versions do
+not support the receive_override_options feature.
+
+If you are 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.
+
+ /etc/postfix.master.cf:
+ # =================================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =================================================================
+ # SMTP service for domains with header/body checks turned on.
+ 1.2.3.4:smtp inet n - n - - smtpd
+
+ # SMTP service for domains with header/body checks turned off.
+ 1.2.3.5:smtp inet n - n - - smtpd
+ -o receive_override_options=no_header_body_checks
+
+Once this is set up you can configure MX records in the DNS that route each
+domain to the proper SMTP server instance.
+
diff --git a/README_FILES/CDB_README b/README_FILES/CDB_README
new file mode 100644
index 0000000..0f06d47
--- /dev/null
+++ b/README_FILES/CDB_README
@@ -0,0 +1,74 @@
+PPoossttffiixx CCDDBB HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+CDB (Constant DataBase) is an indexed file format designed by Daniel Bernstein.
+CDB is optimized exclusively for read access and guarantees that each record
+will be read in at most two disk accesses. This is achieved by forgoing support
+for incremental updates: no single-record inserts or deletes are supported. CDB
+databases can be modified only by rebuilding them completely from scratch,
+hence the "constant" qualifier in the name.
+
+Postfix CDB databases are specified as "cdb:name", where name specifies the CDB
+file name without the ".cdb" suffix (another suffix, ".tmp", is used
+temporarily while a CDB file is under construction). CDB databases are
+maintained with the postmap(1) or postalias(1) command. The DATABASE_README
+document has general information about Postfix databases.
+
+CDB support is available with Postfix 2.2 and later releases. This document
+describes how to build Postfix with CDB support.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh CCDDBB ssuuppppoorrtt
+
+These instructions assume that you build Postfix from source code as described
+in the INSTALL document. Some modification may be required if you build Postfix
+from a vendor-specific source package.
+
+Postfix is compatible with two CDB implementations:
+
+ * The original cdb library from Daniel Bernstein, available from http://
+ cr.yp.to/cdb.html, and
+
+ * tinycdb (version 0.5 and later) from Michael Tokarev, available from http:/
+ /www.corpit.ru/mjt/tinycdb.html.
+
+Tinycdb is preferred, since it is a bit faster, has additional useful
+functionality and is much simpler to use.
+
+To build Postfix after you have installed tinycdb, use something like:
+
+ % make tidy
+ % CDB=../../../tinycdb-0.5
+ % make -f Makefile.init makefiles "CCARGS=-DHAS_CDB -I$CDB" \
+ "AUXLIBS_CDB=$CDB/libcdb.a"
+ % make
+
+Alternatively, for the D.J.B. version of CDB:
+
+ % make tidy
+ % CDB=../../../cdb-0.75
+ % make -f Makefile.init makefiles "CCARGS=-DHAS_CDB -I$CDB" \
+ "AUXLIBS_CDB=$CDB/cdb.a $CDB/alloc.a $CDB/buffer.a $CDB/unix.a $CDB/
+ byte.a"
+ % make
+
+Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_CDB. With Postfix
+3.0 and later, the old AUXLIBS variable still supports building a statically-
+loaded CDB database client, but only the new AUXLIBS_CDB variable supports
+building a dynamically-loaded or statically-loaded CDB database client.
+
+ Failure to use the AUXLIBS_CDB variable will defeat the purpose of dynamic
+ database client loading. Every Postfix executable file will have CDB
+ database library dependencies. And that was exactly what dynamic database
+ client loading was meant to avoid.
+
+After Postfix has been built with cdb support, you can use "cdb" tables
+wherever you can use read-only "hash", "btree" or "dbm" tables. However, the
+"ppoossttmmaapp --ii" (incremental record insertion) and "ppoossttmmaapp --dd" (incremental
+record deletion) command-line options are not available. For the same reason
+the "cdb" map type cannot be used to store the persistent address verification
+cache for the verify(8) service, or to store TLS session information for the
+tlsmgr(8) service.
+
diff --git a/README_FILES/COMPATIBILITY_README b/README_FILES/COMPATIBILITY_README
new file mode 100644
index 0000000..83d300c
--- /dev/null
+++ b/README_FILES/COMPATIBILITY_README
@@ -0,0 +1,205 @@
+PPoossttffiixx BBaacckkwwaarrddss--CCoommppaattiibbiilliittyy SSaaffeettyy NNeett
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+Postfix 3.0 introduces a safety net that runs Postfix programs with backwards-
+compatible default settings after an upgrade. The safety net will log a warning
+whenever a "new" default setting could have an negative effect on your mail
+flow.
+
+This document provides information on the following topics:
+
+ * Detailed descriptions of Postfix backwards-compatibility warnings.
+
+ * What backwards-compatible settings you may have to make permanent in
+ main.cf or master.cf.
+
+ * How to turn off Postfix backwards-compatibility warnings.
+
+OOvveerrvviieeww
+
+With backwards compatibility turned on, Postfix logs a message whenever a
+backwards-compatible default setting may be required for continuity of service.
+Based on this logging the system administrator can decide if any backwards-
+compatible settings need to be made permanent in main.cf or master.cf, before
+turning off the backwards-compatibility safety net as described at the end of
+this document.
+
+The following messages may be logged:
+
+ * Using backwards-compatible default setting append_dot_mydomain=yes
+
+ * Using backwards-compatible default setting chroot=y
+
+ * Using backwards-compatible default setting mynetworks_style=subnet
+
+ * Using backwards-compatible default setting relay_domains=$mydestination
+
+ * Using backwards-compatible default setting smtputf8_enable=no
+
+If such a message is logged in the context of a legitimate request, the system
+administrator should make the backwards-compatible setting permanent in main.cf
+or master.cf, as detailed in the sections that follow.
+
+When no more backwards-compatible settings need to be made permanent, the
+system administrator should turn off the backwards-compatibility safety net as
+described at the end of this document.
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg aappppeenndd__ddoott__mmyyddoommaaiinn==yyeess
+
+The append_dot_mydomain default value has changed from "yes" to "no". As long
+as the append_dot_mydomain parameter is left at its implicit default value, and
+the backwards-compatible default setting is turned on, Postfix may log one of
+the following messages:
+
+ * Messages about missing "localhost" in mydestination or other address class:
+
+ postfix/trivial-rewrite[14777]: using backwards-compatible
+ default setting append_dot_mydomain=yes to rewrite
+ "localhost" to "localhost.example.com"; please add
+ "localhost" to mydestination or other address class
+
+ If Postfix logs the above message, add "localhost" to mydestination (or
+ virtual_alias_domains, virtual_mailbox_domains, or relay_domains) and
+ execute the command "ppoossttffiixx rreellooaadd".
+
+ * Messages about incomplete domains in email addresses:
+
+ postfix/trivial-rewrite[25835]: using backwards-compatible
+ default setting append_dot_mydomain=yes to rewrite "foo" to
+ "foo.example.com"
+
+ If Postfix logs the above message for domains different from "localhost",
+ and the sender cannot be changed to use complete domain names in email
+ addresses, then the system administrator should make the backwards-
+ compatible setting "append_dot_mydomain = yes" permanent in main.cf:
+
+ # ppoossttccoonnff aappppeenndd__ddoott__mmyyddoommaaiinn==yyeess
+ # ppoossttffiixx rreellooaadd
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg cchhrroooott==yy
+
+The master.cf chroot default value has changed from "y" (yes) to "n" (no). As
+long as a master.cf chroot field is left at its implicit default value, and the
+backwards-compatible default setting is turned on, Postfix may log the
+following message while it reads the master.cf file:
+
+ postfix/master[27664]: /etc/postfix/master.cf: line 72: using
+ backwards-compatible default setting chroot=y
+
+If this service should remain chrooted, then the system administrator should
+make the backwards-compatible setting "chroot = y" permanent in master.cf. For
+example, to update the chroot setting for the "smtp inet" service:
+
+ # ppoossttccoonnff --FF ssmmttpp//iinneett//cchhrroooott==yy
+ # ppoossttffiixx rreellooaadd
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg mmyynneettwwoorrkkss__ssttyyllee==ssuubbnneett
+
+The mynetworks_style default value has changed from "subnet" to "host". This
+parameter is used to implement the "permit_mynetworks" feature. As long as the
+mynetworks and mynetworks_style parameters are left at their implicit default
+values, and the backwards-compatible default setting is turned on, the Postfix
+SMTP server may log one of the following messages:
+
+ postfix/smtpd[17375]: using backwards-compatible default setting
+ mynetworks_style=subnet to permit request from client
+ "foo.example.com[10.1.1.1]"
+
+ postfix/postscreen[24982]: using backwards-compatible default
+ setting mynetworks_style=subnet to permit request from client
+ "10.1.1.1"
+
+If the client request should not be rejected, then the system administrator
+should make the backwards-compatible setting "mynetworks_style = subnet"
+permanent in main.cf:
+
+ # ppoossttccoonnff mmyynneettwwoorrkkss__ssttyyllee==ssuubbnneett
+ # ppoossttffiixx rreellooaadd
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg rreellaayy__ddoommaaiinnss==$$mmyyddeessttiinnaattiioonn
+
+The relay_domains default value has changed from "$mydestination" to the empty
+value. As long as the relay_domains parameter is left at its implicit default
+value, and the backwards-compatible default setting is turned on, Postfix may
+log one of the following messages.
+
+ * Messages about accepting mail for a remote domain:
+
+ postfix/smtpd[19052]: using backwards-compatible default setting
+ relay_domains=$mydestination to accept mail for domain
+ "foo.example.com"
+
+ postfix/smtpd[19052]: using backwards-compatible default setting
+ relay_domains=$mydestination to accept mail for address
+ "user@foo.example.com"
+
+ * Messages about providing ETRN service for a remote domain:
+
+ postfix/smtpd[19138]: using backwards-compatible default setting
+ relay_domains=$mydestination to flush mail for domain
+ "bar.example.com"
+
+ postfix/smtp[13945]: using backwards-compatible default setting
+ relay_domains=$mydestination to update fast-flush logfile for
+ domain "bar.example.com"
+
+If Postfix should continue to accept mail for that domain or continue to
+provide ETRN service for that domain, then the system administrator should make
+the backwards-compatible setting "relay_domains = $mydestination" permanent in
+main.cf:
+
+ # ppoossttccoonnff ''rreellaayy__ddoommaaiinnss==$$mmyyddeessttiinnaattiioonn''
+ # ppoossttffiixx rreellooaadd
+
+Note: quotes are required as indicated above.
+
+Instead of $mydestination, it may be better to specify an explicit list of
+domain names.
+
+UUssiinngg bbaacckkwwaarrddss--ccoommppaattiibbllee ddeeffaauulltt sseettttiinngg ssmmttppuuttff88__eennaabbllee==nnoo
+
+The smtputf8_enable default value has changed from "no" to "yes. With the new
+"yes" setting, the Postfix SMTP server rejects non-ASCII addresses from clients
+that don't request SMTPUTF8 support. With the old "no" setting, Postfix will
+accept such addresses, even if such addresses are not permitted by traditional
+SMTP standards.
+
+As long as the smtputf8_enable parameter is left at its implicit default value,
+and the backwards-compatible default setting is turned on, Postfix logs a
+warning each time an SMTP command uses a non-ASCII address localpart without
+requesting SMTPUTF8 support:
+
+ postfix/smtpd[27560]: using backwards-compatible default setting
+ smtputf8_enable=no to accept non-ASCII sender address
+ "??@example.org" from localhost[127.0.0.1]
+
+ postfix/smtpd[27560]: using backwards-compatible default setting
+ smtputf8_enable=no to accept non-ASCII recipient address
+ "??@example.com" from localhost[127.0.0.1]
+
+If the address should not be rejected, and the client cannot be updated to use
+SMTPUTF8, then the system administrator should make the backwards-compatible
+setting "smtputf8_enable = no" permanent in main.cf:
+
+ # ppoossttccoonnff ssmmttppuuttff88__eennaabbllee==nnoo
+ # ppoossttffiixx rreellooaadd
+
+TTuurrnniinngg ooffff tthhee bbaacckkwwaarrddss--ccoommppaattiibbiilliittyy ssaaffeettyy nneett
+
+Backwards compatibility is turned off by updating the compatibility_level
+setting in main.cf.
+
+ # ppoossttccoonnff ccoommppaattiibbiilliittyy__lleevveell==NN
+ # ppoossttffiixx rreellooaadd
+
+For N specify the number that is logged in your postfix(1) warning message:
+
+ warning: To disable backwards compatibility use "postconf
+ compatibility_level=N" and "postfix reload"
+
+Sites that don't care about backwards compatibility may set
+"compatibility_level = 9999" at their own risk.
+
diff --git a/README_FILES/CONNECTION_CACHE_README b/README_FILES/CONNECTION_CACHE_README
new file mode 100644
index 0000000..5067f7a
--- /dev/null
+++ b/README_FILES/CONNECTION_CACHE_README
@@ -0,0 +1,205 @@
+PPoossttffiixx CCoonnnneeccttiioonn CCaacchhee
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+This document describes the Postfix connection cache implementation, which is
+available with Postfix version 2.2 and later.
+
+Topics covered in this document:
+
+ * What SMTP connection caching can do for you
+ * Connection cache implementation
+ * Connection cache configuration
+ * Connection cache safety mechanisms
+ * Connection cache limitations
+ * Connection cache statistics
+
+WWhhaatt SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg ccaann ddoo ffoorr yyoouu
+
+With SMTP connection caching, Postfix can deliver multiple messages over the
+same SMTP connection. By default, Postfix 2.2 reuses an SMTP connection
+automatically when a destination has high volume of mail in the active queue.
+
+SMTP Connection caching is a performance feature. Whether or not it actually
+improves performance depends on the conditions:
+
+ * SMTP Connection caching can greatly improve performance when delivering
+ mail to a destination with multiple mail servers, because it can help
+ Postfix to skip over a non-responding server.
+
+ * Otherwise, the benefits of SMTP connection caching are minor: it eliminates
+ the latency of the TCP handshake (SYN, SYN+ACK, ACK), plus the latency of
+ the SMTP initial handshake (220 greeting, EHLO command, EHLO response).
+
+ * SMTP Connection caching gives no gains with respect to SMTP session tear-
+ down. The Postfix smtp(8) client normally does not wait for the server's
+ reply to the QUIT command, and it never waits for the TCP final handshake
+ to complete.
+
+ * SMTP Connection caching introduces some overhead: the client needs to send
+ an RSET command to find out if a connection is still usable, before it can
+ send the next MAIL FROM command. This introduces one additional round-trip
+ delay.
+
+For other potential issues with SMTP connection caching, see the discussion of
+limitations at the end of this document.
+
+CCoonnnneeccttiioonn ccaacchhee iimmpplleemmeennttaattiioonn
+
+For an overview of how Postfix delivers mail, see the Postfix architecture
+OVERVIEW document.
+
+The Postfix connection cache is shared among Postfix mail delivering processes.
+This maximizes the opportunity to reuse an open connection. Other MTAs such as
+Sendmail or exim have a non-shared connection cache. Here, a connection can be
+reused only by the mail delivering process that creates the connection. To get
+the same performance improvement as with a shared connection cache, non-shared
+connections need to be kept open for a longer time.
+
+The scache(8) server, introduced with Postfix version 2.2, maintains the shared
+connection cache. With Postfix version 2.2, only the smtp(8) client has support
+to access this cache.
+
+ /-- smtp(8) --> Internet
+
+ qmgr(8) |
+ |
+ \-- | smtp(8) --> Internet
+ |
+ ^
+ |
+
+ scache(8)
+
+When SMTP connection caching is enabled (see next section), the smtp(8) client
+does not disconnect after a mail transaction, but gives the connection to the
+scache(8) server which keeps the connection open for a limited amount of time.
+
+After handing over the open connection to the scache(8) server, the smtp(8)
+client continues with some other mail delivery request. Meanwhile, any smtp(8)
+client process can ask the scache(8) server for that cached connection and
+reuse it for mail delivery.
+
+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.
+
+CCoonnnneeccttiioonn ccaacchhee ccoonnffiigguurraattiioonn
+
+The Postfix smtp(8) client supports two connection caching strategies:
+
+ * On-demand connection caching. This is enabled by default, and is controlled
+ with the smtp_connection_cache_on_demand configuration parameter. When this
+ feature is enabled, the Postfix smtp(8) client automatically saves a
+ connection to the connection cache when a destination has a high volume of
+ mail in the active queue.
+
+ Example:
+
+ /etc/postfix/main.cf:
+ smtp_connection_cache_on_demand = yes
+
+ * Per-destination connection caching. This is enabled by explicitly listing
+ specific destinations with the smtp_connection_cache_destinations
+ configuration parameter. After completing delivery to a selected
+ destination, the Postfix smtp(8) client always saves the connection to the
+ connection cache.
+
+ Specify a comma or white space separated list of destinations or pseudo-
+ destinations:
+
+ o if mail is sent without a relay host: a domain name (the right-hand
+ side of an email address, without the [] around a numeric IP address),
+
+ o if mail is sent via a relay host: a relay host name (without the [] or
+ non-default TCP port), as specified in main.cf or in the transport map,
+
+ o a /file/name with domain names and/or relay host names as defined
+ above,
+
+ o a "type:table" with domain names and/or relay host names on the left-
+ hand side. The right-hand side result from "type:table" lookups is
+ ignored.
+
+ Examples:
+
+ /etc/postfix/main.cf:
+ smtp_connection_cache_destinations = $relayhost
+ smtp_connection_cache_destinations = hotmail.com, ...
+ smtp_connection_cache_destinations = static:all (not recommended)
+
+CCoonnnneeccttiioonn ccaacchhee ssaaffeettyy mmeecchhaanniissmmss
+
+Connection caching must be used wisely. It is anti-social to keep an unused
+SMTP connection open for a significant amount of time, and it is unwise to send
+huge numbers of messages through the same connection. In order to avoid
+problems with SMTP connection caching, Postfix implements the following safety
+mechanisms:
+
+ * The Postfix scache(8) server keeps a connection open for only a limited
+ time. The time limit is specified with the smtp_connection_cache_time_limit
+ and with the connection_cache_ttl_limit configuration parameters. This
+ prevents anti-social behavior.
+
+ * The Postfix smtp(8) client reuses a session for only a limited number of
+ times. This avoids triggering bugs in implementations that do not correctly
+ handle multiple deliveries per session.
+
+ As of Postfix 2.3 connection reuse is preferably limited with the
+ smtp_connection_reuse_time_limit parameter. In addition, Postfix 2.11
+ provides smtp_connection_reuse_count_limit to limit how many times a
+ connection may be reused, but this feature is unsafe as it introduces a
+ "fatal attractor" failure mode (when a destination has multiple inbound
+ MTAs, the slowest inbound MTA will attract most connections from Postfix to
+ that destination).
+
+ .
+ Postfix 2.3 logs the use count of multiply-used connections, as shown in
+ the following example:
+
+ Nov 3 16:04:31 myname postfix/smtp[30840]: 19B6B2900FE:
+ to=, orig_to=,
+ relay=mail.example.com[1.2.3.4], ccoonnnn__uussee==22, delay=0.22,
+ delays=0.04/0.01/0.05/0.1, dsn=2.0.0, status=sent (250 2.0.0 Ok)
+
+ * The connection cache explicitly labels each cached connection with
+ destination domain and IP address information. A connection cache lookup
+ succeeds only when the correct information is specified. This prevents mis-
+ delivery of mail.
+
+CCoonnnneeccttiioonn ccaacchhee lliimmiittaattiioonnss
+
+Postfix SMTP connection caching conflicts with certain applications:
+
+ * The Postfix shared connection cache cannot be used with TLS, because saved
+ TLS session information can be used only when a new connection is created
+ (this limitation does not exist in connection caching implementations that
+ reuse a connection only in the process that creates it). For this reason,
+ the Postfix smtp(8) client always closes the connection after completing an
+ attempt to deliver mail over TLS.
+
+ * Postfix connection caching currently does not support multiple SASL
+ accounts per mail server. Specifically, Postfix connection caching assumes
+ that a SASL credential is valid for all hostnames or domain names that
+ deliver via the same mail server IP address and TCP port, and assumes that
+ the SASL credential does not depend on the message originator.
+
+CCoonnnneeccttiioonn ccaacchhee ssttaattiissttiiccss
+
+The scache(8) connection cache server logs statistics about the peak cache size
+and the cache hit rates. This information is logged every
+connection_cache_status_update_time seconds, when the process terminates after
+the maximal idle time is exceeded, or when Postfix is reloaded.
+
+ * Hit rates for connection cache lookups by domain will tell you how useful
+ connection caching is.
+
+ * Connection cache lookups by network address will always fail, unless you're
+ sending mail to different domains that share the same MX hosts.
+
+ * No statistics are logged when no attempts are made to access the connection
+ cache.
+
diff --git a/README_FILES/CONTENT_INSPECTION_README b/README_FILES/CONTENT_INSPECTION_README
new file mode 100644
index 0000000..a6a6fd8
--- /dev/null
+++ b/README_FILES/CONTENT_INSPECTION_README
@@ -0,0 +1,56 @@
+PPoossttffiixx CCoonntteenntt IInnssppeeccttiioonn
+
+-------------------------------------------------------------------------------
+Postfix supports three content inspection methods, ranging from light-weight
+one-line-at-a-time scanning before mail is queued, to heavy duty machinery that
+does sophisticated content analysis after mail is queued. Each approach serves
+a different purpose.
+
+bbeeffoorree qquueeuuee,, bbuuiilltt--iinn,, lliigghhtt--wweeiigghhtt
+ This method inspects mail BEFORE it is stored in the queue, and uses
+ Postfix's built-in message header and message body inspection. Although the
+ main purpose is to stop a specific flood of mail from worms or viruses, it
+ is also useful to block a flood of bounced junk email and email
+ notifications from virus detection systems. The built-in regular
+ expressions are not meant to implement general SPAM and virus detection.
+ For that, you should use one of the content inspection methods described
+ below. Details are described in the BUILTIN_FILTER_README and
+ BACKSCATTER_README documents.
+
+aafftteerr qquueeuuee,, eexxtteerrnnaall,, hheeaavvyy--wweeiigghhtt
+ This method inspects mail AFTER it is stored in the queue, and uses
+ standard protocols such as SMTP or "pipe to command and wait for exit
+ status". After-queue inspection allows you to use content filters of
+ arbitrary complexity without causing timeouts while receiving mail, and
+ without running out of memory resources under a peak load. Details of this
+ approach are in the FILTER_README document.
+
+bbeeffoorree qquueeuuee,, eexxtteerrnnaall,, mmeeddiiuumm--wweeiigghhtt
+ The following two methods inspect mail BEFORE it is stored in the queue.
+
+ * The first method uses the SMTP protocol, and is described in the
+ SMTPD_PROXY_README document. This approach is available with Postfix
+ version 2.1 and later.
+
+ * The second method uses the Sendmail 8 Milter protocol, and is described
+ in the MILTER_README document. This approach is available with Postfix
+ version 2.3 and later.
+
+ Although these approaches appear to be attractive, they have some serious
+ limitations that you need to be aware of. First, content inspection
+ software must finish in a limited amount of time; if content inspection
+ needs too much time then incoming mail deliveries will time out. Second,
+ content inspection software must run in a limited amount of memory; if
+ content inspection needs too much memory then software will crash under a
+ peak load. Before-queue inspection limits the peak load that your system
+ can handle, and limits the sophistication of the content filter that you
+ can use.
+
+The more sophisticated content filtering software is not built into Postfix for
+good reasons: writing an MTA requires different skills than writing a SPAM or
+virus killer. Postfix encourages the use of external filters and standard
+protocols because this allows you to choose the best MTA and the best content
+inspection software for your purpose. Information about external content
+inspection software can be found on the Postfix website at http://
+www.postfix.org/, and on the postfix-users@postfix.org mailing list.
+
diff --git a/README_FILES/CYRUS_README b/README_FILES/CYRUS_README
new file mode 100644
index 0000000..a00df0b
--- /dev/null
+++ b/README_FILES/CYRUS_README
@@ -0,0 +1,5 @@
+PPoossttffiixx CCyyrruuss HHoowwttoo
+
+-------------------------------------------------------------------------------
+This document will be made available via http://www.postfix.org/.
+
diff --git a/README_FILES/DATABASE_README b/README_FILES/DATABASE_README
new file mode 100644
index 0000000..7526e0b
--- /dev/null
+++ b/README_FILES/DATABASE_README
@@ -0,0 +1,322 @@
+PPoossttffiixx LLooookkuupp TTaabbllee OOvveerrvviieeww
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document covers the following topics:
+
+ * The Postfix lookup table model
+ * Postfix lists versus tables
+ * Preparing Postfix for LDAP or SQL lookups
+ * Maintaining Postfix lookup table files
+ * Updating Berkeley DB files safely
+ * Postfix lookup table types
+
+TThhee PPoossttffiixx llooookkuupp ttaabbllee mmooddeell
+
+Postfix uses lookup tables to store and look up information for access control,
+address rewriting and even for content filtering. All Postfix lookup tables are
+specified as "type:table", where "type" is one of the database types described
+under "Postfix lookup table types" at the end of this document, and where
+"table" is the lookup table name. The Postfix documentation uses the terms
+"database" and "lookup table" for the same thing.
+
+Examples of lookup tables that appear often in the Postfix documentation:
+
+ /etc/postfix/main.cf:
+ alias_maps = hash:/etc/postfix/aliases (local aliasing)
+ header_checks = regexp:/etc/postfix/header_checks (content filtering)
+ transport_maps = hash:/etc/postfix/transport (routing table)
+ virtual_alias_maps = hash:/etc/postfix/virtual (address rewriting)
+
+All Postfix lookup tables store information as (key, value) pairs. This
+interface may seem simplistic at first, but it turns out to be very powerful.
+The (key, value) query interface completely hides the complexities of LDAP or
+SQL from Postfix. This is a good example of connecting complex systems with
+simple interfaces.
+
+Benefits of the Postfix (key, value) query interface:
+
+ * You can implement Postfix lookup tables first with local Berkeley DB files
+ and then switch to LDAP or MySQL without any impact on the Postfix
+ configuration itself, as described under "Preparing Postfix for LDAP or SQL
+ lookups" below.
+ * You can use Berkeley DB files with fixed lookup strings for simple address
+ rewriting operations and you can use regular expression tables for the more
+ complicated work. In other words, you don't have to put everything into the
+ same table.
+
+PPoossttffiixx lliissttss vveerrssuuss ttaabblleess
+
+Most Postfix lookup tables are used to look up information. Examples are
+address rewriting (the lookup string is the old address, and the result is the
+new address) or access control (the lookup string is the client, sender or
+recipient, and the result is an action such as "reject").
+
+With some tables, however, Postfix needs to know only if the lookup key exists.
+Any non-empty lookup result value may be used here: the lookup result is not
+used. Examples are the local_recipient_maps that determine what local
+recipients Postfix accepts in mail from the network, the mydestination
+parameter that specifies what domains Postfix delivers locally, or the
+mynetworks parameter that specifies the IP addresses of trusted clients or
+client networks. Technically, these are lists, not tables. Despite the
+difference, Postfix lists are described here because they use the same
+underlying infrastructure as Postfix lookup tables.
+
+PPrreeppaarriinngg PPoossttffiixx ffoorr LLDDAAPP oorr SSQQLL llooookkuuppss
+
+LDAP and SQL are complex systems. Trying to set up both Postfix and LDAP or SQL
+at the same time is definitely not a good idea. You can save yourself a lot of
+time by implementing Postfix first with local files such as Berkeley DB. Local
+files have few surprises, and are easy to debug with the postmap(1) command:
+
+ % ppoossttmmaapp --qq iinnffoo@@eexxaammppllee..ccoomm hhaasshh:://eettcc//ppoossttffiixx//vviirrttuuaall
+
+Once you have local files working properly you can follow the instructions in
+ldap_table(5), mysql_table(5), pgsql_table(5) or sqlite_table(5) and replace
+local file lookups with LDAP or SQL lookups. When you do this, you should use
+the postmap(1) command again, to verify that database lookups still produce the
+exact same results as local file lookup:
+
+ % ppoossttmmaapp --qq iinnffoo@@eexxaammppllee..ccoomm llddaapp:://eettcc//ppoossttffiixx//vviirrttuuaall..ccff
+
+Be sure to exercise all the partial address or parent domain queries that are
+documented under "table search order" in the relevant manual page: access(5),
+canonical(5), virtual(5), transport(5), or under the relevant configuration
+parameter: mynetworks, relay_domains, parent_domain_matches_subdomains.
+
+MMaaiinnttaaiinniinngg PPoossttffiixx llooookkuupp ttaabbllee ffiilleess
+
+When you make changes to a database while the mail system is running, it would
+be desirable if Postfix avoids reading information while that information is
+being changed. It would also be nice if you can change a database without
+having to execute "postfix reload", in order to force Postfix to use the new
+information. Each time you do "postfix reload" Postfix loses a lot of
+performance.
+
+ * If you change a network database such as LDAP, NIS or SQL, there is no need
+ to execute "postfix reload". The LDAP, NIS or SQL server takes care of
+ read/write access conflicts and gives the new data to Postfix once that
+ data is available.
+
+ * If you change a regexp:, pcre:, cidr: or texthash: file then Postfix may
+ not pick up the file changes immediately. This is because a Postfix process
+ reads the entire file into memory once and never examines the file again.
+
+ o If the file is used by a short-running process such as smtpd(8),
+ cleanup(8) or local(8), there is no need to execute "postfix reload"
+ after making a change.
+
+ o If the file is being used by a long-running process such as trivial-
+ rewrite(8) on a busy server it may be necessary to execute "postfix
+ reload".
+
+ * If you change a local file based database such as DBM or Berkeley DB, there
+ is no need to execute "postfix reload". Postfix uses file locking to avoid
+ read/write access conflicts, and whenever a Postfix daemon process notices
+ that a file has changed it will terminate before handling the next client
+ request, so that a new process can initialize with the new database.
+
+UUppddaattiinngg BBeerrkkeelleeyy DDBB ffiilleess ssaaffeellyy
+
+Postfix uses file locking to avoid access conflicts while updating Berkeley DB
+or other local database files. This used to be safe, but as Berkeley DB has
+evolved to use more aggressive caching, file locking may no longer be
+sufficient.
+
+Furthermore, file locking would not prevent problems when the update fails
+because the disk is full or something else causes a database update to fail. In
+particular, commands such as postmap(1) or postalias(1) overwrite existing
+files. If the overwrite fails in the middle then you have no usable database,
+and Postfix will stop working. This is not an issue with the CDB database type
+available with Postfix 2.2 and later: CDB creates a new file, and renames the
+file upon successful completion.
+
+With Berkeley DB and other "one file" databases, it is possible to add some
+extra robustness by using "mv" to REPLACE an existing database file instead of
+overwriting it:
+
+ # ppoossttmmaapp aacccceessss..iinn &&&& mmvv aacccceessss..iinn..ddbb aacccceessss..ddbb
+
+This converts the input file "access.in" into the output file "access.in.db",
+and replaces the file "access.db" only when the postmap(1) command was
+successful. Of course typing such commands becomes boring quickly, and this is
+why people use "make" instead, as shown below. User input is shown in bold
+font.
+
+ # ccaatt MMaakkeeffiillee
+ all: aliases.db access.db virtual.db ...etcetera...
+
+ # Note 1: commands are specified after a TAB character.
+ # Note 2: use postalias(1) for local aliases, postmap(1) for the rest.
+ aliases.db: aliases.in
+ postalias aliases.in
+ mv aliases.in.db aliases.db
+
+ access.db: access.in
+ postmap access.in
+ mv access.in.db access.db
+
+ virtual.db: virtual.in
+ postmap virtual.in
+ mv virtual.in.db virtual.db
+
+ ...etcetera...
+ # vvii aacccceessss..iinn
+ ...editing session not shown...
+ # mmaakkee
+ postmap access.in
+ mv access.in.db access.db
+ #
+
+The "make" command updates only the files that have changed. In case of error,
+the "make" command will stop and will not invoke the "mv" command, so that
+Postfix will keep using the existing database file as if nothing happened.
+
+PPoossttffiixx llooookkuupp ttaabbllee ttyyppeess
+
+To find out what database types your Postfix system supports, use the "ppoossttccoonnff
+--mm" command. Here is a list of database types that are often supported:
+
+ bbttrreeee
+ A sorted, balanced tree structure. This is available only on systems
+ with support for Berkeley DB databases. Database files are created with
+ the postmap(1) or postalias(1) command. The lookup table name as used
+ in "btree:table" is the database file name without the ".db" suffix.
+ ccddbb
+ A read-optimized structure with no support for incremental updates.
+ Database files are created with the postmap(1) or postalias(1) command.
+ The lookup table name as used in "cdb:table" is the database file name
+ without the ".cdb" suffix. This feature is available with Postfix 2.2
+ and later.
+ cciiddrr
+ A table that associates values with Classless Inter-Domain Routing
+ (CIDR) patterns. The table format is described in cidr_table(5).
+ ddbbmm
+ An indexed file type based on hashing. This is available only on
+ systems with support for DBM databases. Public database files are
+ created with the postmap(1) or postalias(1) command, and private
+ databases are maintained by Postfix daemons. The lookup table name as
+ used in "dbm:table" is the database file name without the ".dir" or
+ ".pag" suffix.
+ eennvviirroonn
+ The UNIX process environment array. The lookup key is the variable
+ name. The lookup table name in "environ:table" is ignored.
+ ffaaiill
+ A table that reliably fails all requests. The lookup table name is used
+ for logging only. This table exists to simplify Postfix error tests.
+ hhaasshh
+ An indexed file type based on hashing. This is available only on
+ systems with support for Berkeley DB databases. Public database files
+ are created with the postmap(1) or postalias(1) command, and private
+ databases are maintained by Postfix daemons. The database name as used
+ in "hash:table" is the database file name without the ".db" suffix.
+ iinnlliinnee (read-only)
+ A non-shared, in-memory lookup table. Example: "inline:{ key=value,
+ { key = text with whitespace or comma }}". Key-value pairs are
+ separated by whitespace or comma; whitespace after "{" and before "}"
+ is ignored. Inline tables eliminate the need to create a database file
+ for just a few fixed elements. See also the static: map type.
+ iinntteerrnnaall
+ A non-shared, in-memory hash table. Its content are lost when a process
+ terminates.
+ llmmddbb
+ OpenLDAP LMDB database. This is available only on systems with support
+ for LMDB databases. Public database files are created with the postmap
+ (1) or postalias(1) command, and private databases are maintained by
+ Postfix daemons. The database name as used in "lmdb:table" is the
+ database file name without the ".lmdb" suffix. See lmdb_table(5) for
+ details.
+ llddaapp (read-only)
+ LDAP database client. Configuration details are given in the ldap_table
+ (5).
+ mmeemmccaacchhee
+ Memcache database client. Configuration details are given in
+ memcache_table(5).
+ mmyyssqqll (read-only)
+ MySQL database client. Configuration details are given in mysql_table
+ (5).
+ nneettiinnffoo (read-only)
+ Netinfo database client.
+ nniiss (read-only)
+ NIS database client.
+ nniisspplluuss (read-only)
+ NIS+ database client. Configuration details are given in nisplus_table
+ (5).
+ ppccrree (read-only)
+ A lookup table based on Perl Compatible Regular Expressions. The file
+ format is described in pcre_table(5). The lookup table name as used in
+ "pcre:table" is the name of the regular expression file.
+ ppiippeemmaapp (read-only)
+ A pipeline of lookup tables. Example: "pipemap:{type1:name1, ...,
+ typen:namen}". Each "pipemap:" query is given to the first table. Each
+ lookup result becomes the query for the next table in the pipeline, and
+ the last table produces the final result. When any table lookup
+ produces no result, the pipeline produces no result. The first and last
+ characters of the "pipemap:" table name must be "{" and "}". Within
+ these, individual maps are separated with comma or whitespace.
+ ppggssqqll (read-only)
+ PostgreSQL database client. Configuration details are given in
+ pgsql_table(5).
+ pprrooxxyy
+ Postfix proxymap(8) client for shared access to Postfix databases. The
+ lookup table name syntax is "proxy:type:table".
+ rraannddmmaapp (read-only)
+ An in-memory table that performs random selection. Example: "randmap:
+ {result1. ..., resultn}". Each table query returns a random choice from
+ the specified results. The first and last characters of the "randmap:
+ " table name must be "{" and "}". Within these, individual maps are
+ separated with comma or whitespace.
+ rreeggeexxpp (read-only)
+ A lookup table based on regular expressions. The file format is
+ described in regexp_table(5). The lookup table name as used in "regexp:
+ table" is the name of the regular expression file.
+ ssddbbmm
+ An indexed file type based on hashing. This is available only on
+ systems with support for SDBM databases. Public database files are
+ created with the postmap(1) or postalias(1) command, and private
+ databases are maintained by Postfix daemons. The lookup table name as
+ used in "sdbm:table" is the database file name without the ".dir" or
+ ".pag" suffix.
+ ssoocckkeettmmaapp (read-only)
+ Sendmail-style socketmap client. The name of the table is either iinneett:
+ host:port:name for a TCP/IP server, or uunniixx:pathname:name for a UNIX-
+ domain server. See socketmap_table(5) for details.
+ ssqqlliittee (read-only)
+ SQLite database. Configuration details are given in sqlite_table(5).
+ ssttaattiicc (read-only)
+ A table that always returns its name as the lookup result. For example,
+ "static:foobar" always returns the string "foobar" as lookup result.
+ Specify "static:{ text with whitespace }" when the result contains
+ whitespace; this form ignores whitespace after "{" and before "}". See
+ also the inline: map type.
+ ttccpp
+ TCP/IP client. The protocol is described in tcp_table(5). The lookup
+ table name is "tcp:host:port" where "host" specifies a symbolic
+ hostname or a numeric IP address, and "port" specifies a symbolic
+ service name or a numeric port number.
+ tteexxtthhaasshh (read-only)
+ A table that produces similar results as hash: files, except that you
+ don't have to run the postmap(1) command before you can use the file,
+ and that texthash: does not detect changes after the file is read. The
+ lookup table name is "texthash:filename", where the file name is taken
+ literally; no suffix is appended.
+ uunniioonnmmaapp (read-only)
+ A table that sends each query to multiple lookup tables and that
+ concatenates all found results, separated by comma. The table name
+ syntax is the same as for pipemap tables.
+ uunniixx (read-only)
+ A limited view of the UNIX authentication database. The following
+ tables are implemented:
+ uunniixx::ppaasssswwdd..bbyynnaammee
+ The table is the UNIX password database. The key is a login name.
+ The result is a password file entry in passwd(5) format.
+ uunniixx::ggrroouupp..bbyynnaammee
+ The table is the UNIX group database. The key is a group name. The
+ result is a group file entry in group(5) format.
+
+Other lookup table types may be available depending on how Postfix was built.
+With some Postfix distributions the list is dynamically extensible as support
+for lookup tables is dynamically linked into Postfix.
+
diff --git a/README_FILES/DB_README b/README_FILES/DB_README
new file mode 100644
index 0000000..869218e
--- /dev/null
+++ b/README_FILES/DB_README
@@ -0,0 +1,170 @@
+PPoossttffiixx BBeerrkkeelleeyy DDBB HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix uses databases of various kinds to store and look up information.
+Postfix databases are specified as "type:name". Berkeley DB implements the
+Postfix database type "hash" and "btree". The name of a Postfix Berkeley DB
+database is the name of the database file without the ".db" suffix. Berkeley DB
+databases are maintained with the postmap(1) command.
+
+Note: Berkeley DB version 4 is not supported by Postfix versions before 2.0.
+
+This document describes:
+
+ 1. How to build Postfix without Berkeley DB support even if the system comes
+ with Berkeley DB.
+
+ 2. How to build Postfix on systems that normally have no Berkeley DB library.
+
+ 3. How to build Postfix on BSD or Linux systems with multiple Berkeley DB
+ versions.
+
+ 4. How to tweak performance.
+
+ 5. Missing pthread library trouble.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthhoouutt BBeerrkkeelleeyy DDBB ssuuppppoorrtt eevveenn iiff tthhee ssyysstteemm ccoommeess wwiitthh
+BBeerrkkeelleeyy DDBB
+
+Note: The following instructions apply to Postfix 2.9 and later.
+
+Postfix will normally enable Berkeley DB support if the system is known to have
+it. To build Postfix without Berkeley DB support, build the makefiles as
+follows:
+
+ % make makefiles CCARGS="-DNO_DB"
+ % make
+
+This will disable support for "hash" and "btree" files.
+
+BBuuiillddiinngg PPoossttffiixx oonn ssyysstteemmss tthhaatt nnoorrmmaallllyy hhaavvee nnoo BBeerrkkeelleeyy DDBB lliibbrraarryy
+
+Some UNIXes ship without Berkeley DB support; for historical reasons these use
+DBM files instead. A problem with DBM files is that they can store only limited
+amounts of data. To build Postfix with Berkeley DB support you need to download
+and install the source code from http://www.oracle.com/database/berkeley-db/.
+
+Warning: some Linux system libraries use Berkeley DB, as do some third-party
+libraries such as SASL. If you compile Postfix with a different Berkeley DB
+implementation, then every Postfix program will dump core because either the
+system library, the SASL library, or Postfix itself ends up using the wrong
+version.
+
+The more recent Berkeley DB versions have a compile-time switch, "--with-
+uniquename", which renames the symbols so that multiple versions of Berkeley DB
+can co-exist in the same application. Although wasteful, this may be the only
+way to keep things from falling apart.
+
+To build Postfix after you installed the Berkeley DB from source code, use
+something like:
+
+ % make makefiles CCARGS="-DHAS_DB -I/usr/local/BerkeleyDB/include" \
+ AUXLIBS="-L/usr/local/BerkeleyDB/lib -ldb"
+ % make
+
+Solaris needs this:
+
+ % make makefiles CCARGS="-DHAS_DB -I/usr/local/BerkeleyDB/include" \
+ AUXLIBS="-R/usr/local/BerkeleyDB/lib -L/usr/local/BerkeleyDB/lib -ldb"
+ % make
+
+The exact pathnames depend on the Berkeley DB version, and on how it was
+installed.
+
+Warning: the file format produced by Berkeley DB version 1 is not compatible
+with that of versions 2 and 3 (versions 2 and 3 have the same format). If you
+switch between DB versions, then you may have to rebuild all your Postfix DB
+files.
+
+Warning: if you use Berkeley DB version 2 or later, do not enable DB 1.85
+compatibility mode. Doing so would break fcntl file locking.
+
+Warning: if you use Perl to manipulate Postfix's Berkeley DB files, then you
+need to use the same Berkeley DB version in Perl as in Postfix.
+
+BBuuiillddiinngg PPoossttffiixx oonn BBSSDD ssyysstteemmss wwiitthh mmuullttiippllee BBeerrkkeelleeyy DDBB vveerrssiioonnss
+
+Some BSD systems ship with multiple Berkeley DB implementations. Normally,
+Postfix builds with the default DB version that ships with the system.
+
+To build Postfix on BSD systems with a non-default DB version, use a variant of
+the following commands:
+
+ % make makefiles CCARGS=-I/usr/include/db3 AUXLIBS=-ldb3
+ % make
+
+Warning: the file format produced by Berkeley DB version 1 is not compatible
+with that of versions 2 and 3 (versions 2 and 3 have the same format). If you
+switch between DB versions, then you may have to rebuild all your Postfix DB
+files.
+
+Warning: if you use Berkeley DB version 2 or later, do not enable DB 1.85
+compatibility mode. Doing so would break fcntl file locking.
+
+Warning: if you use Perl to manipulate Postfix's Berkeley DB files, then you
+need to use the same Berkeley DB version in Perl as in Postfix.
+
+BBuuiillddiinngg PPoossttffiixx oonn LLiinnuuxx ssyysstteemmss wwiitthh mmuullttiippllee BBeerrkkeelleeyy DDBB vveerrssiioonnss
+
+Some Linux systems ship with multiple Berkeley DB implementations. Normally,
+Postfix builds with the default DB version that ships with the system.
+
+Warning: some Linux system libraries use Berkeley DB. If you compile Postfix
+with a non-default Berkeley DB implementation, then every Postfix program will
+dump core because either the system library or Postfix itself ends up using the
+wrong version.
+
+On Linux, you need to edit the makedefs script in order to specify a non-
+default DB library. The reason is that the location of the default db.h include
+file changes randomly between vendors and between versions, so that Postfix has
+to choose the file for you.
+
+Warning: the file format produced by Berkeley DB version 1 is not compatible
+with that of versions 2 and 3 (versions 2 and 3 have the same format). If you
+switch between DB versions, then you may have to rebuild all your Postfix DB
+files.
+
+Warning: if you use Berkeley DB version 2 or later, do not enable DB 1.85
+compatibility mode. Doing so would break fcntl file locking.
+
+Warning: if you use Perl to manipulate Postfix's Berkeley DB files, then you
+need to use the same Berkeley DB version in Perl as in Postfix.
+
+TTwweeaakkiinngg ppeerrffoorrmmaannccee
+
+Postfix provides two configuration parameters that control how much buffering
+memory Berkeley DB will use.
+
+ * berkeley_db_create_buffer_size (default: 16 MBytes per table). This setting
+ is used by the commands that maintain Berkeley DB files: postalias(1) and
+ postmap(1). For "hash" files, create performance degrades rapidly unless
+ the memory pool is O(file size). For "btree" files, create performance is
+ good with sorted input even for small memory pools, but with random input
+ degrades rapidly unless the memory pool is O(file size).
+
+ * berkeley_db_read_buffer_size (default: 128 kBytes per table). This setting
+ is used by all other Postfix programs. The buffer size is adequate for
+ reading. If the cache is smaller than the table, random read performance is
+ hardly cache size dependent, except with btree tables, where the cache size
+ must be large enough to contain the entire path from the root node.
+ Empirical evidence shows that 64 kBytes may be sufficient. We double the
+ size to play safe, and to anticipate changes in implementation and bloat.
+
+MMiissssiinngg pptthhrreeaadd lliibbrraarryy ttrroouubbllee
+
+When building Postfix fails with:
+
+ undefined reference to `pthread_condattr_setpshared'
+ undefined reference to `pthread_mutexattr_destroy'
+ undefined reference to `pthread_mutexattr_init'
+ undefined reference to `pthread_mutex_trylock'
+
+Add the "-lpthread" library to the "make makefiles" command.
+
+ % make makefiles .... AUXLIBS="... -lpthread"
+
+More information is available at http://www.oracle.com/database/berkeley-db/.
+
diff --git a/README_FILES/DEBUG_README b/README_FILES/DEBUG_README
new file mode 100644
index 0000000..589036f
--- /dev/null
+++ b/README_FILES/DEBUG_README
@@ -0,0 +1,396 @@
+PPoossttffiixx DDeebbuuggggiinngg HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document describes how to debug parts of the Postfix mail system when
+things do not work according to expectation. The methods vary from making
+Postfix log a lot of detail, to running some daemon processes under control of
+a call tracer or debugger.
+
+The text assumes that the Postfix main.cf and master.cf configuration files are
+stored in directory /etc/postfix. You can use the command "ppoossttccoonnff
+ccoonnffiigg__ddiirreeccttoorryy" to find out the actual location of this directory on your
+machine.
+
+Listed in order of increasing invasiveness, the debugging techniques are as
+follows:
+
+ * Look for obvious signs of trouble
+ * Debugging Postfix from inside
+ * Try turning off chroot operation in master.cf
+ * Verbose logging for specific SMTP connections
+ * Record the SMTP session with a network sniffer
+ * Making Postfix daemon programs more verbose
+ * Manually tracing a Postfix daemon process
+ * Automatically tracing a Postfix daemon process
+ * Running daemon programs with the interactive ddd debugger
+ * Running daemon programs with the interactive gdb debugger
+ * Running daemon programs under a non-interactive debugger
+ * Unreasonable behavior
+ * Reporting problems to postfix-users@postfix.org
+
+LLooookk ffoorr oobbvviioouuss ssiiggnnss ooff ttrroouubbllee
+
+Postfix logs all failed and successful deliveries to a logfile. The file is
+usually called /var/log/maillog or /var/log/mail; the exact pathname is defined
+in the /etc/syslog.conf file.
+
+When Postfix does not receive or deliver mail, the first order of business is
+to look for errors that prevent Postfix from working properly:
+
+ % eeggrreepp ''((wwaarrnniinngg||eerrrroorr||ffaattaall||ppaanniicc))::'' //ssoommee//lloogg//ffiillee || mmoorree
+
+Note: the most important message is near the BEGINNING of the output. Error
+messages that come later are less useful.
+
+The nature of each problem is indicated as follows:
+
+ * "ppaanniicc" indicates a problem in the software itself that only a programmer
+ can fix. Postfix cannot proceed until this is fixed.
+
+ * "ffaattaall" is the result of missing files, incorrect permissions, incorrect
+ configuration file settings that you can fix. Postfix cannot proceed until
+ this is fixed.
+
+ * "eerrrroorr" reports an error condition. For safety reasons, a Postfix process
+ will terminate when more than 13 of these happen.
+
+ * "wwaarrnniinngg" indicates a non-fatal error. These are problems that you may not
+ be able to fix (such as a broken DNS server elsewhere on the network) but
+ may also indicate local configuration errors that could become a problem
+ later.
+
+DDeebbuuggggiinngg PPoossttffiixx ffrroomm iinnssiiddee
+
+Postfix version 2.1 and later can produce mail delivery reports for debugging
+purposes. These reports not only show sender/recipient addresses after address
+rewriting and alias expansion or forwarding, they also show information about
+delivery to mailbox, delivery to non-Postfix command, responses from remote
+SMTP servers, and so on.
+
+Postfix can produce two types of mail delivery reports for debugging:
+
+ * What-if: report what would happen, but do not actually deliver mail. This
+ mode of operation is requested with:
+
+ % //uussrr//ssbbiinn//sseennddmmaaiill --bbvv aaddddrreessss......
+ Mail Delivery Status Report will be mailed to .
+
+ * What happened: deliver mail and report successes and/or failures, including
+ replies from remote SMTP servers. This mode of operation is requested with:
+
+ % //uussrr//ssbbiinn//sseennddmmaaiill --vv aaddddrreessss......
+ Mail Delivery Status Report will be mailed to .
+
+These reports contain information that is generated by Postfix delivery agents.
+Since these run as daemon processes that cannot interact with users directly,
+the result is sent as mail to the sender of the test message. The format of
+these reports is practically identical to that of ordinary non-delivery
+notifications.
+
+For a detailed example of a mail delivery status report, see the debugging
+section at the end of the ADDRESS_REWRITING_README document.
+
+TTrryy ttuurrnniinngg ooffff cchhrroooott ooppeerraattiioonn iinn mmaasstteerr..ccff
+
+A common mistake is to turn on chroot operation in the master.cf file without
+going through all the necessary steps to set up a chroot environment. This
+causes Postfix daemon processes to fail due to all kinds of missing files.
+
+The example below shows an SMTP server that is configured with chroot turned
+off:
+
+ /etc/postfix/master.cf:
+ # =============================================================
+ # service type private unpriv cchhrroooott wakeup maxproc command
+ # (yes) (yes) ((yyeess)) (never) (100)
+ # =============================================================
+ smtp inet n - nn - - smtpd
+
+Inspect master.cf for any processes that have chroot operation not turned off.
+If you find any, save a copy of the master.cf file, and edit the entries in
+question. After executing the command "ppoossttffiixx rreellooaadd", see if the problem has
+gone away.
+
+If turning off chrooted operation made the problem go away, then
+congratulations. Leaving Postfix running in this way is adequate for most
+sites. If you prefer chrooted operation, see the Postfix
+BASIC_CONFIGURATION_README file for information about how to prepare Postfix
+for chrooted operation.
+
+VVeerrbboossee llooggggiinngg ffoorr ssppeecciiffiicc SSMMTTPP ccoonnnneeccttiioonnss
+
+In /etc/postfix/main.cf, list the remote site name or address in the
+debug_peer_list parameter. For example, in order to make the software log a lot
+of information to the syslog daemon for connections from or to the loopback
+interface:
+
+ /etc/postfix/main.cf:
+ debug_peer_list = 127.0.0.1
+
+You can specify one or more hosts, domains, addresses or net/masks. To make the
+change effective immediately, execute the command "ppoossttffiixx rreellooaadd".
+
+RReeccoorrdd tthhee SSMMTTPP sseessssiioonn wwiitthh aa nneettwwoorrkk ssnniiffffeerr
+
+This example uses ttccppdduummpp. In order to record a conversation you need to
+specify a large enough buffer with the "--ss" option or else you will miss some
+or all of the packet payload.
+
+ # ttccppdduummpp --ww //ffiillee//nnaammee --ss 00 hhoosstt eexxaammppllee..ccoomm aanndd ppoorrtt 2255
+
+Older tcpdump versions don't support "--ss 00"; in that case, use "--ss 22000000"
+instead.
+
+Run this for a while, stop with Ctrl-C when done. To view the data use a binary
+viewer, eetthheerreeaall, or good old lleessss.
+
+MMaakkiinngg PPoossttffiixx ddaaeemmoonn pprrooggrraammss mmoorree vveerrbboossee
+
+Append one or more "--vv" options to selected daemon definitions in /etc/postfix/
+master.cf and type "ppoossttffiixx rreellooaadd". This will cause a lot of activity to be
+logged to the syslog daemon. For example, to make the Postfix SMTP server
+process more verbose:
+
+ /etc/postfix/master.cf:
+ smtp inet n - n - - smtpd -v
+
+To diagnose problems with address rewriting specify a "--vv" option for the
+cleanup(8) and/or trivial-rewrite(8) daemon, and to diagnose problems with mail
+delivery specify a "--vv" option for the qmgr(8) or oqmgr(8) queue manager, or
+for the lmtp(8), local(8), pipe(8), smtp(8), or virtual(8) delivery agent.
+
+MMaannuuaallllyy ttrraacciinngg aa PPoossttffiixx ddaaeemmoonn pprroocceessss
+
+Many systems allow you to inspect a running process with a system call tracer.
+For example:
+
+ # ttrraaccee --pp pprroocceessss--iidd (SunOS 4)
+ # ssttrraaccee --pp pprroocceessss--iidd (Linux and many others)
+ # ttrruussss --pp pprroocceessss--iidd (Solaris, FreeBSD)
+ # kkttrraaccee --pp pprroocceessss--iidd (generic 4.4BSD)
+
+Even more informative are traces of system library calls. Examples:
+
+ # llttrraaccee --pp pprroocceessss--iidd (Linux, also ported to FreeBSD and BSD/OS)
+ # ssoottrruussss --pp pprroocceessss--iidd (Solaris)
+
+See your system documentation for details.
+
+Tracing a running process can give valuable information about what a process is
+attempting to do. This is as much information as you can get without running an
+interactive debugger program, as described in a later section.
+
+AAuuttoommaattiiccaallllyy ttrraacciinngg aa PPoossttffiixx ddaaeemmoonn pprroocceessss
+
+Postfix can attach a call tracer whenever a daemon process starts. Call tracers
+come in several kinds.
+
+ 1. System call tracers such as ttrraaccee, ttrruussss, ssttrraaccee, or kkttrraaccee. These show the
+ communication between the process and the kernel.
+
+ 2. Library call tracers such as ssoottrruussss and llttrraaccee. These show calls of
+ library routines, and give a better idea of what is going on within the
+ process.
+
+Append a --DD option to the suspect command in /etc/postfix/master.cf, for
+example:
+
+ /etc/postfix/master.cf:
+ smtp inet n - n - - smtpd -D
+
+Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes
+the call tracer of your choice, for example:
+
+ /etc/postfix/main.cf:
+ debugger_command =
+ PATH=/bin:/usr/bin:/usr/local/bin;
+ (truss -p $process_id 2>&1 | logger -p mail.info) & sleep 5
+
+Type "ppoossttffiixx rreellooaadd" and watch the logfile.
+
+RRuunnnniinngg ddaaeemmoonn pprrooggrraammss wwiitthh tthhee iinntteerraaccttiivvee dddddd ddeebbuuggggeerr
+
+If you have X Windows installed on the Postfix machine, then an interactive
+debugger such as dddddd can be convenient.
+
+Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes
+dddddd:
+
+ /etc/postfix/main.cf:
+ debugger_command =
+ PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
+ ddd $daemon_directory/$process_name $process_id & sleep 5
+
+Be sure that ggddbb is in the command search path, and export XXAAUUTTHHOORRIITTYY so that X
+access control works, for example:
+
+ % sseetteennvv XXAAUUTTHHOORRIITTYY ~~//..XXaauutthhoorriittyy (csh syntax)
+ $ eexxppoorrtt XXAAUUTTHHOORRIITTYY==$$HHOOMMEE//..XXaauutthhoorriittyy (sh syntax)
+
+Append a --DD option to the suspect daemon definition in /etc/postfix/master.cf,
+for example:
+
+ /etc/postfix/master.cf:
+ smtp inet n - n - - smtpd -D
+
+Stop and start the Postfix system. This is necessary so that Postfix runs with
+the proper XXAAUUTTHHOORRIITTYY and DDIISSPPLLAAYY settings.
+
+Whenever the suspect daemon process is started, a debugger window pops up and
+you can watch in detail what happens.
+
+RRuunnnniinngg ddaaeemmoonn pprrooggrraammss wwiitthh tthhee iinntteerraaccttiivvee ggddbb ddeebbuuggggeerr
+
+If you have the screen command installed on the Postfix machine, then you can
+run an interactive debugger such as ggddbb as follows.
+
+Edit the debugger_command definition in /etc/postfix/main.cf so that it runs
+ggddbb inside a detached ssccrreeeenn session:
+
+ /etc/postfix/main.cf:
+ debugger_command =
+ PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH; HOME=/root;
+ export HOME; screen -e^tt -dmS $process_name gdb
+ $daemon_directory/$process_name $process_id & sleep 2
+
+Be sure that ggddbb is in the command search path.
+
+Append a --DD option to the suspect daemon definition in /etc/postfix/master.cf,
+for example:
+
+ /etc/postfix/master.cf:
+ smtp inet n - n - - smtpd -D
+
+Execute the command "ppoossttffiixx rreellooaadd" and wait until a daemon process is started
+(you can see this in the maillog file).
+
+Then attach to the screen, and debug away:
+
+ # HOME=/root screen -r
+ gdb) continue
+ gdb) where
+
+RRuunnnniinngg ddaaeemmoonn pprrooggrraammss uunnddeerr aa nnoonn--iinntteerraaccttiivvee ddeebbuuggggeerr
+
+If you do not have X Windows installed on the Postfix machine, or if you are
+not familiar with interactive debuggers, then you can try to run ggddbb in non-
+interactive mode, and have it print a stack trace when the process crashes.
+
+Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes
+the ggddbb debugger:
+
+ /etc/postfix/main.cf:
+ debugger_command =
+ PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; echo
+ where; sleep 8640000) | gdb $daemon_directory/$process_name
+ $process_id 2>&1
+ >$config_directory/$process_name.$process_id.log & sleep 5
+
+Append a --DD option to the suspect daemon in /etc/postfix/master.cf, for
+example:
+
+ /etc/postfix/master.cf:
+ smtp inet n - n - - smtpd -D
+
+Type "ppoossttffiixx rreellooaadd" to make the configuration changes effective.
+
+Whenever a suspect daemon process is started, an output file is created, named
+after the daemon and process ID (for example, smtpd.12345.log). When the
+process crashes, a stack trace (with output from the "wwhheerree" command) is
+written to its logfile.
+
+UUnnrreeaassoonnaabbllee bbeehhaavviioorr
+
+Sometimes the behavior exhibited by Postfix just does not match the source
+code. Why can a program deviate from the instructions given by its author?
+There are two possibilities.
+
+ * The compiler has erred. This rarely happens.
+
+ * The hardware has erred. Does the machine have ECC memory?
+
+In both cases, the program being executed is not the program that was supposed
+to be executed, so anything could happen.
+
+There is a third possibility:
+
+ * Bugs in system software (kernel or libraries).
+
+Hardware-related failures usually do not reproduce in exactly the same way
+after power cycling and rebooting the system. There's little Postfix can do
+about bad hardware. Be sure to use hardware that at the very least can detect
+memory errors. Otherwise, Postfix will just be waiting to be hit by a bit
+error. Critical systems deserve real hardware.
+
+When a compiler makes an error, the problem can be reproduced whenever the
+resulting program is run. Compiler errors are most likely to happen in the code
+optimizer. If a problem is reproducible across power cycles and system reboots,
+it can be worthwhile to rebuild Postfix with optimization disabled, and to see
+if optimization makes a difference.
+
+In order to compile Postfix with optimizations turned off:
+
+ % mmaakkee ttiiddyy
+ % mmaakkee mmaakkeeffiilleess OOPPTT==
+
+This produces a set of Makefiles that do not request compiler optimization.
+
+Once the makefiles are set up, build the software:
+
+ % mmaakkee
+ % ssuu
+ Password:
+ # mmaakkee iinnssttaallll
+
+If the problem goes away, then it is time to ask your vendor for help.
+
+RReeppoorrttiinngg pprroobblleemmss ttoo ppoossttffiixx--uusseerrss@@ppoossttffiixx..oorrgg
+
+The people who participate on postfix-users@postfix.org are very helpful,
+especially if YOU provide them with sufficient information. Remember, these
+volunteers are willing to help, but their time is limited.
+
+When reporting a problem, be sure to include the following information.
+
+ * A summary of the problem. Please do not just send some logging without
+ explanation of what YOU believe is wrong.
+
+ * Complete error messages. Please use cut-and-paste, or use attachments,
+ instead of reciting information from memory.
+
+ * Postfix logging. See the text at the top of the DEBUG_README document to
+ find out where logging is stored. Please do not frustrate the helpers by
+ word wrapping the logging. If the logging is more than a few kbytes of
+ text, consider posting an URL on a web or ftp site.
+
+ * Consider using a test email address so that you don't have to reveal email
+ addresses or passwords of innocent people.
+
+ * If you can't use a test email address, please anonymize email addresses and
+ host names consistently. Replace each letter by "A", each digit by "D" so
+ that the helpers can still recognize syntactical errors.
+
+ * Command output from:
+
+ o "ppoossttccoonnff --nn". Please do not send your main.cf file, or 1000+ lines of
+ ppoossttccoonnff command output.
+
+ o "ppoossttccoonnff --MMff" (Postfix 2.9 or later).
+
+ * Better, provide output from the ppoossttffiinnggeerr tool. This can be found at http:
+ //ftp.wl0.org/SOURCES/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/.
+
+ * If the problem is about too much mail in the queue, consider including
+ output from the qqsshhaappee tool, as described in the QSHAPE_README file.
+
+ * If the problem is protocol related (connections time out, or an SMTP server
+ complains about syntax errors etc.) consider recording a session with
+ ttccppdduummpp, as described in the DEBUG_README document.
+
diff --git a/README_FILES/DSN_README b/README_FILES/DSN_README
new file mode 100644
index 0000000..efd7f4c
--- /dev/null
+++ b/README_FILES/DSN_README
@@ -0,0 +1,98 @@
+PPoossttffiixx DDSSNN SSuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix version 2.3 introduces support for Delivery Status Notifications as
+described in RFC 3464. This gives senders control over successful and failed
+delivery notifications.
+
+Specifically, DSN support gives an email sender the ability to specify:
+
+ * What notifications are sent: success, failure, delay, or none. Normally,
+ Postfix informs the sender only when mail delivery is delayed or when
+ delivery fails.
+
+ * What content is returned in case of failure: only the message headers, or
+ the full message.
+
+ * An envelope ID that is returned as part of delivery status notifications.
+ This identifies the message submission transaction, and must not be
+ confused with the message ID, which identifies the message content.
+
+The implementation of DSN support involves extra parameters to the SMTP MAIL
+FROM and RCPT TO commands, as well as two Postfix sendmail command line options
+that provide a sub-set of the functions of the extra SMTP command parameters.
+
+This document has information on the following topics:
+
+ * Restricting the scope of "success" notifications
+ * Postfix sendmail command-line interface
+ * Postfix VERP support compatibility
+
+RReessttrriiccttiinngg tthhee ssccooppee ooff ""ssuucccceessss"" nnoottiiffiiccaattiioonnss
+
+Just like reports of undeliverable mail, DSN reports of successful delivery can
+give away more information about the internal infrastructure than desirable.
+Unfortunately, disallowing "success" notification requests requires disallowing
+other DSN requests as well. The RFCs do not offer the option to negotiate
+feature subsets.
+
+This is not as bad as it sounds. When you turn off DSN for remote inbound mail,
+remote senders with DSN support will still be informed that their mail reached
+your Postfix gateway successfully; they just will not get successful delivery
+notices from your internal systems. Remote senders lose very little: they can
+no longer specify how Postfix should report delayed or failed delivery.
+
+Use the smtpd_discard_ehlo_keyword_address_maps feature if you wish to allow
+DSN requests from trusted clients but not from random strangers (see below for
+how to turn this off for all clients):
+
+ /etc/postfix/main.cf:
+ smtpd_discard_ehlo_keyword_address_maps =
+ cidr:/etc/postfix/esmtp_access
+
+ /etc/postfix/esmtp_access:
+ # Allow DSN requests from local subnet only
+ 192.168.0.0/28 silent-discard
+ 0.0.0.0/0 silent-discard, dsn
+ ::/0 silent-discard, dsn
+
+If you want to disallow all use of DSN requests from the network, use the
+smtpd_discard_ehlo_keywords feature:
+
+ /etc/postfix/main.cf:
+ smtpd_discard_ehlo_keywords = silent-discard, dsn
+
+PPoossttffiixx sseennddmmaaiill ccoommmmaanndd--lliinnee iinntteerrffaaccee
+
+Postfix has two Sendmail-compatible command-line options for DSN support.
+
+ * The first option specifies what notifications are sent for mail that is
+ submitted via the Postfix sendmail(1) command line:
+
+ $ sseennddmmaaiill --NN ssuucccceessss,,ddeellaayy,,ffaaiilluurree ...... (one or more of these)
+ $ sseennddmmaaiill --NN nneevveerr ...... (or just this by itself)
+
+ The built-in default corresponds with "delay,failure".
+
+ * The second option specifies an envelope ID which is reported in delivery
+ status notifications for mail that is submitted via the Postfix sendmail(1)
+ command line:
+
+ $ sseennddmmaaiill --VV eennvveellooppee--iidd ......
+
+ Note: this conflicts with VERP support in older Postfix versions, as
+ discussed in the next section.
+
+PPoossttffiixx VVEERRPP ssuuppppoorrtt ccoommppaattiibbiilliittyy
+
+With Postfix versions before 2.3, the sendmail(1) command uses the -V command-
+line option to request VERP-style delivery. In order to request VERP style
+delivery with Postfix 2.3 and later, you must specify -XV instead of -V.
+
+The Postfix 2.3 sendmail(1) command will recognize if you try to use -V for
+VERP-style delivery. It will do the right thing and will remind you of the new
+syntax.
+
diff --git a/README_FILES/ETRN_README b/README_FILES/ETRN_README
new file mode 100644
index 0000000..76bc8de
--- /dev/null
+++ b/README_FILES/ETRN_README
@@ -0,0 +1,250 @@
+PPoossttffiixx EETTRRNN HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
+
+The SMTP ETRN command was designed for sites that have intermittent Internet
+connectivity. With ETRN, a site can tell the mail server of its provider to
+"Please deliver all my mail now". The SMTP server searches the queue for mail
+to the customer, and delivers that mail bbyy ccoonnnneeccttiinngg ttoo tthhee ccuussttoommeerr''ss SSMMTTPP
+sseerrvveerr. The mail is not delivered via the connection that was used for sending
+ETRN.
+
+As of version 1.0, Postfix has a fast ETRN implementation that does not require
+Postfix to examine every queue file. Instead, Postfix maintains a record of
+what queue files contain mail for destinations that are configured for ETRN
+service. ETRN service is no longer available for domains that aren't configured
+for the service.
+
+This document provides information on the following topics:
+
+ * Using the Postfix fast ETRN service
+ * How Postfix fast ETRN works
+ * Postfix fast ETRN service limitations
+ * Configuring the Postfix fast ETRN service
+ * Configuring a domain for ETRN service only
+ * Testing the Postfix fast ETRN service
+
+Other documents with information on this subject:
+
+ * flush(8), flush service implementation
+
+UUssiinngg tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
+
+The following is an example SMTP session that shows how an SMTP client requests
+the ETRN service. Client commands are shown in bold font.
+
+ 220 my.server.tld ESMTP Postfix
+ HHEELLOO mmyy..cclliieenntt..ttlldd
+ 250 Ok
+ EETTRRNN ssoommee..ccuussttoommeerr..ddoommaaiinn
+ 250 Queuing started
+ QQUUIITT
+ 221 Bye
+
+As mentioned in the introduction, the mail is delivered by connecting to the
+customer's SMTP server; it is not sent over the connection that was used to
+send the ETRN command.
+
+The Postfix operator can request delivery for a specific customer by using the
+command "sendmail -qRdestination" and, with Postfix version 1.1 and later,
+"postqueue -sdestination". Access to this feature is controlled with the
+authorized_flush_users configuration parameter (Postfix version 2.2 and later).
+
+HHooww PPoossttffiixx ffaasstt EETTRRNN wwoorrkkss
+
+When a Postfix delivery agent decides that mail must be delivered later, it
+sends the destination domain name and the queue file name to the flush(8)
+daemon which maintains per-destination logfiles with file names of queued mail.
+These logfiles are kept below $queue_directory/flush. Per-destination logfiles
+are maintained only for destinations that are listed with the
+$fast_flush_domains parameter and that have syntactically valid domain names.
+
+ Postfix Postfix One logfile
+ delivery -(domain, queue ID)-> flush -(queue ID)-> per eligible
+ agent daemon domain
+
+When Postfix receives a request to "deliver mail for a domain now", the flush
+(8) daemon moves all deferred queue files that are listed for that domain to
+the incoming queue, and requests that the queue manager deliver them. In order
+to force delivery, the queue manager temporarily ignores the lists of
+undeliverable destinations: the volatile in-memory list of dead domains, and
+the list of message delivery transports specified with the defer_transports
+configuration parameter.
+
+PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee lliimmiittaattiioonnss
+
+The design of the flush(8) server and of the flush queue introduce a few
+limitations that should not be an issue unless you want to turn on fast ETRN
+service for every possible destination.
+
+ * The flush(8) daemon maintains per-destination logfiles with queue file
+ names. When a request to "deliver mail now" arrives, Postfix will attempt
+ to deliver all recipients in the queue files that have mail for the
+ destination in question. This does not perform well with queue files that
+ have recipients in many different domains, such as queue files with
+ outbound mailing list traffic.
+
+ * The flush(8) daemon maintains per-destination logfiles only for
+ destinations listed with $fast_flush_domains. With other destinations you
+ cannot request delivery with "sendmail -qRdestination" or, with Postfix
+ version 1.1 and later, "postqueue -sdestination".
+
+ * Up to and including early versions of Postfix version 2.1, the "fast flush"
+ service may not deliver some messages if the request to "deliver mail now"
+ is received while a deferred queue scan is already in progress. The reason
+ is that the queue manager does not ignore the volatile in-memory list of
+ dead domains, and the list of message delivery transports specified with
+ the defer_transports configuration parameter.
+
+ * Up to and including Postfix version 2.3, the "fast flush" service may not
+ deliver some messages if the request to "deliver mail now" arrives while an
+ incoming queue scan is already in progress.
+
+CCoonnffiigguurriinngg tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
+
+The behavior of the flush(8) daemon is controlled by parameters in the main.cf
+configuration file.
+
+By default, Postfix "fast ETRN" service is available only for destinations that
+Postfix is willing to relay mail to:
+
+ /etc/postfix/main.cf:
+ fast_flush_domains = $relay_domains
+ smtpd_etrn_restrictions = permit_mynetworks, reject
+
+Notes:
+
+ * The relay_domains parameter specifies what destinations Postfix will relay
+ to. For destinations that are not eligible for the "fast ETRN" service,
+ Postfix replies with an error message.
+
+ * The smtpd_etrn_restrictions parameter limits what clients may execute the
+ ETRN command. By default, any client has permission.
+
+To enable "fast ETRN" for some other destination, specify:
+
+ /etc/postfix/main.cf:
+ fast_flush_domains = $relay_domains, some.other.domain
+
+To disable "fast ETRN", so that Postfix rejects all ETRN requests and so that
+it maintains no per-destination logfiles, specify:
+
+ /etc/postfix/main.cf:
+ fast_flush_domains =
+
+CCoonnffiigguurriinngg aa ddoommaaiinn ffoorr EETTRRNN sseerrvviiccee oonnllyy
+
+While an "ETRN" customer is off-line, Postfix will make spontaneous attempts to
+deliver mail to it. These attempts are separated in time by increasing time
+intervals, ranging from $minimal_backoff_time to $maximal_backoff_time, and
+should not be a problem unless a lot of mail is queued.
+
+To prevent Postfix from making spontaneous delivery attempts you can configure
+Postfix to always defer mail for the "ETRN" customer. Mail is delivered only
+after the ETRN command or with "sendmail -q", with "sendmail -qRdomain", or
+with "postqueue -sdomain"(Postfix version 1.1 and later only),
+
+In the example below we configure an "etrn-only" delivery transport which is
+simply a duplicate of the "smtp" and "relay" mail delivery transports. The only
+difference is that mail destined for this delivery transport is deferred as
+soon as it arrives.
+
+ 1 /etc/postfix/master.cf:
+ 2 # =============================================================
+ 3 # service type private unpriv chroot wakeup maxproc command
+ 4 # (yes) (yes) (yes) (never) (100)
+ 5 # =============================================================
+ 6 smtp unix - - n - - smtp
+ 7 relay unix - - n - - smtp
+ 8 etrn-only unix - - n - - smtp
+ 9
+ 10 /etc/postfix/main.cf:
+ 11 relay_domains = customer.tld ...other domains...
+ 12 defer_transports = etrn-only
+ 13 transport_maps = hash:/etc/postfix/transport
+ 14
+ 15 /etc/postfix/transport:
+ 16 customer.tld etrn-only:[mailhost.customer.tld]
+
+Translation:
+
+ * Line 8: The "etrn-only" mail delivery service is a copy of the "smtp" and
+ "relay" service.
+
+ * Line 11: Don't forget to authorize relaying for this customer, either via
+ relay_domains or with the permit_mx_backup feature.
+
+ * Line 12: The "etrn-only" mail delivery service is configured so that
+ spontaneous mail delivery is disabled.
+
+ * Lines 13-16: Mail for the customer is given to the "etrn-only" mail
+ delivery service.
+
+ * Line 16: The "[mailhost.customer.tld]" turns off MX record lookups; you
+ must specify this if your Postfix server is the primary MX host for the
+ customer's domain.
+
+TTeessttiinngg tthhee PPoossttffiixx ffaasstt EETTRRNN sseerrvviiccee
+
+By default, "fast ETRN" service is enabled for all domains that match
+$relay_domains. If you run Postfix with "fast ETRN" service for the very first
+time, you need to run "sendmail -q" once in order to populate the per-site
+deferred mail logfiles. If you omit this step, no harm is done. The logfiles
+will eventually become populated as Postfix routinely attempts to deliver
+delayed mail, but that will take a couple hours. After the "sendmail -q"
+command has completed all delivery attempts (this can take a while), you're
+ready to test the "fast ETRN" service.
+
+To test the "fast ETRN" service, telnet to the Postfix SMTP server from a
+client that is allowed to execute ETRN commands (by default, that's every
+client), and type the commands shown in boldface:
+
+ 220 my.server.tld ESMTP Postfix
+ HHEELLOO mmyy..cclliieenntt..ttlldd
+ 250 Ok
+ EETTRRNN ssoommee..ccuussttoommeerr..ddoommaaiinn
+ 250 Queuing started
+
+where "some.customer.domain" is the name of a domain that has a non-empty
+logfile somewhere under $queue_directory/flush.
+
+In the maillog file, you should immediately see a couple of logfile records, as
+evidence that the queue manager has opened queue files:
+
+ Oct 2 10:51:19 myhostname postfix/qmgr[51999]: 682E8440A4:
+ from=, size=12345, nrcpt=1 (queue active)
+ Oct 2 10:51:19 myhostname postfix/qmgr[51999]: 02249440B7:
+ from=, size=4711, nrcpt=1 (queue active)
+
+What happens next depends on whether the destination is reachable. If it's not
+reachable, the mail queue IDs will be added back to the some.customer.domain
+logfile under $queue_directory/flush.
+
+Repeat the exercise with some other destination that your server is willing to
+relay to (any domain listed in $relay_domains), but that has no mail queued.
+The text in bold face stands for the commands that you type:
+
+ 220 my.server.tld ESMTP Postfix
+ HHEELLOO mmyy..cclliieenntt..ttlldd
+ 250 Ok
+ EETTRRNN ssoommee..ootthheerr..ccuussttoommeerr..ddoommaaiinn
+ 250 Queuing started
+
+This time, the "ETRN"" command should trigger NO mail deliveries at all. If
+this triggers delivery of all mail, then you used the wrong domain name, or
+"fast ETRN" service is turned off.
+
+Finally, repeat the exercise with a destination that your mail server is not
+willing to relay to. It does not matter if your server has mail queued for that
+destination.
+
+ 220 my.server.tld ESMTP Postfix
+ HHEELLOO mmyy..cclliieenntt..ttlldd
+ 250 Ok
+ EETTRRNN nnoott..aa..ccuussttoommeerr..ddoommaaiinn
+ 459 : service unavailable
+
+In this case, Postfix should reject the request as shown above.
+
diff --git a/README_FILES/FILTER_README b/README_FILES/FILTER_README
new file mode 100644
index 0000000..bbe2adb
--- /dev/null
+++ b/README_FILES/FILTER_README
@@ -0,0 +1,617 @@
+PPoossttffiixx AAfftteerr--QQuueeuuee CCoonntteenntt FFiilltteerr
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+This document requires Postfix version 2.1 or later.
+
+Normally, Postfix receives mail, stores it in the mail queue and then delivers
+it. With the external content filter described here, mail is filtered AFTER it
+is queued. This approach decouples mail receiving processes from mail filtering
+processes, and gives you maximal control over how many filtering processes you
+are willing to run in parallel.
+
+The after-queue content filter is meant to be used as follows:
+
+ Network or -> Postfix -> CCoonntteenntt -> Postfix -> Network or
+ local users queue ffiilltteerr queue local mailbox
+
+This document describes implementations that use a single Postfix instance for
+everything: receiving, filtering and delivering mail. Applications that use two
+separate Postfix instances will be covered by a later version of this document.
+
+The after-queue content filter is not to be confused with the approaches
+described in the SMTPD_PROXY_README or MILTER_README documents, where incoming
+SMTP mail is filtered BEFORE it is stored into the Postfix queue.
+
+This document describes two approaches to content filter all email, as well as
+several options to filter mail selectively:
+
+ * Principles of operation
+ * Simple content filter
+
+ o Simple content filter example
+ o Simple content filter performance
+ o Simple content filter limitations
+ o Turning off the simple content filter
+
+ * Advanced content filter
+
+ o Advanced content filter example
+ o Advanced content filter performance
+ o Turning off the advanced content filter
+
+ * Selective content filtering
+
+ o Filtering mail from outside users only
+ o Different filters for different domains
+ o FILTER actions in access or header/body tables
+
+PPrriinncciipplleess ooff ooppeerraattiioonn
+
+An after-queue content filter receives unfiltered mail from Postfix (as
+described further below) and can do one of the following:
+
+ 1. Re-inject the mail back into Postfix, perhaps after changing content and/or
+ destination.
+
+ 2. Discard or quarantine the mail.
+
+ 3. Reject the mail (by sending a suitable status code back to Postfix).
+ Postfix will send the mail back to the sender address.
+
+NOTE: in this time of mail worms and forged spam, it is a VERY BAD IDEA to send
+viruses back to the sender address, because the sender address is almost
+certainly not the originator. It is better to discard known viruses, and to
+quarantine material that is suspect so that a human can decide what to do with
+it.
+
+SSiimmppllee ccoonntteenntt ffiilltteerr eexxaammppllee
+
+The first example is simple to set up, but has major limitations that will be
+addressed in a second example. Postfix receives unfiltered mail from the
+network with the smtpd(8) server, and delivers unfiltered mail to a content
+filter with the Postfix pipe(8) delivery agent. The content filter injects
+filtered mail back into Postfix with the Postfix sendmail(1) command, so that
+Postfix can deliver it to the final destination.
+
+This means that mail submitted via the Postfix sendmail(1) command cannot be
+content filtered.
+
+In the figure below, names followed by a number represent Postfix commands or
+daemon programs. See the OVERVIEW document for an introduction to the Postfix
+architecture.
+
+ Unfiltered -> smtpd(8) qmgr(8) local(8) -> Filtered
+ >- cleanup(8) -> Postfix -< smtp(8) -> Filtered
+ pickup(8) queue pipe(8)
+
+ ^ |
+ | v
+
+ maildrop Postfix Postfix Content
+ queue <- postdrop <- sendmail <- filter
+ (1) (1)
+
+The content filter can be a simple shell script like this:
+
+ 1 #!/bin/sh
+ 2
+ 3 # Simple shell-based filter. It is meant to be invoked as follows:
+ 4 # /path/to/script -f sender recipients...
+ 5
+ 6 # Localize these. The -G option does nothing before Postfix 2.3.
+ 7 INSPECT_DIR=/var/spool/filter
+ 8 SENDMAIL="/usr/sbin/sendmail -G -i" # NEVER NEVER NEVER use "-t" here.
+ 9
+ 10 # Exit codes from
+ 11 EX_TEMPFAIL=75
+ 12 EX_UNAVAILABLE=69
+ 13
+ 14 # Clean up when done or when aborting.
+ 15 trap "rm -f in.$$" 0 1 2 3 15
+ 16
+ 17 # Start processing.
+ 18 cd $INSPECT_DIR || {
+ 19 echo $INSPECT_DIR does not exist; exit $EX_TEMPFAIL; }
+ 20
+ 21 cat >in.$$ || {
+ 22 echo Cannot save mail to file; exit $EX_TEMPFAIL; }
+ 23
+ 24 # Specify your content filter here.
+ 25 # filter smtpd(8) qmgr(8) smtp(8) -> Filtered
+ >- cleanup(8) -> Postfix -<
+ Unfiltered -> pickup(8) queue local(8) -> Filtered
+
+ ^ |
+ | v
+
+ smtpd(8) smtp(8)
+ 10026
+
+ ^ |
+ | v
+
+ content filter 10025
+
+The example given here filters all mail, including mail that arrives via SMTP
+and mail that is locally submitted via the Postfix sendmail command (local
+submissions enter Postfix via the pickup(8) server; to keep the figure simple
+we omit local submission details). See examples near the end of this document
+for how to exclude local users from filtering, or how to configure a
+destination dependent content filter.
+
+You can expect to lose about a factor of two in Postfix performance for mail
+that arrives and leaves via SMTP, provided that the content filter creates no
+temporary files. Each temporary file created by the content filter adds another
+factor to the performance loss.
+
+AAddvvaanncceedd ccoonntteenntt ffiilltteerr:: rreeqquueessttiinngg tthhaatt aallll mmaaiill iiss ffiilltteerreedd
+
+To enable the advanced content filter method for all mail, specify in main.cf:
+
+ /etc/postfix/main.cf:
+ content_filter = scan:localhost:10025
+ receive_override_options = no_address_mappings
+
+ * The "receive_override_options" line disables address manipulation before
+ the content filter, so that the content filter sees the original mail
+ addresses instead of the result of virtual alias expansion, canonical
+ mapping, automatic bcc, address masquerading, etc.
+
+ * The "content_filter" line causes Postfix to add one content filter request
+ record to each incoming mail message, with content "scan:localhost:10025".
+ The content filter request records are added by the smtpd(8) and pickup(8)
+ servers (and qmqpd(8) if you decide to enable this service).
+
+ * Content filter requests are stored in queue files; this is how Postfix
+ keeps track of what mail needs filtering. When a queue file contains a
+ content filter request, the queue manager will deliver the mail to the
+ specified content filter regardless of its final destination.
+
+ * The content_filter configuration parameter expects a value of the form
+ transport:destination. The transport name specifies the first field of a
+ mail delivery agent definition in master.cf; the syntax of the next-hop
+ destination is described in the manual page of the corresponding delivery
+ agent.
+
+ * The meaning of an empty next-hop filter destination is version dependent.
+ Postfix 2.7 and later will use the recipient domain; earlier versions will
+ use $myhostname. Specify "default_filter_nexthop = $myhostname" for
+ compatibility with Postfix 2.6 or earlier, or specify a non-empty next-hop
+ filter destination.
+
+ * The content_filter setting has lower precedence than a FILTER action that
+ is specified in an access(5), header_checks(5) or body_checks(5) table.
+
+AAddvvaanncceedd ccoonntteenntt ffiilltteerr:: sseennddiinngg uunnffiilltteerreedd mmaaiill ttoo tthhee ccoonntteenntt ffiilltteerr
+
+In this example, "scan" is an instance of the Postfix SMTP client with slightly
+different configuration parameters. This is how one would set up the service in
+the Postfix master.cf file:
+
+ /etc/postfix/master.cf:
+ # =============================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =============================================================
+ scan unix - - n - 10 smtp
+ -o smtp_send_xforward_command=yes
+ -o disable_mime_output_conversion=yes
+ -o smtp_generic_maps=
+
+ * This runs up to 10 content filters in parallel. Instead of a limit of 10
+ concurrent processes, use whatever process limit is feasible for your
+ machine. Content inspection software can gobble up a lot of system
+ resources, so you don't want to have too much of it running at the same
+ time.
+
+ * With "-o smtp_send_xforward_command=yes", the scan transport will try to
+ forward the original client name and IP address through the content filter
+ to the after-filter smtpd process, so that filtered mail is logged with the
+ real client name IP address. See smtp(8) and XFORWARD_README for more
+ information.
+
+ * The "-o disable_mime_output_conversion=yes" is a workaround that prevents
+ the breaking of domainkeys and other digital signatures. This is needed
+ because some SMTP-based content filters don't announce 8BITMIME support,
+ even though they can handle 8-bit mail.
+
+ * The "-o smtp_generic_maps=" is a workaround that prevents local address
+ rewriting with generic(5) maps. Such rewriting should happen only when mail
+ is sent out to the Internet.
+
+AAddvvaanncceedd ccoonntteenntt ffiilltteerr:: rruunnnniinngg tthhee ccoonntteenntt ffiilltteerr
+
+The content filter can be set up with the Postfix spawn service, which is the
+Postfix equivalent of inetd. For example, to instantiate up to 10 content
+filtering processes on localhost port 10025:
+
+ /etc/postfix/master.cf:
+ # ===================================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # ===================================================================
+ localhost:10025 inet n n n - 10 spawn
+ user=filter argv=/path/to/filter localhost 10026
+
+ * "filter" is a dedicated local user account. The user will never log in, and
+ can be given a "*" password and non-existent shell and home directory. This
+ user handles all potentially dangerous mail content - that is why it should
+ be a separate account.
+
+ * By default, Postfix will terminate a command that runs longer than
+ command_time_limit seconds (default: 1000s). This is a safety measure that
+ prevents filters from running forever.
+
+If you want to have your filter listening on port localhost:10025 instead of
+Postfix, then you must run your filter as a stand-alone program, and must not
+use the Postfix spawn service.
+
+AAddvvaanncceedd ffiilltteerr:: iinnjjeeccttiinngg mmaaiill bbaacckk iinnttoo PPoossttffiixx
+
+The job of the content filter is to either bounce mail with a suitable
+diagnostic, or to feed the mail back into Postfix through a dedicated listener
+on port localhost 10026.
+
+The simplest content filter just copies SMTP commands and data between its
+inputs and outputs. If it has a problem, all it has to do is to reply to an
+input of `.' from Postfix with `550 content rejected', and to disconnect
+without sending `.' on the connection that injects mail back into Postfix.
+
+ /etc/postfix/master.cf:
+ # ===================================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # ===================================================================
+ localhost:10026 inet n - n - 10 smtpd
+ -o content_filter=
+ -
+ o
+ receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters
+ -o smtpd_helo_restrictions=
+ -o smtpd_client_restrictions=
+ -o smtpd_sender_restrictions=
+ # Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
+ -o smtpd_relay_restrictions=
+ -o smtpd_recipient_restrictions=permit_mynetworks,reject
+ -o mynetworks=127.0.0.0/8
+ -o smtpd_authorized_xforward_hosts=127.0.0.0/8
+
+ * NOTE: do not use spaces around the "=" or "," characters.
+
+ * NOTE: the SMTP server must not have a smaller process limit than the
+ "filter" master.cf entry.
+
+ * The "-o content_filter=" overrides main.cf settings, and requests no
+ content filtering for mail from the content filter. This is required or
+ else mail will loop.
+
+ * The "-o receive_override_options" overrides main.cf settings to avoid
+ duplicating work that was already done before the content filter. These
+ options are complementary to the options that are specified in main.cf:
+
+ o We specify "no_unknown_recipient_checks" to disable attempts to find
+ out if a recipient is unknown.
+
+ o We specify "no_header_body_checks" to disable header/body checks.
+
+ o We specify "no_milters" to disable Milter applications (this option is
+ available only in Postfix 2.3 and later).
+
+ o We don't specify "no_address_mappings" here. This enables virtual alias
+ expansion, canonical mappings, address masquerading, and other address
+ mappings after the content filter. The main.cf setting of
+ "receive_override_options" disables these mappings before the content
+ filter.
+
+ These receive override options are either implemented by the SMTP server
+ itself, or they are passed on to the cleanup server.
+
+ * The "-o smtpd_xxx_restrictions" and "-o mynetworks=127.0.0.0/8" override
+ main.cf settings. They turn off junk mail controls that would only waste
+ time here.
+
+ * With "-o smtpd_authorized_xforward_hosts=127.0.0.0/8", the scan transport
+ will try to forward the original client name and IP address to the after-
+ filter smtpd process, so that filtered mail is logged with the real client
+ name and IP address. See XFORWARD_README and smtpd(8).
+
+AAddvvaanncceedd ccoonntteenntt ffiilltteerr ppeerrffoorrmmaannccee
+
+With the "sandwich" approach to content filtering described here, it is
+important to match the filter concurrency to the available CPU, memory and I/
+O resources. Too few content filter processes and mail accumulates in the
+active queue even with low traffic volume; too much concurrency and Postfix
+ends up deferring mail destined for the content filter because processes fail
+due to insufficient resources.
+
+Currently, content filter performance tuning is a process of trial and error;
+analysis is handicapped because filtered and unfiltered messages share the same
+queue. As mentioned in the introduction of this document, content filtering
+with multiple Postfix instances will be covered in a future version.
+
+TTuurrnniinngg ooffff tthhee aaddvvaanncceedd ccoonntteenntt ffiilltteerr
+
+To turn off "advanced" content filtering:
+
+ * Delete or comment out the two following main.cf lines. The other changes
+ made for advanced content filtering have no effect when content filtering
+ is turned off.
+
+ /etc/postfix/main.cf:
+ content_filter = scan:localhost:10025
+ receive_override_options = no_address_mappings
+
+ * Execute "ppoossttssuuppeerr --rr AALLLL" to remove content filter request records from
+ existing queue files.
+
+ * Execute another "ppoossttffiixx rreellooaadd".
+
+FFiilltteerriinngg mmaaiill ffrroomm oouuttssiiddee uusseerrss oonnllyy
+
+The easiest approach is to configure ONE Postfix instance with multiple SMTP
+server IP addresses in master.cf:
+
+ * Two SMTP server IP addresses for mail from inside users only, with content
+ filtering turned off.
+
+ /etc/postfix.master.cf:
+ # ==================================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # ==================================================================
+ 1.2.3.4:smtp inet n - n - - smtpd
+ -o smtpd_client_restrictions=permit_mynetworks,reject
+ 127.0.0.1:smtp inet n - n - - smtpd
+ -o smtpd_client_restrictions=permit_mynetworks,reject
+
+ * One SMTP server address for mail from outside users with content filtering
+ turned on.
+
+ /etc/postfix.master.cf:
+ # =================================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =================================================================
+ 1.2.3.5:smtp inet n - n - - smtpd
+ -o content_filter=filter-service:filter-destination
+ -o receive_override_options=no_address_mappings
+
+After this, you can follow the same procedure as outlined in the "advanced" or
+"simple" content filtering examples above, except that you must not specify
+"content_filter" or "receive_override_options" in the main.cf file.
+
+DDiiffffeerreenntt ffiilltteerrss ffoorr ddiiffffeerreenntt ddoommaaiinnss
+
+If you are an MX service provider and want to apply different content filters
+for different domains, you can configure ONE Postfix instance with multiple
+SMTP server IP addresses in master.cf. Each address provides a different
+content filter service.
+
+ /etc/postfix.master.cf:
+ # =================================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =================================================================
+ # SMTP service for domains that are filtered with service1:dest1
+ 1.2.3.4:smtp inet n - n - - smtpd
+ -o content_filter=service1:dest1
+ -o receive_override_options=no_address_mappings
+
+ # SMTP service for domains that are filtered with service2:dest2
+ 1.2.3.5:smtp inet n - n - - smtpd
+ -o content_filter=service2:dest2
+ -o receive_override_options=no_address_mappings
+
+After this, you can follow the same procedure as outlined in the "advanced" or
+"simple" content filtering examples above, except that you must not specify
+"content_filter" or "receive_override_options" in the main.cf file.
+
+Set up MX records in the DNS that route each domain to the proper SMTP server
+instance.
+
+FFIILLTTEERR aaccttiioonnss iinn aacccceessss oorr hheeaaddeerr//bbooddyy ttaabblleess
+
+The above filtering configurations are static. Mail that follows a given path
+is either always filtered or it is never filtered. As of Postfix 2.0 you can
+also turn on content filtering on the fly.
+
+To turn on content filtering with an access(5) table rule:
+
+ /etc/postfix/access:
+ whatever FILTER foo:bar
+
+To turn on content filtering with a header_checks(5) or body_checks(5) table
+pattern:
+
+ /etc/postfix/header_checks:
+ /whatever/ FILTER foo:bar
+
+You can do this in smtpd access maps as well as the cleanup server's header/
+body_checks. This feature must be used with great care: you must disable all
+the UCE features in the after-filter smtpd and cleanup daemons or else you will
+have a content filtering loop.
+
+Limitations:
+
+ * FILTER actions from smtpd access maps and header/body_checks take
+ precedence over filters specified with the main.cf content_filter
+ parameter.
+
+ * If a message triggers more than one filter action, only the last one takes
+ effect.
+
+ * The same content filter is applied to all the recipients of a given
+ message.
+
diff --git a/README_FILES/FORWARD_SECRECY_README b/README_FILES/FORWARD_SECRECY_README
new file mode 100644
index 0000000..fb40e4d
--- /dev/null
+++ b/README_FILES/FORWARD_SECRECY_README
@@ -0,0 +1,429 @@
+ TTLLSS FFoorrwwaarrdd SSeeccrreeccyy iinn PPoossttffiixx
+
+-------------------------------------------------------------------------------
+
+WWaarrnniinngg
+
+Forward secrecy does not protect against active attacks such as forged DNS
+replies or forged TLS server certificates. If such attacks are a concern, then
+the SMTP client will need to authenticate the remote SMTP server in a
+sufficiently-secure manner. For example, by the fingerprint of a (CA or leaf)
+public key or certificate. Conventional PKI relies on many trusted parties and
+is easily subverted by a state-funded adversary.
+
+OOvveerrvviieeww
+
+Postfix supports forward secrecy of TLS network communication since version
+2.2. This support was adopted from Lutz Jänicke's "Postfix TLS patch" for
+earlier Postfix versions. This document will focus on TLS Forward Secrecy in
+the Postfix SMTP client and server. See TLS_README for a general description of
+Postfix TLS support.
+
+Topics covered in this document:
+
+ * Give me some background on forward secrecy in Postfix
+
+ o What is Forward Secrecy
+ o Forward Secrecy in TLS
+ o Forward Secrecy in the Postfix SMTP Server
+ o Forward Secrecy in the Postfix SMTP Client
+
+ * Never mind, just show me what it takes to get forward secrecy
+
+ o Getting started, quick and dirty
+ o How can I see that a connection has forward secrecy?
+ o What ciphers provide forward secrecy?
+ o What do "Anonymous", "Untrusted", etc. in Postfix logging mean?
+
+ * Credits
+
+WWhhaatt iiss FFoorrwwaarrdd SSeeccrreeccyy
+
+The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy") is used to
+describe security protocols in which the confidentiality of past traffic is not
+compromised when long-term keys used by either or both sides are later
+disclosed.
+
+Forward secrecy is accomplished by negotiating session keys using per-session
+cryptographically-strong random numbers that are not saved, and signing the
+exchange with long-term authentication keys. Later disclosure of the long-term
+keys allows impersonation of the key holder from that point on, but not
+recovery of prior traffic, since with forward secrecy, the discarded random key
+agreement inputs are not available to the attacker.
+
+Forward secrecy is only "perfect" when brute-force attacks on the key agreement
+algorithm are impractical even for the best-funded adversary and the random-
+number generators used by both parties are sufficiently strong. Otherwise,
+forward secrecy leaves the attacker with the challenge of cracking the key-
+agreement protocol, which is likely quite computationally intensive, but may be
+feasible for sessions of sufficiently high value. Thus forward secrecy places
+cost constraints on the efficacy of bulk surveillance, recovering all past
+traffic is generally infeasible, and even recovery of individual sessions may
+be infeasible given a sufficiently-strong key agreement method.
+
+FFoorrwwaarrdd SSeeccrreeccyy iinn TTLLSS
+
+Early implementations of the SSL protocol do not provide forward secrecy (some
+provide it only with artificially-weakened "export" cipher suites, but we will
+ignore those here). The client sends a random "pre-master secret" to the server
+encrypted with the server's RSA public key. The server decrypts this with its
+private key, and uses it together with other data exchanged in the clear to
+generate the session key. An attacker with access to the server's private key
+can perform the same computation at any later time. The TLS library in Windows
+XP and Windows Server 2003 only supported cipher suites of this type, and
+Exchange 2003 servers largely do not support forward secrecy.
+
+Later revisions to the TLS protocol introduced forward-secrecy cipher suites in
+which the client and server implement a key exchange protocol based on
+ephemeral secrets. Sessions encrypted with one of these newer cipher suites are
+not compromised by future disclosure of long-term authentication keys.
+
+The key-exchange algorithms used for forward secrecy require the TLS server to
+designate appropriate "parameters" consisting of a mathematical "group" and an
+element of that group called a "generator". Presently, there are two flavors of
+"groups" that work with PFS:
+
+ * PPrriimmee--ffiieelldd ggrroouuppss ((EEDDHH)):: The server needs to be configured with a
+ suitably-large prime and a corresponding "generator". The acronym for
+ forward secrecy over prime fields is EDH for Ephemeral Diffie-Hellman (also
+ abbreviated as DHE).
+
+ * EElllliippttiicc--ccuurrvvee ggrroouuppss ((EEEECCDDHH)):: The server needs to be configured with a
+ "named curve". These offer better security at lower computational cost than
+ prime field groups, but are not as widely implemented. The acronym for the
+ elliptic curve version is EECDH which is short for Ephemeral Elliptic Curve
+ Diffie-Hellman (also abbreviated as ECDHE).
+
+It is not essential to know what these are, but one does need to know that
+OpenSSL supports EECDH with version 1.0.0 or later. Thus the configuration
+parameters related to Elliptic-Curve forward secrecy are available when Postfix
+is linked with OpenSSL >= 1.0.0 (provided EC support has not been disabled by
+the vendor, as in some versions of RedHat Linux).
+
+Elliptic curves used in cryptography are typically identified by a "name" that
+stands for a set of well-known parameter values, and it is these "names" (or
+associated ASN.1 object identifiers) that are used in the TLS protocol. On the
+other hand, with TLS there are no specially designated prime field groups, so
+each server is free to select its own suitably-strong prime and generator.
+
+FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP SSeerrvveerr
+
+The Postfix >= 2.2 SMTP server supports forward secrecy in its default
+configuration. If the remote SMTP client prefers cipher suites with forward
+secrecy, then the traffic between the server and client will resist decryption
+even if the server's long-term authentication keys are later compromised.
+
+Some remote SMTP clients may support forward secrecy, but prefer cipher suites
+without forward secrecy. In that case, Postfix >= 2.8 could be configured to
+ignore the client's preference with the main.cf setting "tls_preempt_cipherlist
+= yes". However, this will likely cause interoperability issues with older
+Exchange servers and is not recommended for now.
+
+EEDDHH SSeerrvveerr ssuuppppoorrtt
+
+Postfix >= 2.2 support 1024-bit-prime EDH out of the box, with no additional
+configuration, but you may want to override the default prime to be 2048 bits
+long, and you may want to regenerate your primes periodically. See the quick-
+start section for details. With Postfix >= 3.1 the out of the box (compiled-in)
+EDH prime size is 2048 bits.
+
+With prime-field EDH, OpenSSL wants the server to provide two explicitly-
+selected (prime, generator) combinations. One for the now long-obsolete
+"export" cipher suites, and another for non-export cipher suites. Postfix has
+two such default combinations compiled in, but also supports explicitly-
+configured overrides.
+
+ * The "export" EDH parameters are used only with the obsolete "export"
+ ciphers. To use a non-default prime, generate a 512-bit DH parameter file
+ and set smtpd_tls_dh512_param_file to the filename (see the quick-start
+ section for details). With Postfix releases after the middle of 2015 the
+ default opportunistic TLS cipher grade (smtpd_tls_ciphers) is "medium" or
+ stronger, and export ciphers are no longer used.
+
+ * The non-export EDH parameters are used for all other EDH cipher suites. To
+ use a non-default prime, generate a 1024-bit or 2048-bit DH parameter file
+ and set smtpd_tls_dh1024_param_file to the filename. Despite the name this
+ is simply the non-export parameter file and the prime need not actually be
+ 1024 bits long (see the quick-start section for details).
+
+As of mid-2015, SMTP clients are starting to reject TLS handshakes with primes
+smaller than 2048 bits. Each site needs to determine which prime size works
+best for the majority of its clients. See the quick-start section for the
+recommended configuration to work around this issue.
+
+EEEECCDDHH SSeerrvveerr ssuuppppoorrtt
+
+Postfix >= 2.6 support NIST P-256 EECDH when built with OpenSSL >= 1.0.0. When
+the remote SMTP client also supports EECDH and implements the P-256 curve,
+forward secrecy just works.
+
+ Note: With Postfix 2.6 and 2.7, enable EECDH by setting the main.cf
+ parameter smtpd_tls_eecdh_grade to "strong".
+
+The elliptic curve situation is evolving, with new curves being introduced to
+augment or replace the NIST curves tarnished by the Snowden revelations.
+Fortunately, TLS clients advertise the list of supported curves to the server
+so that servers can in principle choose newer stronger curves when mutually
+supported. The OpenSSL code for making this possible is not yet released as of
+late 2013 (it is available only in OpenSSL development snapshots).
+
+At some point Postfix will need to adjust to the new API for setting the
+elliptic-curve options. Fortunately, when EECDH support was added to Postfix,
+it introduced a layer of indirection:
+
+ smtpd_tls_eecdh_grade = strong | ultra
+ tls_eecdh_strong_curve = prime256v1
+ tls_eecdh_ultra_curve = secp384r1
+
+When it becomes possible in OpenSSL to support a "menu" of curves, we will
+likely extend "tls_eecdh_strong_curve" to be an ordered list of curves and
+likewise with the "ultra" version, where the two might now overlap, and differ
+mostly in the preference order. As a result most existing configurations will
+then support more curves at the desired security level without any changes to
+main.cf.
+
+FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP CClliieenntt
+
+The Postfix >= 2.2 SMTP client supports forward secrecy in its default
+configuration. All supported OpenSSL releases support EDH key exchange. OpenSSL
+releases >= 1.0.0 also support EECDH key exchange (provided elliptic-curve
+support has not been disabled by the vendor as in some versions of RedHat
+Linux). If the remote SMTP server supports cipher suites with forward secrecy
+(and does not override the SMTP client's cipher preference), then the traffic
+between the server and client will resist decryption even if the server's long-
+term authentication keys are later compromised.
+
+The default Postfix SMTP client cipher lists are correctly ordered to prefer
+EECDH and EDH cipher suites ahead of similar cipher suites that don't implement
+forward secrecy. Administrators are strongly discouraged from changing the
+cipher list definitions.
+
+The default minimum cipher grade for opportunistic TLS is "medium" for Postfix
+releases after the middle of 2015, "export" for older releases. Changing the
+minimum cipher grade does not change the cipher preference order. Note that
+cipher grades higher than "medium" exclude Exchange 2003 and likely other MTAs,
+thus a "high" cipher grade should be chosen only on a case-by-case basis via
+the TLS policy table.
+
+GGeettttiinngg ssttaarrtteedd,, qquuiicckk aanndd ddiirrttyy
+
+EEEECCDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 22..22 wwiitthh OOppeennSSSSLL >>== 11..00..00))
+
+This works "out of the box" without additional configuration.
+
+EEEECCDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..66 wwiitthh OOppeennSSSSLL >>== 11..00..00))
+
+With Postfix 2.6 and 2.7, enable elliptic-curve support in the Postfix SMTP
+server. This is the default with Postfix >= 2.8. Note, however, that elliptic-
+curve support may be disabled by the vendor, as in some versions of RedHat
+Linux.
+
+ /etc/postfix/main.cf:
+ # Postfix 2.6 or 2.7 only. This is default with Postfix 2.8 and later.
+ smtpd_tls_eecdh_grade = strong
+
+EEDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss))
+
+This works "out of the box" without additional configuration.
+
+EEDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss))
+
+Optionally generate non-default Postfix SMTP server EDH parameters for improved
+security against pre-computation attacks and for compatibility with Debian-
+patched Exim SMTP clients that require a >= 2048-bit length for the non-export
+prime.
+
+Execute as root (prime group generation can take a few seconds to a few
+minutes):
+
+ # cd /etc/postfix
+ # umask 022
+ # openssl dhparam -out dh512.tmp 512 && mv dh512.tmp dh512.pem
+ # openssl dhparam -out dh1024.tmp 1024 && mv dh1024.tmp dh1024.pem
+ # openssl dhparam -out dh2048.tmp 2048 && mv dh2048.tmp dh2048.pem
+ # chmod 644 dh512.pem dh1024.pem dh2048.pem
+
+The Postfix SMTP server EDH parameter files are not secret, after all these
+parameters are sent to all remote SMTP clients in the clear. Mode 0644 is fine.
+
+You can improve security against pre-computation attacks further by
+regenerating the Postfix SMTP server EDH parameters periodically (an hourly or
+daily cron job running the above commands as root can automate this task).
+
+Once the parameters are in place, update main.cf as follows:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
+ smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
+
+If some of your MSA clients don't support 2048-bit EDH, you may need to adjust
+the submission entry in master.cf accordingly:
+
+ /etc/postfix/master.cf:
+ submission inet n - n - - smtpd
+ # Some submission clients may not yet do 2048-bit EDH, if such
+ # clients use your MSA, configure 1024-bit EDH instead. However,
+ # as of mid-2015, many submission clients no longer accept primes
+ # with less than 2048-bits. Each site needs to determine which
+ # type of client is more important to support.
+ -o smtpd_tls_dh1024_param_file=${config_directory}/dh1024.pem
+ -o smtpd_tls_security_level=encrypt
+ -o smtpd_sasl_auth_enable=yes
+ ...
+
+HHooww ccaann II sseeee tthhaatt aa ccoonnnneeccttiioonn hhaass ffoorrwwaarrdd sseeccrreeccyy??
+
+Postfix can be configured to report information about the negotiated cipher,
+the corresponding key lengths, and the remote peer certificate or public-key
+verification status.
+
+ * With "smtp_tls_loglevel = 1" and "smtpd_tls_loglevel = 1", the Postfix SMTP
+ client and server will log TLS connection information to the maillog file.
+ The general logfile format is:
+
+ postfix/smtp[process-id]: Untrusted TLS connection established
+ to host.example.com[192.168.0.2]:25: TLSv1 with cipher cipher-name
+ (actual-key-size/raw-key-size bits)
+
+ postfix/smtpd[process-id]: Anonymous TLS connection established
+ from host.example.com[192.168.0.2]: TLSv1 with cipher cipher-name
+ (actual-key-size/raw-key-size bits)
+
+ * With "smtpd_tls_received_header = yes", the Postfix SMTP server will record
+ TLS connection information in the Received: header in the form of comments
+ (text inside parentheses). The general format depends on the
+ smtpd_tls_ask_ccert setting:
+
+ Received: from host.example.com (host.example.com [192.168.0.2])
+ (using TLSv1 with cipher cipher-name
+ (actual-key-size/raw-key-size bits))
+ (Client CN "host.example.com", Issuer "John Doe" (not
+ verified))
+
+ Received: from host.example.com (host.example.com [192.168.0.2])
+ (using TLSv1 with cipher cipher-name
+ (actual-key-size/raw-key-size bits))
+ (No client certificate requested)
+
+The next sections will explain what cipher-name, key-size, and peer
+verification status information to expect.
+
+WWhhaatt cciipphheerrss pprroovviiddee ffoorrwwaarrdd sseeccrreeccyy??
+
+There are dozens of ciphers that support forward secrecy. What follows is the
+beginning of a list of 51 ciphers available with OpenSSL 1.0.1e. The list is
+sorted in the default Postfix preference order. It excludes null ciphers that
+only authenticate and don't encrypt, together with export and low-grade ciphers
+whose encryption is too weak to offer meaningful secrecy. The first column
+shows the cipher name, and the second shows the key exchange method.
+
+ $ openssl ciphers -v \
+ 'aNULL:-aNULL:kEECDH:kEDH:+RC4:!eNULL:!EXPORT:!LOW:@STRENGTH' |
+ awk '{printf "%-32s %s\n", $1, $3}'
+ AECDH-AES256-SHA Kx=ECDH
+ ECDHE-RSA-AES256-GCM-SHA384 Kx=ECDH
+ ECDHE-ECDSA-AES256-GCM-SHA384 Kx=ECDH
+ ECDHE-RSA-AES256-SHA384 Kx=ECDH
+ ECDHE-ECDSA-AES256-SHA384 Kx=ECDH
+ ECDHE-RSA-AES256-SHA Kx=ECDH
+ ECDHE-ECDSA-AES256-SHA Kx=ECDH
+ ADH-AES256-GCM-SHA384 Kx=DH
+ ADH-AES256-SHA256 Kx=DH
+ ADH-AES256-SHA Kx=DH
+ ADH-CAMELLIA256-SHA Kx=DH
+ DHE-DSS-AES256-GCM-SHA384 Kx=DH
+ DHE-RSA-AES256-GCM-SHA384 Kx=DH
+ DHE-RSA-AES256-SHA256 Kx=DH
+ ...
+
+To date, all ciphers that support forward secrecy have one of five values for
+the first component of their OpenSSL name: "AECDH", "ECDHE", "ADH", "EDH" or
+"DHE". Ciphers that don't implement forward secrecy have names that don't start
+with one of these prefixes. This pattern is likely to persist until some new
+key-exchange mechanism is invented that also supports forward secrecy.
+
+The actual key length and raw algorithm key length are generally the same with
+non-export ciphers, but may they differ for the legacy export ciphers where the
+actual key is artificially shortened.
+
+WWhhaatt ddoo ""AAnnoonnyymmoouuss"",, ""UUnnttrruusstteedd"",, eettcc.. iinn PPoossttffiixx llooggggiinngg mmeeaann??
+
+The verification levels below are subject to man-in-the-middle attacks to
+different degrees. If such attacks are a concern, then the SMTP client will
+need to authenticate the remote SMTP server in a sufficiently-secure manner.
+For example, by the fingerprint of a (CA or leaf) public key or certificate.
+Remember that conventional PKI relies on many trusted parties and is easily
+subverted by a state-funded adversary.
+
+AAnnoonnyymmoouuss (no peer certificate)
+ PPoossttffiixx SSMMTTPP cclliieenntt:: With opportunistic TLS (the "may" security level) the
+ Postfix SMTP client does not verify any information in the peer
+ certificate. In this case it enables and prefers anonymous cipher suites in
+ which the remote SMTP server does not present a certificate (these ciphers
+ offer forward secrecy of necessity). When the remote SMTP server also
+ supports anonymous TLS, and agrees to such a cipher suite, the verification
+ status will be logged as "Anonymous".
+
+ PPoossttffiixx SSMMTTPP sseerrvveerr:: This is by far most common, as client certificates are
+ optional, and the Postfix SMTP server does not request client certificates
+ by default (see smtpd_tls_ask_ccert). Even when client certificates are
+ requested, the remote SMTP client might not send a certificate. Unlike the
+ Postfix SMTP client, the Postfix SMTP server "anonymous" verification
+ status does not imply that the cipher suite is anonymous, which corresponds
+ to the server not sending a certificate.
+
+UUnnttrruusstteedd (peer certificate not signed by trusted CA)
+ PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server presented a certificate, but
+ the Postfix SMTP client was unable to check the issuing CA signature. With
+ opportunistic TLS this is common with remote SMTP servers that don't
+ support anonymous cipher suites.
+
+ PPoossttffiixx SSMMTTPP sseerrvveerr:: The remote SMTP client presented a certificate, but
+ the Postfix SMTP server was unable to check the issuing CA signature. This
+ can happen when the server is configured to request client certificates
+ (see smtpd_tls_ask_ccert).
+
+TTrruusstteedd (peer certificate signed by trusted CA, unverified peer name)
+ PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server's certificate was signed by a
+ CA that the Postfix SMTP client trusts, but either the client was not
+ configured to verify the destination server name against the certificate,
+ or the server certificate did not contain any matching names. This is
+ common with opportunistic TLS (smtp_tls_security_level is "may" or else
+ "dane" with no usable TLSA DNS records) when the Postfix SMTP client's
+ trusted CAs can verify the authenticity of the remote SMTP server's
+ certificate, but the client is not configured or unable to verify the
+ server name.
+
+ PPoossttffiixx SSMMTTPP sseerrvveerr:: The remote SMTP client certificate was signed by a CA
+ that the Postfix SMTP server trusts. The Postfix SMTP server never verifies
+ the remote SMTP client name against the names in the client certificate.
+ Since the client chooses to connect to the server, the Postfix SMTP server
+ has no expectation of a particular client hostname.
+
+VVeerriiffiieedd (peer certificate signed by trusted CA and verified peer name; or:
+peer certificate with expected public-key or certificate fingerprint)
+ PPoossttffiixx SSMMTTPP cclliieenntt:: The remote SMTP server's certificate was signed by a
+ CA that the Postfix SMTP client trusts, and the certificate name matches
+ the destination or server name(s). The Postfix SMTP client was configured
+ to require a verified name, otherwise the verification status would have
+ been just "Trusted".
+
+ PPoossttffiixx SSMMTTPP cclliieenntt:: The "Verified" status may also mean that the Postfix
+ SMTP client successfully matched the expected fingerprint against the
+ remote SMTP server public key or certificate. The expected fingerprint may
+ come from smtp_tls_policy_maps or from TLSA (secure) DNS records. The
+ Postfix SMTP client ignores the CA signature.
+
+ PPoossttffiixx SSMMTTPP sseerrvveerr:: The status is never "Verified", because the Postfix
+ SMTP server never verifies the remote SMTP client name against the names in
+ the client certificate, and because the Postfix SMTP server does not expect
+ a specific fingerprint in the client public key or certificate.
+
+CCrreeddiittss
+
+ * TLS support for Postfix was originally developed by Lutz Jänicke at Cottbus
+ Technical University.
+ * Wietse Venema adopted and restructured the code and documentation.
+ * Viktor Dukhovni implemented support for many subsequent TLS features,
+ including EECDH, and authored the initial version of this document.
+
diff --git a/README_FILES/INSTALL b/README_FILES/INSTALL
new file mode 100644
index 0000000..dac8e8e
--- /dev/null
+++ b/README_FILES/INSTALL
@@ -0,0 +1,1148 @@
+PPoossttffiixx IInnssttaallllaattiioonn FFrroomm SSoouurrccee CCooddee
+
+-------------------------------------------------------------------------------
+
+11 -- PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+If you are using a pre-compiled version of Postfix, you should start with
+BASIC_CONFIGURATION_README and the general documentation referenced by it.
+INSTALL is only a bootstrap document to get Postfix up and running from scratch
+with the minimal number of steps; it should not be considered part of the
+general documentation.
+
+This document describes how to build, install and configure a Postfix system so
+that it can do one of the following:
+
+ * Send mail only, without changing an existing Sendmail installation.
+ * Send and receive mail via a virtual host interface, still without any
+ change to an existing Sendmail installation.
+ * Run Postfix instead of Sendmail.
+
+Topics covered in this document:
+
+ 1. Purpose of this document
+ 2. Typographical conventions
+ 3. Documentation
+ 4. Building on a supported system
+ 5. Porting Postfix to an unsupported system
+ 6. Installing the software after successful compilation
+ 7. Configuring Postfix to send mail only
+ 8. Configuring Postfix to send and receive mail via virtual interface
+ 9. Running Postfix instead of Sendmail
+10. Mandatory configuration file edits
+11. To chroot or not to chroot
+12. Care and feeding of the Postfix system
+
+22 -- TTyyppooggrraapphhiiccaall ccoonnvveennttiioonnss
+
+In the instructions below, a command written as
+
+ # command
+
+should be executed as the superuser.
+
+A command written as
+
+ $ command
+
+should be executed as an unprivileged user.
+
+33 -- DDooccuummeennttaattiioonn
+
+Documentation is available as README files (start with the file README_FILES/
+AAAREADME), as HTML web pages (point your browser to "html/index.html") and as
+UNIX-style manual pages.
+
+You should view the README files with a pager such as more(1) or less(1),
+because the files use backspace characters in order to produce bboolldd font. To
+print a README file without backspace characters, use the col(1) command. For
+example:
+
+ $ col -bx =
+ 3.0)
+ * 4.4 - Building with Postfix dynamically-linked libraries and database
+ plugins (Postfix >= 3.0)
+ * 4.5 - Building with optional features
+ * 4.6 - Overriding built-in parameter default settings
+ * 4.7 - Overriding other compile-time features
+ * 4.8 - Support for thousands of processes
+ * 4.9 - Compiling Postfix, at last
+
+44..11 -- GGeettttiinngg ssttaarrtteedd
+
+On Solaris, the "make" command and other development utilities are in /usr/ccs/
+bin, so you MUST have /usr/ccs/bin in your command search path. If these files
+do not exist, you need to install the development packages first.
+
+If you need to build Postfix for multiple architectures from a single source-
+code tree, use the "lndir" command to build a shadow tree with symbolic links
+to the source files.
+
+If at any time in the build process you get messages like: "make: don't know
+how to ..." you should be able to recover by running the following command from
+the Postfix top-level directory:
+
+ $ make -f Makefile.init makefiles
+
+If you copied the Postfix source code after building it on another machine, it
+is a good idea to cd into the top-level directory and first do this:
+
+ $ make tidy
+
+This will get rid of any system dependencies left over from compiling the
+software elsewhere.
+
+44..22 -- WWhhaatt ccoommppiilleerr ttoo uussee
+
+To build with GCC, or with the native compiler if people told me that is better
+for your system, just cd into the top-level Postfix directory of the source
+tree and type:
+
+ $ make
+
+To build with a non-default compiler, you need to specify the name of the
+compiler. Here are a few examples:
+
+ $ make makefiles CC=/opt/SUNWspro/bin/cc (Solaris)
+ $ make
+
+ $ make makefiles CC="/opt/ansic/bin/cc -Ae" (HP-UX)
+ $ make
+
+ $ make makefiles CC="purify cc"
+ $ make
+
+and so on. In some cases, optimization will be turned off automatically.
+
+44..33 -- BBuuiillddiinngg wwiitthh PPoossttffiixx ppoossiittiioonn--iinnddeeppeennddeenntt eexxeeccuuttaabblleess ((PPoossttffiixx >>== 33..00))
+
+On some systems Postfix can be built with Position-Independent Executables. PIE
+is used by the ASLR exploit mitigation technique (ASLR = Address-Space Layout
+Randomization):
+
+ $ make makefiles pie=yes ...other arguments...
+
+(Specify "make makefiles pie=no" to explicitly disable Postfix position-
+independent executable support).
+
+Postfix PIE support appears to work on Fedora Core 20, Ubuntu 14.04, FreeBSD 9
+and 10, and NetBSD 6 (all with the default system compilers).
+
+Whether the "pie=yes" above has any effect depends on the compiler. Some
+compilers always produce PIE executables, and some may even complain that the
+Postfix build option is redundant.
+
+44..44 -- BBuuiillddiinngg wwiitthh PPoossttffiixx ddyynnaammiiccaallllyy--lliinnkkeedd lliibbrraarriieess aanndd ddaattaabbaassee pplluuggiinnss
+((PPoossttffiixx >>== 33..00))
+
+Postfix dynamically-linked library and database plugin support exists for
+recent versions of Linux, FreeBSD and MacOS X. Dynamically-linked library
+builds may become the default at some point in the future.
+
+Overview of topics:
+
+ * 4.4.1 Turning on Postfix dynamically-linked library support
+ * 4.4.2 Turning on Postfix database-plugin support
+ * 4.4.3 Customizing Postfix dynamically-linked libraries and database plugins
+ * 4.4.4 Tips for distribution maintainers
+
+Note: directories with Postfix dynamically-linked libraries or database plugins
+should contain only postfix-related files. Postfix dynamically-linked libraries
+and database plugins should not be installed in a "public" system directory
+such as /usr/lib or /usr/local/lib. Linking Postfix dynamically-linked library
+or database-plugin files into non-Postfix programs is not supported. Postfix
+dynamically-linked libraries and database plugins implement a Postfix-internal
+API that changes without maintaining compatibility.
+
+44..44..11 TTuurrnniinngg oonn PPoossttffiixx ddyynnaammiiccaallllyy--lliinnkkeedd lliibbrraarryy ssuuppppoorrtt
+
+Postfix can be built with Postfix dynamically-linked libraries (files typically
+named libpostfix-*.so). Postfix dynamically-linked libraries add minor run-time
+overhead and result in significantly-smaller Postfix executable files.
+
+Specify "shared=yes" on the "make makefiles" command line to build Postfix with
+dynamically-linked library support.
+
+ $ make makefiles shared=yes ...other arguments...
+ $ make
+
+(Specify "make makefiles shared=no" to explicitly disable Postfix dynamically-
+linked library support).
+
+This installs dynamically-linked libraries in $shlib_directory, typically /usr/
+lib/postfix or /usr/local/lib/postfix, with file names libpostfix-name.so,
+where the name is a source-code directory name such as "util" or "global".
+
+See section 4.4.3 "Customizing Postfix dynamically-linked libraries and
+database plugins" below for how to customize the Postfix dynamically-linked
+library location, including support to upgrade a running mail system safely.
+
+44..44..22 TTuurrnniinngg oonn PPoossttffiixx ddaattaabbaassee--pplluuggiinn ssuuppppoorrtt
+
+Additionally, Postfix can be built to support dynamic loading of Postfix
+database clients (database plugins) with the Debian-style dynamicmaps feature.
+Postfix 3.0 supports dynamic loading of cdb:, ldap:, lmdb:, mysql:, pcre:,
+pgsql:, sdbm:, and sqlite: database clients. Dynamic loading is useful when you
+distribute or install pre-compiled Postfix packages.
+
+Specify "dynamicmaps=yes" on the "make makefiles" command line to build Postfix
+with support to dynamically load Postfix database clients with the Debian-style
+dynamicmaps feature.
+
+ $ make makefiles dynamicmaps=yes ...other arguments...
+ $ make
+
+(Specify "make makefiles dynamicmaps=no" to explicitly disable Postfix
+database-plugin support).
+
+This implicitly enables dynamically-linked library support, installs the
+configuration file dynamicmaps.cf in $meta_directory (usually, /etc/postfix or
+/usr/local/etc/postfix), and installs database plugins in $shlib_directory (see
+above). Database plugins are named postfix-type.so where the type is a database
+type such as "cdb" or "ldap".
+
+ NOTE: The Postfix 3.0 build procedure expects that you specify database
+ library dependencies with variables named AUXLIBS_CDB, AUXLIBS_LDAP, etc.
+ With Postfix 3.0 and later, the old AUXLIBS variable still supports
+ building a statically-loaded database client, but only the new AUXLIBS_CDB
+ etc. variables support building a dynamically-loaded or statically-loaded
+ CDB etc. database client. See CDB_README, LDAP_README, etc. for details.
+
+ Failure to follow this advice will defeat the purpose of dynamic database
+ client loading. Every Postfix executable file will have database library
+ dependencies. And that was exactly what dynamic database client loading was
+ meant to avoid.
+
+See the next section for how to customize the location and version of Postfix
+database plugins and the location of the file dynamicmaps.cf.
+
+44..44..33 CCuussttoommiizziinngg PPoossttffiixx ddyynnaammiiccaallllyy--lliinnkkeedd lliibbrraarriieess aanndd ddaattaabbaassee pplluuggiinnss
+
+CCuussttoommiizziinngg bbuuiilldd--ttiimmee aanndd rruunn--ttiimmee ooppttiioonnss ffoorr PPoossttffiixx ddyynnaammiiccaallllyy--lliinnkkeedd
+lliibbrraarriieess aanndd ddaattaabbaassee pplluuggiinnss
+
+The build-time environment variables SHLIB_CFLAGS, SHLIB_RPATH, and
+SHLIB_SUFFIX provide control over how Postfix libraries and plugins are
+compiled, linked, and named.
+
+ $ make makefiles SHLIB_CFLAGS=flags SHLIB_RPATH=rpath SHLIB_SUFFIX=suffix
+ ...other arguments...
+ $ make
+
+See section 4.7 "Overriding other compile-time features" below for details.
+
+CCuussttoommiizziinngg tthhee llooccaattiioonn ooff PPoossttffiixx ddyynnaammiiccaallllyy--lliinnkkeedd lliibbrraarriieess aanndd ddaattaabbaassee
+pplluuggiinnss
+
+As a reminder, the directories with Postfix dynamically-linked libraries or
+database plugins should contain only Postfix-related files. Linking these files
+into other programs is not supported.
+
+To override the default location of Postfix dynamically-linked libraries and
+database plugins specify, for example:
+
+ $ make makefiles shared=yes shlib_directory=/usr/local/lib/postfix ...
+
+If you intend to upgrade Postfix without stopping the mail system, then you
+should append the Postfix release version to the shlib_directory pathname, to
+eliminate the possibility that programs will link with dynamically-linked
+libraries or database plugins from the wrong Postfix version. For example:
+
+ $ make makefiles shared=yes \
+ shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+
+The command "make makefiles 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 inconsistent results with different versions of the make(1) command.
+
+You can change the shlib_directory setting after Postfix is built, with "make
+install" or "make upgrade". However, you may have to run ldconfig if you change
+shlib_directory after Postfix is built (the symptom is that Postfix programs
+fail because the run-time linker cannot find the files libpostfix-*.so). No
+ldconfig command is needed if you keep the files libpostfix-*.so in the
+compiled-in default $shlib_directory location.
+
+ # make upgrade shlib_directory=/usr/local/lib/postfix ...
+ # make install shlib_directory=/usr/local/lib/postfix ...
+
+To append the Postfix release version to the pathname if you intend to upgrade
+Postfix without stopping the mail system:
+
+ # make upgrade shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+ # make install shlib_directory=/usr/local/lib/postfix/MAIL_VERSION ...
+
+See also the comments above for appending MAIL_VERSION with the "make
+makefiles" command.
+
+CCuussttoommiizziinngg tthhee llooccaattiioonn ooff ddyynnaammiiccmmaappss..ccff aanndd ootthheerr ffiilleess
+
+The meta_directory parameter has the same default setting as the
+config_directory parameter, typically /etc/postfix or /usr/local/etc/postfix.
+
+You can override the default meta_directory location at compile time or after
+Postfix is built. To override the default location at compile time specify, for
+example:
+
+ % make makefiles meta_directory=/usr/libexec/postfix ...
+
+Here is a tip if you want to make a pathname dependent on the Postfix release
+version: the command "make makefiles 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 inconsistent results with different versions of the
+make(1) command.
+
+You can override the meta_directory setting after Postfix is built, with "make
+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
+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
+inconsistent results with different versions of the make(1) command.
+
+44..44..44 TTiippss ffoorr ddiissttrriibbuuttiioonn mmaaiinnttaaiinneerrss
+
+ * The shlib_directory parameter setting also provides the default directory
+ for database plugin files with a relative pathname in the file
+ dynamicmaps.cf.
+
+ * The meta_directory parameter specifies the location of the files
+ dynamicmaps.cf, postfix-files, and some multi-instance template files. The
+ meta_directory parameter has the same default value as the config_directory
+ parameter (typically, /etc/postfix or /usr/local/etc/postfix). For
+ backwards compatibility with Postfix 2.6 .. 2.11, specify "meta_directory =
+ $daemon_directory" in main.cf before installing or upgrading Postfix, or
+ specify "meta_directory = /path/name" on the "make makefiles", "make
+ install" or "make upgrade" command line.
+
+ * The configuration file dynamicmaps.cf will automatically include files
+ under the directory dynamicmaps.cf.d, just like the configuration file
+ postfix-files will automatically include files under the directory postfix-
+ files.d. Thanks to this, you can install or deinstall a database plugin
+ package without having to edit postfix-files or dynamicmaps.cf. Instead,
+ you give that plugin its own configuration files dynamicmaps.cf.d and
+ postfix-files.d, and you add or remove those configuration files along with
+ the database plugin dynamically-linked object.
+
+ * Each configuration file under the directory dynamicmaps.cf.d must have the
+ same format as the configuration file dynamicmaps.cf. There is no
+ requirement that these configuration file *names* have a specific format.
+
+ * Each configuration file under the directory postfix-files.d must have the
+ same format as the configuration file postfix-files. There is no
+ requirement that these configuration file *names* have a specific format.
+
+44..55 -- BBuuiillddiinngg wwiitthh ooppttiioonnaall ffeeaattuurreess
+
+By default, Postfix builds as a mail system with relatively few bells and
+whistles. Support for third-party databases etc. must be configured when
+Postfix is compiled. The following documents describe how to build Postfix with
+support for optional features:
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |OOppttiioonnaall ffeeaattuurree |DDooccuummeenntt |AAvvaaiillaabbiilliittyy|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |Berkeley DB database |DB_README |Postfix 1.0 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |LMDB database |LMDB_README |Postfix 2.11|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |LDAP database |LDAP_README |Postfix 1.0 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |MySQL database |MYSQL_README |Postfix 1.0 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |Perl compatible regular expression|PCRE_README |Postfix 1.0 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |PostgreSQL database |PGSQL_README |Postfix 2.0 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |SASL authentication |SASL_README |Postfix 1.0 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |SQLite database |SQLITE_README|Postfix 2.8 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |STARTTLS session encryption |TLS_README |Postfix 2.2 |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+
+Note: IP version 6 support is compiled into Postfix on operating systems that
+have IPv6 support. See the IPV6_README file for details.
+
+44..66 -- OOvveerrrriiddiinngg bbuuiilltt--iinn ppaarraammeetteerr ddeeffaauulltt sseettttiinnggss
+
+44..66..11 -- PPoossttffiixx 33..00 aanndd llaatteerr
+
+All Postfix configuration parameters can be changed by editing a Postfix
+configuration file, except for one: the parameter that specifies the location
+of Postfix configuration files. In order to build Postfix with a configuration
+directory other than /etc/postfix, use:
+
+ $ make makefiles config_directory=/some/where ...other arguments...
+ $ make
+
+The command "make makefiles 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 inconsistent results with different versions of the
+make(1) command.
+
+Parameters whose defaults can be specified in this way are listed below. See
+the postconf(5) manpage for a description (command: "nroff -man man/man5/
+postconf.5 | less").
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |ppaarraammeetteerr nnaammee |ttyyppiiccaall ddeeffaauulltt |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |command_directory |/usr/sbin |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |config_directory |/etc/postfix |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |default_database_type|hash |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |daemon_directory |/usr/libexec/postfix|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |data_directory |/var/lib/postfix |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |html_directory |no |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |mail_spool_directory |/var/mail |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |mailq_path |/usr/bin/mailq |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |manpage_directory |/usr/local/man |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |meta_directory |/etc/postfix |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |newaliases_path |/usr/bin/newaliases |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |queue_directory |/var/spool/postfix |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |readme_directory |no |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |sendmail_path |/usr/sbin/sendmail |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |shlib_directory |/usr/lib/postfix |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+44..66..22 -- AAllll PPoossttffiixx vveerrssiioonnss
+
+All Postfix configuration parameters can be changed by editing a Postfix
+configuration file, except for one: the parameter that specifies the location
+of Postfix configuration files. In order to build Postfix with a configuration
+directory other than /etc/postfix, use:
+
+ $ make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/some/where\"'
+ $ make
+
+IMPORTANT: Be sure to get the quotes right. These details matter a lot.
+
+Parameters whose defaults can be specified in this way are listed below. See
+the postconf(5) manpage for a description (command: "nroff -man man/man5/
+postconf.5 | less").
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |MMaaccrroo nnaammee |ddeeffaauulltt vvaalluuee ffoorr |ttyyppiiccaall ddeeffaauulltt |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_COMMAND_DIR |command_directory |/usr/sbin |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_CONFIG_DIR |config_directory |/etc/postfix |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_DB_TYPE |default_database_type|hash |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_DAEMON_DIR |daemon_directory |/usr/libexec/postfix|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_DATA_DIR |data_directory |/var/lib/postfix |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_MAILQ_PATH |mailq_path |/usr/bin/mailq |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_HTML_DIR |html_directory |no |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_MANPAGE_DIR |manpage_directory |/usr/local/man |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_NEWALIAS_PATH|newaliases_path |/usr/bin/newaliases |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_QUEUE_DIR |queue_directory |/var/spool/postfix |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_README_DIR |readme_directory |no |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |DEF_SENDMAIL_PATH|sendmail_path |/usr/sbin/sendmail |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+Note: the data_directory parameter (for caches and pseudo-random numbers) was
+introduced with Postfix version 2.5.
+
+44..77 -- OOvveerrrriiddiinngg ootthheerr ccoommppiillee--ttiimmee ffeeaattuurreess
+
+The general method to override Postfix compile-time features is as follows:
+
+ $ make makefiles name=value name=value...
+ $ make
+
+The following is an extensive list of names and values.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+|NNaammee//VVaalluuee |DDeessccrriippttiioonn |
+|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+| |Specifies one or more non-default object |
+| |libraries. Postfix 3.0 and later specify some |
+| |of their database library dependencies with |
+|AUXLIBS="object_library..." |AUXLIBS_CDB, AUXLIBS_LDAP, AUXLIBS_LMDB, |
+| |AUXLIBS_MYSQL, AUXLIBS_PCRE, AUXLIBS_PGSQL, |
+| |AUXLIBS_SDBM, and AUXLIBS_SQLITE, |
+| |respectively. |
+|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|CC=compiler_command |Specifies a non-default compiler. On many |
+| |systems, the default is gcc. |
+|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+| |Specifies non-default compiler arguments, for |
+|CCARGS="compiler_arguments..."|example, a non-default include directory. The |
+| |following directives turn off Postfix features|
+| |at compile time: |
+|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Do not build with Berkeley DB support. By |
+|| |default, Berkeley DB support is compiled in on|
+||-DNO_DB |platforms that are known to support this |
+|| |feature. If you override this, then you |
+|| |probably should also override DEF_DB_TYPE as |
+|| |described in section 4.6. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+||-DNO_DNSSEC |Do not build with DNSSEC support, even if the |
+|| |resolver library appears to support it. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Do not build with Solaris /dev/poll support. |
+||-DNO_DEVPOLL |By default, /dev/poll support is compiled in |
+|| |on Solaris versions that are known to support |
+|| |this feature. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Do not build with Linux EPOLL support. By |
+||-DNO_EPOLL |default, EPOLL support is compiled in on |
+|| |platforms that are known to support this |
+|| |feature. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Do not build with EAI (SMTPUTF8) support. By |
+||-DNO_EAI |default, EAI support is compiled in when the |
+|| |"icuuc" library and header files are found. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Do not require support for C99 "inline" |
+||-DNO_INLINE |functions. Instead, implement argument |
+|| |typechecks for non-printf/scanf-like functions|
+|| |with ternary operators and unreachable code. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Do not build with IPv6 support. By default, |
+|| |IPv6 support is compiled in on platforms that |
+||-DNO_IPV6 |are known to have IPv6 support. Note: this |
+|| |directive is for debugging and testing only. |
+|| |It is not guaranteed to work on all platforms.|
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Do not build with FreeBSD / NetBSD / OpenBSD /|
+||-DNO_KQUEUE |MacOSX KQUEUE support. By default, KQUEUE |
+|| |support is compiled in on platforms that are |
+|| |known to support it. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Do not build with NIS or NISPLUS support. NIS |
+||-DNO_NIS |is not available on some recent Linux |
+|| |distributions. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Do not build with NISPLUS support. NISPLUS is |
+||-DNO_NISPLUS |not available on some recent Solaris |
+|| |distributions. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Do not build with PCRE support. By default, |
+||-DNO_PCRE |PCRE support is compiled in when the pcre- |
+|| |config utility is installed. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Disable support for POSIX getpwnam_r/ |
+||-DNO_POSIX_GETPW_R |getpwuid_r. By default Postfix uses these |
+|| |where they are known to be available. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+|| |Use setjmp()/longjmp() instead of sigsetjmp()/|
+||-DNO_SIGSETJMP |siglongjmp(). By default, Postfix uses |
+|| |sigsetjmp()/siglongjmp() when they are known |
+|| |to be available. |
+|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+| |Specifies a non-default compiler debugging |
+|DEBUG=debug_level |level. The default is "-g". Specify DEBUG= to |
+| |turn off debugging. |
+|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+| |Specifies a non-default optimization level. |
+|OPT=optimization_level |The default is "-O". Specify OPT= to turn off |
+| |optimization. |
+|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+| |Specifies non-default compiler options for |
+|SHLIB_CFLAGS=flags |building Postfix dynamically-linked libraries |
+| |and database plugins. The typical default is |
+| |"-fPIC". |
+|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+| |Specifies a non-default runpath for Postfix |
+|SHLIB_RPATH=rpath |dynamically-linked libraries. The typical |
+| |default is "'-Wl,-rpath,${SHLIB_DIR}'". |
+|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+| |Specifies a non-default suffix for Postfix |
+|SHLIB_SUFFIX=suffix |dynamically-linked libraries and database |
+| |plugins. The typical default is ".so". |
+|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+| |Specifies non-default compiler warning options|
+|WARN="warning_flags..." |for use when "make" is invoked in a source |
+| |subdirectory only. |
+|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+44..88 -- SSuuppppoorrtt ffoorr tthhoouussaannddss ooff pprroocceesssseess
+
+The number of connections that Postfix can manage simultaneously is limited by
+the number of processes that it can run. This number in turn is limited by the
+number of files and sockets that a single process can open. For example, the
+Postfix queue manager has a separate connection to each delivery process, and
+the anvil(8) server has one connection per smtpd(8) process.
+
+Postfix version 2.4 and later have no built-in limits on the number of open
+files or sockets, when compiled on systems that support one of the following:
+
+ * BSD kqueue(2) (FreeBSD 4.1, NetBSD 2.0, OpenBSD 2.9),
+ * Solaris 8 /dev/poll,
+ * Linux 2.6 epoll(4).
+
+With other Postfix versions or operating systems, the number of file
+descriptors per process is limited by the value of the FD_SETSIZE macro. If you
+expect to run more than 1000 mail delivery processes, you may need to override
+the definition of the FD_SETSIZE macro to make select() work correctly:
+
+ $ make makefiles CCARGS=-DFD_SETSIZE=2048
+
+Warning: the above has no effect on some Linux versions. Apparently, on these
+systems the FD_SETSIZE value can be changed only by using undocumented
+interfaces. Currently, that means including directly (which is
+not allowed) and overriding the __FD_SETSIZE macro. Beware, undocumented
+interfaces can change at any time and without warning.
+
+But wait, there is more: none of this will work unless the operating system is
+configured to handle thousands of connections. See the TUNING_README guide for
+examples of how to increase the number of open sockets or files.
+
+44..99 -- CCoommppiilliinngg PPoossttffiixx,, aatt llaasstt
+
+If the command
+
+ $ make
+
+is successful, then you can proceed to install Postfix (section 6).
+
+If the command produces compiler error messages, it may be time to search the
+web or to ask the postfix-users@postfix.org mailing list, but be sure to search
+the mailing list archives first. Some mailing list archives are linked from
+http://www.postfix.org/.
+
+55 -- PPoorrttiinngg PPoossttffiixx ttoo aann uunnssuuppppoorrtteedd ssyysstteemm
+
+Each system type that Postfix knows is identified by a unique name. Examples:
+SUNOS5, FREEBSD4, and so on. When porting Postfix to a new system, the first
+step is to choose a SYSTEMTYPE name for the new system. You must use a name
+that includes at least the major version of the operating system (such as
+SUNOS4 or LINUX2), so that different releases of the same system can be
+supported without confusion.
+
+Add a case statement to the "makedefs" shell script in the source code top-
+level directory that recognizes the new system reliably, and that emits the
+right system-specific information. Be sure to make the code robust against user
+PATH settings; if the system offers multiple UNIX flavors (e.g. BSD and SYSV)
+be sure to build for the native flavor, instead of the emulated one.
+
+Add an "#ifdef SYSTEMTYPE" section to the central util/sys_defs.h include file.
+You may have to invent new feature macro names. Please choose sensible feature
+macro names such as HAS_DBM or FIONREAD_IN_SYS_FILIO_H.
+
+I strongly recommend against using "#ifdef SYSTEMTYPE" in individual source
+files. While this may look like the quickest solution, it will create a mess
+when newer versions of the same SYSTEMTYPE need to be supported. You're likely
+to end up placing "#ifdef" sections all over the source code again.
+
+66 -- IInnssttaalllliinngg tthhee ssooffttwwaarree aafftteerr ssuucccceessssffuull ccoommppiillaattiioonn
+
+This text describes how to install Postfix from source code. See the
+PACKAGE_README file if you are building a package for distribution to other
+systems.
+
+66..11 -- SSaavvee eexxiissttiinngg SSeennddmmaaiill bbiinnaarriieess
+
+IMPORTANT: if you are REPLACING an existing Sendmail installation with Postfix,
+you may need to keep the old sendmail program running for some time in order to
+flush the mail queue.
+
+ * Some systems implement a mail switch mechanism where different MTAs
+ (Postfix, Sendmail, etc.) can be installed at the same time, while only one
+ of them is actually being used. Examples of such switching mechanisms are
+ the FreeBSD mailwrapper(8) or the Linux mail switch. In this case you
+ should try to "flip" the switch to "Postfix" before installing Postfix.
+
+ * If your system has no mail switch mechanism, execute the following commands
+ (your sendmail, newaliases and mailq programs may be in a different place):
+
+ # mv /usr/sbin/sendmail /usr/sbin/sendmail.OFF
+ # mv /usr/bin/newaliases /usr/bin/newaliases.OFF
+ # mv /usr/bin/mailq /usr/bin/mailq.OFF
+ # chmod 755 /usr/sbin/sendmail.OFF /usr/bin/newaliases.OFF \
+ /usr/bin/mailq.OFF
+
+66..22 -- CCrreeaattee aaccccoouunntt aanndd ggrroouuppss
+
+Before you install Postfix for the first time you need to create an account and
+a group:
+
+ * Create a user account "postfix" with a user id and group id that are not
+ used by any other user account. Preferably, this is an account that no-one
+ can log into. The account does not need an executable login shell, and
+ needs no existing home directory. My password and group file entries look
+ like this:
+
+ /etc/passwd:
+ postfix:*:12345:12345:postfix:/no/where:/no/shell
+
+ /etc/group:
+ postfix:*:12345:
+
+ Note: there should be no whitespace before "postfix:".
+
+ * Create a group "postdrop" with a group id that is not used by any other
+ user account. Not even by the postfix user account. My group file entry
+ looks like:
+
+ /etc/group:
+ postdrop:*:54321:
+
+ Note: there should be no whitespace before "postdrop:".
+
+66..33 -- IInnssttaallll PPoossttffiixx
+
+To install or upgrade Postfix from compiled source code, run one of the
+following commands as the super-user:
+
+ # make install (interactive version, first time install)
+
+ # make upgrade (non-interactive version, for upgrades)
+
+ * The interactive version ("make install") asks for pathnames for Postfix
+ data and program files, and stores your preferences in the main.cf file. IIff
+ yyoouu ddoonn''tt wwaanntt PPoossttffiixx ttoo oovveerrwwrriittee nnoonn--PPoossttffiixx ""sseennddmmaaiill"",, ""mmaaiillqq"" aanndd
+ ""nneewwaalliiaasseess"" ffiilleess,, ssppeecciiffyy ppaatthhnnaammeess tthhaatt eenndd iinn ""..ppoossttffiixx"".
+
+ * The non-interactive version ("make upgrade") needs the /etc/postfix/main.cf
+ file from a previous installation. If the file does not exist, use
+ interactive installation ("make install") instead.
+
+ * If you specify name=value arguments on the "make install" or "make upgrade"
+ command line, then these will take precedence over compiled-in default
+ settings or main.cf settings.
+
+ 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 inconsistent results with different versions of
+ the make(1) command.
+
+66..44 -- CCoonnffiigguurree PPoossttffiixx
+
+Proceed to the section on how you wish to run Postfix on your particular
+machine:
+
+ * Send mail only, without changing an existing Sendmail installation (section
+ 7).
+
+ * Send and receive mail via a virtual host interface, still without any
+ change to an existing Sendmail installation (section 8).
+
+ * Run Postfix instead of Sendmail (section 9).
+
+77 -- CCoonnffiigguurriinngg PPoossttffiixx ttoo sseenndd mmaaiill oonnllyy
+
+If you are going to use Postfix to send mail only, there is no need to change
+your existing sendmail setup. Instead, set up your mail user agent so that it
+calls the Postfix sendmail program directly.
+
+Follow the instructions in the "Mandatory configuration file edits" in section
+10, and review the "To chroot or not to chroot" text in section 11.
+
+You MUST comment out the "smtp inet" entry in /etc/postfix/master.cf, in order
+to avoid conflicts with the real sendmail. Put a "#" character in front of the
+line that defines the smtpd service:
+
+ /etc/postfix/master.cf:
+ #smtp inet n - n - - smtpd
+
+Start the Postfix system:
+
+ # postfix start
+
+or, if you feel nostalgic, use the Postfix sendmail command:
+
+ # sendmail -bd -qwhatever
+
+and watch your maillog file for any error messages. The pathname is /var/log/
+maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
+pathname is defined in the /etc/syslog.conf file.
+
+ $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+Note: the most important error message is logged first. Later messages are not
+as useful.
+
+In order to inspect the mail queue, use one of the following commands:
+
+ $ mailq
+
+ $ sendmail -bp
+
+ $ postqueue -p
+
+See also the "Care and feeding" section 12 below.
+
+88 -- CCoonnffiigguurriinngg PPoossttffiixx ttoo sseenndd aanndd rreecceeiivvee mmaaiill vviiaa vviirrttuuaall iinntteerrffaaccee
+
+Alternatively, you can use the Postfix system to send AND receive mail while
+leaving your Sendmail setup intact, by running Postfix on a virtual interface
+address. Simply configure your mail user agent to directly invoke the Postfix
+sendmail program.
+
+To create a virtual network interface address, study your system ifconfig
+manual page. The command syntax could be any of:
+
+ # iiffccoonnffiigg llee00::11 <> nneettmmaasskk <> uupp
+ # iiffccoonnffiigg eenn00 aalliiaass <> nneettmmaasskk 225555..225555..225555..225555
+
+In the /etc/postfix/main.cf file, I would specify
+
+ /etc/postfix/main.cf:
+ myhostname = virtual.host.tld
+ inet_interfaces = $myhostname
+ mydestination = $myhostname
+
+Follow the instructions in the "Mandatory configuration file edits" in section
+10, and review the "To chroot or not to chroot" text in section 11.
+
+Start the Postfix system:
+
+ # postfix start
+
+or, if you feel nostalgic, use the Postfix sendmail command:
+
+ # sendmail -bd -qwhatever
+
+and watch your maillog file for any error messages. The pathname is /var/log/
+maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
+pathname is defined in the /etc/syslog.conf file.
+
+ $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+Note: the most important error message is logged first. Later messages are not
+as useful.
+
+In order to inspect the mail queue, use one of the following commands:
+
+ $ mailq
+
+ $ sendmail -bp
+
+ $ postqueue -p
+
+See also the "Care and feeding" section 12 below.
+
+99 -- RRuunnnniinngg PPoossttffiixx iinnsstteeaadd ooff SSeennddmmaaiill
+
+Prior to installing Postfix you should save any existing sendmail program files
+as described in section 6. Be sure to keep the old sendmail running for at
+least a couple days to flush any unsent mail. To do so, stop the sendmail
+daemon and restart it as:
+
+ # /usr/sbin/sendmail.OFF -q
+
+Note: this is old sendmail syntax. Newer versions use separate processes for
+mail submission and for running the queue.
+
+After you have visited the "Mandatory configuration file edits" section below,
+you can start the Postfix system with:
+
+ # postfix start
+
+or, if you feel nostalgic, use the Postfix sendmail command:
+
+ # sendmail -bd -qwhatever
+
+and watch your maillog file for any error messages. The pathname is /var/log/
+maillog, /var/log/mail, /var/log/syslog, or something else. Typically, the
+pathname is defined in the /etc/syslog.conf file.
+
+ $ egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+Note: the most important error message is logged first. Later messages are not
+as useful.
+
+In order to inspect the mail queue, use one of the following commands:
+
+ $ mailq
+
+ $ sendmail -bp
+
+ $ postqueue -p
+
+See also the "Care and feeding" section 12 below.
+
+1100 -- MMaannddaattoorryy ccoonnffiigguurraattiioonn ffiillee eeddiittss
+
+Note: the material covered in this section is covered in more detail in the
+BASIC_CONFIGURATION_README document. The information presented below is
+targeted at experienced system administrators.
+
+1100..11 -- PPoossttffiixx ccoonnffiigguurraattiioonn ffiilleess
+
+By default, Postfix configuration files are in /etc/postfix. The two most
+important files are main.cf and master.cf; these files must be owned by root.
+Giving someone else write permission to main.cf or master.cf (or to their
+parent directories) means giving root privileges to that person.
+
+In /etc/postfix/main.cf, you will have to set up a minimal number of
+configuration parameters. Postfix configuration parameters resemble shell
+variables, with two important differences: the first one is that Postfix does
+not know about quotes like the UNIX shell does.
+
+You specify a configuration parameter as:
+
+ /etc/postfix/main.cf:
+ parameter = value
+
+and you use it by putting a "$" character in front of its name:
+
+ /etc/postfix/main.cf:
+ other_parameter = $parameter
+
+You can use $parameter before it is given a value (that is the second main
+difference with UNIX shell variables). The Postfix configuration language uses
+lazy evaluation, and does not look at a parameter value until it is needed at
+runtime.
+
+Whenever you make a change to the main.cf or master.cf file, execute the
+following command in order to refresh a running mail system:
+
+ # postfix reload
+
+1100..22 -- DDeeffaauulltt ddoommaaiinn ffoorr uunnqquuaalliiffiieedd aaddddrreesssseess
+
+First of all, you must specify what domain will be appended to an unqualified
+address (i.e. an address without @domain.tld). The "myorigin" parameter
+defaults to the local hostname, but that is probably OK only for very small
+sites.
+
+Some examples (use only one):
+
+ /etc/postfix/main.cf:
+ myorigin = $myhostname (send mail as "user@$myhostname")
+ myorigin = $mydomain (send mail as "user@$mydomain")
+
+1100..33 -- WWhhaatt ddoommaaiinnss ttoo rreecceeiivvee llooccaallllyy
+
+Next you need to specify what mail addresses Postfix should deliver locally.
+
+Some examples (use only one):
+
+ /etc/postfix/main.cf:
+ mydestination = $myhostname, localhost.$mydomain, localhost
+ mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
+ mydestination = $myhostname
+
+The first example is appropriate for a workstation, the second is appropriate
+for the mailserver for an entire domain. The third example should be used when
+running on a virtual host interface.
+
+1100..44 -- PPrrooxxyy//NNAATT iinntteerrffaaccee aaddddrreesssseess
+
+The proxy_interfaces parameter specifies all network addresses that Postfix
+receives mail on by way of a proxy or network address translation unit. You may
+specify symbolic hostnames instead of network addresses.
+
+IMPORTANT: You must specify your proxy/NAT external addresses when your system
+is a backup MX host for other domains, otherwise mail delivery loops will
+happen when the primary MX host is down.
+
+Example: host behind NAT box running a backup MX host.
+
+ /etc/postfix/main.cf:
+ proxy_interfaces = 1.2.3.4 (the proxy/NAT external network address)
+
+1100..55 -- WWhhaatt llooccaall cclliieennttss ttoo rreellaayy mmaaiill ffrroomm
+
+If your machine is on an open network then you must specify what client IP
+addresses are authorized to relay their mail through your machine into the
+Internet. The default setting includes all subnetworks that the machine is
+attached to. This may give relay permission to too many clients. My own
+settings are:
+
+ /etc/postfix/main.cf:
+ mynetworks = 168.100.189.0/28, 127.0.0.0/8
+
+1100..66 -- WWhhaatt rreellaayy ddeessttiinnaattiioonnss ttoo aacccceepptt ffrroomm ssttrraannggeerrss
+
+If your machine is on an open network then you must also specify whether
+Postfix will forward mail from strangers. The default setting will forward mail
+to all domains (and subdomains of) what is listed in $mydestination. This may
+give relay permission for too many destinations. Recommended settings (use only
+one):
+
+ /etc/postfix/main.cf:
+ relay_domains = (do not forward mail from strangers)
+ relay_domains = $mydomain (my domain and subdomains)
+ relay_domains = $mydomain, other.domain.tld, ...
+
+1100..77 -- OOppttiioonnaall:: ccoonnffiigguurree aa ssmmaarrtt hhoosstt ffoorr rreemmoottee ddeelliivveerryy
+
+If you're behind a firewall, you should set up a relayhost. If you can, specify
+the organizational domain name so that Postfix can use DNS lookups, and so that
+it can fall back to a secondary MX host when the primary MX host is down.
+Otherwise just specify a hard-coded hostname.
+
+Some examples (use only one):
+
+ /etc/postfix/main.cf:
+ relayhost = $mydomain
+ relayhost = [mail.$mydomain]
+
+The form enclosed with [] eliminates DNS MX lookups.
+
+By default, the SMTP client will do DNS lookups even when you specify a relay
+host. If your machine has no access to a DNS server, turn off SMTP client DNS
+lookups like this:
+
+ /etc/postfix/main.cf:
+ disable_dns_lookups = yes
+
+The STANDARD_CONFIGURATION_README file has more hints and tips for firewalled
+and/or dial-up networks.
+
+1100..88 -- CCrreeaattee tthhee aalliiaasseess ddaattaabbaassee
+
+Postfix uses a Sendmail-compatible aliases(5) table to redirect mail for local
+(8) recipients. Typically, this information is kept in two files: in a text
+file /etc/aliases and in an indexed file /etc/aliases.db. The command "postconf
+alias_maps" will tell you the exact location of the text file.
+
+First, be sure to update the text file with aliases for root, postmaster and
+"postfix" that forward mail to a real person. Postfix has a sample aliases file
+/etc/postfix/aliases that you can adapt to local conditions.
+
+ /etc/aliases:
+ root: you
+ postmaster: root
+ postfix: root
+ bin: root
+ etcetera...
+
+Note: there should be no whitespace before the ":".
+
+Finally, build the indexed aliases file with one of the following commands:
+
+ # newaliases
+ # sendmail -bi
+
+1111 -- TToo cchhrroooott oorr nnoott ttoo cchhrroooott
+
+Postfix daemon processes can be configured (via master.cf) to run in a chroot
+jail. The processes run at a fixed low privilege and with access only to the
+Postfix queue directories (/var/spool/postfix). This provides a significant
+barrier against intrusion. The barrier is not impenetrable, but every little
+bit helps.
+
+With the exception of Postfix daemons that deliver mail locally and/or that
+execute non-Postfix commands, every Postfix daemon can run chrooted.
+
+Sites with high security requirements should consider to chroot all daemons
+that talk to the network: the smtp(8) and smtpd(8) processes, and perhaps also
+the lmtp(8) client. The author's own porcupine.org mail server runs all daemons
+chrooted that can be chrooted.
+
+The default /etc/postfix/master.cf file specifies that no Postfix daemon runs
+chrooted. In order to enable chroot operation, edit the file /etc/postfix/
+master.cf. Instructions are in the file.
+
+Note that a chrooted daemon resolves all filenames relative to the Postfix
+queue directory (/var/spool/postfix). For successful use of a chroot jail, most
+UNIX systems require you to bring in some files or device nodes. The examples/
+chroot-setup directory in the source code distribution has a collection of
+scripts that help you set up Postfix chroot environments on different operating
+systems.
+
+Additionally, you almost certainly need to configure syslogd so that it listens
+on a socket inside the Postfix queue directory. Examples for specific systems:
+
+FreeBSD:
+
+ # mkdir -p /var/spool/postfix/var/run
+ # syslogd -l /var/spool/postfix/var/run/log
+
+Linux, OpenBSD:
+
+ # mkdir -p /var/spool/postfix/dev
+ # syslogd -a /var/spool/postfix/dev/log
+
+1122 -- CCaarree aanndd ffeeeeddiinngg ooff tthhee PPoossttffiixx ssyysstteemm
+
+Postfix daemon processes run in the background, and log problems and normal
+activity to the syslog daemon. The names of logfiles are specified in /etc/
+syslog.conf. At the very least you need something like:
+
+ /etc/syslog.conf:
+ mail.err /dev/console
+ mail.debug /var/log/maillog
+
+IMPORTANT: the syslogd will not create files. You must create them before
+(re)starting syslogd.
+
+IMPORTANT: on Linux you need to put a "-" character before the pathname, e.g.,
+-/var/log/maillog, otherwise the syslogd will use more system resources than
+Postfix does.
+
+Hopefully, the number of problems will be small, but it is a good idea to run
+every night before the syslog files are rotated:
+
+ # postfix check
+ # egrep '(reject|warning|error|fatal|panic):' /some/log/file
+
+ * The first line (postfix check) causes Postfix to report file permission/
+ ownership discrepancies.
+
+ * The second line looks for problem reports from the mail software, and
+ reports how effective the relay and junk mail access blocks are. This may
+ produce a lot of output. You will want to apply some postprocessing to
+ eliminate uninteresting information.
+
+The DEBUG_README document describes the meaning of the "warning" etc. labels in
+Postfix logging.
+
diff --git a/README_FILES/IPV6_README b/README_FILES/IPV6_README
new file mode 100644
index 0000000..872756e
--- /dev/null
+++ b/README_FILES/IPV6_README
@@ -0,0 +1,264 @@
+PPoossttffiixx IIPPvv66 SSuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix 2.2 introduces support for the IPv6 (IP version 6) protocol. IPv6
+support for older Postfix versions was available as an add-on patch. The
+section "Compatibility with Postfix <2.2 IPv6 support" below discusses the
+differences between these implementations.
+
+The main feature of interest is that IPv6 uses 128-bit IP addresses instead of
+the 32-bit addresses used by IPv4. It can therefore accommodate a much larger
+number of hosts and networks without ugly kluges such as NAT. A side benefit of
+the much larger address space is that it makes random network scanning
+impractical.
+
+Postfix uses the same SMTP protocol over IPv6 as it already uses over the older
+IPv4 network, and does AAAA record lookups in the DNS in addition to the older
+A records. Information about IPv6 can be found at http://www.ipv6.org/.
+
+This document provides information on the following topics:
+
+ * Supported platforms
+ * Configuration
+ * Known limitations
+ * Compatibility with Postfix <2.2 IPv6 support
+ * IPv6 Support for unsupported platforms
+ * Credits
+
+SSuuppppoorrtteedd PPllaattffoorrmmss
+
+Postfix version 2.2 supports IPv4 and IPv6 on the following platforms:
+
+ * AIX 5.1+
+ * Darwin 7.3+
+ * FreeBSD 4+
+ * Linux 2.4+
+ * NetBSD 1.5+
+ * OpenBSD 2+
+ * Solaris 8+
+ * Tru64Unix V5.1+
+
+On other platforms Postfix will simply use IPv4 as it has always done.
+
+See below for tips how to port Postfix IPv6 support to other environments.
+
+CCoonnffiigguurraattiioonn
+
+Postfix IPv6 support introduces two new main.cf configuration parameters, and
+introduces an important change in address syntax notation in match lists such
+as mynetworks or debug_peer_list.
+
+Postfix IPv6 address syntax is a little tricky, because there are a few places
+where you must enclose an IPv6 address inside "[]" characters, and a few places
+where you must not. It is a good idea to use "[]" only in the few places where
+you have to. Check out the postconf(5) manual whenever you do IPv6 related
+configuration work with Postfix.
+
+ * Instead of hard-coding 127.0.0.1 and ::1 loopback addresses in master.cf,
+ specify "inet_interfaces = loopback-only" in main.cf. This way you can use
+ the same master.cf file regardless of whether or not Postfix will run on an
+ IPv6-enabled system.
+
+ * The first new parameter is called inet_protocols. This specifies what
+ protocols Postfix will use when it makes or accepts network connections,
+ and also controls what DNS lookups Postfix will use when it makes network
+ connections.
+
+ /etc/postfix/main.cf:
+ # You must stop/start Postfix after changing this parameter.
+ inet_protocols = ipv4 (DEFAULT: enable IPv4 only)
+ inet_protocols = all (enable IPv4, and IPv6 if supported)
+ inet_protocols = ipv4, ipv6 (enable both IPv4 and IPv6)
+ inet_protocols = ipv6 (enable IPv6 only)
+
+ By default, Postfix uses IPv4 only, because most systems aren't attached to
+ an IPv6 network.
+
+ o On systems with combined IPv4/IPv6 stacks, attempts to deliver mail via
+ IPv6 would always fail with "network unreachable", and those attempts
+ would only slow down Postfix.
+
+ o Linux kernels don't even load IPv6 protocol support by default. Any
+ attempt to use it would fail immediately.
+
+ Note 1: you must stop and start Postfix after changing the inet_protocols
+ configuration parameter.
+
+ Note 2: if you see error messages like the following, then you're running
+ Linux and need to turn on IPv6 in the kernel: see http://www.ipv6.org/ for
+ hints and tips. Unlike other systems, Linux does not have a combined stack
+ for IPv4 and IPv6, and IPv6 protocol support is not loaded by default.
+
+ postconf: warning: inet_protocols: IPv6 support is disabled: Address
+ family not supported by protocol
+ postconf: warning: inet_protocols: configuring for IPv4 support only
+
+ Note 3: on older Linux and Solaris systems, the setting "inet_protocols =
+ ipv6" will not prevent Postfix from accepting IPv4 connections. Postfix
+ will present the client IP addresses in IPv6 format, though. In all other
+ cases, Postfix always presents IPv4 client IP addresses in the traditional
+ dotted quad IPv4 format.
+
+ * The other new parameter is smtp_bind_address6. This sets the local
+ interface address for outgoing IPv6 SMTP connections, just like the
+ smtp_bind_address parameter does for IPv4:
+
+ /etc/postfix/main.cf:
+ smtp_bind_address6 = 2001:240:587:0:250:56ff:fe89:1
+
+ * If you left the value of the mynetworks parameter at its default (i.e. no
+ mynetworks setting in main.cf) Postfix will figure out by itself what its
+ network addresses are. This is what a typical setting looks like:
+
+ % postconf mynetworks
+ mynetworks = 127.0.0.0/8 168.100.189.0/28 [::1]/128 [fe80::]/10 [2001:
+ 240:587::]/64
+
+ If you did specify the mynetworks parameter value in main.cf, you need
+ update the mynetworks value to include the IPv6 networks the system is in.
+ Be sure to specify IPv6 address information inside "[]", like this:
+
+ /etc/postfix/main.cf:
+ mynetworks = ...IPv4 networks... [::1]/128 [2001:240:587::]/64 ...
+
+NNOOTTEE:: wwhheenn ccoonnffiigguurriinngg PPoossttffiixx mmaattcchh lliissttss ssuucchh aass mmyynneettwwoorrkkss oorr
+ddeebbuugg__ppeeeerr__lliisstt,, yyoouu mmuusstt ssppeecciiffyy IIPPvv66 aaddddrreessss iinnffoorrmmaattiioonn iinnssiiddee ""[[]]"" iinn tthhee
+mmaaiinn..ccff ppaarraammeetteerr vvaalluuee aanndd iinn ffiilleess ssppeecciiffiieedd wwiitthh aa ""//ffiillee//nnaammee"" ppaatttteerrnn..
+IIPPvv66 aaddddrreesssseess ccoonnttaaiinn tthhee ""::"" cchhaarraacctteerr,, aanndd wwoouulldd ootthheerrwwiissee bbee ccoonnffuusseedd wwiitthh
+aa ""ttyyppee::ttaabbllee"" ppaatttteerrnn..
+
+KKnnoowwnn LLiimmiittaattiioonnss
+
+ * Postfix SMTP clients before version 2.8 try to connect over IPv6 before
+ trying IPv4. With more recent Postfix versions, the order of IPv6 versus
+ IPv4 outgoing connection attempts is configurable with the
+ smtp_address_preference parameter.
+
+ * Postfix versions before 2.6 do not support DNSBL (real-time blackhole list)
+ lookups for IPv6 client IP addresses.
+
+ * IPv6 does not have class A, B, C, etc. networks. With IPv6 networks, the
+ setting "mynetworks_style = class" has the same effect as the setting
+ "mynetworks_style = subnet".
+
+ * On Tru64Unix and AIX, Postfix can't figure out the local subnet mask and
+ always assumes a /128 network. This is a problem only with
+ "mynetworks_style = subnet" and no explicit mynetworks setting in main.cf.
+
+CCoommppaattiibbiilliittyy wwiitthh PPoossttffiixx <<22..22 IIPPvv66 ssuuppppoorrtt
+
+Postfix version 2.2 IPv6 support is based on the Postfix/IPv6 patch by Dean
+Strik and others, but differs in a few minor ways.
+
+ * main.cf: The inet_interfaces parameter does not support the notation "ipv6:
+ all" or "ipv4:all". Use the inet_protocols parameter instead.
+
+ * main.cf: Specify "inet_protocols = all" or "inet_protocols = ipv4, ipv6" in
+ order to enable both IPv4 and IPv6 support.
+
+ * main.cf: The inet_protocols parameter also controls what DNS lookups
+ Postfix will attempt to make when delivering or receiving mail.
+
+ * main.cf: Specify "inet_interfaces = loopback-only" to listen on loopback
+ network interfaces only.
+
+ * The lmtp_bind_address and lmtp_bind_address6 features were omitted. The
+ Postfix LMTP client will be absorbed into the SMTP client, so there is no
+ reason to keep adding features to the LMTP client.
+
+ * The SMTP server now requires that IPv6 addresses in SMTP commands are
+ specified as [ipv6:ipv6address], as described in RFC 2821.
+
+ * The IPv6 network address matching code was rewritten from the ground up,
+ and is expected to be closer to the specification. The result may be
+ incompatible with the Postfix/IPv6 patch.
+
+IIPPvv66 SSuuppppoorrtt ffoorr uunnssuuppppoorrtteedd ppllaattffoorrmmss
+
+Getting Postfix IPv6 working on other platforms involves the following steps:
+
+ * Specify how Postfix should find the local network interfaces. Postfix needs
+ this information to avoid mailer loops and to find out if mail for user@
+ [ipaddress] is a local or remote destination.
+
+ If your system has the getifaddrs() routine then add the following to your
+ platform-specific section in src/util/sys_defs.h:
+
+ #ifndef NO_IPV6
+ # define HAS_IPV6
+ # define HAVE_GETIFADDRS
+ #endif
+
+ Otherwise, if your system has the SIOCGLIF ioctl() command in /usr/include/
+ */*.h, add the following to your platform-specific section in src/util/
+ sys_defs.h:
+
+ #ifndef NO_IPV6
+ # define HAS_IPV6
+ # define HAS_SIOCGLIF
+ #endif
+
+ Otherwise, Postfix will have to use the old SIOCGIF commands and get along
+ with reduced IPv6 functionality (it won't be able to figure out your IPv6
+ netmasks, which are needed for "mynetworks_style = subnet". Add this to
+ your platform-specific section in src/util/sys_defs.h:
+
+ #ifndef NO_IPV6
+ # define HAS_IPV6
+ #endif
+
+ * Test if Postfix can figure out its interface information.
+
+ After compiling Postfix in the usual manner, step into the src/util
+ directory and type "mmaakkee iinneett__aaddddrr__llooccaall". Running this file by hand should
+ produce all the interface addresses and network masks, for example:
+
+ % make
+ % cd src/util
+ % make inet_addr_local
+ [... some messages ...]
+ % ./inet_addr_local
+ [... some messages ...]
+ ./inet_addr_local: inet_addr_local: configured 2 IPv4 addresses
+ ./inet_addr_local: inet_addr_local: configured 4 IPv6 addresses
+ 168.100.189.2/255.255.255.224
+ 127.0.0.1/255.0.0.0
+ fe80:1::2d0:b7ff:fe88:2ca7/ffff:ffff:ffff:ffff::
+ 2001:240:587:0:2d0:b7ff:fe88:2ca7/ffff:ffff:ffff:ffff::
+ fe80:5::1/ffff:ffff:ffff:ffff::
+ ::1/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
+
+ The above is for an old FreeBSD machine. Other systems produce slightly
+ different results, but you get the idea.
+
+If none of all this produces a usable result, send email to the postfix-
+users@postfix.org mailing list and we'll try to help you through this.
+
+CCrreeddiittss
+
+The following information is in part based on information that was compiled by
+Dean Strik.
+
+ * Mark Huizer wrote the original Postfix IPv6 patch.
+
+ * Jun-ichiro 'itojun' Hagino of the KAME project made substantial
+ improvements. Since then, we speak of the KAME patch.
+
+ * The PLD Linux Distribution ported the code to other stacks (notably USAGI).
+ We speak of the PLD patch. A very important feature of the PLD patch was
+ that it can work with Lutz Jaenicke's TLS patch for Postfix.
+
+ * Dean Strik extended IPv6 support to platforms other than KAME and USAGI,
+ updated the patch to keep up with Postfix development, and provided a
+ combined IPv6 + TLS patch. Information about his effort can be found on
+ Dean Strik's Postfix website at http://www.ipnet6.org/postfix/.
+
+ * Wietse Venema took Dean Strik's IPv6 patch, merged it into Postfix 2.2, and
+ took the opportunity to eliminate all IPv4-specific code from Postfix that
+ could be removed. For systems without IPv6 support in the kernel and system
+ libraries, Postfix has a simple compatibility layer, so that it will use
+ IPv4 as before.
+
diff --git a/README_FILES/LDAP_README b/README_FILES/LDAP_README
new file mode 100644
index 0000000..6723356
--- /dev/null
+++ b/README_FILES/LDAP_README
@@ -0,0 +1,462 @@
+PPoossttffiixx LLDDAAPP HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+LLDDAAPP SSuuppppoorrtt iinn PPoossttffiixx
+
+Postfix can use an LDAP directory as a source for any of its lookups: aliases
+(5), virtual(5), canonical(5), etc. This allows you to keep information for
+your mail service in a replicated network database with fine-grained access
+controls. By not storing it locally on the mail server, the administrators can
+maintain it from anywhere, and the users can control whatever bits of it you
+think appropriate. You can have multiple mail servers using the same
+information, without the hassle and delay of having to copy it to each.
+
+Topics covered in this document:
+
+ * Building Postfix with LDAP support
+ * Configuring LDAP lookups
+ * Example: aliases
+ * Example: virtual domains/addresses
+ * Example: expanding LDAP groups
+ * Other uses of LDAP lookups
+ * Notes and things to think about
+ * Feedback
+ * Credits
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh LLDDAAPP ssuuppppoorrtt
+
+These instructions assume that you build Postfix from source code as described
+in the INSTALL document. Some modification may be required if you build Postfix
+from a vendor-specific source package.
+
+Note 1: Postfix no longer supports the LDAP version 1 interface.
+
+Note 2: to use LDAP with Debian GNU/Linux's Postfix, all you need is to install
+the postfix-ldap package and you're done. There is no need to recompile
+Postfix.
+
+You need to have LDAP libraries and include files installed somewhere on your
+system, and you need to configure the Postfix Makefiles accordingly.
+
+For example, to build the OpenLDAP libraries for use with Postfix (i.e. LDAP
+client code only), you could use the following command:
+
+ % ./configure --without-kerberos --without-cyrus-sasl --without-tls \
+ --without-threads --disable-slapd --disable-slurpd \
+ --disable-debug --disable-shared
+
+If you're using the libraries from the UM distribution (http://www.umich.edu/
+~dirsvcs/ldap/ldap.html) or OpenLDAP (http://www.openldap.org), something like
+this in the top level of your Postfix source tree should work:
+
+ % make tidy
+ % make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \
+ AUXLIBS_LDAP="-L/usr/local/lib -lldap -L/usr/local/lib -llber"
+
+Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_LDAP. With Postfix
+3.0 and later, the old AUXLIBS variable still supports building a statically-
+loaded LDAP database client, but only the new AUXLIBS_LDAP variable supports
+building a dynamically-loaded or statically-loaded LDAP database client.
+
+ Failure to use the AUXLIBS_LDAP variable will defeat the purpose of dynamic
+ database client loading. Every Postfix executable file will have LDAP
+ database library dependencies. And that was exactly what dynamic database
+ client loading was meant to avoid.
+
+On Solaris 2.x you may have to specify run-time link information, otherwise
+ld.so will not find some of the shared libraries:
+
+ % make tidy
+ % make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \
+ AUXLIBS_LDAP="-L/usr/local/lib -R/usr/local/lib -lldap \
+ -L/usr/local/lib -R/usr/local/lib -llber"
+
+The 'make tidy' command is needed only if you have previously built Postfix
+without LDAP support.
+
+Instead of '/usr/local' specify the actual locations of your LDAP include files
+and libraries. Be sure to not mix LDAP include files and LDAP libraries of
+different versions!!
+
+If your LDAP libraries were built with Kerberos support, you'll also need to
+include your Kerberos libraries in this line. Note that the KTH Kerberos IV
+libraries might conflict with Postfix's lib/libdns.a, which defines dns_lookup.
+If that happens, you'll probably want to link with LDAP libraries that lack
+Kerberos support just to build Postfix, as it doesn't support Kerberos binds to
+the LDAP server anyway. Sorry about the bother.
+
+If you're using one of the Netscape LDAP SDKs, you'll need to change the
+AUXLIBS line to point to libldap10.so or libldapssl30.so or whatever you have,
+and you may need to use the appropriate linker option (e.g. '-R') so the
+executables can find it at runtime.
+
+If you are using OpenLDAP, and the libraries were built with SASL support, you
+can add -DUSE_LDAP_SASL to the CCARGS to enable SASL support. For example:
+
+ CCARGS="-I/usr/local/include -DHAS_LDAP -DUSE_LDAP_SASL"
+
+CCoonnffiigguurriinngg LLDDAAPP llooookkuuppss
+
+In order to use LDAP lookups, define an LDAP source as a table lookup in
+main.cf, for example:
+
+ alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
+
+The file /etc/postfix/ldap-aliases.cf can specify a great number of parameters,
+including parameters that enable LDAP SSL or STARTTLS, and LDAP SASL. For a
+complete description, see the ldap_table(5) manual page.
+
+EExxaammppllee:: llooccaall((88)) aalliiaasseess
+
+Here's a basic example for using LDAP to look up local(8) aliases. Assume that
+in main.cf, you have:
+
+ alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
+
+and in ldap:/etc/postfix/ldap-aliases.cf you have:
+
+ server_host = ldap.example.com
+ search_base = dc=example, dc=com
+
+Upon receiving mail for a local address "ldapuser" that isn't found in the /
+etc/aliases database, Postfix will search the LDAP server listening at port 389
+on ldap.example.com. It will bind anonymously, search for any directory entries
+whose mailacceptinggeneralid attribute is "ldapuser", read the "maildrop"
+attributes of those found, and build a list of their maildrops, which will be
+treated as RFC822 addresses to which the message will be delivered.
+
+EExxaammppllee:: vviirrttuuaall ddoommaaiinnss//aaddddrreesssseess
+
+If you want to keep information for virtual lookups in your directory, it's
+only a little more complicated. First, you need to make sure Postfix knows
+about the virtual domain. An easy way to do that is to add the domain to the
+mailacceptinggeneralid attribute of some entry in the directory. Next, you'll
+want to make sure all of your virtual recipient's mailacceptinggeneralid
+attributes are fully qualified with their virtual domains. Finally, if you want
+to designate a directory entry as the default user for a virtual domain, just
+give it an additional mailacceptinggeneralid (or the equivalent in your
+directory) of "@fake.dom". That's right, no user part. If you don't want a
+catchall user, omit this step and mail to unknown users in the domain will
+simply bounce.
+
+In summary, you might have a catchall user for a virtual domain that looks like
+this:
+
+ dn: cn=defaultrecipient, dc=fake, dc=dom
+ objectclass: top
+ objectclass: virtualaccount
+ cn: defaultrecipient
+ owner: uid=root, dc=someserver, dc=isp, dc=dom
+ 1 -> mailacceptinggeneralid: fake.dom
+ 2 -> mailacceptinggeneralid: @fake.dom
+ 3 -> maildrop: realuser@real.dom
+
+ 1: Postfix knows fake.dom is a valid virtual domain when it looks for this
+ and gets something (the maildrop) back.
+
+ 2: This causes any mail for unknown users in fake.dom to go to this entry
+ ...
+
+ 3: ... and then to its maildrop.
+
+Normal users might simply have one mailacceptinggeneralid and maildrop, e.g.
+"normaluser@fake.dom" and "normaluser@real.dom".
+
+EExxaammppllee:: eexxppaannddiinngg LLDDAAPP ggrroouuppss
+
+LDAP is frequently used to store group member information. There are a number
+of ways of handling LDAP groups. We will show a few examples in order of
+increasing complexity, but owing to the number of independent variables, we can
+only present a tiny portion of the solution space. We show how to:
+
+ 1. query groups as lists of addresses;
+
+ 2. query groups as lists of user objects containing addresses;
+
+ 3. forward special lists unexpanded to a separate list server, for moderation
+ or other processing;
+
+ 4. handle complex schemas by controlling expansion and by treating leaf nodes
+ specially, using features that are new in Postfix 2.4.
+
+The example LDAP entries and implied schema below show two group entries
+("agroup" and "bgroup") and four user entries ("auser", "buser", "cuser" and
+"duser"). The group "agroup" has the users "auser" (1) and "buser" (2) as
+members via DN references in the multi-valued attribute "memberdn", and direct
+email addresses of two external users "auser@example.org" (3) and
+"buser@example.org" (4) stored in the multi-valued attribute "memberaddr". The
+same is true of "bgroup" and "cuser"/"duser" (6)/(7)/(8)/(9), but "bgroup" also
+has a "maildrop" attribute of "bgroup@mlm.example.com" (5):
+
+ dn: cn=agroup, dc=example, dc=com
+ objectclass: top
+ objectclass: ldapgroup
+ cn: agroup
+ mail: agroup@example.com
+ 1 -> memberdn: uid=auser, dc=example, dc=com
+ 2 -> memberdn: uid=buser, dc=example, dc=com
+ 3 -> memberaddr: auser@example.org
+ 4 -> memberaddr: buser@example.org
+
+ dn: cn=bgroup, dc=example, dc=com
+ objectclass: top
+ objectclass: ldapgroup
+ cn: bgroup
+ mail: bgroup@example.com
+ 5 -> maildrop: bgroup@mlm.example.com
+ 6 -> memberdn: uid=cuser, dc=example, dc=com
+ 7 -> memberdn: uid=duser, dc=example, dc=com
+ 8 -> memberaddr: cuser@example.org
+ 9 -> memberaddr: duser@example.org
+
+ dn: uid=auser, dc=example, dc=com
+ objectclass: top
+ objectclass: ldapuser
+ uid: auser
+ 10 -> mail: auser@example.com
+ 11 -> maildrop: auser@mailhub.example.com
+
+ dn: uid=buser, dc=example, dc=com
+ objectclass: top
+ objectclass: ldapuser
+ uid: buser
+ 12 -> mail: buser@example.com
+ 13 -> maildrop: buser@mailhub.example.com
+
+ dn: uid=cuser, dc=example, dc=com
+ objectclass: top
+ objectclass: ldapuser
+ uid: cuser
+ 14 -> mail: cuser@example.com
+
+ dn: uid=duser, dc=example, dc=com
+ objectclass: top
+ objectclass: ldapuser
+ uid: duser
+ 15 -> mail: duser@example.com
+
+Our first use case ignores the "memberdn" attributes, and assumes that groups
+hold only direct "memberaddr" strings as in (3), (4), (8) and (9). The goal is
+to map the group address to the list of constituent "memberaddr" values. This
+is simple, ignoring the various connection related settings (hosts, ports, bind
+settings, timeouts, ...) we have:
+
+ simple.cf:
+ ...
+ search_base = dc=example, dc=com
+ query_filter = mail=%s
+ result_attribute = memberaddr
+ $ postmap -q agroup@example.com ldap:/etc/postfix/simple.cf \
+ auser@example.org,buser@example.org
+
+We search "dc=example, dc=com". The "mail" attribute is used in the
+query_filter to locate the right group, the "result_attribute" setting
+described in ldap_table(5) is used to specify that "memberaddr" values from the
+matching group are to be returned as a comma separated list. Always check
+tables using postmap(1) with the "-q" option, before deploying them into
+production use in main.cf.
+
+Our second use case instead expands "memberdn" attributes (1), (2), (6) and
+(7), follows the DN references and returns the "maildrop" of the referenced
+user entries. Here we use the "special_result_attribute" setting from
+ldap_table(5) to designate the "memberdn" attribute as holding DNs of the
+desired member entries. The "result_attribute" setting selects which attributes
+are returned from the selected DNs. It is important to choose a result
+attribute that is not also present in the group object, because result
+attributes are collected from both the group and the member DNs. In this case
+we choose "maildrop" and assume for the moment that groups never have a
+"maildrop" (the "bgroup" "maildrop" attribute is for a different use case). The
+returned data for "auser" and "buser" is from items (11) and (13) in the
+example data.
+
+ special.cf:
+ ...
+ search_base = dc=example, dc=com
+ query_filter = mail=%s
+ result_attribute = maildrop
+ special_result_attribute = memberdn
+ $ postmap -q agroup@example.com ldap:/etc/postfix/special.cf \
+ auser@mailhub.example.com,buser@mailhub.example.com
+
+Note: if the desired member object result attribute is always also present in
+the group, you get surprising results: the expansion also returns the address
+of the group. This is a known limitation of Postfix releases prior to 2.4, and
+is addressed in the new with Postfix 2.4 "leaf_result_attribute" feature
+described in ldap_table(5).
+
+Our third use case has some groups that are expanded immediately, and other
+groups that are forwarded to a dedicated mailing list manager host for delayed
+expansion. This uses two LDAP tables, one for users and forwarded groups and a
+second for groups that can be expanded immediately. It is assumed that groups
+that require forwarding are never nested members of groups that are directly
+expanded.
+
+ no_expand.cf:
+ ...
+ search_base = dc=example, dc=com
+ query_filter = mail=%s
+ result_attribute = maildrop
+ expand.cf
+ ...
+ search_base = dc=example, dc=com
+ query_filter = mail=%s
+ result_attribute = maildrop
+ special_result_attribute = memberdn
+ $ postmap -q auser@example.com \
+ ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
+ auser@mailhub.example.com
+ $ postmap -q agroup@example.com \
+ ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
+ auser@mailhub.example.com,buser@mailhub.example.com
+ $ postmap -q bgroup@example.com \
+ ldap:/etc/postfix/no_expand.cf ldap:/etc/postfix/expand.cf \
+ bgroup@mlm.example.com
+
+Non-group objects and groups with delayed expansion (those that have a maildrop
+attribute) are rewritten to a single maildrop value. Groups that don't have a
+maildrop are expanded as the second use case. This admits a more elegant
+solution with Postfix 2.4 and later.
+
+Our final use case is the same as the third, but this time uses new features in
+Postfix 2.4. We now are able to use just one LDAP table and no longer need to
+assume that forwarded groups are never nested inside expanded groups.
+
+ fancy.cf:
+ ...
+ search_base = dc=example, dc=com
+ query_filter = mail=%s
+ result_attribute = memberaddr
+ special_result_attribute = memberdn
+ terminal_result_attribute = maildrop
+ leaf_result_attribute = mail
+ $ postmap -q auser@example.com ldap:/etc/postfix/fancy.cf \
+ auser@mailhub.example.com
+ $ postmap -q cuser@example.com ldap:/etc/postfix/fancy.cf \
+ cuser@example.com
+ $ postmap -q agroup@example.com ldap:/etc/postfix/fancy.cf \
+
+ auser@mailhub.example.com,buser@mailhub.example.com,auser@example.org,buser@example.org
+ $ postmap -q bgroup@example.com ldap:/etc/postfix/fancy.cf \
+ bgroup@mlm.example.com
+
+Above, delayed expansion is enabled via "terminal_result_attribute", which, if
+present, is used as the sole result and all other expansion is suppressed.
+Otherwise, the "leaf_result_attribute" is only returned for leaf objects that
+don't have a "special_result_attribute" (non-groups), while the
+"result_attribute" (direct member address of groups) is returned at every level
+of recursive expansion, not just the leaf nodes. This fancy example illustrates
+all the features of Postfix 2.4 group expansion.
+
+OOtthheerr uusseess ooff LLDDAAPP llooookkuuppss
+
+Other common uses for LDAP lookups include rewriting senders and recipients
+with Postfix's canonical lookups, for example in order to make mail leaving
+your site appear to be coming from "First.Last@example.com" instead of
+"userid@example.com".
+
+NNootteess aanndd tthhiinnggss ttoo tthhiinnkk aabboouutt
+
+ * The bits of schema and attribute names used in this document are just
+ examples. There's nothing special about them, other than that some are the
+ defaults in the LDAP configuration parameters. You can use whatever schema
+ you like, and configure Postfix accordingly.
+
+ * You probably want to make sure that mailacceptinggeneralids are unique, and
+ that not just anyone can specify theirs as postmaster or root, say.
+
+ * An entry can have an arbitrary number of mailacceptinggeneralids or
+ maildrops. Maildrops can also be comma-separated lists of addresses. They
+ will all be found and returned by the lookups. For example, you could
+ define an entry intended for use as a mailing list that looks like this
+ (Warning! Schema made up just for this example):
+
+ dn: cn=Accounting Staff List, dc=example, dc=com
+ cn: Accounting Staff List
+ o: example.com
+ objectclass: maillist
+ mailacceptinggeneralid: accountingstaff
+ mailacceptinggeneralid: accounting-staff
+ maildrop: mylist-owner
+ maildrop: an-accountant
+ maildrop: some-other-accountant
+ maildrop: this, that, theother
+
+ * If you use an LDAP map for lookups other than aliases, you may have to make
+ sure the lookup makes sense. In the case of virtual lookups, maildrops
+ other than mail addresses are pretty useless, because Postfix can't know
+ how to set the ownership for program or file delivery. Your qquueerryy__ffiilltteerr
+ should probably look something like this:
+
+ query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")
+ (maildrop="*:*")(maildrop="*/*"))))
+
+ * And for that matter, even for aliases, you may not want users able to
+ specify their maildrops as programs, includes, etc. This might be
+ particularly pertinent on a "sealed" server where they don't have local
+ UNIX accounts, but exist only in LDAP and Cyrus. You might allow the fun
+ stuff only for directory entries owned by an administrative account, so
+ that if the object had a program as its maildrop and weren't owned by
+ "cn=root" it wouldn't be returned as a valid local user. This will require
+ some thought on your part to implement safely, considering the
+ ramifications of this type of delivery. You may decide it's not worth the
+ bother to allow any of that nonsense in LDAP lookups, ban it in the
+ qquueerryy__ffiilltteerr, and keep things like majordomo lists in local alias
+ databases.
+
+ query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")
+ (maildrop="*:*")(maildrop="*/*"))(owner=cn=root, dc=your, dc=com)))
+
+ * LDAP lookups are slower than local DB or DBM lookups. For most sites they
+ won't be a bottleneck, but it's a good idea to know how to tune your
+ directory service.
+
+ * Multiple LDAP maps share the same LDAP connection if they differ only in
+ their query related parameters: base, scope, query_filter, and so on. To
+ take advantage of this, avoid spurious differences in the definitions of
+ LDAP maps: host selection order, version, bind, tls parameters, ... should
+ be the same for multiple maps whenever possible.
+
+FFeeeeddbbaacckk
+
+If you have questions, send them to postfix-users@postfix.org. Please include
+relevant information about your Postfix setup: LDAP-related output from
+postconf, which LDAP libraries you built with, and which directory server
+you're using. If your question involves your directory contents, please include
+the applicable bits of some directory entries.
+
+CCrreeddiittss
+
+ * Manuel Guesdon: Spotted a bug with the timeout attribute.
+ * John Hensley: Multiple LDAP sources with more configurable attributes.
+ * Carsten Hoeger: Search scope handling.
+ * LaMont Jones: Domain restriction, URL and DN searches, multiple result
+ attributes.
+ * Mike Mattice: Alias dereferencing control.
+ * Hery Rakotoarisoa: Patches for LDAPv3 updating.
+ * Prabhat K Singh: Wrote the initial Postfix LDAP lookups and connection
+ caching.
+ * Keith Stevenson: RFC 2254 escaping in queries.
+ * Samuel Tardieu: Noticed that searches could include wildcards, prompting
+ the work on RFC 2254 escaping in queries. Spotted a bug in binding.
+ * Sami Haahtinen: Referral chasing and v3 support.
+ * Victor Duchovni: ldap_bind() timeout. With fixes from LaMont Jones:
+ OpenLDAP cache deprecation. Limits on recursion, expansion and search
+ results size. LDAP connection sharing for maps differing only in the query
+ parameters.
+ * Liviu Daia: Support for SSL/STARTTLS. Support for storing map definitions
+ in external files (ldap:/path/ldap.cf) needed to securely store passwords
+ for plain auth.
+ * Liviu Daia revised the configuration interface and added the main.cf
+ configuration feature.
+ * Liviu Daia with further refinements from Jose Luis Tallon and Victor
+ Duchovni developed the common query, result_format, domain and
+ expansion_limit interface for LDAP, MySQL and PosgreSQL.
+ * Gunnar Wrobel provided a first implementation of a feature to limit LDAP
+ search results to leaf nodes only. Victor generalized this into the Postfix
+ 2.4 "leaf_result_attribute" feature.
+ * Quanah Gibson-Mount contributed support for advanced LDAP SASL mechanisms,
+ beyond the password-based LDAP "simple" bind.
+
+And of course Wietse.
+
diff --git a/README_FILES/LINUX_README b/README_FILES/LINUX_README
new file mode 100644
index 0000000..a8569c7
--- /dev/null
+++ b/README_FILES/LINUX_README
@@ -0,0 +1,61 @@
+PPoossttffiixx aanndd LLiinnuuxx
+
+-------------------------------------------------------------------------------
+
+HHoosstt llooookkuupp iissssuueess
+
+By default Linux /etc/hosts lookups do not support multiple IP address 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
+addresses:
+
+ /etc/host.conf:
+ ...
+ # We have machines with multiple IP addresses.
+ multi on
+ ...
+
+Alternatively, specify the RESOLV_MULTI environment variable in main.cf:
+
+ /etc/postfix/main.cf:
+ import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY
+ DISPLAY LANG=C RESOLV_MULTI=on
+
+BBeerrkkeelleeyy DDBB iissssuueess
+
+If you can't compile Postfix because the file "db.h" isn't found, then you MUST
+install the Berkeley DB development package (name: db???-devel-???) that
+matches your system library. You can find out what is installed with the rpm
+command. For example:
+
+ $ rrppmm --qqff //uussrr//lliibb//lliibbddbb..ssoo
+ db4-4.3.29-2
+
+This means that you need to install db4-devel-4.3.29-2 (on some systems,
+specify "rrppmm --qqff //lliibb//lliibbddbb..ssoo" instead).
+
+DO NOT download some Berkeley DB version from the network. Every Postfix
+program will dump core when it is built with a different Berkeley DB version
+than the version that is used by the system library routines. See the DB_README
+file for further information.
+
+PPrrooccmmaaiill iissssuueess
+
+On RedHat Linux 7.1 and later pprrooccmmaaiill no longer has permission to write the
+mail spool directory. Workaround:
+
+ # chmod 1777 /var/spool/mail
+
+SSyyssllooggdd ppeerrffoorrmmaannccee
+
+LINUX ssyyssllooggdd uses synchronous writes by default. Because of this, ssyyssllooggdd can
+actually use more system resources than Postfix. To avoid such badness, disable
+synchronous mail logfile writes by editing /etc/syslog.conf and by prepending a
+- to the logfile name:
+
+ /etc/syslog.conf:
+ mail.* -/var/log/mail.log
+
+Send a "kkiillll --HHUUPP" to the ssyyssllooggdd to make the change effective.
+
diff --git a/README_FILES/LMDB_README b/README_FILES/LMDB_README
new file mode 100644
index 0000000..e63640f
--- /dev/null
+++ b/README_FILES/LMDB_README
@@ -0,0 +1,123 @@
+PPoossttffiixx OOppeennLLDDAAPP LLMMDDBB HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix uses databases of various kinds to store and look up information.
+Postfix databases are specified as "type:name". OpenLDAP LMDB (called "LMDB"
+from here on) implements the Postfix database type "lmdb". The name of a
+Postfix LMDB database is the name of the database file without the ".lmdb"
+suffix.
+
+This document describes:
+
+ * Building Postfix with LMDB support.
+
+ * Configuring LMDB settings.
+
+ * Using LMDB maps with non-Postfix programs.
+
+ * Required minimum LMDB patchlevel.
+
+ * Credits.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh LLMMDDBB ssuuppppoorrtt
+
+Postfix normally does not enable LMDB support. To build Postfix with LMDB
+support, use something like:
+
+ % make makefiles CCARGS="-DHAS_LMDB -I/usr/local/include" \
+ AUXLIBS_LMDB="-L/usr/local/lib -llmdb"
+ % make
+
+Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_LMDB. With Postfix
+3.0 and later, the old AUXLIBS variable still supports building a statically-
+loaded LMDB database client, but only the new AUXLIBS_LMDB variable supports
+building a dynamically-loaded or statically-loaded LMDB database client.
+
+ Failure to use the AUXLIBS_LMDB variable will defeat the purpose of dynamic
+ database client loading. Every Postfix executable file will have LMDB
+ database library dependencies. And that was exactly what dynamic database
+ client loading was meant to avoid.
+
+Solaris may need this:
+
+ % make makefiles CCARGS="-DHAS_LMDB -I/usr/local/include" \
+ AUXLIBS_LMDB="-R/usr/local/lib -L/usr/local/lib -llmdb"
+ % make
+
+The exact pathnames depend on how LMDB was installed.
+
+When building Postfix fails with:
+
+ undefined reference to `pthread_mutexattr_destroy'
+ undefined reference to `pthread_mutexattr_init'
+ undefined reference to `pthread_mutex_lock'
+
+Add the "-lpthread" library to the "make makefiles" command.
+
+ % make makefiles .... AUXLIBS_LMDB="... -lpthread"
+
+CCoonnffiigguurriinngg LLMMDDBB sseettttiinnggss
+
+Postfix provides one configuration parameter that controls LMDB database
+behavior.
+
+ * lmdb_map_size (default: 16777216). This setting specifies the initial LMDB
+ database size limit in bytes. Each time a database becomes "full", its size
+ limit is doubled. The maximum size is the largest signed integer value of
+ "long".
+
+UUssiinngg LLMMDDBB mmaappss wwiitthh nnoonn--PPoossttffiixx pprrooggrraammss
+
+Programs that use LMDB's built-in locking protocol will corrupt a Postfix LMDB
+database or will read garbage.
+
+Postfix does not use LMDB's built-in locking protocol, because that would
+require world-writable lockfiles, and would violate Postfix security policy.
+Instead, Postfix uses external locks based on fcntl(2) to prevent writers from
+corrupting the database, and to prevent readers from receiving garbage.
+
+See lmdb_table(5) for a detailed description of the locking protocol that all
+programs must use when they access a Postfix LMDB database.
+
+RReeqquuiirreedd mmiinniimmuumm LLMMDDBB ppaattcchhlleevveell
+
+Currently, Postfix requires LMDB 0.9.11 or later. The required minimum LMDB
+patchlevel has evolved over time, as the result of Postfix deployment
+experience:
+
+ * LMDB 0.9.11 allows Postfix daemons to log an LMDB error message, instead of
+ falling out of the sky without any notification.
+
+ * LMDB 0.9.10 closes an information leak where LMDB was writing up to 4-kbyte
+ chunks of uninitialized heap memory to the database. This would persist
+ information that was not meant to be persisted, or share information that
+ was not meant to be shared.
+
+ * LMDB 0.9.9 allows Postfix to use external (fcntl()-based) locks, instead of
+ having to use world-writable LMDB lock files, violating the Postfix
+ security model in multiple ways.
+
+ * LMDB 0.9.8 allows Postfix to recover from a "database full" error without
+ having to close the database. This version adds support to update the
+ database size limit on-the-fly. This is necessary because Postfix database
+ sizes vary with mail server load.
+
+ * LMDB 0.9.7 allows the postmap(1) and postalias(1) commands to use a bulk-
+ mode transaction larger than the amount of physical memory. This is
+ necessary because LMDB supports databases larger than physical memory.
+
+CCrreeddiittss
+
+ * Howard Chu contributed the initial Postfix dict_lmdb driver.
+
+ * Wietse Venema wrote an abstraction layer (slmdb) that behaves more like
+ Berkeley DB, NDBM, etc. This layer automatically retries an LMDB request
+ when a database needs to be resized, or after a database was resized by a
+ different process.
+
+ * Howard and Wietse went through many iterations with changes to both LMDB
+ and Postfix, with input from Viktor Dukhovni.
+
diff --git a/README_FILES/LOCAL_RECIPIENT_README b/README_FILES/LOCAL_RECIPIENT_README
new file mode 100644
index 0000000..ea4ce25
--- /dev/null
+++ b/README_FILES/LOCAL_RECIPIENT_README
@@ -0,0 +1,117 @@
+RReejjeeccttiinngg UUnnkknnoowwnn LLooccaall RReecciippiieennttss wwiitthh PPoossttffiixx
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+As of Postfix version 2.0, the Postfix SMTP server rejects mail for unknown
+recipients in local domains (domains that match $mydestination or the IP
+addresses in $inet_interfaces or $proxy_interfaces) with "User unknown in local
+recipient table". This feature was optional with earlier Postfix versions.
+
+The good news is that this keeps undeliverable mail out of your queue, so that
+your mail queue is not clogged up with undeliverable MAILER-DAEMON messages.
+
+The bad news is that it may cause mail to be rejected when you upgrade from a
+Postfix system that was not configured to reject mail for unknown local
+recipients.
+
+This document describes what steps are needed in order to reject unknown local
+recipients correctly.
+
+ * Configuring local_recipient_maps in main.cf
+ * When you need to change the local_recipient_maps setting in main.cf
+ * Local recipient table format
+
+CCoonnffiigguurriinngg llooccaall__rreecciippiieenntt__mmaappss iinn mmaaiinn..ccff
+
+The local_recipient_maps parameter specifies lookup tables with all names or
+addresses of local recipients. A recipient address is local when its domain
+matches $mydestination, $inet_interfaces or $proxy_interfaces. If a local
+username or address is not listed in $local_recipient_maps, then the Postfix
+SMTP server will reject the address with "User unknown in local recipient
+table".
+
+The default setting, shown below, assumes that you use the default Postfix
+local(8) delivery agent for local delivery, where recipients are either UNIX
+accounts or local aliases:
+
+ /etc/postfix/main.cf:
+ local_recipient_maps = proxy:unix:passwd.byname $alias_maps
+
+To turn off unknown local recipient rejects by the SMTP server, specify:
+
+ /etc/postfix/main.cf:
+ local_recipient_maps =
+
+That is, an empty value. With this setting, the Postfix SMTP server will not
+reject mail with "User unknown in local recipient table". DDoonn''tt ddoo tthhiiss oonn
+ssyysstteemmss tthhaatt rreecceeiivvee mmaaiill ddiirreeccttllyy ffrroomm tthhee IInntteerrnneett.. WWiitthh ttooddaayy''ss wwoorrmmss aanndd
+vviirruusseess,, PPoossttffiixx wwiillll bbeeccoommee aa bbaacckkssccaatttteerr ssoouurrccee:: iitt aacccceeppttss mmaaiill ffoorr nnoonn--
+eexxiisstteenntt rreecciippiieennttss aanndd tthheenn ttrriieess ttoo rreettuurrnn tthhaatt mmaaiill aass ""uunnddeelliivveerraabbllee"" ttoo
+tthhee oofftteenn ffoorrggeedd sseennddeerr aaddddrreessss.
+
+WWhheenn yyoouu nneeeedd ttoo cchhaannggee tthhee llooccaall__rreecciippiieenntt__mmaappss sseettttiinngg iinn mmaaiinn..ccff
+
+ * Problem: you don't use the default Postfix local(8) delivery agent for
+ domains matching $mydestination, $inet_interfaces, or $proxy_interfaces.
+ For example, you redefined the "local_transport" setting in main.cf.
+
+ Solution: your local_recipient_maps setting needs to specify a database
+ that lists all the known user names or addresses for that delivery agent.
+ For example, if you deliver users in $mydestination etc. domains via the
+ virtual(8) delivery agent, specify:
+
+ /etc/postfix/main.cf
+ mydestination = $myhostname localhost.$mydomain localhost ...
+ local_transport = virtual
+ local_recipient_maps = $virtual_mailbox_maps
+
+ If you use a different delivery agent for $mydestination etc. domains, see
+ the section "Local recipient table format" below for a description of how
+ the table should be populated.
+
+ * Problem: you use the mailbox_transport or fallback_transport feature of the
+ Postfix local(8) delivery agent in order to deliver mail to non-UNIX
+ accounts.
+
+ Solution: you need to add the database that lists the non-UNIX users:
+
+ /etc/postfix/main.cf
+ local_recipient_maps = proxy:unix:passwd.byname, $alias_maps,
+
+
+ See the section "Local recipient table format" below for a description of
+ how the table should be populated.
+
+ * Problem: you use the luser_relay feature of the Postfix local delivery
+ agent.
+
+ Solution: you must disable the local_recipient_maps feature completely, so
+ that Postfix accepts mail for all local addresses:
+
+ /etc/postfix/main.cf
+ local_recipient_maps =
+
+LLooccaall rreecciippiieenntt ttaabbllee ffoorrmmaatt
+
+If you use local files in postmap(1) format, then local_recipient_maps expects
+the following table format:
+
+ * In the left-hand side, specify a bare username, an "@domain.tld" wild-card,
+ or specify a complete "user@domain.tld" address.
+
+ * You have to specify something on the right-hand side of the table, but the
+ value is ignored by local_recipient_maps.
+
+If you use lookup tables based on NIS, LDAP, MYSQL, or PGSQL, then
+local_recipient_maps does the same queries as for local files in postmap(1)
+format, and expects the same results.
+
+With regular expression tables, Postfix only queries with the full recipient
+address, and not with the bare username or the "@domain.tld" wild-card.
+
+NOTE: a lookup table should always return a result when the address exists, and
+should always return "not found" when the address does not exist. In
+particular, a zero-length result does not count as a "not found" result.
+
diff --git a/README_FILES/MAILDROP_README b/README_FILES/MAILDROP_README
new file mode 100644
index 0000000..e1d320e
--- /dev/null
+++ b/README_FILES/MAILDROP_README
@@ -0,0 +1,129 @@
+PPoossttffiixx ++ MMaaiillddrroopp HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+This document discusses various options to plug the maildrop delivery agent
+into Postfix:
+
+ * Direct delivery without the local delivery agent
+ * Indirect delivery via the local delivery agent
+ * Credits
+
+DDiirreecctt ddeelliivveerryy wwiitthhoouutt tthhee llooccaall ddeelliivveerryy aaggeenntt
+
+Postfix can be configured to deliver mail directly to maildrop, without using
+the local(8) delivery agent as an intermediate. This means that you do not get
+local aliases(5) expansion or $HOME/.forward file processing. You would
+typically do this for hosted domains with recipients that don't have UNIX home
+directories.
+
+The following example shows how to use maildrop for some.domain and for
+someother.domain. The example comes in two parts.
+
+Part 1 describes changes to the main.cf file:
+
+ 1 /etc/postfix/main.cf:
+ 2 maildrop_destination_recipient_limit = 1
+ 3 virtual_mailbox_domains = some.domain someother.domain
+ 4 virtual_transport = maildrop
+ 5 virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox
+ 6 virtual_alias_maps = hash:/etc/postfix/virtual_alias
+ 7
+ 8 /etc/postfix/virtual_mailbox:
+ 9 user1@some.domain ...text here does not matter...
+ 10 user2@some.domain ...text here does not matter...
+ 11 user3@someother.domain ...text here does not matter...
+ 12
+ 13 /etc/postfix/virtual_alias:
+ 14 postmaster@some.domain postmaster
+ 15 postmaster@someother.domain postmaster
+
+ * Line 2 is needed so that Postfix will provide one recipient at a time to
+ the maildrop delivery agent.
+
+ * Line 3 informs Postfix that some.domain and someother.domain are so-called
+ virtual mailbox domains. Instead of listing the names in main.cf you can
+ also list them in a file; see the virtual_mailbox_domains documentation for
+ details.
+
+ * Line 4 specifies that mail for some.domain and someother.domain should be
+ delivered by the maildrop delivery agent.
+
+ * Lines 5 and 8-11 specify what recipients the Postfix SMTP server should
+ receive mail for. This prevents the mail queue from becoming clogged with
+ undeliverable messages. Specify an empty value ("virtual_mailbox_maps =")
+ to disable this feature.
+
+ * Lines 6 and 13-15 redirect mail for postmaster to the local postmaster. RFC
+ 821 requires that every domain has a postmaster address.
+
+The vmail userid as used below is the user that maildrop should run as. This
+would be the owner of the virtual mailboxes if they all have the same owner. If
+maildrop is suid (see maildrop documentation), then maildrop will change to the
+appropriate owner to deliver the mail.
+
+Note: Do not use the postfix user as the maildrop user.
+
+Part 2 describes changes to the master.cf file:
+
+ /etc/postfix/master.cf:
+ maildrop unix - n n - - pipe
+ flags=ODRhu user=vmail argv=/path/to/maildrop -d ${recipient}
+
+The pipe(8) manual page gives a detailed description of the above command line
+arguments, and more.
+
+If you want to support user+extension@domain style addresses, use the following
+instead:
+
+ /etc/postfix/master.cf:
+ maildrop unix - n n - - pipe
+ flags=ODRhu user=vmail argv=/path/to/maildrop
+ -d ${user}@${domain} ${extension} ${recipient} ${user} ${nexthop}
+
+The mail is delivered to ${user}@${domain} (search key for maildrop userdb
+lookup). The ${extension} and the other address components are available to
+maildrop rules as $1, $2, $3, ... and can be omitted from master.cf or ignored
+by maildrop when not needed.
+
+With Postfix 2.4 and earlier, use ${nexthop} instead of ${domain}.
+
+IInnddiirreecctt ddeelliivveerryy vviiaa tthhee llooccaall ddeelliivveerryy aaggeenntt
+
+Postfix can be configured to deliver mail to maildrop via the local delivery
+agent. This is slightly less efficient than the "direct" approach discussed
+above, but gives you the convenience of local aliases(5) expansion and
+$HOME/.forward file processing. You would typically use this for domains that
+are listed in mydestination and that have users with a UNIX system account.
+
+To configure maildrop delivery for all UNIX system accounts:
+
+ /etc/postfix/main.cf:
+ mailbox_command = /path/to/maildrop -d ${USER}
+
+Note: ${USER} is spelled in upper case.
+
+To enable maildrop delivery for specific users only, you can use the Postfix
+local(8) delivery agent's mailbox_command_maps feature:
+
+ /etc/postfix/main.cf:
+ mailbox_command_maps = hash:/etc/postfix/mailbox_commands
+
+ /etc/postfix/mailbox_commands:
+ you /path/to/maildrop -d ${USER}
+
+Maildrop delivery for specific users is also possible by invoking it from the
+user's $HOME/.forward file:
+
+ /home/you/.forward:
+ "|/path/to/maildrop -d ${USER}"
+
+CCrreeddiittss
+
+ * The original text was kindly provided by Russell Mosemann.
+ * Victor Duchovni provided tips for supporting user+foo@domain addresses.
+ * Tonni Earnshaw contributed text about delivery via the local(8) delivery
+ agent.
+
diff --git a/README_FILES/MEMCACHE_README b/README_FILES/MEMCACHE_README
new file mode 100644
index 0000000..f89e148
--- /dev/null
+++ b/README_FILES/MEMCACHE_README
@@ -0,0 +1,50 @@
+PPoossttffiixx mmeemmccaacchhee cclliieenntt HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+The Postfix memcache client allows you to hook up Postfix to a memcache server.
+The current implementation supports one memcache server per Postfix table, with
+one optional Postfix database that provides persistent backup. The Postfix
+memcache client supports the lookup, update, delete and sequence operations.
+The sequence (i.e. first/next) operation requires a backup database that
+supports this operation.
+
+Typically, the Postfix memcache client is used to reduce query load on a
+persistent database, but it may also be used to query a memory-only database
+for low-value, easy-to-recreate, information such as a reputation cache for
+postscreen(8), verify(8) or greylisting.
+
+LLiimmiittaattiioonnss
+
+ * The Postfix memcache client cannot be used for security-sensitive tables
+ such as alias_maps (these may contain "|command" and "/file/name"
+ destinations), or virtual_uid_maps, virtual_gid_maps and
+ virtual_mailbox_maps (these specify UNIX process privileges or "/file/name"
+ destinations). Typically, a memcache database is writable by any process
+ that can talk to the memcache server; in contrast, security-sensitive
+ tables must never be writable by the unprivileged Postfix user.
+
+ * The Postfix memcache client requires additional configuration when used as
+ postscreen(8) or verify(8) cache. For details see the backup and ttl
+ parameter discussions in the memcache_table(5) manual page.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh mmeemmccaacchhee ssuuppppoorrtt
+
+The Postfix memcache client has no external dependencies, and is therefore
+built into Postfix by default.
+
+CCoonnffiigguurriinngg mmeemmccaacchhee llooookkuupp ttaabblleess
+
+Configuration is described in the memcache_table(5) manpage.
+
+CCrreeddiittss
+
+The first memcache client for Postfix was written by Omar Kilani, and was based
+on the libmemcache library.
+
+Wietse wrote the current memcache client from the ground up for Postfix version
+2.9. This implementation does not use libmemcache, and bears no resemblance to
+earlier work.
+
diff --git a/README_FILES/MILTER_README b/README_FILES/MILTER_README
new file mode 100644
index 0000000..730aa5b
--- /dev/null
+++ b/README_FILES/MILTER_README
@@ -0,0 +1,620 @@
+PPoossttffiixx bbeeffoorree--qquueeuuee MMiilltteerr ssuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+Postfix implements support for the Sendmail version 8 Milter (mail filter)
+protocol. This protocol is used by applications that run outside the MTA to
+inspect SMTP events (CONNECT, DISCONNECT), SMTP commands (HELO, MAIL FROM,
+etc.) as well as mail content (headers and body). All this happens before mail
+is queued.
+
+The reason for adding Milter support to Postfix is that there exists a large
+collection of applications, not only to block unwanted mail, but also to verify
+authenticity (examples: OpenDKIM and DMARC) or to digitally sign mail (example:
+OpenDKIM). Having yet another Postfix-specific version of all that software is
+a poor use of human and system resources.
+
+The Milter protocol has evolved over time, and different Postfix versions
+implement different feature sets. See the workarounds and limitations sections
+at the end of this document for differences between Postfix and Sendmail
+implementations.
+
+This document provides information on the following topics:
+
+ * How Milter applications plug into Postfix
+ * Building Milter applications
+ * Running Milter applications
+ * Configuring Postfix
+ * Workarounds
+ * Limitations
+
+HHooww MMiilltteerr aapppplliiccaattiioonnss pplluugg iinnttoo PPoossttffiixx
+
+The Postfix Milter implementation uses two different lists of mail filters: one
+list of filters for SMTP mail only, and one list of filters for non-SMTP mail.
+The two lists have different capabilities, which is unfortunate. Avoiding this
+would require major restructuring of Postfix.
+
+ * The SMTP-only filters handle mail that arrives via the Postfix smtpd(8)
+ server. They are typically used to filter unwanted mail and to sign mail
+ from authorized SMTP clients. You specify SMTP-only Milter applications
+ with the smtpd_milters parameter as described in a later section. Mail that
+ arrives via the Postfix smtpd(8) server is not filtered by the non-SMTP
+ filters that are described next.
+
+ * The non-SMTP filters handle mail that arrives via the Postfix sendmail(1)
+ command-line or via the Postfix qmqpd(8) server. They are typically used to
+ digitally sign mail only. Although non-SMTP filters can be used to filter
+ unwanted mail, they have limitations compared to the SMTP-only filters. You
+ specify non-SMTP Milter applications with the non_smtpd_milters parameter
+ as described in a later section.
+
+For those who are familiar with the Postfix architecture, the figure below
+shows how Milter applications plug into Postfix. Names followed by a number are
+Postfix commands or server programs, while unnumbered names inside shaded areas
+represent Postfix queues. To avoid clutter, the path for local submission is
+simplified (the OVERVIEW document has a more complete description of the
+Postfix architecture).
+
+ SMTP-only non-SMTP
+ filters filters
+
+ ^ |
+ | v
+ ^ |
+ | |
+ Network -> smtpd(8) | |
+ | v
+
+ \
+
+ Network -> qmqpd(8) -> cleanup(8) -> incoming
+
+ /
+
+ pickup(8)
+
+ :
+
+ Local -> sendmail(1)
+
+BBuuiillddiinngg MMiilltteerr aapppplliiccaattiioonnss
+
+Milter applications have been written in C, JAVA and Perl, but this document
+deals with C applications only. For these, you need an object library that
+implements the Sendmail 8 Milter protocol. Postfix currently does not provide
+such a library, but Sendmail does.
+
+Some systems install the Sendmail libmilter library by default. With other
+systems, libmilter may be provided by a package (called "sendmail-devel" on
+some Linux systems).
+
+Once libmilter is installed, applications such as OpenDKIM and OpenDMARC build
+out of the box without requiring any tinkering:
+
+ $ ggzzccaatt ooppeennddkkiimm--xx..yy..zz..ttaarr..ggzz || ttaarr xxff --
+ $ ccdd ooppeennddkkiimm--xx..yy..zz
+ $ ..//ccoonnffiigguurree ......ooppttiioonnss......
+ $ mmaakkee
+ [...lots of output omitted...]
+ $ mmaakkee iinnssttaallll
+
+RRuunnnniinngg MMiilltteerr aapppplliiccaattiioonnss
+
+To run a Milter application, see the documentation of the filter for options. A
+typical command looks like this:
+
+ # //ssoommee//wwhheerree//ooppeennddkkiimm --ll --uu uusseerriidd --pp iinneett::ppoorrttnnuummbbeerr@@llooccaallhhoosstt ......ootthheerr
+ ooppttiioonnss......
+
+Please specify a userid value that isn't used for other applications (not
+"postfix", not "www", etc.).
+
+CCoonnffiigguurriinngg PPoossttffiixx
+
+Like Sendmail, Postfix has a lot of configuration options that control how it
+talks to Milter applications. Besides global options that apply to all Milter
+applications, Postfix 3.0 and later support per-Milter timeouts, per-Milter
+error handling, etc.
+
+Information in this section:
+
+ * SMTP-Only Milter applications
+ * Non-SMTP Milter applications
+ * Milter error handling
+ * Milter protocol version
+ * Milter protocol timeouts
+ * Different settings for different Milter applications
+ * Sendmail macro emulation
+ * What macros will Postfix send to Milters?
+
+SSMMTTPP--OOnnllyy MMiilltteerr aapppplliiccaattiioonnss
+
+The SMTP-only Milter applications handle mail that arrives via the Postfix
+smtpd(8) server. They are typically used to filter unwanted mail, and to sign
+mail from authorized SMTP clients. Mail that arrives via the Postfix smtpd(8)
+server is not filtered by the non-SMTP filters that are described in the next
+section.
+
+ NOTE for Postfix versions that have a mail_release_date before 20141018: do
+ not use the header_checks(5) IGNORE action to remove Postfix's own
+ Received: message header. This causes problems with mail signing filters.
+ Instead, keep Postfix's own Received: message header and use the
+ header_checks(5) REPLACE action to sanitize information.
+
+You specify SMTP-only Milter applications (there can be more than one) with the
+smtpd_milters parameter. Each Milter application is identified by the name of
+its listening socket; other Milter configuration options will be discussed in
+later sections. Milter applications are applied in the order as specified, and
+the first Milter application that rejects a command will override the responses
+from other Milter applications.
+
+ /etc/postfix/main.cf:
+ # Milters for mail that arrives via the smtpd(8) server.
+ # See below for socket address syntax.
+ smtpd_milters = inet:localhost:portnumber ...other filters...
+
+The general syntax for listening sockets is as follows:
+
+ uunniixx::pathname
+ Connect to the local UNIX-domain server that is bound to the specified
+ pathname. If the smtpd(8) or cleanup(8) process runs chrooted, an
+ absolute pathname is interpreted relative to the Postfix queue
+ directory.
+
+ iinneett::host::port
+ Connect to the specified TCP port on the specified local or remote
+ host. The host and port can be specified in numeric or symbolic form.
+
+ NOTE: Postfix syntax differs from Milter syntax which has the form
+ iinneett::port@@host.
+
+NNoonn--SSMMTTPP MMiilltteerr aapppplliiccaattiioonnss
+
+The non-SMTP Milter applications handle mail that arrives via the Postfix
+sendmail(1) command-line or via the Postfix qmqpd(8) server. They are typically
+used to digitally sign mail. Although non-SMTP filters can be used to filter
+unwanted mail, there are limitations as discussed later in this section. Mail
+that arrives via the Postfix smtpd(8) server is not filtered by the non-SMTP
+filters.
+
+NOTE: Do not use the header_checks(5) IGNORE action to remove Postfix's own
+Received: message header. This causes problems with mail signing filters.
+Instead, keep Postfix's own Received: message header and use the header_checks
+(5) REPLACE action to sanitize information.
+
+You specify non-SMTP Milter applications with the non_smtpd_milters parameter.
+This parameter uses the same syntax as the smtpd_milters parameter in the
+previous section. As with the SMTP-only filters, you can specify more than one
+Milter application; they are applied in the order as specified, and the first
+Milter application that rejects a command will override the responses from the
+other applications.
+
+ /etc/postfix/main.cf:
+ # Milters for non-SMTP mail.
+ # See below for socket address syntax.
+ non_smtpd_milters = inet:localhost:portnumber ...other filters...
+
+There's one small complication when using Milter applications for non-SMTP
+mail: there is no SMTP session. To keep Milter applications happy, the Postfix
+cleanup(8) server actually has to simulate the SMTP client CONNECT and
+DISCONNECT events, and the SMTP client EHLO, MAIL FROM, RCPT TO and DATA
+commands.
+
+ * When new mail arrives via the sendmail(1) command line, the Postfix cleanup
+ (8) server pretends that the mail arrives with ESMTP from "localhost" with
+ IP address "127.0.0.1". The result is very similar to what happens with
+ command line submissions in Sendmail version 8.12 and later, although
+ Sendmail uses a different mechanism to achieve this result.
+
+ * When new mail arrives via the qmqpd(8) server, the Postfix cleanup(8)
+ server pretends that the mail arrives with ESMTP, and uses the QMQPD client
+ hostname and IP address.
+
+ * When old mail is re-injected into the queue with "postsuper -r", the
+ Postfix cleanup(8) server uses the same client information that was used
+ when the mail arrived as new mail.
+
+This generally works as expected, with only one exception: non-SMTP filters
+must not REJECT or TEMPFAIL simulated RCPT TO commands. When a
+non_smtpd_milters application REJECTs or TEMPFAILs a recipient, Postfix will
+report a configuration error, and mail will stay in the queue.
+
+SSiiggnniinngg iinntteerrnnaallllyy--ggeenneerraatteedd bboouunnccee mmeessssaaggeess
+
+Postfix normally does not apply content filters to mail that is generated
+internally such as bounces or Postmaster notifications. Filtering internally-
+generated bounces would result in loss of mail when a filter rejects a message,
+as the resulting double-bounce message would almost certainly also be blocked.
+
+To sign Postfix's own bounce messages, enable filtering of internally-generated
+bounces (line 2 below), and don't reject any internally-generated bounces with
+non_smtpd_milters, header_checks or body_checks (lines 3-5 below).
+
+ 1 /etc/postfix/main.cf:
+ 2 internal_mail_filter_classes = bounce
+ 3 non_smtpd_milters = don't reject internally-generated bounces
+ 4 header_checks = don't reject internally-generated bounces
+ 5 body_checks = don't reject internally-generated bounces
+
+MMiilltteerr eerrrroorr hhaannddlliinngg
+
+The milter_default_action parameter specifies how Postfix handles Milter
+application errors. The default action is to respond with a temporary error
+status, so that the client will try again later. Specify "accept" if you want
+to receive mail as if the filter does not exist, and "reject" to reject mail
+with a permanent status. The "quarantine" action is like "accept" but freezes
+the message in the "hold" queue, and is available with Postfix 2.6 or later.
+
+ /etc/postfix/main.cf:
+ # What to do in case of errors? Specify accept, reject, tempfail,
+ # or quarantine (Postfix 2.6 or later).
+ milter_default_action = tempfail
+
+See "Different settings for different Milter applications" for advanced
+configuration options.
+
+MMiilltteerr pprroottooccooll vveerrssiioonn
+
+As Postfix is not built with the Sendmail libmilter library, you may need to
+configure the Milter protocol version that Postfix should use. The default
+version is 6 (before Postfix 2.6 the default version is 2).
+
+ /etc/postfix/main.cf:
+ # Postfix >= 2.6
+ milter_protocol = 6
+ # 2.3 <= Postfix <= 2.5
+ milter_protocol = 2
+
+If the Postfix milter_protocol setting specifies a too low version, the
+libmilter library will log an error message like this:
+
+ application name: st_optionneg[xxxxx]: 0xyy does not fulfill action
+ requirements 0xzz
+
+The remedy is to increase the Postfix milter_protocol version number. See,
+however, the limitations section below for features that aren't supported by
+Postfix.
+
+With Postfix 2.7 and earlier, if the Postfix milter_protocol setting specifies
+a too high version, the libmilter library simply hangs up without logging a
+warning, and you see a Postfix warning message like one of the following:
+
+ warning: milter inet:host:port: can't read packet header: Unknown error : 0
+ warning: milter inet:host:port: can't read packet header: Success
+ warning: milter inet:host:port: can't read SMFIC_DATA reply packet header:
+ No such file or directory
+
+The remedy is to lower the Postfix milter_protocol version number. Postfix 2.8
+and later will automatically turn off protocol features that the application's
+libmilter library does not expect.
+
+See "Different settings for different Milter applications" for advanced
+configuration options.
+
+MMiilltteerr pprroottooccooll ttiimmeeoouuttss
+
+Postfix uses different time limits at different Milter protocol stages. The
+table shows the timeout settings and the corresponding protocol stages (EOH =
+end of headers; EOM = end of message).
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |PPoossttffiixx ppaarraammeetteerr |TTiimmee lliimmiitt|MMiilltteerr pprroottooccooll ssttaaggee |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_connect_timeout|30s |CONNECT |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_command_timeout|30s |HELO, MAIL, RCPT, DATA, UNKNOWN|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_content_timeout|300s |HEADER, EOH, BODY, EOM |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+Beware: 30s may be too short for Milter applications that do lots of DNS
+lookups. However, if you increase the above timeouts too much, remote SMTP
+clients may hang up and mail may be delivered multiple times. This is an
+inherent problem with before-queue filtering.
+
+See "Different settings for different Milter applications" for advanced
+configuration options.
+
+DDiiffffeerreenntt sseettttiinnggss ffoorr ddiiffffeerreenntt MMiilltteerr aapppplliiccaattiioonnss
+
+The previous sections list a number of Postfix main.cf parameters that control
+time limits and other settings for all Postfix Milter clients. This is
+sufficient for simple configurations. With more complex configurations it
+becomes desirable to have different settings for different Milter clients. This
+is supported with Postfix 3.0 and later.
+
+The following example shows a "non-critical" Milter client with a short connect
+timeout, and with "accept" as default action when the service is unvailable.
+
+ 1 /etc/postfix/main.cf:
+ 2 smtpd_milters = { inet:host:port,
+ 3 connect_timeout=10s, default_action=accept }
+
+Instead of a server endpoint, we now have a list enclosed in {}.
+
+ * Line 2: The first item in the list is the server endpoint. This supports
+ the exact same "inet" and "unix" syntax as described earlier.
+
+ * Line 3: The remainder of the list contains per-Milter settings. These
+ settings override global main.cf parameters, and have the same name as
+ those parameters, without the "milter_" prefix. The per-Milter settings
+ that are supported as of Postfix 3.0 are command_timeout, connect_timeout,
+ content_timeout, default_action, and protocol.
+
+Inside the list, syntax is similar to what we already know from main.cf: items
+separated by space or comma. There is one difference: yyoouu mmuusstt eenncclloossee aa
+sseettttiinngg iinn ppaarreenntthheesseess,, aass iinn ""{{ nnaammee == vvaalluuee }}"",, iiff yyoouu wwaanntt ttoo hhaavvee ssppaaccee oorr
+ccoommmmaa wwiitthhiinn aa vvaalluuee oorr aarroouunndd ""=="".
+
+SSeennddmmaaiill mmaaccrroo eemmuullaattiioonn
+
+Postfix emulates a limited number of Sendmail macros, as shown in the table.
+Some macro values depend on whether a recipient is rejected (rejected
+recipients are available on request by the Milter application). Different
+macros are available at different Milter protocol stages (EOH = end-of-header,
+EOM = end-of-message); their availability is not always the same as in
+Sendmail. See the workarounds section below for solutions.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |SSeennddmmaaiill mmaaccrroo |MMiilltteerr pprroottooccooll ssttaaggee |DDeessccrriippttiioonn |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |i |DATA, EOH, EOM |Queue ID, also Postfix |
+ | | |queue file name |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |j |Always |Value of myhostname |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |_ |Always |The validated client name |
+ | | |and address |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{auth_authen} |MAIL, DATA, EOH, EOM |SASL login name |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{auth_author} |MAIL, DATA, EOH, EOM |SASL sender |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{auth_type} |MAIL, DATA, EOH, EOM |SASL login method |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{client_addr} |Always |Client IP address |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ | | |Connection concurrency for|
+ | | |this client (zero if the |
+ |{client_connections}|CONNECT |client is excluded from |
+ | | |all smtpd_client_* |
+ | | |limits). |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ | | |Client hostname |
+ | | |When address -> name |
+ |{client_name} |Always |lookup or name -> address |
+ | | |verification fails: |
+ | | |"unknown" |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{client_port} |Always (Postfix >=2.5) |Client TCP port |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ | | |Client name from address -|
+ |{client_ptr} |CONNECT, HELO, MAIL, DATA|> name lookup |
+ | | |When address -> name |
+ | | |lookup fails: "unknown" |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{cert_issuer} |HELO, MAIL, DATA, EOH, |TLS client certificate |
+ | |EOM |issuer |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{cert_subject} |HELO, MAIL, DATA, EOH, |TLS client certificate |
+ | |EOM |subject |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{cipher_bits} |HELO, MAIL, DATA, EOH, |TLS session key size |
+ | |EOM | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{cipher} |HELO, MAIL, DATA, EOH, |TLS cipher |
+ | |EOM | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{daemon_name} |Always |value of |
+ | | |milter_macro_daemon_name |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{mail_addr} |MAIL |Sender address |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{mail_host} |MAIL (Postfix >= 2.6, |Sender next-hop |
+ | |only with smtpd_milters) |destination |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{mail_mailer} |MAIL (Postfix >= 2.6, |Sender mail delivery |
+ | |only with smtpd_milters) |transport |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ | | |Recipient address |
+ |{rcpt_addr} |RCPT |With rejected recipient: |
+ | | |descriptive text |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ | | |Recipient next-hop |
+ |{rcpt_host} |RCPT (Postfix >= 2.6, |destination |
+ | |only with smtpd_milters) |With rejected recipient: |
+ | | |enhanced status code |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ | | |Recipient mail delivery |
+ |{rcpt_mailer} |RCPT (Postfix >= 2.6, |transport |
+ | |only with smtpd_milters) |With rejected recipient: |
+ | | |"error" |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |{tls_version} |HELO, MAIL, DATA, EOH, |TLS protocol version |
+ | |EOM | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |v |Always |value of milter_macro_v |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+WWhhaatt mmaaccrrooss wwiillll PPoossttffiixx sseenndd ttoo MMiilltteerrss??
+
+Postfix sends specific sets of macros at different Milter protocol stages. The
+sets are configured with the parameters as shown in the table below (EOH = end
+of headers; EOM = end of message). The protocol version is a number that
+Postfix sends at the beginning of the Milter protocol handshake.
+
+As of Sendmail 8.14.0, Milter applications can specify what macros they want to
+receive at different Milter protocol stages. An application-specified list
+takes precedence over a Postfix-specified list.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |PPoossttffiixx ppaarraammeetteerr |MMiilltteerr pprroottooccooll|MMiilltteerr pprroottooccooll ssttaaggee|
+ | |vveerrssiioonn | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_connect_macros |2 or higher |CONNECT |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_helo_macros |2 or higher |HELO/EHLO |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_mail_macros |2 or higher |MAIL FROM |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_rcpt_macros |2 or higher |RCPT TO |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_data_macros |4 or higher |DATA |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_end_of_header_macros |6 or higher |EOH |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_end_of_data_macros |2 or higher |EOM |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |milter_unknown_command_macros|3 or higher |unknown command |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+By default, Postfix will send only macros whose values have been updated with
+information from main.cf or master.cf, from an SMTP session (for example; SASL
+login, or TLS certificates) or from a Mail delivery transaction (for example;
+queue ID, sender, or recipient).
+
+To force a macro to be sent even when its value has not been updated, you may
+specify macro default values with the milter_macro_defaults parameter. Specify
+zero or more name=value pairs separated by comma or whitespace; you may even
+specify macro names that Postfix does know about!
+
+WWoorrkkaarroouunnddss
+
+ * To avoid breaking DKIM etc. signatures with an SMTP-based content filter,
+ update the before-filter SMTP client in master.cf, and add a line with "-
+ o disable_mime_output_conversion=yes" (note: no spaces around the "="). For
+ details, see the advanced content filter example.
+
+ /etc/postfix/master.cf:
+ # =============================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =============================================================
+ scan unix - - n - 10 smtp
+ -o smtp_send_xforward_command=yes
+ -o disable_mime_output_conversion=yes
+ -o smtp_generic_maps=
+
+ * Some Milter applications use the "{if_addr}" macro to recognize local mail;
+ this macro does not exist in Postfix. Workaround: use the "{client_addr}"
+ macro instead.
+
+ * Some Milter applications log a warning that looks like this:
+
+ sid-filter[36540]: WARNING: sendmail symbol 'i' not available
+
+ And they may insert an ugly message header with "unknown-msgid" like this:
+
+ X-SenderID: Sendmail Sender-ID Filter vx.y.z host.example.com
+
+ The problem is that Milter applications expect that the queue ID is known
+ before the MTA accepts the MAIL FROM (sender) command. Postfix does not
+ choose a queue ID, which is used as the queue file name, until after it
+ accepts the first valid RCPT TO (recipient) command.
+
+ If you experience the ugly header problem, see if a recent version of the
+ Milter application fixes it. For example, current versions of dkim-filter
+ and dk-filter already have code that looks up the Postfix queue ID at a
+ later protocol stage, and sid-filter version 1.0.0 no longer includes the
+ queue ID in the message header.
+
+ To fix the ugly message header, you will need to add code that looks up the
+ Postfix queue ID at some later point in time. The example below adds the
+ lookup after the end-of-message.
+
+ o Edit the filter source file (typically named xxx-filter/xxx-filter.c or
+ similar).
+
+ o Look up the mlfi_eom() function and add code near the top shown as bboolldd
+ text below:
+
+ dfc = cc->cctx_msg;
+ assert(dfc != NULL);
+
+ //** DDeetteerrmmiinnee tthhee jjoobb IIDD ffoorr llooggggiinngg.. **//
+ iiff ((ddffcc-->>mmccttxx__jjoobbiidd ==== 00 |||| ssttrrccmmpp((ddffcc-->>mmccttxx__jjoobbiidd,, JJOOBBIIDDUUNNKKNNOOWWNN)) ==== 00))
+ {{
+ cchhaarr **jjoobbiidd == ssmmffii__ggeettssyymmvvaall((ccttxx,, ""ii""));;
+ iiff ((jjoobbiidd !!== 00))
+ ddffcc-->>mmccttxx__jjoobbiidd == jjoobbiidd;;
+ }}
+
+ NOTES:
+
+ o Different mail filters use slightly different names for variables. If
+ the above code does not compile, look elsewhere in the mail filter
+ source file for code that looks up the "i" macro value, and copy that
+ code.
+
+ o This change fixes only the ugly message header, but not the WARNING
+ message. Fortunately, many Milters log that message only once.
+
+LLiimmiittaattiioonnss
+
+This section lists limitations of the Postfix Milter implementation. Some
+limitations will be removed as the implementation is extended over time. Of
+course the usual limitations of before-queue filtering will always apply. See
+the CONTENT_INSPECTION_README document for a discussion.
+
+ * The Milter protocol has evolved over time. Therefore, different Postfix
+ versions implement different feature sets.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |PPoossttffiixx|SSuuppppoorrtteedd MMiilltteerr rreeqquueessttss |
+ |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ | 2.6 |All Milter requests of Sendmail 8.14.0 (see notes below). |
+ |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ | |All Milter requests of Sendmail 8.14.0, except: |
+ | |SMFIP_RCPT_REJ (report rejected recipients to the mail filter), |
+ | 2.5 |SMFIR_CHGFROM (replace sender, with optional ESMTP parameters), |
+ | |SMFIR_ADDRCPT_PAR (add recipient, with optional ESMTP |
+ | |parameters). |
+ |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ | 2.4 |All Milter requests of Sendmail 8.13.0. |
+ |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ | 2.3 |All Milter requests of Sendmail 8.13.0, except: |
+ | |SMFIR_REPLBODY (replace message body). |
+ |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+ * For Milter applications that are written in C, you need to use the Sendmail
+ libmilter library.
+
+ * Postfix has TWO sets of mail filters: filters that are used for SMTP mail
+ only (specified with the smtpd_milters parameter), and filters for non-SMTP
+ mail (specified with the non_smtpd_milters parameter). The non-SMTP filters
+ are primarily for local submissions.
+
+ When mail is filtered by non_smtpd_milters, the Postfix cleanup(8) server
+ has to simulate SMTP client requests. This works as expected, with only one
+ exception: non_smtpd_milters must not REJECT or TEMPFAIL simulated RCPT TO
+ commands. When this rule is violated, Postfix will report a configuration
+ error, and mail will stay in the queue.
+
+ * When you use the before-queue content filter for incoming SMTP mail (see
+ SMTPD_PROXY_README), Milter applications have access only to the SMTP
+ command information; they have no access to the message header or body, and
+ cannot make modifications to the message or to the envelope.
+
+ * Postfix 2.6 ignores the optional ESMTP parameters in requests to replace
+ the sender (SMFIR_CHGFROM) or to append a recipient (SMFIR_ADDRCPT_PAR).
+ Postfix logs a warning message when a Milter application supplies such
+ ESMTP parameters:
+
+ warning: queue-id: cleanup_chg_from: ignoring ESMTP arguments "whatever"
+ warning: queue-id: cleanup_add_rcpt: ignoring ESMTP arguments "whatever"
+
+ * Postfix 2.3 does not implement requests to replace the message body. Milter
+ applications log a warning message when they need this unsupported
+ operation:
+
+ st_optionneg[134563840]: 0x3d does not fulfill action requirements 0x1e
+
+ The solution is to use Postfix version 2.4 or later.
+
+ * Most Milter configuration options are global. Future Postfix versions may
+ support per-Milter timeouts, per-Milter error handling, etc.
+
diff --git a/README_FILES/MULTI_INSTANCE_README b/README_FILES/MULTI_INSTANCE_README
new file mode 100644
index 0000000..7e930f2
--- /dev/null
+++ b/README_FILES/MULTI_INSTANCE_README
@@ -0,0 +1,981 @@
+MMaannaaggiinngg mmuullttiippllee PPoossttffiixx iinnssttaanncceess oonn aa ssiinnggllee hhoosstt
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document is a guide to managing multiple Postfix instances on a single
+host using the postmulti(1) instance manager. Multi-instance support is
+available with Postfix version 2.6 and later. See the postfix-wrapper(5) manual
+page for background on the instance management framework, and on how to deploy
+a custom instance manager.
+
+Topics covered in this document:
+
+ * Why multiple Postfix instances
+ * Null-client instances versus service instances
+ * Multi-instance walk-through
+ * Components of a Postfix system
+ * The default Postfix instance
+ * Instance groups
+ * Multi-instance configuration parameters
+ * Using the postmulti(1) command
+ * Credits
+
+WWhhyy mmuullttiippllee PPoossttffiixx iinnssttaanncceess
+
+Postfix is a general-purpose mail system that can be configured to serve a
+variety of needs. Examples of Postfix applications are:
+
+ * Local mail submission for shell users and system processes.
+
+ * Incoming (MX host) email from the Internet.
+
+ * Outbound mail relay for a corporate network.
+
+ * Authenticated submission for roaming users.
+
+ * Before/after content-filter mail.
+
+A single Postfix configuration can provide many or all of these services, but a
+complex interplay of settings may be required, for example with master.cf
+options overriding main.cf settings. In this document we take the view that
+multiple Postfix instances may be a simpler way to configure a multi-function
+Postfix system. With multiple Postfix instances, each instance has its own
+directories for configuration, queue and data files, but it shares all Postfix
+program and documentation files with other instances.
+
+Since there is no single right way to configure your system, we recommend that
+you choose what makes you most comfortable. If different Postfix services don't
+involve incompatible main.cf or master.cf settings, and if they can be combined
+together without complex tricks, then a single monolithic configuration may be
+the simplest approach.
+
+The purpose of multi-instance support in Postfix is not to force you to create
+multiple Postfix instances, but rather to give you a choice. Multiple instances
+give you the freedom to tune each Postfix instance to a single task that it
+does well and to combine instances into complete systems.
+
+With the introduction of the postmulti(1) utility and the reduction of the per-
+instance configuration footprint of a secondary Postfix instance to just a
+main.cf and master.cf file (other files are now in shared locations), we hope
+that multiple instances will be easier to use than ever before.
+
+NNuullll--cclliieenntt iinnssttaanncceess vveerrssuuss sseerrvviiccee iinnssttaanncceess
+
+In the multi-instance approach to configuring Postfix, the first simplification
+is with the default local-submission Postfix instance.
+
+Most UNIX systems require support for email submission with the sendmail(1)
+command so that system processes such as cron jobs can send status reports, and
+so that system users can send email with command-line utilities. Such email can
+be handled with a null-client Postfix configuration that forwards all mail to a
+central mail hub. The null client will typically either not run an SMTP
+listener at all (master_service_disable = inet), or it will listen only on the
+loopback interface (inet_interfaces = loopback-only).
+
+When implementing specialized servers for inbound Internet email, outbound
+MTAs, internal mail hubs, and so on, we recommend using a null client for local
+submission and creating single-function secondary Postfix instances to serve
+the specialized needs.
+
+ Note: usually, you need to use different "myhostname" settings when you run
+ multiple instances on the same host. Otherwise, there will be false "mail
+ loops back to myself" alarms when one instance tries to send mail into
+ another instance. Typically, the null-client instance will use the system's
+ hostname, and other instances will use their own dedicated "myhostname"
+ settings. Different names are not needed when instances send mail to each
+ other with a protocol other than SMTP, or with SMTP over a TCP port other
+ than 25 as is usual with SMTP-based content filters.
+
+MMuullttii--iinnssttaannccee wwaallkk--tthhrroouugghh
+
+Before discussing the fine details of multi-instance operation we first show
+the steps for creating a border mail server. This server has with a null-client
+Postfix instance for local submission, an input Postfix instance to receive
+mail from the Internet, plus an advanced SMTP content-filter and an output
+Postfix instance to deliver filtered email to its internal destination.
+
+SSeettttiinngg uupp tthhee nnuullll--cclliieenntt PPoossttffiixx iinnssttaannccee
+
+On a border mail hub, while mail from the Internet requires a great deal of
+scrutiny, locally submitted messages are typically limited to mail from cron
+jobs and other system services. In this regard the border MTA is not different
+from other Unix hosts in your environment. For this reason, it will submit
+locally-generated email to the internal mail hub. We start the construction of
+the border mail server with the default instance, which will be a local-
+submission null client:
+
+ /etc/postfix/main.cf:
+ # We are mta1.example.com
+ #
+ myhostname = mta1.example.com
+ mydomain = example.com
+
+ # Flat user-account namespace in example.com:
+ #
+ # user@example.com not user@host.example.com
+ #
+ myorigin = $mydomain
+
+ # Postfix 2.6+, disable inet services, specifically disable smtpd(8)
+ #
+ master_service_disable = inet
+
+ # No local delivery:
+ #
+ mydestination =
+ local_transport = error:5.1.1 Mailbox unavailable
+ alias_database =
+ alias_maps =
+ local_recipient_maps =
+
+ # Send everything to the internal mailhub
+ #
+ relayhost = [mailhub.example.com]
+
+ # Indexed table macro:
+ # (use "hash", ... when cdb is not available)
+ #
+ default_database_type = cdb
+ indexed = ${default_database_type}:${config_directory}/
+
+ # Expose origin host of mail from "root", ...
+ #
+ smtp_generic_maps = ${indexed}generic
+
+ # Send messages addressed to "root", ... to the MTA support team
+ #
+ virtual_alias_maps = ${indexed}virtual
+
+ /etc/postfix/generic:
+ # The smarthost supports "+" addressing (recipient_delimiter = +).
+ # Mail from "root" exposes the origin host, without replies
+ # and bounces going back to the same host.
+ #
+ # On clustered MTAs this file is typically machine-built from
+ # a template file. The build process expands the template into
+ # "mtaadmin+root=mta1"
+ #
+ root mtaadmin+root=mta1
+
+ /etc/postfix/virtual:
+ # Caretaker aliases:
+ #
+ root mtaadmin
+ postmaster root
+
+You would typically also add a Makefile, to automatically run postmap(1)
+commands when source files change. This Makefile also creates a "generic"
+database when none exists.
+
+ /etc/postfix/Makefile:
+ MTAADMIN=mtaadmin
+
+ all: virtual.cdb generic.cdb
+
+ generic: Makefile
+ @echo Creating $@
+ @rm -f $@.tmp
+ @printf '%s\t%s+root=%s\n' root ${MTAADMIN} `uname -n` > $@.tmp
+ @mv $@.tmp generic
+
+ %.cdb: %
+ postmap cdb:$<
+
+Construct the "virtual" and "generic" databases (the latter is created by
+running "make"), then start and test the null-client:
+
+ # cd /etc/postfix; make
+ # postfix start
+ # sendmail -i -f root -t < smtpd(8)
+
+ ^ |
+ \ | v
+
+ Network -> qmqpd(8) -> cleanup(8) -> incoming
+
+ /
+
+ pickup(8) <- maildrop
+
+ ^
+ |
+
+ Local -> sendmail(1) -> postdrop(1)
+
+ * Network mail enters Postfix via the smtpd(8) or qmqpd(8) servers. These
+ servers remove the SMTP or QMQP protocol encapsulation, enforce some sanity
+ checks to protect Postfix, and give the sender, recipients and message
+ content to the cleanup(8) server. The smtpd(8) server can be configured to
+ block unwanted mail, as described in the SMTPD_ACCESS_README document.
+
+ * Local submissions are received with the Postfix sendmail(1) compatibility
+ command, and are queued in the maildrop queue by the privileged postdrop(1)
+ command. This arrangement even works while the Postfix mail system is not
+ running. The local pickup(8) server picks up local submissions, enforces
+ some sanity checks to protect Postfix, and gives the sender, recipients and
+ message content to the cleanup(8) server.
+
+ * Mail from internal sources is given directly to the cleanup(8) server.
+ These sources are not shown in the figure, and include: mail that is
+ forwarded by the local(8) delivery agent (see next section), messages that
+ are returned to the sender by the bounce(8) server (see second-next
+ section), and postmaster notifications about problems with Postfix.
+
+ * The cleanup(8) server implements the final processing stage before mail is
+ queued. It adds missing From: and other message headers, and transforms
+ addresses as described in the ADDRESS_REWRITING_README document.
+ Optionally, the cleanup(8) server can be configured to do light-weight
+ content inspection with regular expressions as described in the
+ BUILTIN_FILTER_README document. The cleanup(8) server places the result as
+ a single file into the incoming queue, and notifies the queue manager (see
+ next section) of the arrival of new mail.
+
+ * The trivial-rewrite(8) server rewrites addresses to the standard
+ "user@fully.qualified.domain" form, as described in the
+ ADDRESS_REWRITING_README document. Postfix currently does not implement a
+ rewriting language, but a lot can be done via table lookups and, if need
+ be, regular expressions.
+
+HHooww PPoossttffiixx ddeelliivveerrss mmaaiill
+
+Once a message has reached the incoming queue the next step is to deliver it.
+The figure shows the main components of the Postfix mail delivery apparatus.
+Names followed by a number are Postfix commands or server programs, while
+unnumbered names inside shaded areas represent Postfix queues.
+
+ trivial- smtp(8) -> Network
+ rewrite(8)
+ /
+
+ - lmtp(8) -> Network
+ ^ |
+ | v /
+
+ incoming -> active -> qmgr(8) --- local(8) -> File, command
+
+ \
+ ^ |
+ | v - virtual(8) -> File
+
+ deferred \
+
+ pipe(8) -> Command
+
+ * The queue manager (the qmgr(8) server process in the figure) is the heart
+ of Postfix mail delivery. It contacts the smtp(8), lmtp(8), local(8),
+ virtual(8), pipe(8), discard(8) or error(8) delivery agents, and sends a
+ delivery request for one or more recipient addresses. The discard(8) and
+ error(8) delivery agents are special: they discard or bounce all mail, and
+ are not shown in the figure above.
+
+ The queue manager maintains a small active queue with the messages that it
+ has opened for delivery. The active queue acts as a limited window on
+ potentially large incoming or deferred queues. The limited active queue
+ prevents the queue manager from running out of memory under heavy load.
+
+ The queue manager maintains a separate deferred queue for mail that cannot
+ be delivered, so that a large mail backlog will not slow down normal queue
+ accesses. The queue manager's strategy for delayed mail delivery attempts
+ is described in the QSHAPE_README and TUNING_README documents.
+
+ * The trivial-rewrite(8) server resolves each recipient address according to
+ its local or remote address class, as defined in the ADDRESS_CLASS_README
+ document. Additional routing information can be specified with the optional
+ transport(5) table. The trivial-rewrite(8) server optionally queries the
+ relocated(5) table for recipients whose address has changed; mail for such
+ recipients is returned to the sender with an explanation.
+
+ * The smtp(8) client looks up a list of mail exchangers for the destination
+ host, sorts the list by preference, and tries each server in turn until it
+ finds a server that responds. It then encapsulates the sender, recipient
+ and message content as required by the SMTP protocol; this includes
+ conversion of 8-bit MIME to 7-bit encoding.
+
+ * The lmtp(8) client speaks a protocol similar to SMTP that is optimized for
+ delivery to mailbox servers such as Cyrus. The advantage of this setup is
+ that one Postfix machine can feed multiple mailbox servers over LMTP. The
+ opposite is true as well: one mailbox server can be fed over LMTP by
+ multiple Postfix machines.
+
+ * The local(8) delivery agent understands UNIX-style mailboxes, qmail-
+ compatible maildir files, Sendmail-style system-wide aliases(5) databases,
+ and Sendmail-style per-user .forward files. Multiple local delivery agents
+ can be run in parallel, but parallel delivery to the same user is usually
+ limited.
+
+ The local(8) delivery agent has hooks for alternative forms of local
+ delivery: you can configure it to deliver to mailbox files in user home
+ directories, you can configure it to delegate mailbox delivery to an
+ external command such as procmail, or you can delegate delivery to a
+ different Postfix delivery agent.
+
+ * The virtual(8) delivery agent is a bare-bones delivery agent that delivers
+ to UNIX-style mailbox or qmail-style maildir files only. This delivery
+ agent can deliver mail for multiple domains, which makes it especially
+ suitable for hosting lots of small domains on a single machine. This is
+ described in the VIRTUAL_README document.
+
+ * The pipe(8) mailer is the outbound interface to other mail processing
+ systems (the Postfix sendmail(1) command being the inbound interface). The
+ interface is UNIX compatible: it provides information on the command line
+ and on the standard input stream, and expects a process exit status code as
+ defined in . Examples of delivery via the pipe(8) mailer are in
+ the MAILDROP_README and UUCP_README documents.
+
+PPoossttffiixx bbeehhiinndd tthhee sscceenneess
+
+The previous sections gave an overview of how Postfix server processes send and
+receive mail. These server processes rely on other server processes that do
+things behind the scenes. The text below attempts to visualize each service in
+its own context. As before, names followed by a number are Postfix commands or
+server programs, while unnumbered names inside shaded areas represent Postfix
+queues.
+
+ * The resident master(8) server is the supervisor that keeps an eye on the
+ well-being of the Postfix mail system. It is typically started at system
+ boot time with the "postfix start" command, and keeps running until the
+ system goes down. The master(8) server is responsible for starting Postfix
+ server processes to receive and deliver mail, and for restarting servers
+ that terminate prematurely because of some problem. The master(8) server is
+ also responsible for enforcing the server process count limits as specified
+ in the mmaasstteerr..ccff configuration file. The picture below gives the program
+ hierarchy when Postfix is started up. Only some of the mail handling daemon
+ processes are shown.
+
+ postfix(1)
+
+ |
+ |
+
+ postfix-script(1)
+
+ / | \
+ |
+ / \
+
+ postsuper(1) master(8) postlog(1)
+
+ / | \
+ |
+ / \
+
+ smtpd(8) qmgr(8) local(8)
+
+ * The anvil(8) server implements client connection and request rate limiting
+ for all smtpd(8) servers. The TUNING_README document provides guidance for
+ dealing with mis-behaving SMTP clients. The anvil(8) service is available
+ in Postfix version 2.2 and later.
+
+ Network -> smtpd(8) <-> anvil(8)
+
+ * The bounce(8), defer(8) and trace(8) services each maintain their own queue
+ directory trees with per-message logfiles. Postfix uses this information
+ when sending "failed", "delayed" or "success" delivery status notifications
+ to the sender.
+
+ The trace(8) service also implements support for the Postfix "sendmail -bv"
+ and "sendmail -v" commands which produce reports about how Postfix delivers
+ mail, and is available with Postfix version 2.1 and later. See DEBUG_README
+ for examples.
+
+ qmgr(8) Delivery
+ cleanup(8) -> Postfix -> agents
+ queue
+
+ ^ | |
+ | v v
+
+ (Non-) bounce(8) Queue id,
+ delivery <- defer(8) <- recipient,
+ notice trace(8) status
+
+ ^ |
+ | v
+
+ Per-
+ message
+ logfiles
+
+ * The flush(8) servers maintain per-destination logs and implement both ETRN
+ and "sendmail -qRdestination", as described in the ETRN_README document.
+ This moves selected queue files from the deferred queue back to the
+ incoming queue and requests their delivery. The flush(8) service is
+ available with Postfix version 1.0 and later.
+
+ incoming
+ ^
+ deferred
+
+ ^
+ |
+
+ smtpd(8) Destination Deferred Delivery
+ sendmail(1) - to flush -> flush(8) <- destination, - agents,
+ postqueue(1) queue id qmgr(8)
+
+ ^ |
+ | v
+
+ Per-dest-
+ ination
+ logs
+
+ * The proxymap(8) servers provide read-only and read-write table lookup
+ service to Postfix processes. This overcomes chroot restrictions, reduces
+ the number of open lookup tables by sharing one open table among multiple
+ processes, and implements single-updater tables.
+
+ * The scache(8) server maintains the connection cache for the Postfix smtp(8)
+ client. When connection caching is enabled for selected destinations, the
+ smtp(8) client does not disconnect immediately after a mail transaction,
+ but gives the connection to the connection cache server which keeps the
+ connection open for a limited amount of time. The smtp(8) client continues
+ with some other mail delivery request. Meanwhile, any smtp(8) process can
+ ask the scache(8) server for that cached connection and reuse it for mail
+ delivery. As a safety measure, Postfix limits the number of times that a
+ connection may be reused.
+
+ When delivering mail to a destination with multiple mail servers,
+ connection caching can help to skip over a non-responding server, and thus
+ dramatically speed up delivery. SMTP connection caching is available in
+ Postfix version 2.2 and later. More information about this feature is in
+ the CONNECTION_CACHE_README document.
+
+ /-- smtp(8) --> Internet
+
+ qmgr(8) |
+ |
+ \-- | smtp(8) --> Internet
+ |
+ ^
+ |
+
+ scache(8)
+
+ * The showq(8) servers list the Postfix queue status. This is the queue
+ listing service that does the work for the mailq(1) and postqueue(1)
+ commands.
+
+ mailq(1) Postfix
+ Output <- post- <- showq(8) <- queue
+ queue(1)
+
+ * The spawn(8) servers run non-Postfix commands on request, with the client
+ connected via socket or FIFO to the command's standard input, output and
+ error streams. You can find examples of its use in the SMTPD_POLICY_README
+ document.
+
+ * The tlsmgr(8) server runs when TLS (Transport Layer Security, formerly
+ known as SSL) is turned on in the Postfix smtp(8) client or smtpd(8)
+ server. This process has two duties:
+
+ o Maintain the pseudo-random number generator (PRNG) that is used to seed
+ the TLS engines in Postfix smtp(8) client or smtpd(8) server processes.
+ The state of this PRNG is periodically saved to a file, and is read
+ when tlsmgr(8) starts up.
+
+ o Maintain the optional Postfix smtp(8) client or smtpd(8) server caches
+ with TLS session keys. Saved keys can improve performance by reducing
+ the amount of computation at the start of a TLS session.
+
+ TLS support is available in Postfix version 2.2 and later. Information
+ about the Postfix TLS implementation is in the TLS_README document.
+
+ <---seed--- ---seed--->
+ Network-> smtpd(8) tlsmgr(8) smtp(8) ->Network
+ <-session-> <-session->
+
+ / | \
+ |
+ / \
+
+ smtpd PRNG smtp
+ session state session
+ cache file cache
+
+ * The verify(8) server verifies that a sender or recipient address is
+ deliverable before the smtpd(8) server accepts it. The verify(8) server
+ queries a cache with address verification results. If a result is not
+ found, the verify(8) server injects a probe message into the Postfix queue
+ and processes the status update from a delivery agent or queue manager.
+ This process is described in the ADDRESS_VERIFICATION_README document. The
+ verify(8) service is available with Postfix version 2.1 and later.
+
+
+ probe Postfix
+ message -> mail
+ queue
+ Network -> smtpd(8) <-> verify(8) ->
+
+ |
+ v
+
+ <- probe Postfix -> Local
+ status <- delivery -> Network
+ ^ agents
+ |
+ v
+
+
+ Address
+ verification
+ cache
+
+ * The postscreen(8) server can be put "in front" of Postfix smtpd(8)
+ processes. Its purpose is to accept connections from the network and to
+ decide what SMTP clients are allowed to talk to Postfix. According to the
+ 2008 MessageLabs annual report, 81% of all email was spam, and 90% of that
+ was sent by botnets; by 2010, those numbers were 92% and 95%, respectively.
+ While postscreen(8) keeps the zombies away, more smtpd(8) processes remain
+ available for legitimate clients.
+
+ postscreen(8) maintains a temporary whitelist for clients that pass its
+ tests; by allowing whitelisted clients to skip tests, postscreen(8)
+ minimizes its impact on legitimate email traffic.
+
+ The postscreen(8) server is available with Postfix 2.8 and later. To keep
+ the implementation simple, postscreen(8) delegates DNS white/blacklist
+ lookups to dnsblog(8) server processes, and delegates TLS encryption/
+ decryption to tlsproxy(8) server processes. This delegation is invisible to
+ the remote SMTP client, and is not shown in the diagram below.
+
+ zombie
+
+ \
+
+ zombie - - smtpd(8)
+
+ \ /
+
+ other --- postscreen(8)
+
+ / \
+
+ other - - smtpd(8)
+
+ /
+
+ zombie
+
+PPoossttffiixx ssuuppppoorrtt ccoommmmaannddss
+
+The Postfix architecture overview ends with a summary of command-line utilities
+for day-to-day use of the Postfix mail system. Besides the Sendmail-compatible
+sendmail(1), mailq(1), and newaliases(1) commands, the Postfix system comes
+with it own collection of command-line utilities. For consistency, these are
+all named postsomething.
+
+ * The postfix(1) command controls the operation of the mail system. It is the
+ interface for starting, stopping, and restarting the mail system, as well
+ as for some other administrative operations. This command is reserved to
+ the super-user.
+
+ * The postalias(1) command maintains Postfix aliases(5) type databases. This
+ is the program that does the work for the newaliases(1) command.
+
+ * The postcat(1) command displays the contents of Postfix queue files. This
+ is a limited, preliminary utility. This program is likely to be superseded
+ by something more powerful that can also edit Postfix queue files.
+
+ * The postconf(1) command displays or updates Postfix main.cf parameters and
+ displays system dependent information about the supported file locking
+ methods, and the supported types of lookup tables.
+
+ * The postdrop(1) command is the mail posting utility that is run by the
+ Postfix sendmail(1) command in order to deposit mail into the maildrop
+ queue directory.
+
+ * The postkick(1) command makes some Postfix internal communication channels
+ available for use in, for example, shell scripts.
+
+ * The postlock(1) command provides Postfix-compatible mailbox locking for use
+ in, for example, shell scripts.
+
+ * The postlog(1) command provides Postfix-compatible logging for shell
+ scripts.
+
+ * The postmap(1) command maintains Postfix lookup tables such as canonical
+ (5), virtual(5) and others. It is a cousin of the UNIX makemap command.
+
+ * The postmulti(1) command repeats the "postfix start" etc. command for each
+ Postfix instance, and supports creation, deletion etc. of Postfix
+ instances. For a tutorial, see MULTI_INSTANCE_README.
+
+ * The postqueue(1) command is the privileged command that is run by Postfix
+ sendmail(1) and mailq(1) in order to flush or list the mail queue.
+
+ * The postsuper(1) command maintains the Postfix queue. It removes old
+ temporary files, and moves queue files into the right directory after a
+ change in the hashing depth of queue directories. This command is run at
+ mail system startup time and when Postfix is restarted.
+
diff --git a/README_FILES/PACKAGE_README b/README_FILES/PACKAGE_README
new file mode 100644
index 0000000..c64604b
--- /dev/null
+++ b/README_FILES/PACKAGE_README
@@ -0,0 +1,109 @@
+GGuuiiddeelliinneess ffoorr PPaacckkaaggee BBuuiillddeerrss
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document has hints and tips for those who manage their own Postfix binary
+distribution for internal use, and for those who maintain Postfix binary
+distributions for general use.
+
+GGeenneerraall ddiissttrriibbuuttiioonnss:: pplleeaassee pprroovviiddee aa ssmmaallll ddeeffaauulltt mmaaiinn..ccff ffiillee
+
+The installed main.cf file must be small. PLEASE resist the temptation to list
+all parameters in the main.cf file. Postfix is supposed to be easy to
+configure. Listing all parameters in main.cf defeats the purpose. It is an
+invitation for hobbyists to make random changes without understanding what they
+do, and gets them into endless trouble.
+
+GGeenneerraall ddiissttrriibbuuttiioonnss:: pplleeaassee iinncclluuddee RREEAADDMMEE oorr HHTTMMLL ffiilleess
+
+Please provide the applicable README or HTML files. They are referenced by the
+Postfix manual pages and by other files. Without README or HTML files, Postfix
+will be difficult if not impossible to configure.
+
+PPoossttffiixx IInnssttaallllaattiioonn ppaarraammeetteerrss
+
+Postfix installation is controlled by a dozen installation parameters. See the
+postfix-install and post-install files for details. Most parameters have
+system-dependent default settings that are configurable at compile time, as
+described in the INSTALL file.
+
+PPrreeppaarriinngg aa pprree--bbuuiilltt ppaacckkaaggee ffoorr ddiissttrriibbuuttiioonn ttoo ootthheerr ssyysstteemmss
+
+You can build a Postfix package on a machine that does not have Postfix
+installed on it. All you need is Postfix source code and a compilation
+environment that is compatible with the target system.
+
+You can build a pre-built Postfix package as an unprivileged user.
+
+First compile Postfix. After successful compilation, execute:
+
+ % mmaakkee ppaacckkaaggee
+
+With Postfix versions before 2.2 you must invoke the post-install script
+directly (% sshh ppoosstt--iinnssttaallll).
+
+You will be prompted for installation parameters. Specify an install_root
+directory other than /. The mail_owner and setgid_group installation parameter
+settings will be recorded in the main.cf file, but they won't take effect until
+the package is unpacked and installed on the destination machine.
+
+If you want to fully automate this process, specify all the non-default
+installation parameters on the command line:
+
+ % mmaakkee nnoonn--iinntteerraaccttiivvee--ppaacckkaaggee iinnssttaallll__rroooott==//ssoommee//wwhheerree...
+
+With Postfix versions before 2.2 you must invoke the post-install script
+directly (% sshh ppoosstt--iinnssttaallll --nnoonn--iinntteerraaccttiivvee iinnssttaallll__rroooott......).
+
+With Postfix 3.0 and later, the command "make package name=value ..." will
+replace the string MAIL_VERSION in a configuration parameter value with the
+Postfix release version. Do not try to specify something like $mail_version on
+this command line. This produces inconsistent results with different versions
+of the make(1) command.
+
+BBeeggiinn SSeeccuurriittyy AAlleerrtt
+
+WWhheenn bbuuiillddiinngg aann aarrcchhiivvee ffoorr ddiissttrriibbuuttiioonn,, bbee ssuurree ttoo aarrcchhiivvee oonnllyy ffiilleess aanndd
+ssyymmbboolliicc lliinnkkss,, nnoott tthheeiirr ppaarreenntt ddiirreeccttoorriieess.. OOtthheerrwwiissee,, uunnppaacckkiinngg aa pprree--bbuuiilltt
+PPoossttffiixx ppaacckkaaggee mmaayy mmeessss uupp ppeerrmmiissssiioonn aanndd//oorr oowwnneerrsshhiipp ooff ssyysstteemm ddiirreeccttoorriieess
+ssuucchh aass // //eettcc //uussrr //uussrr//bbiinn //vvaarr //vvaarr//ssppooooll aanndd ssoo oonn.. TThhiiss iiss eessppeecciiaallllyy aann
+iissssuuee iiff yyoouu eexxeeccuutteedd ppoossttffiixx--iinnssttaallll ((sseeee aabboovvee)) aass aann uunnpprriivviilleeggeedd uusseerr..
+
+EEnndd SSeeccuurriittyy AAlleerrtt
+
+Thus, to tar up the pre-built package, take the following steps:
+
+ % cd INSTALL_ROOT
+ % rm -f SOMEWHERE/outputfile
+ % find . \! -type d -print | xargs tar rf SOMEWHERE/outputfile
+ % gzip SOMEWHERE/outputfile
+
+This way you will not include any directories that might cause trouble upon
+extraction.
+
+IInnssttaalllliinngg aa pprree--bbuuiilltt PPoossttffiixx ppaacckkaaggee
+
+ * To unpack a pre-built Postfix package, execute the equivalent of:
+
+ # umask 022
+ # gzip -d . Lines ending in a "bare" , that is newline not
+preceded by carriage return, are not allowed in SMTP. postscreen(8)'s deep
+protocol test for this is disabled by default.
+
+With "postscreen_bare_newline_enable = yes", postscreen(8) detects clients that
+send lines ending in bare newline characters.
+
+This test is opportunistically enabled when postscreen(8) has to use the built-
+in SMTP engine anyway. This is to make postscreen(8) logging more informative.
+
+When a client sends bare newline characters, postscreen(8) logs this as:
+
+ BBAARREE NNEEWWLLIINNEE ffrroomm [address]:port aafftteerr command
+
+Translation: the SMTP client at [address]:port sent a bare newline character,
+that is newline not preceded by carriage return. The "aafftteerr command" portion is
+logged with Postfix 2.10 and later.
+
+The postscreen_bare_newline_action parameter specifies the action that is taken
+next. See "When tests fail after the 220 SMTP server greeting" below.
+
+WWhheenn tteessttss ffaaiill aafftteerr tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
+
+When the client fails the pipelining, non-SMTP command or bare newline tests,
+the action is specified with postscreen_pipelining_action,
+postscreen_non_smtp_command_action or postscreen_bare_newline_action,
+respectively.
+
+iiggnnoorree (default for bare newline)
+ Ignore the failure of this test. Allow other tests to complete. Do NOT
+ repeat this test before the result from some other test expires. This
+ option is useful for testing and collecting statistics without blocking
+ mail permanently.
+eennffoorrccee (default for pipelining)
+ Allow other tests to complete. Reject attempts to deliver mail with a 550
+ SMTP reply, and log the helo/sender/recipient information. Repeat this test
+ the next time the client connects.
+ddrroopp (default for non-SMTP commands)
+ Drop the connection immediately with a 521 SMTP reply. Repeat this test the
+ next time the client connects. This action is compatible with the Postfix
+ SMTP server's smtpd_forbidden_commands feature.
+
+OOtthheerr eerrrroorrss
+
+When an SMTP client hangs up unexpectedly, postscreen(8) logs this as:
+
+ HHAANNGGUUPP aafftteerr time ffrroomm [address]:port iinn test name
+
+Translation: the SMTP client at [address]:port disconnected unexpectedly, time
+seconds after the start of the test named test name.
+
+There is no punishment for hanging up. A client that hangs up without sending
+the QUIT command can still pass all postscreen(8) tests.
+
+The following errors are reported by the built-in SMTP engine. This engine
+never accepts mail, therefore it has per-session limits on the number of
+commands and on the session length.
+
+ CCOOMMMMAANNDD TTIIMMEE LLIIMMIITT ffrroomm [address]:port aafftteerr command
+
+Translation: the SMTP client at [address]:port reached the per-command time
+limit as specified with the postscreen_command_time_limit parameter. The
+session is terminated immediately. The "aafftteerr command" portion is logged with
+Postfix 2.10 and later.
+
+ CCOOMMMMAANNDD CCOOUUNNTT LLIIMMIITT ffrroomm [address]:port aafftteerr command
+
+Translation: the SMTP client at [address]:port reached the per-session command
+count limit as specified with the postscreen_command_count_limit parameter. The
+session is terminated immediately. The "aafftteerr command" portion is logged with
+Postfix 2.10 and later.
+
+ CCOOMMMMAANNDD LLEENNGGTTHH LLIIMMIITT ffrroomm [address]:port aafftteerr command
+
+Translation: the SMTP client at [address]:port reached the per-command length
+limit, as specified with the line_length_limit parameter. The session is
+terminated immediately. The "aafftteerr command" portion is logged with Postfix 2.10
+and later.
+
+When an SMTP client makes too many connections at the same time, or when all
+postscreen(8) ports are busy, postscreen(8) rejects the connection with a 421
+status code and logs:
+
+ NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: ttoooo mmaannyy ccoonnnneeccttiioonnss
+ NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: aallll sseerrvveerr ppoorrttss bbuussyy
+
+The postscreen_client_connection_count_limit and postscreen_pre_queue_limit
+parameters control these limits.
+
+WWhheenn aallll tteessttss ssuucccceeeedd
+
+When a new SMTP client passes all tests (i.e. it is not whitelisted via some
+mechanism), postscreen(8) logs this as:
+
+ PPAASSSS NNEEWW [address]:port
+
+Where [address]:port are the client IP address and port. Then, postscreen(8)
+creates a temporary whitelist entry that excludes the client IP address from
+further tests until the temporary whitelist entry expires, as controlled with
+the postscreen_*_ttl parameters.
+
+When no "deep protocol tests" are configured, postscreen(8) hands off the
+"live" connection to a Postfix SMTP server process. The client can then
+continue as if postscreen(8) never even existed (except for the short
+postscreen_greet_wait delay).
+
+When any "deep protocol tests" are configured, postscreen(8) cannot hand off
+the "live" connection to a Postfix SMTP server process in the middle of the
+session. Instead, postscreen(8) defers mail delivery attempts with a 4XX
+status, logs the helo/sender/recipient information, and waits for the client to
+disconnect. The next time the client connects it will be allowed to talk to a
+Postfix SMTP server process to deliver its mail. postscreen(8) mitigates the
+impact of this limitation by giving deep protocol tests a long expiration time.
+
+CCoonnffiigguurriinngg tthhee ppoossttssccrreeeenn((88)) sseerrvviiccee
+
+postscreen(8) has been tested on FreeBSD [4-8], Linux 2.[4-6] and Solaris 9
+systems.
+
+ * Turning on postscreen(8) without blocking mail
+ * postscreen(8) TLS configuration
+ * Blocking mail with postscreen(8)
+ * Turning off postscreen(8)
+ * Sharing the temporary whitelist
+
+TTuurrnniinngg oonn ppoossttssccrreeeenn((88)) wwiitthhoouutt bblloocckkiinngg mmaaiill
+
+To enable the postscreen(8) service and log client information without blocking
+mail:
+
+ 1. Make sure that local clients and systems with non-standard SMTP
+ implementations are excluded from any postscreen(8) tests. The default is
+ to exclude all clients in mynetworks. To exclude additional clients, for
+ example, third-party performance monitoring tools (these tend to have
+ broken SMTP implementations):
+
+ /etc/postfix/main.cf:
+ # Exclude broken clients by whitelisting. Clients in mynetworks
+ # should always be whitelisted.
+ postscreen_access_list = permit_mynetworks,
+ cidr:/etc/postfix/postscreen_access.cidr
+
+ /etc/postfix/postscreen_access.cidr:
+ 192.168.254.0/24 permit
+
+ 2. Comment out the "smtp inet ... smtpd" service in master.cf, including any
+ "-o parameter=value" entries that follow.
+
+ /etc/postfix/master.cf:
+ #smtp inet n - n - - smtpd
+ # -o parameter=value ...
+
+ 3. Uncomment the new "smtpd pass ... smtpd" service in master.cf, and
+ duplicate any "-o parameter=value" entries from the smtpd service that was
+ commented out in the previous step.
+
+ /etc/postfix/master.cf:
+ smtpd pass - - n - - smtpd
+ -o parameter=value ...
+
+ 4. Uncomment the new "smtp inet ... postscreen" service in master.cf.
+
+ /etc/postfix/master.cf:
+ smtp inet n - n - 1 postscreen
+
+ 5. Uncomment the new "tlsproxy unix ... tlsproxy" service in master.cf. This
+ service implements STARTTLS support for postscreen(8).
+
+ /etc/postfix/master.cf:
+ tlsproxy unix - - n - 0 tlsproxy
+
+ 6. Uncomment the new "dnsblog unix ... dnsblog" service in master.cf. This
+ service does DNSBL lookups for postscreen(8) and logs results.
+
+ /etc/postfix/master.cf:
+ dnsblog unix - - n - 0 dnsblog
+
+ 7. To enable DNSBL lookups, list some DNS blocklist sites in main.cf,
+ separated by whitespace. Different sites can have different weights. For
+ example:
+
+ /etc/postfix/main.cf:
+ postscreen_dnsbl_threshold = 2
+ postscreen_dnsbl_sites = zen.spamhaus.org*2
+ bl.spamcop.net*1 b.barracudacentral.org*1
+
+ Note: if your DNSBL queries have a "secret" in the domain name, you must
+ censor this information from the postscreen(8) SMTP replies. For example:
+
+ /etc/postfix/main.cf:
+ postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
+
+ /etc/postfix/dnsbl_reply:
+ # Secret DNSBL name Name in postscreen(8) replies
+ secret.zen.dq.spamhaus.net zen.spamhaus.org
+
+ The texthash: format is similar to hash: except that there is no need to
+ run postmap(1) before the file can be used, and that it does not detect
+ changes after the file is read. It is new with Postfix version 2.8.
+
+ 8. Read the new configuration with "postfix reload".
+
+Notes:
+
+ * Some postscreen(8) configuration parameters implement stress-dependent
+ behavior. This is supported only when the default value is stress-dependent
+ (that is, "postconf -d parametername" output shows "parametername = $
+ {stress?something}${stress:something}"). Other parameters always evaluate
+ as if the stress value is the empty string.
+
+ * See "Tests before the 220 SMTP server greeting" for details about the
+ logging from these postscreen(8) tests.
+
+ * If you run Postfix 2.6 or earlier you must stop and start the master daemon
+ ("postfix stop; postfix start"). This is needed because the Postfix "pass"
+ master service type did not work reliably on all systems.
+
+ppoossttssccrreeeenn((88)) TTLLSS ccoonnffiigguurraattiioonn
+
+postscreen(8) TLS support is available for remote SMTP clients that aren't
+whitelisted, including clients that need to renew their temporary whitelist
+status. When a remote SMTP client requests TLS service, postscreen(8) invisibly
+hands off the connection to a tlsproxy(8) process. Then, tlsproxy(8) encrypts
+and decrypts the traffic between postscreen(8) and the remote SMTP client. One
+tlsproxy(8) process can handle multiple SMTP sessions. The number of tlsproxy
+(8) processes slowly increases with server load, but it should always be much
+smaller than the number of postscreen(8) TLS sessions.
+
+TLS support for postscreen(8) and tlsproxy(8) uses the same parameters as with
+smtpd(8). We recommend that you keep the relevant configuration parameters in
+main.cf. If you must specify "-o smtpd_mumble=value" parameter overrides in
+master.cf for a postscreen-protected smtpd(8) service, then you should specify
+those same parameter overrides for the postscreen(8) and tlsproxy(8) services.
+
+BBlloocckkiinngg mmaaiill wwiitthh ppoossttssccrreeeenn((88))
+
+For compatibility with smtpd(8), postscreen(8) implements the soft_bounce
+safety feature. This causes Postfix to reject mail with a "try again" reply
+code.
+
+ * To turn this on for all of Postfix, specify "soft_bounce = yes" in main.cf.
+
+ * To turn this on for postscreen(8) only, append "-o soft_bounce=yes" (note:
+ NO SPACES around '=') to the postscreen entry in master.cf.
+
+Execute "postfix reload" to make the change effective.
+
+After testing, do not forget to remove the soft_bounce feature, otherwise
+senders won't receive their non-delivery notification until many days later.
+
+To use the postscreen(8) service to block mail, edit main.cf and specify one or
+more of:
+
+ * "postscreen_dnsbl_action = enforce", to reject clients that are on DNS
+ blocklists, and to log the helo/sender/recipient information. With good
+ DNSBLs this reduces the amount of load on Postfix SMTP servers
+ dramatically.
+
+ * "postscreen_greet_action = enforce", to reject clients that talk before
+ their turn, and to log the helo/sender/recipient information. This stops
+ over half of all known-to-be illegitimate connections to Wietse's mail
+ server. It is backup protection for zombies that haven't yet been
+ blacklisted.
+
+ * You can also enable "deep protocol tests", but these are more intrusive
+ than the pregreet or DNSBL tests.
+
+ When a good client passes the "deep protocol tests", postscreen(8) adds the
+ client to the temporary whitelist but it cannot hand off the "live"
+ connection to a Postfix SMTP server process in the middle of the session.
+ Instead, postscreen(8) defers mail delivery attempts with a 4XX status,
+ logs the helo/sender/recipient information, and waits for the client to
+ disconnect.
+
+ When the good client comes back in a later session, it is allowed to talk
+ directly to a Postfix SMTP server. See "Tests after the 220 SMTP server
+ greeting" above for limitations with AUTH and other features that clients
+ may need.
+
+ An unexpected benefit from "deep protocol tests" is that some "good"
+ clients don't return after the 4XX reply; these clients were not so good
+ after all.
+
+ Unfortunately, some senders will retry requests from different IP
+ addresses, and may never get whitelisted. For this reason, Wietse stopped
+ using "deep protocol tests" on his own internet-facing mail server.
+
+ * There is also support for permanent blacklisting and whitelisting; see the
+ description of the postscreen_access_list parameter for details.
+
+TTuurrnniinngg ooffff ppoossttssccrreeeenn((88))
+
+To turn off postscreen(8) and handle mail directly with Postfix SMTP server
+processes:
+
+ 1. Comment out the "smtp inet ... postscreen" service in master.cf, including
+ any "-o parameter=value" entries that follow.
+
+ /etc/postfix/master.cf:
+ #smtp inet n - n - 1 postscreen
+ # -o parameter=value ...
+
+ 2. Comment out the "dnsblog unix ... dnsblog" service in master.cf.
+
+ /etc/postfix/master.cf:
+ #dnsblog unix - - n - 0 dnsblog
+
+ 3. Comment out the "smtpd pass ... smtpd" service in master.cf, including any
+ "-o parameter=value" entries that follow.
+
+ /etc/postfix/master.cf:
+ #smtpd pass - - n - - smtpd
+ # -o parameter=value ...
+
+ 4. Comment out the "tlsproxy unix ... tlsproxy" service in master.cf,
+ including any "-o parameter=value" entries that follow.
+
+ /etc/postfix/master.cf:
+ #tlsproxy unix - - n - 0 tlsproxy
+ # -o parameter=value ...
+
+ 5. Uncomment the "smtp inet ... smtpd" service in master.cf, including any "-
+ o parameter=value" entries that may follow.
+
+ /etc/postfix/master.cf:
+ smtp inet n - n - - smtpd
+ -o parameter=value ...
+
+ 6. Read the new configuration with "postfix reload".
+
+SShhaarriinngg tthhee tteemmppoorraarryy wwhhiitteelliisstt
+
+By default, the temporary whitelist is not shared between multiple postscreen
+(8) daemons. To enable sharing, choose one of the following options:
+
+ * A non-persistent memcache: temporary whitelist can be shared between
+ postscreen(8) daemons on the same host or different hosts. Disable cache
+ cleanup (postscreen_cache_cleanup_interval = 0) in all postscreen(8)
+ daemons because memcache: does not implement this (but see example 4 below
+ for memcache: with persistent backup). This requires Postfix 2.9 or later.
+
+ # Example 1: non-persistent memcache: whitelist.
+ /etc/postfix/main.cf:
+ postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
+ postscreen_cache_cleanup_interval = 0
+
+ /etc/postfix/postscreen_cache:
+ memcache = inet:127.0.0.1:11211
+ key_format = postscreen:%s
+
+ * A persistent lmdb: temporary whitelist can be shared between postscreen(8)
+ daemons that run under the same master(8) daemon, or under different master
+ (8) daemons on the same host. Disable cache cleanup
+ (postscreen_cache_cleanup_interval = 0) in all postscreen(8) daemons except
+ one that is responsible for cache cleanup. This requires Postfix 2.11 or
+ later.
+
+ # Example 2: persistent lmdb: whitelist.
+ /etc/postfix/main.cf:
+ postscreen_cache_map = lmdb:$data_directory/postscreen_cache
+ # See note 1 below.
+ # postscreen_cache_cleanup_interval = 0
+
+ * Other kinds of persistent temporary whitelist can be shared only between
+ postscreen(8) daemons that run under the same master(8) daemon. In this
+ case, temporary whitelist access must be shared through the proxymap(8)
+ daemon. This requires Postfix 2.9 or later.
+
+ # Example 3: proxied btree: whitelist.
+ /etc/postfix/main.cf:
+ postscreen_cache_map =
+ proxy:btree:/var/lib/postfix/postscreen_cache
+ # See note 1 below.
+ # postscreen_cache_cleanup_interval = 0
+
+ # Example 4: proxied btree: whitelist with memcache: accelerator.
+ /etc/postfix/main.cf:
+ postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
+ proxy_write_maps =
+ proxy:btree:/var/lib/postfix/postscreen_cache
+ ... other proxied tables ...
+ # See note 1 below.
+ # postscreen_cache_cleanup_interval = 0
+
+ /etc/postfix/postscreen_cache:
+ # Note: the $data_directory macro is not defined in this context.
+ memcache = inet:127.0.0.1:11211
+ backup = proxy:btree:/var/lib/postfix/postscreen_cache
+ key_format = postscreen:%s
+
+ Note 1: disable cache cleanup (postscreen_cache_cleanup_interval = 0) in
+ all postscreen(8) daemons except one that is responsible for cache cleanup.
+
+ Note 2: postscreen(8) cache sharing via proxymap(8) requires Postfix 2.9 or
+ later; earlier proxymap(8) implementations don't support cache cleanup.
+
+HHiissttoorriiccaall nnootteess aanndd ccrreeddiittss
+
+Many ideas in postscreen(8) were explored in earlier work by Michael Tokarev,
+in OpenBSD spamd, and in MailChannels Traffic Control.
+
+Wietse threw together a crude prototype with pregreet and dnsbl support in June
+2009, because he needed something new for a Mailserver conference presentation
+in July. Ralf Hildebrandt ran this code on several servers to collect real-
+world statistics. This version used the dnsblog(8) ad-hoc DNS client program.
+
+Wietse needed new material for a LISA conference presentation in November 2010,
+so he added support for DNSBL weights and filters in August, followed by a
+major code rewrite, deep protocol tests, helo/sender/recipient logging, and
+stress-adaptive behavior in September. Ralf Hildebrandt ran this code on
+several servers to collect real-world statistics. This version still used the
+embarrassing dnsblog(8) ad-hoc DNS client program.
+
+Wietse added STARTTLS support in December 2010. This makes postscreen(8) usable
+for sites that require TLS support. The implementation introduces the tlsproxy
+(8) event-driven TLS proxy that decrypts/encrypts the sessions for multiple
+SMTP clients.
+
+The tlsproxy(8) implementation led to the discovery of a "new" class of
+vulnerability (CVE-2011-0411) that affected multiple implementations of SMTP,
+POP, IMAP, NNTP, and FTP over TLS.
+
+postscreen(8) was officially released as part of the Postfix 2.8 stable release
+in January 2011.
+
diff --git a/README_FILES/QMQP_README b/README_FILES/QMQP_README
new file mode 100644
index 0000000..6bb664f
--- /dev/null
+++ b/README_FILES/QMQP_README
@@ -0,0 +1,5 @@
+PPoossttffiixx qqmmaaiill aanndd eezzmmllmm ssuuppppoorrtt
+
+-------------------------------------------------------------------------------
+This document will be made available via http://www.postfix.org/.
+
diff --git a/README_FILES/QSHAPE_README b/README_FILES/QSHAPE_README
new file mode 100644
index 0000000..311797a
--- /dev/null
+++ b/README_FILES/QSHAPE_README
@@ -0,0 +1,739 @@
+PPoossttffiixx BBoottttlleenneecckk AAnnaallyyssiiss
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document is an introduction to Postfix queue congestion analysis. It
+explains how the qshape(1) program can help to track down the reason for queue
+congestion. qshape(1) is bundled with Postfix 2.1 and later source code, under
+the "auxiliary" directory. This document describes qshape(1) as bundled with
+Postfix 2.4.
+
+This document covers the following topics:
+
+ * Introducing the qshape tool
+ * Trouble shooting with qshape
+ * Example 1: Healthy queue
+ * Example 2: Deferred queue full of dictionary attack bounces
+ * Example 3: Congestion in the active queue
+ * Example 4: High volume destination backlog
+ * Postfix queue directories
+
+ o The "maildrop" queue
+ o The "hold" queue
+ o The "incoming" queue
+ o The "active" queue
+ o The "deferred" queue
+
+ * Credits
+
+IInnttrroodduucciinngg tthhee qqsshhaappee ttooooll
+
+When mail is draining slowly or the queue is unexpectedly large, run qshape(1)
+as the super-user (root) to help zero in on the problem. The qshape(1) program
+displays a tabular view of the Postfix queue contents.
+
+ * On the horizontal axis, it displays the queue age with fine granularity for
+ recent messages and (geometrically) less fine granularity for older
+ messages.
+
+ * The vertical axis displays the destination (or with the "-s" switch the
+ sender) domain. Domains with the most messages are listed first.
+
+For example, in the output below we see the top 10 lines of the (mostly forged)
+sender domain distribution for captured spam in the "hold" queue:
+
+ $ qshape -s hold | head
+ T 5 10 20 40 80 160 320 640 1280 1280+
+ TOTAL 486 0 0 1 0 0 2 4 20 40 419
+ yahoo.com 14 0 0 1 0 0 0 0 1 0 12
+ extremepricecuts.net 13 0 0 0 0 0 0 0 2 0 11
+ ms35.hinet.net 12 0 0 0 0 0 0 0 0 1 11
+ winnersdaily.net 12 0 0 0 0 0 0 0 2 0 10
+ hotmail.com 11 0 0 0 0 0 0 0 0 1 10
+ worldnet.fr 6 0 0 0 0 0 0 0 0 0 6
+ ms41.hinet.net 6 0 0 0 0 0 0 0 0 0 6
+ osn.de 5 0 0 0 0 0 1 0 0 0 4
+
+ * The "T" column shows the total (in this case sender) count for each domain.
+ The columns with numbers above them, show counts for messages aged fewer
+ than that many minutes, but not younger than the age limit for the previous
+ column. The row labeled "TOTAL" shows the total count for all domains.
+
+ * In this example, there are 14 messages allegedly from yahoo.com, 1 between
+ 10 and 20 minutes old, 1 between 320 and 640 minutes old and 12 older than
+ 1280 minutes (1440 minutes in a day).
+
+When the output is a terminal intermediate results showing the top 20 domains
+(-n option) are displayed after every 1000 messages (-N option) and the final
+output also shows only the top 20 domains. This makes qshape useful even when
+the deferred queue is very large and it may otherwise take prohibitively long
+to read the entire deferred queue.
+
+By default, qshape shows statistics for the union of both the incoming and
+active queues which are the most relevant queues to look at when analyzing
+performance.
+
+One can request an alternate list of queues:
+
+ $ qshape deferred
+ $ qshape incoming active deferred
+
+this will show the age distribution of the deferred queue or the union of the
+incoming active and deferred queues.
+
+Command line options control the number of display "buckets", the age limit for
+the smallest bucket, display of parent domain counts and so on. The "-h" option
+outputs a summary of the available switches.
+
+TTrroouubbllee sshhoooottiinngg wwiitthh qqsshhaappee
+
+Large numbers in the qshape output represent a large number of messages that
+are destined to (or alleged to come from) a particular domain. It should be
+possible to tell at a glance which domains dominate the queue sender or
+recipient counts, approximately when a burst of mail started, and when it
+stopped.
+
+The problem destinations or sender domains appear near the top left corner of
+the output table. Remember that the active queue can accommodate up to 20000
+($qmgr_message_active_limit) messages. To check whether this limit has been
+reached, use:
+
+ $ qshape -s active (show sender statistics)
+
+If the total sender count is below 20000 the active queue is not yet saturated,
+any high volume sender domains show near the top of the output.
+
+With oqmgr(8) the active queue is also limited to at most 20000 recipient
+addresses ($qmgr_message_recipient_limit). To check for exhaustion of this
+limit use:
+
+ $ qshape active (show recipient statistics)
+
+Having found the high volume domains, it is often useful to search the logs for
+recent messages pertaining to the domains in question.
+
+ # Find deliveries to example.com
+ #
+ $ tail -10000 /var/log/maillog |
+ egrep -i ': to=<.*@example\.com>,' |
+ less
+
+ # Find messages from example.com
+ #
+ $ tail -10000 /var/log/maillog |
+ egrep -i ': from=<.*@example\.com>,' |
+ less
+
+You may want to drill in on some specific queue ids:
+
+ # Find all messages for a specific queue id.
+ #
+ $ tail -10000 /var/log/maillog | egrep ': 2B2173FF68: '
+
+Also look for queue manager warning messages in the log. These warnings can
+suggest strategies to reduce congestion.
+
+ $ egrep 'qmgr.*(panic|fatal|error|warning):' /var/log/maillog
+
+When all else fails try the Postfix mailing list for help, but please don't
+forget to include the top 10 or 20 lines of qshape(1) output.
+
+EExxaammppllee 11:: HHeeaalltthhyy qquueeuuee
+
+When looking at just the incoming and active queues, under normal conditions
+(no congestion) the incoming and active queues are nearly empty. Mail leaves
+the system almost as quickly as it comes in or is deferred without congestion
+in the active queue.
+
+ $ qshape (show incoming and active queue status)
+
+ T 5 10 20 40 80 160 320 640 1280 1280+
+ TOTAL 5 0 0 0 1 0 0 0 1 1 2
+ meri.uwasa.fi 5 0 0 0 1 0 0 0 1 1 2
+
+If one looks at the two queues separately, the incoming queue is empty or
+perhaps briefly has one or two messages, while the active queue holds more
+messages and for a somewhat longer time:
+
+ $ qshape incoming
+
+ T 5 10 20 40 80 160 320 640 1280 1280+
+ TOTAL 0 0 0 0 0 0 0 0 0 0 0
+
+ $ qshape active
+
+ T 5 10 20 40 80 160 320 640 1280 1280+
+ TOTAL 5 0 0 0 1 0 0 0 1 1 2
+ meri.uwasa.fi 5 0 0 0 1 0 0 0 1 1 2
+
+EExxaammppllee 22:: DDeeffeerrrreedd qquueeuuee ffuullll ooff ddiiccttiioonnaarryy aattttaacckk bboouunncceess
+
+This is from a server where recipient validation is not yet available for some
+of the hosted domains. Dictionary attacks on the unvalidated domains result in
+bounce backscatter. The bounces dominate the queue, but with proper tuning they
+do not saturate the incoming or active queues. The high volume of deferred mail
+is not a direct cause for alarm.
+
+ $ qshape deferred | head
+
+ T 5 10 20 40 80 160 320 640 1280 1280+
+ TOTAL 2234 4 2 5 9 31 57 108 201 464 1353
+ heyhihellothere.com 207 0 0 1 1 6 6 8 25 68 92
+ pleazerzoneprod.com 105 0 0 0 0 0 0 0 5 44 56
+ groups.msn.com 63 2 1 2 4 4 14 14 14 8 0
+ orion.toppoint.de 49 0 0 0 1 0 2 4 3 16 23
+ kali.com.cn 46 0 0 0 0 1 0 2 6 12 25
+ meri.uwasa.fi 44 0 0 0 0 1 0 2 8 11 22
+ gjr.paknet.com.pk 43 1 0 0 1 1 3 3 6 12 16
+ aristotle.algonet.se 41 0 0 0 0 0 1 2 11 12 15
+
+The domains shown are mostly bulk-mailers and all the volume is the tail end of
+the time distribution, showing that short term arrival rates are moderate.
+Larger numbers and lower message ages are more indicative of current trouble.
+Old mail still going nowhere is largely harmless so long as the active and
+incoming queues are short. We can also see that the groups.msn.com
+undeliverables are low rate steady stream rather than a concentrated dictionary
+attack that is now over.
+
+ $ qshape -s deferred | head
+
+ T 5 10 20 40 80 160 320 640 1280 1280+
+ TOTAL 2193 4 4 5 8 33 56 104 205 465 1309
+ MAILER-DAEMON 1709 4 4 5 8 33 55 101 198 452 849
+ example.com 263 0 0 0 0 0 0 0 0 2 261
+ example.org 209 0 0 0 0 0 1 3 6 11 188
+ example.net 6 0 0 0 0 0 0 0 0 0 6
+ example.edu 3 0 0 0 0 0 0 0 0 0 3
+ example.gov 2 0 0 0 0 0 0 0 1 0 1
+ example.mil 1 0 0 0 0 0 0 0 0 0 1
+
+Looking at the sender distribution, we see that as expected most of the
+messages are bounces.
+
+EExxaammppllee 33:: CCoonnggeessttiioonn iinn tthhee aaccttiivvee qquueeuuee
+
+This example is taken from a Feb 2004 discussion on the Postfix Users list.
+Congestion was reported with the active and incoming queues large and not
+shrinking despite very large delivery agent process limits. The thread is
+archived at: http://groups.google.com/
+groups?threadm=c0b7js$2r65$1@FreeBSD.csie.NCTU.edu.tw and http://
+archives.neohapsis.com/archives/postfix/2004-02/thread.html#1371
+
+Using an older version of qshape(1) it was quickly determined that all the
+messages were for just a few destinations:
+
+ $ qshape (show incoming and active queue status)
+
+ T A 5 10 20 40 80 160 320 320+
+ TOTAL 11775 9996 0 0 1 1 42 94 221 1420
+ user.sourceforge.net 7678 7678 0 0 0 0 0 0 0 0
+ lists.sourceforge.net 2313 2313 0 0 0 0 0 0 0 0
+ gzd.gotdns.com 102 0 0 0 0 0 0 0 2 100
+
+The "A" column showed the count of messages in the active queue, and the
+numbered columns showed totals for the deferred queue. At 10000 messages
+(Postfix 1.x active queue size limit) the active queue is full. The incoming
+was growing rapidly.
+
+With the trouble destinations clearly identified, the administrator quickly
+found and fixed the problem. It is substantially harder to glean the same
+information from the logs. While a careful reading of mailq(1) output should
+yield similar results, it is much harder to gauge the magnitude of the problem
+by looking at the queue one message at a time.
+
+EExxaammppllee 44:: HHiigghh vvoolluummee ddeessttiinnaattiioonn bbaacckklloogg
+
+When a site you send a lot of email to is down or slow, mail messages will
+rapidly build up in the deferred queue, or worse, in the active queue. The
+qshape output will show large numbers for the destination domain in all age
+buckets that overlap the starting time of the problem:
+
+ $ qshape deferred | head
+
+ T 5 10 20 40 80 160 320 640 1280 1280+
+ TOTAL 5000 200 200 400 800 1600 1000 200 200 200 200
+ highvolume.com 4000 160 160 320 640 1280 1440 0 0 0 0
+ ...
+
+Here the "highvolume.com" destination is continuing to accumulate deferred
+mail. The incoming and active queues are fine, but the deferred queue started
+growing some time between 1 and 2 hours ago and continues to grow.
+
+If the high volume destination is not down, but is instead slow, one might see
+similar congestion in the active queue. Active queue congestion is a greater
+cause for alarm; one might need to take measures to ensure that the mail is
+deferred instead or even add an access(5) rule asking the sender to try again
+later.
+
+If a high volume destination exhibits frequent bursts of consecutive
+connections refused by all MX hosts or "421 Server busy errors", it is possible
+for the queue manager to mark the destination as "dead" despite the transient
+nature of the errors. The destination will be retried again after the
+expiration of a $minimal_backoff_time timer. If the error bursts are frequent
+enough it may be that only a small quantity of email is delivered before the
+destination is again marked "dead". In some cases enabling static (not on
+demand) connection caching by listing the appropriate nexthop domain in a table
+included in "smtp_connection_cache_destinations" may help to reduce the error
+rate, because most messages will re-use existing connections.
+
+The MTA that has been observed most frequently to exhibit such bursts of errors
+is Microsoft Exchange, which refuses connections under load. Some proxy virus
+scanners in front of the Exchange server propagate the refused connection to
+the client as a "421" error.
+
+Note that it is now possible to configure Postfix to exhibit similarly erratic
+behavior by misconfiguring the anvil(8) service. Do not use anvil(8) for
+steady-state rate limiting, its purpose is (unintentional) DoS prevention and
+the rate limits set should be very generous!
+
+If one finds oneself needing to deliver a high volume of mail to a destination
+that exhibits frequent brief bursts of errors and connection caching does not
+solve the problem, there is a subtle workaround.
+
+ * Postfix version 2.5 and later:
+
+ o In master.cf set up a dedicated clone of the "smtp" transport for the
+ destination in question. In the example below we will call it
+ "fragile".
+
+ o In master.cf configure a reasonable process limit for the cloned smtp
+ transport (a number in the 10-20 range is typical).
+
+ o IMPORTANT!!! In main.cf configure a large per-destination pseudo-cohort
+ failure limit for the cloned smtp transport.
+
+ /etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+ fragile_destination_concurrency_failed_cohort_limit = 100
+ fragile_destination_concurrency_limit = 20
+
+ /etc/postfix/transport:
+ example.com fragile:
+
+ /etc/postfix/master.cf:
+ # service type private unpriv chroot wakeup maxproc command
+ fragile unix - - n - 20 smtp
+
+ See also the documentation for
+ default_destination_concurrency_failed_cohort_limit and
+ default_destination_concurrency_limit.
+
+ * Earlier Postfix versions:
+
+ o In master.cf set up a dedicated clone of the "smtp" transport for the
+ destination in question. In the example below we will call it
+ "fragile".
+
+ o In master.cf configure a reasonable process limit for the transport (a
+ number in the 10-20 range is typical).
+
+ o IMPORTANT!!! In main.cf configure a very large initial and destination
+ concurrency limit for this transport (say 2000).
+
+ /etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+ initial_destination_concurrency = 2000
+ fragile_destination_concurrency_limit = 2000
+
+ /etc/postfix/transport:
+ example.com fragile:
+
+ /etc/postfix/master.cf:
+ # service type private unpriv chroot wakeup maxproc command
+ fragile unix - - n - 20 smtp
+
+ See also the documentation for default_destination_concurrency_limit.
+
+The effect of this configuration is that up to 2000 consecutive errors are
+tolerated without marking the destination dead, while the total concurrency
+remains reasonable (10-20 processes). This trick is only for a very specialized
+situation: high volume delivery into a channel with multi-error bursts that is
+capable of high throughput, but is repeatedly throttled by the bursts of
+errors.
+
+When a destination is unable to handle the load even after the Postfix process
+limit is reduced to 1, a desperate measure is to insert brief delays between
+delivery attempts.
+
+ * Postfix version 2.5 and later:
+
+ o In master.cf set up a dedicated clone of the "smtp" transport for the
+ problem destination. In the example below we call it "slow".
+
+ o In main.cf configure a short delay between deliveries to the same
+ destination.
+
+ /etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+ slow_destination_rate_delay = 1
+ slow_destination_concurrency_failed_cohort_limit = 100
+
+ /etc/postfix/transport:
+ example.com slow:
+
+ /etc/postfix/master.cf:
+ # service type private unpriv chroot wakeup maxproc command
+ slow unix - - n - - smtp
+
+ See also the documentation for default_destination_rate_delay.
+
+ This solution forces the Postfix smtp(8) client to wait for
+ $slow_destination_rate_delay seconds between deliveries to the same
+ destination.
+
+ IMPORTANT!! The large slow_destination_concurrency_failed_cohort_limit
+ value is needed. This prevents Postfix from deferring all mail for the same
+ destination after only one connection or handshake error (the reason for
+ this is that non-zero slow_destination_rate_delay forces a per-destination
+ concurrency of 1).
+
+ * Earlier Postfix versions:
+
+ o In the transport map entry for the problem destination, specify a dead
+ host as the primary nexthop.
+
+ o In the master.cf entry for the transport specify the problem
+ destination as the fallback_relay and specify a small
+ smtp_connect_timeout value.
+
+ /etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+
+ /etc/postfix/transport:
+ example.com slow:[dead.host]
+
+ /etc/postfix/master.cf:
+ # service type private unpriv chroot wakeup maxproc command
+ slow unix - - n - 1 smtp
+ -o fallback_relay=problem.example.com
+ -o smtp_connect_timeout=1
+ -o smtp_connection_cache_on_demand=no
+
+ This solution forces the Postfix smtp(8) client to wait for
+ $smtp_connect_timeout seconds between deliveries. The connection caching
+ feature is disabled to prevent the client from skipping over the dead host.
+
+PPoossttffiixx qquueeuuee ddiirreeccttoorriieess
+
+The following sections describe Postfix queues: their purpose, what normal
+behavior looks like, and how to diagnose abnormal behavior.
+
+TThhee ""mmaaiillddrroopp"" qquueeuuee
+
+Messages that have been submitted via the Postfix sendmail(1) command, but not
+yet brought into the main Postfix queue by the pickup(8) service, await
+processing in the "maildrop" queue. Messages can be added to the "maildrop"
+queue even when the Postfix system is not running. They will begin to be
+processed once Postfix is started.
+
+The "maildrop" queue is drained by the single threaded pickup(8) service
+scanning the queue directory periodically or when notified of new message
+arrival by the postdrop(1) program. The postdrop(1) program is a setgid helper
+that allows the unprivileged Postfix sendmail(1) program to inject mail into
+the "maildrop" queue and to notify the pickup(8) service of its arrival.
+
+All mail that enters the main Postfix queue does so via the cleanup(8) service.
+The cleanup service is responsible for envelope and header rewriting, header
+and body regular expression checks, automatic bcc recipient processing, milter
+content processing, and reliable insertion of the message into the Postfix
+"incoming" queue.
+
+In the absence of excessive CPU consumption in cleanup(8) header or body
+regular expression checks or other software consuming all available CPU
+resources, Postfix performance is disk I/O bound. The rate at which the pickup
+(8) service can inject messages into the queue is largely determined by disk
+access times, since the cleanup(8) service must commit the message to stable
+storage before returning success. The same is true of the postdrop(1) program
+writing the message to the "maildrop" directory.
+
+As the pickup service is single threaded, it can only deliver one message at a
+time at a rate that does not exceed the reciprocal disk I/O latency (+ CPU if
+not negligible) of the cleanup service.
+
+Congestion in this queue is indicative of an excessive local message submission
+rate or perhaps excessive CPU consumption in the cleanup(8) service due to
+excessive body_checks, or (Postfix >= 2.3) high latency milters.
+
+Note, that once the active queue is full, the cleanup service will attempt to
+slow down message injection by pausing $in_flow_delay for each message. In this
+case "maildrop" queue congestion may be a consequence of congestion downstream,
+rather than a problem in its own right.
+
+Note, you should not attempt to deliver large volumes of mail via the pickup(8)
+service. High volume sites should avoid using "simple" content filters that re-
+inject scanned mail via Postfix sendmail(1) and postdrop(1).
+
+A high arrival rate of locally submitted mail may be an indication of an
+uncaught forwarding loop, or a run-away notification program. Try to keep the
+volume of local mail injection to a moderate level.
+
+The "postsuper -r" command can place selected messages into the "maildrop"
+queue for reprocessing. This is most useful for resetting any stale
+content_filter settings. Requeuing a large number of messages using "postsuper
+-r" can clearly cause a spike in the size of the "maildrop" queue.
+
+TThhee ""hhoolldd"" qquueeuuee
+
+The administrator can define "smtpd" access(5) policies, or cleanup(8) header/
+body checks that cause messages to be automatically diverted from normal
+processing and placed indefinitely in the "hold" queue. Messages placed in the
+"hold" queue stay there until the administrator intervenes. No periodic
+delivery attempts are made for messages in the "hold" queue. The postsuper(1)
+command can be used to manually release messages into the "deferred" queue.
+
+Messages can potentially stay in the "hold" queue longer than
+$maximal_queue_lifetime. If such "old" messages need to be released from the
+"hold" queue, they should typically be moved into the "maildrop" queue using
+"postsuper -r", so that the message gets a new timestamp and is given more than
+one opportunity to be delivered. Messages that are "young" can be moved
+directly into the "deferred" queue using "postsuper -H".
+
+The "hold" queue plays little role in Postfix performance, and monitoring of
+the "hold" queue is typically more closely motivated by tracking spam and
+malware, than by performance issues.
+
+TThhee ""iinnccoommiinngg"" qquueeuuee
+
+All new mail entering the Postfix queue is written by the cleanup(8) service
+into the "incoming" queue. New queue files are created owned by the "postfix"
+user with an access bitmask (or mode) of 0600. Once a queue file is ready for
+further processing the cleanup(8) service changes the queue file mode to 0700
+and notifies the queue manager of new mail arrival. The queue manager ignores
+incomplete queue files whose mode is 0600, as these are still being written by
+cleanup.
+
+The queue manager scans the incoming queue bringing any new mail into the
+"active" queue if the active queue resource limits have not been exceeded. By
+default, the active queue accommodates at most 20000 messages. Once the active
+queue message limit is reached, the queue manager stops scanning the incoming
+(and deferred, see below) queue.
+
+Under normal conditions the incoming queue is nearly empty (has only mode 0600
+files), with the queue manager able to import new messages into the active
+queue as soon as they become available.
+
+The incoming queue grows when the message input rate spikes above the rate at
+which the queue manager can import messages into the active queue. The main
+factors slowing down the queue manager are disk I/O and lookup queries to the
+trivial-rewrite service. If the queue manager is routinely not keeping up,
+consider not using "slow" lookup services (MySQL, LDAP, ...) for transport
+lookups or speeding up the hosts that provide the lookup service. If the
+problem is I/O starvation, consider striping the queue over more disks, faster
+controllers with a battery write cache, or other hardware improvements. At the
+very least, make sure that the queue directory is mounted with the "noatime"
+option if applicable to the underlying filesystem.
+
+The in_flow_delay parameter is used to clamp the input rate when the queue
+manager starts to fall behind. The cleanup(8) service will pause for
+$in_flow_delay seconds before creating a new queue file if it cannot obtain a
+"token" from the queue manager.
+
+Since the number of cleanup(8) processes is limited in most cases by the SMTP
+server concurrency, the input rate can exceed the output rate by at most "SMTP
+connection count" / $in_flow_delay messages per second.
+
+With a default process limit of 100, and an in_flow_delay of 1s, the coupling
+is strong enough to limit a single run-away injector to 1 message per second,
+but is not strong enough to deflect an excessive input rate from many sources
+at the same time.
+
+If a server is being hammered from multiple directions, consider raising the
+in_flow_delay to 10 seconds, but only if the incoming queue is growing even
+while the active queue is not full and the trivial-rewrite service is using a
+fast transport lookup mechanism.
+
+TThhee ""aaccttiivvee"" qquueeuuee
+
+The queue manager is a delivery agent scheduler; it works to ensure fast and
+fair delivery of mail to all destinations within designated resource limits.
+
+The active queue is somewhat analogous to an operating system's process run
+queue. Messages in the active queue are ready to be sent (runnable), but are
+not necessarily in the process of being sent (running).
+
+While most Postfix administrators think of the "active" queue as a directory on
+disk, the real "active" queue is a set of data structures in the memory of the
+queue manager process.
+
+Messages in the "maildrop", "hold", "incoming" and "deferred" queues (see
+below) do not occupy memory; they are safely stored on disk waiting for their
+turn to be processed. The envelope information for messages in the "active"
+queue is managed in memory, allowing the queue manager to do global scheduling,
+allocating available delivery agent processes to an appropriate message in the
+active queue.
+
+Within the active queue, (multi-recipient) messages are broken up into groups
+of recipients that share the same transport/nexthop combination; the group size
+is capped by the transport's recipient concurrency limit.
+
+Multiple recipient groups (from one or more messages) are queued for delivery
+grouped by transport/nexthop combination. The ddeessttiinnaattiioonn concurrency limit for
+the transports caps the number of simultaneous delivery attempts for each
+nexthop. Transports with a rreecciippiieenntt concurrency limit of 1 are special: these
+are grouped by the actual recipient address rather than the nexthop, yielding
+per-recipient concurrency limits rather than per-domain concurrency limits.
+Per-recipient limits are appropriate when performing final delivery to
+mailboxes rather than when relaying to a remote server.
+
+Congestion occurs in the active queue when one or more destinations drain
+slower than the corresponding message input rate.
+
+Input into the active queue comes both from new mail in the "incoming" queue,
+and retries of mail in the "deferred" queue. Should the "deferred" queue get
+really large, retries of old mail can dominate the arrival rate of new mail.
+Systems with more CPU, faster disks and more network bandwidth can deal with
+larger deferred queues, but as a rule of thumb the deferred queue scales to
+somewhere between 100,000 and 1,000,000 messages with good performance unlikely
+above that "limit". Systems with queues this large should typically stop
+accepting new mail, or put the backlog "on hold" until the underlying issue is
+fixed (provided that there is enough capacity to handle just the new mail).
+
+When a destination is down for some time, the queue manager will mark it dead,
+and immediately defer all mail for the destination without trying to assign it
+to a delivery agent. In this case the messages will quickly leave the active
+queue and end up in the deferred queue (with Postfix < 2.4, this is done
+directly by the queue manager, with Postfix >= 2.4 this is done via the "retry"
+delivery agent).
+
+When the destination is instead simply slow, or there is a problem causing an
+excessive arrival rate the active queue will grow and will become dominated by
+mail to the congested destination.
+
+The only way to reduce congestion is to either reduce the input rate or
+increase the throughput. Increasing the throughput requires either increasing
+the concurrency or reducing the latency of deliveries.
+
+For high volume sites a key tuning parameter is the number of "smtp" delivery
+agents allocated to the "smtp" and "relay" transports. High volume sites tend
+to send to many different destinations, many of which may be down or slow, so a
+good fraction of the available delivery agents will be blocked waiting for slow
+sites. Also mail destined across the globe will incur large SMTP command-
+response latencies, so high message throughput can only be achieved with more
+concurrent delivery agents.
+
+The default "smtp" process limit of 100 is good enough for most sites, and may
+even need to be lowered for sites with low bandwidth connections (no use
+increasing concurrency once the network pipe is full). When one finds that the
+queue is growing on an "idle" system (CPU, disk I/O and network not exhausted)
+the remaining reason for congestion is insufficient concurrency in the face of
+a high average latency. If the number of outbound SMTP connections (either
+ESTABLISHED or SYN_SENT) reaches the process limit, mail is draining slowly and
+the system and network are not loaded, raise the "smtp" and/or "relay" process
+limits!
+
+When a high volume destination is served by multiple MX hosts with typically
+low delivery latency, performance can suffer dramatically when one of the MX
+hosts is unresponsive and SMTP connections to that host timeout. For example,
+if there are 2 equal weight MX hosts, the SMTP connection timeout is 30 seconds
+and one of the MX hosts is down, the average SMTP connection will take
+approximately 15 seconds to complete. With a default per-destination
+concurrency limit of 20 connections, throughput falls to just over 1 message
+per second.
+
+The best way to avoid bottlenecks when one or more MX hosts is non-responsive
+is to use connection caching. Connection caching was introduced with Postfix
+2.2 and is by default enabled on demand for destinations with a backlog of mail
+in the active queue. When connection caching is in effect for a particular
+destination, established connections are re-used to send additional messages,
+this reduces the number of connections made per message delivery and maintains
+good throughput even in the face of partial unavailability of the destination's
+MX hosts.
+
+If connection caching is not available (Postfix < 2.2) or does not provide a
+sufficient latency reduction, especially for the "relay" transport used to
+forward mail to "your own" domains, consider setting lower than default SMTP
+connection timeouts (1-5 seconds) and higher than default destination
+concurrency limits. This will further reduce latency and provide more
+concurrency to maintain throughput should latency rise.
+
+Setting high concurrency limits to domains that are not your own may be viewed
+as hostile by the receiving system, and steps may be taken to prevent you from
+monopolizing the destination system's resources. The defensive measures may
+substantially reduce your throughput or block access entirely. Do not set
+aggressive concurrency limits to remote domains without coordinating with the
+administrators of the target domain.
+
+If necessary, dedicate and tune custom transports for selected high volume
+destinations. The "relay" transport is provided for forwarding mail to domains
+for which your server is a primary or backup MX host. These can make up a
+substantial fraction of your email traffic. Use the "relay" and not the "smtp"
+transport to send email to these domains. Using the "relay" transport allocates
+a separate delivery agent pool to these destinations and allows separate tuning
+of timeouts and concurrency limits.
+
+Another common cause of congestion is unwarranted flushing of the entire
+deferred queue. The deferred queue holds messages that are likely to fail to be
+delivered and are also likely to be slow to fail delivery (time out). As a
+result the most common reaction to a large deferred queue (flush it!) is more
+than likely counter-productive, and typically makes the congestion worse. Do
+not flush the deferred queue unless you expect that most of its content has
+recently become deliverable (e.g. relayhost back up after an outage)!
+
+Note that whenever the queue manager is restarted, there may already be
+messages in the active queue directory, but the "real" active queue in memory
+is empty. In order to recover the in-memory state, the queue manager moves all
+the active queue messages back into the incoming queue, and then uses its
+normal incoming queue scan to refill the active queue. The process of moving
+all the messages back and forth, redoing transport table (trivial-rewrite(8)
+resolve service) lookups, and re-importing the messages back into memory is
+expensive. At all costs, avoid frequent restarts of the queue manager (e.g. via
+frequent execution of "postfix reload").
+
+TThhee ""ddeeffeerrrreedd"" qquueeuuee
+
+When all the deliverable recipients for a message are delivered, and for some
+recipients delivery failed for a transient reason (it might succeed later), the
+message is placed in the deferred queue.
+
+The queue manager scans the deferred queue periodically. The scan interval is
+controlled by the queue_run_delay parameter. While a deferred queue scan is in
+progress, if an incoming queue scan is also in progress (ideally these are
+brief since the incoming queue should be short), the queue manager alternates
+between looking for messages in the "incoming" queue and in the "deferred"
+queue. This "round-robin" strategy prevents starvation of either the incoming
+or the deferred queues.
+
+Each deferred queue scan only brings a fraction of the deferred queue back into
+the active queue for a retry. This is because each message in the deferred
+queue is assigned a "cool-off" time when it is deferred. This is done by time-
+warping the modification time of the queue file into the future. The queue file
+is not eligible for a retry if its modification time is not yet reached.
+
+The "cool-off" time is at least $minimal_backoff_time and at most
+$maximal_backoff_time. The next retry time is set by doubling the message's age
+in the queue, and adjusting up or down to lie within the limits. This means
+that young messages are initially retried more often than old messages.
+
+If a high volume site routinely has large deferred queues, it may be useful to
+adjust the queue_run_delay, minimal_backoff_time and maximal_backoff_time to
+provide short enough delays on first failure (Postfix >= 2.4 has a sensibly low
+minimal backoff time by default), with perhaps longer delays after multiple
+failures, to reduce the retransmission rate of old messages and thereby reduce
+the quantity of previously deferred mail in the active queue. If you want a
+really low minimal_backoff_time, you may also want to lower queue_run_delay,
+but understand that more frequent scans will increase the demand for disk I/O.
+
+One common cause of large deferred queues is failure to validate recipients at
+the SMTP input stage. Since spammers routinely launch dictionary attacks from
+unrepliable sender addresses, the bounces for invalid recipient addresses clog
+the deferred queue (and at high volumes proportionally clog the active queue).
+Recipient validation is strongly recommended through use of the
+local_recipient_maps and relay_recipient_maps parameters. Even when bounces
+drain quickly they inundate innocent victims of forgery with unwanted email. To
+avoid this, do not accept mail for invalid recipients.
+
+When a host with lots of deferred mail is down for some time, it is possible
+for the entire deferred queue to reach its retry time simultaneously. This can
+lead to a very full active queue once the host comes back up. The phenomenon
+can repeat approximately every maximal_backoff_time seconds if the messages are
+again deferred after a brief burst of congestion. Perhaps, a future Postfix
+release will add a random offset to the retry time (or use a combination of
+strategies) to reduce the odds of repeated complete deferred queue flushes.
+
+CCrreeddiittss
+
+The qshape(1) program was developed by Victor Duchovni of Morgan Stanley, who
+also wrote the initial version of this document.
+
diff --git a/README_FILES/RELEASE_NOTES b/README_FILES/RELEASE_NOTES
new file mode 120000
index 0000000..577eefe
--- /dev/null
+++ b/README_FILES/RELEASE_NOTES
@@ -0,0 +1 @@
+../RELEASE_NOTES
\ No newline at end of file
diff --git a/README_FILES/RESTRICTION_CLASS_README b/README_FILES/RESTRICTION_CLASS_README
new file mode 100644
index 0000000..9c78684
--- /dev/null
+++ b/README_FILES/RESTRICTION_CLASS_README
@@ -0,0 +1,166 @@
+PPoossttffiixx PPeerr--CClliieenntt//UUsseerr//eettcc.. AAcccceessss CCoonnttrrooll
+
+-------------------------------------------------------------------------------
+
+PPoossttffiixx rreessttrriiccttiioonn ccllaasssseess
+
+The Postfix SMTP server supports access restrictions such as reject_rbl_client
+or reject_unknown_client_hostname on the right-hand side of SMTP server access
+(5) tables. This allows you to implement different junk mail restrictions for
+different clients or users.
+
+Having to specify lists of access restrictions for every recipient becomes
+tedious quickly. Postfix restriction classes allow you to give easy-to-remember
+names to groups of UCE restrictions (such as "permissive", "restrictive", and
+so on).
+
+The real reason for the existence of Postfix restriction classes is more
+mundane: you can't specify a lookup table on the right-hand side of a Postfix
+access table. This is because Postfix needs to open lookup tables ahead of
+time, but the reader probably does not care about these low-level details.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_restriction_classes = restrictive, permissive
+ # With Postfix < 2.3 specify reject_unknown_client.
+ restrictive = reject_unknown_sender_domain
+ reject_unknown_client_hostname ...
+ permissive = permit
+
+ smtpd_recipient_restrictions =
+ permit_mynetworks
+ # reject_unauth_destination is not needed here if the mail
+ # relay policy is specified with smtpd_relay_restrictions
+ # (available with Postfix 2.10 and later).
+ reject_unauth_destination
+ check_recipient_access hash:/etc/postfix/recipient_access
+ ...
+
+ /etc/postfix/recipient_access:
+ joe@my.domain permissive
+ jane@my.domain restrictive
+
+With this in place, you can use "restrictive" or "permissive" on the right-hand
+side of your per-client, helo, sender, or recipient SMTPD access tables.
+
+The remainder of this document gives examples of how Postfix access restriction
+classes can be used to:
+
+ * Shield an internal mailing list from outside posters,
+ * Prevent external access by internal senders.
+
+These questions come up frequently, and the examples hopefully make clear that
+Postfix restriction classes aren't really the right solution. They should be
+used for what they were designed to do, different junk mail restrictions for
+different clients or users.
+
+PPrrootteeccttiinngg iinntteerrnnaall eemmaaiill ddiissttrriibbuuttiioonn lliissttss
+
+ We want to implement an internal email distribution list. Something like
+ all@our.domain.com, which aliases to all employees. My first thought was to
+ use the aliases map, but that would lead to "all" being accessible from the
+ "outside", and this is not desired... :-)
+
+Postfix can implement per-address access controls. What follows is based on the
+SMTP client IP address, and therefore is subject to IP spoofing.
+
+ /etc/postfix/main.cf:
+ smtpd_recipient_restrictions =
+ ...
+ check_recipient_access hash:/etc/postfix/access
+ ...the usual stuff...
+
+ /etc/postfix/access:
+ all@my.domain permit_mynetworks,reject
+ all@my.hostname permit_mynetworks,reject
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what map types Postfix supports, use the command ppoossttccoonnff --mm.
+
+Now, that would be sufficient when your machine receives all Internet mail
+directly from the Internet. That's unlikely if your network is a bit larger
+than an office. For example, your backup MX hosts would "launder" the client IP
+address of mail from the outside so it would appear to come from a trusted
+machine.
+
+In the general case you need two lookup tables: one table that lists
+destinations that need to be protected, and one table that lists domains that
+are allowed to send to the protected destinations.
+
+What follows is based on the sender SMTP envelope address, and therefore is
+subject to SMTP sender spoofing.
+
+ /etc/postfix/main.cf:
+ smtpd_recipient_restrictions =
+ ...
+ check_recipient_access hash:/etc/postfix/protected_destinations
+ ...the usual stuff...
+
+ smtpd_restriction_classes = insiders_only
+ insiders_only = check_sender_access hash:/etc/postfix/insiders, reject
+
+ /etc/postfix/protected_destinations:
+ all@my.domain insiders_only
+ all@my.hostname insiders_only
+
+ /etc/postfix/insiders:
+ my.domain OK matches my.domain and subdomains
+ another.domain OK matches another.domain and subdomains
+
+Getting past this scheme is relatively easy, because all one has to do is to
+spoof the SMTP sender address.
+
+If the internal list is a low-volume one, perhaps it makes more sense to make
+it moderated.
+
+RReessttrriiccttiinngg wwhhaatt uusseerrss ccaann sseenndd mmaaiill ttoo ooffff--ssiittee ddeessttiinnaattiioonnss
+
+ How can I configure Postfix in a way that some users can send mail to the
+ internet and other users not. The users with no access should receive a
+ generic bounce message. Please don't discuss whether such access
+ restrictions are necessary, it was not my decision.
+
+Postfix has support for per-user restrictions. The restrictions are implemented
+by the SMTP server. Thus, users that violate the policy have their mail
+rejected by the SMTP server. Like this:
+
+ 554 : Access denied
+
+The implementation uses two lookup tables. One table defines what users are
+restricted in where they can send mail, and the other table defines what
+destinations are local. It is left as an exercise for the reader to change this
+into a scheme where only some users have permission to send mail to off-site
+destinations, and where most users are restricted.
+
+The example assumes DB/DBM files, but this could also be done with LDAP or SQL.
+
+ /etc/postfix/main.cf:
+ smtpd_recipient_restrictions =
+ ...
+ check_sender_access hash:/etc/postfix/restricted_senders
+ ...other stuff...
+
+ smtpd_restriction_classes = local_only
+ local_only =
+ check_recipient_access hash:/etc/postfix/local_domains, reject
+
+ /etc/postfix/restricted_senders:
+ foo@domain local_only
+ bar@domain local_only
+
+ /etc/postfix/local_domains:
+ this.domain OK matches this.domain and subdomains
+ that.domain OK matches that.domain and subdomains
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what map types Postfix supports, use the command ppoossttccoonnff --mm.
+
+Note: this scheme does not authenticate the user, and therefore it can be
+bypassed in several ways:
+
+ * By sending mail via a less restrictive mail relay host.
+
+ * By sending mail as someone else who does have permission to send mail to
+ off-site destinations.
+
diff --git a/README_FILES/SASL_README b/README_FILES/SASL_README
new file mode 100644
index 0000000..c4b22a2
--- /dev/null
+++ b/README_FILES/SASL_README
@@ -0,0 +1,1420 @@
+PPoossttffiixx SSAASSLL HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+WWaarrnniinngg
+
+People who go to the trouble of installing Postfix may have the expectation
+that Postfix is more secure than some other mailers. The Cyrus SASL library
+contains a lot of code. With this, Postfix becomes as secure as other mail
+systems that use the Cyrus SASL library. Dovecot provides an alternative that
+may be worth considering.
+
+HHooww PPoossttffiixx uusseess SSAASSLL aauutthheennttiiccaattiioonn
+
+SMTP servers need to decide whether an SMTP client is authorized to send mail
+to remote destinations, or only to destinations that the server itself is
+responsible for. Usually, SMTP servers accept mail to remote destinations when
+the client's IP address is in the "same network" as the server's IP address.
+
+SMTP clients outside the SMTP server's network need a different way to get
+"same network" privileges. To address this need, Postfix supports SASL
+authentication (RFC 4954, formerly RFC 2554). With this a remote SMTP client
+can authenticate to the Postfix SMTP server, and the Postfix SMTP client can
+authenticate to a remote SMTP server. Once a client is authenticated, a server
+can give it "same network" privileges.
+
+Postfix does not implement SASL itself, but instead uses existing
+implementations as building blocks. This means that some SASL-related
+configuration files will belong to Postfix, while other configuration files
+belong to the specific SASL implementation that Postfix will use. This document
+covers both the Postfix and non-Postfix configuration.
+
+You can read more about the following topics:
+
+ * Configuring SASL authentication in the Postfix SMTP server
+ * Configuring SASL authentication in the Postfix SMTP/LMTP client
+ * Building Postfix with SASL support
+ * Using Cyrus SASL version 1.5.x
+ * Credits
+
+CCoonnffiigguurriinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr
+
+As mentioned earlier, SASL is implemented separately from Postfix. For this
+reason, configuring SASL authentication in the Postfix SMTP server involves two
+different steps:
+
+ * Configuring the SASL implementation to offer a list of mechanisms that are
+ suitable for SASL authentication and, depending on the SASL implementation
+ used, configuring authentication backends that verify the remote SMTP
+ client's authentication data against the system password file or some other
+ database.
+
+ * Configuring the Postfix SMTP server to enable SASL authentication, and to
+ authorize clients to relay mail or to control what envelope sender
+ addresses the client may use.
+
+Successful authentication in the Postfix SMTP server requires a functional SASL
+framework. Configuring SASL should therefore always be the first step, before
+configuring Postfix.
+
+You can read more about the following topics:
+
+ * Which SASL Implementations are supported?
+ * Configuring Dovecot SASL
+
+ o Postfix to Dovecot SASL communication
+
+ * Configuring Cyrus SASL
+
+ o Cyrus SASL configuration file name
+ o Cyrus SASL configuration file location
+ o Postfix to Cyrus SASL communication
+
+ * Enabling SASL authentication and authorization in the Postfix SMTP server
+
+ o Enabling SASL authentication in the Postfix SMTP server
+ o Postfix SMTP Server policy - SASL mechanism properties
+ o Enabling SASL authorization in the Postfix SMTP server
+ o Additional SMTP Server SASL options
+
+ * Testing SASL authentication in the Postfix SMTP server
+
+WWhhiicchh SSAASSLL IImmpplleemmeennttaattiioonnss aarree ssuuppppoorrtteedd??
+
+Currently the Postfix SMTP server supports the Cyrus SASL and Dovecot SASL
+implementations.
+
+ NNoottee
+
+ Current Postfix versions have a plug-in architecture that can support
+ multiple SASL implementations. Before Postfix version 2.3, Postfix had
+ support only for Cyrus SASL.
+
+To find out what SASL implementations are compiled into Postfix, use the
+following commands:
+
+ % ppoossttccoonnff --aa (SASL support in the SMTP server)
+ % ppoossttccoonnff --AA (SASL support in the SMTP+LMTP client)
+
+These commands are available only with Postfix version 2.3 and later.
+
+CCoonnffiigguurriinngg DDoovveeccoott SSAASSLL
+
+Dovecot is a POP/IMAP server that has its own configuration to authenticate
+POP/IMAP clients. When the Postfix SMTP server uses Dovecot SASL, it reuses
+parts of this configuration. Consult the Dovecot documentation for how to
+configure and operate the Dovecot authentication server.
+
+PPoossttffiixx ttoo DDoovveeccoott SSAASSLL ccoommmmuunniiccaattiioonn
+
+Communication between the Postfix SMTP server and Dovecot SASL happens over a
+UNIX-domain socket or over a TCP socket. We will be using a UNIX-domain socket
+for better privacy.
+
+The following fragment for Dovecot version 2 assumes that the Postfix queue is
+under /var/spool/postfix/.
+
+ 1 conf.d/10-master.conf:
+ 2 service auth {
+ 3 ...
+ 4 unix_listener /var/spool/postfix/private/auth {
+ 5 mode = 0660
+ 6 # Assuming the default Postfix user and group
+ 7 user = postfix
+ 8 group = postfix
+ 9 }
+ 10 ...
+ 11 }
+ 12
+ 13 conf.d/10-auth.conf
+ 14 auth_mechanisms = plain login
+
+Line 4 places the Dovecot SASL socket in /var/spool/postfix/private/auth, lines
+5-8 limit read+write permissions to user and group postfix only, and line 14
+provides plain and login as mechanisms for the Postfix SMTP server.
+
+Proceed with the section "Enabling SASL authentication and authorization in the
+Postfix SMTP server" to turn on and use SASL in the Postfix SMTP server.
+
+CCoonnffiigguurriinngg CCyyrruuss SSAASSLL
+
+The Cyrus SASL framework supports a wide variety of applications (POP, IMAP,
+SMTP, etc.). Different applications may require different configurations. As a
+consequence each application may have its own configuration file.
+
+The first step configuring Cyrus SASL is to determine name and location of a
+configuration file that describes how the Postfix SMTP server will use the SASL
+framework.
+
+CCyyrruuss SSAASSLL ccoonnffiigguurraattiioonn ffiillee nnaammee
+
+The name of the configuration file (default: smtpd.conf) is configurable. It is
+a concatenation from a value that the Postfix SMTP server sends to the Cyrus
+SASL library, and the suffix .conf, added by Cyrus SASL.
+
+The value sent by Postfix is the name of the server component that will use
+Cyrus SASL. It defaults to smtpd and is configured with one of the following
+variables:
+
+ /etc/postfix/main.cf:
+ # Postfix 2.3 and later
+ smtpd_sasl_path = smtpd
+
+ # Postfix < 2.3
+ smtpd_sasl_application_name = smtpd
+
+CCyyrruuss SSAASSLL ccoonnffiigguurraattiioonn ffiillee llooccaattiioonn
+
+The location where Cyrus SASL searches for the named file depends on the Cyrus
+SASL version and the OS/distribution used.
+
+You can read more about the following topics:
+
+ * Cyrus SASL version 2.x searches for the configuration file in /usr/lib/
+ sasl2/.
+
+ * Cyrus SASL version 2.1.22 and newer additionally search in /etc/sasl2/.
+
+ * Some Postfix distributions are modified and look for the Cyrus SASL
+ configuration file in /etc/postfix/sasl/, /var/lib/sasl2/ etc. See the
+ distribution-specific documentation to determine the expected location.
+
+ NNoottee
+
+ Cyrus SASL searches /usr/lib/sasl2/ first. If it finds the specified
+ configuration file there, it will not examine other locations.
+
+PPoossttffiixx ttoo CCyyrruuss SSAASSLL ccoommmmuunniiccaattiioonn
+
+As the Postfix SMTP server is linked with the Cyrus SASL library libsasl,
+communication between Postfix and Cyrus SASL takes place by calling functions
+in the SASL library.
+
+The SASL library may use an external password verification service, or an
+internal plugin to connect to authentication backends and verify the SMTP
+client's authentication data against the system password file or other
+databases.
+
+The following table shows typical combinations discussed in this document:
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ | aauutthheennttiiccaattiioonn bbaacckkeenndd |ppaasssswwoorrdd vveerriiffiiccaattiioonn sseerrvviiccee // pplluuggiinn|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |/etc/shadow |saslauthd |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |PAM |saslauthd |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |IMAP server |saslauthd |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |sasldb |sasldb |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |MySQL, PostgreSQL, SQLite|sql |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |LDAP |ldapdb |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+ NNoottee
+
+ Read the Cyrus SASL documentation for other backends it can use.
+
+ssaassllaauutthhdd -- CCyyrruuss SSAASSLL ppaasssswwoorrdd vveerriiffiiccaattiioonn sseerrvviiccee
+
+Communication between the Postfix SMTP server (read: Cyrus SASL's libsasl) and
+the saslauthd server takes place over a UNIX-domain socket.
+
+saslauthd usually establishes the UNIX domain socket in /var/run/saslauthd/ and
+waits for authentication requests. The Postfix SMTP server must have
+read+execute permission to this directory or authentication attempts will fail.
+
+ IImmppoorrttaanntt
+
+ Some distributions require the user postfix to be member of a special group
+ e.g. sasl, otherwise it will not be able to access the saslauthd socket
+ directory.
+
+The following example configures the Cyrus SASL library to contact saslauthd as
+its password verification service:
+
+ /etc/sasl2/smtpd.conf:
+ pwcheck_method: saslauthd
+ mech_list: PLAIN LOGIN
+
+ IImmppoorrttaanntt
+
+ Do not specify any other mechanisms in mech_list than PLAIN or LOGIN when
+ using saslauthd! It can only handle these two mechanisms, and
+ authentication will fail if clients are allowed to choose other mechanisms.
+
+ IImmppoorrttaanntt
+
+ Plaintext mechanisms (PLAIN, LOGIN) send credentials unencrypted. This
+ information should be protected by an additional security layer such as a
+ TLS-encrypted SMTP session (see: TLS_README).
+
+Additionally the saslauthd server itself must be configured. It must be told
+which authentication backend to turn to for password verification. The backend
+is selected with a saslauthd command-line option and will be shown in the
+following examples.
+
+ NNoottee
+
+ Some distributions use a configuration file to provide saslauthd command
+ line options to set e.g. the authentication backend. Typical locations are
+ /etc/sysconfig/saslauthd or /etc/default/saslauthd.
+
+UUssiinngg ssaassllaauutthhdd wwiitthh //eettcc//sshhaaddooww
+
+Access to the /etc/shadow system password file requires root privileges. The
+Postfix SMTP server (and in consequence libsasl linked to the server) runs with
+the least privilege possible. Direct access to /etc/shadow would not be
+possible without breaking the Postfix security architecture.
+
+The saslauthd socket builds a safe bridge. Postfix, running as limited user
+postfix, can access the UNIX-domain socket that saslauthd receives commands on;
+saslauthd, running as privileged user root, has the privileges required to
+access the shadow file.
+
+The saslauthd server verifies passwords against the authentication backend /
+etc/shadow if started like this:
+
+ % ssaassllaauutthhdd --aa sshhaaddooww
+
+See section "Testing saslauthd authentication" for test instructions.
+
+UUssiinngg ssaassllaauutthhdd wwiitthh PPAAMM
+
+Cyrus SASL can use the PAM framework to authenticate credentials. saslauthd
+uses the PAM framework when started like this:
+
+ % ssaassllaauutthhdd --aa ppaamm
+
+ NNoottee
+
+ PAM configuration for the Postfix SMTP server is usually given in /etc/
+ pam.d/smtp and is beyond the scope of this document.
+
+See section "Testing saslauthd authentication" for test instructions.
+
+UUssiinngg ssaassllaauutthhdd wwiitthh aann IIMMAAPP sseerrvveerr
+
+saslauthd can verify the SMTP client credentials by using them to log into an
+IMAP server. If the login succeeds, SASL authentication also succeeds.
+saslauthd contacts an IMAP server when started like this:
+
+ % ssaassllaauutthhdd --aa rriimmaapp --OO iimmaapp..eexxaammppllee..ccoomm
+
+ NNoottee
+
+ The option "-O imap.example.com" specifies the IMAP server saslauthd should
+ contact when it verifies credentials.
+
+ IImmppoorrttaanntt
+
+ saslauthd sends IMAP login information unencrypted. Any IMAP session
+ leaving the local host should be protected by an additional security layer
+ such as an SSL tunnel.
+
+See section "Testing saslauthd authentication" for test instructions.
+
+TTeessttiinngg ssaassllaauutthhdd aauutthheennttiiccaattiioonn
+
+Cyrus SASL provides the testsaslauthd utility to test saslauthd authentication.
+The username and password are given as command line arguments. The example
+shows the response when authentication is successful:
+
+ % tteessttssaassllaauutthhdd --uu uusseerrnnaammee --pp ppaasssswwoorrdd
+ 0: OK "Success."
+
+ NNoottee
+
+ Sometimes the testsaslauthd program is not distributed with a the Cyrus
+ SASL main package. In that case, it may be distributed with -devel, -dev or
+ -debug packages.
+
+Specify an additional "-s smtp" if saslauthd was configured to contact the PAM
+authentication framework, and specify an additional "-f //ppaatthh//ttoo//ssoocckkeettddiirr//mmuuxx"
+if saslauthd establishes the UNIX-domain socket in a non-default location.
+
+If authentication succeeds, proceed with the section "Enabling SASL
+authentication and authorization in the Postfix SMTP server".
+
+CCyyrruuss SSAASSLL PPlluuggiinnss -- aauuxxiilliiaarryy pprrooppeerrttyy pplluuggiinnss
+
+Cyrus SASL uses a plugin infrastructure (called auxprop) to expand libsasl's
+capabilities. Currently Cyrus SASL sources provide three authentication
+plugins.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |PPlluuggiinn|DDeessccrriippttiioonn |
+ |_ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |sasldb|Accounts are stored stored in a Cyrus SASL Berkeley DB database|
+ |_ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |sql |Accounts are stored in a SQL database |
+ |_ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |ldapdb|Accounts are stored stored in an LDAP database |
+ |_ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+ IImmppoorrttaanntt
+
+ These three plugins support shared-secret mechanisms i.e. CRAM-MD5, DIGEST-
+ MD5 and NTLM. These mechanisms send credentials encrypted but their
+ verification process requires the password to be available in plaintext.
+ Consequently passwords cannot (!) be stored in encrypted form.
+
+TThhee ssaassllddbb pplluuggiinn
+
+The sasldb auxprop plugin authenticates SASL clients against credentials that
+are stored in a Berkeley DB database. The database schema is specific to Cyrus
+SASL. The database is usually located at /etc/sasldb2.
+
+ NNoottee
+
+ The sasldb2 file contains passwords in plaintext, and should have
+ read+write access only to user postfix or a group that postfix is member
+ of.
+
+The saslpasswd2 command-line utility creates and maintains the database:
+
+ % ssaassllppaasssswwdd22 --cc --uu eexxaammppllee..ccoomm uusseerrnnaammee
+ Password:
+ Again (for verification):
+
+This command creates an account uusseerrnnaammee@@eexxaammppllee..ccoomm.
+
+ IImmppoorrttaanntt
+
+ users must specify uusseerrnnaammee@@eexxaammppllee..ccoomm as login name, not uusseerrnnaammee.
+
+Run the following command to reuse the Postfix mydomain parameter value as the
+login domain:
+
+ % ssaassllppaasssswwdd22 --cc --uu ``ppoossttccoonnff --hh mmyyddoommaaiinn`` uusseerrnnaammee
+ Password:
+ Again (for verification):
+
+ NNoottee
+
+ Run saslpasswd2 without any options for further help on how to use the
+ command.
+
+The sasldblistusers2 command lists all existing users in the sasldb database:
+
+ % ssaassllddbblliissttuusseerrss22
+ username1@example.com: password1
+ username2@example.com: password2
+
+Configure libsasl to use sasldb with the following instructions:
+
+ /etc/sasl2/smtpd.conf:
+ pwcheck_method: auxprop
+ auxprop_plugin: sasldb
+ mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
+
+ NNoottee
+
+ In the above example adjust mech_list to the mechanisms that are applicable
+ for your environment.
+
+TThhee ssqqll pplluuggiinn
+
+The sql auxprop plugin is a generic SQL plugin. It provides access to
+credentials stored in a MySQL, PostgreSQL or SQLite database. This plugin
+requires that SASL client passwords are stored as plaintext.
+
+ TTiipp
+
+ If you must store encrypted passwords, you cannot use the sql auxprop
+ plugin. Instead, see section "Using saslauthd with PAM", and configure PAM
+ to look up the encrypted passwords with, for example, the pam_mysql module.
+ You will not be able to use any of the methods that require access to
+ plaintext passwords, such as the shared-secret methods CRAM-MD5 and DIGEST-
+ MD5.
+
+The following example configures libsasl to use the sql plugin and connects it
+to a PostgreSQL server:
+
+ /etc/sasl2/smtpd.conf:
+ pwcheck_method: auxprop
+ auxprop_plugin: sql
+ mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
+ sql_engine: pgsql
+ sql_hostnames: 127.0.0.1, 192.0.2.1
+ sql_user: username
+ sql_passwd: secret
+ sql_database: dbname
+ sql_select: SELECT password FROM users WHERE user = '%u@%r'
+
+ NNoottee
+
+ Set appropriate permissions if smtpd.conf contains a password. The file
+ should be readable by the postfix user.
+
+ NNoottee
+
+ In the above example, adjust mech_list to the mechanisms that are
+ applicable for your environment.
+
+The sql plugin has the following configuration options:
+
+ sql_engine
+ Specify mysql to connect to a MySQL server, pgsql for a PostgreSQL
+ server or sqlite for an SQLite database
+
+ sql_hostnames
+ Specify one or more servers (hostname or hostname:port) separated by
+ commas.
+
+ NNoottee
+
+ With MySQL servers, specify localhost to connect over a UNIX-domain
+ socket, and specify 127.0.0.1 to connect over a TCP socket.
+
+ sql_user
+ The login name to gain access to the database.
+
+ sql_passwd
+ The password to gain access to the database.
+
+ sql_database
+ The name of the database to connect to.
+
+ sql_select
+ The SELECT statement that should retrieve the plaintext password from a
+ database table.
+
+ IImmppoorrttaanntt
+
+ Do not enclose the statement in quotes! Use single quotes to escape
+ macros!
+
+The sql plugin provides macros to build sql_select statements. They will be
+replaced with arguments sent from the client. The following macros are
+available:
+
+ %u
+ The name of the user whose properties are being selected.
+
+ %p
+ The name of the property being selected. While this could technically
+ be anything, Cyrus SASL will try userPassword and cmusaslsecretMECHNAME
+ (where MECHNAME is the name of a SASL mechanism).
+
+ %r
+ The name of the realm to which the user belongs. This could be the
+ KERBEROS realm, the fully-qualified domain name of the computer the
+ SASL application is running on, or the domain after the "@" in a
+ username.
+
+TThhee llddaappddbb pplluuggiinn
+
+The ldapdb auxprop plugin provides access to credentials stored in an LDAP
+server. This plugin requires that SASL client passwords are stored as
+plaintext.
+
+ TTiipp
+
+ If you must store encrypted passwords, you cannot use the ldapdb auxprop
+ plugin. Instead, you can use "saslauthd -a ldap" to query the LDAP database
+ directly, with appropriate configuration in saslauthd.conf, as described
+ here. You will not be able to use any of the methods that require access to
+ plaintext passwords, such as the shared-secret methods CRAM-MD5 and DIGEST-
+ MD5.
+
+The ldapdb plugin implements proxy authorization. This means that the ldapdb
+plugin uses its own username and password to authenticate with the LDAP server,
+before it asks the LDAP server for the remote SMTP client's password. The LDAP
+server then decides if the ldapdb plugin is authorized to read the remote SMTP
+client's password.
+
+In a nutshell: Configuring ldapdb means authentication and authorization must
+be configured twice - once in the Postfix SMTP server to authenticate and
+authorize the remote SMTP client, and once in the LDAP server to authenticate
+and authorize the ldapdb plugin.
+
+This example configures libsasl to use the ldapdb plugin and the plugin to
+connect to an LDAP server:
+
+ /etc/sasl2/smtpd.conf:
+ pwcheck_method: auxprop
+ auxprop_plugin: ldapdb
+ mech_list: PLAIN LOGIN NTLM CRAM-MD5 DIGEST-MD5
+ ldapdb_uri: ldap://localhost
+ ldapdb_id: proxyuser
+ ldapdb_pw: password
+ ldapdb_mech: DIGEST-MD5
+
+ IImmppoorrttaanntt
+
+ Set appropriate permissions if smtpd.conf contains a password. The file
+ should be readable by the postfix user.
+
+ NNoottee
+
+ The shared-secret mechanisms (CRAM-MD5, etc.) require that the SASL client
+ passwords are stored as plaintext.
+
+The following is a summary of applicable smtpd.conf file entries:
+
+ auxprop_plugin
+ 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
+ connection.
+
+ ldapdb_id
+ The login name to authenticate the ldapdb plugin to the LDAP server
+ (proxy authorization).
+
+ ldapdb_pw
+ The password (in plaintext) to authenticate the ldapdb plugin to the
+ LDAP server (proxy authorization).
+
+ ldapdb_mech
+ The mechanism to authenticate the ldapdb plugin to the LDAP server.
+
+ NNoottee
+
+ Specify a mechanism here that is supported by the LDAP server.
+
+ ldapdb_rc (optional)
+ The path to a file containing individual configuration options for the
+ ldapdb LDAP client (libldap). This allows to specify a TLS client
+ certificate which in turn can be used to use the SASL EXTERNAL
+ mechanism.
+
+ NNoottee
+
+ This mechanism supports authentication over an encrypted transport
+ layer, which is recommended if the plugin must connect to an
+ OpenLDAP server on a remote machine.
+
+ ldapdb_starttls (optional)
+ The TLS policy for connecting to the LDAP server. Specify either try or
+ demand. If the option is try the plugin will attempt to establish a
+ TLS-encrypted connection with the LDAP server, and will fallback to an
+ unencrypted connection if TLS fails. If the policy is demand and a TLS-
+ encrypted connection cannot be established, the connection fails
+ immediately.
+
+When the ldapdb plugin connects to the OpenLDAP server and successfully
+authenticates, the OpenLDAP server decides if the plugin user is authorized to
+read SASL account information.
+
+The following configuration gives an example of authorization configuration in
+the OpenLDAP slapd server:
+
+ /etc/openldap/slapd.conf:
+ authz-regexp
+ uid=(.*),cn=.*,cn=auth
+ ldap:///dc=example,dc=com??sub?cn=$1
+ authz-policy to
+
+Here, the authz-regexp option serves for authentication of the ldapdb user. It
+maps its login name to a DN in the LDAP directory tree where slapd can look up
+the SASL account information. The authz-policy options defines the
+authentication policy. In this case it grants authentication privileges "to"
+the ldapdb plugin.
+
+The last configuration step is to tell the OpenLDAP slapd server where ldapdb
+may search for usernames matching the one given by the mail client. The example
+below adds an additional attribute ldapdb user object (here: authzTo because
+the authz-policy is "to") and configures the scope where the login name
+"proxyuser" may search:
+
+ dn: cn=proxyuser,dc=example,dc=com
+ changetype: modify
+ add: authzTo
+ authzTo: dn.regex:uniqueIdentifier=(.*),ou=people,dc=example,dc=com
+
+Use the ldapmodify or ldapadd command to add the above attribute.
+
+ NNoottee
+
+ Read the chapter "Using SASL" in the OpenLDAP Admin Guide for more detailed
+ instructions to set up SASL authentication in OpenLDAP.
+
+EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn aanndd aauutthhoorriizzaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr
+
+By default the Postfix SMTP server uses the Cyrus SASL implementation. If the
+Dovecot SASL implementation should be used, specify an smtpd_sasl_type value of
+dovecot instead of cyrus:
+
+ /etc/postfix/main.cf:
+ smtpd_sasl_type = dovecot
+
+Additionally specify how Postfix SMTP server can find the Dovecot
+authentication server. This depends on the settings that you have selected in
+the section "Postfix to Dovecot SASL communication".
+
+ * If you configured Dovecot for UNIX-domain socket communication, configure
+ Postfix as follows:
+
+ /etc/postfix/main.cf:
+ smtpd_sasl_path = private/auth
+
+ NNoottee
+ This example uses a pathname relative to the Postfix queue directory, so
+ that it will work whether or not the Postfix SMTP server runs chrooted.
+
+ * If you configured Dovecot for TCP socket communication, configure Postfix
+ as follows. If Dovecot runs on a different machine, replace 127.0.0.1 by
+ that machine's IP address.
+
+ /etc/postfix/main.cf:
+ smtpd_sasl_path = inet:127.0.0.1:12345
+
+ NNoottee
+ If you specify a remote IP address, information will be sent as plaintext
+ over the network.
+
+EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr
+
+Regardless of the SASL implementation type, enabling SMTP authentication in the
+Postfix SMTP server always requires setting the smtpd_sasl_auth_enable option:
+
+ /etc/postfix/main.cf:
+ smtpd_sasl_auth_enable = yes
+
+After a "postfix reload", SMTP clients will see the additional capability AUTH
+in an SMTP session, followed by a list of authentication mechanisms the server
+supports:
+
+ % tteellnneett sseerrvveerr..eexxaammppllee..ccoomm 2255
+ ...
+ 220 server.example.com ESMTP Postfix
+ EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+ 250-server.example.com
+ 250-PIPELINING
+ 250-SIZE 10240000
+ 250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+ ...
+
+However not all clients recognize the AUTH capability as defined by the SASL
+authentication RFC. Some historical implementations expect the server to send
+an "=" as separator between the AUTH verb and the list of mechanisms that
+follows it.
+
+The broken_sasl_auth_clients configuration option lets Postfix repeat the AUTH
+statement in a form that these broken clients understand:
+
+ /etc/postfix/main.cf:
+ broken_sasl_auth_clients = yes
+
+ NNoottee
+
+ Enable this option for Outlook up to and including version 2003 and Outlook
+ Express up to version 6. This option does not hurt other clients.
+
+After "postfix reload", the Postfix SMTP server will propagate the AUTH
+capability twice - once for compliant and once for broken clients:
+
+ % tteellnneett sseerrvveerr..eexxaammppllee..ccoomm 2255
+ ...
+ 220 server.example.com ESMTP Postfix
+ EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+ 250-server.example.com
+ 250-PIPELINING
+ 250-SIZE 10240000
+ 250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+ 250-AUTH=DIGEST-MD5 PLAIN CRAM-MD5
+ ...
+
+PPoossttffiixx SSMMTTPP SSeerrvveerr ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm pprrooppeerrttiieess
+
+The Postfix SMTP server supports policies that limit the SASL mechanisms that
+it makes available to clients, based on the properties of those mechanisms. The
+next two sections give examples of how these policies are used.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |PPrrooppeerrttyy |DDeessccrriippttiioonn |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |noanonymous |Don't use mechanisms that permit anonymous |
+ | |authentication. |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |noplaintext |Don't use mechanisms that transmit unencrypted username |
+ | |and password information. |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |nodictionary |Don't use mechanisms that are vulnerable to dictionary |
+ | |attacks. |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |forward_secrecy|Require forward secrecy between sessions (breaking one |
+ | |session does not break earlier sessions). |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |mutual_auth |Use only mechanisms that authenticate both the client and|
+ | |the server to each other. |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+UUnneennccrryypptteedd SSMMTTPP sseessssiioonn
+
+The default policy is to allow any mechanism in the Postfix SMTP server except
+for those based on anonymous authentication:
+
+ /etc/postfix/main.cf:
+ # Specify a list of properties separated by comma or whitespace
+ smtpd_sasl_security_options = noanonymous
+
+ IImmppoorrttaanntt
+
+ Always set at least the noanonymous option. Otherwise, the Postfix SMTP
+ server can give strangers the same authorization as a properly-
+ authenticated client.
+
+EEnnccrryypptteedd SSMMTTPP sseessssiioonn ((TTLLSS))
+
+A separate parameter controls Postfix SASL mechanism policy during a TLS-
+encrypted SMTP session. The default is to copy the settings from the
+unencrypted session:
+
+ /etc/postfix/main.cf:
+ smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
+
+A more sophisticated policy allows plaintext mechanisms, but only over a TLS-
+encrypted connection:
+
+ /etc/postfix/main.cf:
+ smtpd_sasl_security_options = noanonymous, noplaintext
+ smtpd_sasl_tls_security_options = noanonymous
+
+To offer SASL authentication only after a TLS-encrypted session has been
+established specify this:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_auth_only = yes
+
+EEnnaabblliinngg SSAASSLL aauutthhoorriizzaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr
+
+After the client has authenticated with SASL, the Postfix SMTP server decides
+what the remote SMTP client will be authorized for. Examples of possible SMTP
+clients authorizations are:
+
+ * Send a message to a remote recipient.
+
+ * Use a specific envelope sender in the MAIL FROM command.
+
+These permissions are not enabled by default.
+
+MMaaiill rreellaayy aauutthhoorriizzaattiioonn
+
+With permit_sasl_authenticated the Postfix SMTP server can allow SASL-
+authenticated SMTP clients to send mail to remote destinations. Examples:
+
+ # With Postfix 2.10 and later, the mail relay policy is
+ # preferably specified under smtpd_relay_restrictions.
+ /etc/postfix/main.cf:
+ smtpd_relay_restrictions =
+ permit_mynetworks
+ ppeerrmmiitt__ssaassll__aauutthheennttiiccaatteedd
+ reject_unauth_destination
+
+ # Older configurations combine relay control and spam control under
+ # smtpd_recipient_restrictions. To use this example with Postfix >=
+ # 2.10 specify "smtpd_relay_restrictions=".
+ /etc/postfix/main.cf:
+ smtpd_recipient_restrictions =
+ permit_mynetworks
+ ppeerrmmiitt__ssaassll__aauutthheennttiiccaatteedd
+ reject_unauth_destination
+ ...other rules...
+
+EEnnvveellooppee sseennddeerr aaddddrreessss aauutthhoorriizzaattiioonn
+
+By default an SMTP client may specify any envelope sender address in the MAIL
+FROM command. That is because the Postfix SMTP server only knows the remote
+SMTP client hostname and IP address, but not the user who controls the remote
+SMTP client.
+
+This changes the moment an SMTP client uses SASL authentication. Now, the
+Postfix SMTP server knows who the sender is. Given a table of envelope sender
+addresses and SASL login names, the Postfix SMTP server can decide if the SASL
+authenticated client is allowed to use a particular envelope sender address:
+
+ /etc/postfix/main.cf:
+ ssmmttppdd__sseennddeerr__llooggiinn__mmaappss == hhaasshh:://eettcc//ppoossttffiixx//ccoonnttrroolllleedd__eennvveellooppee__sseennddeerrss
+
+ smtpd_recipient_restrictions =
+ ...
+ rreejjeecctt__sseennddeerr__llooggiinn__mmiissmmaattcchh
+ permit_sasl_authenticated
+ ...
+
+The controlled_envelope_senders table specifies the binding between a sender
+envelope address and the SASL login names that own that address:
+
+ /etc/postfix/controlled_envelope_senders
+ # envelope sender owners (SASL login names)
+ john@example.com john@example.com
+ helpdesk@example.com john@example.com, mary@example.com
+ postmaster admin@example.com
+ @example.net barney, fred, john@example.com,
+ mary@example.com
+
+With this, the reject_sender_login_mismatch restriction above will reject the
+sender address in the MAIL FROM command if smtpd_sender_login_maps does not
+specify the SMTP client's login name as an owner of that address.
+
+See also reject_authenticated_sender_login_mismatch,
+reject_known_sender_login_mismatch, and
+reject_unauthenticated_sender_login_mismatch for additional control over the
+SASL login name and the envelope sender.
+
+AAddddiittiioonnaall SSMMTTPP SSeerrvveerr SSAASSLL ooppttiioonnss
+
+Postfix provides a wide range of SASL authentication configuration options. The
+next section lists a few that are discussed frequently. See postconf(5) for a
+complete list.
+
+PPeerr--aaccccoouunntt aacccceessss ccoonnttrrooll
+
+Postfix can implement policies that depend on the SASL login name (Postfix 2.11
+and later). Typically this is used to HOLD or REJECT mail from accounts whose
+credentials have been compromised.
+
+ /etc/postfix/main.cf:
+ smtpd_recipient_restrictions =
+ permit_mynetworks
+ check_sasl_access hash:/etc/postfix/sasl_access
+ permit_sasl_authenticated
+ ...
+
+ /etc/postfix/sasl_access:
+ # Use this when smtpd_sasl_local_domain is empty.
+ username HOLD
+ # Use this when smtpd_sasl_local_domain=example.com.
+ username@example.com HOLD
+
+DDeeffaauulltt aauutthheennttiiccaattiioonn ddoommaaiinn
+
+Postfix can append a domain name (or any other string) to a SASL login name
+that does not have a domain part, e.g. "john" instead of "john@example.com":
+
+ /etc/postfix/main.cf:
+ smtpd_sasl_local_domain = example.com
+
+This is useful as a default setting and safety net for misconfigured clients,
+or during a migration to an authentication method/backend that requires an
+authentication REALM or domain name, before all SMTP clients are configured to
+send such information.
+
+HHiiddiinngg SSAASSLL aauutthheennttiiccaattiioonn ffrroomm cclliieennttss oorr nneettwwoorrkkss
+
+Some clients insist on using SASL authentication if it is offered, even when
+they are not configured to send credentials - and therefore they will always
+fail and disconnect.
+
+Postfix can hide the AUTH capability from these clients/networks:
+
+ /etc/postfix/main.cf:
+ smtpd_sasl_exceptions_networks = !192.0.2.171/32, 192.0.2.0/24
+
+AAddddiinngg tthhee SSAASSLL llooggiinn nnaammee ttoo mmaaiill hheeaaddeerrss
+
+To report SASL login names in Received: message headers (Postfix version 2.3
+and later):
+
+ /etc/postfix/main.cf:
+ smtpd_sasl_authenticated_header = yes
+
+ NNoottee
+
+ The SASL login names will be shared with the entire world.
+
+TTeessttiinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP SSeerrvveerr
+
+To test the server side, connect (for example, with telnet) to the Postfix SMTP
+server port and you should be able to have a conversation as shown below.
+Information sent by the client (that is, you) is shown in bboolldd font.
+
+ % tteellnneett sseerrvveerr..eexxaammppllee..ccoomm 2255
+ ...
+ 220 server.example.com ESMTP Postfix
+ EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+ 250-server.example.com
+ 250-PIPELINING
+ 250-SIZE 10240000
+ 250-ETRN
+ 250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
+ 250 8BITMIME
+ AAUUTTHH PPLLAAIINN AAHHRRllcc33QQAAddGGVVzzddHHBBhhcc33MM==
+ 235 Authentication successful
+
+To test this over a connection that is encrypted with TLS, use openssl s_client
+instead of telnet:
+
+ % ooppeennssssll ss__cclliieenntt --ccoonnnneecctt sseerrvveerr..eexxaammppllee..ccoomm::2255 --ssttaarrttttllss ssmmttpp
+ ...
+ 220 server.example.com ESMTP Postfix
+ EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+ ...see above example for more...
+
+Instead of AHRlc3QAdGVzdHBhc3M=, specify the base64-encoded form of
+\0username\0password (the \0 is a null byte). The example above is for a user
+named `test' with password `testpass'.
+
+ CCaauuttiioonn
+
+ When posting logs of the SASL negotiations to public lists, please keep in
+ mind that username/password information is trivial to recover from the
+ base64-encoded form.
+
+You can use one of the following commands to generate base64 encoded
+authentication information:
+
+ * Using a recent version of the bbaasshh shell:
+
+ % eecchhoo --nnee ''\\000000uusseerrnnaammee\\000000ppaasssswwoorrdd'' || ooppeennssssll bbaassee6644
+
+ Some other shells support similar syntax.
+
+ * Using the pprriinnttff command:
+
+ % pprriinnttff ''\\00%%ss\\00%%ss'' ''uusseerrnnaammee'' ''ppaasssswwoorrdd'' || ooppeennssssll bbaassee6644
+ % pprriinnttff ''\\00%%ss\\00%%ss'' ''uusseerrnnaammee'' ''ppaasssswwoorrdd'' || mmmmeennccooddee
+
+ The mmmmeennccooddee command is part of the metamail software.
+
+ * Using Perl MMIIMMEE::::BBaassee6644 (from http://www.cpan.org/):
+
+ % ppeerrll --MMMMIIMMEE::::BBaassee6644 --ee \\
+ ''pprriinntt eennccooddee__bbaassee6644((""\\00uusseerrnnaammee\\00ppaasssswwoorrdd""));;''
+
+ If the username or password contain "@", you must specify "\@".
+
+ * Using the ggeenn--aauutthh script:
+
+ % ggeenn--aauutthh ppllaaiinn
+ username: uusseerrnnaammee
+ password:
+
+ The ggeenn--aauutthh Perl script was written by John Jetmore and can be found at
+ http://jetmore.org/john/code/gen-auth.
+
+CCoonnffiigguurriinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
+
+The Postfix SMTP and the LMTP client can authenticate with a remote SMTP server
+via the Cyrus SASL framework. At this time, the Dovecot SASL implementation
+does not provide client functionality.
+
+ NNoottee
+
+ The examples in this section discuss only the SMTP client. Replace smtp_
+ with lmtp_ to get the corresponding LMTP client configuration.
+
+You can read more about the following topics:
+
+ * Enabling SASL authentication in the Postfix SMTP/LMTP client
+ * Configuring sender-dependent SASL authentication
+ * Postfix SMTP/LMTP client policy - SASL mechanism pprrooppeerrttiieess
+ * Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess
+
+EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
+
+This section shows a typical scenario where the Postfix SMTP client sends all
+messages via a mail gateway server that requires SASL authentication.
+
+ TTrroouubbllee ssoollvviinngg ttiippss::
+
+ * If your SASL logins fail with "SASL authentication failure: No worthy
+ mechs found" in the mail logfile, then see the section "Postfix SMTP/
+ LMTP client policy - SASL mechanism pprrooppeerrttiieess".
+
+ * For a solution to a more obscure class of SASL authentication failures,
+ see "Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess".
+
+To make the example more readable we introduce it in two parts. The first part
+takes care of the basic configuration, while the second part sets up the
+username/password information.
+
+ /etc/postfix/main.cf:
+ smtp_sasl_auth_enable = yes
+ smtp_tls_security_level = encrypt
+ smtp_sasl_tls_security_options = noanonymous
+ relayhost = [mail.isp.example]
+ # Alternative form:
+ # relayhost = [mail.isp.example]:submission
+ smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+
+ * The smtp_sasl_auth_enable setting enables client-side authentication. We
+ will configure the client's username and password information in the second
+ part of the example.
+
+ * The smtp_tls_security_level setting ensures that the connection to the
+ remote smtp server will be encrypted, and smtp_sasl_tls_security_options
+ removes the prohibition on plaintext passwords.
+
+ * The relayhost setting forces the Postfix SMTP to send all remote messages
+ to the specified mail server instead of trying to deliver them directly to
+ their destination.
+
+ * In the relayhost setting, the "[" and "]" prevent the Postfix SMTP client
+ from looking up MX (mail exchanger) records for the enclosed name.
+
+ * The relayhost destination may also specify a non-default TCP port. For
+ example, the alternative form [mail.isp.example]:submission tells Postfix
+ to connect to TCP network port 587, which is reserved for email client
+ applications.
+
+ * The Postfix SMTP client is compatible with SMTP servers that use the non-
+ standard "AUTH=mmeetthhoodd....." syntax in response to the EHLO command; this
+ requires no additional Postfix client configuration.
+
+ * The Postfix SMTP client does not support the obsolete "wrappermode"
+ protocol, which uses TCP port 465 on the SMTP server. See TLS_README for a
+ solution that uses the stunnel command.
+
+ * With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP
+ client to send username and password information to the mail gateway
+ server. As discussed in the next section, the Postfix SMTP client supports
+ multiple ISP accounts. For this reason the username and password are stored
+ in a table that contains one username/password combination for each mail
+ gateway server.
+
+ /etc/postfix/sasl_passwd:
+ # destination credentials
+ [mail.isp.example] username:password
+ # Alternative form:
+ # [mail.isp.example]:submission username:password
+
+ IImmppoorrttaanntt
+
+ Keep the SASL client password file in /etc/postfix, and make the file
+ read+write only for root to protect the username/password combinations
+ against other users. The Postfix SMTP client will still be able to read the
+ SASL client passwords. It opens the file as user root before it drops
+ privileges, and before entering an optional chroot jail.
+
+ * Use the postmap command whenever you change the /etc/postfix/sasl_passwd
+ file.
+
+ * If you specify the "[" and "]" in the relayhost destination, then you must
+ use the same form in the smtp_sasl_password_maps file.
+
+ * If you specify a non-default TCP Port (such as ":submission" or ":587") in
+ the relayhost destination, then you must use the same form in the
+ smtp_sasl_password_maps file.
+
+CCoonnffiigguurriinngg SSeennddeerr--DDeeppeennddeenntt SSAASSLL aauutthheennttiiccaattiioonn
+
+Postfix supports different ISP accounts for different sender addresses (version
+2.3 and later). This can be useful when one person uses the same machine for
+work and for personal use, or when people with different ISP accounts share the
+same Postfix server.
+
+To make this possible, Postfix supports per-sender SASL passwords and per-
+sender relay hosts. In the example below, the Postfix SMTP client will search
+the SASL password file by sender address before it searches that same file by
+destination. Likewise, the Postfix trivial-rewrite(8) daemon will search the
+per-sender relayhost file, and use the default relayhost setting only as a
+final resort.
+
+ /etc/postfix/main.cf:
+ smtp_sender_dependent_authentication = yes
+ sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
+ smtp_sasl_auth_enable = yes
+ smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+ relayhost = [mail.isp.example]
+ # Alternative form:
+ # relayhost = [mail.isp.example]:submission
+
+ /etc/postfix/sasl_passwd:
+ # Per-sender authentication; see also /etc/postfix/sender_relay.
+ user1@example.com username1:password1
+ user2@example.net username2:password2
+ # Login information for the default relayhost.
+ [mail.isp.example] username:password
+ # Alternative form:
+ # [mail.isp.example]:submission username:password
+
+ /etc/postfix/sender_relay:
+ # Per-sender provider; see also /etc/postfix/sasl_passwd.
+ user1@example.com [mail.example.com]:submission
+ user2@example.net [mail.example.net]
+
+ * If you are creative, then you can try to combine the two tables into one
+ single MySQL database, and configure different Postfix queries to extract
+ the appropriate information.
+
+ * Specify dbm instead of hash if your system uses dbm files instead of db
+ files. To find out what lookup tables Postfix supports, use the command
+ "postconf -m".
+
+ * Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change
+ the sasl_passwd table.
+
+ * Execute the command "postmap /etc/postfix/sender_relay" whenever you change
+ the sender_relay table.
+
+PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm pprrooppeerrttiieess
+
+Just like the Postfix SMTP server, the SMTP client has a policy that determines
+which SASL mechanisms are acceptable, based on their properties. The next two
+sections give examples of how these policies are used.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |PPrrooppeerrttyy |DDeessccrriippttiioonn |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |noanonymous |Don't use mechanisms that permit anonymous authentication. |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |noplaintext |Don't use mechanisms that transmit unencrypted username and|
+ | |password information. |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |nodictionary|Don't use mechanisms that are vulnerable to dictionary |
+ | |attacks. |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |mutual_auth |Use only mechanisms that authenticate both the client and |
+ | |the server to each other. |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+UUnneennccrryypptteedd SSMMTTPP sseessssiioonn
+
+The default policy is stricter than that of the Postfix SMTP server - plaintext
+mechanisms are not allowed (nor is any anonymous mechanism):
+
+ /etc/postfix/main.cf:
+ smtp_sasl_security_options = noplaintext, noanonymous
+
+This default policy, which allows no plaintext passwords, leads to
+authentication failures if the remote server only offers plaintext
+authentication mechanisms (the SMTP server announces "AUTH PLAIN LOGIN"). In
+such cases the SMTP client will log the following error message:
+
+ SASL authentication failure: No worthy mechs found
+
+ NNoottee
+
+ This same error message will also be logged when the libplain.so or
+ liblogin.so modules are not installed in the /usr/lib/sasl2 directory.
+
+The insecure approach is to lower the security standards and permit plaintext
+authentication mechanisms:
+
+ /etc/postfix/main.cf:
+ smtp_sasl_security_options = noanonymous
+
+The more secure approach is to protect the plaintext username and password with
+TLS session encryption. To find out if the remote SMTP server supports TLS,
+connect to the server and see if it announces STARTTLS support as shown in the
+example. Information sent by the client (that is, you) is shown in bboolldd font.
+
+ % tteellnneett sseerrvveerr..eexxaammppllee..ccoomm 2255
+ ...
+ 220 server.example.com ESMTP Postfix
+ EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+ 250-server.example.com
+ 250-PIPELINING
+ 250-SIZE 10240000
+ 250-STARTTLS
+ ...
+
+Instead of port 25 (smtp), specify port 587 (submission) where appropriate.
+
+EEnnccrryypptteedd SSMMTTPP sseessssiioonn ((TTLLSS))
+
+To turn on TLS in the Postfix SMTP client, see TLS_README for configuration
+details.
+
+The smtp_sasl_tls_security_options parameter controls Postfix SASL mechanism
+policy during a TLS-encrypted SMTP session. The default is to copy the settings
+from the unencrypted session:
+
+ /etc/postfix/main.cf:
+ smtp_sasl_tls_security_options = $smtp_sasl_security_options
+
+A more sophisticated policy allows plaintext mechanisms, but only over a TLS-
+encrypted connection:
+
+ /etc/postfix/main.cf:
+ smtp_sasl_security_options = noanonymous, noplaintext
+ smtp_sasl_tls_security_options = noanonymous
+
+PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt ppoolliiccyy -- SSAASSLL mmeecchhaanniissmm nnaammeess
+
+Given the SASL security options of the previous section, the Cyrus SASL library
+will choose the most secure authentication mechanism that both the SMTP client
+and server implement. Unfortunately, that authentication mechanism may fail
+because the client or server is not configured to use that mechanism.
+
+To prevent this, the Postfix SMTP client can filter the names of the
+authentication mechanisms from the remote SMTP server. Used correctly, the
+filter hides unwanted mechanisms from the Cyrus SASL library, forcing the
+library to choose from the mechanisms the Postfix SMTP client filter passes
+through.
+
+The following example filters out everything but the mechanisms PLAIN and
+LOGIN:
+
+ /etc/postfix/main.cf:
+ smtp_sasl_mechanism_filter = plain, login
+
+ NNoottee
+
+ If the remote server does not offer any of the mechanisms on the filter
+ list, authentication will fail.
+
+We close this section with an example that passes every mechanism except for
+GSSAPI and LOGIN:
+
+ /etc/postfix/main.cf:
+ smtp_sasl_mechanism_filter = !gssapi, !login, static:all
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh SSAASSLL ssuuppppoorrtt
+
+As mentioned elsewhere, Postfix supports two SASL implementations: Cyrus SASL
+(SMTP client and server) and Dovecot SASL (SMTP server only). Both
+implementations can be built into Postfix simultaneously.
+
+ * Building Dovecot SASL support
+ * Building Cyrus SASL support
+
+BBuuiillddiinngg DDoovveeccoott SSAASSLL ssuuppppoorrtt
+
+These instructions assume that you build Postfix from source code as described
+in the INSTALL document. Some modification may be required if you build Postfix
+from a vendor-specific source package.
+
+Support for the Dovecot version 1 SASL protocol is available in Postfix 2.3 and
+later. At the time of writing, only server-side SASL support is available, so
+you can't use it to authenticate the Postfix SMTP client to your network
+provider's server.
+
+Dovecot uses its own daemon process for authentication. This keeps the Postfix
+build process simple, because there is no need to link extra libraries into
+Postfix.
+
+To generate the necessary Makefiles, execute the following in the Postfix top-
+level directory:
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==''--DDUUSSEE__SSAASSLL__AAUUTTHH \\
+ --DDDDEEFF__SSEERRVVEERR__SSAASSLL__TTYYPPEE==\\""ddoovveeccoott\\""''
+
+After this, proceed with "make" as described in the INSTALL document.
+
+NNoottee
+
+ * The -DDEF_SERVER_SASL_TYPE=\"dovecot\" is not necessary; it just makes
+ Postfix configuration a little more convenient because you don't have to
+ specify the SASL plug-in type in the Postfix main.cf file (but this may
+ cause surprises when you switch to a later Postfix version that is built
+ with the default SASL type of sasl).
+
+ * If you also want support for LDAP or TLS (or for Cyrus SASL), you need to
+ merge their CCARGS and AUXLIBS options into the above command line; see the
+ LDAP_README and TLS_README for details.
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==''--DDUUSSEE__SSAASSLL__AAUUTTHH \\
+ --DDDDEEFF__SSEERRVVEERR__SSAASSLL__TTYYPPEE==\\""ddoovveeccoott\\"" \\
+ ......CCCCAARRGGSS ooppttiioonnss ffoorr LLDDAAPP oorr TTLLSS eettcc........'' \\
+ AAUUXXLLIIBBSS==''......AAUUXXLLIIBBSS ooppttiioonnss ffoorr LLDDAAPP oorr TTLLSS eettcc........''
+
+BBuuiillddiinngg CCyyrruuss SSAASSLL ssuuppppoorrtt
+
+BBuuiillddiinngg tthhee CCyyrruuss SSAASSLL lliibbrraarryy
+
+Postfix works with cyrus-sasl-1.5.x or cyrus-sasl-2.1.x, which are available
+from ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/.
+
+ IImmppoorrttaanntt
+
+ If you install the Cyrus SASL libraries as per the default, you will have
+ to create a symlink /usr/lib/sasl -> /usr/local/lib/sasl for version 1.5.x
+ or /usr/lib/sasl2 -> /usr/local/lib/sasl2 for version 2.1.x.
+
+Reportedly, Microsoft Outlook (Express) requires the non-standard LOGIN and/or
+NTLM authentication mechanism. To enable these authentication mechanisms, build
+the Cyrus SASL libraries with:
+
+ % ..//ccoonnffiigguurree ----eennaabbllee--llooggiinn ----eennaabbllee--nnttllmm
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh CCyyrruuss SSAASSLL ssuuppppoorrtt
+
+These instructions assume that you build Postfix from source code as described
+in the INSTALL document. Some modification may be required if you build Postfix
+from a vendor-specific source package.
+
+The following assumes that the Cyrus SASL include files are in /usr/local/
+include, and that the Cyrus SASL libraries are in /usr/local/lib.
+
+On some systems this generates the necessary Makefile definitions:
+
+Cyrus SASL version 2.1.x
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH --DDUUSSEE__CCYYRRUUSS__SSAASSLL \\
+ --II//uussrr//llooccaall//iinncclluuddee//ssaassll"" AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb --llssaassll22""
+
+Cyrus SASL version 1.5.x
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH --DDUUSSEE__CCYYRRUUSS__SSAASSLL \\
+ --II//uussrr//llooccaall//iinncclluuddee"" AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb --llssaassll""
+
+On Solaris 2.x you need to specify run-time link information, otherwise the
+ld.so run-time linker will not find the SASL shared library:
+
+Cyrus SASL version 2.1.x
+
+ % mmaakkee ttiiddyy # remove left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH --DDUUSSEE__CCYYRRUUSS__SSAASSLL \\
+ --II//uussrr//llooccaall//iinncclluuddee//ssaassll"" AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb \\
+ --RR//uussrr//llooccaall//lliibb --llssaassll22""
+
+Cyrus SASL version 1.5.x
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__SSAASSLL__AAUUTTHH --DDUUSSEE__CCYYRRUUSS__SSAASSLL \\
+ --II//uussrr//llooccaall//iinncclluuddee"" AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb \\
+ --RR//uussrr//llooccaall//lliibb --llssaassll""
+
+UUssiinngg CCyyrruuss SSAASSLL vveerrssiioonn 11..55..xx
+
+Postfix supports Cyrus SASL version 1.x, but you shouldn't use it unless you
+are forced to. The makers of Cyrus SASL write:
+
+ This library is being deprecated and applications should transition to
+ using the SASLv2 library (source: Project Cyrus: Downloads).
+
+If you still need to set it up, here's a quick rundown:
+
+Read the regular section on SMTP server configurations for the Cyrus SASL
+framework. The differences are:
+
+ * Cyrus SASL version 1.5.x searches for configuration (smtpd.conf) in /usr/
+ lib/sasl/ only. You must place the configuration in that directory. Some
+ systems may have modified Cyrus SASL and put the files into e.g. /var/lib/
+ sasl/.
+
+ * Use the saslpasswd command instead of saslpasswd2 to create users in
+ sasldb.
+
+ * Use the sasldblistusers command instead of sasldblistusers2 to find users
+ in sasldb.
+
+ * In the smtpd.conf file you can't use mech_list to limit the range of
+ mechanisms offered. Instead, remove their libraries from /usr/lib/sasl/
+ (and remember remove those files again when a system update re-installs new
+ versions).
+
+CCrreeddiittss
+
+ * Postfix SASL support was originally implemented by Till Franke of SuSE
+ Rhein/Main AG.
+ * Wietse trimmed down the code to only the bare necessities.
+ * Support for Cyrus SASL version 2 was contributed by Jason Hoos.
+ * Liviu Daia added smtpd_sasl_application_name, separated
+ reject_sender_login_mismatch into
+ reject_authenticated_sender_login_mismatch and
+ reject_unauthenticated_sender_login_mismatch, and revised the docs.
+ * Wietse made another iteration through the code to add plug-in support for
+ multiple SASL implementations, and for reasons that have been lost, also
+ changed smtpd_sasl_application_name into smtpd_sasl_path.
+ * The Dovecot SMTP server-only plug-in was originally implemented by Timo
+ Sirainen of Procontrol, Finland.
+ * Patrick Ben Koetter revised this document for Postfix 2.4 and made much
+ needed updates.
+ * Patrick Ben Koetter revised this document again for Postfix 2.7 and made
+ much needed updates.
+
diff --git a/README_FILES/SCHEDULER_README b/README_FILES/SCHEDULER_README
new file mode 100644
index 0000000..a6f7702
--- /dev/null
+++ b/README_FILES/SCHEDULER_README
@@ -0,0 +1,1160 @@
+PPoossttffiixx QQuueeuuee SScchheedduulleerr
+
+-------------------------------------------------------------------------------
+
+DDiissccllaaiimmeerr
+
+Many of the transport-specific configuration parameters discussed in this
+document will not show up in "postconf" command output before Postfix version
+2.9. This limitation applies to many parameters whose name is a combination of
+a master.cf service name such as "relay" and a built-in suffix such as
+"_destination_concurrency_limit".
+
+OOvveerrvviieeww
+
+The queue manager is by far the most complex part of the Postfix mail system.
+It schedules delivery of new mail, retries failed deliveries at specific times,
+and removes mail from the queue after the last delivery attempt. There are two
+major classes of mechanisms that control the operation of the queue manager.
+
+Topics covered by this document:
+
+ * Concurrency scheduling, concerned with the number of concurrent deliveries
+ to a specific destination, including decisions on when to suspend
+ deliveries after persistent failures.
+ * Preemptive scheduling, concerned with the selection of email messages and
+ recipients for a given destination.
+ * Credits, something this document would not be complete without.
+
+CCoonnccuurrrreennccyy sscchheedduulliinngg
+
+The following sections document the Postfix 2.5 concurrency scheduler, after a
+discussion of the limitations of the earlier concurrency scheduler. This is
+followed by results of medium-concurrency experiments, and a discussion of
+trade-offs between performance and robustness.
+
+The material is organized as follows:
+
+ * Drawbacks of the existing concurrency scheduler
+ * Summary of the Postfix 2.5 concurrency feedback algorithm
+ * Summary of the Postfix 2.5 "dead destination" detection algorithm
+ * Pseudocode for the Postfix 2.5 concurrency scheduler
+ * Results for delivery to concurrency limited servers
+ * Discussion of concurrency limited server results
+ * Limitations of less-than-1 per delivery feedback
+ * Concurrency configuration parameters
+
+DDrraawwbbaacckkss ooff tthhee eexxiissttiinngg ccoonnccuurrrreennccyy sscchheedduulleerr
+
+From the start, Postfix has used a simple but robust algorithm where the per-
+destination delivery concurrency is decremented by 1 after delivery failed due
+to connection or handshake failure, and incremented by 1 otherwise. Of course
+the concurrency is never allowed to exceed the maximum per-destination
+concurrency limit. And when a destination's concurrency level drops to zero,
+the destination is declared "dead" and delivery is suspended.
+
+Drawbacks of +/-1 concurrency feedback per delivery are:
+
+ * Overshoot due to exponential delivery concurrency growth with each pseudo-
+ cohort(*). This can be an issue with high-concurrency channels. For
+ example, with the default initial concurrency of 5, concurrency would
+ proceed over time as (5-10-20).
+
+ * Throttling down to zero concurrency after a single pseudo-cohort(*)
+ failure. This was especially an issue with low-concurrency channels where a
+ single failure could be sufficient to mark a destination as "dead", causing
+ the suspension of further deliveries to the affected destination.
+
+(*) A pseudo-cohort is a number of delivery requests equal to a destination's
+delivery concurrency.
+
+The revised concurrency scheduler has a highly modular structure. It uses
+separate mechanisms for per-destination concurrency control and for "dead
+destination" detection. The concurrency control in turn is built from two
+separate mechanisms: it supports less-than-1 feedback per delivery to allow for
+more gradual concurrency adjustments, and it uses feedback hysteresis to
+suppress concurrency oscillations. And instead of waiting for delivery
+concurrency to throttle down to zero, a destination is declared "dead" after a
+configurable number of pseudo-cohorts reports connection or handshake failure.
+
+SSuummmmaarryy ooff tthhee PPoossttffiixx 22..55 ccoonnccuurrrreennccyy ffeeeeddbbaacckk aallggoorriitthhmm
+
+We want to increment a destination's delivery concurrency when some (not
+necessarily consecutive) number of deliveries complete without connection or
+handshake failure. This is implemented with positive feedback g(N) where N is
+the destination's delivery concurrency. With g(N)=1 feedback per delivery,
+concurrency increases by 1 after each positive feedback event; this gives us
+the old scheduler's exponential growth in time. With g(N)=1/N feedback per
+delivery, concurrency increases by 1 after an entire pseudo-cohort N of
+positive feedback reports; this gives us linear growth in time. Less-than-
+1 feedback per delivery and integer truncation naturally give us hysteresis, so
+that transitions to larger concurrency happen every 1/g(N) positive feedback
+events.
+
+We want to decrement a destination's delivery concurrency when some (not
+necessarily consecutive) number of deliveries complete after connection or
+handshake failure. This is implemented with negative feedback f(N) where N is
+the destination's delivery concurrency. With f(N)=1 feedback per delivery,
+concurrency decreases by 1 after each negative feedback event; this gives us
+the old scheduler's behavior where concurrency is throttled down dramatically
+after a single pseudo-cohort failure. With f(N)=1/N feedback per delivery,
+concurrency backs off more gently. Again, less-than-1 feedback per delivery and
+integer truncation naturally give us hysteresis, so that transitions to lower
+concurrency happen every 1/f(N) negative feedback events.
+
+However, with negative feedback we introduce a subtle twist. We "reverse" the
+negative hysteresis cycle so that the transition to lower concurrency happens
+at the bbeeggiinnnniinngg of a sequence of 1/f(N) negative feedback events. Otherwise, a
+correction for overload would be made too late. This makes the choice of f(N)
+relatively unimportant, as borne out by measurements later in this document.
+
+In summary, the main ingredients for the Postfix 2.5 concurrency feedback
+algorithm are a) the option of less-than-1 positive feedback per delivery to
+avoid overwhelming servers, b) the option of less-than-1 negative feedback per
+delivery to avoid giving up too fast, c) feedback hysteresis to avoid rapid
+oscillation, and d) a "reverse" hysteresis cycle for negative feedback, so that
+it can correct for overload quickly.
+
+SSuummmmaarryy ooff tthhee PPoossttffiixx 22..55 ""ddeeaadd ddeessttiinnaattiioonn"" ddeetteeccttiioonn aallggoorriitthhmm
+
+We want to suspend deliveries to a specific destination after some number of
+deliveries suffers connection or handshake failure. The old scheduler declares
+a destination "dead" when negative (-1) feedback throttles the delivery
+concurrency down to zero. With less-than-1 feedback per delivery, this
+throttling down would obviously take too long. We therefore have to separate
+"dead destination" detection from concurrency feedback. This is implemented by
+introducing the concept of pseudo-cohort failure. The Postfix 2.5 concurrency
+scheduler declares a destination "dead" after a configurable number of pseudo-
+cohorts suffers from connection or handshake failures. The old scheduler
+corresponds to the special case where the pseudo-cohort failure limit is equal
+to 1.
+
+PPsseeuuddooccooddee ffoorr tthhee PPoossttffiixx 22..55 ccoonnccuurrrreennccyy sscchheedduulleerr
+
+The pseudo code shows how the ideas behind new concurrency scheduler are
+implemented as of November 2007. The actual code can be found in the module
+qmgr/qmgr_queue.c.
+
+Types:
+ Each destination has one set of the following variables
+ int concurrency
+ double success
+ double failure
+ double fail_cohorts
+
+Feedback functions:
+ N is concurrency; x, y are arbitrary numbers in [0..1] inclusive
+ positive feedback: g(N) = x/N | x/sqrt(N) | x
+ negative feedback: f(N) = y/N | y/sqrt(N) | y
+
+Initialization:
+ concurrency = initial_concurrency
+ success = 0
+ failure = 0
+ fail_cohorts = 0
+
+After success:
+ fail_cohorts = 0
+ Be prepared for feedback > hysteresis, or rounding error
+ success += g(concurrency)
+ while (success >= 1) Hysteresis 1
+ concurrency += 1 Hysteresis 1
+ failure = 0
+ success -= 1 Hysteresis 1
+ Be prepared for overshoot
+ if (concurrency > concurrency limit)
+ concurrency = concurrency limit
+
+Safety:
+ Don't apply positive feedback unless
+ concurrency < busy_refcount + init_dest_concurrency
+ otherwise negative feedback effect could be delayed
+
+After failure:
+ if (concurrency > 0)
+ fail_cohorts += 1.0 / concurrency
+ if (fail_cohorts > cohort_failure_limit)
+ concurrency = 0
+ if (concurrency > 0)
+ Be prepared for feedback > hysteresis, rounding errors
+ failure -= f(concurrency)
+ while (failure < 0)
+ concurrency -= 1 Hysteresis 1
+ failure += 1 Hysteresis 1
+ success = 0
+ Be prepared for overshoot
+ if (concurrency < 1)
+ concurrency = 1
+
+RReessuullttss ffoorr ddeelliivveerryy ttoo ccoonnccuurrrreennccyy--lliimmiitteedd sseerrvveerrss
+
+Discussions about the concurrency scheduler redesign started early 2004, when
+the primary goal was to find alternatives that did not exhibit exponential
+growth or rapid concurrency throttling. No code was implemented until late
+2007, when the primary concern had shifted towards better handling of server
+concurrency limits. For this reason we measure how well the new scheduler does
+this job. The table below compares mail delivery performance of the old +/-
+1 feedback per delivery with several less-than-1 feedback functions, for
+different limited-concurrency server scenarios. Measurements were done with a
+FreeBSD 6.2 client and with FreeBSD 6.2 and various Linux servers.
+
+Server configuration:
+
+ * The mail flow was slowed down with 1 second latency per recipient
+ ("smtpd_client_restrictions = sleep 1"). The purpose was to make results
+ less dependent on hardware details, by avoiding slow-downs by queue file I/
+ O, logging I/O, and network I/O.
+ * Concurrency was limited by the server process limit ("default_process_limit
+ = 5" and "smtpd_client_event_limit_exceptions = static:all"). Postfix was
+ stopped and started after changing the process limit, because the same
+ number is also used as the backlog argument to the listen(2) system call,
+ and "postfix reload" does not re-issue this call.
+ * Mail was discarded with "local_recipient_maps = static:all" and
+ "local_transport = discard". The discard action in access maps or header/
+ body checks could not be used as it fails to update the in_flow_delay
+ counters.
+
+Client configuration:
+
+ * Queue file overhead was minimized by sending one message to a virtual alias
+ that expanded into 2000 different remote recipients. All recipients were
+ accounted for according to the maillog file. The
+ virtual_alias_expansion_limit setting was increased to avoid complaints
+ from the cleanup(8) server.
+ * The number of deliveries was maximized with
+ "smtp_destination_recipient_limit = 2". A smaller limit would cause Postfix
+ to schedule the concurrency per recipient instead of domain, which is not
+ what we want.
+ * Maximum concurrency was limited with "smtp_destination_concurrency_limit =
+ 20", and initial_destination_concurrency was set to the same value.
+ * The positive and negative concurrency feedback hysteresis was 1.
+ Concurrency was incremented by 1 at the END of 1/feedback steps of positive
+ feedback, and was decremented by 1 at the START of 1/feedback steps of
+ negative feedback.
+ * The SMTP client used the default 30s SMTP connect timeout and 300s SMTP
+ greeting timeout.
+
+IImmppaacctt ooff tthhee 3300ss SSMMTTPP ccoonnnneecctt ttiimmeeoouutt
+
+The first results are for a FreeBSD 6.2 server, where our artificially low
+listen(2) backlog results in a very short kernel queue for established
+connections. The table shows that all deferred deliveries failed due to a 30s
+connection timeout, and none failed due to a server greeting timeout. This
+measurement simulates what happens when the server's connection queue is
+completely full under load, and the TCP engine drops new connections.
+
+ cclliieenntt sseerrvveerr ffeeeeddbbaacckk ccoonnnneeccttiioonn ppeerrcceennttaaggee cclliieenntt ttiimmeedd--oouutt iinn
+ lliimmiitt lliimmiitt ssttyyllee ccaacchhiinngg ddeeffeerrrreedd ccoonnccuurrrreennccyy ccoonnnneecctt//
+ aavveerraaggee//ssttddddeevv ggrreeeettiinngg
+
+ -------------------------------------------------------------------------
+ 20 5 1/N no 9.9 19.4 0.49 198 -
+
+ 20 5 1/N yes 10.3 19.4 0.49 206 -
+
+ 20 5 1/sqrt(N) no 10.4 19.6 0.59 208 -
+
+ 20 5 1/sqrt(N) yes 10.6 19.6 0.61 212 -
+
+ 20 5 1 no 10.1 19.5 1.29 202 -
+
+ 20 5 1 yes 10.8 19.3 1.57 216 -
+
+ -------------------------------------------------------------------------
+
+ A busy server with a completely full connection queue. N is the client
+ delivery concurrency. Failed deliveries time out after 30s without
+ completing the TCP handshake. See text for a discussion of results.
+
+IImmppaacctt ooff tthhee 330000ss SSMMTTPP ggrreeeettiinngg ttiimmeeoouutt
+
+The next table shows results for a Fedora Core 8 server (results for RedHat 7.3
+are identical). In this case, the artificially small listen(2) backlog argument
+does not impact our measurement. The table shows that practically all deferred
+deliveries fail after the 300s SMTP greeting timeout. As these timeouts were
+10x longer than with the first measurement, we increased the recipient count
+(and thus the running time) by a factor of 10 to keep the results comparable.
+The deferred mail percentages are a factor 10 lower than with the first
+measurement, because the 1s per-recipient delay was 1/300th of the greeting
+timeout instead of 1/30th of the connection timeout.
+
+ cclliieenntt sseerrvveerr ffeeeeddbbaacckk ccoonnnneeccttiioonn ppeerrcceennttaaggee cclliieenntt ttiimmeedd--oouutt iinn
+ lliimmiitt lliimmiitt ssttyyllee ccaacchhiinngg ddeeffeerrrreedd ccoonnccuurrrreennccyy ccoonnnneecctt//
+ aavveerraaggee//ssttddddeevv ggrreeeettiinngg
+
+ -------------------------------------------------------------------------
+ 20 5 1/N no 1.16 19.8 0.37 - 230
+
+ 20 5 1/N yes 1.36 19.8 0.36 - 272
+
+ 20 5 1/sqrt(N) no 1.21 19.9 0.23 4 238
+
+ 20 5 1/sqrt(N) yes 1.36 20.0 0.23 - 272
+
+ 20 5 1 no 1.18 20.0 0.16 - 236
+
+ 20 5 1 yes 1.39 20.0 0.16 - 278
+
+ -------------------------------------------------------------------------
+
+ A busy server with a non-full connection queue. N is the client delivery
+ concurrency. Failed deliveries complete at the TCP level, but time out
+ after 300s while waiting for the SMTP greeting. See text for a discussion
+ of results.
+
+IImmppaacctt ooff aaccttiivvee sseerrvveerr ccoonnccuurrrreennccyy lliimmiitteerr
+
+The final concurrency-limited result shows what happens when SMTP connections
+don't time out, but are rejected immediately with the Postfix server's
+smtpd_client_connection_count_limit feature (the server replies with a 421
+status and disconnects immediately). Similar results can be expected with
+concurrency limiting features built into other MTAs or firewalls. For this
+measurement we specified a server concurrency limit and a client initial
+destination concurrency of 5, and a server process limit of 10; all other
+conditions were the same as with the first measurement. The same result would
+be obtained with a FreeBSD or Linux server, because the "pushing back" is done
+entirely by the receiving side.
+
+ cclliieenntt sseerrvveerr ffeeeeddbbaacckk ccoonnnneeccttiioonn ppeerrcceennttaaggee cclliieenntt tthheeoorreettiiccaall
+ lliimmiitt lliimmiitt ssttyyllee ccaacchhiinngg ddeeffeerrrreedd ccoonnccuurrrreennccyy ddeeffeerr rraattee
+ aavveerraaggee//ssttddddeevv
+
+ -------------------------------------------------------------------------
+ 20 5 1/N no 16.5 5.17 0.38 1/6
+
+ 20 5 1/N yes 16.5 5.17 0.38 1/6
+
+ 20 5 1/sqrt(N) no 24.5 5.28 0.45 1/4
+
+ 20 5 1/sqrt(N) yes 24.3 5.28 0.46 1/4
+
+ 20 5 1 no 49.7 5.63 0.67 1/2
+
+ 20 5 1 yes 49.7 5.68 0.70 1/2
+
+ -------------------------------------------------------------------------
+
+ A server with active per-client concurrency limiter that replies with 421
+ and disconnects. N is the client delivery concurrency. The theoretical
+ defer rate is 1/(1+roundup(1/feedback)). This is always 1/2 with the fixed
+ +/-1 feedback per delivery; with the concurrency-dependent feedback
+ variants, the defer rate decreases with increasing concurrency. See text
+ for a discussion of results.
+
+DDiissccuussssiioonn ooff ccoonnccuurrrreennccyy--lliimmiitteedd sseerrvveerr rreessuullttss
+
+All results in the previous sections are based on the first delivery runs only;
+they do not include any second etc. delivery attempts. It's also worth noting
+that the measurements look at steady-state behavior only. They don't show what
+happens when the client starts sending at a much higher or lower concurrency.
+
+The first two examples show that the effect of feedback is negligible when
+concurrency is limited due to congestion. This is because the initial
+concurrency is already at the client's concurrency maximum, and because there
+is 10-100 times more positive than negative feedback. Under these conditions,
+it is no surprise that the contribution from SMTP connection caching is also
+negligible.
+
+In the last example, the old +/-1 feedback per delivery will defer 50% of the
+mail when confronted with an active (anvil-style) server concurrency limit,
+where the server hangs up immediately with a 421 status (a TCP-level RST would
+have the same result). Less aggressive feedback mechanisms fare better than
+more aggressive ones. Concurrency-dependent feedback fares even better at
+higher concurrencies than shown here, but has limitations as discussed in the
+next section.
+
+LLiimmiittaattiioonnss ooff lleessss--tthhaann--11 ppeerr ddeelliivveerryy ffeeeeddbbaacckk
+
+Less-than-1 feedback is of interest primarily when sending large amounts of
+mail to destinations with active concurrency limiters (servers that reply with
+421, or firewalls that send RST). When sending small amounts of mail per
+destination, less-than-1 per-delivery feedback won't have a noticeable effect
+on the per-destination concurrency, because the number of deliveries to the
+same destination is too small. You might just as well use zero per-delivery
+feedback and stay with the initial per-destination concurrency. And when mail
+deliveries fail due to congestion instead of active concurrency limiters, the
+measurements above show that per-delivery feedback has no effect. With large
+amounts of mail you might just as well use zero per-delivery feedback and start
+with the maximal per-destination concurrency.
+
+The scheduler with less-than-1 concurrency feedback per delivery solves a
+problem with servers that have active concurrency limiters. This works only
+because feedback is handled in a peculiar manner: positive feedback will
+increment the concurrency by 1 at the eenndd of a sequence of events of length 1/
+feedback, while negative feedback will decrement concurrency by 1 at the
+bbeeggiinnnniinngg of such a sequence. This is how Postfix adjusts quickly for overshoot
+without causing lots of mail to be deferred. Without this difference in
+feedback treatment, less-than-1 feedback per delivery would defer 50% of the
+mail, and would be no better in this respect than the old +/-1 feedback per
+delivery.
+
+Unfortunately, the same feature that corrects quickly for concurrency overshoot
+also makes the scheduler more sensitive for noisy negative feedback. The reason
+is that one lonely negative feedback event has the same effect as a complete
+sequence of length 1/feedback: in both cases delivery concurrency is dropped by
+1 immediately. As a worst-case scenario, consider multiple servers behind a
+load balancer on a single IP address, and no backup MX address. When 1 out of K
+servers fails to complete the SMTP handshake or drops the connection, a
+scheduler with 1/N (N = concurrency) feedback stops increasing its concurrency
+once it reaches a concurrency level of about K, even though the good servers
+behind the load balancer are perfectly capable of handling more traffic.
+
+This noise problem gets worse as the amount of positive feedback per delivery
+gets smaller. A compromise is to use fixed less-than-1 positive feedback values
+instead of concurrency-dependent positive feedback. For example, to tolerate 1
+of 4 bad servers in the above load balancer scenario, use positive feedback of
+1/4 per "good" delivery (no connect or handshake error), and use an equal or
+smaller amount of negative feedback per "bad" delivery. The downside of using
+concurrency-independent feedback is that some of the old +/-1 feedback problems
+will return at large concurrencies. Sites that must deliver mail at non-trivial
+per-destination concurrencies will require special configuration.
+
+CCoonnccuurrrreennccyy ccoonnffiigguurraattiioonn ppaarraammeetteerrss
+
+The Postfix 2.5 concurrency scheduler is controlled with the following
+configuration parameters, where "transport_foo" provides a transport-specific
+parameter override. All parameter default settings are compatible with earlier
+Postfix versions.
+
+ PPaarraammeetteerr nnaammee PPoossttffiixx DDeessccrriippttiioonn
+ vveerrssiioonn
+
+ ---------------------------------------------------------------------------
+ Initial per-
+ initial_destination_concurrency all destination
+ transport_initial_destination_concurrency 2.5 delivery
+ concurrency
+
+ Maximum per-
+ default_destination_concurrency_limit all destination
+ transport_destination_concurrency_limit all delivery
+ concurrency
+
+ Per-
+ destination
+ positive
+ feedback
+ default_destination_concurrency_positive_feedback 2.5 amount, per
+ transport_destination_concurrency_positive_feedback 2.5 delivery that
+ does not fail
+ with
+ connection or
+ handshake
+ failure
+
+ Per-
+ destination
+ negative
+ feedback
+ default_destination_concurrency_negative_feedback 2.5 amount, per
+ transport_destination_concurrency_negative_feedback 2.5 delivery that
+ fails with
+ connection or
+ handshake
+ failure
+
+ Number of
+ failed
+ pseudo-
+ cohorts after
+ default_destination_concurrency_failed_cohort_limit 2.5 which a
+ transport_destination_concurrency_failed_cohort_limit 2.5 destination
+ is declared
+ "dead" and
+ delivery is
+ suspended
+
+ Enable
+ verbose
+ destination_concurrency_feedback_debug 2.5 logging of
+ concurrency
+ scheduler
+ activity
+
+ ---------------------------------------------------------------------------
+
+PPrreeeemmppttiivvee sscchheedduulliinngg
+
+The following sections describe the new queue manager and its preemptive
+scheduler algorithm. Note that the document was originally written to describe
+the changes between the new queue manager (in this text referred to as nqmgr,
+the name it was known by before it became the default queue manager) and the
+old queue manager (referred to as oqmgr). This is why it refers to oqmgr every
+so often.
+
+This document is divided into sections as follows:
+
+ * The structures used by nqmgr
+ * What happens when nqmgr picks up the message - how it is assigned to
+ transports, jobs, peers, entries
+ * How the entry selection works
+ * How the preemption works - what messages may be preempted and how and what
+ messages are chosen to preempt them
+ * How destination concurrency limits affect the scheduling algorithm
+ * Dealing with memory resource limits
+
+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
+elsewhere, but it is nice to have a coherent overview in one place:
+
+ * Each message structure represents one mail message which Postfix is to
+ deliver. The message recipients specify to what destinations is the message
+ to be delivered and what transports are going to be used for the delivery.
+
+ * Each recipient entry groups a batch of recipients of one message which are
+ all going to be delivered to the same destination (and over the same
+ transport).
+
+ * Each transport structure groups everything what is going to be delivered by
+ delivery agents dedicated for that transport. Each transport maintains a
+ 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
+ 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
+ (batches of message recipients) which shall be delivered to given
+ destination (the todo list), and a list of recipient entries already being
+ delivered by the delivery agents (the busy list).
+
+ * Each queue corresponds to multiple peer structures. Each peer structure is
+ like the queue structure, belonging to one transport and referencing one
+ destination. The difference is that it lists only the recipient entries
+ which all originate from the same message, unlike the queue structure,
+ whose entries may originate from various messages. For messages with few
+ recipients, there is usually just one recipient entry for each destination,
+ resulting in one recipient entry per peer. But for large mailing list
+ messages the recipients may need to be split to multiple recipient entries,
+ in which case the peer structure may list many entries for single
+ destination.
+
+ * Each transport job groups everything it takes to deliver one message via
+ its transport. Each job represents one message within the context of the
+ transport. The job belongs to one transport and message, so each message
+ may have multiple jobs, one for each transport. The job groups all the peer
+ structures, which describe the destinations the job's message has to be
+ delivered to.
+
+The first four structures are common to both nqmgr and oqmgr, the latter two
+were introduced by nqmgr.
+
+These terms are used extensively in the text below, feel free to look up the
+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.
+
+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
+basically the same as in oqmgr.
+
+Then for each triple which was bound to some queue (and thus transport), the
+program finds the job which represents the message within that transport's
+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.
+
+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.]
+
+HHooww tthhee eennttrryy sseelleeccttiioonn wwoorrkkss
+
+Having prepared all those above mentioned structures, the task of the nqmgr's
+scheduler is to choose the recipient entries one at a time and pass them to the
+delivery agent for corresponding transport. Now how does this work?
+
+The first approximation of the new scheduling algorithm is like this:
+
+ foreach transport (round-robin-by-transport)
+ do
+ if transport busy continue
+ if transport process limit reached continue
+ foreach transport's job (in the order of the transport's job list)
+ do
+ foreach job's peer (round-robin-by-destination)
+ if peer->queue->concurrency < peer->queue->window
+ return next peer entry.
+ done
+ done
+ done
+
+Now what is the "order of the transport's job list"? As we know already, the
+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.
+
+[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
+resource limits and no destination concurrency problems.]
+
+HHooww tthhee pprreeeemmppttiioonn wwoorrkkss
+
+As you might perhaps expect by now, the transport's job list does not remain
+sorted by the job's message enqueue time all the time. The most cool thing
+about nqmgr is not the simple FIFO delivery, but that it is able to slip mail
+with little recipients past the mailing-list bulk mail. This is what the job
+preemption is about - shuffling the jobs on the transport's job list to get the
+best message delivery rates. Now how is it achieved?
+
+First I have to tell you that there are in fact two job lists in each
+transport. One is the scheduler's job list, which the scheduler is free to play
+with, while the other one keeps the jobs always listed in the order of the
+enqueue time and is used for recipient pool management we will discuss later.
+For now, we will deal with the scheduler's job list only.
+
+So, we have the job list, which is first ordered by the time the jobs' messages
+were enqueued, oldest messages first, the most recently picked one at the end.
+For now, let's assume that there are no destination concurrency problems.
+Without preemption, we pick some entry of the first (oldest) job on the queue,
+assign it to delivery agent, pick another one from the same job, assign it
+again, and so on, until all the entries are used and the job is delivered. We
+would then move onto the next job and so on and on. Now how do we manage to
+sneak in some entries from the recently added jobs when the first job on the
+job list belongs to a message going to the mailing-list and has thousands of
+recipient entries?
+
+The nqmgr's answer is that we can artificially "inflate" the delivery time of
+that first job by some constant for free - it is basically the same trick you
+might remember as "accumulation of potential" from the amortized complexity
+lessons. For example, instead of delivering the entries of the first job on the
+job list every time a delivery agent becomes available, we can do it only every
+second time. If you view the moments the delivery agent becomes available on a
+timeline as "delivery slots", then instead of using every delivery slot for the
+first job, we can use only every other slot, and still the overall delivery
+efficiency of the first job remains the same. So the delivery 11112222 becomes
+1.1.1.1.2.2.2.2 (1 and 2 are the imaginary job numbers, . denotes the free
+slot). Now what do we do with free slots?
+
+As you might have guessed, we will use them for sneaking the mail with little
+recipients in. For example, if we have one four-recipient mail followed by four
+one recipients mail, the delivery sequence (that is, the sequence in which the
+jobs are assigned to the delivery slots) might look like this: 12131415. Hmm,
+fine for sneaking in the single recipient mail, but how do we sneak in the mail
+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
+the hundred-recipient mail is delivered, which really sucks.
+
+So, it becomes obvious that while inflating the message to get free slots is
+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?
+
+The key idea is that one does not have to generate the free slots in a uniform
+way. The delivery sequence 111...1 is no worse than 1.1.1.1, in fact, it is
+even better as some entries are in the first case selected earlier than in the
+second case, and none is selected later! So it is possible to first
+"accumulate" the free delivery slots and then use them all at once. It is even
+possible to accumulate some, then use them, then accumulate some more and use
+them again, as in 11..1.1 .
+
+Let's get back to the one hundred recipient example. We now know that we could
+first accumulate one hundred free slots, and only after then to preempt the
+first job and sneak the one hundred recipient mail in. Applying the algorithm
+recursively, we see the hundred recipient job can accumulate ten free delivery
+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.
+
+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
+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.]
+
+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
+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
+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
+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
+several times). In either case, we know how many are accumulated and how many
+are left to deliver, so we know how many it may yet accumulate at maximum.
+Every other job which may be delivered by less than that number of slots is a
+valid candidate for preemption. How do we choose among them?
+
+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.
+
+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
+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
+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
+answer to the last part of the original question - when does the preemption
+happen?
+
+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
+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
+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
+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
+mail, but it allows the small messages to be delivered sooner.
+
+The concept of these slot loans is where the transport_delivery_slot_discount
+and transport_delivery_slot_loan come from (they default to
+default_delivery_slot_discount and default_delivery_slot_loan, whose values are
+by default 50 and 3, respectively). The discount (resp. loan) specifies how
+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.
+
+[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
+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
+been said already. But I would be surprised if your mental image of the
+scheduler's functionality is not completely shattered once you start wondering
+how it works when not all recipients may be read in-core. More on that later.]
+
+HHooww ddeessttiinnaattiioonn ccoonnccuurrrreennccyy lliimmiittss aaffffeecctt tthhee sscchheedduulliinngg aallggoorriitthhmm
+
+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.
+
+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
+on its own and there are no knobs they would need to control it.
+
+From a programmer's point of view, the blocker jobs complicate the scheduler
+quite a lot. Without them, the jobs on the job list would be normally delivered
+in strict FIFO order. If the current job is preempted, the job preempting it is
+completely delivered unless it is preempted itself. Without blockers, the
+current job is thus always either the first job on the job list, or the top of
+the stack of jobs preempting the first job on the job list.
+
+The visualization of the job list and the preemption stack without blockers
+would be like this:
+
+ first job-> 1--2--3--5--6--8--... <- job list
+ on job list |
+ 4 <- preemption stack
+ |
+ current job-> 7
+
+In the example above we see that job 1 was preempted by job 4 and then job 4
+was preempted by job 7. After job 7 is completed, remaining entries of job 4
+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:
+
+ 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
+ before the job 7 becomes unblocked again. Or if both 7 and 4 are blocked,
+ then 1 is completed, then 7 becomes unblocked and is completed, then 2 is
+ 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
+ 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
+ destination limit allows selection of more recipient entries for that
+ destination), all jobs which have peers for that destination are unblocked
+ at once.]
+
+ 2. The idea of the preemption stack at the head of the job list is gone. That
+ is, it must be possible to preempt any job on the job list. For example, if
+ the jobs 7, 4, 1 and 2 in the example above become all blocked, job 3
+ becomes the current job. And of course we do not want the preemption to be
+ affected by the fact that there are some blocked jobs or not. Therefore, if
+ it turns out that job 3 might be preempted by job 6, the implementation
+ shall make it possible.
+
+ 3. The idea of the linear preemption stack itself is gone. It's no longer true
+ that one job is always preempted by only one job at one time (that is
+ directly preempted, not counting the recursively nested jobs). For example,
+ in the example above, job 1 is directly preempted by only job 4, and job 4
+ by job 7. Now assume job 7 becomes blocked, and job 4 is being delivered.
+ If it accumulates enough delivery slots, it is natural that it might be
+ preempted for example by job 8. Now job 4 is preempted by both job 7 AND
+ job 8 at the same time.
+
+Now combine the points 2) and 3) with point 1) again and you realize that the
+relations on the once linear job list became pretty complicated. If we extend
+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:
+
+ v- parent
+
+ adoptive parent -> 1--2--3--5--... <- "stack" level 0
+ | |
+ parent gone -> ? 6 <- "stack" level 1
+ / \
+ children -> 7 8 ^- child <- "stack" level 2
+
+ ^- siblings
+
+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:
+
+ 7--8--1--2--6--3--5--.. <- scheduler's job list order
+
+The job list order and the preemption parent/child/siblings relations are
+maintained separately. And because the selection works only with the job list,
+you can happily forget about those complicated relations unless you want to
+study the nqmgr sources. In that case the text above might provide some helpful
+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
+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.]
+
+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.
+
+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
+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.
+
+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
+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.
+
+The recipient limit complicates more things. First of all, the message reading
+code must support reading the recipients in batches, which among other things
+means accessing the queue file several times and continuing where the last
+recipient batch ended. This is invoked by the scheduler whenever the current
+job has space for more recipients, subject to transport's refill_limit and
+refill_delay parameters. It is also done any time when all in-core recipients
+of the message are dealt with (which may also mean they were deferred) but
+there are still more in the queue file.
+
+The second complication is that with some recipients left unread in the queue
+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.
+
+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
+that the job will be revived later, when another batch of recipients is read in
+core. It is also possible that some jobs will be created for the first time
+long after the first batch of recipients was read in core. The nqmgr code must
+be ready to handle all such situations.
+
+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
+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
+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
+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
+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.
+
+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
+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.
+
+Once the first batch of recipients was read in core and the message jobs were
+created, the size of the subsequent recipient batches (if any - of course it's
+best when all recipients are read in one batch) is based solely on the position
+of the message jobs on their corresponding transports' job lists. Each
+transport has a pool of transport_recipient_limit recipient slots which it can
+distribute among its jobs (how this is done is described later). The subsequent
+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.
+
+The above example illustrates several things which might be worth mentioning
+explicitly: first, note that although the per-transport slots are assigned to
+particular jobs, we can't guarantee that once the next batch of recipients is
+read in core, that the corresponding amounts of recipients will be assigned to
+those jobs. The jobs lend its slots to the message as a whole, so it is
+possible that some jobs end up sponsoring other jobs of their message. For
+example, if in the example above the 2 newly read recipients were assigned to
+the second job, the first job sponsored the second job with 2 slots. The second
+notable thing is the third job, which has more recipients in-core than it has
+slots. Apart from sponsoring by other job we just saw it can be result of the
+first recipient batch, which is sponsored from global recipient pool of
+qmgr_message_recipient_limit recipients. It can be also sponsored from the
+message recipient pool of qmgr_message_recipient_minimum recipients.
+
+Now how does each transport distribute the recipient slots among its jobs? The
+strategy is quite simple. As most scheduler activity happens on the head of the
+job list, it is our intention to make sure that the scheduler has the best
+estimates of the recipient counts for those jobs. As we mentioned above, this
+means that we want to try to make sure that the messages of those jobs have all
+recipients read in-core. Therefore the transport distributes the slots "along"
+the job list from start to end. In this case the job list sorted by message
+enqueue time is used, because it doesn't change over time as the scheduler's
+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)
+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
+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).
+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.
+
+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
+(if there are any). The jobs queued before this job are completely read (that
+is, all recipients of their message were already read in core) and have at
+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.
+
+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.
+Perhaps the only important things to know for most people are the following
+upper bound formulas:
+
+Each transport has at maximum
+
+ max(
+ qmgr_message_recipient_minimum * qmgr_message_active_limit
+ + *_recipient_limit + *_extra_recipient_limit,
+ qmgr_message_recipient_limit
+ )
+
+recipients in core.
+
+The total amount of recipients in core is
+
+ max(
+ qmgr_message_recipient_minimum * qmgr_message_active_limit
+ + sum( *_recipient_limit + *_extra_recipient_limit ),
+ qmgr_message_recipient_limit
+ )
+
+where the sum is over all used transports.
+
+And this terribly complicated chapter concludes the documentation of 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.]
+
+CCrreeddiittss
+
+ * Wietse Venema designed and implemented the initial queue manager with per-
+ domain FIFO scheduling, and per-delivery +/-1 concurrency feedback.
+ * Patrik Rak designed and implemented preemption where mail with fewer
+ recipients can slip past mail with more recipients in a controlled manner,
+ and wrote up its documentation.
+ * Wietse Venema initiated a discussion with Patrik Rak and Victor Duchovni on
+ alternatives for the +/-1 feedback scheduler's aggressive behavior. This is
+ when K/N feedback was reviewed (N = concurrency). The discussion ended
+ without a good solution for both negative feedback and dead site detection.
+ * Victor Duchovni resumed work on concurrency feedback in the context of
+ concurrency-limited servers.
+ * Wietse Venema then re-designed the concurrency scheduler in terms of the
+ simplest possible concepts: less-than-1 concurrency feedback per delivery,
+ forward and reverse concurrency feedback hysteresis, and pseudo-cohort
+ failure. At this same time, concurrency feedback was separated from dead
+ site detection.
+ * These simplifications, and their modular implementation, helped to develop
+ further insights into the different roles that positive and negative
+ concurrency feedback play, and helped to identify some worst-case
+ scenarios.
+
diff --git a/README_FILES/SMTPD_ACCESS_README b/README_FILES/SMTPD_ACCESS_README
new file mode 100644
index 0000000..2e7a92d
--- /dev/null
+++ b/README_FILES/SMTPD_ACCESS_README
@@ -0,0 +1,346 @@
+PPoossttffiixx SSMMTTPP rreellaayy aanndd aacccceessss ccoonnttrrooll
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+The Postfix SMTP server receives mail from the network and is exposed to the
+big bad world of junk email and viruses. This document introduces the built-in
+and external methods that control what SMTP mail Postfix will accept, what
+mistakes to avoid, and how to test your configuration.
+
+Topics covered in this document:
+
+ * Relay control, junk mail control, and per-user policies
+ * Restrictions that apply to all SMTP mail
+ * Getting selective with SMTP access restriction lists
+ * Delayed evaluation of SMTP access restriction lists
+ * Dangerous use of smtpd_recipient_restrictions
+ * SMTP access rule testing
+
+RReellaayy ccoonnttrrooll,, jjuunnkk mmaaiill ccoonnttrrooll,, aanndd ppeerr--uusseerr ppoolliicciieess
+
+In a distant past, the Internet was a friendly environment. Mail servers
+happily forwarded mail on behalf of anyone towards any destination. On today's
+Internet, spammers abuse servers that forward mail from arbitrary systems, and
+abused systems end up on anti-spammer blacklists. See, for example, the
+information on http://www.mail-abuse.org/ and other websites.
+
+By default, Postfix has a moderately restrictive approach to mail relaying.
+Postfix forwards mail only from clients in trusted networks, from clients that
+have authenticated with SASL, or to domains that are configured as authorized
+relay destinations. For a description of the default mail relay policy, see the
+smtpd_relay_restrictions parameter in the postconf(5) manual page, and the
+information that is referenced from there.
+
+ NOTE: Postfix versions before 2.10 did not have smtpd_relay_restrictions.
+ They combined the mail relay and spam blocking policies, under
+ smtpd_recipient_restrictions. This could lead to unexpected results. For
+ example, a permissive spam blocking policy could unexpectedly result in a
+ permissive mail relay policy. An example of this is documented under
+ "Dangerous use of smtpd_recipient_restrictions".
+
+Most of the Postfix SMTP server access controls are targeted at stopping junk
+email.
+
+ * Protocol oriented: some SMTP server access controls block mail by being
+ very strict with respect to the SMTP protocol; these catch poorly
+ implemented and/or poorly configured junk email software, as well as email
+ worms that come with their own non-standard SMTP client implementations.
+ Protocol-oriented access controls become less useful over time as spammers
+ and worm writers learn to read RFC documents.
+
+ * Blacklist oriented: some SMTP server access controls query blacklists with
+ known to be bad sites such as open mail relays, open web proxies, and home
+ computers that have been compromised and that are under remote control by
+ criminals. The effectiveness of these blacklists depends on how complete
+ and how up to date they are.
+
+ * Threshold oriented: some SMTP server access controls attempt to raise the
+ bar by either making the client do more work (greylisting) or by asking for
+ a second opinion (SPF and sender/recipient address verification). The
+ greylisting and SPF policies are implemented externally, and are the
+ subject of the SMTPD_POLICY_README document. Sender/recipient address
+ verification is the subject of the ADDRESS_VERIFICATION_README document.
+
+Unfortunately, all junk mail controls have the possibility of falsely rejecting
+legitimate mail. This can be a problem for sites with many different types of
+users. For some users it is unacceptable when any junk email slips through,
+while for other users the world comes to an end when a single legitimate email
+message is blocked. Because there is no single policy that is "right" for all
+users, Postfix supports different SMTP access restrictions for different users.
+This is described in the RESTRICTION_CLASS_README document.
+
+RReessttrriiccttiioonnss tthhaatt aappppllyy ttoo aallll SSMMTTPP mmaaiill
+
+Besides the restrictions that can be made configurable per client or per user
+as described in the next section, Postfix implements a few restrictions that
+apply to all SMTP mail.
+
+ * The built-in header_checks and body_checks content restrictions, as
+ described in the BUILTIN_FILTER_README document. This happens while Postfix
+ receives mail, before it is stored in the incoming queue.
+
+ * The external before-queue content restrictions, as described in the
+ SMTPD_PROXY_README document. This happens while Postfix receives mail,
+ before it is stored in the incoming queue.
+
+ * Requiring that the client sends the HELO or EHLO command before sending the
+ MAIL FROM or ETRN command. This may cause problems with home-grown
+ applications that send mail. For this reason, the requirement is disabled
+ by default ("smtpd_helo_required = no").
+
+ * Disallowing illegal syntax in MAIL FROM or RCPT TO commands. This may cause
+ problems with home-grown applications that send mail, and with ancient PC
+ mail clients. For this reason, the requirement is disabled by default
+ ("strict_rfc821_envelopes = no").
+
+ o Disallowing RFC 822 address syntax (example: "MAIL FROM: the dude
+ ").
+
+ o Disallowing addresses that are not enclosed with <> (example: "MAIL
+ FROM: dude@example.com").
+
+ * Rejecting mail from a non-existent sender address. This form of egress
+ filtering helps to slow down worms and other malware, but may cause
+ problems with home-grown software that sends out mail software with an
+ unreplyable address. For this reason the requirement is disabled by default
+ ("smtpd_reject_unlisted_sender = no").
+
+ * Rejecting mail for a non-existent recipient address. This form of ingress
+ filtering helps to keep the mail queue free of undeliverable MAILER-DAEMON
+ messages. This requirement is enabled by default
+ ("smtpd_reject_unlisted_recipient = yes").
+
+GGeettttiinngg sseelleeccttiivvee wwiitthh SSMMTTPP aacccceessss rreessttrriiccttiioonn lliissttss
+
+Postfix allows you to specify lists of access restrictions for each stage of
+the SMTP conversation. Individual restrictions are described in the postconf(5)
+manual page.
+
+Examples of simple restriction lists are:
+
+/etc/postfix/main.cf:
+ # Allow connections from trusted networks only.
+ smtpd_client_restrictions = permit_mynetworks, reject
+
+ # Don't talk to mail systems that don't know their own hostname.
+ # With Postfix < 2.3, specify reject_unknown_hostname.
+ smtpd_helo_restrictions = reject_unknown_helo_hostname
+
+ # Don't accept mail from domains that don't exist.
+ smtpd_sender_restrictions = reject_unknown_sender_domain
+
+ # Relay control (Postfix 2.10 and later): local clients and
+ # authenticated clients may specify any destination domain.
+ smtpd_relay_restrictions = permit_mynetworks,
+ permit_sasl_authenticated,
+ reject_unauth_destination
+
+ # Spam control: exclude local clients and authenticated clients
+ # from DNSBL lookups.
+ smtpd_recipient_restrictions = permit_mynetworks,
+ permit_sasl_authenticated,
+ # reject_unauth_destination is not needed here if the mail
+ # relay policy is specified under smtpd_relay_restrictions
+ # (available with Postfix 2.10 and later).
+ reject_unauth_destination
+ reject_rbl_client zen.spamhaus.org,
+ reject_rhsbl_reverse_client dbl.spamhaus.org,
+ reject_rhsbl_helo dbl.spamhaus.org,
+ reject_rhsbl_sender dbl.spamhaus.org
+
+ # Block clients that speak too early.
+ smtpd_data_restrictions = reject_unauth_pipelining
+
+ # Enforce mail volume quota via policy service callouts.
+ smtpd_end_of_data_restrictions = check_policy_service unix:private/policy
+
+Each restriction list is evaluated from left to right until some restriction
+produces a result of PERMIT, REJECT or DEFER (try again later). The end of each
+list is equivalent to a PERMIT result. By placing a PERMIT restriction before a
+REJECT restriction you can make exceptions for specific clients or users. This
+is called whitelisting; the fourth example above allows mail from local
+networks but otherwise rejects mail to arbitrary destinations.
+
+The table below summarizes the purpose of each SMTP access restriction list.
+All lists use the exact same syntax; they differ only in the time of evaluation
+and in the effect of a REJECT or DEFER result.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ | | | |EEffffeecctt ooff |
+ |RReessttrriiccttiioonn lliisstt nnaammee |VVeerrssiioonn|SSttaattuuss |RREEJJEECCTT oorr |
+ | | | |DDEEFFEERR |
+ | | | |rreessuulltt |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | | |Reject all |
+ |smtpd_client_restrictions |All |Optional |client |
+ | | | |commands |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | | |Reject |
+ |smtpd_helo_restrictions |All |Optional |HELO/EHLO |
+ | | | |information|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | | |Reject MAIL|
+ |smtpd_sender_restrictions |All |Optional |FROM |
+ | | | |information|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | |Required if | |
+ | |>= 2.10|smtpd_recipient_restrictions| |
+ | | |does not enforce relay |Reject RCPT|
+ |smtpd_relay_restrictions | |policy |TO |
+ | |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |information|
+ | | | | |
+ | |< 2.10 |Not available | |
+ | | | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | |Required if | |
+ | |>= 2.10|smtpd_relay_restrictions | |
+ | | |does not enforce relay |Reject RCPT|
+ |smtpd_recipient_restrictions | |policy |TO |
+ | |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |information|
+ | | | | |
+ | |< 2.10 |Required | |
+ | | | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ |smtpd_data_restrictions |>= 2.0 |Optional |Reject DATA|
+ | | | |command |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | | |Reject END-|
+ |smtpd_end_of_data_restrictions|>= 2.2 |Optional |OF-DATA |
+ | | | |command |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ |smtpd_etrn_restrictions |All |Optional |Reject ETRN|
+ | | | |command |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+
+DDeellaayyeedd eevvaalluuaattiioonn ooff SSMMTTPP aacccceessss rreessttrriiccttiioonn lliissttss
+
+Early Postfix versions evaluated SMTP access restrictions lists as early as
+possible. The client restriction list was evaluated before Postfix sent the
+"220 $myhostname..." greeting banner to the SMTP client, the helo restriction
+list was evaluated before Postfix replied to the HELO (EHLO) command, the
+sender restriction list was evaluated before Postfix replied to the MAIL FROM
+command, and so on. This approach turned out to be difficult to use.
+
+Current Postfix versions postpone the evaluation of client, helo and sender
+restriction lists until the RCPT TO or ETRN command. This behavior is
+controlled by the smtpd_delay_reject parameter. Restriction lists are still
+evaluated in the proper order of (client, helo, etrn) or (client, helo, sender,
+relay, recipient, data, or end-of-data) restrictions. When a restriction list
+(example: client) evaluates to REJECT or DEFER the restriction lists that
+follow (example: helo, sender, etc.) are skipped.
+
+Around the time that smtpd_delay_reject was introduced, Postfix was also
+changed to support mixed restriction lists that combine information about the
+client, helo, sender and recipient or etrn command.
+
+Benefits of delayed restriction evaluation, and of restriction mixing:
+
+ * Some SMTP clients do not expect a negative reply early in the SMTP session.
+ When the bad news is postponed until the RCPT TO reply, the client goes
+ away as it is supposed to, instead of hanging around until a timeout
+ happens, or worse, going into an endless connect-reject-connect loop.
+
+ * Postfix can log more useful information. For example, when Postfix rejects
+ a client name or address and delays the action until the RCPT TO command,
+ it can log the sender and the recipient address. This is more useful than
+ logging only the client hostname and IP address and not knowing whose mail
+ was being blocked.
+
+ * Mixing is needed for complex whitelisting policies. For example, in order
+ to reject local sender addresses in mail from non-local clients, you need
+ to be able to mix restrictions on client information with restrictions on
+ sender information in the same restriction list. Without this ability, many
+ per-user access restrictions would be impossible to express.
+
+DDaannggeerroouuss uussee ooff ssmmttppdd__rreecciippiieenntt__rreessttrriiccttiioonnss
+
+By now the reader may wonder why we need smtpd client, helo or sender
+restrictions, when their evaluation is postponed until the RCPT TO or ETRN
+command. Some people recommend placing ALL the access restrictions in the
+smtpd_recipient_restrictions list. Unfortunately, this can result in too
+permissive access. How is this possible?
+
+The purpose of the smtpd_recipient_restrictions feature is to control how
+Postfix replies to the RCPT TO command. If the restriction list evaluates to
+REJECT or DEFER, the recipient address is rejected; no surprises here. If the
+result is PERMIT, then the recipient address is accepted. And this is where
+surprises can happen.
+
+The problem is that Postfix versions before 2.10 did not have
+smtpd_relay_restrictions. They combined the mail relay and spam blocking
+policies, under smtpd_recipient_restrictions. The result is that a permissive
+spam blocking policy could unexpectedly result in a permissive mail relay
+policy.
+
+Here is an example that shows when a PERMIT result can result in too much
+access permission:
+
+1 /etc/postfix/main.cf:
+2 smtpd_recipient_restrictions =
+3 permit_mynetworks
+4 check_helo_access hash:/etc/postfix/helo_access
+5 reject_unknown_helo_hostname
+6 rreejjeecctt__uunnaauutthh__ddeessttiinnaattiioonn
+7
+8 /etc/postfix/helo_access:
+9 localhost.localdomain PERMIT
+
+Line 5 rejects mail from hosts that don't specify a proper hostname in the HELO
+command (with Postfix < 2.3, specify reject_unknown_hostname). Lines 4 and 9
+make an exception to allow mail from some machine that announces itself with
+"HELO localhost.localdomain".
+
+The problem with this configuration is that smtpd_recipient_restrictions
+evaluates to PERMIT for EVERY host that announces itself as
+"localhost.localdomain", making Postfix an open relay for all such hosts.
+
+With Postfix before version 2.10 you should place non-recipient restrictions
+AFTER the reject_unauth_destination restriction, not before. In the above
+example, the HELO based restrictions should be placed AFTER
+reject_unauth_destination, or better, the HELO based restrictions should be
+placed under smtpd_helo_restrictions where they can do no harm.
+
+1 /etc/postfix/main.cf:
+2 smtpd_recipient_restrictions =
+3 permit_mynetworks
+4 rreejjeecctt__uunnaauutthh__ddeessttiinnaattiioonn
+5 check_helo_access hash:/etc/postfix/helo_access
+6 reject_unknown_helo_hostname
+7
+8 /etc/postfix/helo_access:
+9 localhost.localdomain PERMIT
+
+The above mistake will not happen with Postfix 2.10 and later, when the relay
+policy is specified under smtpd_relay_restrictions, and the spam blocking
+policy under smtpd_recipient_restrictions. Then, a permissive spam blocking
+policy will not result in a permissive mail relay policy.
+
+SSMMTTPP aacccceessss rruullee tteessttiinngg
+
+Postfix has several features that aid in SMTP access rule testing:
+
+soft_bounce
+ This is a safety net that changes SMTP server REJECT actions into DEFER
+ (try again later) actions. This keeps mail queued that would otherwise be
+ returned to the sender. Specify "soft_bounce = yes" in the main.cf file to
+ prevent the Postfix SMTP server from rejecting mail permanently, by
+ changing all 5xx SMTP reply codes into 4xx.
+
+warn_if_reject
+ When placed before a reject-type restriction, access table query, or
+ check_policy_service query, this logs a "reject_warning" message instead of
+ rejecting a request (when a reject-type restriction fails due to a
+ temporary error, this logs a "reject_warning" message for any implicit
+ "defer_if_permit" actions that would normally prevent mail from being
+ accepted by some later access restriction). This feature has no effect on
+ defer_if_reject restrictions.
+
+XCLIENT
+ With this feature, an authorized SMTP client can impersonate other systems
+ and perform realistic SMTP access rule tests. Examples of how to
+ impersonate other systems for access rule testing are given at the end of
+ the XCLIENT_README document.
+ This feature is available in Postfix 2.1.
+
diff --git a/README_FILES/SMTPD_POLICY_README b/README_FILES/SMTPD_POLICY_README
new file mode 100644
index 0000000..51c1df2
--- /dev/null
+++ b/README_FILES/SMTPD_POLICY_README
@@ -0,0 +1,622 @@
+PPoossttffiixx SSMMTTPP AAcccceessss PPoolliiccyy DDeelleeggaattiioonn
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff PPoossttffiixx SSMMTTPP aacccceessss ppoolliiccyy ddeelleeggaattiioonn
+
+The Postfix SMTP server has a number of built-in mechanisms to block or accept
+mail at specific SMTP protocol stages. In addition, the Postfix SMTP server can
+delegate decisions to an external policy server (Postfix 2.1 and later).
+
+With this policy delegation mechanism, a simple greylist policy can be
+implemented with only a dozen lines of Perl, as is shown at the end of this
+document. A complete example can be found in the Postfix source code, in the
+directory examples/smtpd-policy.
+
+Another example of policy delegation is the SPF policy server at http://
+www.openspf.org/Software.
+
+Policy delegation is now the preferred method for adding policies to Postfix.
+It's much easier to develop a new feature in few lines of Perl, Python, Ruby,
+or TCL, than trying to do the same in C code. The difference in performance
+will be unnoticeable except in the most demanding environments. On active
+systems a policy daemon process is used multiple times, for up to $max_use
+incoming SMTP connections.
+
+This document covers the following topics:
+
+ * Policy protocol description
+ * Simple policy client/server configuration
+ * Advanced policy client configuration
+ * Example: greylist policy server
+ * Greylisting mail from frequently forged domains
+ * Greylisting all your mail
+ * Routine greylist maintenance
+ * Example Perl greylist server
+
+PPrroottooccooll ddeessccrriippttiioonn
+
+The Postfix policy delegation protocol is really simple. The client request is
+a sequence of name=value attributes separated by newline, and is terminated by
+an empty line. The server reply is one name=value attribute and it, too, is
+terminated by an empty line.
+
+Here is an example of all the attributes that the Postfix SMTP server sends in
+a delegated SMTPD access policy request:
+
+ PPoossttffiixx vveerrssiioonn 22..11 aanndd llaatteerr::
+ request=smtpd_access_policy
+ protocol_state=RCPT
+ protocol_name=SMTP
+ helo_name=some.domain.tld
+ queue_id=8045F2AB23
+ sender=foo@bar.tld
+ recipient=bar@foo.tld
+ recipient_count=0
+ client_address=1.2.3.4
+ client_name=another.domain.tld
+ reverse_client_name=another.domain.tld
+ instance=123.456.7
+ PPoossttffiixx vveerrssiioonn 22..22 aanndd llaatteerr::
+ sasl_method=plain
+ sasl_username=you
+ sasl_sender=
+ size=12345
+ ccert_subject=solaris9.porcupine.org
+ ccert_issuer=Wietse+20Venema
+ ccert_fingerprint=C2:9D:F4:87:71:73:73:D9:18:E7:C2:F3:C1:DA:6E:04
+ PPoossttffiixx vveerrssiioonn 22..33 aanndd llaatteerr::
+ encryption_protocol=TLSv1/SSLv3
+ encryption_cipher=DHE-RSA-AES256-SHA
+ encryption_keysize=256
+ etrn_domain=
+ PPoossttffiixx vveerrssiioonn 22..55 aanndd llaatteerr::
+ stress=
+ PPoossttffiixx vveerrssiioonn 22..99 aanndd llaatteerr::
+ ccert_pubkey_fingerprint=68:B3:29:DA:98:93:E3:40:99:C7:D8:AD:5C:B9:C9:40
+ PPoossttffiixx vveerrssiioonn 33..00 aanndd llaatteerr::
+ client_port=1234
+ PPoossttffiixx vveerrssiioonn 33..11 aanndd llaatteerr::
+ policy_context=submission
+ [empty line]
+
+Notes:
+
+ * The "request" attribute is required. In this example the request type is
+ "smtpd_access_policy".
+
+ * The order of the attributes does not matter. The policy server should
+ ignore any attributes that it does not care about.
+
+ * When the same attribute name is sent more than once, the server may keep
+ the first value or the last attribute value.
+
+ * When an attribute value is unavailable, the client either does not send the
+ attribute, sends the attribute with an empty value ("name="), or sends a
+ zero value ("name=0") in the case of a numerical attribute.
+
+ * The "recipient" attribute is available in the "RCPT TO" stage. It is also
+ available in the "DATA" and "END-OF-MESSAGE" stages if Postfix accepted
+ only one recipient for the current message.
+
+ * The "recipient_count" attribute (Postfix 2.3 and later) is non-zero only in
+ the "DATA" and "END-OF-MESSAGE" stages. It specifies the number of
+ recipients that Postfix accepted for the current message.
+
+ * The client address is an IPv4 dotted quad in the form 1.2.3.4 or it is an
+ IPv6 address in the form 1:2:3::4:5:6.
+
+ * For a discussion of the differences between reverse and verified
+ client_name information, see the reject_unknown_client_hostname discussion
+ in the postconf(5) document.
+
+ * An attribute name must not contain "=", null or newline, and an attribute
+ value must not contain null or newline.
+
+ * The "instance" attribute value can be used to correlate different requests
+ regarding the same message delivery. These requests are sent over the same
+ policy connection (unless the policy daemon terminates the connection).
+ Once Postfix sends a query with a different instance attribute over that
+ same policy connection, the previous message delivery is either completed
+ or aborted.
+
+ * The "size" attribute value specifies the message size that the client
+ specified in the MAIL FROM command (zero if none was specified). With
+ Postfix 2.2 and later, it specifies the actual message size when the client
+ sends the END-OF-DATA command.
+
+ * The "sasl_*" attributes (Postfix 2.2 and later) specify information about
+ how the client was authenticated via SASL. These attributes are empty in
+ case of no SASL authentication.
+
+ * The "ccert_*" attributes (Postfix 2.2 and later) specify information about
+ how the client was authenticated via TLS. These attributes are empty in
+ case of no certificate authentication. As of Postfix 2.2.11 these attribute
+ values are encoded as xtext: some characters are represented by +XX, where
+ XX is the two-digit hexadecimal representation of the character value. With
+ Postfix 2.6 and later, the decoded string is an UTF-8 string without non-
+ printable ASCII characters.
+
+ * The "encryption_*" attributes (Postfix 2.3 and later) specify information
+ about how the connection is encrypted. With plaintext connections the
+ protocol and cipher attributes are empty and the keysize is zero.
+
+ * The "etrn_domain" attribute is defined only in the context of the ETRN
+ command, and specifies the ETRN command parameter.
+
+ * The "stress" attribute is either empty or "yes". See the STRESS_README
+ document for further information.
+
+ * The "policy_context" attribute provides a way to pass information that is
+ not available via other attributes (Postfix version 3.1 and later).
+
+The following is specific to SMTPD delegated policy requests:
+
+ * Protocol names are ESMTP or SMTP.
+
+ * Protocol states are CONNECT, EHLO, HELO, MAIL, RCPT, DATA, END-OF-MESSAGE,
+ VRFY or ETRN; these are the SMTP protocol states where the Postfix SMTP
+ server makes an OK/REJECT/HOLD/etc. decision.
+
+The policy server replies with any action that is allowed in a Postfix SMTPD
+access(5) table. Example:
+
+ action=defer_if_permit Service temporarily unavailable
+ [empty line]
+
+This causes the Postfix SMTP server to reject the request with a 450 temporary
+error code and with text "Service temporarily unavailable", if the Postfix SMTP
+server finds no reason to reject the request permanently.
+
+In case of trouble the policy server must not send a reply. Instead the server
+must log a warning and disconnect. Postfix will retry the request at some later
+time.
+
+SSiimmppllee ppoolliiccyy cclliieenntt//sseerrvveerr ccoonnffiigguurraattiioonn
+
+The Postfix delegated policy client can connect to a TCP socket or to a UNIX-
+domain socket. Examples:
+
+ inet:127.0.0.1:9998
+ unix:/some/where/policy
+ unix:private/policy
+
+The first example specifies that the policy server listens on a TCP socket at
+127.0.0.1 port 9998. The second example specifies an absolute pathname of a
+UNIX-domain socket. The third example specifies a pathname relative to the
+Postfix queue directory; use this for policy servers that are spawned by the
+Postfix master daemon.
+
+To create a policy service that listens on a UNIX-domain socket called
+"policy", and that runs under control of the Postfix spawn(8) daemon, you would
+use something like this:
+
+ 1 /etc/postfix/master.cf:
+ 2 policy unix - n n - 0 spawn
+ 3 user=nobody argv=/some/where/policy-server
+ 4
+ 5 /etc/postfix/main.cf:
+ 6 smtpd_recipient_restrictions =
+ 7 ...
+ 8 reject_unauth_destination
+ 9 check_policy_service unix:private/policy
+ 10 ...
+ 11 policy_time_limit = 3600
+ 12 # smtpd_policy_service_request_limit = 1
+
+NOTES:
+
+ * Lines 2-3: this creates the service called "policy" that listens on a UNIX-
+ domain socket. The service is implemented by the Postfix spawn(8) daemon,
+ which executes the policy server program that is specified with the aarrggvv
+ attribute, using the privileges specified with the uusseerr attribute.
+
+ * Line 2: specify a "0" process limit instead of the default "-", to avoid
+ "connection refused" and other problems when you increase the smtpd process
+ limit.
+
+ * Line 8: reject_unauth_destination is not needed here if the mail relay
+ policy is specified with smtpd_relay_restrictions (available with Postfix
+ 2.10 and later).
+
+ * Lines 8, 9: always specify "check_policy_service" AFTER
+ "reject_unauth_destination" or else your system could become an open relay.
+
+ * Line 11: this increases the time that a policy server process may run to
+ 3600 seconds. The default time limit of 1000 seconds is too short; the
+ policy daemon needs to run long as the SMTP server process that talks to
+ it. See the spawn(8) manpage for more information about the
+ transport_time_limit parameter.
+
+ Note: the "policy_time_limit" parameter will not show up in "postconf"
+ command output before Postfix version 2.9. This limitation applies to
+ many parameters whose name is a combination of a master.cf service name
+ (in the above example, "policy") and a built-in suffix (in the above
+ example: "_time_limit").
+
+ * Line 12: specify smtpd_policy_service_request_limit to avoid error-recovery
+ delays with policy servers that cannot maintain a persistent connection.
+
+ * With Solaris < 9, or Postfix < 2.10 on any Solaris version, use TCP sockets
+ instead of UNIX-domain sockets:
+
+ 1 /etc/postfix/master.cf:
+ 2 127.0.0.1:9998 inet n n n - 0 spawn
+ 3 user=nobody argv=/some/where/policy-server
+ 4
+ 5 /etc/postfix/main.cf:
+ 6 smtpd_recipient_restrictions =
+ 7 ...
+ 8 reject_unauth_destination
+ 9 check_policy_service inet:127.0.0.1:9998
+ 10 ...
+ 11 127.0.0.1:9998_time_limit = 3600
+ 12 # smtpd_policy_service_request_limit = 1
+
+Configuration parameters that control the client side of the policy delegation
+protocol:
+
+ * smtpd_policy_service_default_action (default: 451 4.3.5 Server
+ configuration problem): The default action when an SMTPD policy service
+ request fails. Available with Postfix 3.0 and later.
+
+ * smtpd_policy_service_max_idle (default: 300s): The amount of time before
+ the Postfix SMTP server closes an unused policy client connection.
+
+ * smtpd_policy_service_max_ttl (default: 1000s): The amount of time before
+ the Postfix SMTP server closes an active policy client connection.
+
+ * smtpd_policy_service_request_limit (default: 0): The maximal number of
+ requests per policy connection, or zero (no limit). Available with Postfix
+ 3.0 and later.
+
+ * smtpd_policy_service_timeout (default: 100s): The time limit to connect to,
+ send to or receive from a policy server.
+
+ * smtpd_policy_service_try_limit (default: 2): The maximal number of attempts
+ to send an SMTPD policy service request before giving up. Available with
+ Postfix 3.0 and later.
+
+ * smtpd_policy_service_retry_delay (default: 1s): The delay between attempts
+ to resend a failed SMTPD policy service request. Available with Postfix 3.0
+ and later.
+
+ * smtpd_policy_service_policy_context (default: empty): Optional information
+ that is passed in the "policy_context" attribute of an SMTPD policy service
+ request (originally, to share the same SMTPD service endpoint among
+ multiple check_policy_service clients). Available with Postfix 3.1 and
+ later.
+
+Configuration parameters that control the server side of the policy delegation
+protocol:
+
+ * transport_time_limit ($command_time_limit): The maximal amount of time the
+ policy daemon is allowed to run before it is terminated. The transport is
+ the service name of the master.cf entry for the policy daemon service. In
+ the above examples, the service name is "policy" or "127.0.0.1:9998".
+
+AAddvvaanncceedd ppoolliiccyy cclliieenntt ccoonnffiigguurraattiioonn
+
+The previous section lists a number of Postfix main.cf parameters that control
+time limits and other settings for all policy clients. This is sufficient for
+simple configurations. With more complex configurations it becomes desirable to
+have different settings per policy client. This is supported with Postfix 3.0
+and later.
+
+The following example shows a "non-critical" policy service with a short
+timeout, and with "DUNNO" as default action when the service is unvailable. The
+"DUNNO" action causes Postfix to ignore the result.
+
+ 1 /etc/postfix/main.cf:
+ 2 smtpd_recipient_restrictions =
+ 3 ...
+ 4 reject_unauth_destination
+ 5 check_policy_service { inet:host:port,
+ 6 timeout=10s, default_action=DUNNO }
+ 8 ...
+
+Instead of a server endpoint, we now have a list enclosed in {}.
+
+ * Line 5: The first item in the list is the server endpoint. This supports
+ the exact same "inet" and "unix" syntax as described earlier.
+
+ * Line 6: The remainder of the list contains per-client settings. These
+ settings override global main.cf parameters, and have the same name as
+ those parameters, without the "smtpd_policy_service_" prefix.
+
+Inside the list, syntax is similar to what we already know from main.cf: items
+separated by space or comma. There is one difference: yyoouu mmuusstt eenncclloossee aa
+sseettttiinngg iinn ppaarreenntthheesseess,, aass iinn ""{{ nnaammee == vvaalluuee }}"",, iiff yyoouu wwaanntt ttoo hhaavvee ssppaaccee oorr
+ccoommmmaa wwiitthhiinn aa vvaalluuee oorr aarroouunndd ""=="". This comes in handy when different policy
+servers require different default actions with different SMTP status codes or
+text:
+
+ 1 /etc/postfix/main.cf:
+ 2 smtpd_recipient_restrictions =
+ 3 ...
+ 4 reject_unauth_destination
+ 5 check_policy_service {
+ 6 inet:host:port1,
+ 7 { default_action = 451 4.3.5 See http://www.example.com/
+ support1 }
+ 8 }
+ 9 ...
+
+EExxaammppllee:: ggrreeyylliisstt ppoolliiccyy sseerrvveerr
+
+Greylisting is a defense against junk email that is described at http://
+www.greylisting.org/. The idea was discussed on the postfix-users mailing list
+one year before it was popularized.
+
+The file examples/smtpd-policy/greylist.pl in the Postfix source tree
+implements a simplified greylist policy server. This server stores a time stamp
+for every (client, sender, recipient) triple. By default, mail is not accepted
+until a time stamp is more than 60 seconds old. This stops junk mail with
+randomly selected sender addresses, and mail that is sent through randomly
+selected open proxies. It also stops junk mail from spammers that change their
+IP address frequently.
+
+Copy examples/smtpd-policy/greylist.pl to /usr/libexec/postfix or whatever
+location is appropriate for your system.
+
+In the greylist.pl Perl script you need to specify the location of the greylist
+database file, and how long mail will be delayed before it is accepted. The
+default settings are:
+
+ $database_name="/var/mta/greylist.db";
+ $greylist_delay=60;
+
+The /var/mta directory (or whatever you choose) should be writable by "nobody",
+or by whatever username you configure below in master.cf for the policy
+service.
+
+Example:
+
+ # mkdir /var/mta
+ # chown nobody /var/mta
+
+Note: DO NOT create the greylist database in a world-writable directory such as
+/tmp or /var/tmp, and DO NOT create the greylist database in a file system that
+may run out of space. Postfix can survive "out of space" conditions with the
+mail queue and with the mailbox store, but it cannot survive a corrupted
+greylist database. If the file becomes corrupted you may not be able to receive
+mail at all until you delete the file by hand.
+
+The greylist.pl Perl script can be run under control by the Postfix master
+daemon. For example, to run the script as user "nobody", using a UNIX-domain
+socket that is accessible by Postfix processes only:
+
+ 1 /etc/postfix/master.cf:
+ 2 greylist unix - n n - 0 spawn
+ 3 user=nobody argv=/usr/bin/perl /usr/libexec/postfix/greylist.pl
+ 4
+ 5 /etc/postfix/main.cf:
+ 6 greylist_time_limit = 3600
+ 7 smtpd_recipient_restrictions =
+ 8 ...
+ 9 reject_unauth_destination
+ 10 check_policy_service unix:private/greylist
+ 11 ...
+ 12 # smtpd_policy_service_request_limit = 1
+
+Notes:
+
+ * Lines 2-3: this creates the service called "greylist" that listens on a
+ UNIX-domain socket. The service is implemented by the Postfix spawn(8)
+ daemon, which executes the greylist.pl script that is specified with the
+ aarrggvv attribute, using the privileges specified with the uusseerr attribute.
+
+ * Line 2: specify a "0" process limit instead of the default "-", to avoid
+ "connection refused" and other problems when you increase the smtpd process
+ limit.
+
+ * Line 3: Specify "greylist.pl -v" for verbose logging of each request and
+ reply.
+
+ * Line 6: this increases the time that a greylist server process may run to
+ 3600 seconds. The default time limit of 1000 seconds is too short; the
+ greylist daemon needs to run long as the SMTP server process that talks to
+ it. See the spawn(8) manpage for more information about the
+ transport_time_limit parameter.
+
+ * Line 9: reject_unauth_destination is not needed here if the mail relay
+ policy is specified with smtpd_relay_restrictions (available with Postfix
+ 2.10 and later).
+
+ Note: the "greylist_time_limit" parameter will not show up in
+ "postconf" command output before Postfix version 2.9. This limitation
+ applies to many parameters whose name is a combination of a master.cf
+ service name (in the above example, "greylist") and a built-in suffix
+ (in the above example: "_time_limit").
+
+ * Line 12: specify smtpd_policy_service_request_limit to avoid error-recovery
+ delays with policy servers that cannot maintain a persistent connection.
+
+With Solaris < 9, or Postfix < 2.10 on any Solaris version, use inet: style
+sockets instead of unix: style, as detailed in the "Policy client/server
+configuration" section above.
+
+ 1 /etc/postfix/master.cf:
+ 2 127.0.0.1:9998 inet n n n - 0 spawn
+ 3 user=nobody argv=/usr/bin/perl /usr/libexec/postfix/greylist.pl
+ 4
+ 5 /etc/postfix/main.cf:
+ 6 127.0.0.1:9998_time_limit = 3600
+ 7 smtpd_recipient_restrictions =
+ 8 ...
+ 9 reject_unauth_destination
+ 10 check_policy_service inet:127.0.0.1:9998
+ 11 ...
+ 12 # smtpd_policy_service_request_limit = 1
+
+GGrreeyylliissttiinngg mmaaiill ffrroomm ffrreeqquueennttllyy ffoorrggeedd ddoommaaiinnss
+
+It is relatively safe to turn on greylisting for specific domains that often
+appear in forged email. At some point in cyberspace/time a list of frequently
+forged MAIL FROM domains could be found at http://www.monkeys.com/anti-spam/
+filtering/sender-domain-validate.in.
+
+ 1 /etc/postfix/main.cf:
+ 2 smtpd_recipient_restrictions =
+ 3 reject_unlisted_recipient
+ 4 ...
+ 5 reject_unauth_destination
+ 6 check_sender_access hash:/etc/postfix/sender_access
+ 7 ...
+ 8 smtpd_restriction_classes = greylist
+ 9 greylist = check_policy_service unix:private/greylist
+ 10
+ 11 /etc/postfix/sender_access:
+ 12 aol.com greylist
+ 13 hotmail.com greylist
+ 14 bigfoot.com greylist
+ 15 ... etcetera ...
+
+NOTES:
+
+ * Line 9: On Solaris < 9, or Postfix < 2.10 on any Solaris version, use inet:
+ style sockets instead of unix: style, as detailed in the "Example: greylist
+ policy server" section above.
+
+ * Line 5: reject_unauth_destination is not needed here if the mail relay
+ policy is specified with smtpd_relay_restrictions (available with Postfix
+ 2.10 and later).
+
+ * Line 6: Be sure to specify "check_sender_access" AFTER
+ "reject_unauth_destination" or else your system could become an open mail
+ relay.
+
+ * Line 3: With Postfix 2.0 snapshot releases, "reject_unlisted_recipient" is
+ called "check_recipient_maps". Postfix 2.1 understands both forms.
+
+ * Line 3: The greylist database gets polluted quickly with bogus addresses.
+ It helps if you protect greylist lookups with other restrictions that
+ reject unknown senders and/or recipients.
+
+GGrreeyylliissttiinngg aallll yyoouurr mmaaiill
+
+If you turn on greylisting for all mail you may want to make exceptions for
+mailing lists that use one-time sender addresses, because each message will be
+delayed due to greylisting, and the one-time sender addresses can pollute your
+greylist database relatively quickly. Instead of making exceptions, you can
+automatically whitelist clients that survive greylisting repeatedly; this
+avoids most of the delays and most of the database pollution problem.
+
+ 1 /etc/postfix/main.cf:
+ 2 smtpd_recipient_restrictions =
+ 3 reject_unlisted_recipient
+ 4 ...
+ 5 reject_unauth_destination
+ 6 check_sender_access hash:/etc/postfix/sender_access
+ 7 check_policy_service unix:private/policy
+ 8 ...
+ 9
+ 10 /etc/postfix/sender_access:
+ 11 securityfocus.com OK
+ 12 ...
+
+NOTES:
+
+ * Line 7: On Solaris < 9, or Postfix < 2.10 on any Solaris version, use inet:
+ style sockets instead of unix: style, as detailed in the "Example: greylist
+ policy server" section above.
+
+ * Line 5: reject_unauth_destination is not needed here if the mail relay
+ policy is specified with smtpd_relay_restrictions (available with Postfix
+ 2.10 and later).
+
+ * Lines 6-7: Be sure to specify check_sender_access and check_policy_service
+ AFTER reject_unauth_destination or else your system could become an open
+ mail relay.
+
+ * Line 3: The greylist database gets polluted quickly with bogus addresses.
+ It helps if you precede greylist lookups with restrictions that reject
+ unknown senders and/or recipients.
+
+RRoouuttiinnee ggrreeyylliisstt mmaaiinntteennaannccee
+
+The greylist database grows over time, because the greylist server never
+removes database entries. If left unattended, the greylist database will
+eventually run your file system out of space.
+
+When the status file size exceeds some threshold you can simply rename or
+remove the file without adverse effects; Postfix automatically creates a new
+file. In the worst case, new mail will be delayed by an hour or so. To lessen
+the impact, rename or remove the file in the middle of the night at the
+beginning of a weekend.
+
+EExxaammppllee PPeerrll ggrreeyylliisstt sseerrvveerr
+
+This is the Perl subroutine that implements the example greylist policy. It is
+part of a general purpose sample policy server that is distributed with the
+Postfix source as examples/smtpd-policy/greylist.pl.
+
+#
+# greylist status database and greylist time interval. DO NOT create the
+# greylist status database in a world-writable directory such as /tmp
+# or /var/tmp. DO NOT create the greylist database in a file system
+# that can run out of space.
+#
+$database_name="/var/mta/greylist.db";
+$greylist_delay=60;
+
+#
+# Auto-whitelist threshold. Specify 0 to disable, or the number of
+# successful "come backs" after which a client is no longer subject
+# to greylisting.
+#
+$auto_whitelist_threshold = 10;
+
+#
+# Demo SMTPD access policy routine. The result is an action just like
+# it would be specified on the right-hand side of a Postfix access
+# table. Request attributes are available via the %attr hash.
+#
+sub smtpd_access_policy {
+ my($key, $time_stamp, $now);
+
+ # Open the database on the fly.
+ open_database() unless $database_obj;
+
+ # Search the auto-whitelist.
+ if ($auto_whitelist_threshold > 0) {
+ $count = read_database($attr{"client_address"});
+ if ($count > $auto_whitelist_threshold) {
+ return "dunno";
+ }
+ }
+
+ # Lookup the time stamp for this client/sender/recipient.
+ $key =
+ lc $attr{"client_address"}."/".$attr{"sender"}."/".$attr{"recipient"};
+ $time_stamp = read_database($key);
+ $now = time();
+
+ # If new request, add this client/sender/recipient to the database.
+ if ($time_stamp == 0) {
+ $time_stamp = $now;
+ update_database($key, $time_stamp);
+ }
+
+ # The result can be any action that is allowed in a Postfix access(5) map.
+ #
+ # To label the mail, return ``PREPEND headername: headertext''
+ #
+ # In case of success, return ``DUNNO'' instead of ``OK'', so that the
+ # check_policy_service restriction can be followed by other restrictions.
+ #
+ # In case of failure, return ``DEFER_IF_PERMIT optional text...'',
+ # so that mail can still be blocked by other access restrictions.
+ #
+ syslog $syslog_priority, "request age %d", $now - $time_stamp if $verbose;
+ if ($now - $time_stamp > $greylist_delay) {
+ # Update the auto-whitelist.
+ if ($auto_whitelist_threshold > 0) {
+ update_database($attr{"client_address"}, $count + 1);
+ }
+ return "dunno";
+ } else {
+ return "defer_if_permit Service temporarily unavailable";
+ }
+}
+
diff --git a/README_FILES/SMTPD_PROXY_README b/README_FILES/SMTPD_PROXY_README
new file mode 100644
index 0000000..f2cd530
--- /dev/null
+++ b/README_FILES/SMTPD_PROXY_README
@@ -0,0 +1,243 @@
+PPoossttffiixx BBeeffoorree--QQuueeuuee CCoonntteenntt FFiilltteerr
+
+-------------------------------------------------------------------------------
+
+WWAARRNNIINNGG
+
+The before-queue content filtering feature described in this document limits
+the amount of mail that a site can handle. See the "Pros and Cons" section
+below for details.
+
+TThhee PPoossttffiixx bbeeffoorree--qquueeuuee ccoonntteenntt ffiilltteerr ffeeaattuurree
+
+As of version 2.1, the Postfix SMTP server can forward all incoming mail to a
+content filtering proxy server that inspects all mail BEFORE it is stored in
+the Postfix mail queue. It is roughly equivalent in capabilities to the
+approach described in MILTER_README, except that the latter uses a dedicated
+protocol instead of SMTP.
+
+The before-queue content filter is meant to be used as follows:
+
+ Postfix BBeeffoorree Postfix Postfix Postfix smtp
+ Internet -> SMTP -> qquueeuuee -> SMTP -> cleanup -> queue -< local
+ server ffiilltteerr server server virtual
+
+The before-queue content filter is not to be confused with the approach
+described in the FILTER_README document, where mail is filtered AFTER it is
+stored in the Postfix mail queue.
+
+This document describes the following topics:
+
+ * Principles of operation
+ * Pros and cons of before-queue content filtering
+ * Configuring the Postfix SMTP pass-through proxy feature
+ * Configuration parameters
+ * How Postfix talks to the before-queue content filter
+
+PPrriinncciipplleess ooff ooppeerraattiioonn
+
+As shown in the diagram above, the before-queue filter sits between two Postfix
+SMTP server processes.
+
+ * The before-filter Postfix SMTP server accepts connections from the Internet
+ and does the usual relay access control, SASL authentication, TLS
+ negotiation, RBL lookups, rejecting non-existent sender or recipient
+ addresses, etc.
+
+ * The before-queue filter receives unfiltered mail content from Postfix and
+ does one of the following:
+
+ 1. Re-inject the mail back into Postfix via SMTP, perhaps after changing
+ its content and/or destination.
+
+ 2. Discard or quarantine the mail.
+
+ 3. Reject the mail by sending a suitable SMTP status code back to Postfix.
+ Postfix passes the status back to the remote SMTP client. This way,
+ Postfix does not have to send a bounce message.
+
+ * The after-filter Postfix SMTP server receives mail from the content filter.
+ From then on Postfix processes the mail as usual.
+
+The before-queue content filter described here works just like the after-queue
+content filter described in the FILTER_README document. In many cases you can
+use the same software, within the limitations as discussed in the "Pros and
+Cons" section below.
+
+PPrrooss aanndd ccoonnss ooff bbeeffoorree--qquueeuuee ccoonntteenntt ffiilltteerriinngg
+
+ * Pro: Postfix can reject mail before the incoming SMTP mail transfer
+ completes, so that Postfix does not have to send rejected mail back to the
+ sender (which is usually forged anyway). Mail that is not accepted remains
+ the responsibility of the remote SMTP client.
+
+ * Con: The remote SMTP client expects an SMTP reply within a deadline. As the
+ system load increases, fewer and fewer CPU cycles remain available to
+ answer within the deadline, and eventually you either have to stop
+ accepting mail or you have to stop filtering mail. It is for this reason
+ that the before-queue content filter limits the amount of mail that a site
+ can handle.
+
+ * Con: Content filtering software can use lots of memory resources. You have
+ to reduce the number of simultaneous content filter processes so that a
+ burst of mail will not drive your system into the ground.
+
+ o With Postfix versions 2.7 and later, SMTP clients will experience an
+ increase in the delay between the time the client sends "end-of-
+ message" and the time the Postfix SMTP server replies (here, the number
+ of before-filter SMTP server processes can be larger than the number of
+ filter processes).
+
+ o With Postfix versions before 2.7, SMTP clients will experience an
+ increase in the delay before they can receive service (here, the number
+ of before-filter SMTP server processes is always equal to the number of
+ filter processes).
+
+CCoonnffiigguurriinngg tthhee PPoossttffiixx SSMMTTPP ppaassss--tthhrroouugghh pprrooxxyy ffeeaattuurree
+
+In the following example, the before-filter Postfix SMTP server gives mail to a
+content filter that listens on localhost port 10025. The after-filter Postfix
+SMTP server receives mail from the content filter via localhost port 10026.
+From then on mail is processed as usual.
+
+The content filter itself is not described here. You can use any filter that is
+SMTP enabled. For non-SMTP capable content filtering software, Bennett Todd's
+SMTP proxy implements a nice Perl-based framework. See: http://
+bent.latency.net/smtpprox/ or https://github.com/jnorell/smtpprox.
+
+ Postfix
+ Postfix filter on SMTP server Postfix Postfix
+ Internet -> SMTP server -> localhost -> on -> cleanup -> incoming
+ on port 25 port 10025 localhost server queue
+ port 10026
+
+This is configured by editing the master.cf file:
+
+ /etc/postfix/master.cf:
+ # =============================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =============================================================
+ #
+ # Before-filter SMTP server. Receive mail from the network and
+ # pass it to the content filter on localhost port 10025.
+ #
+ smtp inet n - n - 20 smtpd
+ -o smtpd_proxy_filter=127.0.0.1:10025
+ -o smtpd_client_connection_count_limit=10
+ # Postfix 2.7 and later performance feature.
+ # -o smtpd_proxy_options=speed_adjust
+ #
+ # After-filter SMTP server. Receive mail from the content filter
+ # on localhost port 10026.
+ #
+ 127.0.0.1:10026 inet n - n - - smtpd
+ -o smtpd_authorized_xforward_hosts=127.0.0.0/8
+ -o smtpd_client_restrictions=
+ -o smtpd_helo_restrictions=
+ -o smtpd_sender_restrictions=
+ # Postfix 2.10 and later: specify empty smtpd_relay_restrictions.
+ -o smtpd_relay_restrictions=
+ -o smtpd_recipient_restrictions=permit_mynetworks,reject
+ -o smtpd_data_restrictions=
+ -o mynetworks=127.0.0.0/8
+ -o receive_override_options=no_unknown_recipient_checks
+
+Note: do not specify spaces around the "=" or "," characters.
+
+The before-filter SMTP server entry is a modified version of the default
+Postfix SMTP server entry that is normally configured at the top of the
+master.cf file:
+
+ * The number of SMTP sessions is reduced from the default 100 to only 20.
+ This prevents a burst of mail from running your system into the ground with
+ too many content filter processes.
+
+ * The "-o smtpd_client_connection_count_limit=10" prevents one SMTP client
+ from using up all 20 SMTP server processes. This limit is not necessary if
+ you receive all mail from a trusted relay host.
+
+ Note: this setting is available in Postfix version 2.2 and later. Earlier
+ Postfix versions will ignore it.
+
+ * The "-o smtpd_proxy_filter=127.0.0.1:10025" tells the before-filter SMTP
+ server that it should give incoming mail to the content filter that listens
+ on localhost TCP port 10025.
+
+ * The "-o smtpd_proxy_options=speed_adjust" tells the before-filter SMTP
+ server that it should receive an entire email message before it connects to
+ a content filter. This reduces the number of simultaneous filter processes.
+
+ NOTE 1: When this option is turned on, a content filter must not
+ selectively reject recipients of a multi-recipient message. Rejecting all
+ recipients is OK, as is accepting all recipients.
+
+ NOTE 2: This feature increases the minimum amount of free queue space by
+ $message_size_limit. The extra space is needed to save the message to a
+ temporary file.
+
+ * Postfix >= 2.3 supports both TCP and UNIX-domain filters. The above filter
+ could be specified as "inet:127.0.0.1:10025". To specify a UNIX-domain
+ filter, specify "unix:pathname". A relative pathname is interpreted
+ relative to the Postfix queue directory.
+
+The after-filter SMTP server is a new master.cf entry:
+
+ * The "127.0.0.1:10026" makes the after-filter SMTP server listen on the
+ localhost address only, without exposing it to the network. NEVER expose
+ the after-filter SMTP server to the Internet :-)
+
+ * The "-o smtpd_authorized_xforward_hosts=127.0.0.0/8" allows the after-
+ filter SMTP server to receive remote SMTP client information from the
+ before-filter SMTP server, so that the after-filter Postfix daemons log the
+ remote SMTP client information instead of logging localhost[127.0.0.1].
+
+ * The other after-filter SMTP server settings avoid duplication of work that
+ is already done in the "before filter" SMTP server.
+
+By default, the filter has 100 seconds to do its work. If it takes longer then
+Postfix gives up and reports an error to the remote SMTP client. You can
+increase this time limit (see configuration parameter section below) but doing
+so is pointless because you can't control when the remote SMTP client times
+out.
+
+CCoonnffiigguurraattiioonn ppaarraammeetteerrss
+
+Parameters that control proxying:
+
+ * smtpd_proxy_filter (syntax: host:port): The host and TCP port of the
+ before-queue content filter. When no host or host: is specified here,
+ localhost is assumed.
+
+ * smtpd_proxy_timeout (default: 100s): Timeout for connecting to the before-
+ queue content filter and for sending and receiving commands and data. All
+ proxy errors are logged to the maillog file. For privacy reasons, all the
+ remote SMTP client sees is "451 Error: queue file write error". It would
+ not be right to disclose internal details to strangers.
+
+ * smtpd_proxy_ehlo (default: $myhostname): The hostname to use when sending
+ an EHLO command to the before-queue content filter.
+
+HHooww PPoossttffiixx ttaallkkss ttoo tthhee bbeeffoorree--qquueeuuee ccoonntteenntt ffiilltteerr
+
+The before-filter Postfix SMTP server connects to the content filter, delivers
+one message, and disconnects. While sending mail into the content filter,
+Postfix speaks ESMTP but uses no command pipelining. Postfix generates its own
+EHLO, XFORWARD (for logging the remote client IP address instead of localhost
+[127.0.0.1]), DATA and QUIT commands, and forwards unmodified copies of all the
+MAIL FROM and RCPT TO commands that the before-filter Postfix SMTP server
+didn't reject itself. Postfix sends no other SMTP commands.
+
+The content filter should accept the same MAIL FROM and RCPT TO command syntax
+as the before-filter Postfix SMTP server, and should forward the commands
+without modification to the after-filter SMTP server. If the content filter or
+after-filter SMTP server does not support all the ESMTP features that the
+before-filter Postfix SMTP server supports, then the missing features must be
+turned off in the before-filter Postfix SMTP server with the
+smtpd_discard_ehlo_keywords parameter.
+
+When the filter rejects content, it should send a negative SMTP response back
+to the before-filter Postfix SMTP server, and it should abort the connection
+with the after-filter Postfix SMTP server without completing the SMTP
+conversation with the after-filter Postfix SMTP server.
+
diff --git a/README_FILES/SMTPUTF8_README b/README_FILES/SMTPUTF8_README
new file mode 100644
index 0000000..68fb6c2
--- /dev/null
+++ b/README_FILES/SMTPUTF8_README
@@ -0,0 +1,268 @@
+ PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document describes Postfix support for Email Address Internationalization
+(EAI) as defined in RFC 6531 (SMTPUTF8 extension), RFC 6532 (Internationalized
+email headers) and RFC 6533 (Internationalized delivery status notifications).
+Introduced with Postfix version 3.0, this fully supports UTF-8 email addresses
+and UTF-8 message header values.
+
+Topics covered in this document:
+
+ * Building with/without SMTPUTF8 support
+ * Enabling Postfix SMTPUTF8 support
+ * Using Postfix SMTPUTF8 support
+ * SMTPUTF8 autodetection
+ * Limitations of the current implementation
+ * Compatibility with pre-SMTPUTF8 environments
+ * Credits
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh//wwiitthhoouutt SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+Postfix will build with SMTPUTF8 support if the ICU library and header files
+are installed on the system. The package name varies with the OS distribution
+(and version). The table shows package names for a number of platforms at the
+time this text was written.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |OOSS DDiissttrriibbuuttiioonn |PPaacckkaaggee |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |FreeBSD, NetBSD, etc.|icu |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |Centos, Fedora, RHEL |libicu-devel|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+ |Debian, Ubuntu |libicu-dev |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+
+To force Postfix to build without SMTPUTF8, specify:
+
+ $ mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDNNOO__EEAAII ......""
+
+See the INSTALL document for more "make makefiles" options.
+
+EEnnaabblliinngg PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+There is more to SMTPUTF8 than just Postfix itself. The rest of your email
+infrastructure also needs to be able to handle UTF-8 email addresses and
+message header values. This includes SMTPUTF8 protocol support in SMTP-based
+content filters (Amavisd), LMTP servers (Dovecot), and down-stream SMTP
+servers.
+
+Postfix SMTPUTF8 support is enabled by default, but it may be disabled as part
+of a backwards-compatibility safety net (see the COMPATIBILITY_README file).
+
+SMTPUTF8 support is enabled by setting the smtputf8_enable parameter in
+main.cf:
+
+ # ppoossttccoonnff ""ssmmttppuuttff88__eennaabbllee == yyeess""
+ # ppoossttffiixx rreellooaadd
+
+With SMTPUTF8 support enabled, Postfix changes behavior with respect to earlier
+Postfix releases:
+
+ * UTF-8 is permitted in the myorigin parameter value. However, the myhostname
+ and mydomain parameters must currently specify ASCII-only domain names.
+ This limitation may be removed later.
+
+ * UTF-8 is the only form of non-ASCII text that Postfix supports in access
+ tables, address rewriting tables, and other tables that are indexed with an
+ email address, hostname, or domain name.
+
+ * The header_checks-like and body_checks-like features are not UTF-8 enabled,
+ and therefore they do not enforce UTF-8 syntax rules on inputs and outputs.
+ The reason is that non-ASCII text may be sent in encodings other than UTF-
+ 8, and that real email sometimes contains malformed headers. Instead of
+ skipping non-UTF-8 content, Postfix should be able to filter it. You may
+ try to enable UTF-8 processing by starting a PCRE pattern with the sequence
+ (*UTF8), but this is will result in "message not accepted, try again later"
+ errors when the PCRE pattern matcher encounters non-UTF-8 input. Other
+ features that are not UTF-8 enabled are smtpd_command_filter,
+ smtp_reply_filter, the *_delivery_status_filter features, and the
+ *_dns_reply_filter features (the latter because DNS is by definition an
+ ASCII protocol).
+
+ * The Postfix SMTP server announces SMTPUTF8 support in the EHLO response.
+
+ 220 server.example.com ESMTP Postfix
+ EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+ 250-server.example.com
+ 250-PIPELINING
+ 250-SIZE 10240000
+ 250-VRFY
+ 250-ETRN
+ 250-STARTTLS
+ 250-AUTH PLAIN LOGIN
+ 250-ENHANCEDSTATUSCODES
+ 250-8BITMIME
+ 250-DSN
+ 250 SMTPUTF8
+
+ * The Postfix SMTP server accepts the SMTPUTF8 request in MAIL FROM and VRFY
+ commands.
+
+ MMAAIILL FFRROOMM::<> SSMMTTPPUUTTFF88 ......
+
+ VVRRFFYY aaddddrreessss SSMMTTPPUUTTFF88
+
+ * The Postfix SMTP client may issue the SMTPUTF8 request in MAIL FROM
+ commands.
+
+ * The Postfix SMTP server accepts UTF-8 in email address domains, but only
+ after the remote SMTP client issues the SMTPUTF8 request in MAIL FROM or
+ VRFY commands.
+
+Postfix already permitted UTF-8 in message header values and in address
+localparts. This does not change.
+
+UUssiinngg PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+After Postfix SMTPUTF8 support is turned on, Postfix behavior will depend on 1)
+whether a remote SMTP client requests SMTPUTF8 support, 2) the presence of UTF-
+8 content in the message envelope and headers, and 3) whether a down-stream
+SMTP (or LMTP) server announces SMTPUTF8 support.
+
+ * When the Postfix SMTP server receives a message WITHOUT the SMTPUTF8
+ request, Postfix handles the message as it has always done (at least that
+ is the default, see autodetection below). Specifically, the Postfix SMTP
+ server does not accept UTF-8 in the envelope sender domain name or envelope
+ recipient domain name, and the Postfix SMTP client does not issue the
+ SMTPUTF8 request when delivering that message to an SMTP or LMTP server
+ that announces SMTPUTF8 support (again, that is the default). Postfix will
+ accept UTF-8 in message header values and in the localpart of envelope
+ sender and recipient addresses, because it has always done that.
+
+ * When the Postfix SMTP server receives a message WITH the SMTPUTF8 request,
+ Postfix will issue the SMTPUTF8 request when delivering that message to an
+ SMTP or LMTP server that announces SMTPUTF8 support. This is not
+ configurable.
+
+ * When a message is received with the SMTPUTF8 request, Postfix will deliver
+ the message to a non-SMTPUTF8 SMTP or LMTP server ONLY if:
+
+ o No message header value contains UTF-8.
+
+ o The envelope sender address contains no UTF-8,
+
+ o No envelope recipient address for that specific SMTP/LMTP delivery
+ transaction contains UTF-8.
+
+ NOTE: Recipients in other email delivery transactions for that same
+ message may still contain UTF-8.
+
+ Otherwise, Postfix will return the recipient(s) for that email delivery
+ transaction as undeliverable. The delivery status notification message will
+ be an SMTPUTF8 message. It will therefore be subject to the same
+ restrictions as email that is received with the SMTPUTF8 request.
+
+ * When the Postfix SMTP server receives a message with the SMTPUTF8 request,
+ that request also applies after the message is forwarded via a virtual or
+ local alias, or $HOME/.forward file.
+
+SSMMTTPPUUTTFF88 aauuttooddeetteeccttiioonn
+
+This section applies only to systems that have SMTPUTF8 support turned on
+(smtputf8_enable = yes).
+
+For compatibility with pre-SMTPUTF8 environments, Postfix does not
+automatically set the "SMTPUTF8 requested" flag on messages from non-SMTPUTF8
+clients that contain an UTF-8 header value or UTF-8 address localpart. This
+would make such messages undeliverable to non-SMTPUTF8 servers, and could be a
+barrier to SMTPUTF8 adoption.
+
+By default, Postfix sets the "SMTPUTF8 requested" flag only on address
+verification probes and on Postfix sendmail submissions that contain UTF-8 in
+the sender address, UTF-8 in a recipient address, or UTF-8 in a message header
+value.
+
+ /etc/postfix/main.cf:
+ smtputf8_autodetect_classes = sendmail, verify
+
+However, if you have a non-ASCII myorigin or mydomain setting, or if you have a
+configuration that introduces UTF-8 addresses with virtual aliases, canonical
+mappings, or BCC mappings, then you may have to apply SMTPUTF8 autodetection to
+all email:
+
+ /etc/postfix/main.cf:
+ smtputf8_autodetect_classes = all
+
+This will, of course, also flag email that was received without SMTPUTF8
+request, but that contains UTF-8 in a sender address localpart, receiver
+address localpart, or message header value. Such email was not standards-
+compliant, but Postfix would have delivered it if SMTPUTF8 support was
+disabled.
+
+LLiimmiittaattiioonnss ooff tthhee ccuurrrreenntt iimmpplleemmeennttaattiioonn
+
+The Postfix implementation is a work in progress; limitations are steadily
+being removed. The text below describes the situation at one point in time.
+
+NNoo aauuttoommaattiicc ccoonnvveerrssiioonnss bbeettwweeeenn AASSCCIIII aanndd UUTTFF--88 ddoommaaiinn nnaammeess..
+
+Some background: According to RFC 6530 and related documents, an
+internationalized domain name can appear in two forms: the UTF-8 form, and the
+ASCII (xn--mumble) form. An internationalized address localpart must be encoded
+in UTF-8; the RFCs do not define an ASCII alternative form.
+
+Postfix currently does not convert internationalized domain names from UTF-
+8 into ASCII (or from ASCII into UTF-8) before using domain names in SMTP
+commands and responses, before looking up domain names in lists such as
+mydestination, relay_domains or in lookup tables such as access tables, etc.,
+before using domain names in a policy daemon or Milter request, or before
+logging events.
+
+Postfix does, however, casefold domain names and email addresses before
+matching them against a Postfix configuration parameter or lookup table.
+
+In order to use Postfix SMTPUTF8 support:
+
+ * The Postfix parameters myhostname and mydomain must be in ASCII form. One
+ is a substring of the other, and the myhostname value is used in SMTP
+ commands and responses that require ASCII. The parameter myorigin (added to
+ local addresses without domain) supports UTF-8.
+
+ * You need to configure both the ASCII and UTF-8 forms of an
+ Internationalized domain name in Postfix parameters such as mydestination
+ and relay_domains, as well as lookup table search keys.
+
+ * Milters, content filters, policy servers and logfile analysis tools need to
+ be able to handle both the ASCII and UTF-8 forms of Internationalized
+ domain names.
+
+CCoommppaattiibbiilliittyy wwiitthh pprree--SSMMTTPPUUTTFF88 eennvviirroonnmmeennttss
+
+MMaaiilliinngg lliissttss wwiitthh UUTTFF--88 aanndd nnoonn--UUTTFF--88 ssuubbssccrriibbeerrss
+
+With Postfix, there is no need to split mailing lists into UTF-8 and non-UTF-
+8 members. Postfix will try to deliver the non-UTF8 subscribers over
+"traditional" non-SMTPUTF8 sessions, as long as the message has an ASCII
+envelope sender address and all-ASCII header values. The mailing list manager
+may have to apply RFC 2047 encoding to satisfy that last condition.
+
+PPrree--eexxiissttiinngg nnoonn--AASSCCIIII eemmaaiill fflloowwss
+
+With "smtputf8_enable = no", Postfix handles email with non-ASCII in address
+localparts (and in headers) as before. The vast majority of email software is
+perfectly capable of handling such email, even if pre-SMTPUTF8 standards do not
+support such practice.
+
+However, when you specify "smtputf8_enable = yes", Postfix requires that non-
+ASCII address information is encoded in UTF-8 and will reject other encodings
+such as ISO-8859. It is not practical for Postfix to support multiple encodings
+at the same time. There is no problem with RFC 2047 encodings such as "=?ISO-
+8859-1?Q?text?=", because those use only characters from the ASCII
+characterset.
+
+CCrreeddiittss
+
+ * May 15, 2014: Arnt Gulbrandsen posted his patch for Unicode email support.
+ This work was sponsored by CNNIC.
+
+ * July 15, 2014: Wietse integrated Arnt Gulbrandsen's code and released
+ Postfix with SMTPUTF8 support.
+
+ * January 2015: Wietse added UTF-8 support for casefolding in Postfix lookup
+ tables and caseless string comparison in Postfix list-based features.
+
diff --git a/README_FILES/SOHO_README b/README_FILES/SOHO_README
new file mode 100644
index 0000000..722bece
--- /dev/null
+++ b/README_FILES/SOHO_README
@@ -0,0 +1,288 @@
+PPoossttffiixx SSmmaallll//HHoommee OOffffiiccee HHiinnttss aanndd TTiippss
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document combines hints and tips for "small office/home office"
+applications into one document so that they are easier to find. The text
+describes the mail sending side only. If your machine does not receive mail
+directly (i.e. it does not have its own Internet domain name and its own fixed
+IP address), then you will need a solution such as "fetchmail", which is
+outside the scope of the Postfix documentation.
+
+ * Selected topics from the STANDARD_CONFIGURATION_README document:
+
+ o Postfix on a stand-alone Internet host
+ o Postfix on hosts without a real Internet hostname
+
+ Selected topics from the SASL_README document:
+
+ o Enabling SASL authentication in the Postfix SMTP client
+ o Configuring Sender-Dependent SASL authentication
+
+See the SASL_README and STANDARD_CONFIGURATION_README documents for further
+information on these topics.
+
+PPoossttffiixx oonn aa ssttaanndd--aalloonnee IInntteerrnneett hhoosstt
+
+Postfix should work out of the box without change on a stand-alone machine that
+has direct Internet access. At least, that is how Postfix installs when you
+download the Postfix source code via http://www.postfix.org/.
+
+You can use the command "ppoossttccoonnff --nn" to find out what settings are overruled
+by your main.cf. Besides a few pathname settings, few parameters should be set
+on a stand-alone box, beyond what is covered in the BASIC_CONFIGURATION_README
+document:
+
+ /etc/postfix/main.cf:
+ # Optional: send mail as user@domainname instead of user@hostname.
+ #myorigin = $mydomain
+
+ # Optional: specify NAT/proxy external address.
+ #proxy_interfaces = 1.2.3.4
+
+ # Alternative 1: don't relay mail from other hosts.
+ mynetworks_style = host
+ relay_domains =
+
+ # Alternative 2: relay mail from local clients only.
+ # mynetworks = 192.168.1.0/28
+ # relay_domains =
+
+See also the section "Postfix on hosts without a real Internet hostname" if
+this is applicable to your configuration.
+
+PPoossttffiixx oonn hhoossttss wwiitthhoouutt aa rreeaall IInntteerrnneett hhoossttnnaammee
+
+This section is for hosts that don't have their own Internet hostname.
+Typically these are systems that get a dynamic IP address via DHCP or via
+dialup. Postfix will let you send and receive mail just fine between accounts
+on a machine with a fantasy name. However, you cannot use a fantasy hostname in
+your email address when sending mail into the Internet, because no-one would be
+able to reply to your mail. In fact, more and more sites refuse mail addresses
+with non-existent domain names.
+
+Note: the following information is Postfix version dependent. To find out what
+Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
+
+SSoolluuttiioonn 11:: PPoossttffiixx vveerrssiioonn 22..22 aanndd llaatteerr
+
+Postfix 2.2 uses the generic(5) address mapping to replace local fantasy email
+addresses by valid Internet addresses. This mapping happens ONLY when mail
+leaves the machine; not when you send mail between users on the same machine.
+
+The following example presents additional configuration. You need to combine
+this with basic configuration information as discussed the first half of this
+document.
+
+ 1 /etc/postfix/main.cf:
+ 2 smtp_generic_maps = hash:/etc/postfix/generic
+ 3
+ 4 /etc/postfix/generic:
+ 5 his@localdomain.local hisaccount@hisisp.example
+ 6 her@localdomain.local heraccount@herisp.example
+ 7 @localdomain.local hisaccount+local@hisisp.example
+
+When mail is sent to a remote host via SMTP:
+
+ * Line 5 replaces his@localdomain.local by his ISP mail address,
+
+ * Line 6 replaces her@localdomain.local by her ISP mail address, and
+
+ * Line 7 replaces other local addresses by his ISP account, with an address
+ extension of +local (this example assumes that the ISP supports "+" style
+ address extensions).
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ggeenneerriicc" whenever you change the
+generic table.
+
+SSoolluuttiioonn 22:: PPoossttffiixx vveerrssiioonn 22..11 aanndd eeaarrlliieerr
+
+The solution with older Postfix systems is to use valid Internet addresses
+where possible, and to let Postfix map valid Internet addresses to local
+fantasy addresses. With this, you can send mail to the Internet and to local
+fantasy addresses, including mail to local fantasy addresses that don't have a
+valid Internet address of their own.
+
+The following example presents additional configuration. You need to combine
+this with basic configuration information as discussed the first half of this
+document.
+
+ 1 /etc/postfix/main.cf:
+ 2 myhostname = hostname.localdomain
+ 3 mydomain = localdomain
+ 4
+ 5 canonical_maps = hash:/etc/postfix/canonical
+ 6
+ 7 virtual_alias_maps = hash:/etc/postfix/virtual
+ 8
+ 9 /etc/postfix/canonical:
+ 10 your-login-name your-account@your-isp.com
+ 11
+ 12 /etc/postfix/virtual:
+ 13 your-account@your-isp.com your-login-name
+
+Translation:
+
+ * Lines 2-3: Substitute your fantasy hostname here. Do not use a domain name
+ that is already in use by real organizations on the Internet. See RFC 2606
+ for examples of domain names that are guaranteed not to be owned by anyone.
+
+ * Lines 5, 9, 10: This provides the mapping from "your-login-
+ name@hostname.localdomain" to "your-account@your-isp.com". This part is
+ required.
+
+ * Lines 7, 12, 13: Deliver mail for "your-account@your-isp.com" locally,
+ instead of sending it to the ISP. This part is not required but is
+ convenient.
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ccaannoonniiccaall" whenever you change the
+canonical table.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" whenever you change the
+virtual table.
+
+EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
+
+This section shows a typical scenario where the Postfix SMTP client sends all
+messages via a mail gateway server that requires SASL authentication.
+
+ TTrroouubbllee ssoollvviinngg ttiippss::
+
+ * If your SASL logins fail with "SASL authentication failure: No worthy
+ mechs found" in the mail logfile, then see the section "Postfix SMTP/
+ LMTP client policy - SASL mechanism pprrooppeerrttiieess".
+
+ * For a solution to a more obscure class of SASL authentication failures,
+ see "Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess".
+
+To make the example more readable we introduce it in two parts. The first part
+takes care of the basic configuration, while the second part sets up the
+username/password information.
+
+ /etc/postfix/main.cf:
+ smtp_sasl_auth_enable = yes
+ smtp_tls_security_level = encrypt
+ smtp_sasl_tls_security_options = noanonymous
+ relayhost = [mail.isp.example]
+ # Alternative form:
+ # relayhost = [mail.isp.example]:submission
+ smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+
+ * The smtp_sasl_auth_enable setting enables client-side authentication. We
+ will configure the client's username and password information in the second
+ part of the example.
+
+ * The smtp_tls_security_level setting ensures that the connection to the
+ remote smtp server will be encrypted, and smtp_sasl_tls_security_options
+ removes the prohibition on plaintext passwords.
+
+ * The relayhost setting forces the Postfix SMTP to send all remote messages
+ to the specified mail server instead of trying to deliver them directly to
+ their destination.
+
+ * In the relayhost setting, the "[" and "]" prevent the Postfix SMTP client
+ from looking up MX (mail exchanger) records for the enclosed name.
+
+ * The relayhost destination may also specify a non-default TCP port. For
+ example, the alternative form [mail.isp.example]:submission tells Postfix
+ to connect to TCP network port 587, which is reserved for email client
+ applications.
+
+ * The Postfix SMTP client is compatible with SMTP servers that use the non-
+ standard "AUTH=mmeetthhoodd....." syntax in response to the EHLO command; this
+ requires no additional Postfix client configuration.
+
+ * The Postfix SMTP client does not support the obsolete "wrappermode"
+ protocol, which uses TCP port 465 on the SMTP server. See TLS_README for a
+ solution that uses the stunnel command.
+
+ * With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP
+ client to send username and password information to the mail gateway
+ server. As discussed in the next section, the Postfix SMTP client supports
+ multiple ISP accounts. For this reason the username and password are stored
+ in a table that contains one username/password combination for each mail
+ gateway server.
+
+ /etc/postfix/sasl_passwd:
+ # destination credentials
+ [mail.isp.example] username:password
+ # Alternative form:
+ # [mail.isp.example]:submission username:password
+
+ IImmppoorrttaanntt
+
+ Keep the SASL client password file in /etc/postfix, and make the file
+ read+write only for root to protect the username/password combinations
+ against other users. The Postfix SMTP client will still be able to read the
+ SASL client passwords. It opens the file as user root before it drops
+ privileges, and before entering an optional chroot jail.
+
+ * Use the postmap command whenever you change the /etc/postfix/sasl_passwd
+ file.
+
+ * If you specify the "[" and "]" in the relayhost destination, then you must
+ use the same form in the smtp_sasl_password_maps file.
+
+ * If you specify a non-default TCP Port (such as ":submission" or ":587") in
+ the relayhost destination, then you must use the same form in the
+ smtp_sasl_password_maps file.
+
+CCoonnffiigguurriinngg SSeennddeerr--DDeeppeennddeenntt SSAASSLL aauutthheennttiiccaattiioonn
+
+Postfix supports different ISP accounts for different sender addresses (version
+2.3 and later). This can be useful when one person uses the same machine for
+work and for personal use, or when people with different ISP accounts share the
+same Postfix server.
+
+To make this possible, Postfix supports per-sender SASL passwords and per-
+sender relay hosts. In the example below, the Postfix SMTP client will search
+the SASL password file by sender address before it searches that same file by
+destination. Likewise, the Postfix trivial-rewrite(8) daemon will search the
+per-sender relayhost file, and use the default relayhost setting only as a
+final resort.
+
+ /etc/postfix/main.cf:
+ smtp_sender_dependent_authentication = yes
+ sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
+ smtp_sasl_auth_enable = yes
+ smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
+ relayhost = [mail.isp.example]
+ # Alternative form:
+ # relayhost = [mail.isp.example]:submission
+
+ /etc/postfix/sasl_passwd:
+ # Per-sender authentication; see also /etc/postfix/sender_relay.
+ user1@example.com username1:password1
+ user2@example.net username2:password2
+ # Login information for the default relayhost.
+ [mail.isp.example] username:password
+ # Alternative form:
+ # [mail.isp.example]:submission username:password
+
+ /etc/postfix/sender_relay:
+ # Per-sender provider; see also /etc/postfix/sasl_passwd.
+ user1@example.com [mail.example.com]:submission
+ user2@example.net [mail.example.net]
+
+ * If you are creative, then you can try to combine the two tables into one
+ single MySQL database, and configure different Postfix queries to extract
+ the appropriate information.
+
+ * Specify dbm instead of hash if your system uses dbm files instead of db
+ files. To find out what lookup tables Postfix supports, use the command
+ "postconf -m".
+
+ * Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change
+ the sasl_passwd table.
+
+ * Execute the command "postmap /etc/postfix/sender_relay" whenever you change
+ the sender_relay table.
+
diff --git a/README_FILES/SQLITE_README b/README_FILES/SQLITE_README
new file mode 100644
index 0000000..324b305
--- /dev/null
+++ b/README_FILES/SQLITE_README
@@ -0,0 +1,77 @@
+PPoossttffiixx SSQQLLiittee HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+The Postfix sqlite map type allows you to hook up Postfix to a SQLite database.
+This implementation allows for multiple sqlite databases: you can use one for a
+virtual(5) table, one for an access(5) table, and one for an aliases(5) table
+if you want.
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh SSQQLLiittee ssuuppppoorrtt
+
+The Postfix SQLite client utilizes the sqlite3 library, which can be obtained
+from:
+
+ http://www.sqlite.org/
+
+In order to build Postfix with sqlite map support, you will need to add to
+CCARGS the flags -DHAS_SQLITE and -I with the directory containing the sqlite
+header files, and you will need to add to AUXLIBS the directory and name of the
+sqlite3 library, plus the name of the standard POSIX thread library (pthread).
+For example:
+
+ make -f Makefile.init makefiles \
+ 'CCARGS=-DHAS_SQLITE -I/usr/local/include' \
+ 'AUXLIBS_SQLITE=-L/usr/local/lib -lsqlite3 -lpthread'
+
+Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_SQLITE. With Postfix
+3.0 and later, the old AUXLIBS variable still supports building a statically-
+loaded SQLite database client, but only the new AUXLIBS_SQLITE variable
+supports building a dynamically-loaded or statically-loaded SQLite database
+client.
+
+ Failure to use the AUXLIBS_SQLITE variable will defeat the purpose of
+ dynamic database client loading. Every Postfix executable file will have
+ SQLITE database library dependencies. And that was exactly what dynamic
+ database client loading was meant to avoid.
+
+Then, just run 'make'.
+
+UUssiinngg SSQQLLiittee ttaabblleess
+
+Once Postfix is built with sqlite support, you can specify a map type in
+main.cf like this:
+
+ alias_maps = sqlite:/etc/postfix/sqlite-aliases.cf
+
+The file /etc/postfix/sqlite-aliases.cf specifies lots of information telling
+Postfix how to reference the sqlite database. For a complete description, see
+the sqlite_table(5) manual page.
+
+EExxaammppllee:: llooccaall aalliiaasseess
+
+#
+# sqlite config file for local(8) aliases(5) lookups
+#
+
+# Path to database
+dbpath = /some/path/to/sqlite_database
+
+# See sqlite_table(5) for details.
+query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND status='paid'
+
+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.
+
+ * Implementation by Axel Steiner
+ * Documentation by Jesus Garcia Crespo
+
diff --git a/README_FILES/STANDARD_CONFIGURATION_README b/README_FILES/STANDARD_CONFIGURATION_README
new file mode 100644
index 0000000..ceb18fc
--- /dev/null
+++ b/README_FILES/STANDARD_CONFIGURATION_README
@@ -0,0 +1,631 @@
+PPoossttffiixx SSttaannddaarrdd CCoonnffiigguurraattiioonn EExxaammpplleess
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document presents a number of typical Postfix configurations. This
+document should be reviewed after you have followed the basic configuration
+steps as described in the BASIC_CONFIGURATION_README document. In particular,
+do not proceed here if you don't already have Postfix working for local mail
+submission and for local mail delivery.
+
+The first part of this document presents standard configurations that each
+solve one specific problem.
+
+ * Postfix on a stand-alone Internet host
+ * Postfix on a null client
+ * Postfix on a local network
+ * Postfix email firewall/gateway
+
+The second part of this document presents additional configurations for hosts
+in specific environments.
+
+ * Delivering some but not all accounts locally
+ * Running Postfix behind a firewall
+ * Configuring Postfix as primary or backup MX host for a remote site
+ * Postfix on a dialup machine
+ * Postfix on hosts without a real Internet hostname
+
+PPoossttffiixx oonn aa ssttaanndd--aalloonnee IInntteerrnneett hhoosstt
+
+Postfix should work out of the box without change on a stand-alone machine that
+has direct Internet access. At least, that is how Postfix installs when you
+download the Postfix source code via http://www.postfix.org/.
+
+You can use the command "ppoossttccoonnff --nn" to find out what settings are overruled
+by your main.cf. Besides a few pathname settings, few parameters should be set
+on a stand-alone box, beyond what is covered in the BASIC_CONFIGURATION_README
+document:
+
+ /etc/postfix/main.cf:
+ # Optional: send mail as user@domainname instead of user@hostname.
+ #myorigin = $mydomain
+
+ # Optional: specify NAT/proxy external address.
+ #proxy_interfaces = 1.2.3.4
+
+ # Alternative 1: don't relay mail from other hosts.
+ mynetworks_style = host
+ relay_domains =
+
+ # Alternative 2: relay mail from local clients only.
+ # mynetworks = 192.168.1.0/28
+ # relay_domains =
+
+See also the section "Postfix on hosts without a real Internet hostname" if
+this is applicable to your configuration.
+
+PPoossttffiixx oonn aa nnuullll cclliieenntt
+
+A null client is a machine that can only send mail. It receives no mail from
+the network, and it does not deliver any mail locally. A null client typically
+uses POP, IMAP or NFS for mailbox access.
+
+In this example we assume that the Internet domain name is "example.com" and
+that the machine is named "hostname.example.com". As usual, the examples show
+only parameters that are not left at their default settings.
+
+ 1 /etc/postfix/main.cf:
+ 2 myhostname = hostname.example.com
+ 3 myorigin = $mydomain
+ 4 relayhost = $mydomain
+ 5 inet_interfaces = loopback-only
+ 6 mydestination =
+
+Translation:
+
+ * Line 2: Set myhostname to hostname.example.com, in case the machine name
+ isn't set to a fully-qualified domain name (use the command "postconf -
+ d myhostname" to find out what the machine name is).
+
+ * Line 2: The myhostname value also provides the default value for the
+ mydomain parameter (here, "mydomain = example.com").
+
+ * Line 3: Send mail as "user@example.com" (instead of
+ "user@hostname.example.com"), so that nothing ever has a reason to send
+ mail to "user@hostname.example.com".
+
+ * Line 4: Forward all mail to the mail server that is responsible for the
+ "example.com" domain. This prevents mail from getting stuck on the null
+ client if it is turned off while some remote destination is unreachable.
+ Specify a real hostname here if your "example.com" domain has no MX record.
+
+ * Line 5: Do not accept mail from the network.
+
+ * Line 6: Disable local mail delivery. All mail goes to the mail server as
+ specified in line 4.
+
+PPoossttffiixx oonn aa llooccaall nneettwwoorrkk
+
+This section describes a local area network environment of one main server and
+multiple other systems that send and receive email. As usual we assume that the
+Internet domain name is "example.com". All systems are configured to send mail
+as "user@example.com", and all systems receive mail for
+"user@hostname.example.com". The main server also receives mail for
+"user@example.com". We call this machine by the name of mailhost.example.com.
+
+A drawback of sending mail as "user@example.com" is that mail for "root" and
+other system accounts is also sent to the central mailhost. See the section
+"Delivering some but not all accounts locally" below for possible solutions.
+
+As usual, the examples show only parameters that are not left at their default
+settings.
+
+First we present the non-mailhost configuration, because it is the simpler one.
+This machine sends mail as "user@example.com" and is final destination for
+"user@hostname.example.com".
+
+ 1 /etc/postfix/main.cf:
+ 2 myorigin = $mydomain
+ 3 mynetworks = 127.0.0.0/8 10.0.0.0/24
+ 4 relay_domains =
+ 5 # Optional: forward all non-local mail to mailhost
+ 6 #relayhost = $mydomain
+
+Translation:
+
+ * Line 2: Send mail as "user@example.com".
+
+ * Line 3: Specify the trusted networks.
+
+ * Line 4: This host does not relay mail from untrusted networks.
+
+ * Line 6: This is needed if no direct Internet access is available. See also
+ below, "Postfix behind a firewall".
+
+Next we present the mailhost configuration. This machine sends mail as
+"user@example.com" and is final destination for "user@hostname.example.com" as
+well as "user@example.com".
+
+ 1 DNS:
+ 2 example.com IN MX 10 mailhost.example.com.
+ 3
+ 4 /etc/postfix/main.cf:
+ 5 myorigin = $mydomain
+ 6 mydestination = $myhostname localhost.$mydomain localhost $mydomain
+ 7 mynetworks = 127.0.0.0/8 10.0.0.0/24
+ 8 relay_domains =
+ 9 # Optional: forward all non-local mail to firewall
+ 10 #relayhost = [firewall.example.com]
+
+Translation:
+
+ * Line 2: Send mail for the domain "example.com" to the machine
+ mailhost.example.com. Remember to specify the "." at the end of the line.
+
+ * Line 5: Send mail as "user@example.com".
+
+ * Line 6: This host is the final mail destination for the "example.com"
+ domain, in addition to the names of the machine itself.
+
+ * Line 7: Specify the trusted networks.
+
+ * Line 8: This host does not relay mail from untrusted networks.
+
+ * Line 10: This is needed only when the mailhost has to forward non-local
+ mail via a mail server on a firewall. The [] forces Postfix to do no MX
+ record lookups.
+
+In an environment like this, users access their mailbox in one or more of the
+following ways:
+
+ * Mailbox access via NFS or equivalent.
+
+ * Mailbox access via POP or IMAP.
+
+ * Mailbox on the user's preferred machine.
+
+In the latter case, each user has an alias on the mailhost that forwards mail
+to her preferred machine:
+
+ /etc/aliases:
+ joe: joe@joes.preferred.machine
+ jane: jane@janes.preferred.machine
+
+On some systems the alias database is not in /etc/aliases. To find out the
+location for your system, execute the command "ppoossttccoonnff aalliiaass__mmaappss".
+
+Execute the command "nneewwaalliiaasseess" whenever you change the aliases file.
+
+PPoossttffiixx eemmaaiill ffiirreewwaallll//ggaatteewwaayy
+
+The idea is to set up a Postfix email firewall/gateway that forwards mail for
+"example.com" to an inside gateway machine but rejects mail for
+"anything.example.com". There is only one problem: with "relay_domains =
+example.com", the firewall normally also accepts mail for
+"anything.example.com". That would not be right.
+
+Note: this example requires Postfix version 2.0 and later. To find out what
+Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
+
+The solution is presented in multiple parts. This first part gets rid of local
+mail delivery on the firewall, making the firewall harder to break.
+
+ 1 /etc/postfix/main.cf:
+ 2 myorigin = example.com
+ 3 mydestination =
+ 4 local_recipient_maps =
+ 5 local_transport = error:local mail delivery is disabled
+ 6
+ 7 /etc/postfix/master.cf:
+ 8 Comment out the local delivery agent
+
+Translation:
+
+ * Line 2: Send mail from this machine as "user@example.com", so that no
+ reason exists to send mail to "user@firewall.example.com".
+
+ * Lines 3-8: Disable local mail delivery on the firewall machine.
+
+For the sake of technical correctness the firewall must be able to receive mail
+for postmaster@[firewall ip address]. Reportedly, some things actually expect
+this ability to exist. The second part of the solution therefore adds support
+for postmaster@[firewall ip address], and as a bonus we do abuse@[firewall ip
+address] as well. All the mail to these two accounts is forwarded to an inside
+address.
+
+ 1 /etc/postfix/main.cf:
+ 2 virtual_alias_maps = hash:/etc/postfix/virtual
+ 3
+ 4 /etc/postfix/virtual:
+ 5 postmaster postmaster@example.com
+ 6 abuse abuse@example.com
+
+Translation:
+
+ * Because mydestination is empty (see the previous example), only address
+ literals matching $inet_interfaces or $proxy_interfaces are deemed local.
+ So "localpart@[a.d.d.r]" can be matched as simply "localpart" in canonical
+ (5) and virtual(5). This avoids the need to specify firewall IP addresses
+ into Postfix configuration files.
+
+The last part of the solution does the email forwarding, which is the real
+purpose of the firewall email function.
+
+ 1 /etc/postfix/main.cf:
+ 2 mynetworks = 127.0.0.0/8 12.34.56.0/24
+ 3 relay_domains = example.com
+ 4 parent_domain_matches_subdomains =
+ 5 debug_peer_list smtpd_access_maps
+
+ 6a # Postfix 2.10 and later support separate relay control and
+ 7a # spam control.
+ 8a smtpd_relay_restrictions =
+ 9a permit_mynetworks reject_unauth_destination
+ 10a smtpd_recipient_restrictions = ...spam blocking rules....
+
+ 6b # Older configurations combine relay control and spam control. To
+ 7b # use this with Postfix >= 2.10 specify "smtpd_relay_restrictions=".
+ 8b smtpd_recipient_restrictions =
+ 9b permit_mynetworks reject_unauth_destination
+ 10b ...spam blocking rules....
+
+ 11 relay_recipient_maps = hash:/etc/postfix/relay_recipients
+ 12 transport_maps = hash:/etc/postfix/transport
+ 13
+ 14 /etc/postfix/relay_recipients:
+ 15 user1@example.com x
+ 16 user2@example.com x
+ 17 . . .
+ 18
+ 19 /etc/postfix/transport:
+ 20 example.com smtp:[inside-gateway.example.com]
+
+Translation:
+
+ * Lines 1-10: Accept mail from local systems in $mynetworks, and accept mail
+ from outside for "user@example.com" but not for
+ "user@anything.example.com". The magic is in lines 4-5.
+
+ * Lines 11, 13-16: Define the list of valid addresses in the "example.com"
+ domain that can receive mail from the Internet. This prevents the mail
+ queue from filling up with undeliverable MAILER-DAEMON messages. If you
+ can't maintain a list of valid recipients then you must specify
+ "relay_recipient_maps =" (that is, an empty value), or you must specify an
+ "@example.com x" wild-card in the relay_recipients table.
+
+ * Lines 12, 19-20: Route mail for "example.com" to the inside gateway
+ machine. The [] forces Postfix to do no MX lookup.
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//rreellaayy__rreecciippiieennttss" whenever you change
+the relay_recipients table.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you change the
+transport table.
+
+In some installations, there may be separate instances of Postfix processing
+inbound and outbound mail on a multi-homed firewall. The inbound Postfix
+instance has an SMTP server listening on the external firewall interface, and
+the outbound Postfix instance has an SMTP server listening on the internal
+interface. In such a configuration is it is tempting to configure
+$inet_interfaces in each instance with just the corresponding interface
+address.
+
+In most cases, using inet_interfaces in this way will not work, because as
+documented in the $inet_interfaces reference manual, the smtp(8) delivery agent
+will also use the specified interface address as the source address for
+outbound connections and will be unable to reach hosts on "the other side" of
+the firewall. The symptoms are that the firewall is unable to connect to hosts
+that are in fact up. See the inet_interfaces parameter documentation for
+suggested work-arounds.
+
+DDeelliivveerriinngg ssoommee bbuutt nnoott aallll aaccccoouunnttss llooccaallllyy
+
+A drawback of sending mail as "user@example.com" (instead of
+"user@hostname.example.com") is that mail for "root" and other system accounts
+is also sent to the central mailhost. In order to deliver such accounts
+locally, you can set up virtual aliases as follows:
+
+ 1 /etc/postfix/main.cf:
+ 2 virtual_alias_maps = hash:/etc/postfix/virtual
+ 3
+ 4 /etc/postfix/virtual:
+ 5 root root@localhost
+ 6 . . .
+
+Translation:
+
+ * Line 5: As described in the virtual(5) manual page, the bare name "root"
+ matches "root@site" when "site" is equal to $myorigin, when "site" is
+ listed in $mydestination, or when it matches $inet_interfaces or
+ $proxy_interfaces.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after editing the file.
+
+RRuunnnniinngg PPoossttffiixx bbeehhiinndd aa ffiirreewwaallll
+
+The simplest way to set up Postfix on a host behind a firewalled network is to
+send all mail to a gateway host, and to let that mail host take care of
+internal and external forwarding. Examples of that are shown in the local area
+network section above. A more sophisticated approach is to send only external
+mail to the gateway host, and to send intranet mail directly.
+
+Note: this example requires Postfix version 2.0 and later. To find out what
+Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
+
+The following example presents additional configuration. You need to combine
+this with basic configuration information as discussed the first half of this
+document.
+
+ 1 /etc/postfix/main.cf:
+ 2 transport_maps = hash:/etc/postfix/transport
+ 3 relayhost =
+ 4 # Optional for a machine that isn't "always on"
+ 5 #fallback_relay = [gateway.example.com]
+ 6
+ 7 /etc/postfix/transport:
+ 8 # Internal delivery.
+ 9 example.com :
+ 10 .example.com :
+ 11 # External delivery.
+ 12 * smtp:[gateway.example.com]
+
+Translation:
+
+ * Lines 2, 7-12: Request that intranet mail is delivered directly, and that
+ external mail is given to a gateway. Obviously, this example assumes that
+ the organization uses DNS MX records internally. The [] forces Postfix to
+ do no MX lookup.
+
+ * Line 3: IMPORTANT: do not specify a relayhost in main.cf.
+
+ * Line 5: This prevents mail from being stuck in the queue when the machine
+ is turned off. Postfix tries to deliver mail directly, and gives
+ undeliverable mail to a gateway.
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you edit the
+transport table.
+
+CCoonnffiigguurriinngg PPoossttffiixx aass pprriimmaarryy oorr bbaacckkuupp MMXX hhoosstt ffoorr aa rreemmoottee ssiittee
+
+This section presents additional configuration. You need to combine this with
+basic configuration information as discussed the first half of this document.
+
+When your system is SECONDARY MX host for a remote site this is all you need:
+
+ 1 DNS:
+ 2 the.backed-up.domain.tld IN MX 100 your.machine.tld.
+ 3
+ 4 /etc/postfix/main.cf:
+ 5 relay_domains = . . . the.backed-up.domain.tld
+
+ 6a # Postfix 2.10 and later support separate relay control and
+ 7a # spam control.
+ 8a smtpd_relay_restrictions =
+ 9a permit_mynetworks reject_unauth_destination
+ 10a smtpd_recipient_restrictions = ...spam blocking rules....
+
+ 6b # Older configurations combine relay control and spam control. To
+ 7b # use this with Postfix >= 2.10 specify "smtpd_relay_restrictions=".
+ 8b smtpd_recipient_restrictions =
+ 9b permit_mynetworks reject_unauth_destination
+ 10b ...spam blocking rules....
+
+ 11 # You must specify your NAT/proxy external address.
+ 12 #proxy_interfaces = 1.2.3.4
+ 13
+ 14 relay_recipient_maps = hash:/etc/postfix/relay_recipients
+ 15
+ 16 /etc/postfix/relay_recipients:
+ 17 user1@the.backed-up.domain.tld x
+ 18 user2@the.backed-up.domain.tld x
+ 19 . . .
+
+When your system is PRIMARY MX host for a remote site you need the above, plus:
+
+ 20 /etc/postfix/main.cf:
+ 21 transport_maps = hash:/etc/postfix/transport
+ 22
+ 23 /etc/postfix/transport:
+ 24 the.backed-up.domain.tld relay:[their.mail.host.tld]
+
+Important notes:
+
+ * Do not list the.backed-up.domain.tld in mydestination.
+
+ * Do not list the.backed-up.domain.tld in virtual_alias_domains.
+
+ * Do not list the.backed-up.domain.tld in virtual_mailbox_domains.
+
+ * Lines 1-9: Forward mail from the Internet for "the.backed-up.domain.tld" to
+ the primary MX host for that domain.
+
+ * Line 12: This is a must if Postfix receives mail via a NAT relay or proxy
+ that presents a different IP address to the world than the local machine.
+
+ * Lines 14-18: Define the list of valid addresses in the "the.backed-
+ up.domain.tld" domain. This prevents your mail queue from filling up with
+ undeliverable MAILER-DAEMON messages. If you can't maintain a list of valid
+ recipients then you must specify "relay_recipient_maps =" (that is, an
+ empty value), or you must specify an "@the.backed-up.domain.tld x" wild-
+ card in the relay_recipients table.
+
+ * Line 24: The [] forces Postfix to do no MX lookup.
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you change the
+transport table.
+
+NOTE for Postfix < 2.2: Do not use the fallback_relay feature when relaying
+mail for a backup or primary MX domain. Mail would loop between the Postfix MX
+host and the fallback_relay host when the final destination is unavailable.
+
+ * In main.cf specify "relay_transport = relay",
+ * In master.cf specify "-o fallback_relay =" at the end of the relay entry.
+ * In transport maps, specify "relay:nexthop..." as the right-hand side for
+ backup or primary MX domain entries.
+
+These are default settings in Postfix version 2.2 and later.
+
+PPoossttffiixx oonn aa ddiiaalluupp mmaacchhiinnee
+
+This section applies to dialup connections that are down most of the time. For
+dialup connections that are up 24x7, see the local area network section above.
+
+This section presents additional configuration. You need to combine this with
+basic configuration information as discussed the first half of this document.
+
+If you do not have your own hostname and IP address (usually with dialup, cable
+TV or DSL connections) then you should also study the section on "Postfix on
+hosts without a real Internet hostname".
+
+ * Route all outgoing mail to your network provider.
+ If your machine is disconnected most of the time, there isn't a lot of
+ opportunity for Postfix to deliver mail to hard-to-reach corners of the
+ Internet. It's better to give the mail to a machine that is connected all
+ the time. In the example below, the [] prevents Postfix from trying to look
+ up DNS MX records.
+
+ /etc/postfix/main.cf:
+ relayhost = [smtprelay.someprovider.com]
+
+ * Disable spontaneous SMTP mail delivery (if using on-demand dialup IP only).
+
+ Normally, Postfix attempts to deliver outbound mail at its convenience. If
+ your machine uses on-demand dialup IP, this causes your system to place a
+ telephone call whenever you submit new mail, and whenever Postfix retries
+ to deliver delayed mail. To prevent such telephone calls from being placed,
+ disable spontaneous SMTP mail deliveries.
+
+ /etc/postfix/main.cf:
+ defer_transports = smtp (Only for on-demand dialup IP hosts)
+
+ * Disable SMTP client DNS lookups (dialup LAN only).
+
+ /etc/postfix/main.cf:
+ disable_dns_lookups = yes (Only for on-demand dialup IP hosts)
+
+ * Flush the mail queue whenever the Internet link is established.
+ Put the following command into your PPP or SLIP dialup scripts:
+
+ /usr/sbin/sendmail -q (whenever the Internet link is up)
+
+ The exact location of the Postfix sendmail command is system-specific. Use
+ the command "ppoossttccoonnff sseennddmmaaiill__ppaatthh" to find out where the Postfix sendmail
+ command is located on your machine.
+
+ In order to find out if the mail queue is flushed, use something like:
+
+ #!/bin/sh
+
+ # Start mail deliveries.
+ /usr/sbin/sendmail -q
+
+ # Allow deliveries to start.
+ sleep 10
+
+ # Loop until all messages have been tried at least once.
+ while mailq | grep '^[^ ]*\*' >/dev/null
+ do
+ sleep 10
+ done
+
+ If you have disabled spontaneous SMTP mail delivery, you also need to run
+ the "sseennddmmaaiill --qq" command every now and then while the dialup link is up,
+ so that newly-posted mail is flushed from the queue.
+
+PPoossttffiixx oonn hhoossttss wwiitthhoouutt aa rreeaall IInntteerrnneett hhoossttnnaammee
+
+This section is for hosts that don't have their own Internet hostname.
+Typically these are systems that get a dynamic IP address via DHCP or via
+dialup. Postfix will let you send and receive mail just fine between accounts
+on a machine with a fantasy name. However, you cannot use a fantasy hostname in
+your email address when sending mail into the Internet, because no-one would be
+able to reply to your mail. In fact, more and more sites refuse mail addresses
+with non-existent domain names.
+
+Note: the following information is Postfix version dependent. To find out what
+Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
+
+SSoolluuttiioonn 11:: PPoossttffiixx vveerrssiioonn 22..22 aanndd llaatteerr
+
+Postfix 2.2 uses the generic(5) address mapping to replace local fantasy email
+addresses by valid Internet addresses. This mapping happens ONLY when mail
+leaves the machine; not when you send mail between users on the same machine.
+
+The following example presents additional configuration. You need to combine
+this with basic configuration information as discussed the first half of this
+document.
+
+ 1 /etc/postfix/main.cf:
+ 2 smtp_generic_maps = hash:/etc/postfix/generic
+ 3
+ 4 /etc/postfix/generic:
+ 5 his@localdomain.local hisaccount@hisisp.example
+ 6 her@localdomain.local heraccount@herisp.example
+ 7 @localdomain.local hisaccount+local@hisisp.example
+
+When mail is sent to a remote host via SMTP:
+
+ * Line 5 replaces his@localdomain.local by his ISP mail address,
+
+ * Line 6 replaces her@localdomain.local by her ISP mail address, and
+
+ * Line 7 replaces other local addresses by his ISP account, with an address
+ extension of +local (this example assumes that the ISP supports "+" style
+ address extensions).
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ggeenneerriicc" whenever you change the
+generic table.
+
+SSoolluuttiioonn 22:: PPoossttffiixx vveerrssiioonn 22..11 aanndd eeaarrlliieerr
+
+The solution with older Postfix systems is to use valid Internet addresses
+where possible, and to let Postfix map valid Internet addresses to local
+fantasy addresses. With this, you can send mail to the Internet and to local
+fantasy addresses, including mail to local fantasy addresses that don't have a
+valid Internet address of their own.
+
+The following example presents additional configuration. You need to combine
+this with basic configuration information as discussed the first half of this
+document.
+
+ 1 /etc/postfix/main.cf:
+ 2 myhostname = hostname.localdomain
+ 3 mydomain = localdomain
+ 4
+ 5 canonical_maps = hash:/etc/postfix/canonical
+ 6
+ 7 virtual_alias_maps = hash:/etc/postfix/virtual
+ 8
+ 9 /etc/postfix/canonical:
+ 10 your-login-name your-account@your-isp.com
+ 11
+ 12 /etc/postfix/virtual:
+ 13 your-account@your-isp.com your-login-name
+
+Translation:
+
+ * Lines 2-3: Substitute your fantasy hostname here. Do not use a domain name
+ that is already in use by real organizations on the Internet. See RFC 2606
+ for examples of domain names that are guaranteed not to be owned by anyone.
+
+ * Lines 5, 9, 10: This provides the mapping from "your-login-
+ name@hostname.localdomain" to "your-account@your-isp.com". This part is
+ required.
+
+ * Lines 7, 12, 13: Deliver mail for "your-account@your-isp.com" locally,
+ instead of sending it to the ISP. This part is not required but is
+ convenient.
+
+Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
+To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ccaannoonniiccaall" whenever you change the
+canonical table.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" whenever you change the
+virtual table.
+
diff --git a/README_FILES/STRESS_README b/README_FILES/STRESS_README
new file mode 100644
index 0000000..85b73f5
--- /dev/null
+++ b/README_FILES/STRESS_README
@@ -0,0 +1,426 @@
+PPoossttffiixx SSttrreessss--DDeeppeennddeenntt CCoonnffiigguurraattiioonn
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+This document describes the symptoms of Postfix SMTP server overload. It
+presents permanent main.cf changes to avoid overload during normal operation,
+and temporary main.cf changes to cope with an unexpected burst of mail. This
+document makes specific suggestions for Postfix 2.5 and later which support
+stress-adaptive behavior, and for earlier Postfix versions that don't.
+
+Topics covered in this document:
+
+ * Symptoms of Postfix SMTP server overload
+ * Automatic stress-adaptive behavior
+ * Service more SMTP clients at the same time
+ * Spend less time per SMTP client
+ * Disconnect suspicious SMTP clients
+ * Temporary measures for older Postfix releases
+ * Detecting support for stress-adaptive behavior
+ * Forcing stress-adaptive behavior on or off
+ * Other measures to off-load zombies
+ * Credits
+
+SSyymmppttoommss ooff PPoossttffiixx SSMMTTPP sseerrvveerr oovveerrllooaadd
+
+Under normal conditions, the Postfix SMTP server responds immediately when an
+SMTP client connects to it; the time to deliver mail is noticeable only with
+large messages. Performance degrades dramatically when the number of SMTP
+clients exceeds the number of Postfix SMTP server processes. When an SMTP
+client connects while all Postfix SMTP server processes are busy, the client
+must wait until a server process becomes available.
+
+SMTP server overload may be caused by a surge of legitimate mail (example: a
+DNS registrar opens a new zone for registrations), by mistake (mail explosion
+caused by a forwarding loop) or by malice (worm outbreak, botnet, or other
+illegitimate activity).
+
+Symptoms of Postfix SMTP server overload are:
+
+ * Remote SMTP clients experience a long delay before Postfix sends the "220
+ hostname.example.com ESMTP Postfix" greeting.
+
+ o NOTE: Broken DNS configurations can also cause lengthy delays before
+ Postfix sends "220 hostname.example.com ...". These delays also exist
+ when Postfix is NOT overloaded.
+
+ o NOTE: To avoid "overload" delays for end-user mail clients, enable the
+ "submission" service entry in master.cf (present since Postfix 2.1),
+ and tell users to connect to this instead of the public SMTP service.
+
+ * The Postfix SMTP server logs an increased number of "lost connection after
+ CONNECT" events. This happens because remote SMTP clients disconnect before
+ Postfix answers the connection.
+
+ o NOTE: A portscan for open SMTP ports can also result in "lost
+ connection ..." logfile messages.
+
+ * Postfix 2.3 and later logs a warning that all server ports are busy:
+
+ Oct 3 20:39:27 spike postfix/master[28905]: warning: service "smtp"
+ (25) has reached its process limit "30": new clients may experience
+ noticeable delays
+ Oct 3 20:39:27 spike postfix/master[28905]: warning: to avoid this
+ condition, increase the process count in master.cf or reduce the
+ service time per client
+ Oct 3 20:39:27 spike postfix/master[28905]: warning: see
+ http://www.postfix.org/STRESS_README.html for examples of
+ stress-adapting configuration settings
+
+Legitimate mail that doesn't get through during an episode of Postfix SMTP
+server overload is not necessarily lost. It should still arrive once the
+situation returns to normal, as long as the overload condition is temporary.
+
+AAuuttoommaattiicc ssttrreessss--aaddaappttiivvee bbeehhaavviioorr
+
+Postfix version 2.5 introduces automatic stress-adaptive behavior. It works as
+follows. When a "public" network service such as the SMTP server runs into an
+"all server ports are busy" condition, the Postfix master(8) daemon logs a
+warning, restarts the service (without interrupting existing network sessions),
+and runs the service with "-o stress=yes" on the server process command line:
+
+ 80821 ?? S 0:00.24 smtpd -n smtp -t inet -u -c -o stress=yes
+
+Normally, the Postfix master(8) daemon runs such a service with "-o stress=" on
+the command line (i.e. with an empty parameter value):
+
+ 83326 ?? S 0:00.28 smtpd -n smtp -t inet -u -c -o stress=
+
+Services that have local access only never have "-o stress" parameters on the
+command line. This includes services internal to Postfix such as the queue
+manager, and services that listen on a loopback interface only, such as after-
+filter SMTP services.
+
+The "stress" parameter value is the key to making main.cf parameter settings
+stress adaptive. The following settings are the default with Postfix 2.6 and
+later.
+
+ 1 smtpd_timeout = ${stress?{10}:{300}}s
+ 2 smtpd_hard_error_limit = ${stress?{1}:{20}}
+ 3 smtpd_junk_command_limit = ${stress?{1}:{100}}
+ 4 # Parameters added after Postfix 2.6:
+ 5 smtpd_per_record_deadline = ${stress?{yes}:{no}}
+ 6 smtpd_starttls_timeout = ${stress?{10}:{300}}s
+ 7 address_verify_poll_count = ${stress?{1}:{3}}
+
+With Postfix versions before 3.0, replace ${stress?{x}:{y}} with ${stress?x}$
+{stress:y}.
+
+Translation:
+
+ * Line 1: under conditions of stress, use an smtpd_timeout value of 10
+ seconds instead of the default 300 seconds. Experience on the postfix-users
+ list from a variety of sysadmins shows that reducing the "normal"
+ smtpd_timeout to 60s is unlikely to affect legitimate clients. However, it
+ is unlikely to become the Postfix default because it's not RFC compliant.
+ Setting smtpd_timeout to 10s or even 5s under stress will still allow most
+ legitimate clients to connect and send mail, but may delay mail from some
+ clients. No mail should be lost, as long as this measure is used only
+ temporarily.
+
+ * Line 2: under conditions of stress, use an smtpd_hard_error_limit of 1
+ instead of the default 20. This helps by disconnecting clients after a
+ single error, giving other clients a chance to connect. However, this may
+ cause significant delays with legitimate mail, such as a mailing list that
+ contains a few no-longer-active user names that didn't bother to
+ unsubscribe. No mail should be lost, as long as this measure is used only
+ temporarily.
+
+ * Line 3: under conditions of stress, use an smtpd_junk_command_limit of 1
+ instead of the default 100. This prevents clients from keeping connections
+ open by repeatedly sending HELO, EHLO, NOOP, RSET, VRFY or ETRN commands.
+
+ * Line 5: under conditions of stress, change the behavior of smtpd_timeout
+ and smtpd_starttls_timeout, from a time limit per read or write system
+ call, to a time limit to send or receive a complete record (an SMTP command
+ line, SMTP response line, SMTP message content line, or TLS protocol
+ message).
+
+ * Line 6: under conditions of stress, reduce the time limit for TLS protocol
+ handshake messages to 10 seconds, from the default value of 300 seconds.
+ See also the smtpd_timeout discussion above.
+
+ * Line 7: under conditions of stress, do not wait up to 6 seconds for the
+ completion of an address verification probe. If the result is not already
+ in the address verification cache, reply immediately with
+ $unverified_recipient_tempfail_action or
+ $unverified_sender_tempfail_action. No mail should be lost, as long as this
+ measure is used only temporarily.
+
+The syntax of ${name?value} and ${name:value} is explained at the beginning of
+the postconf(5) manual page.
+
+NOTE: Please keep in mind that the stress-adaptive feature is a fairly
+desperate measure to keep ssoommee legitimate mail flowing under overload
+conditions. If a site is reaching the SMTP server process limit when there
+isn't an attack or bot flood occurring, then either the process limit needs to
+be raised or more hardware needs to be added.
+
+SSeerrvviiccee mmoorree SSMMTTPP cclliieennttss aatt tthhee ssaammee ttiimmee
+
+This section and the ones that follow discuss permanent measures against mail
+server overload.
+
+One measure to avoid the "all server processes busy" condition is to service
+more SMTP clients simultaneously. For this you need to increase the number of
+Postfix SMTP server processes. This will improve the responsiveness for remote
+SMTP clients, as long as the server machine has enough hardware and software
+resources to run the additional processes, and as long as the file system can
+keep up with the additional load.
+
+ * You increase the number of SMTP server processes either by increasing the
+ default_process_limit in main.cf (line 3 below), or by increasing the SMTP
+ server's "maxproc" field in master.cf (line 10 below). Either way, you need
+ to issue a "postfix reload" command to make the change effective.
+
+ * Process limits above 1000 require Postfix version 2.4 or later, and an
+ operating system that supports kernel-based event filters (BSD kqueue(2),
+ Linux epoll(4), or Solaris /dev/poll).
+
+ * More processes use more memory. You can reduce the Postfix memory footprint
+ by using cdb: lookup tables instead of Berkeley DB's hash: or btree:
+ tables.
+
+ 1 /etc/postfix/main.cf:
+ 2 # Raise the global process limit, 100 since Postfix 2.0.
+ 3 default_process_limit = 200
+ 4
+ 5 /etc/postfix/master.cf:
+ 6 # =============================================================
+ 7 # service type private unpriv chroot wakeup maxproc command
+ 8 # =============================================================
+ 9 # Raise the SMTP service process limit only.
+ 10 smtp inet n - n - 200 smtpd
+
+ * NOTE: older versions of the SMTPD_POLICY_README document contain a mistake:
+ they configure a fixed number of policy daemon processes. When you raise
+ the SMTP server's "maxproc" field in master.cf, SMTP server processes will
+ report problems when connecting to policy server processes, because there
+ aren't enough of them. Examples of errors are "connection refused" or
+ "operation timed out".
+
+ To fix, edit master.cf and specify a zero "maxproc" field in all policy
+ server entries; see line 6 in the example below. Issue a "postfix reload"
+ command to make the change effective.
+
+ 1 /etc/postfix/master.cf:
+ 2 # =============================================================
+ 3 # service type private unpriv chroot wakeup maxproc command
+ 4 # =============================================================
+ 5 # Disable the policy service process limit.
+ 6 policy unix - n n - 0 spawn
+ 7 user=nobody argv=/some/where/policy-server
+
+SSppeenndd lleessss ttiimmee ppeerr SSMMTTPP cclliieenntt
+
+When increasing the number of SMTP server processes is not practical, you can
+improve Postfix server responsiveness by eliminating delays. When Postfix
+spends less time per SMTP session, the same number of SMTP server processes can
+service more clients in a given amount of time.
+
+ * Eliminate non-functional RBL lookups (blocklists that are no longer in
+ operation). These lookups can degrade performance. Postfix logs a warning
+ when an RBL server does not respond.
+
+ * Eliminate redundant RBL lookups (people often use multiple Spamhaus RBLs
+ that include each other). To find out whether RBLs include other RBLs, look
+ up the websites that document the RBL's policies.
+
+ * Eliminate header_checks and body_checks, and keep just a few emergency
+ patterns to block the latest worm explosion or backscatter mail. See
+ BACKSCATTER_README for examples of the latter.
+
+ * Group your header_checks and body_checks patterns to avoid unnecessary
+ pattern matching operations:
+
+ 1 /etc/postfix/header_checks:
+ 2 if /^Subject:/
+ 3 /^Subject: virus found in mail from you/ reject
+ 4 /^Subject: ..other../ reject
+ 5 endif
+ 6
+ 7 if /^Received:/
+ 8 /^Received: from (postfix\.org) / reject forged client name in
+ received header: $1
+ 9 /^Received: from ..other../ reject ....
+ 10 endif
+
+DDiissccoonnnneecctt ssuussppiicciioouuss SSMMTTPP cclliieennttss
+
+Under conditions of overload you can improve Postfix SMTP server responsiveness
+by hanging up on suspicious clients, so that other clients get a chance to talk
+to Postfix.
+
+ * Use "521" SMTP reply codes (Postfix 2.6 and later) or "421" (Postfix 2.3-
+ 2.5) to hang up on clients that that match botnet-related RBLs (see next
+ bullet) or that match selected non-RBL restrictions such as SMTP access
+ maps. The Postfix SMTP server will reject mail and disconnect without
+ waiting for the remote SMTP client to send a QUIT command.
+
+ * To hang up connections from blacklisted zombies, you can set specific
+ Postfix SMTP server reject codes for specific RBLs, and for individual
+ responses from specific RBLs. We'll use zen.spamhaus.org as an example; by
+ the time you read this document, details may have changed. Right now, their
+ documents say that a response of 127.0.0.10 or 127.0.0.11 indicates a
+ dynamic client IP address, which means that the machine is probably running
+ a bot of some kind. To give a 521 response instead of the default 554
+ response, use something like:
+
+ 1 /etc/postfix/main.cf:
+ 2 smtpd_client_restrictions =
+ 3 permit_mynetworks
+ 4 reject_rbl_client zen.spamhaus.org=127.0.0.10
+ 5 reject_rbl_client zen.spamhaus.org=127.0.0.11
+ 6 reject_rbl_client zen.spamhaus.org
+ 7
+ 8 rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps
+ 9
+ 10 /etc/postfix/rbl_reply_maps:
+ 11 # With Postfix 2.3-2.5 use "421" to hang up connections.
+ 12 zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable;
+ 13 $rbl_class [$rbl_what] blocked using
+ 14 $rbl_domain${rbl_reason?; $rbl_reason}
+ 15
+ 16 zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable;
+ 17 $rbl_class [$rbl_what] blocked using
+ 18 $rbl_domain${rbl_reason?; $rbl_reason}
+
+ Although the above example shows three RBL lookups (lines 4-6), Postfix
+ will only do a single DNS query, so it does not affect the performance.
+
+ * With Postfix 2.3-2.5, use reply code 421 (521 will not cause Postfix to
+ disconnect). The down-side of replying with 421 is that it works only for
+ zombies and other malware. If the client is running a real MTA, then it may
+ connect again several times until the mail expires in its queue. When this
+ is a problem, stick with the default 554 reply, and use
+ "smtpd_hard_error_limit = 1" as described below.
+
+ * You can automatically turn on the above overload measure with Postfix 2.5
+ and later, or with earlier releases that contain the stress-adaptive
+ behavior source code patch from the mirrors listed at http://
+ www.postfix.org/download.html. Simply replace line above 8 with:
+
+ 8 rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
+
+More information about automatic stress-adaptive behavior is in section
+"Automatic stress-adaptive behavior".
+
+TTeemmppoorraarryy mmeeaassuurreess ffoorr oollddeerr PPoossttffiixx rreelleeaasseess
+
+See the next section, "Automatic stress-adaptive behavior", if you are running
+Postfix version 2.5 or later, or if you have applied the source code patch for
+stress-adaptive behavior from the mirrors listed at http://www.postfix.org/
+download.html.
+
+The following measures can be applied temporarily during overload. They still
+allow mmoosstt legitimate clients to connect and send mail, but may affect some
+legitimate clients.
+
+ * Reduce smtpd_timeout (default: 300s). Experience on the postfix-users list
+ from a variety of sysadmins shows that reducing the "normal" smtpd_timeout
+ to 60s is unlikely to affect legitimate clients. However, it is unlikely to
+ become the Postfix default because it's not RFC compliant. Setting
+ smtpd_timeout to 10s (line 2 below) or even 5s under stress will still
+ allow mmoosstt legitimate clients to connect and send mail, but may delay mail
+ from some clients. No mail should be lost, as long as this measure is used
+ only temporarily.
+
+ * Reduce smtpd_hard_error_limit (default: 20). Setting this to 1 under stress
+ (line 3 below) helps by disconnecting clients after a single error, giving
+ other clients a chance to connect. However, this may cause significant
+ delays with legitimate mail, such as a mailing list that contains a few no-
+ longer-active user names that didn't bother to unsubscribe. No mail should
+ be lost, as long as this measure is used only temporarily.
+
+ * Use an smtpd_junk_command_limit of 1 instead of the default 100. This
+ prevents clients from keeping idle connections open by repeatedly sending
+ NOOP or RSET commands.
+
+ 1 /etc/postfix/main.cf:
+ 2 smtpd_timeout = 10
+ 3 smtpd_hard_error_limit = 1
+ 4 smtpd_junk_command_limit = 1
+
+With these measures, no mail should be lost, as long as these measures are used
+only temporarily. The next section of this document introduces a way to
+automate this process.
+
+DDeetteeccttiinngg ssuuppppoorrtt ffoorr ssttrreessss--aaddaappttiivvee bbeehhaavviioorr
+
+To find out if your Postfix installation supports stress-adaptive behavior, use
+the "ps" command, and look for the smtpd processes. Postfix has stress-adaptive
+support when you see "-o stress=" or "-o stress=yes" command-line options.
+Remember that Postfix never enables stress-adaptive behavior on servers that
+listen on local addresses only.
+
+The following example is for FreeBSD or Linux. On Solaris, HP-UX and other
+System-V flavors, use "ps -ef" instead of "ps ax".
+
+ $ ps ax|grep smtpd
+ 83326 ?? S 0:00.28 smtpd -n smtp -t inet -u -c -o stress=
+ 84345 ?? Ss 0:00.11 /usr/bin/perl /usr/libexec/postfix/smtpd-
+ policy.pl
+
+You can't use postconf(1) to detect stress-adaptive support. The postconf(1)
+command ignores the existence of the stress parameter in main.cf, because the
+parameter has no effect there. Command-line "-o parameter" settings always take
+precedence over main.cf parameter settings.
+
+If you configure stress-adaptive behavior in main.cf when it isn't supported,
+nothing bad will happen. The processes will run as if the stress parameter
+always has an empty value.
+
+FFoorrcciinngg ssttrreessss--aaddaappttiivvee bbeehhaavviioorr oonn oorr ooffff
+
+You can manually force stress-adaptive behavior on, by adding a "-o stress=yes"
+command-line option in master.cf. This can be useful for testing overrides on
+the SMTP service. Issue "postfix reload" to make the change effective.
+
+Note: setting the stress parameter in main.cf has no effect for services that
+accept remote connections.
+
+ 1 /etc/postfix/master.cf:
+ 2 # =============================================================
+ 3 # service type private unpriv chroot wakeup maxproc command
+ 4 # =============================================================
+ 5 #
+ 6 smtp inet n - n - - smtpd
+ 7 -o stress=yes
+ 8 -o . . .
+
+To permanently force stress-adaptive behavior off with a specific service,
+specify "-o stress=" on its master.cf command line. This may be desirable for
+the "submission" service. Issue "postfix reload" to make the change effective.
+
+Note: setting the stress parameter in main.cf has no effect for services that
+accept remote connections.
+
+ 1 /etc/postfix/master.cf:
+ 2 # =============================================================
+ 3 # service type private unpriv chroot wakeup maxproc command
+ 4 # =============================================================
+ 5 #
+ 6 submission inet n - n - - smtpd
+ 7 -o stress=
+ 8 -o . . .
+
+OOtthheerr mmeeaassuurreess ttoo ooffff--llooaadd zzoommbbiieess
+
+The postscreen(8) daemon, introduced with Postfix 2.8, provides additional
+protection against mail server overload. One postscreen(8) process handles
+multiple inbound SMTP connections, and decides which clients may to talk to a
+Postfix SMTP server process. By keeping spambots away, postscreen(8) leaves
+more SMTP server processes available for legitimate clients, and delays the
+onset of server overload conditions.
+
+CCrreeddiittss
+
+ * Thanks to the postfix-users mailing list members for sharing early
+ experiences with the stress-adaptive feature.
+ * The RBL example and several other paragraphs of text were adapted from
+ postfix-users postings by Noel Jones.
+ * Wietse implemented stress-adaptive behavior as the smallest possible patch
+ while he should be working on other things.
+
diff --git a/README_FILES/TLS_LEGACY_README b/README_FILES/TLS_LEGACY_README
new file mode 100644
index 0000000..e9f36fd
--- /dev/null
+++ b/README_FILES/TLS_LEGACY_README
@@ -0,0 +1,1119 @@
+PPoossttffiixx lleeggaaccyy TTLLSS SSuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+NNOOTTEE
+
+This document describes an old TLS user interface that is based on a third-
+party TLS patch by Lutz Jänicke. As of Postfix version 2.3, the old user
+interface still exists to allow migration from earlier Postfix releases, but
+its functionality is frozen.
+
+WWhhaatt PPoossttffiixx TTLLSS ssuuppppoorrtt ddooeess ffoorr yyoouu
+
+Transport Layer Security (TLS, formerly called SSL) provides certificate-based
+authentication and encrypted sessions. An encrypted session protects the
+information that is transmitted with SMTP mail or with SASL authentication.
+
+Postfix version 2.2 introduces support for TLS as described in RFC 3207. TLS
+Support for older Postfix versions was available as an add-on patch. The
+section "Compatibility with Postfix < 2.2 TLS support" below discusses the
+differences between these implementations.
+
+Topics covered in this document:
+
+ * How Postfix TLS support works
+ * Building Postfix with TLS support
+ * SMTP Server specific settings
+ * SMTP Client specific settings
+ * TLS manager specific settings
+ * Reporting problems
+ * Compatibility with Postfix < 2.2 TLS support
+ * Credits
+
+And last but not least, for the impatient:
+
+ * Getting started, quick and dirty
+
+HHooww PPoossttffiixx TTLLSS ssuuppppoorrtt wwoorrkkss
+
+The diagram below shows the main elements of the Postfix TLS architecture and
+their relationships. Colored boxes with numbered names represent Postfix daemon
+programs. Other colored boxes represent storage elements.
+
+ * The smtpd(8) server implements the SMTP over TLS server side.
+
+ * The smtp(8) client implements the SMTP over TLS client side.
+
+ * The tlsmgr(8) server maintains the pseudo-random number generator (PRNG)
+ that seeds the TLS engines in the smtpd(8) server and smtp(8) client
+ processes, and maintains the TLS session key cache files.
+
+ <---seed--- ---seed--->
+Network-> smtpd(8) tlsmgr(8) smtp(8) ->Network
+ <-session-> <-session->
+
+ / | \
+ |
+ / \
+
+ smtpd PRNG smtp
+ session state session
+ key cache file key cache
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh TTLLSS ssuuppppoorrtt
+
+To build Postfix with TLS support, first we need to generate the make(1) files
+with the necessary definitions. This is done by invoking the command "make
+makefiles" in the Postfix top-level directory and with arguments as shown next.
+
+NNOOTTEE:: DDoo nnoott uussee GGnnuu TTLLSS.. IItt wwiillll ssppoonnttaanneeoouussllyy tteerrmmiinnaattee aa PPoossttffiixx ddaaeemmoonn
+pprroocceessss wwiitthh eexxiitt ssttaattuuss ccooddee 22,, iinnsstteeaadd ooff aalllloowwiinngg PPoossttffiixx ttoo 11)) rreeppoorrtt tthhee
+eerrrroorr ttoo tthhee mmaaiilllloogg ffiillee,, aanndd ttoo 22)) pprroovviiddee ppllaaiinntteexxtt sseerrvviiccee wwhheerree tthhiiss iiss
+aapppprroopprriiaattee..
+
+ * If the OpenSSL include files (such as ssl.h) are in directory /usr/include/
+ openssl, and the OpenSSL libraries (such as libssl.so and libcrypto.so) are
+ in directory /usr/lib:
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__TTLLSS"" AAUUXXLLIIBBSS==""--llssssll --llccrryyppttoo""
+
+ * If the OpenSSL include files (such as ssl.h) are in directory /usr/local/
+ include/openssl, and the OpenSSL libraries (such as libssl.so and
+ libcrypto.so) are in directory /usr/local/lib:
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__TTLLSS --II//uussrr//llooccaall//iinncclluuddee"" \\
+ AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb --llssssll --llccrryyppttoo""
+
+ On Solaris, specify the -R option as shown below:
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__TTLLSS --II//uussrr//llooccaall//iinncclluuddee"" \\
+ AAUUXXLLIIBBSS==""--RR//uussrr//llooccaall//lliibb --LL//uussrr//llooccaall//lliibb --llssssll --llccrryyppttoo""
+
+If you need to apply other customizations (such as Berkeley DB databases,
+MySQL, PosgreSQL, LDAP or SASL), see the respective Postfix README documents,
+and combine their "make makefiles" instructions with the instructions above:
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__TTLLSS \\
+ ((ootthheerr --DD oorr --II ooppttiioonnss))"" \\
+ AAUUXXLLIIBBSS==""--llssssll --llccrryyppttoo \\
+ ((ootthheerr --ll ooppttiioonnss ffoorr lliibbrraarriieess iinn //uussrr//lliibb)) \\
+ ((--LL//ppaatthh//nnaammee ++ --ll ooppttiioonnss ffoorr ootthheerr lliibbrraarriieess))""
+
+To complete the build process, see the Postfix INSTALL instructions. Postfix
+has TLS support turned off by default, so you can start using Postfix as soon
+as it is installed.
+
+SSMMTTPP SSeerrvveerr ssppeecciiffiicc sseettttiinnggss
+
+Topics covered in this section:
+
+ * Server-side certificate and private key configuration
+ * Server-side TLS activity logging
+ * Enabling TLS in the Postfix SMTP server
+ * Client certificate verification
+ * Supporting AUTH over TLS only
+ * Server-side TLS session cache
+ * Server access control
+ * Server-side cipher controls
+ * Miscellaneous server controls
+
+SSeerrvveerr--ssiiddee cceerrttiiffiiccaattee aanndd pprriivvaattee kkeeyy ccoonnffiigguurraattiioonn
+
+In order to use TLS, the Postfix SMTP server needs a certificate and a private
+key. Both must be in "pem" format. The private key must not be encrypted,
+meaning: the key must be accessible without password. Both certificate and
+private key may be in the same file.
+
+Both RSA and DSA certificates are supported. Typically you will only have RSA
+certificates issued by a commercial CA. In addition, the tools supplied with
+OpenSSL will by default issue RSA certificates. You can have both at the same
+time, in which case the cipher used determines which certificate is presented.
+For Netscape and OpenSSL clients without special cipher choices, the RSA
+certificate is preferred.
+
+In order for remote SMTP clients to check the Postfix SMTP server certificates,
+the CA certificate (in case of a certificate chain, all CA certificates) must
+be available. You should add these certificates to the server certificate, the
+server certificate first, then the issuing CA(s).
+
+Example: the certificate for "server.dom.ain" was issued by "intermediate CA"
+which itself has a certificate issued by "root CA". Create the server.pem file
+with:
+
+ % ccaatt sseerrvveerr__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> sseerrvveerr..ppeemm
+
+A Postfix SMTP server certificate supplied here must be usable as SSL server
+certificate and hence pass the "openssl verify -purpose sslserver ..." test.
+
+A client that trusts the root CA has a local copy of the root CA certificate,
+so it is not necessary to include the root CA certificate here. Leaving it out
+of the "server.pem" file reduces the overhead of the TLS exchange.
+
+If you want the Postfix SMTP server to accept remote SMTP client certificates
+issued by these CAs, append the root certificate to $smtpd_tls_CAfile or
+install it in the $smtpd_tls_CApath directory. When you configure trust in a
+root CA, it is not necessary to explicitly trust intermediary CAs signed by the
+root CA, unless $smtpd_tls_ccert_verifydepth is less than the number of CAs in
+the certificate chain for the clients of interest. With a verify depth of 1 you
+can only verify certificates directly signed by a trusted CA, and all trusted
+intermediary CAs need to be configured explicitly. With a verify depth of 2 you
+can verify clients signed by a root CA or a direct intermediary CA (so long as
+the client is correctly configured to supply its intermediate CA certificate).
+
+RSA key and certificate examples:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_cert_file = /etc/postfix/server.pem
+ smtpd_tls_key_file = $smtpd_tls_cert_file
+
+Their DSA counterparts:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem
+ smtpd_tls_dkey_file = $smtpd_tls_dcert_file
+
+To verify a remote SMTP client certificate, the Postfix SMTP server needs to
+trust the certificates of the issuing Certification Authorities. These
+certificates in "pem" format can be stored in a single $smtpd_tls_CAfile or in
+multiple files, one CA per file in the $smtpd_tls_CApath directory. If you use
+a directory, don't forget to create the necessary "hash" links with:
+
+ # $$OOPPEENNSSSSLL__HHOOMMEE//bbiinn//cc__rreehhaasshh //ppaatthh//ttoo//ddiirreeccttoorryy
+
+The $smtpd_tls_CAfile contains the CA certificates of one or more trusted CAs.
+The file is opened (with root privileges) before Postfix enters the optional
+chroot jail and so need not be accessible from inside the chroot jail.
+
+Additional trusted CAs can be specified via the $smtpd_tls_CApath directory, in
+which case the certificates are read (with $mail_owner privileges) from the
+files in the directory when the information is needed. Thus, the
+$smtpd_tls_CApath directory needs to be accessible inside the optional chroot
+jail.
+
+When you configure Postfix to request client certificates (by setting
+$smtpd_tls_ask_ccert = yes), any certificates in $smtpd_tls_CAfile are sent to
+the client, in order to allow it to choose an identity signed by a CA you
+trust. If no $smtpd_tls_CAfile is specified, no preferred CA list is sent, and
+the client is free to choose an identity signed by any CA. Many clients use a
+fixed identity regardless of the preferred CA list and you may be able to
+reduce TLS negotiation overhead by installing client CA certificates mostly or
+only in $smtpd_tls_CApath. In the latter case you need not specify a
+$smtpd_tls_CAfile.
+
+Note, that unless client certificates are used to allow greater access to TLS
+authenticated clients, it is best to not ask for client certificates at all, as
+in addition to increased overhead some clients (notably in some cases qmail)
+are unable to complete the TLS handshake when client certificates are
+requested.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_CAfile = /etc/postfix/CAcert.pem
+ smtpd_tls_CApath = /etc/postfix/certs
+
+SSeerrvveerr--ssiiddee TTLLSS aaccttiivviittyy llooggggiinngg
+
+To get additional information about Postfix SMTP server TLS activity you can
+increase the loglevel from 0..4. Each logging level also includes the
+information that is logged at a lower logging level.
+
+ 0 Disable logging of TLS activity.
+
+ 1 Log TLS handshake and certificate information.
+
+ 2 Log levels during TLS negotiation.
+
+ 3 Log hexadecimal and ASCII dump of TLS negotiation process
+
+ 4 Log hexadecimal and ASCII dump of complete transmission after STARTTLS
+
+Use loglevel 3 only in case of problems. Use of loglevel 4 is strongly
+discouraged.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_loglevel = 0
+
+To include information about the protocol and cipher used as well as the client
+and issuer CommonName into the "Received:" message header, set the
+smtpd_tls_received_header variable to true. The default is no, as the
+information is not necessarily authentic. Only information recorded at the
+final destination is reliable, since the headers may be changed by intermediate
+servers.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_received_header = yes
+
+EEnnaabblliinngg TTLLSS iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr
+
+By default, TLS is disabled in the Postfix SMTP server, so no difference to
+plain Postfix is visible. Explicitly switch it on using "smtpd_use_tls = yes".
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_use_tls = yes
+
+With this, Postfix SMTP server announces STARTTLS support to SMTP clients, but
+does not require that clients use TLS encryption.
+
+Note: when an unprivileged user invokes "sendmail -bs", STARTTLS is never
+offered due to insufficient privileges to access the server private key. This
+is intended behavior.
+
+You can ENFORCE the use of TLS, so that the Postfix SMTP server announces
+STARTTLS and accepts no mail without TLS encryption, by setting
+"smtpd_enforce_tls = yes". According to RFC 2487 this MUST NOT be applied in
+case of a publicly-referenced Postfix SMTP server. This option is off by
+default and should only seldom be used.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_enforce_tls = yes
+
+TLS is sometimes used in the non-standard "wrapper" mode where a server always
+uses TLS, instead of announcing STARTTLS support and waiting for clients to
+request TLS service. Some clients, namely Outlook [Express] prefer the
+"wrapper" mode. This is true for OE (Win32 < 5.0 and Win32 >=5.0 when run on a
+port<>25 and OE (5.01 Mac on all ports).
+
+It is strictly discouraged to use this mode from main.cf. If you want to
+support this service, enable a special port in master.cf and specify "-
+o smtpd_tls_wrappermode = yes" as an smtpd(8) command line option. Port 465
+(smtps) was once chosen for this feature.
+
+Example:
+
+ /etc/postfix/master.cf:
+ smtps inet n - n - - smtpd
+ -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
+
+CClliieenntt cceerrttiiffiiccaattee vveerriiffiiccaattiioonn
+
+To receive a remote SMTP client certificate, the Postfix SMTP server must
+explicitly ask for one (any contents of $smtpd_tls_CAfile are also sent to the
+client as a hint for choosing a certificate from a suitable CA). Unfortunately,
+Netscape clients will either complain if no matching client certificate is
+available or will offer the user client a list of certificates to choose from.
+Additionally some MTAs (notably some versions of qmail) are unable to complete
+TLS negotiation when client certificates are requested, and abort the SMTP
+session. So this option is "off" by default. You will however need the
+certificate if you want to use certificate based relaying with, for example,
+the permit_tls_clientcerts feature.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_ask_ccert = no
+
+You may also decide to REQUIRE a remote SMTP client certificate before allowing
+TLS connections. This feature is included for completeness, and implies
+"smtpd_tls_ask_ccert = yes".
+
+Please be aware, that this will inhibit TLS connections without a proper client
+certificate and that it makes sense only when non-TLS submission is disabled
+(smtpd_enforce_tls = yes). Otherwise, clients could bypass the restriction by
+simply not using STARTTLS at all.
+
+When TLS is not enforced, the connection will be handled as if only
+"smtpd_tls_ask_ccert = yes" is specified, and a warning is logged.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_req_ccert = no
+
+A client certificate verification depth of 1 is sufficient if the certificate
+is directly issued by a CA listed in the CA file. The default value (5) should
+also suffice for longer chains (root CA issues special CA which then issues the
+actual certificate...)
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_ccert_verifydepth = 5
+
+SSuuppppoorrttiinngg AAUUTTHH oovveerr TTLLSS oonnllyy
+
+Sending AUTH data over an unencrypted channel poses a security risk. When TLS
+layer encryption is required (smtpd_enforce_tls = yes), the Postfix SMTP server
+will announce and accept AUTH only after the TLS layer has been activated with
+STARTTLS. When TLS layer encryption is optional (smtpd_enforce_tls = no), it
+may however still be useful to only offer AUTH when TLS is active. To maintain
+compatibility with non-TLS clients, the default is to accept AUTH without
+encryption. In order to change this behavior, set "smtpd_tls_auth_only = yes".
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_auth_only = no
+
+SSeerrvveerr--ssiiddee TTLLSS sseessssiioonn ccaacchhee
+
+The Postfix SMTP server and the remote SMTP client negotiate a session, which
+takes some computer time and network bandwidth. By default, this session
+information is cached only in the smtpd(8) process actually using this session
+and is lost when the process terminates. To share the session information
+between multiple smtpd(8) processes, a persistent session cache can be used.
+You can specify any database type that can store objects of several kbytes and
+that supports the sequence operator. DBM databases are not suitable because
+they can only store small objects. The cache is maintained by the tlsmgr(8)
+process, so there is no problem with concurrent access. Session caching is
+highly recommended, because the cost of repeatedly negotiating TLS session keys
+is high.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_scache
+
+As of version 2.5, Postfix will no longer maintain this file in a directory
+with non-Postfix ownership. As a migration aid, attempts to open such files are
+redirected to the Postfix-owned $data_directory, and a warning is logged.
+
+Cached Postfix SMTP server session information expires after a certain amount
+of time. Postfix/TLS does not use the OpenSSL default of 300s, but a longer
+time of 3600sec (=1 hour). RFC 2246 recommends a maximum of 24 hours.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_session_cache_timeout = 3600s
+
+SSeerrvveerr aacccceessss ccoonnttrrooll
+
+Postfix TLS support introduces three additional features for Postfix SMTP
+server access control:
+
+ permit_tls_clientcerts
+ Allow the remote SMTP client SMTP request if the client certificate
+ passes verification, and if its fingerprint is listed in the list of
+ client certificates (see relay_clientcerts discussion below).
+
+ permit_tls_all_clientcerts
+ Allow the remote client SMTP request if the client certificate passes
+ verification.
+
+ check_ccert_access type:table
+ If the client certificate passes verification, use its fingerprint as a
+ key for the specified access(5) table.
+
+The permit_tls_all_clientcerts feature must be used with caution, because it
+can result in too many access permissions. Use this feature only if a special
+CA issues the client certificates, and only if this CA is listed as trusted CA.
+If other CAs are trusted, any owner of a valid client certificate would be
+authorized. The permit_tls_all_clientcerts feature can be practical for a
+specially created email relay server.
+
+It is however recommended to stay with the permit_tls_clientcerts feature and
+list all certificates via $relay_clientcerts, as permit_tls_all_clientcerts
+does not permit any control when a certificate must no longer be used (e.g. an
+employee leaving).
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_recipient_restrictions =
+ ...
+ permit_tls_clientcerts
+ reject_unauth_destination
+ ...
+
+The Postfix list manipulation routines give special treatment to whitespace and
+some other characters, making the use of certificate names impractical. Instead
+we use the certificate fingerprints as they are difficult to fake but easy to
+use for lookup. Postfix lookup tables are in the form of (key, value) pairs.
+Since we only need the key, the value can be chosen freely, e.g. the name of
+the user or host.
+
+Example:
+
+ /etc/postfix/main.cf:
+ relay_clientcerts = hash:/etc/postfix/relay_clientcerts
+
+ /etc/postfix/relay_clientcerts:
+ D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80 lutzpc.at.home
+
+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!
+
+DO NOT USE " to enclose the string, specify just the string!!!
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_cipherlist = DEFAULT
+
+If you want to take advantage of ciphers with EDH, DH parameters are needed.
+Instead of using the built-in DH parameters for both 1024bit and 512bit, it is
+better to generate "own" parameters, since otherwise it would "pay" for a
+possible attacker to start a brute force attack against parameters that are
+used by everybody. For this reason, the parameters chosen are already different
+from those distributed with other TLS packages.
+
+To generate your own set of DH parameters, use:
+
+ % ooppeennssssll ggeennddhh --oouutt //eettcc//ppoossttffiixx//ddhh__11002244..ppeemm --22 --rraanndd //vvaarr//rruunn//eeggdd--ppooooll
+ 11002244
+ % ooppeennssssll ggeennddhh --oouutt //eettcc//ppoossttffiixx//ddhh__551122..ppeemm --22 --rraanndd //vvaarr//rruunn//eeggdd--ppooooll 551122
+
+Examples:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
+ smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
+
+MMiisscceellllaanneeoouuss sseerrvveerr ccoonnttrroollss
+
+The smtpd_starttls_timeout parameter limits the time of Postfix SMTP server
+write and read operations during TLS startup and shutdown handshake procedures.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_starttls_timeout = 300s
+
+SSMMTTPP CClliieenntt ssppeecciiffiicc sseettttiinnggss
+
+Topics covered in this section:
+
+ * Client-side certificate and private key configuration
+ * Client-side TLS activity logging
+ * Client-side TLS session cache
+ * Enabling TLS in the Postfix SMTP client
+ * Requiring TLS encryption
+ * Disabling server certificate verification
+ * Per-site TLS policies
+ * Closing a DNS loophole with per-site TLS policies
+ * Discovering servers that support TLS
+ * Server certificate verification depth
+ * Client-side cipher controls
+ * Miscellaneous client controls
+
+CClliieenntt--ssiiddee cceerrttiiffiiccaattee aanndd pprriivvaattee kkeeyy ccoonnffiigguurraattiioonn
+
+During TLS startup negotiation the Postfix SMTP client may present a
+certificate to the remote SMTP server. The Netscape client is rather clever
+here and lets the user select between only those certificates that match CA
+certificates offered by the remote SMTP server. As the Postfix SMTP client uses
+the "SSL_connect()" function from the OpenSSL package, this is not possible and
+we have to choose just one certificate. So for now the default is to use _no_
+certificate and key unless one is explicitly specified here.
+
+Both RSA and DSA certificates are supported. You can have both at the same
+time, in which case the cipher used determines which certificate is presented.
+
+It is possible for the Postfix SMTP client to use the same key/certificate pair
+as the Postfix SMTP server. If a certificate is to be presented, it must be in
+"pem" format. The private key must not be encrypted, meaning: it must be
+accessible without password. Both parts (certificate and private key) may be in
+the same file.
+
+In order for remote SMTP servers to verify the Postfix SMTP client
+certificates, the CA certificate (in case of a certificate chain, all CA
+certificates) must be available. You should add these certificates to the
+client certificate, the client certificate first, then the issuing CA(s).
+
+Example: the certificate for "client.example.com" was issued by "intermediate
+CA" which itself has a certificate of "root CA". Create the client.pem file
+with:
+
+ % ccaatt cclliieenntt__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> cclliieenntt..ppeemm
+
+A Postfix SMTP client certificate supplied here must be usable as SSL client
+certificate and hence pass the "openssl verify -purpose sslclient ..." test.
+
+A server that trusts the root CA has a local copy of the root CA certificate,
+so it is not necessary to include the root CA certificate here. Leaving it out
+of the "client.pem" file reduces the overhead of the TLS exchange.
+
+If you want the Postfix SMTP client to accept remote SMTP server certificates
+issued by these CAs, append the root certificate to $smtp_tls_CAfile or install
+it in the $smtp_tls_CApath directory. When you configure trust in a root CA, it
+is not necessary to explicitly trust intermediary CAs signed by the root CA,
+unless $smtp_tls_scert_verifydepth is less than the number of CAs in the
+certificate chain for the servers of interest. With a verify depth of 1 you can
+only verify certificates directly signed by a trusted CA, and all trusted
+intermediary CAs need to be configured explicitly. With a verify depth of 2 you
+can verify servers signed by a root CA or a direct intermediary CA (so long as
+the server is correctly configured to supply its intermediate CA certificate).
+
+RSA key and certificate examples:
+
+ /etc/postfix/main.cf:
+ smtp_tls_cert_file = /etc/postfix/client.pem
+ smtp_tls_key_file = $smtp_tls_cert_file
+
+Their DSA counterparts:
+
+ /etc/postfix/main.cf:
+ smtp_tls_dcert_file = /etc/postfix/client-dsa.pem
+ smtp_tls_dkey_file = $smtp_tls_dcert_file
+
+To verify a remote SMTP server certificate, the Postfix SMTP client needs to
+trust the certificates of the issuing Certification Authorities. These
+certificates in "pem" format can be stored in a single $smtp_tls_CAfile or in
+multiple files, one CA per file in the $smtp_tls_CApath directory. If you use a
+directory, don't forget to create the necessary "hash" links with:
+
+ # $$OOPPEENNSSSSLL__HHOOMMEE//bbiinn//cc__rreehhaasshh //ppaatthh//ttoo//ddiirreeccttoorryy
+
+The $smtp_tls_CAfile contains the CA certificates of one or more trusted CAs.
+The file is opened (with root privileges) before Postfix enters the optional
+chroot jail and so need not be accessible from inside the chroot jail.
+
+Additional trusted CAs can be specified via the $smtp_tls_CApath directory, in
+which case the certificates are read (with $mail_owner privileges) from the
+files in the directory when the information is needed. Thus, the
+$smtp_tls_CApath directory needs to be accessible inside the optional chroot
+jail.
+
+The choice between $smtp_tls_CAfile and $smtp_tls_CApath is a space/time
+tradeoff. If there are many trusted CAs, the cost of preloading them all into
+memory may not pay off in reduced access time when the certificate is needed.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_CAfile = /etc/postfix/CAcert.pem
+ smtp_tls_CApath = /etc/postfix/certs
+
+CClliieenntt--ssiiddee TTLLSS aaccttiivviittyy llooggggiinngg
+
+To get additional information about Postfix SMTP client TLS activity you can
+increase the loglevel from 0..4. Each logging level also includes the
+information that is logged at a lower logging level.
+
+ 0 Disable logging of TLS activity.
+
+ 1 Log TLS handshake and certificate information.
+
+ 2 Log levels during TLS negotiation.
+
+ 3 Log hexadecimal and ASCII dump of TLS negotiation process
+
+ 4 Log hexadecimal and ASCII dump of complete transmission after STARTTLS
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_loglevel = 0
+
+CClliieenntt--ssiiddee TTLLSS sseessssiioonn ccaacchhee
+
+The remote SMTP server and the Postfix SMTP client negotiate a session, which
+takes some computer time and network bandwidth. By default, this session
+information is cached only in the smtp(8) process actually using this session
+and is lost when the process terminates. To share the session information
+between multiple smtp(8) processes, a persistent session cache can be used. You
+can specify any database type that can store objects of several kbytes and that
+supports the sequence operator. DBM databases are not suitable because they can
+only store small objects. The cache is maintained by the tlsmgr(8) process, so
+there is no problem with concurrent access. Session caching is highly
+recommended, because the cost of repeatedly negotiating TLS session keys is
+high. Future Postfix SMTP servers may limit the number of sessions that a
+client is allowed to negotiate per unit time.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache
+
+As of version 2.5, Postfix will no longer maintain this file in a directory
+with non-Postfix ownership. As a migration aid, attempts to open such files are
+redirected to the Postfix-owned $data_directory, and a warning is logged.
+
+Cached Postfix SMTP client session information expires after a certain amount
+of time. Postfix/TLS does not use the OpenSSL default of 300s, but a longer
+time of 3600s (=1 hour). RFC 2246 recommends a maximum of 24 hours.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_session_cache_timeout = 3600s
+
+EEnnaabblliinngg TTLLSS iinn tthhee PPoossttffiixx SSMMTTPP cclliieenntt
+
+By default, TLS is disabled in the Postfix SMTP client, so no difference to
+plain Postfix is visible. If you enable TLS, the Postfix SMTP client will send
+STARTTLS when TLS support is announced by the remote SMTP server.
+
+When the server accepts the STARTTLS command, but the subsequent TLS handshake
+fails, and no other server is available, the Postfix SMTP client defers the
+delivery attempt, and the mail stays in the queue. After a handshake failure,
+the communications channel is in an indeterminate state and cannot be used for
+non-TLS deliveries.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_use_tls = yes
+
+RReeqquuiirriinngg TTLLSS eennccrryyppttiioonn
+
+You can ENFORCE the use of TLS, so that the Postfix SMTP client will not
+deliver mail over unencrypted connections. In this mode, the remote SMTP server
+hostname must match the information in the remote server certificate, and the
+server certificate must be issued by a CA that is trusted by the Postfix SMTP
+client. If the remote server certificate doesn't verify or the remote SMTP
+server hostname doesn't match, and no other server is available, the delivery
+attempt is deferred and the mail stays in the queue.
+
+The remote SMTP server hostname is verified against all names provided as
+dNSNames in the SubjectAlternativeName. If no dNSNames are specified, the
+CommonName is checked. Verification may be turned off with the
+smtp_tls_enforce_peername option which is discussed below.
+
+Enforcing the use of TLS is useful if you know that you will only connect to
+servers that support RFC 2487 _and_ that present server certificates that meet
+the above requirements. An example would be a client only sends email to one
+specific mailhub that offers the necessary STARTTLS support.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_enforce_tls = yes
+
+DDiissaabblliinngg sseerrvveerr cceerrttiiffiiccaattee vveerriiffiiccaattiioonn
+
+As of RFC 2487 the requirements for hostname checking for MTA clients are not
+set. When TLS is required (smtp_enforce_tls = yes), the option
+smtp_tls_enforce_peername can be set to "no" to disable strict remote SMTP
+server hostname checking. In this case, the mail delivery will proceed
+regardless of the CommonName etc. listed in the certificate.
+
+Despite the potential for eliminating "man-in-the-middle" and other attacks,
+mandatory certificate/peername verification is not viable as a default Internet
+mail delivery policy at this time. A significant fraction of TLS enabled MTAs
+uses self-signed certificates, or certificates that are signed by a private
+Certification Authority. On a machine that delivers mail to the Internet, if
+you set smtp_enforce_tls = yes, you should probably also set
+smtp_tls_enforce_peername = no. You can use the per-site TLS policies (see
+below) to enable full peer verification for specific destinations that are
+known to have verifiable TLS server certificates.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_enforce_tls = yes
+ smtp_tls_enforce_peername = no
+
+PPeerr--ssiittee TTLLSS ppoolliicciieess
+
+A small fraction of servers offer STARTTLS but the negotiation consistently
+fails, leading to mail aging out of the queue and bouncing back to the sender.
+In such cases, you can use the per-site policies to disable TLS for the problem
+sites. Alternatively, you can enable TLS for just a few specific sites and not
+enable it for all sites.
+
+The smtp_tls_per_site table is searched for a policy that matches the following
+information:
+
+ remote SMTP server hostname
+ This is simply the DNS name of the server that the Postfix SMTP client
+ connects to; this name may be obtained from other DNS lookups, such as
+ MX lookups or CNAME lookups.
+ next-hop destination
+ This is normally the domain portion of the recipient address, but it
+ may be overruled by information from the transport(5) table, from the
+ relayhost parameter setting, or from the relay_transport setting. When
+ it's not the recipient domain, the next-hop destination can have the
+ Postfix-specific form "[name]", [name]:port", "name" or "name:port".
+
+When both the hostname lookup and the next-hop lookup succeed, the host policy
+does not automatically override the next-hop policy. Instead, precedence is
+given to either the more specific or the more secure per-site policy as
+described below.
+
+The smtp_tls_per_site table uses a simple "name whitespace value" format.
+Specify host names or next-hop destinations on the left-hand side; no wildcards
+are allowed. On the right hand side specify one of the following keywords:
+
+ NONE
+ Don't use TLS at all. This overrides a less specific MMAAYY lookup result
+ from the alternate host or next-hop lookup key, and overrides the
+ global smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername
+ settings.
+ MAY
+ Try to use TLS if the server announces support, otherwise use the
+ unencrypted connection. This has less precedence than a more specific
+ result (including NNOONNEE) from the alternate host or next-hop lookup key,
+ and has less precedence than the more specific global "smtp_enforce_tls
+ = yes" or "smtp_tls_enforce_peername = yes".
+ MUST_NOPEERMATCH
+ Require TLS encryption, but do not require that the remote SMTP server
+ hostname matches the information in the remote SMTP server certificate,
+ or that the server certificate was issued by a trusted CA. This
+ overrides a less secure NNOONNEE or a less specific MMAAYY lookup result from
+ the alternate host or next-hop lookup key, and overrides the global
+ smtp_use_tls, smtp_enforce_tls and smtp_tls_enforce_peername settings.
+ MUST
+ Require TLS encryption, require that the remote SMTP server hostname
+ matches the information in the remote SMTP server certificate, and
+ require that the remote SMTP server certificate was issued by a trusted
+ CA. This overrides a less secure NNOONNEE and MMUUSSTT__NNOOPPEEEERRMMAATTCCHH or a less
+ specific MMAAYY lookup result from the alternate host or next-hop lookup
+ key, and overrides the global smtp_use_tls, smtp_enforce_tls and
+ smtp_tls_enforce_peername settings.
+
+The precedences between global (main.cf) and per-site TLS policies can be
+summarized as follows:
+
+ * When neither the remote SMTP server hostname nor the next-hop destination
+ are found in the smtp_tls_per_site table, the policy is based on
+ smtp_use_tls, smtp_enforce_tls and smtp_tls_enforce_peername. Note:
+ "smtp_enforce_tls = yes" and "smtp_tls_enforce_peername = yes" imply
+ "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).
+
+ * After the per-site policy lookups are combined, the result generally
+ overrides the global policy. The exception is the less specific MMAAYY per-
+ site policy, which is overruled by the more specific global
+ "smtp_enforce_tls = yes" with server certificate verification as specified
+ with the smtp_tls_enforce_peername parameter.
+
+CClloossiinngg aa DDNNSS lloooopphhoollee wwiitthh ppeerr--ssiittee TTLLSS ppoolliicciieess
+
+As long as no secure DNS lookup mechanism is available, false hostnames in MX
+or CNAME responses can change the server hostname that Postfix uses for TLS
+policy lookup and server certificate verification. Even with a perfect match
+between the server hostname and the server certificate, there is no guarantee
+that Postfix is connected to the right server. To avoid this loophole take the
+following steps:
+
+ * Eliminate MX lookups. Specify local transport(5) table entries for
+ sensitive domains with explicit smtp:[mailhost] or smtp:[mailhost]:port
+ destinations (you can assure security of this table unlike DNS); in the
+ smtp_tls_per_site table specify the value MMUUSSTT for the key [mailhost] or
+ smtp:[mailhost]:port. This prevents false hostname information in DNS MX
+ records from changing the server hostname that Postfix uses for TLS policy
+ lookup and server certificate verification.
+
+ * Disallow CNAME hostname overrides. In main.cf specify
+ "smtp_cname_overrides_servername = no". This prevents false hostname
+ information in DNS CNAME records from changing the server hostname that
+ Postfix uses for TLS policy lookup and server certificate verification.
+ This feature requires Postfix 2.2.9 or later.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_per_site = hash:/etc/postfix/tls_per_site
+ relayhost = [msa.example.net]:587
+
+ /etc/postfix/tls_per_site:
+ # relayhost exact nexthop match
+ [msa.example.net]:587 MUST
+
+ # TLS should not be used with the example.org MX hosts.
+ example.org NONE
+
+ # TLS should not be used with the host smtp.example.com.
+ smtp.example.com NONE
+
+DDiissccoovveerriinngg sseerrvveerrss tthhaatt ssuuppppoorrtt TTLLSS
+
+As we decide on a "per site" basis whether or not to use TLS, it would be good
+to have a list of sites that offered "STARTTLS". We can collect it ourselves
+with this option.
+
+If the smtp_tls_note_starttls_offer feature is enabled and a server offers
+STARTTLS while TLS is not already enabled for that server, the Postfix SMTP
+client logs a line as follows:
+
+ postfix/smtp[pid]: Host offered STARTTLS: [hostname.example.com]
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_note_starttls_offer = yes
+
+SSeerrvveerr cceerrttiiffiiccaattee vveerriiffiiccaattiioonn ddeepptthh
+
+When verifying a remote SMTP server certificate, a verification depth of 1 is
+sufficient if the certificate is directly issued by a CA specified with
+smtp_tls_CAfile or smtp_tls_CApath. The default value of 5 should also suffice
+for longer chains (root CA issues special CA which then issues the actual
+certificate...)
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_scert_verifydepth = 5
+
+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!
+
+DO NOT USE " to enclose the string, specify just the string!!!
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_cipherlist = DEFAULT
+
+MMiisscceellllaanneeoouuss cclliieenntt ccoonnttrroollss
+
+The smtp_starttls_timeout parameter limits the time of Postfix SMTP client
+write and read operations during TLS startup and shutdown handshake procedures.
+In case of problems the Postfix SMTP client tries the next network address on
+the mail exchanger list, and defers delivery if no alternative server is
+available.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_starttls_timeout = 300s
+
+TTLLSS mmaannaaggeerr ssppeecciiffiicc sseettttiinnggss
+
+The security of cryptographic software such as TLS depends critically on the
+ability to generate unpredictable numbers for keys and other information. To
+this end, the tlsmgr(8) process maintains a Pseudo Random Number Generator
+(PRNG) pool. This is queried by the smtp(8) and smtpd(8) processes when they
+initialize. By default, these daemons request 32 bytes, the equivalent to 256
+bits. This is more than sufficient to generate a 128bit (or 168bit) session
+key.
+
+Example:
+
+ /etc/postfix/main.cf:
+ tls_daemon_random_bytes = 32
+
+In order to feed its in-memory PRNG pool, the tlsmgr(8) reads entropy from an
+external source, both at startup and during run-time. Specify a good entropy
+source, like EGD or /dev/urandom; be sure to only use non-blocking sources (on
+OpenBSD, use /dev/arandom when tlsmgr(8) complains about /dev/urandom timeout
+errors). If the entropy source is not a regular file, you must prepend the
+source type to the source name: "dev:" for a device special file, or "egd:" for
+a source with EGD compatible socket interface.
+
+Examples (specify only one in main.cf):
+
+ /etc/postfix/main.cf:
+ tls_random_source = dev:/dev/urandom
+ tls_random_source = egd:/var/run/egd-pool
+
+By default, tlsmgr(8) reads 32 bytes from the external entropy source at each
+seeding event. This amount (256bits) is more than sufficient for generating a
+128bit symmetric key. With EGD and device entropy sources, the tlsmgr(8) limits
+the amount of data read at each step to 255 bytes. If you specify a regular
+file as entropy source, a larger amount of data can be read.
+
+Example:
+
+ /etc/postfix/main.cf:
+ tls_random_bytes = 32
+
+In order to update its in-memory PRNG pool, the tlsmgr(8) queries the external
+entropy source again after a pseudo-random amount of time. The time is
+calculated using the PRNG, and is between 0 and the maximal time specified with
+tls_random_reseed_period. The default maximal time interval is 1 hour.
+
+Example:
+
+ /etc/postfix/main.cf:
+ tls_random_reseed_period = 3600s
+
+The tlsmgr(8) process saves the PRNG state to a persistent exchange file at
+regular times and when the process terminates, so that it can recover the PRNG
+state the next time it starts up. This file is created when it does not exist.
+Its default location is under the Postfix configuration directory, which is not
+the proper place for information that is modified by Postfix. Instead, the file
+location should probably be on the /var partition (but nnoott inside the chroot
+jail).
+
+Examples:
+
+ /etc/postfix/main.cf:
+ tls_random_exchange_name = /etc/postfix/prng_exch
+ tls_random_prng_update_period = 3600s
+
+GGeettttiinngg ssttaarrtteedd,, qquuiicckk aanndd ddiirrttyy
+
+The following steps will get you started quickly. Because you sign your own
+Postfix public key certificate, you get TLS encryption but no TLS
+authentication. This is sufficient for testing, and for exchanging email with
+sites that you have no trust relationship with. For real authentication, your
+Postfix public key certificate needs to be signed by a recognized Certification
+Authority, and Postfix needs to be configured with a list of public key
+certificates of Certification Authorities, so that Postfix can verify the
+public key certificates of remote hosts.
+
+In the examples below, user input is shown in bboolldd font, and a "#" prompt
+indicates a super-user shell.
+
+ * Become your own Certification Authority, so that you can sign your own
+ public keys. This example uses the CA.pl script that ships with OpenSSL. By
+ default, OpenSSL installs this as /usr/local/ssl/misc/CA.pl, but your
+ mileage may vary. The script creates a private key in ./demoCA/private/
+ cakey.pem and a public key in ./demoCA/cacert.pem.
+
+ % //uussrr//llooccaall//ssssll//mmiisscc//CCAA..ppll --nneewwccaa
+ CA certificate filename (or enter to create)
+
+ Making CA certificate ...
+ Using configuration from /etc/ssl/openssl.cnf
+ Generating a 1024 bit RSA private key
+ ....................++++++
+ .....++++++
+ writing new private key to './demoCA/private/cakey.pem'
+ Enter PEM pass phrase:wwhhaatteevveerr
+
+ * Create an unpassworded private key for host FOO and create an unsigned
+ public key certificate.
+
+ % ooppeennssssll rreeqq --nneeww --nnooddeess --kkeeyyoouutt FFOOOO--kkeeyy..ppeemm --oouutt FFOOOO--rreeqq..ppeemm --ddaayyss
+ 336655
+ Using configuration from /etc/ssl/openssl.cnf
+ Generating a 1024 bit RSA private key
+ ........................................++++++
+ ....++++++
+ writing new private key to 'FOO-key.pem'
+ -----
+ You are about to be asked to enter information that will be
+ incorporated
+ into your certificate request.
+ What you are about to enter is what is called a Distinguished Name or a
+ DN.
+ There are quite a few fields but you can leave some blank
+ For some fields there will be a default value,
+ If you enter '.', the field will be left blank.
+ -----
+ Country Name (2 letter code) [AU]:UUSS
+ State or Province Name (full name) [Some-State]:NNeeww YYoorrkk
+ Locality Name (eg, city) []:WWeessttcchheesstteerr
+ Organization Name (eg, company) [Internet Widgits Pty Ltd]:PPoorrccuuppiinnee
+ Organizational Unit Name (eg, section) []:
+ Common Name (eg, YOUR name) []:FFOOOO
+ Email Address []:wwiieettssee@@ppoorrccuuppiinnee..oorrgg
+
+ Please enter the following 'extra' attributes
+ to be sent with your certificate request
+ A challenge password []:wwhhaatteevveerr
+ An optional company name []:
+
+ * Sign the public key certificate for host FOO with the Certification
+ Authority private key that we created a few steps ago.
+
+ % ooppeennssssll ccaa --oouutt FFOOOO--cceerrtt..ppeemm --iinnffiilleess FFOOOO--rreeqq..ppeemm
+ Uing configuration from /etc/ssl/openssl.cnf
+ Enter PEM pass phrase:wwhhaatteevveerr
+ Check that the request matches the signature
+ Signature ok
+ The Subjects Distinguished Name is as follows
+ countryName :PRINTABLE:'US'
+ stateOrProvinceName :PRINTABLE:'New York'
+ localityName :PRINTABLE:'Westchester'
+ organizationName :PRINTABLE:'Porcupine'
+ commonName :PRINTABLE:'FOO'
+ emailAddress :IA5STRING:'wietse@porcupine.org'
+ Certificate is to be certified until Nov 21 19:40:56 2005 GMT (365
+ days)
+ Sign the certificate? [y/n]:yy
+
+ 1 out of 1 certificate requests certified, commit? [y/n]yy
+ Write out database with 1 new entries
+ Data Base Updated
+
+ * Install the host private key, the host public key certificate, and the
+ Certification Authority certificate files. This requires super-user
+ privileges.
+
+ # ccpp ddeemmooCCAA//ccaacceerrtt..ppeemm FFOOOO--kkeeyy..ppeemm FFOOOO--cceerrtt..ppeemm //eettcc//ppoossttffiixx
+ # cchhmmoodd 664444 //eettcc//ppoossttffiixx//FFOOOO--cceerrtt..ppeemm //eettcc//ppoossttffiixx//ccaacceerrtt..ppeemm
+ # cchhmmoodd 440000 //eettcc//ppoossttffiixx//FFOOOO--kkeeyy..ppeemm
+
+ * Configure Postfix, by adding the following to /etc/postfix/main.cf.
+
+ smtp_tls_CAfile = /etc/postfix/cacert.pem
+ smtp_tls_cert_file = /etc/postfix/FOO-cert.pem
+ smtp_tls_key_file = /etc/postfix/FOO-key.pem
+ smtp_tls_session_cache_database = btree:/var/run/smtp_tls_session_cache
+ smtp_use_tls = yes
+ smtpd_tls_CAfile = /etc/postfix/cacert.pem
+ smtpd_tls_cert_file = /etc/postfix/FOO-cert.pem
+ smtpd_tls_key_file = /etc/postfix/FOO-key.pem
+ smtpd_tls_received_header = yes
+ smtpd_tls_session_cache_database = btree:/var/run/
+ smtpd_tls_session_cache
+ smtpd_use_tls = yes
+ tls_random_source = dev:/dev/urandom
+
+RReeppoorrttiinngg pprroobblleemmss
+
+When reporting a problem, please be thorough in the report. Patches, when
+possible, are greatly appreciated too.
+
+Please differentiate when possible between:
+
+ * Problems in the TLS code:
+ * Problems in vanilla Postfix:
+
+CCoommppaattiibbiilliittyy wwiitthh PPoossttffiixx <<22..22 TTLLSS ssuuppppoorrtt
+
+Postfix version 2.2 TLS support is based on the Postfix/TLS patch by Lutz
+Jänicke, but differs in a few minor ways.
+
+ * main.cf: Specify "btree" instead of "sdbm" for TLS session cache databases.
+
+ TLS session cache databases are now accessed only by the tlsmgr(8) process,
+ so there are no more concurrency issues. Although Postfix has an sdbm
+ client, the sdbm library (1000 lines of code) is not included with Postfix.
+
+ TLS session caches can use any database that can store objects of several
+ kbytes or more, and that implements the sequence operation. In most cases,
+ btree databases should be adequate.
+
+ NOTE: You cannot use dbm databases. TLS session objects are too large.
+
+ * master.cf: Specify "unix" instead of "fifo" as the tlsmgr service type.
+
+ The smtp(8) and smtpd(8) processes now use a client-server protocol in
+ order to access the tlsmgr(8) pseudo-random number generation (PRNG) pool,
+ and in order to access the TLS session cache databases. Such a protocol
+ cannot be run across fifos.
+
+ * smtp_tls_per_site: the MUST_NOPEERMATCH per-site policy cannot override the
+ global "smtp_tls_enforce_peername = yes" setting.
+
+ * smtp_tls_per_site: a combined (NONE + MAY) lookup result for (hostname and
+ next-hop destination) produces counter-intuitive results for different
+ main.cf settings. TLS is enabled with "smtp_tls_enforce_peername = no", but
+ it is disabled when both "smtp_enforce_tls = yes" and
+ "smtp_tls_enforce_peername = yes".
+
+The smtp_tls_per_site limitations were removed by the end of the Postfix 2.2
+support cycle.
+
+CCrreeddiittss
+
+ * TLS support for Postfix was originally developed by Lutz Jänicke at Cottbus
+ Technical University.
+ * Wietse Venema adopted the code, did some restructuring, and compiled this
+ part of the documentation from Lutz's documents.
+ * Victor Duchovni was instrumental with the re-implementation of the
+ smtp_tls_per_site code in terms of enforcement levels, which simplified the
+ implementation greatly.
+
diff --git a/README_FILES/TLS_README b/README_FILES/TLS_README
new file mode 100644
index 0000000..a53acb0
--- /dev/null
+++ b/README_FILES/TLS_README
@@ -0,0 +1,2287 @@
+PPoossttffiixx TTLLSS SSuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+WWAARRNNIINNGG
+
+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
+thousands and thousands of lines of OpenSSL library code. Assuming that OpenSSL
+is written as carefully as Wietse's own code, every 1000 lines introduce one
+additional bug into Postfix.
+
+WWhhaatt PPoossttffiixx TTLLSS ssuuppppoorrtt ddooeess ffoorr yyoouu
+
+Transport Layer Security (TLS, formerly called SSL) provides certificate-based
+authentication and encrypted sessions. An encrypted session protects the
+information that is transmitted with SMTP mail or with SASL authentication.
+
+ NOTE: This document describes a TLS user interface that was introduced
+ with Postfix version 2.3. Support for an older user interface is documented
+ in TLS_LEGACY_README, which also describes the differences between Postfix
+ and the third-party patch on which Postfix version 2.2 TLS support was
+ based.
+
+Topics covered in this document:
+
+ * How Postfix TLS support works
+ * SMTP Server specific settings
+ * SMTP Client specific settings
+ * TLS manager specific settings
+ * Building Postfix with TLS support
+ * Reporting problems
+ * Credits
+
+And last but not least, for the impatient:
+
+ * Getting started, quick and dirty
+
+HHooww PPoossttffiixx TTLLSS ssuuppppoorrtt wwoorrkkss
+
+The diagram below shows the main elements of the Postfix TLS architecture and
+their relationships. Colored boxes with numbered names represent Postfix daemon
+programs. Other colored boxes represent storage elements.
+
+ * The smtpd(8) server implements the SMTP over TLS server side.
+
+ * The smtp(8) client implements the SMTP (and LMTP) over TLS client side.
+
+ * The tlsmgr(8) server maintains the pseudo-random number generator (PRNG)
+ that seeds the TLS engines in the smtpd(8) server and smtp(8) client
+ processes, and maintains the TLS session key cache files.
+
+Not shown in the figure are the tlsproxy(8) server and the postscreen(8)
+server. These use TLS in the same manner as smtpd(8).
+
+ <---seed---- ----seed--->
+Network-> smtpd(8) tlsmgr(8) smtp(8) ->Network
+ <-key/cert-> <-key/cert->
+
+ / | \
+ |
+ / \
+
+ smtpd PRNG smtp
+ session state session
+ key cache file key cache
+
+SSMMTTPP SSeerrvveerr ssppeecciiffiicc sseettttiinnggss
+
+Topics covered in this section:
+
+ * Server-side certificate and private key configuration
+ * Server-side TLS activity logging
+ * Enabling TLS in the Postfix SMTP server
+ * Client certificate verification
+ * Supporting AUTH over TLS only
+ * Server-side TLS session cache
+ * Server access control
+ * Server-side cipher controls
+ * Miscellaneous server controls
+
+SSeerrvveerr--ssiiddee cceerrttiiffiiccaattee aanndd pprriivvaattee kkeeyy ccoonnffiigguurraattiioonn
+
+In order to use TLS, the Postfix SMTP server generally 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 a password. The
+certificate and private key may be in the same file, in which case the
+certificate file should be owned by "root" and not be readable by any other
+user. If the key is stored separately, this access restriction applies to the
+key file only, and the certificate file may be "world-readable".
+
+Public Internet MX hosts without certificates signed by a well-known public CA
+must still generate, and be prepared to present to most clients, a self-signed
+or private-CA signed certificate. The remote SMTP client will generally not be
+able to verify the self-signed certificate, but unless the client is running
+Postfix or similar software, it will only negotiate TLS ciphersuites that
+require a server certificate.
+
+For servers that are nnoott public Internet MX hosts, Postfix supports
+configurations with no certificates. This entails the use of just the anonymous
+TLS ciphers, which are not supported by typical SMTP clients. Since such
+clients will not, as a rule, fall back to plain text after a TLS handshake
+failure, a certificate-less Postfix SMTP server will be unable to receive email
+from most TLS enabled clients. To avoid accidental configurations with no
+certificates, Postfix enables certificate-less operation only when the
+administrator explicitly sets "smtpd_tls_cert_file = none". This ensures that
+new Postfix SMTP server configurations will not accidentally run with no
+certificates.
+
+RSA, DSA and ECDSA (Postfix >= 2.6) certificates are supported. Most sites only
+have RSA certificates. You can configure all three at the same time, in which
+case the ciphersuite negotiated with the remote SMTP client determines which
+certificate is used. If your DNS zone is signed, and you want to publish RFC
+6698 TLSA records, these must match any of the configured certificates. Since
+the best practice is to publish "3 1 1" certificate associations, create a
+separate TLSA record for each public-key certificate digest.
+
+CCrreeaattiinngg tthhee sseerrvveerr cceerrttiiffiiccaattee ffiillee
+
+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
+certificate and hence pass the "openssl verify -purpose sslserver ..." test.
+
+The examples that follow show how to create a server certificate file. We
+assume that the certificate for "server.example.com" was issued by
+"intermediate CA" which itself has a certificate issued by "root CA".
+
+ * With legacy public CA trust verification, you can omit the root certificate
+ from the "server.pem" certificate file. If the client trusts the root CA,
+ it will already have a local copy of the root CA certificate. Omitting the
+ root CA certificate reduces the size of the server TLS handshake.
+
+ % ccaatt sseerrvveerr__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> sseerrvveerr..ppeemm
+
+ * If you publish RFC 6698 TLSA "2 0 1" or "2 1 1" records to specify root CA
+ certificate digests, you must include the corresponding root CA
+ certificates in the "server.pem" certificate file. See the documentation of
+ the tls_dane_trust_anchor_digest_enable main.cf parameter.
+
+ % ccaatt sseerrvveerr__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm rroooott..ppeemm >> sseerrvveerr..ppeemm
+
+ Remote SMTP clients will be able to use the TLSA record you publish (which
+ only contains the certificate digest) only if they have access to the
+ corresponding certificate. Failure to verify certificates per the server's
+ published TLSA records will typically cause the SMTP client to defer mail
+ delivery. The foregoing also applies to "2 0 2" and "2 1 2" TLSA records or
+ any other digest of a CA certificate, but it is expected that SHA256 will
+ be by far the most common digest for TLSA.
+
+ As a best practice, publish either "3 0 1" or "3 1 1" TLSA associations
+ that specify the SHA256 digest of the server certificate public key with
+ the alias-expanded hostname of each STARTTLS capable SMTP server. These
+ continue to work when a certificate is renewed with the same public/private
+ key pair.
+
+For instructions on how to compute the digest of a certificate or its public
+key for use in TLSA records, see the documentation of the
+smtpd_tls_fingerprint_digest main.cf parameter.
+
+When a new key or certificate is generated, an additional TLSA record with the
+new digest must be published in advance of the actual deployment of the new key
+or certificate on the server. You must allow sufficient time for any TLSA
+RRsets with only the old digest to expire from DNS caches. The safest practice
+is to wait until the DNSSEC signature on the previous TLSA RRset expires, and
+only then switch the server to use new keys published in the updated TLSA
+RRset. Once the new certificate trust chain and private key are in effect, the
+DNS should be updated once again to remove the old digest from the TLSA RRset.
+
+If you want the Postfix SMTP server to accept remote SMTP client certificates
+issued by one or more root CAs, append the root certificate to
+$smtpd_tls_CAfile or install it in the $smtpd_tls_CApath directory.
+
+CCoonnffiigguurriinngg tthhee sseerrvveerr cceerrttiiffiiccaattee aanndd kkeeyy ffiilleess
+
+RSA key and certificate examples:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_cert_file = /etc/postfix/server.pem
+ smtpd_tls_key_file = $smtpd_tls_cert_file
+
+Their DSA counterparts:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem
+ smtpd_tls_dkey_file = $smtpd_tls_dcert_file
+
+Their ECDSA counterparts (Postfix >= 2.6 + OpenSSL >= 1.0.0):
+
+ /etc/postfix/main.cf:
+ # Most clients will not be ECDSA capable, so you will likely also need
+ # an RSA or DSA certificate and private key.
+ #
+ smtpd_tls_eccert_file = /etc/postfix/server-ecdsa.pem
+ smtpd_tls_eckey_file = $smtpd_tls_eccert_file
+
+TLS without certificates for servers serving exclusively anonymous-cipher
+capable clients:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_cert_file = none
+
+To verify a remote SMTP client certificate, the Postfix SMTP server needs to
+trust the certificates of the issuing Certification Authorities. These
+certificates in "PEM" format can be stored in a single $smtpd_tls_CAfile or in
+multiple files, one CA per file in the $smtpd_tls_CApath directory. If you use
+a directory, don't forget to create the necessary "hash" links with:
+
+ # $$OOPPEENNSSSSLL__HHOOMMEE//bbiinn//cc__rreehhaasshh //ppaatthh//ttoo//ddiirreeccttoorryy
+
+The $smtpd_tls_CAfile contains the CA certificates of one or more trusted CAs.
+The file is opened (with root privileges) before Postfix enters the optional
+chroot jail and so need not be accessible from inside the chroot jail.
+
+Additional trusted CAs can be specified via the $smtpd_tls_CApath directory, in
+which case the certificates are read (with $mail_owner privileges) from the
+files in the directory when the information is needed. Thus, the
+$smtpd_tls_CApath directory needs to be accessible inside the optional chroot
+jail.
+
+When you configure the Postfix SMTP server to request client certificates, the
+DNs of Certification Authorities in $smtpd_tls_CAfile are sent to the client,
+in order to allow it to choose an identity signed by a CA you trust. If no
+$smtpd_tls_CAfile is specified, no preferred CA list is sent, and the client is
+free to choose an identity signed by any CA. Many clients use a fixed identity
+regardless of the preferred CA list and you may be able to reduce TLS
+negotiation overhead by installing client CA certificates mostly or only in
+$smtpd_tls_CApath. In the latter case you need not specify a $smtpd_tls_CAfile.
+
+Note, that unless client certificates are used to allow greater access to TLS
+authenticated clients, it is best to not ask for client certificates at all, as
+in addition to increased overhead some clients (notably in some cases qmail)
+are unable to complete the TLS handshake when client certificates are
+requested.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_CAfile = /etc/postfix/CAcert.pem
+ smtpd_tls_CApath = /etc/postfix/certs
+
+SSeerrvveerr--ssiiddee TTLLSS aaccttiivviittyy llooggggiinngg
+
+To get additional information about Postfix SMTP server TLS activity you can
+increase the log level from 0..4. Each logging level also includes the
+information that is logged at a lower logging level.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |LLeevveell|PPoossttffiixx 22..99 aanndd llaatteerr |EEaarrlliieerr rreelleeaasseess.. |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |0 |Disable logging of TLS activity. |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |1 |Log only a summary message on TLS |Log the summary message, peer |
+ | |handshake completion -- no logging|certificate summary information|
+ | |of client certificate trust-chain |and unconditionally log trust- |
+ | |verification errors if client |chain verification errors. |
+ | |certificate verification is not | |
+ | |required. | |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |2 |Also log levels during TLS negotiation. |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |3 |Also log hexadecimal and ASCII dump of TLS negotiation process. |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |4 |Also log hexadecimal and ASCII dump of complete transmission after|
+ | |STARTTLS. |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+Use log level 3 only in case of problems. Use of log level 4 is strongly
+discouraged.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_loglevel = 0
+
+To include information about the protocol and cipher used as well as the client
+and issuer CommonName into the "Received:" message header, set the
+smtpd_tls_received_header variable to true. The default is no, as the
+information is not necessarily authentic. Only information recorded at the
+final destination is reliable, since the headers may be changed by intermediate
+servers.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_received_header = yes
+
+EEnnaabblliinngg TTLLSS iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr
+
+By default, TLS is disabled in the Postfix SMTP server, so no difference to
+plain Postfix is visible. Explicitly switch it on with
+"smtpd_tls_security_level = may".
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_security_level = may
+
+With this, the Postfix SMTP server announces STARTTLS support to remote SMTP
+clients, but does not require that clients use TLS encryption.
+
+Note: when an unprivileged user invokes "sendmail -bs", STARTTLS is never
+offered due to insufficient privileges to access the Postfix SMTP server
+private key. This is intended behavior.
+
+You can ENFORCE the use of TLS, so that the Postfix SMTP server announces
+STARTTLS and accepts no mail without TLS encryption, by setting
+"smtpd_tls_security_level = encrypt". According to RFC 2487 this MUST NOT be
+applied in case of a publicly-referenced Postfix SMTP server. This option is
+off by default and should only seldom be used.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_security_level = encrypt
+
+TLS is sometimes used in the non-standard "wrapper" mode where a server always
+uses TLS, instead of announcing STARTTLS support and waiting for remote SMTP
+clients to request TLS service. Some clients, namely Outlook [Express] prefer
+the "wrapper" mode. This is true for OE (Win32 < 5.0 and Win32 >=5.0 when run
+on a port<>25 and OE (5.01 Mac on all ports).
+
+It is strictly discouraged to use this mode from main.cf. If you want to
+support this service, enable a special port in master.cf and specify "-
+o smtpd_tls_wrappermode=yes" (note: no space around the "=") as an smtpd(8)
+command line option. Port 465 (smtps) was once chosen for this feature.
+
+Example:
+
+ /etc/postfix/master.cf:
+ smtps inet n - n - - smtpd
+ -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
+
+CClliieenntt cceerrttiiffiiccaattee vveerriiffiiccaattiioonn
+
+To receive a remote SMTP client certificate, the Postfix SMTP server must
+explicitly ask for one (any contents of $smtpd_tls_CAfile are also sent to the
+client as a hint for choosing a certificate from a suitable CA). Unfortunately,
+Netscape clients will either complain if no matching client certificate is
+available or will offer the user client a list of certificates to choose from.
+Additionally some MTAs (notably some versions of qmail) are unable to complete
+TLS negotiation when client certificates are requested, and abort the SMTP
+session. So this option is "off" by default. You will however need the
+certificate if you want to use certificate based relaying with, for example,
+the permit_tls_clientcerts feature. A server that wants client certificates
+must first present its own certificate. While Postfix by default offers
+anonymous ciphers to remote SMTP clients, these are automatically suppressed
+when the Postfix SMTP server is configured to ask for client certificates.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_ask_ccert = yes
+ smtpd_tls_security_level = may
+
+When TLS is enforced you may also decide to REQUIRE a remote SMTP client
+certificate for all TLS connections, by setting "smtpd_tls_req_ccert = yes".
+This feature implies "smtpd_tls_ask_ccert = yes". When TLS is not enforced,
+"smtpd_tls_req_ccert = yes" is ignored and a warning is logged.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_req_ccert = yes
+ smtpd_tls_security_level = encrypt
+
+The client certificate verification depth is specified with the main.cf
+smtpd_tls_ccert_verifydepth parameter. The default verification depth is 9 (the
+OpenSSL default), for compatibility with Postfix versions before 2.5 where
+smtpd_tls_ccert_verifydepth was ignored. When you configure trust in a root CA,
+it is not necessary to explicitly trust intermediary CAs signed by the root CA,
+unless $smtpd_tls_ccert_verifydepth is less than the number of CAs in the
+certificate chain for the clients of interest. With a verify depth of 1 you can
+only verify certificates directly signed by a trusted CA, and all trusted
+intermediary CAs need to be configured explicitly. With a verify depth of 2 you
+can verify clients signed by a root CA or a direct intermediary CA (so long as
+the client is correctly configured to supply its intermediate CA certificate).
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_ccert_verifydepth = 2
+
+SSuuppppoorrttiinngg AAUUTTHH oovveerr TTLLSS oonnllyy
+
+Sending AUTH data over an unencrypted channel poses a security risk. When TLS
+layer encryption is required ("smtpd_tls_security_level = encrypt"), the
+Postfix SMTP server will announce and accept AUTH only after the TLS layer has
+been activated with STARTTLS. When TLS layer encryption is optional
+("smtpd_tls_security_level = may"), it may however still be useful to only
+offer AUTH when TLS is active. To maintain compatibility with non-TLS clients,
+the default is to accept AUTH without encryption. In order to change this
+behavior, set "smtpd_tls_auth_only = yes".
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_auth_only = no
+
+SSeerrvveerr--ssiiddee TTLLSS sseessssiioonn ccaacchhee
+
+The Postfix SMTP server and the remote SMTP client negotiate a session, which
+takes some computer time and network bandwidth. SSL protocol versions other
+than SSLv2 support resumption of cached sessions. Not only is this more CPU and
+bandwidth efficient, it also reduces latency as only one network round-trip is
+used to resume a session while it takes two round-trips to create a session
+from scratch.
+
+Since Postfix uses multiple smtpd(8) service processes, an in-memory cache is
+not sufficient for session re-use. Clients store at most one cached session per
+server and are very unlikely to repeatedly connect to the same server process.
+Thus session caching in the Postfix SMTP server generally requires a shared
+cache (an alternative available with Postfix >= 2.11 is described below).
+
+To share the session information between multiple smtpd(8) processes, a session
+cache database is used. You can specify any database type that can store
+objects of several kbytes and that supports the sequence operator. DBM
+databases are not suitable because they can only store small objects. The cache
+is maintained by the tlsmgr(8) process, so there is no problem with concurrent
+access. Session caching is highly recommended, because the cost of repeatedly
+negotiating TLS session keys is high.
+
+Starting with Postfix 2.11, linked with a compatible OpenSSL library (at least
+0.9.8h, preferably 1.0.0 or later) the Postfix SMTP server supports RFC 5077
+TLS session resumption without server-side state when the remote SMTP client
+also supports RFC 5077. The session is encrypted by the server in a session
+ticket returned to client for storage. When a client sends a valid session
+ticket, the server decrypts it and resumes the session, provided neither the
+ticket nor the session have expired. This makes it possible to resume cached
+sessions without allocating space for a shared database on the server.
+Consequently, for Postfix >= 2.11 the smtpd_tls_session_cache_database
+parameter should generally be left empty. Session caching can be disabled by
+setting the session cache timeout to zero, otherwise the timeout must be at
+least 2 minutes and at most 100 days.
+
+Note, session tickets can only be negotiated if the client disables SSLv2 and
+does not use the legacy SSLv2 compatible HELLO message. This is true by default
+with the Postfix >= 2.6 SMTP client.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
+
+Note: as of version 2.5, Postfix no longer uses root privileges when opening
+this file. The file should now be stored under the Postfix-owned
+data_directory. As a migration aid, an attempt to open the file under a non-
+Postfix directory is redirected to the Postfix-owned data_directory, and a
+warning is logged.
+
+Cached Postfix SMTP server session information expires after a certain amount
+of time. Postfix/TLS does not use the OpenSSL default of 300s, but a longer
+time of 3600sec (=1 hour). RFC 2246 recommends a maximum of 24 hours.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_session_cache_timeout = 3600s
+
+As of Postfix 2.11 this setting cannot exceed 100 days. If set <= 0, session
+caching is disabled. If set to a positive value less than 2 minutes, the
+minimum value of 2 minutes is used instead.
+
+When the Postfix SMTP server does not save TLS sessions to an external cache
+database, client-side session caching is unlikely to be useful. To reduce waste
+of client resources, the Postfix SMTP server can be configured to not issue TLS
+session ids. By default the Postfix SMTP server always issues TLS session ids.
+This works around known interoperability issues with some MUAs, and prevents
+possible interoperability issues with other MTAs.
+
+Example:
+
+ smtpd_tls_always_issue_session_ids = no
+
+SSeerrvveerr aacccceessss ccoonnttrrooll
+
+Postfix TLS support introduces three additional features for Postfix SMTP
+server access control:
+
+ permit_tls_clientcerts
+ Allow the remote SMTP client request if the client certificate
+ fingerprint or certificate public key fingerprint (Postfix 2.9 and
+ later) is listed in the client certificate table (see relay_clientcerts
+ discussion below).
+
+ permit_tls_all_clientcerts
+ Allow the remote SMTP client request if the client certificate passes
+ trust chain verification. Useful with private-label CAs that only issue
+ certificates to trusted clients (and not otherwise).
+
+ check_ccert_access type:table
+ Use the remote SMTP client certificate fingerprint or public key
+ fingerprint (Postfix 2.9 and later) as the lookup key for the specified
+ access(5) table.
+
+The digest algorithm used to compute the client certificate fingerprints is
+specified with the main.cf smtpd_tls_fingerprint_digest parameter. The default
+is "md5", for compatibility with Postfix versions < 2.5.
+
+The permit_tls_all_clientcerts feature must be used with caution, because it
+can result in too many access permissions. Use this feature only if a special
+CA issues the client certificates, and only if this CA is listed as trusted CA.
+If other CAs are trusted, any owner of a valid client certificate would be
+authorized. The permit_tls_all_clientcerts feature can be practical for a
+specially created email relay server.
+
+It is however recommended to stay with the permit_tls_clientcerts feature and
+list all certificates via $relay_clientcerts, as permit_tls_all_clientcerts
+does not permit any control when a certificate must no longer be used (e.g. an
+employee leaving).
+
+Example:
+
+ # With Postfix 2.10 and later, the mail relay policy is
+ # preferably specified under smtpd_relay_restrictions.
+ /etc/postfix/main.cf:
+ smtpd_relay_restrictions =
+ permit_mynetworks
+ permit_tls_clientcerts
+ reject_unauth_destination
+
+ # Older configurations combine relay control and spam control under
+ # smtpd_recipient_restrictions. To use this example with Postfix >=
+ # 2.10 specify "smtpd_relay_restrictions=".
+ /etc/postfix/main.cf:
+ smtpd_recipient_restrictions =
+ permit_mynetworks
+ permit_tls_clientcerts
+ reject_unauth_destination
+ ...other rules...
+
+Example: Postfix lookup tables are in the form of (key, value) pairs. Since we
+only need the key, the value can be chosen freely, e.g. the name of the user or
+host:
+
+ /etc/postfix/main.cf:
+ relay_clientcerts = hash:/etc/postfix/relay_clientcerts
+
+ /etc/postfix/relay_clientcerts:
+ D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80 lutzpc.at.home
+
+To extract the public key fingerprint from an X.509 certificate, you need to
+extract the public key from the certificate and compute the appropriate digest
+of its DER (ASN.1) encoding. With OpenSSL the "-pubkey" option of the "x509"
+command extracts the public key always in "PEM" format. We pipe the result to
+another OpenSSL command that converts the key to DER and then to the "dgst"
+command to compute the fingerprint.
+
+The actual command to transform the key to DER format depends on the version of
+OpenSSL used. With OpenSSL 1.0.0 and later, the "pkey" command supports all key
+types. With OpenSSL 0.9.8 and earlier, the key type is always RSA (nobody uses
+DSA, and EC keys are not fully supported by 0.9.8), so the "rsa" command is
+used.
+
+ # OpenSSL 1.0 with all certificates and SHA-1 fingerprints.
+ $ openssl x509 -in cert.pem -noout -pubkey |
+ openssl pkey -pubin -outform DER |
+ openssl dgst -sha1 -c
+ (stdin)= 64:3f:1f:f6:e5:1e:d4:2a:56:8b:fc:09:1a:61:98:b5:bc:7c:60:58
+
+ # OpenSSL 0.9.8 with RSA certificates and MD5 fingerprints.
+ $ openssl x509 -in cert.pem -noout -pubkey |
+ openssl rsa -pubin -outform DER |
+ openssl dgst -md5 -c
+ (stdin)= f4:62:60:f6:12:8f:d5:8d:28:4d:13:a7:db:b2:ff:50
+
+Note: Postfix 2.9.0-2.9.5 computed the public key fingerprint incorrectly. To
+use public-key fingerprints, upgrade to Postfix 2.9.6 or later.
+
+SSeerrvveerr--ssiiddee cciipphheerr ccoonnttrroollss
+
+The Postfix SMTP server supports 5 distinct cipher grades as specified by the
+smtpd_tls_mandatory_ciphers configuration parameter, which determines the
+minimum cipher grade with mandatory TLS encryption. The default minimum cipher
+grade for mandatory TLS is "medium" which is essentially 128-bit encryption or
+better. The smtpd_tls_ciphers parameter (Postfix >= 2.6) controls the minimum
+cipher grade used with opportunistic TLS. Here, the default minimum cipher
+grade is "medium" for Postfix releases after the middle of 2015, "export" for
+older Postfix releases. With Postfix < 2.6, the minimum opportunistic TLS
+cipher grade is always "export".
+
+By default anonymous ciphers are enabled. They are automatically disabled when
+remote SMTP client certificates are requested. If clients are expected to
+always verify the Postfix SMTP server certificate you may want to disable
+anonymous ciphers by setting "smtpd_tls_mandatory_exclude_ciphers = aNULL" or
+"smtpd_tls_exclude_ciphers = aNULL", as appropriate. One can't force a remote
+SMTP client to check the server certificate, so excluding anonymous ciphers is
+generally unnecessary.
+
+With mandatory and opportunistic TLS encryption, the Postfix SMTP server by
+default disables SSLv2 and SSLv3 with Postfix releases after the middle of
+2015; older releases only disable SSLv2 for mandatory TLS. The mandatory TLS
+protocol list is specified via the smtpd_tls_mandatory_protocols configuration
+parameter. The smtpd_tls_protocols parameter (Postfix >= 2.6) controls the SSL/
+TLS protocols used with opportunistic TLS.
+
+Note that the OpenSSL library only supports protocol exclusion (not inclusion).
+For this reason, Postfix can exclude only protocols that are known at the time
+the Postfix software is written. If new protocols are added to the OpenSSL
+library, they cannot be excluded without corresponding changes to the Postfix
+source code.
+
+For a server that is not a public Internet MX host, Postfix supports
+configurations with no server certificates that use oonnllyy the anonymous ciphers.
+This is enabled by explicitly setting "smtpd_tls_cert_file = none" and not
+specifying an smtpd_tls_dcert_file or smtpd_tls_eccert_file.
+
+Example, MSA that requires TLSv1 or higher, not SSLv2 or SSLv3, with high grade
+ciphers:
+
+ /etc/postfix/main.cf:
+ smtpd_tls_cert_file = /etc/postfix/cert.pem
+ smtpd_tls_key_file = /etc/postfix/key.pem
+ smtpd_tls_mandatory_ciphers = high
+ smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
+ smtpd_tls_security_level = encrypt
+ # Preferred syntax with Postfix >= 2.5:
+ smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
+ # Legacy syntax:
+ smtpd_tls_mandatory_protocols = TLSv1
+
+If you want to take maximal advantage of ciphers that offer forward secrecy see
+the Getting started section of FORWARD_SECRECY_README. The full document
+conveniently presents all information about Postfix "perfect" forward secrecy
+support in one place: what forward secrecy is, how to tweak settings, and what
+you can expect to see when Postfix uses ciphers with forward secrecy.
+
+Postfix 2.8 and later, in combination with OpenSSL 0.9.7 and later allows TLS
+servers to preempt the TLS client's cipher-suite preference list. This is
+possible only with SSLv3 and later, as in SSLv2 the client chooses the cipher-
+suite from a list supplied by the server.
+
+By default, the OpenSSL server selects the client's most preferred cipher-suite
+that the server supports. With SSLv3 and later, the server may choose its own
+most preferred cipher-suite that is supported (offered) by the client. Setting
+"tls_preempt_cipherlist = yes" enables server cipher-suite preferences. The
+default OpenSSL behavior applies with "tls_preempt_cipherlist = no".
+
+While server cipher-suite selection may in some cases lead to a more secure or
+performant cipher-suite choice, there is some risk of interoperability issues.
+In the past, some SSL clients have listed lower priority ciphers that they did
+not implement correctly. If the server chooses a cipher that the client prefers
+less, it may select a cipher whose client implementation is flawed. Most
+notably Windows 2003 Microsoft Exchange servers have flawed implementations of
+DES-CBC3-SHA, which OpenSSL considers stronger than RC4-SHA. Enabling server
+cipher-suite selection may create interoperability issues with Windows 2003
+Microsoft Exchange clients.
+
+MMiisscceellllaanneeoouuss sseerrvveerr ccoonnttrroollss
+
+The smtpd_starttls_timeout parameter limits the time of Postfix SMTP server
+write and read operations during TLS startup and shutdown handshake procedures.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtpd_starttls_timeout = 300s
+
+With Postfix 2.8 and later, the tls_disable_workarounds parameter specifies a
+list or bit-mask of OpenSSL bug work-arounds to disable. This may be necessary
+if one of the work-arounds enabled by default in OpenSSL proves to pose a
+security risk, or introduces an unexpected interoperability issue. Some bug
+work-arounds known to be problematic are disabled in the default value of the
+parameter when linked with an OpenSSL library that could be vulnerable.
+
+Example:
+
+ /etc/postfix/main.cf:
+ tls_disable_workarounds = 0xFFFFFFFF
+ tls_disable_workarounds = CVE-2010-4180
+
+With Postfix >= 2.11, the tls_ssl_options parameter specifies a list or bit-
+mask of OpenSSL options to enable. Specify one or more of the named options
+below, or a hexadecimal bitmask of options found in the ssl.h file
+corresponding to the run-time OpenSSL library. While it may be reasonable to
+turn off all bug workarounds (see above), it is not a good idea to attempt to
+turn on all features.
+
+LLEEGGAACCYY__SSEERRVVEERR__CCOONNNNEECCTT
+ See SSL_CTX_set_options(3).
+NNOO__TTIICCKKEETT
+ See SSL_CTX_set_options(3).
+NNOO__CCOOMMPPRREESSSSIIOONN
+ Disable SSL compression even if supported by the OpenSSL library.
+ Compression is CPU-intensive, and compression before encryption does not
+ always improve security.
+Example:
+
+ /etc/postfix/main.cf:
+ tls_ssl_options = no_ticket, no_compression
+
+You should only enable features via the hexadecimal mask when the need to
+control the feature is critical (to deal with a new vulnerability or a serious
+interoperability problem). Postfix DOES NOT promise backwards compatible
+behavior with respect to the mask bits. A feature enabled via the mask in one
+release may be enabled by other means in a later release, and the mask bit will
+then be ignored. Therefore, use of the hexadecimal mask is only a temporary
+measure until a new Postfix or OpenSSL release provides a better solution.
+
+SSMMTTPP CClliieenntt ssppeecciiffiicc sseettttiinnggss
+
+Topics covered in this section:
+
+ * Configuring TLS in the SMTP/LMTP client
+ * Client-side TLS activity logging
+ * Client-side certificate and private key configuration
+ * Client-side TLS session cache
+ * Client TLS limitations
+ * Per-destination TLS policy
+ * Discovering servers that support TLS
+ * Server certificate verification depth
+ * Client-side cipher controls
+ * Client-side SMTPS support
+ * Miscellaneous client controls
+
+CCoonnffiigguurriinngg TTLLSS iinn tthhee SSMMTTPP//LLMMTTPP cclliieenntt
+
+Similar to the Postfix SMTP server, the Postfix SMTP/LMTP client implements
+multiple TLS security levels. These levels are described in more detail in the
+sections that follow.
+
+nnoonnee
+ No TLS.
+mmaayy
+ Opportunistic TLS.
+eennccrryypptt
+ Mandatory TLS encryption.
+ddaannee
+ Opportunistic DANE TLS.
+ddaannee--oonnllyy
+ Mandatory DANE TLS.
+ffiinnggeerrpprriinntt
+ Certificate fingerprint verification.
+vveerriiffyy
+ Mandatory server certificate verification.
+sseeccuurree
+ Secure-channel TLS.
+
+TTLLSS ssuuppppoorrtt iinn tthhee LLMMTTPP ddeelliivveerryy aaggeenntt
+
+The smtp(8) and lmtp(8) delivery agents are implemented by a single dual-
+purpose program. Specifically, all the TLS features described below apply
+equally to SMTP and LMTP, after replacing the "smtp_" prefix of the each
+parameter name with "lmtp_".
+
+The Postfix LMTP delivery agent can communicate with LMTP servers listening on
+UNIX-domain sockets. When server certificate verification is enabled and the
+server is listening on a UNIX-domain socket, the $myhostname parameter is used
+to set the TLS verification nexthop and hostname.
+
+NOTE: Opportunistic encryption of LMTP traffic over UNIX-domain sockets or
+loopback TCP connections is futile. TLS is only useful in this context when it
+is mandatory, typically to allow at least one of the server or the client to
+authenticate the other. The "null" cipher grade may be appropriate in this
+context, when available on both client and server. The "null" ciphers provide
+authentication without encryption.
+
+NNoo TTLLSS eennccrryyppttiioonn
+
+At the "none" TLS security level, TLS encryption is disabled. This is the
+default security level, and can be configured explicitly by setting
+"smtp_tls_security_level = none". For LMTP, use the corresponding "lmtp_"
+parameter.
+
+Per-destination settings may override this default setting, in which case TLS
+is used selectively, only with destinations explicitly configured for TLS.
+
+You can disable TLS for a subset of destinations, while leaving it enabled for
+the rest. With the Postfix TLS policy table, specify the "none" security level.
+
+OOppppoorrttuunniissttiicc TTLLSS
+
+At the "may" TLS security level, TLS encryption is opportunistic. The SMTP
+transaction is encrypted if the STARTTLS ESMTP feature is supported by the
+server. Otherwise, messages are sent in the clear. Opportunistic TLS can be
+configured by setting "smtp_tls_security_level = may". For LMTP, use the
+corresponding "lmtp_" parameter.
+
+The "smtp_tls_ciphers" and "smtp_tls_protocols" configuration parameters
+(Postfix >= 2.6) provide control over the cipher grade and protocols used with
+opportunistic TLS. With earlier Postfix releases, opportunistic TLS always uses
+the cipher grade "export" and enables all protocols.
+
+With opportunistic TLS, mail delivery continues even if the server certificate
+is untrusted or bears the wrong name. When the TLS handshake fails for an
+opportunistic TLS session, rather than give up on mail delivery, the Postfix
+SMTP client retries the transaction with TLS disabled. Trying an unencrypted
+connection makes it possible to deliver mail to sites with non-interoperable
+server TLS implementations.
+
+Opportunistic encryption is never used for LMTP over UNIX-domain sockets. The
+communications channel is already confidential without TLS, so the only
+potential benefit of TLS is authentication. Do not configure opportunistic TLS
+for LMTP deliveries over UNIX-domain sockets. Only configure TLS for LMTP over
+UNIX-domain sockets at the encrypt security level or higher. Attempts to
+configure opportunistic encryption of LMTP sessions will be ignored with a
+warning written to the mail logs.
+
+You can enable opportunistic TLS just for selected destinations. With the
+Postfix TLS policy table, specify the "may" security level.
+
+This is the most common security level for TLS protected SMTP sessions,
+stronger security is not generally available and, if needed, is typically only
+configured on a per-destination basis. See the section on TLS limitations
+above.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_security_level = may
+
+MMaannddaattoorryy TTLLSS eennccrryyppttiioonn
+
+At the "encrypt" TLS security level, messages are sent only over TLS encrypted
+sessions. The SMTP transaction is aborted unless the STARTTLS ESMTP feature is
+supported by the remote SMTP server. If no suitable servers are found, the
+message will be deferred. Mandatory TLS encryption can be configured by setting
+"smtp_tls_security_level = encrypt". Even though TLS encryption is always used,
+mail delivery continues even if the server certificate is untrusted or bears
+the wrong name. For LMTP, use the corresponding "lmtp_" parameter.
+
+At this security level and higher, the smtp_tls_mandatory_protocols and
+smtp_tls_mandatory_ciphers configuration parameters determine the list of
+sufficiently secure SSL protocol versions and the minimum cipher strength. If
+the protocol or cipher requirements are not met, the mail transaction is
+aborted. The documentation for these parameters includes useful
+interoperability and security guidelines.
+
+Despite the potential for eliminating passive eavesdropping attacks, mandatory
+TLS encryption is not viable as a default security level for mail delivery to
+the public Internet. Most MX hosts do not support TLS at all, and some of those
+that do have broken implementations. On a host that delivers mail to the
+Internet, you should not configure mandatory TLS encryption as the default
+security level.
+
+You can enable mandatory TLS encryption just for specific destinations. With
+the Postfix TLS policy table, specify the "encrypt" security level.
+
+Examples:
+
+In the example below, traffic to example.com and its sub-domains via the
+corresponding MX hosts always uses TLS. The SSLv2 protocol will be disabled
+(the default setting of smtp_tls_mandatory_protocols excludes SSLv2+3). Only
+high- or medium-strength (i.e. 128 bit or better) ciphers will be used by
+default for all "encrypt" security level sessions.
+
+ /etc/postfix/main.cf:
+ smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+
+ /etc/postfix/tls_policy:
+ example.com encrypt
+ .example.com encrypt
+
+In the next example, secure message submission is configured via the MSA "
+[example.net]:587". TLS sessions are encrypted without authentication, because
+this MSA does not possess an acceptable certificate. This MSA is known to be
+capable of "TLSv1" and "high" grade ciphers, so these are selected via the
+policy table.
+
+NNoottee:: the policy table lookup key is the verbatim next-hop specification from
+the recipient domain, transport(5) table or relayhost parameter, with any
+enclosing square brackets and optional port. Take care to be consistent: the
+suffixes ":smtp" or ":25" or no port suffix result in different policy table
+lookup keys, even though they are functionally equivalent nexthop
+specifications. Use at most one of these forms for all destinations. Below, the
+policy table has multiple keys, just in case the transport table entries are
+not specified consistently.
+
+ /etc/postfix/main.cf:
+ smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+
+ /etc/services:
+ submission 587/tcp msa # mail message
+ submission
+
+ /etc/postfix/tls_policy:
+ [example.net]:587 encrypt protocols=TLSv1 ciphers=high
+ [example.net]:msa encrypt protocols=TLSv1 ciphers=high
+ [example.net]:submission encrypt protocols=TLSv1 ciphers=high
+
+DDAANNEE TTLLSS aauutthheennttiiccaattiioonn..
+
+The Postfix SMTP client supports two TLS security levels based on RFC6698 DANE
+TLSA records. The opportunistic "dane" level and the mandatory "dane-only"
+level.
+
+The "dane" level is a stronger form of opportunistic TLS that is resistant to
+man in the middle and downgrade attacks when the destination domain uses DNSSEC
+to publish DANE TLSA records for its MX hosts. If a remote SMTP server has
+"usable" (see RFC 6698) DANE TLSA records, the server connection will be
+authenticated. When DANE authentication fails, there is no fallback to
+unauthenticated or plaintext delivery.
+
+If TLSA records are published for a given remote SMTP server (implying TLS
+support), but are all "unusable" due to unsupported parameters or malformed
+data, the Postfix SMTP client will use mandatory unauthenticated TLS.
+Otherwise, when no TLSA records are published, the Postfix SMTP client behavior
+is the same as with may.
+
+TLSA records must be published in DNSSEC validated DNS zones. Any TLSA records
+in DNS zones not protected via DNSSEC are ignored. The Postfix SMTP client will
+not look for TLSA records associated with MX hosts whose "A" or "AAAA" records
+lie in an "insecure" DNS zone. Such lookups have been observed to cause
+interoperability issues with poorly implemented DNS servers, and are in any
+case not expected to ever yield "secure" results, since that would require a
+very unlikely DLV DNS trust anchor configured between the host record and the
+associated "_25._tcp" child TLSA record.
+
+The "dane-only" level is a form of secure-channel TLS based on the DANE PKI. If
+"usable" TLSA records are present these are used to authenticate the remote
+SMTP server. Otherwise, or when server certificate verification fails, delivery
+via the server in question tempfails.
+
+At both security levels, the TLS policy for the destination is obtained via
+TLSA records validated with DNSSEC. For TLSA policy to be in effect, the
+destination domain's containing DNS zone must be signed and the Postfix SMTP
+client's operating system must be configured to send its DNS queries to a
+recursive DNS nameserver that is able to validate the signed records. Each MX
+host's DNS zone needs to also be signed, and needs to publish DANE TLSA (RFC
+6698) records that specify how that MX host's TLS certificate is to be
+verified.
+
+TLSA records do not preempt the normal SMTP MX host selection algorithm, if
+some MX hosts support TLSA and others do not, TLS security will vary from
+delivery to delivery. It is up to the domain owner to configure their MX hosts
+and their DNS sensibly. To configure the Postfix SMTP client for DNSSEC lookups
+see the documentation for the smtp_dns_support_level main.cf parameter. The
+tls_dane_trust_anchor_digest_enable main.cf parameter controls support for
+trust-anchor digest TLSA records. The tls_dane_digests and
+tls_dane_digest_agility parameters control the list of supported digests and
+digest downgrade attack resistance.
+
+DANE for SMTP MTAs deviates in some details from the baseline DANE protocol in
+RFC 6698. Most notably, it is not expected that SMTP MTAs can reasonably
+include every public CA that a remote SMTP server's administrator may believe
+to be well-known. Nor is there an interactive user to "click OK" when
+authentication fails.
+
+Therefore, certificate usages "0" and "1" from RFC 6698 which are intended to
+"constrain" existing PKI trust, are not supported. TLSA records with usage "0"
+are treated as "unusable". TLSA records with usage "1" are instead treated as
+"trust assertions" and mapped to usage "3". Specifically, with certificate
+usage "1", Postfix will not require the remote SMTP server's certificate to be
+trusted with respect to any locally defined public CAs, it is the domain
+owner's responsibility to ensure that the certificate associations in their
+TLSA records are appropriate to authenticate their SMTP servers.
+
+The Postfix SMTP client supports only certificate usages "2" and "3" (with "1"
+treated as though it were "3"). See tls_dane_trust_anchor_digest_enable for
+usage "2" usability considerations. Support for certificate usage "1" is an
+experiment, it may be withdrawn in the future. Server operators SHOULD NOT
+publish TLSA records with usage "1".
+
+When usable TLSA records are obtained for the remote SMTP server the Postfix
+SMTP client sends the SNI TLS extension in its SSL client hello message. This
+may help the remote SMTP server live up to its promise to provide a certificate
+that matches its TLSA records.
+
+For purposes of protocol and cipher selection, the "dane" security level is
+treated like a "mandatory" TLS security level, and weak ciphers and protocols
+are disabled. Since DANE authenticates server certificates the "aNULL" cipher-
+suites are transparently excluded at this level, no need to configure this
+manually. RFC 6698 (DANE) TLS authentication is available with Postfix 2.11 and
+later.
+
+When a DANE TLSA record specifies a trust-anchor (TA) certificate (that is an
+issuing CA), the strategy used to verify the peername of the server certificate
+is unconditionally "nexthop, hostname". Both the nexthop domain and the
+hostname obtained from the DNSSEC-validated MX lookup are safe from forgery and
+the server certificate must contain at least one of these names.
+
+When a DANE TLSA record specifies an end-entity (EE) certificate, (that is the
+actual server certificate), as with the fingerprint security level below, no
+name checks or certificate expiration checks are applied. The server
+certificate (or its public key) either matches the DANE record or not. Server
+administrators should publish such EE records in preference to all other types.
+
+The pre-requisites for DANE support in the Postfix SMTP client are:
+
+ * A compile-time OpenSSL library that supports the TLS SNI extension and
+ "SHA-2" message digests.
+ * A compile-time DNS resolver library that supports DNSSEC. Postfix binaries
+ built on an older system will not support DNSSEC even if deployed on a
+ system with an updated resolver library.
+ * The "smtp_dns_support_level" must be set to "dnssec".
+ * The "smtp_host_lookup" parameter must include "dns".
+ * A DNSSEC-validating recursive resolver (see note below).
+
+The above client pre-requisites do not apply to the Postfix SMTP server. It
+will support DANE provided it supports TLSv1 and its TLSA records are published
+in a DNSSEC signed zone. To receive DANE secured mail for multiple domains, use
+the same hostname to add the server to each domain's MX records. There are no
+plans to implement SNI in the Postfix SMTP server.
+
+Note: The Postfix SMTP client's internal stub DNS resolver is DNSSEC-aware, but
+it does not itself validate DNSSEC records, rather it delegates DNSSEC
+validation to the operating system's configured recursive DNS nameserver. The
+Postfix DNS client relies on a secure channel to the resolver's cache for
+DNSSEC integrity, but does not support TSIG to protect the transmission channel
+between itself and the nameserver. Therefore, it is strongly recommended (DANE
+security guarantee void otherwise) that each MTA run a local DNSSEC-validating
+recursive resolver ("unbound" from nlnetlabs.nl is a reasonable choice)
+listening on the loopback interface, and that the system be configured to use
+only this local nameserver. The local nameserver may forward queries to an
+upstream recursive resolver on another host if desired.
+
+Note: When the operating system's recursive nameserver is not local, enabling
+EDNS0 expanded DNS packet sizes and turning on the DNSSEC "DO" bit in the DNS
+request and/or the new DNSSEC-specific records returned in the nameserver's
+replies may cause problems with older or buggy firewall and DNS server
+implementations. Therefore, Postfix does not enable DNSSEC by default. Since MX
+lookups happen before the security level is determined, DANE support is
+disabled for all destinations unless you set "smtp_dns_support_level = dnssec".
+To enable DNSSEC lookups selectively, define a new dedicated transport with a
+"-o smtp_dns_support_level=dnssec" override in master.cf and route selected
+domains to that transport. If DNSSEC proves to be sufficiently reliable for
+these domains, you can enable it for all destinations by changing the global
+smtp_dns_support_level in main.cf.
+
+EExxaammppllee: "dane" security for selected destinations, with opportunistic TLS by
+default. This is the recommended configuration for early adopters.
+
+ * The "example.com" destination uses DANE, but if TLSA records are not
+ present or are unusable, mail is deferred.
+
+ * The "example.org" destination uses DANE if possible, but if no TLSA records
+ are found opportunistic TLS is used.
+
+ main.cf:
+ indexed = ${default_database_type}:${config_directory}/
+ #
+ # default: Opportunistic TLS with no DNSSEC lookups.
+ #
+ smtp_tls_security_level = may
+ smtp_dns_support_level = enabled
+ #
+ # Per-destination TLS policy
+ #
+ smtp_tls_policy_maps = ${indexed}tls_policy
+ #
+ # default_transport = smtp, but some destinations are special:
+ #
+ transport_maps = ${indexed}transport
+
+ transport:
+ example.com dane
+ example.org dane
+
+ tls_policy:
+ example.com dane-only
+
+ master.cf:
+ dane unix - - n - - smtp
+ -o smtp_dns_support_level=dnssec
+ -o smtp_tls_security_level=dane
+
+CCeerrttiiffiiccaattee ffiinnggeerrpprriinntt vveerriiffiiccaattiioonn
+
+At the fingerprint security level, no trusted Certification Authorities are
+used or required. The certificate trust chain, expiration date, etc., are not
+checked. Instead, the smtp_tls_fingerprint_cert_match parameter or the "match"
+attribute in the policy table lists the remote SMTP server certificate
+fingerprint or public key fingerprint. Certificate fingerprint verification is
+available with Postfix 2.5 and later, public-key fingerprint support is
+available with Postfix 2.9 and later.
+
+If certificate fingerprints are exchanged securely, this is the strongest, and
+least scalable security level. The administrator needs to securely collect the
+fingerprints of the X.509 certificates of each peer server, store them into a
+local file, and update this local file whenever the peer server's public
+certificate changes. If public key fingerprints are used in place of
+fingerprints of the entire certificate, the fingerprints remain valid even
+after the certificate is renewed, pprroovviiddeedd that the same public/private keys
+are used to obtain the new certificate.
+
+Fingerprint verification may be feasible for an SMTP "VPN" connecting a small
+number of branch offices over the Internet, or for secure connections to a
+central mail hub. It works poorly if the remote SMTP server is managed by a
+third party, and its public certificate changes periodically without prior
+coordination with the verifying site.
+
+The digest algorithm used to calculate the fingerprint is selected by the
+ssmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt parameter. In the policy table multiple
+fingerprints can be combined with a "|" delimiter in a single match attribute,
+or multiple match attributes can be employed. The ":" character is not used as
+a delimiter as it occurs between each pair of fingerprint (hexadecimal) digits.
+
+Example: fingerprint TLS security with an internal mailhub. Two matching
+fingerprints are listed. The relayhost may be multiple physical hosts behind a
+load-balancer, each with its own private/public key and self-signed
+certificate. Alternatively, a single relayhost may be in the process of
+switching from one set of private/public keys to another, and both keys are
+trusted just prior to the transition.
+
+ relayhost = [mailhub.example.com]
+ smtp_tls_security_level = fingerprint
+ smtp_tls_fingerprint_digest = md5
+ smtp_tls_fingerprint_cert_match =
+ 3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+ EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+
+Example: Certificate fingerprint verification with selected destinations. As in
+the example above, we show two matching fingerprints:
+
+ /etc/postfix/main.cf:
+ smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+ smtp_tls_fingerprint_digest = md5
+
+ /etc/postfix/tls_policy:
+ example.com fingerprint
+ match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+ match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+
+To extract the public key fingerprint from an X.509 certificate, you need to
+extract the public key from the certificate and compute the appropriate digest
+of its DER (ASN.1) encoding. With OpenSSL the "-pubkey" option of the "x509"
+command extracts the public key always in "PEM" format. We pipe the result to
+another OpenSSL command that converts the key to DER and then to the "dgst"
+command to compute the fingerprint.
+
+The actual command to transform the key to DER format depends on the version of
+OpenSSL used. With OpenSSL 1.0.0 and later, the "pkey" command supports all key
+types. With OpenSSL 0.9.8 and earlier, the key type is always RSA (nobody uses
+DSA, and EC keys are not fully supported by 0.9.8), so the "rsa" command is
+used.
+
+ # OpenSSL 1.0 with all certificates and SHA-1 fingerprints.
+ $ openssl x509 -in cert.pem -noout -pubkey |
+ openssl pkey -pubin -outform DER |
+ openssl dgst -sha1 -c
+ (stdin)= 64:3f:1f:f6:e5:1e:d4:2a:56:8b:fc:09:1a:61:98:b5:bc:7c:60:58
+
+ # OpenSSL 0.9.8 with RSA certificates and MD5 fingerprints.
+ $ openssl x509 -in cert.pem -noout -pubkey |
+ openssl rsa -pubin -outform DER |
+ openssl dgst -md5 -c
+ (stdin)= f4:62:60:f6:12:8f:d5:8d:28:4d:13:a7:db:b2:ff:50
+
+Note: Postfix 2.9.0-2.9.5 computed the public key fingerprint incorrectly. To
+use public-key fingerprints, upgrade to Postfix 2.9.6 or later.
+
+MMaannddaattoorryy sseerrvveerr cceerrttiiffiiccaattee vveerriiffiiccaattiioonn
+
+At the verify TLS security level, messages are sent only over TLS encrypted
+sessions if the remote SMTP server certificate is valid (not expired or
+revoked, and signed by a trusted Certification Authority) and where the server
+certificate name matches a known pattern. Mandatory server certificate
+verification can be configured by setting "smtp_tls_security_level = verify".
+The smtp_tls_verify_cert_match parameter can override the default "hostname"
+certificate name matching strategy. Fine-tuning the matching strategy is
+generally only appropriate for secure-channel destinations. For LMTP use the
+corresponding "lmtp_" parameters.
+
+If the server certificate chain is trusted (see smtp_tls_CAfile and
+smtp_tls_CApath), any DNS names in the SubjectAlternativeName certificate
+extension are used to verify the remote SMTP server name. If no DNS names are
+specified, the certificate CommonName is checked. If you want mandatory
+encryption without server certificate verification, see above.
+
+With Postfix >= 2.11 the "smtp_tls_trust_anchor_file" parameter or more
+typically the corresponding per-destination "tafile" attribute optionally
+modifies trust chain verification. If the parameter is not empty the root CAs
+in CAfile and CApath are no longer trusted. Rather, the Postfix SMTP client
+will only trust certificate-chains signed by one of the trust-anchors contained
+in the chosen files. The specified trust-anchor certificates and public keys
+are not subject to expiration, and need not be (self-signed) root CAs. They
+may, if desired, be intermediate certificates. Therefore, these certificates
+also may be found "in the middle" of the trust chain presented by the remote
+SMTP server, and any untrusted issuing parent certificates will be ignored.
+
+Despite the potential for eliminating "man-in-the-middle" and other attacks,
+mandatory certificate trust chain and subject name verification is not viable
+as a default Internet mail delivery policy. Most MX hosts do not support TLS at
+all, and a significant portion of TLS enabled MTAs use self-signed
+certificates, or certificates that are signed by a private Certification
+Authority. On a machine that delivers mail to the Internet, you should not
+configure mandatory server certificate verification as a default policy.
+
+Mandatory server certificate verification as a default security level may be
+appropriate if you know that you will only connect to servers that support RFC
+2487 and that present verifiable server certificates. An example would be a
+client that sends all email to a central mailhub that offers the necessary
+STARTTLS support. In such cases, you can often use a secure-channel
+configuration instead.
+
+You can enable mandatory server certificate verification just for specific
+destinations. With the Postfix TLS policy table, specify the "verify" security
+level.
+
+Example:
+
+In this example, the Postfix SMTP client encrypts all traffic to the
+example.com domain. The peer hostname is verified, but verification is
+vulnerable to DNS response forgery. Mail transmission to example.com recipients
+uses "high" grade ciphers.
+
+ /etc/postfix/main.cf:
+ indexed = ${default_database_type}:${config_directory}/
+ smtp_tls_CAfile = ${config_directory}/CAfile.pem
+ smtp_tls_policy_maps = ${indexed}tls_policy
+
+ /etc/postfix/tls_policy:
+ example.com verify ciphers=high
+
+SSeeccuurree sseerrvveerr cceerrttiiffiiccaattee vveerriiffiiccaattiioonn
+
+At the secure TLS security level, messages are sent only over secure-channel
+TLS sessions where DNS forgery resistant server certificate verification
+succeeds. If no suitable servers are found, the message will be deferred.
+Postfix secure-channels can be configured by setting "smtp_tls_security_level =
+secure". The smtp_tls_secure_cert_match parameter can override the default
+"nexthop, dot-nexthop" certificate match strategy. For LMTP, use the
+corresponding "lmtp_" parameters.
+
+If the server certificate chain is trusted (see smtp_tls_CAfile and
+smtp_tls_CApath), any DNS names in the SubjectAlternativeName certificate
+extension are used to verify the remote SMTP server name. If no DNS names are
+specified, the CommonName is checked. If you want mandatory encryption without
+server certificate verification, see above.
+
+With Postfix >= 2.11 the "smtp_tls_trust_anchor_file" parameter or more
+typically the corresponding per-destination "tafile" attribute optionally
+modifies trust chain verification. If the parameter is not empty the root CAs
+in CAfile and CApath are no longer trusted. Rather, the Postfix SMTP client
+will only trust certificate-chains signed by one of the trust-anchors contained
+in the chosen files. The specified trust-anchor certificates and public keys
+are not subject to expiration, and need not be (self-signed) root CAs. They
+may, if desired, be intermediate certificates. Therefore, these certificates
+also may be found "in the middle" of the trust chain presented by the remote
+SMTP server, and any untrusted issuing parent certificates will be ignored.
+
+Despite the potential for eliminating "man-in-the-middle" and other attacks,
+mandatory secure server certificate verification is not viable as a default
+Internet mail delivery policy. Most MX hosts do not support TLS at all, and a
+significant portion of TLS enabled MTAs use self-signed certificates, or
+certificates that are signed by a private Certification Authority. On a machine
+that delivers mail to the Internet, you should not configure secure TLS
+verification as a default policy.
+
+Mandatory secure server certificate verification as a default security level
+may be appropriate if you know that you will only connect to servers that
+support RFC 2487 and that present verifiable server certificates. An example
+would be a client that sends all email to a central mailhub that offers the
+necessary STARTTLS support.
+
+You can enable secure TLS verification just for specific destinations. With the
+Postfix TLS policy table, specify the "secure" security level.
+
+Examples:
+
+ * Secure-channel TLS without transport(5) table overrides:
+
+ The Postfix SMTP client will encrypt all traffic and verify the destination
+ name immune from forged DNS responses. MX lookups are still used to find
+ the hostnames of the SMTP servers for example.com, but these hostnames are
+ not used when checking the names in the server certificate(s). Rather, the
+ requirement is that the MX hosts for example.com have trusted certificates
+ with a subject name of example.com or a sub-domain, see the documentation
+ for the smtp_tls_secure_cert_match parameter.
+
+ The related domains example.co.uk and example.co.jp are hosted on the same
+ MX hosts as the primary example.com domain, and traffic to these is secured
+ by verifying the primary example.com domain in the server certificates.
+ This frees the server administrator from needing the CA to sign
+ certificates that list all the secondary domains. The downside is that
+ clients that want secure channels to the secondary domains need explicit
+ TLS policy table entries.
+
+ Note, there are two ways to handle related domains. The first is to use the
+ default routing for each domain, but add policy table entries to override
+ the expected certificate subject name. The second is to override the next-
+ hop in the transport table, and use a single policy table entry for the
+ common nexthop. We choose the first approach, because it works better when
+ domain ownership changes. With the second approach we securely deliver mail
+ to the wrong destination, with the first approach, authentication fails and
+ mail stays in the local queue, the first approach is more appropriate in
+ most cases.
+
+ /etc/postfix/main.cf:
+ smtp_tls_CAfile = /etc/postfix/CAfile.pem
+ smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+
+ /etc/postfix/transport:
+
+ /etc/postfix/tls_policy:
+ example.com secure
+ example.co.uk secure match=example.com:.example.com
+ example.co.jp secure match=example.com:.example.com
+
+ * Secure-channel TLS with transport(5) table overrides:
+
+ In this case traffic to example.com and its related domains is sent to a
+ single logical gateway (to avoid a single point of failure, its name may
+ resolve to one or more load-balancer addresses, or to the combined
+ addresses of multiple physical hosts). All the physical hosts reachable via
+ the gateway's IP addresses have the logical gateway name listed in their
+ certificates.
+
+ /etc/postfix/main.cf:
+ smtp_tls_CAfile = /etc/postfix/CAfile.pem
+ transport_maps = hash:/etc/postfix/transport
+ smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+
+ /etc/postfix/transport:
+ example.com smtp:[tls.example.com]
+ example.co.uk smtp:[tls.example.com]
+ example.co.jp smtp:[tls.example.com]
+
+ /etc/postfix/tls_policy:
+ [tls.example.com] secure match=tls.example.com
+
+CClliieenntt--ssiiddee TTLLSS aaccttiivviittyy llooggggiinngg
+
+To get additional information about Postfix SMTP client TLS activity you can
+increase the loglevel from 0..4. Each logging level also includes the
+information that is logged at a lower logging level.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |LLeevveell|PPoossttffiixx 22..99 aanndd llaatteerr |EEaarrlliieerr rreelleeaasseess.. |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |0 |Disable logging of TLS activity. |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |1 |Log only a summary message on TLS |Log the summary message and |
+ | |handshake completion -- no logging|unconditionally log trust-chain|
+ | |of remote SMTP server certificate |verification errors. |
+ | |trust-chain verification errors if| |
+ | |server certificate verification is| |
+ | |not required. | |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |2 |Also log levels during TLS negotiation. |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |3 |Also log hexadecimal and ASCII dump of TLS negotiation process. |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |4 |Also log hexadecimal and ASCII dump of complete transmission after|
+ | |STARTTLS. |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_loglevel = 0
+
+CClliieenntt--ssiiddee cceerrttiiffiiccaattee aanndd pprriivvaattee kkeeyy ccoonnffiigguurraattiioonn
+
+Do not configure Postfix SMTP client certificates unless you mmuusstt present
+client TLS certificates to one or more servers. Client certificates are not
+usually needed, and can cause problems in configurations that work well without
+them. The recommended setting is to let the defaults stand:
+
+ smtp_tls_cert_file =
+ smtp_tls_dcert_file =
+ smtp_tls_key_file =
+ smtp_tls_dkey_file =
+ # Postfix >= 2.6
+ smtp_tls_eccert_file =
+ smtp_tls_eckey_file =
+
+The best way to use the default settings is to comment out the above parameters
+in main.cf if present.
+
+During TLS startup negotiation the Postfix SMTP client may present a
+certificate to the remote SMTP server. The Netscape client is rather clever
+here and lets the user select between only those certificates that match CA
+certificates offered by the remote SMTP server. As the Postfix SMTP client uses
+the "SSL_connect()" function from the OpenSSL package, this is not possible and
+we have to choose just one certificate. So for now the default is to use _no_
+certificate and key unless one is explicitly specified here.
+
+RSA, DSA and ECDSA (Postfix >= 2.6) certificates are supported. You can
+configure all three at the same time, in which case the cipher used determines
+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.
+
+To enable remote SMTP servers to verify the Postfix SMTP client certificate,
+the issuing CA certificates must be made available to the server. You should
+include the required certificates in the client certificate file, the client
+certificate first, then the issuing CA(s) (bottom-up order).
+
+Example: the certificate for "client.example.com" was issued by "intermediate
+CA" which itself has a certificate issued by "root CA". Create the client.pem
+file with:
+
+ % ccaatt cclliieenntt__cceerrtt..ppeemm iinntteerrmmeeddiiaattee__CCAA..ppeemm >> cclliieenntt..ppeemm
+
+A Postfix SMTP client certificate supplied here must be usable as SSL client
+certificate and hence pass the "openssl verify -purpose sslclient ..." test.
+
+A server that trusts the root CA has a local copy of the root CA certificate,
+so it is not necessary to include the root CA certificate here. Leaving it out
+of the "client.pem" file reduces the overhead of the TLS exchange.
+
+If you want the Postfix SMTP client to accept remote SMTP server certificates
+issued by these CAs, append the root certificate to $smtp_tls_CAfile or install
+it in the $smtp_tls_CApath directory.
+
+RSA key and certificate examples:
+
+ /etc/postfix/main.cf:
+ smtp_tls_cert_file = /etc/postfix/client.pem
+ smtp_tls_key_file = $smtp_tls_cert_file
+
+Their DSA counterparts:
+
+ /etc/postfix/main.cf:
+ smtp_tls_dcert_file = /etc/postfix/client-dsa.pem
+ smtp_tls_dkey_file = $smtp_tls_dcert_file
+
+Their ECDSA counterparts (Postfix >= 2.6 + OpenSSL >= 1.0.0):
+
+ /etc/postfix/main.cf:
+ smtp_tls_eccert_file = /etc/postfix/client-ecdsa.pem
+ smtp_tls_eckey_file = $smtp_tls_eccert_file
+
+To verify a remote SMTP server certificate, the Postfix SMTP client needs to
+trust the certificates of the issuing Certification Authorities. These
+certificates in "pem" format can be stored in a single $smtp_tls_CAfile or in
+multiple files, one CA per file in the $smtp_tls_CApath directory. If you use a
+directory, don't forget to create the necessary "hash" links with:
+
+ # $$OOPPEENNSSSSLL__HHOOMMEE//bbiinn//cc__rreehhaasshh //ppaatthh//ttoo//ddiirreeccttoorryy
+
+The $smtp_tls_CAfile contains the CA certificates of one or more trusted CAs.
+The file is opened (with root privileges) before Postfix enters the optional
+chroot jail and so need not be accessible from inside the chroot jail.
+
+Additional trusted CAs can be specified via the $smtp_tls_CApath directory, in
+which case the certificates are read (with $mail_owner privileges) from the
+files in the directory when the information is needed. Thus, the
+$smtp_tls_CApath directory needs to be accessible inside the optional chroot
+jail.
+
+The choice between $smtp_tls_CAfile and $smtp_tls_CApath is a space/time
+tradeoff. If there are many trusted CAs, the cost of preloading them all into
+memory may not pay off in reduced access time when the certificate is needed.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_CAfile = /etc/postfix/CAcert.pem
+ smtp_tls_CApath = /etc/postfix/certs
+
+CClliieenntt--ssiiddee TTLLSS sseessssiioonn ccaacchhee
+
+The remote SMTP server and the Postfix SMTP client negotiate a session, which
+takes some computer time and network bandwidth. By default, this session
+information is cached only in the smtp(8) process actually using this session
+and is lost when the process terminates. To share the session information
+between multiple smtp(8) processes, a persistent session cache can be used. You
+can specify any database type that can store objects of several kbytes and that
+supports the sequence operator. DBM databases are not suitable because they can
+only store small objects. The cache is maintained by the tlsmgr(8) process, so
+there is no problem with concurrent access. Session caching is highly
+recommended, because the cost of repeatedly negotiating TLS session keys is
+high. Future Postfix SMTP servers may limit the number of sessions that a
+client is allowed to negotiate per unit time.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
+
+Note: as of version 2.5, Postfix no longer uses root privileges when opening
+this file. The file should now be stored under the Postfix-owned
+data_directory. As a migration aid, an attempt to open the file under a non-
+Postfix directory is redirected to the Postfix-owned data_directory, and a
+warning is logged.
+
+Cached Postfix SMTP client session information expires after a certain amount
+of time. Postfix/TLS does not use the OpenSSL default of 300s, but a longer
+time of 3600s (=1 hour). RFC 2246 recommends a maximum of 24 hours.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_session_cache_timeout = 3600s
+
+As of Postfix 2.11 this setting cannot exceed 100 days. If set <= 0, session
+caching is disabled. If set to a positive value less than 2 minutes, the
+minimum value of 2 minutes is used instead.
+
+CClliieenntt TTLLSS lliimmiittaattiioonnss
+
+The security properties of TLS communication channels are application specific.
+While the TLS protocol can provide a confidential, tamper-resistant, mutually
+authenticated channel between client and server, not all of these security
+features are applicable to every communication.
+
+For example, while mutual TLS authentication between browsers and web servers
+is possible, it is not practical, or even useful, for web-servers that serve
+the public to verify the identity of every potential user. In practice, most
+HTTPS transactions are asymmetric: the browser verifies the HTTPS server's
+identity, but the user remains anonymous. Much of the security policy is up to
+the client. If the client chooses to not verify the server's name, the server
+is not aware of this. There are many interesting browser security topics, but
+we shall not dwell on them here. Rather, our goal is to understand the security
+features of TLS in conjunction with SMTP.
+
+An important SMTP-specific observation is that a public MX host is even more at
+the mercy of the SMTP client than is an HTTPS server. Not only can it not
+enforce due care in the client's use of TLS, but it cannot even enforce the use
+of TLS, because TLS support in SMTP clients is still the exception rather than
+the rule. One cannot, in practice, limit access to one's MX hosts to just TLS-
+enabled clients. Such a policy would result in a vast reduction in one's
+ability to communicate by email with the world at large.
+
+One may be tempted to try enforcing TLS for mail from specific sending
+organizations, but this, too, runs into obstacles. One such obstacle is that we
+don't know who is (allegedly) sending mail until we see the "MAIL FROM:" SMTP
+command, and at that point, if TLS is not already in use, a potentially
+sensitive sender address (and with SMTP PIPELINING one or more of the
+recipients) has (have) already been leaked in the clear. Another obstacle is
+that mail from the sender to the recipient may be forwarded, and the forwarding
+organization may not have any security arrangements with the final destination.
+Bounces also need to be protected. These can only be identified by the IP
+address and HELO name of the connecting client, and it is difficult to keep
+track of all the potential IP addresses or HELO names of the outbound email
+servers of the sending organization.
+
+Consequently, TLS security for mail delivery to public MX hosts is almost
+entirely the client's responsibility. The server is largely a passive enabler
+of TLS security, the rest is up to the client. While the server has a greater
+opportunity to mandate client security policy when it is a dedicated MSA that
+only handles outbound mail from trusted clients, below we focus on the client
+security policy.
+
+On the SMTP client, there are further complications. When delivering mail to a
+given domain, in contrast to HTTPS, one rarely uses the domain name directly as
+the target host of the SMTP session. More typically, one uses MX lookups -
+- these are usually unauthenticated -- to obtain the domain's SMTP server
+hostname(s). When, as is current practice, the client verifies the insecurely
+obtained MX hostname, it is subject to a DNS man-in-the-middle attack.
+
+Adoption of DNSSEC and RFC6698 (DANE) may gradually (as domains implement
+DNSSEC and publish TLSA records for their MX hosts) address the DNS man-in-the-
+middle risk and provide scalable key management for SMTP with TLS. Postfix >=
+2.11 supports the new dane and dane-only security levels that take advantage of
+these standards.
+
+If clients instead attempted to verify the recipient domain name, an SMTP
+server for multiple domains would need to list all its email domain names in
+its certificate, and generate a new certificate each time a new domain were
+added. At least some CAs set fairly low limits (20 for one prominent CA) on the
+number of names that server certificates can contain. This approach is not
+consistent with current practice and does not scale.
+
+It is regrettably the case that TLS secure-channels (fully authenticated and
+immune to man-in-the-middle attacks) impose constraints on the sending and
+receiving sites that preclude ubiquitous deployment. One needs to manually
+configure this type of security for each destination domain, and in many cases
+implement non-default TLS policy table entries for additional domains hosted at
+a common secured destination. For these reasons secure-channel configurations
+will never be the norm. For the generic domain with which you have made no
+specific security arrangements, this security level is not a good fit.
+
+Given that strong authentication is not generally possible, and that verifiable
+certificates cost time and money, many servers that implement TLS use self-
+signed certificates or private CAs. This further limits the applicability of
+verified TLS on the public Internet.
+
+Historical note: while the documentation of these issues and many of the
+related features were new with Postfix 2.3, the issue was well understood
+before Postfix 1.0, when Lutz Jänicke was designing the first unofficial
+Postfix TLS patch. See his original post http://www.imc.org/ietf-apps-tls/mail-
+archive/msg00304.html and the first response http://www.imc.org/ietf-apps-tls/
+mail-archive/msg00305.html. The problem is not even unique to SMTP or even TLS,
+similar issues exist for secure connections via aliases for HTTPS and Kerberos.
+SMTP merely uses indirect naming (via MX records) more frequently.
+
+TTLLSS ppoolliiccyy ttaabbllee
+
+A small fraction of servers offer STARTTLS but the negotiation consistently
+fails. As long as encryption is not mandatory, the Postfix SMTP client retries
+the delivery immediately with TLS disabled, without any need to explicitly
+disable TLS for the problem destinations.
+
+The policy table is specified via the smtp_tls_policy_maps parameter. This
+lists optional lookup tables with the Postfix SMTP client TLS security policy
+by next-hop destination.
+
+The TLS policy table is indexed by the full next-hop destination, which is
+either the recipient domain, or the verbatim next-hop specified in the
+transport table, $local_transport, $virtual_transport, $relay_transport or
+$default_transport. This includes any enclosing square brackets and any non-
+default destination server port suffix. The LMTP socket type prefix (inet: or
+unix:) is not included in the lookup key.
+
+Only the next-hop domain, or $myhostname with LMTP over UNIX-domain sockets, is
+used as the nexthop name for certificate verification. The port and any
+enclosing square brackets are used in the table lookup key, but are not used
+for server name verification.
+
+When the lookup key is a domain name without enclosing square brackets or any :
+port suffix (typically the recipient domain), and the full domain is not found
+in the table, just as with the transport(5) table, the parent domain starting
+with a leading "." is matched recursively. This allows one to specify a
+security policy for a recipient domain and all its sub-domains.
+
+The lookup result is a security level, followed by an optional list of
+whitespace and/or comma separated name=value attributes that override related
+main.cf settings. The TLS security levels are described above. Below, we
+describe the corresponding table syntax:
+
+nnoonnee
+ No TLS. No additional attributes are supported at this level.
+mmaayy
+ Opportunistic TLS. The optional "ciphers", "exclude" and "protocols"
+ attributes (available for opportunistic TLS with Postfix >= 2.6) override
+ the "smtp_tls_ciphers", "smtp_tls_exclude_ciphers" and "smtp_tls_protocols"
+ configuration parameters.
+eennccrryypptt
+ Mandatory encryption. Mail is delivered only if the remote SMTP server
+ offers STARTTLS and the TLS handshake succeeds. At this level and higher,
+ the optional "protocols" attribute overrides the main.cf
+ smtp_tls_mandatory_protocols parameter, the optional "ciphers" attribute
+ overrides the main.cf smtp_tls_mandatory_ciphers parameter, and the
+ optional "exclude" attribute (Postfix >= 2.6) overrides the main.cf
+ smtp_tls_mandatory_exclude_ciphers parameter.
+ddaannee
+ Opportunistic DANE TLS. The TLS policy for the destination is obtained via
+ TLSA records in DNSSEC. If no TLSA records are found, the effective
+ security level used is may. If TLSA records are found, but none are usable,
+ the effective security level is encrypt. When usable TLSA records are
+ obtained for the remote SMTP server, SSLv2+3 are automatically disabled
+ (see smtp_tls_mandatory_protocols), and the server certificate must match
+ the TLSA records. RFC 6698 (DANE) TLS authentication and DNSSEC support is
+ available with Postfix 2.11 and later.
+ddaannee--oonnllyy
+ Mandatory DANE TLS. The TLS policy for the destination is obtained via TLSA
+ records in DNSSEC. If no TLSA records are found, or none are usable, no
+ connection is made to the server. When usable TLSA records are obtained for
+ the remote SMTP server, SSLv2+3 are automatically disabled (see
+ smtp_tls_mandatory_protocols), and the server certificate must match the
+ TLSA records. RFC 6698 (DANE) TLS authentication and DNSSEC support is
+ available with Postfix 2.11 and later.
+ffiinnggeerrpprriinntt
+ Certificate fingerprint verification. Available with Postfix 2.5 and later.
+ At this security level, there are no trusted Certification Authorities. The
+ certificate trust chain, expiration date, ... are not checked. Instead, the
+ optional mmaattcchh attribute, or else the main.cf
+ ssmmttpp__ttllss__ffiinnggeerrpprriinntt__cceerrtt__mmaattcchh parameter, lists the server certificate
+ fingerprints or public key fingerprints (Postfix 2.9 and later). The digest
+ algorithm used to calculate fingerprints is selected by the
+ ssmmttpp__ttllss__ffiinnggeerrpprriinntt__ddiiggeesstt parameter. Multiple fingerprints can be
+ combined with a "|" delimiter in a single match attribute, or multiple
+ match attributes can be employed. The ":" character is not used as a
+ delimiter as it occurs between each pair of fingerprint (hexadecimal)
+ digits.
+vveerriiffyy
+ Mandatory server certificate verification. Mail is delivered only if the
+ TLS handshake succeeds, if the remote SMTP server certificate can be
+ validated (not expired or revoked, and signed by a trusted Certification
+ Authority), and if the server certificate name matches the optional "match"
+ attribute (or the main.cf smtp_tls_verify_cert_match parameter value when
+ no optional "match" attribute is specified). With Postfix >= 2.11 the
+ "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.
+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.
+Notes:
+
+ * The "match" attribute is especially useful to verify TLS certificates for
+ domains that are hosted on a shared server. In that case, specify "match"
+ rules for the shared server's name. While secure verification can also be
+ achieved with manual routing overrides in Postfix transport(5) tables, that
+ approach can deliver mail to the wrong host when domains are assigned to
+ new gateway hosts. The "match" attribute approach avoids the problems of
+ manual routing overrides; mail is deferred if verification of a new MX host
+ fails.
+
+ * When a policy table entry specifies multiple match patterns, multiple match
+ strategies, or multiple protocols, these must be separated by colons.
+
+ * The "exclude" attribute (Postfix >= 2.6) is used to disable ciphers that
+ cause handshake failures with a specific mandatory TLS destination, without
+ disabling the ciphers for all mandatory destinations. Alternatively, you
+ can exclude ciphers that cause issues with multiple remote servers in
+ main.cf, and selectively enable them on a per-destination basis in the
+ policy table by setting a shorter or empty exclusion list. The per-
+ destination "exclude" list preempts both the opportunistic and mandatory
+ security level exclusions, so that all excluded ciphers can be enabled for
+ known-good destinations. For non-mandatory TLS destinations that exhibit
+ cipher-specific problems, Postfix will fall back to plain-text delivery. If
+ plain-text is not acceptable make TLS mandatory and exclude the problem
+ ciphers.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+ # Postfix 2.5 and later
+ smtp_tls_fingerprint_digest = md5
+ /etc/postfix/tls_policy:
+ example.edu none
+ example.mil may
+ example.gov encrypt ciphers=high
+ example.com verify match=hostname:dot-nexthop ciphers=high
+ example.net secure
+ .example.net secure match=.example.net:example.net
+ [mail.example.org]:587 secure match=nexthop
+ # Postfix 2.5 and later
+ [thumb.example.org] fingerprint
+ match=EC:3B:2D:B0:5B:B1:FB:6D:20:A3:9D:72:F6:8D:12:35
+ match=3D:95:34:51:24:66:33:B9:D2:40:99:C0:C1:17:0B:D1
+ # Postfix 2.6 and later
+ example.info may protocols=!SSLv2 ciphers=medium
+ exclude=3DES
+
+NNoottee:: The "hostname" strategy if listed in a non-default setting of
+smtp_tls_secure_cert_match or in the "match" attribute in the policy table can
+render the "secure" level vulnerable to DNS forgery. Do not use the "hostname"
+strategy for secure-channel configurations in environments where DNS security
+is not assured.
+
+DDiissccoovveerriinngg sseerrvveerrss tthhaatt ssuuppppoorrtt TTLLSS
+
+As we decide on a "per site" basis whether or not to use TLS, it would be good
+to have a list of sites that offered "STARTTLS". We can collect it ourselves
+with this option.
+
+If the smtp_tls_note_starttls_offer feature is enabled and a server offers
+STARTTLS while TLS is not already enabled for that server, the Postfix SMTP
+client logs a line as follows:
+
+ postfix/smtp[pid]: Host offered STARTTLS: [hostname.example.com]
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_note_starttls_offer = yes
+
+SSeerrvveerr cceerrttiiffiiccaattee vveerriiffiiccaattiioonn ddeepptthh
+
+The server certificate verification depth is specified with the main.cf
+smtp_tls_scert_verifydepth parameter. The default verification depth is 9 (the
+OpenSSL default), for compatibility with Postfix versions before 2.5 where
+smtp_tls_scert_verifydepth was ignored. When you configure trust in a root CA,
+it is not necessary to explicitly trust intermediary CAs signed by the root CA,
+unless $smtp_tls_scert_verifydepth is less than the number of CAs in the
+certificate chain for the servers of interest. With a verify depth of 1 you can
+only verify certificates directly signed by a trusted CA, and all trusted
+intermediary CAs need to be configured explicitly. With a verify depth of 2 you
+can verify servers signed by a root CA or a direct intermediary CA (so long as
+the server is correctly configured to supply its intermediate CA certificate).
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_scert_verifydepth = 2
+
+CClliieenntt--ssiiddee cciipphheerr ccoonnttrroollss
+
+The Postfix SMTP client supports 5 distinct cipher grades as specified by the
+smtp_tls_mandatory_ciphers configuration parameter. This setting controls the
+minimum acceptable SMTP client TLS cipher grade for use with mandatory TLS
+encryption. The default value "medium" is suitable for most destinations with
+which you may want to enforce TLS, and is beyond the reach of today's
+cryptanalytic methods. See smtp_tls_policy_maps for information on how to
+configure ciphers on a per-destination basis.
+
+By default anonymous ciphers are allowed, and automatically disabled when
+remote SMTP server certificates are verified. If you want to disable anonymous
+ciphers even at the "encrypt" security level, set
+"smtp_tls_mandatory_exclude_ciphers = aNULL"; and to disable anonymous ciphers
+even with opportunistic TLS, set "smtp_tls_exclude_ciphers = aNULL". There is
+generally no need to take these measures. Anonymous ciphers save bandwidth and
+TLS session cache space, if certificates are ignored, there is little point in
+requesting them.
+
+The "smtp_tls_ciphers" configuration parameter (Postfix >= 2.6) provides
+control over the minimum cipher grade for opportunistic TLS. The default
+minimum cipher grade for opportunistic TLS is "medium" for Postfix releases
+after the middle of 2015, and "export" for older releases. With Postfix < 2.6,
+the minimum opportunistic TLS cipher grade is always "export".
+
+With mandatory and opportunistic TLS encryption, the Postfix SMTP client will
+by default disable SSLv2 and SSLv3. The mandatory TLS protocol list is
+specified via the smtp_tls_mandatory_protocols configuration parameter. The
+corresponding smtp_tls_protocols parameter (Postfix >= 2.6) controls the SSL/
+TLS protocols used with opportunistic TLS.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_tls_mandatory_ciphers = medium
+ smtp_tls_mandatory_exclude_ciphers = RC4, MD5
+ smtp_tls_exclude_ciphers = aNULL
+ # Preferred form with Postfix >= 2.5:
+ smtp_tls_mandatory_protocols = !SSLv2
+ # Legacy form for Postfix < 2.5:
+ smtp_tls_mandatory_protocols = SSLv3, TLSv1
+ # Also available with Postfix >= 2.6:
+ smtp_tls_ciphers = medium
+ smtp_tls_protocols = !SSLv2
+
+CClliieenntt--ssiiddee SSMMTTPPSS ssuuppppoorrtt
+
+These sections show how to send mail to a server that does not support
+STARTTLS, but that provides the deprecated SMTPS service on TCP port 465.
+Depending on the Postfix version, some additional tooling may be required.
+
+PPoossttffiixx >>== 33..00
+
+The Postfix SMTP client has SMTPS support built-in as of version 3.0. Use one
+of the following examples, to send all remote mail, or to send only some remote
+mail, to an SMTPS server.
+
+PPoossttffiixx >>== 33..00:: SSeennddiinngg aallll rreemmoottee mmaaiill ttoo aann SSMMTTPPSS sseerrvveerr
+
+The first example will send all remote mail over SMTPS through a provider's
+server called "mail.example.com":
+
+ /etc/postfix/main.cf:
+ # Client-side SMTPS requires "encrypt" or stronger.
+ smtp_tls_security_level = encrypt
+ smtp_tls_wrappermode = yes
+ # The [] suppress MX lookups.
+ relayhost = [mail.example.com]:465
+
+Use "postfix reload" to make the change effective.
+
+See SOHO_README for additional information about SASL authentication.
+
+PPoossttffiixx >>== 33..00:: SSeennddiinngg oonnllyy mmaaiill ffoorr aa ssppeecciiffiicc ddeessttiinnaattiioonn vviiaa SSMMTTPPSS
+
+The second example will send only mail for "example.com" via SMTPS. This time,
+Postfix uses a transport map to deliver only mail for "example.com" via SMTPS:
+
+ /etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+
+ /etc/postfix/transport:
+ example.com relay-smtps:example.com:465
+
+ /etc/postfix/master.cf:
+ relay-smtps unix - - n - - smtp
+ # Client-side SMTPS requires "encrypt" or stronger.
+ -o smtp_tls_security_level=encrypt
+ -o smtp_tls_wrappermode=yes
+
+Use "postmap hash:/etc/postfix/transport" and "postfix reload" to make the
+change effective.
+
+See SOHO_README for additional information about SASL authentication.
+
+PPoossttffiixx << 33..00
+
+Although older Postfix SMTP client versions do not support TLS wrapper mode, it
+is relatively easy to forward a connection through the stunnel program if
+Postfix needs to deliver mail to some legacy system that doesn't support
+STARTTLS.
+
+PPoossttffiixx << 33..00:: SSeennddiinngg aallll rreemmoottee mmaaiill ttoo aann SSMMTTPPSS sseerrvveerr
+
+The first example uses SMTPS to send all remote mail to a provider's mail
+server called "mail.example.com".
+
+A minimal stunnel.conf file is sufficient to set up a tunnel from local port
+11125 to the remote destination "mail.example.com" and port "smtps". Postfix
+will later use this tunnel to connect to the remote server.
+
+ /path/to/stunnel.conf:
+ [smtp-tls-wrapper]
+ accept = 11125
+ client = yes
+ connect = mail.example.com:smtps
+
+To test this tunnel, use:
+
+ $ telnet localhost 11125
+
+This should produce the greeting from the remote SMTP server at
+mail.example.com.
+
+On the Postfix side, the relayhost feature sends all remote mail through the
+local stunnel listener on port 11125:
+
+ /etc/postfix/main.cf:
+ relayhost = [127.0.0.1]:11125
+
+Use "postfix reload" to make the change effective.
+
+See SOHO_README for additional information about SASL authentication.
+
+PPoossttffiixx << 33..00:: SSeennddiinngg oonnllyy mmaaiill ffoorr aa ssppeecciiffiicc ddeessttiinnaattiioonn vviiaa SSMMTTPPSS
+
+The second example will use SMTPS to send only mail for "example.com" via
+SMTPS. It uses the same stunnel configuration file as the first example, so it
+won't be repeated here.
+
+This time, the Postfix side uses a transport map to direct only mail for
+"example.com" through the tunnel:
+
+ /etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+
+ /etc/postfix/transport:
+ example.com relay:[127.0.0.1]:11125
+
+Use "postmap hash:/etc/postfix/transport" and "postfix reload" to make the
+change effective.
+
+See SOHO_README for additional information about SASL authentication.
+
+MMiisscceellllaanneeoouuss cclliieenntt ccoonnttrroollss
+
+The smtp_starttls_timeout parameter limits the time of Postfix SMTP client
+write and read operations during TLS startup and shutdown handshake procedures.
+In case of problems the Postfix SMTP client tries the next network address on
+the mail exchanger list, and defers delivery if no alternative server is
+available.
+
+Example:
+
+ /etc/postfix/main.cf:
+ smtp_starttls_timeout = 300s
+
+With Postfix 2.8 and later, the tls_disable_workarounds parameter specifies a
+list or bit-mask of OpenSSL bug work-arounds to disable. This may be necessary
+if one of the work-arounds enabled by default in OpenSSL proves to pose a
+security risk, or introduces an unexpected interoperability issue. Some bug
+work-arounds known to be problematic are disabled in the default value of the
+parameter when linked with an OpenSSL library that could be vulnerable.
+
+Example:
+
+ /etc/postfix/main.cf:
+ tls_disable_workarounds = 0xFFFFFFFF
+ tls_disable_workarounds = CVE-2010-4180, LEGACY_SERVER_CONNECT
+
+Note: Disabling LEGACY_SERVER_CONNECT is not wise at this time, lots of servers
+are still unpatched and Postfix is not significantly vulnerable to the
+renegotiation issue in the TLS protocol.
+
+With Postfix >= 2.11, the tls_ssl_options parameter specifies a list or bit-
+mask of OpenSSL options to enable. Specify one or more of the named options
+below, or a hexadecimal bitmask of options found in the ssl.h file
+corresponding to the run-time OpenSSL library. While it may be reasonable to
+turn off all bug workarounds (see above), it is not a good idea to attempt to
+turn on all features.
+
+A future version of OpenSSL may by default no longer allow connections to
+servers that don't support secure renegotiation. Since the exposure for SMTP is
+minimal, and some SMTP servers may remain unpatched, you can add
+LEGACY_SERVER_CONNECT to the options to restore the more permissive default of
+current OpenSSL releases.
+
+Example:
+
+ /etc/postfix/main.cf:
+ tls_ssl_options = NO_TICKET, NO_COMPRESSION, LEGACY_SERVER_CONNECT
+
+You should only enable features via the hexadecimal mask when the need to
+control the feature is critical (to deal with a new vulnerability or a serious
+interoperability problem). Postfix DOES NOT promise backwards compatible
+behavior with respect to the mask bits. A feature enabled via the mask in one
+release may be enabled by other means in a later release, and the mask bit will
+then be ignored. Therefore, use of the hexadecimal mask is only a temporary
+measure until a new Postfix or OpenSSL release provides a better solution.
+
+TTLLSS mmaannaaggeerr ssppeecciiffiicc sseettttiinnggss
+
+The security of cryptographic software such as TLS depends critically on the
+ability to generate unpredictable numbers for keys and other information. To
+this end, the tlsmgr(8) process maintains a Pseudo Random Number Generator
+(PRNG) pool. This is queried by the smtp(8) and smtpd(8) processes when they
+initialize. By default, these daemons request 32 bytes, the equivalent to 256
+bits. This is more than sufficient to generate a 128bit (or 168bit) session
+key.
+
+Example:
+
+ /etc/postfix/main.cf:
+ tls_daemon_random_bytes = 32
+
+In order to feed its in-memory PRNG pool, the tlsmgr(8) reads entropy from an
+external source, both at startup and during run-time. Specify a good entropy
+source, like EGD or /dev/urandom; be sure to only use non-blocking sources (on
+OpenBSD, use /dev/arandom when tlsmgr(8) complains about /dev/urandom timeout
+errors). If the entropy source is not a regular file, you must prepend the
+source type to the source name: "dev:" for a device special file, or "egd:" for
+a source with EGD compatible socket interface.
+
+Examples (specify only one in main.cf):
+
+ /etc/postfix/main.cf:
+ tls_random_source = dev:/dev/urandom
+ tls_random_source = egd:/var/run/egd-pool
+
+By default, tlsmgr(8) reads 32 bytes from the external entropy source at each
+seeding event. This amount (256bits) is more than sufficient for generating a
+128bit symmetric key. With EGD and device entropy sources, the tlsmgr(8) limits
+the amount of data read at each step to 255 bytes. If you specify a regular
+file as entropy source, a larger amount of data can be read.
+
+Example:
+
+ /etc/postfix/main.cf:
+ tls_random_bytes = 32
+
+In order to update its in-memory PRNG pool, the tlsmgr(8) queries the external
+entropy source again after a pseudo-random amount of time. The time is
+calculated using the PRNG, and is between 0 and the maximal time specified with
+tls_random_reseed_period. The default maximal time interval is 1 hour.
+
+Example:
+
+ /etc/postfix/main.cf:
+ tls_random_reseed_period = 3600s
+
+The tlsmgr(8) process saves the PRNG state to a persistent exchange file at
+regular times and when the process terminates, so that it can recover the PRNG
+state the next time it starts up. This file is created when it does not exist.
+
+Examples:
+
+ /etc/postfix/main.cf:
+ tls_random_exchange_name = /var/lib/postfix/prng_exch
+ tls_random_prng_update_period = 3600s
+
+As of version 2.5, Postfix no longer uses root privileges when opening this
+file. The file should now be stored under the Postfix-owned data_directory. As
+a migration aid, an attempt to open the file under a non-Postfix directory is
+redirected to the Postfix-owned data_directory, and a warning is logged. If you
+wish to continue using a pre-existing PRNG state file, move it to the
+data_directory and change the ownership to the account specified with the
+mail_owner parameter.
+
+With earlier Postfix versions the default file location is under the Postfix
+configuration directory, which is not the proper place for information that is
+modified by Postfix.
+
+GGeettttiinngg ssttaarrtteedd,, qquuiicckk aanndd ddiirrttyy
+
+The following steps will get you started quickly. Because you sign your own
+Postfix public key certificate, you get TLS encryption but no TLS
+authentication. This is sufficient for testing, and for exchanging email with
+sites that you have no trust relationship with. For real authentication, your
+Postfix public key certificate needs to be signed by a recognized Certification
+Authority, and Postfix needs to be configured with a list of public key
+certificates of Certification Authorities, so that Postfix can verify the
+public key certificates of remote hosts.
+
+In the examples below, user input is shown in bboolldd font, and a "#" prompt
+indicates a super-user shell.
+
+ * Self-signed server certificate.
+
+ * Private Certification Authority.
+
+SSeellff--ssiiggnneedd sseerrvveerr cceerrttiiffiiccaattee
+
+The following commands (credits: Viktor Dukhovni) generate and install a 2048-
+bit RSA private key and 10-year self-signed certificate for the local Postfix
+system. This requires super-user privileges.
+
+ # dir="$(postconf -h config_directory)"
+ # fqdn=$(postconf -h myhostname)
+ # case $fqdn in /*) fqdn=$(cat "$fqdn");; esac
+ # ymd=$(date +%Y-%m-%d)
+ # key="${dir}/key-${ymd}.pem"; rm -f "${key}"
+ # cert="${dir}/cert-${ymd}.pem"; rm -f "${cert}"
+ # (umask 077; openssl genrsa -out "${key}" 2048) &&
+ openssl req -new -key "${key}" \
+ -x509 -subj "/CN=${fqdn}" -days 3650 -out "${cert}" &&
+ postconf -e \
+ "smtpd_tls_cert_file = ${cert}" \
+ "smtpd_tls_key_file = ${key}" \
+ 'smtpd_tls_security_level = may' \
+ 'smtpd_tls_received_header = yes' \
+ 'smtpd_tls_loglevel = 1' \
+ 'smtp_tls_security_level = may' \
+ 'smtp_tls_loglevel = 1' \
+ 'smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache'
+ \
+ 'tls_random_source = dev:/dev/urandom'
+
+Note: the last command requires both single (') and double (") quotes.
+
+The postconf(1) command above enables opportunistic TLS for receiving and
+sending mail. It also enables logging of TLS connections and recording of TLS
+use in the "Received" header. TLS session caching is also enabled in the
+Postfix SMTP client. With Postfix >= 2.10, the SMTP server does not need an
+explicit session cache since session reuse is better handled via RFC 5077 TLS
+session tickets.
+
+PPrriivvaattee CCeerrttiiffiiccaattiioonn AAuutthhoorriittyy
+
+ * Become your own Certification Authority, so that you can sign your own
+ certificates, and so that your own systems can authenticate certificates
+ from your own CA. This example uses the CA.pl script that ships with
+ OpenSSL. On some systems, OpenSSL installs this as /usr/local/openssl/misc/
+ CA.pl. Some systems install this as part of a package named openssl-perl or
+ something similar. The script creates a private key in ./demoCA/private/
+ cakey.pem and a public key in ./demoCA/cacert.pem.
+
+ % //uussrr//llooccaall//ssssll//mmiisscc//CCAA..ppll --nneewwccaa
+ CA certificate filename (or enter to create)
+
+ Making CA certificate ...
+ Using configuration from /etc/ssl/openssl.cnf
+ Generating a 1024 bit RSA private key
+ ....................++++++
+ .....++++++
+ writing new private key to './demoCA/private/cakey.pem'
+ Enter PEM pass phrase:wwhhaatteevveerr
+
+ * Create an unpassworded private key for host foo.porcupine.org and create an
+ unsigned public key certificate.
+
+ % ((uummaasskk 007777;; ooppeennssssll rreeqq --nneeww --nneewwkkeeyy rrssaa::22004488 --nnooddeess --kkeeyyoouutt ffoooo--
+ kkeeyy..ppeemm --oouutt ffoooo--rreeqq..ppeemm))
+ Using configuration from /etc/ssl/openssl.cnf
+ Generating a 2048 bit RSA private key
+ ........................................++++++
+ ....++++++
+ writing new private key to 'foo-key.pem'
+ -----
+ You are about to be asked to enter information that will be
+ incorporated
+ into your certificate request.
+ What you are about to enter is what is called a Distinguished Name or a
+ DN.
+ There are quite a few fields but you can leave some blank
+ For some fields there will be a default value,
+ If you enter '.', the field will be left blank.
+ -----
+ Country Name (2 letter code) [AU]:UUSS
+ State or Province Name (full name) [Some-State]:NNeeww YYoorrkk
+ Locality Name (eg, city) []:WWeessttcchheesstteerr
+ Organization Name (eg, company) [Internet Widgits Pty Ltd]:PPoorrccuuppiinnee
+ Organizational Unit Name (eg, section) []:
+ Common Name (eg, YOUR name) []:ffoooo..ppoorrccuuppiinnee..oorrgg
+ Email Address []:wwiieettssee@@ppoorrccuuppiinnee..oorrgg
+
+ Please enter the following 'extra' attributes
+ to be sent with your certificate request
+ A challenge password []:wwhhaatteevveerr
+ An optional company name []:
+
+ * Sign the public key certificate for host foo.porcupine.org with the
+ Certification Authority private key that we created a few steps ago.
+
+ % ooppeennssssll ccaa --oouutt ffoooo--cceerrtt..ppeemm --ddaayyss 336655 --iinnffiilleess ffoooo--rreeqq..ppeemm
+ Using configuration from /etc/ssl/openssl.cnf
+ Enter PEM pass phrase:wwhhaatteevveerr
+ Check that the request matches the signature
+ Signature ok
+ The Subjects Distinguished Name is as follows
+ countryName :PRINTABLE:'US'
+ stateOrProvinceName :PRINTABLE:'New York'
+ localityName :PRINTABLE:'Westchester'
+ organizationName :PRINTABLE:'Porcupine'
+ commonName :PRINTABLE:'foo.porcupine.org'
+ emailAddress :IA5STRING:'wietse@porcupine.org'
+ Certificate is to be certified until Nov 21 19:40:56 2005 GMT (365
+ days)
+ Sign the certificate? [y/n]:yy
+
+ 1 out of 1 certificate requests certified, commit? [y/n]yy
+ Write out database with 1 new entries
+ Data Base Updated
+
+ * Install the host private key, the host public key certificate, and the
+ Certification Authority certificate files. This requires super-user
+ privileges.
+
+ The following commands assume that the key and certificate will be
+ installed for the local Postfix MTA. You will need to adjust the commands
+ if the Postfix MTA is on a different host.
+
+ # ccpp ddeemmooCCAA//ccaacceerrtt..ppeemm ffoooo--kkeeyy..ppeemm ffoooo--cceerrtt..ppeemm //eettcc//ppoossttffiixx
+ # cchhmmoodd 664444 //eettcc//ppoossttffiixx//ffoooo--cceerrtt..ppeemm //eettcc//ppoossttffiixx//ccaacceerrtt..ppeemm
+ # cchhmmoodd 440000 //eettcc//ppoossttffiixx//ffoooo--kkeeyy..ppeemm
+
+ * Configure Postfix, by adding the following to /etc/postfix/main.cf. It is
+ generally best to not configure client certificates, unless there are
+ servers which authenticate your mail submission via client certificates.
+ 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.
+
+ /etc/postfix/main.cf:
+ smtp_tls_CAfile = /etc/postfix/cacert.pem
+ smtp_tls_session_cache_database =
+ btree:/var/lib/postfix/smtp_tls_session_cache
+ smtp_tls_security_level = may
+ smtp_tls_loglevel = 1
+ smtpd_tls_CAfile = /etc/postfix/cacert.pem
+ smtpd_tls_cert_file = /etc/postfix/foo-cert.pem
+ smtpd_tls_key_file = /etc/postfix/foo-key.pem
+ smtpd_tls_received_header = yes
+ smtpd_tls_session_cache_database =
+ btree:/var/lib/postfix/smtpd_tls_session_cache
+ tls_random_source = dev:/dev/urandom
+ smtpd_tls_security_level = may
+ smtpd_tls_loglevel = 1
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh TTLLSS ssuuppppoorrtt
+
+These instructions assume that you build Postfix from source code as described
+in the INSTALL document. Some modification may be required if you build Postfix
+from a vendor-specific source package.
+
+To build Postfix with TLS support, first we need to generate the make(1) files
+with the necessary definitions. This is done by invoking the command "make
+makefiles" in the Postfix top-level directory and with arguments as shown next.
+
+NNOOTTEE:: DDoo nnoott uussee GGnnuu TTLLSS.. IItt wwiillll ssppoonnttaanneeoouussllyy tteerrmmiinnaattee aa PPoossttffiixx ddaaeemmoonn
+pprroocceessss wwiitthh eexxiitt ssttaattuuss ccooddee 22,, iinnsstteeaadd ooff aalllloowwiinngg PPoossttffiixx ttoo 11)) rreeppoorrtt tthhee
+eerrrroorr ttoo tthhee mmaaiilllloogg ffiillee,, aanndd ttoo 22)) pprroovviiddee ppllaaiinntteexxtt sseerrvviiccee wwhheerree tthhiiss iiss
+aapppprroopprriiaattee..
+
+ * If the OpenSSL include files (such as ssl.h) are in directory /usr/include/
+ openssl, and the OpenSSL libraries (such as libssl.so and libcrypto.so) are
+ in directory /usr/lib:
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__TTLLSS"" AAUUXXLLIIBBSS==""--llssssll --llccrryyppttoo""
+
+ * If the OpenSSL include files (such as ssl.h) are in directory /usr/local/
+ include/openssl, and the OpenSSL libraries (such as libssl.so and
+ libcrypto.so) are in directory /usr/local/lib:
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__TTLLSS --II//uussrr//llooccaall//iinncclluuddee"" \\
+ AAUUXXLLIIBBSS==""--LL//uussrr//llooccaall//lliibb --llssssll --llccrryyppttoo""
+
+ On Solaris, specify the -R option as shown below:
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__TTLLSS --II//uussrr//llooccaall//iinncclluuddee"" \\
+ AAUUXXLLIIBBSS==""--RR//uussrr//llooccaall//lliibb --LL//uussrr//llooccaall//lliibb --llssssll --llccrryyppttoo""
+
+If you need to apply other customizations (such as Berkeley DB databases,
+MySQL, PostgreSQL, LDAP or SASL), see the respective Postfix README documents,
+and combine their "make makefiles" instructions with the instructions above:
+
+ % mmaakkee ttiiddyy # if you have left-over files from a previous build
+ % mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDUUSSEE__TTLLSS \\
+ ((ootthheerr --DD oorr --II ooppttiioonnss))"" \\
+ AAUUXXLLIIBBSS==""--llssssll --llccrryyppttoo \\
+ ((ootthheerr --ll ooppttiioonnss ffoorr lliibbrraarriieess iinn //uussrr//lliibb)) \\
+ ((--LL//ppaatthh//nnaammee ++ --ll ooppttiioonnss ffoorr ootthheerr lliibbrraarriieess))""
+
+To complete the build process, see the Postfix INSTALL instructions. Postfix
+has TLS support turned off by default, so you can start using Postfix as soon
+as it is installed.
+
+RReeppoorrttiinngg pprroobblleemmss
+
+Problems are preferably reported via . See http://
+www.postfix.org/lists.html for subscription information. When reporting a
+problem, please be thorough in the report. Patches, when possible, are greatly
+appreciated too.
+
+CCrreeddiittss
+
+ * TLS support for Postfix was originally developed by Lutz Jänicke at Cottbus
+ Technical University.
+ * Wietse Venema adopted the code, did some restructuring, and compiled this
+ part of the documentation from Lutz's documents.
+ * Victor Duchovni was instrumental with the re-implementation of the
+ smtp_tls_per_site code in terms of enforcement levels, which simplified the
+ implementation greatly.
+ * Victor Duchovni implemented the fingerprint security level, added more
+ sanity checks, and separated TLS connection management from security policy
+ enforcement. The latter change simplified the code that verifies
+ certificate signatures, certificate names, and certificate fingerprints.
+
diff --git a/README_FILES/TUNING_README b/README_FILES/TUNING_README
new file mode 100644
index 0000000..b7a3f3a
--- /dev/null
+++ b/README_FILES/TUNING_README
@@ -0,0 +1,491 @@
+ PPoossttffiixx PPeerrffoorrmmaannccee TTuunniinngg
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff PPoossttffiixx ppeerrffoorrmmaannccee ttuunniinngg
+
+The hints and tips in this document help you improve the performance of Postfix
+systems that already work. If your Postfix system is unable to receive or
+deliver mail, then you need to solve those problems first, using the
+DEBUG_README document as guidance.
+
+For tuning external content filter performance, first read the respective
+information in the FILTER_README and SMTPD_PROXY_README documents. Then make
+sure to avoid latency in the content filter code. As much as possible avoid
+performing queries against external data sources with a high or highly variable
+delay. Your content filter will run with a small concurrency to avoid CPU/
+memory starvation, and if any latency creeps in, content filter throughput will
+suffer. High volume environments should avoid RBL lookups, complex database
+queries and so on.
+
+Topics on mail receiving performance:
+
+ * General mail receiving performance tips
+ * Doing more work with your SMTP server processes
+ * Slowing down SMTP clients that make many errors
+ * Measures against clients that make too many connections
+
+Topics on mail delivery performance:
+
+ * General mail delivery performance tips
+ * Tuning the frequency of deferred mail delivery attempts
+ * Tuning the number of simultaneous deliveries
+ * Tuning the number of recipients per delivery
+
+Other Postfix performance tuning topics:
+
+ * Tuning the number of Postfix processes
+ * Tuning the number of processes on the system
+ * Tuning the number of open files or sockets
+
+The following tools can be used to measure mail system performance under
+artificial loads. They are normally not installed with Postfix.
+
+ * smtp-source, SMTP/LMTP message generator
+ * smtp-sink, SMTP/LMTP message dump
+ * qmqp-source, QMQP message generator
+ * qmqp-sink, QMQP message dump
+
+GGeenneerraall mmaaiill rreecceeiivviinngg ppeerrffoorrmmaannccee ttiippss
+
+ * Read and understand the maildrop queue, incoming queue, and active queue
+ discussions in the QSHAPE_README document.
+
+ * Run a local name server to reduce slow-down due to DNS lookups. If you run
+ multiple Postfix systems, point each local name server to a shared
+ forwarding server to reduce the number of lookups across the upstream
+ network link.
+
+ * Eliminate unnecessary LDAP lookups, by specifying a domain filter. This
+ eliminates lookups for addresses in remote domains, and eliminates lookups
+ of partial addresses. See ldap_table(5) for details.
+
+When Postfix responds slowly to SMTP clients:
+
+ * Look for obvious signs of trouble as described in the DEBUG_README
+ document, and eliminate those problems first.
+
+ * Turn off your header_checks and body_checks patterns and see if the problem
+ goes away.
+
+ * Turn off chroot operation as described in the DEBUG_README document and see
+ if the problem goes away.
+
+ * If Postfix logs the SMTP client as "unknown" then you have a name service
+ problem: the name server is bad, or the resolv.conf file contains bad
+ information, or some packet filter is blocking the DNS requests or replies.
+
+ * If the number of smtpd(8) processes has reached the process limit as
+ specified in master.cf, new SMTP clients must wait until a process becomes
+ available. See the STRESS_README and POSTSCREEN_README documents for
+ measures that help to prevent SMTP server overload.
+
+DDooiinngg mmoorree wwoorrkk wwiitthh yyoouurr SSMMTTPP sseerrvveerr pprroocceesssseess
+
+With Postfix versions 2.0 and earlier, the smtpd(8) server pauses before
+reporting an error to an SMTP client. The idea is called tar pitting. However,
+these delays also slow down Postfix. When the smtpd(8) server replies slowly,
+sessions take more time, so that more smtpd(8) server processes are needed to
+handle the load. When your Postfix smtpd(8) server process limit is reached,
+new clients must wait until a server process becomes available. This means that
+all clients experience poor performance.
+
+You can speed up the handling of smtpd(8) server error replies by turning off
+the delay:
+
+ /etc/postfix/main.cf:
+ # Not needed with Postfix 2.1
+ smtpd_error_sleep_time = 0
+
+With the above setting, Postfix 2.0 and earlier can serve more SMTP clients
+with the same number SMTP server processes. The next section describes how
+Postfix deals with clients that make a large number of errors.
+
+SSlloowwiinngg ddoowwnn SSMMTTPP cclliieennttss tthhaatt mmaakkee mmaannyy eerrrroorrss
+
+The Postfix smtpd(8) server maintains a per-session error count. The error
+count is reset when a message is transferred successfully, and is incremented
+when a client request is unrecognized or unimplemented, when a client request
+violates access restrictions, or when some other error happens.
+
+As the per-session error count increases, the smtpd(8) server changes behavior
+and begins to insert delays into the responses. The idea is to slow down a run-
+away client in order to limit resource usage. The behavior is Postfix version
+dependent.
+
+IMPORTANT: These delays slow down Postfix, too. When too much delay is
+configured, the number of simultaneous SMTP sessions will increase until it
+reaches the smtpd(8) server process limit, and new SMTP clients must wait until
+an smtpd(8) server process becomes available.
+
+Postfix version 2.1 and later:
+
+ * When the error count reaches $smtpd_soft_error_limit (default: 10), the
+ Postfix smtpd(8) server delays all non-error and error responses by
+ $smtpd_error_sleep_time seconds (default: 1 second).
+
+ * When the error count reaches $smtpd_hard_error_limit (default: 20) the
+ Postfix smtpd(8) server breaks the connection.
+
+Postfix version 2.0 and earlier:
+
+ * When the error count is less than $smtpd_soft_error_limit (default: 10) the
+ Postfix smtpd(8) server delays all error replies by $smtpd_error_sleep_time
+ (1 second with Postfix 2.0, 5 seconds with Postfix 1.1 and earlier).
+
+ * When the error count reaches $smtpd_soft_error_limit, the Postfix smtpd(8)
+ server delays all responses by "error count" seconds or
+ $smtpd_error_sleep_time, whichever is more.
+
+ * When the error count reaches $smtpd_hard_error_limit (default: 20) the
+ Postfix smtpd(8) server breaks the connection.
+
+MMeeaassuurreess aaggaaiinnsstt cclliieennttss tthhaatt mmaakkee ttoooo mmaannyy ccoonnnneeccttiioonnss
+
+Note: these features use the Postfix anvil(8) service, introduced with Postfix
+version 2.2.
+
+The Postfix smtpd(8) server can limit the number of simultaneous connections
+from the same SMTP client, as well as the connection rate and the rate of
+certain SMTP commands from the same client. These statistics are maintained by
+the anvil(8) server (translation: if anvil(8) breaks, then connection limits
+stop working).
+
+IMPORTANT: These limits must not be used to regulate legitimate traffic: mail
+will suffer grotesque delays if you do so. The limits are designed to protect
+the smtpd(8) server against abuse by out-of-control clients.
+
+ smtpd_client_connection_count_limit (default: 50)
+ The maximum number of connections that an SMTP client may make
+ simultaneously.
+ smtpd_client_connection_rate_limit (default: no limit)
+ The maximum number of connections that an SMTP client may make in the
+ time interval specified with anvil_rate_time_unit (default: 60s).
+ smtpd_client_message_rate_limit (default: no limit)
+ The maximum number of message delivery requests that an SMTP client may
+ make in the time interval specified with anvil_rate_time_unit (default:
+ 60s).
+ smtpd_client_recipient_rate_limit (default: no limit)
+ The maximum number of recipient addresses that an SMTP client may
+ specify in the time interval specified with anvil_rate_time_unit
+ (default: 60s).
+ smtpd_client_new_tls_session_rate_limit (default: no limit)
+ The maximum number of new TLS sessions (without using the TLS session
+ cache) that an SMTP client may negotiate in the time interval specified
+ with anvil_rate_time_unit (default: 60s).
+ smtpd_client_event_limit_exceptions (default: $mynetworks)
+ SMTP clients that are excluded from connection and rate limits
+ specified above.
+
+GGeenneerraall mmaaiill ddeelliivveerryy ppeerrffoorrmmaannccee ttiippss
+
+ * Read and understand the maildrop queue, incoming queue, active queue and
+ deferred queue discussions in the QSHAPE_README document.
+
+ * In case of slow delivery, run the qshape tool as described in the
+ QSHAPE_README document.
+
+ * Submit multiple recipients per message instead of submitting messages with
+ only a few recipients.
+
+ * Submit mail via SMTP instead of /usr/sbin/sendmail. You may have to adjust
+ the smtpd_recipient_limit parameter setting.
+
+ * Don't overwhelm the disk with mail submissions. Optimize the mail
+ submission rate by tuning the number of parallel submissions and/or by
+ tuning the Postfix in_flow_delay parameter setting.
+
+ * Run a local name server to reduce slow-down due to DNS lookups. If you run
+ multiple Postfix systems, point each local name server to a shared
+ forwarding server to reduce the number of lookups across the upstream
+ network link.
+
+ * Reduce the smtp_connect_timeout and smtp_helo_timeout values so that
+ Postfix does not waste lots of time connecting to non-responding remote
+ SMTP servers.
+
+ * Use a dedicated mail delivery transport for problematic destinations, with
+ reduced timeouts and with adjusted concurrency. See "Tuning the number of
+ simultaneous deliveries" below.
+
+ * Use a fallback_relay host for mail that cannot be delivered upon the first
+ attempt. This "graveyard" machine can use shorter retry times for difficult
+ to reach destinations. See "Tuning the frequency of deferred mail delivery
+ attempts" below.
+
+ * Speed up disk updates with a large (64MB) persistent write cache. This
+ allows disk updates to be sorted for optimal access speed without
+ compromising file system integrity when the system crashes.
+
+ * Use a solid-state disk (a persistent RAM disk). This is an expensive
+ solution that should be used in combination with short SMTP timeouts and a
+ fallback_relay "graveyard" machine that delivers mail for problem
+ destinations.
+
+TTuunniinngg tthhee nnuummbbeerr ooff ssiimmuullttaanneeoouuss ddeelliivveerriieess
+
+Although Postfix can be configured to run 1000 SMTP client processes at the
+same time, it is rarely desirable that it makes 1000 simultaneous connections
+to the same remote system. For this reason, Postfix has safety mechanisms in
+place to avoid this so-called "thundering herd" problem.
+
+The Postfix queue manager implements the analog of the TCP slow start flow
+control strategy: when delivering to a site, send a small number of messages
+first, then increase the concurrency as long as all goes well; reduce
+concurrency in the face of congestion.
+
+ * The initial_destination_concurrency parameter (default: 5) controls how
+ many messages are initially sent to the same destination before adapting
+ delivery concurrency. Of course, this setting is effective only as long as
+ it does not exceed the process limit and the destination concurrency limit
+ for the specific mail transport channel.
+
+ * The default_destination_concurrency_limit parameter (default: 20) controls
+ how many messages may be sent to the same destination simultaneously. You
+ can override this setting for specific message delivery transports by
+ taking the name of the master.cf entry and appending
+ "_destination_concurrency_limit".
+
+Examples of transport specific concurrency limits are:
+
+ * The local_destination_concurrency_limit parameter (default: 2) controls how
+ many messages are delivered simultaneously to the same local recipient. The
+ recommended limit is low because delivery to the same mailbox must happen
+ sequentially, so massive parallelism is not useful. Another good reason to
+ limit delivery concurrency to the same recipient: if the recipient has an
+ expensive shell command in her .forward file, or if the recipient is a
+ mailing list manager, you don't want to run too many instances of those
+ processes at the same time.
+
+ * The default smtp_destination_concurrency_limit of 20 seems enough to
+ noticeably load a system without bringing it to its knees. Be careful when
+ changing this to a much larger number.
+
+The above default values of the concurrency limits work well in a broad range
+of situations. Knee-jerk changes to these parameters in the face of congestion
+can actually make problems worse. Specifically, large destination concurrencies
+should never be the default. They should be used only for transports that
+deliver mail to a small number of high volume domains.
+
+A common situation where high concurrency is called for is on gateways relaying
+a high volume of mail between the Internet and an intranet mail environment.
+Approximately half the mail (assuming equal volumes inbound and outbound) will
+be destined for the internal mail hubs. Since the internal mail hubs will be
+receiving all external mail exclusively from the gateway, it is reasonable to
+configure the gateway to make greater demands on the capacity of the internal
+SMTP servers.
+
+The tuning of the inbound concurrency limits need not be trial and error. A
+high volume capable mailhub should be able to easily handle 50 or 100 (rather
+than the default 20) simultaneous connections, especially if the gateway
+forwards to multiple MX hosts. When all MX hosts are up and accepting
+connections in a timely fashion, throughput will be high. If any MX host is
+down and completely unresponsive, the average connection latency rises to at
+least 1/N * $smtp_connection_timeout, if there are N MX hosts. This limits
+throughput to at most the destination concurrency * N /
+$smtp_connection_timeout.
+
+For example, with a destination concurrency of 100 and 2 MX hosts, each host
+will handle up to 50 simultaneous connections. If one MX host is down and the
+default SMTP connection timeout is 30s, the throughput limit is 100 * 2 / 30 ~=
+6 messages per second. This suggests that high volume destinations with good
+connectivity and multiple MX hosts need a lower connection timeout, values as
+low as 5s or even 1s can be used to prevent congestion when one or more, but
+not all MX hosts are down.
+
+If necessary, set a higher transport_destination_concurrency_limit (in main.cf
+since this is a queue manager parameter) and a lower smtp_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.
+
+TTuunniinngg tthhee nnuummbbeerr ooff rreecciippiieennttss ppeerr ddeelliivveerryy
+
+The default_destination_recipient_limit parameter (default: 50) controls how
+many recipients a Postfix delivery agent will send with each copy of an email
+message. You can override this setting for specific Postfix delivery agents.
+For example, "uucp_destination_recipient_limit = 100" would limit the number of
+recipients per UUCP delivery to 100.
+
+If an email message exceeds the recipient limit for some destination, the
+Postfix queue manager breaks up the list of recipients into smaller lists.
+Postfix will attempt to send multiple copies of the message in parallel.
+
+IMPORTANT: Be careful when increasing the recipient limit per message delivery;
+some SMTP servers abort the connection when they run out of memory or when a
+hard recipient limit is reached, so that the message will never be delivered.
+
+The smtpd_recipient_limit parameter (default: 1000) controls how many
+recipients the Postfix smtpd(8) server will take per delivery. The default
+limit is more than any reasonable SMTP client would send. The limit exists to
+protect the local mail system against a run-away client.
+
+TTuunniinngg tthhee ffrreeqquueennccyy ooff ddeeffeerrrreedd mmaaiill ddeelliivveerryy aatttteemmppttss
+
+When a Postfix delivery agent (smtp(8), local(8), etc.) is unable to deliver a
+message it may blame the message itself, or it may blame the receiving party.
+
+ * When the delivery agent blames the message, the queue manager gives the
+ queue file a time stamp into the future, so it won't be looked at for a
+ while. By default, the amount of time to cool down is the amount of time
+ that has passed since the message arrived. This results in so-called
+ exponential backoff behavior.
+
+ * When the delivery agent blames the receiving party (for example a local
+ recipient user, or a remote host), the queue manager not only advances the
+ queue file time stamp, but also puts the receiving party on a "dead" list
+ so that it will be skipped for some amount of time.
+
+This process is governed by a bunch of little parameters.
+
+ queue_run_delay (default: 300 seconds; before Postfix 2.4: 1000s)
+ How often the queue manager scans the queue for deferred mail.
+ minimal_backoff_time (default: 300 seconds; before Postfix 2.4: 1000s)
+ The minimal amount of time a message won't be looked at, and the
+ minimal amount of time to stay away from a "dead" destination.
+ maximal_backoff_time (default: 4000 seconds)
+ The maximal amount of time a message won't be looked at after a
+ delivery failure.
+ maximal_queue_lifetime (default: 5 days)
+ How long a message stays in the queue before it is sent back as
+ undeliverable. Specify 0 for mail that should be returned immediately
+ after the first unsuccessful delivery attempt.
+ bounce_queue_lifetime (default: 5 days, available with Postfix version 2.1
+ and later)
+ How long a MAILER-DAEMON message stays in the queue before it is
+ considered undeliverable. Specify 0 for mail that should be tried only
+ once.
+ qmgr_message_recipient_limit (default: 20000)
+ The size of many in-memory queue manager data structures. Among others,
+ this parameter limits the size of the short-term, in-memory list of
+ "dead" destinations. Destinations that don't fit the list are not
+ added.
+ transport_destination_concurrency_failed_cohort_limit
+ Controls when a destination is considered "dead". This parameter is
+ critical with a non-zero transport_destination_rate_delay, with a
+ reduced transport_destination_concurrency_limit, or with a reduced
+ initial_destination_concurrency.
+
+IMPORTANT: If you increase the frequency of deferred mail delivery attempts, or
+if you flush the deferred mail queue frequently, then you may find that Postfix
+mail delivery performance actually becomes worse. The symptoms are as follows:
+
+ * The active queue becomes saturated with mail that has delivery problems.
+ New mail enters the active queue only when an old message is deferred. This
+ is a slow process that usually requires timing out one or more SMTP
+ connections.
+
+ * All available Postfix delivery agents become occupied trying to connect to
+ unreachable sites etc. New mail has to wait until a delivery agent becomes
+ available. This is a slow process that usually requires timing out one or
+ more SMTP connections.
+
+When mail is being deferred frequently, fixing the problem is always better
+than increasing the frequency of delivery attempts. However, if you can control
+only the delivery attempt frequency, consider using a dedicated fallback_relay
+"graveyard" machine for bad destinations, so that these destinations do not
+ruin the performance of normal mail deliveries.
+
+TTuunniinngg tthhee nnuummbbeerr ooff PPoossttffiixx pprroocceesssseess
+
+The default_process_limit configuration parameter gives direct control over how
+many daemon processes Postfix will run. As of Postfix 2.0 the default limit is
+100 SMTP client processes, 100 SMTP server processes, and so on. This may
+overwhelm systems with little memory, as well as networks with low bandwidth.
+
+You can change the global process limit by specifying a non-default
+default_process_limit in the main.cf file. For example, to run up to 10 SMTP
+client processes, 10 SMTP server processes, and so on:
+
+ /etc/postfix/main.cf:
+ default_process_limit = 10
+
+You need to execute "postfix reload" to make the change effective. This limit
+is enforced by the Postfix master(8) daemon which does not automatically read
+main.cf when it changes.
+
+You can override the process limit for specific Postfix daemons by editing the
+master.cf file. For example, if you do not wish to receive 100 SMTP messages at
+the same time, but do not want to change the process limits for other Postfix
+daemons, you could specify:
+
+ /etc/postfix/master.cf:
+ # ====================================================================
+ # service type private unpriv chroot wakeup maxproc command + args
+ # (yes) (yes) (yes) (never) (100)
+ # ====================================================================
+ . . .
+ smtp inet n - - - 10 smtpd
+ . . .
+
+TTuunniinngg tthhee nnuummbbeerr ooff pprroocceesssseess oonn tthhee ssyysstteemm
+
+ * MacOS X will run out of process slots when you increase Postfix process
+ limits. The following works with OSX 10.4 and OSX 10.5.
+
+ MacOS X kernel parameters can be specified in /etc/sysctl.conf.
+
+ /etc/sysctl.conf:
+ kern.maxproc=2048
+ kern.maxprocperuid=2048
+
+ Unfortunately these can't simply be set on the fly with "sysctl -w". You
+ also have to set the following in /etc/launchd.conf so that the root user
+ after boot will have the right process limit (2048). Otherwise you have to
+ always run ulimit -u 2048 as root, then start a user shell, and then start
+ processes for things to take effect.
+
+ /etc/launchd.conf:
+ limit maxproc 2048
+
+ Once these are in place, reboot the system. After that, the limits will
+ stay in place.
+
+TTuunniinngg tthhee nnuummbbeerr ooff ooppeenn ffiilleess oorr ssoocckkeettss
+
+When Postfix opens too many files or sockets, processes will abort with fatal
+errors, and the system may log "file table full" errors.
+
+ * Depending on your Postfix and operating system versions you may need to
+ recompile Postfix if you need more than 1024 file descriptors per process:
+
+ o No recompilation is needed for Postfix version 2.4 and later, when it
+ was compiled for systems that support BSD kqueue(2) (FreeBSD 4.1,
+ NetBSD 2.0, OpenBSD 2.9), Solaris 8 /dev/poll, or Linux 2.6 epoll(4).
+
+ o Otherwise, Postfix needs to be recompiled to override the default
+ FD_SETSIZE value.
+
+ * Reduce the number of processes as described under "Tuning the number of
+ Postfix processes" above. Fewer processes need fewer open files and
+ sockets.
+
+ * Configure the kernel for more open files and sockets. The details are
+ extremely system dependent and change with the operating system version. Be
+ sure to verify the following information with your system tuning guide:
+
+ o Some FreeBSD kernel parameters can be specified in /boot/loader.conf,
+ and some can be specified in /etc/sysctl.conf or changed with sysctl
+ commands. Which is which depends on the version.
+
+ kern.ipc.maxsockets="5000"
+ kern.ipc.nmbclusters="65536"
+ kern.maxproc="2048"
+ kern.maxfiles="16384"
+ kern.maxfilesperproc="16384"
+
+ o Linux kernel parameters can be specified in /etc/sysctl.conf or changed
+ with sysctl commands:
+
+ fs.file-max=16384
+ kernel.threads-max=2048
+
+ o Solaris kernel parameters can be specified in /etc/system, as described
+ in the Solaris FAQ entry titled "How can I increase the number of file
+ descriptors per process?"
+
+ * set hard limit on file descriptors
+ set rlim_fd_max = 4096
+ * set soft limit on file descriptors
+ set rlim_fd_cur = 1024
+
diff --git a/README_FILES/ULTRIX_README b/README_FILES/ULTRIX_README
new file mode 100644
index 0000000..98078d1
--- /dev/null
+++ b/README_FILES/ULTRIX_README
@@ -0,0 +1,45 @@
+PPoossttffiixx aanndd UUllttrriixx
+
+-------------------------------------------------------------------------------
+
+PPoossttffiixx oonn UUllttrriixx
+
+This document is probably only of historical value, because Ultrix version 4
+dates from the early 1990s. However, as long as Wietse keeps Postfix alive for
+SunOS 4, it is likely to run on Ultrix 4 with very little change. Feedback is
+welcome if anyone actually still uses Postfix on any version of Ultrix.
+
+The source of this document is an email message by Christian von Roques that
+was sent on Jun 2, 1999.
+
+ I've upgraded the MTA of our DECstation-3100 running Ultrix4.3a to postfix-
+ 19990317-pl05 and am sending you the patches I needed to get it running
+ under Ultrix.
+
+ . . .
+
+ One of the bugs of Ultrix's /bin/sh is that shell-variables set in
+ arguments of `:' expand to garbage if expanded in here-documents. Using a
+ different shell helps. I needed to replace all calls of ``sh .../makedefs''
+ by ``$(SHELL) .../makedefs'' in all the Makefile.in and am now able to use
+ ``make SHELL=/bin/sh5'' or zsh.
+
+ . . .
+
+ Ultrix's FD_SET_SIZE is 4096, but getdtablesize() returns 64 by default, if
+ not increased when building a new kernel. getrlimit() doesn't know
+ RLIMIT_NOFILE. This makes event_init() always log the warning: `could
+ allocate space for only 64 open files'.
+
+ I just reduced the threshold from 256 to 64, but this is not good. The
+ initial problem still remains: How to disable this warning on Ultrix
+ without making the source ugly?
+
+To work around the first problem, all the Makefile.in files have been updated
+to use `$(SHELL)' instead of `sh'. So you only need to supply a non-default
+shell in order to eliminate Ultrix shell trouble.
+
+To work around the latter, util/sys_defs.h was updated for Ultrix, with a
+default FD_SETSIZE of 100. This should be sufficient for a workstation. Even in
+1999, no-one would run a major mail hub on Ultrix 4.
+
diff --git a/README_FILES/UUCP_README b/README_FILES/UUCP_README
new file mode 100644
index 0000000..1368eb3
--- /dev/null
+++ b/README_FILES/UUCP_README
@@ -0,0 +1,121 @@
+PPoossttffiixx aanndd UUUUCCPP
+
+-------------------------------------------------------------------------------
+
+UUssiinngg UUUUCCPP oovveerr TTCCPP
+
+Despite a serious lack of sex-appeal, email via UUCP over TCP is a practical
+option for sites without permanent Internet connections, and for sites without
+a fixed IP address. For first-hand information, see the following guides:
+
+ * Jim Seymour's guide for using UUCP over TCP at http://jimsun.LinxNet.com/
+ jdp/uucp_over_tcp/index.html,
+ * Craig Sanders's guide for SSL-encrypted UUCP over TCP using stunnel at
+ http://taz.net.au/postfix/uucp/.
+
+Here's a graphical description of what this document is about:
+
+ LAN to Internet
+ Local network <---> UUCP <--- UUCP ---> to UUCP <---> Internet
+ Gateway Gateway
+
+And here's the table of contents of this document:
+
+ * Setting up a Postfix Internet to UUCP gateway
+ * Setting up a Postfix LAN to UUCP gateway
+
+SSeettttiinngg uupp aa PPoossttffiixx IInntteerrnneett ttoo UUUUCCPP ggaatteewwaayy
+
+Here is how to set up a machine that sits on the Internet and that forwards
+mail to a LAN that is connected via UUCP. See the LAN to UUCP gateway section
+for the other side of the story.
+
+ * You need an rrmmaaiill program that extracts the sender address from mail that
+ arrives via UUCP, and that feeds the mail into the Postfix sseennddmmaaiill
+ command. Most UNIX systems come with an rrmmaaiill utility. If you're in a
+ pinch, try the one bundled with the Postfix source code in the aauuxxiilliiaarryy//
+ rrmmaaiill directory.
+
+ * Define a pipe(8) based mail delivery transport for delivery via UUCP:
+
+ /etc/postfix/master.cf:
+ uucp unix - n n - - pipe
+ flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
+ ($recipient)
+
+ This runs the uuuuxx command to place outgoing mail into the UUCP queue after
+ replacing $nexthop by the next-hop hostname (the receiving UUCP host) and
+ after replacing $recipient by the recipients. The pipe(8) delivery agent
+ executes the uuuuxx command without assistance from the shell, so there are no
+ problems with shell meta characters in command-line parameters.
+
+ * Specify that mail for example.com, should be delivered via UUCP, to a host
+ named uucp-host:
+
+ /etc/postfix/transport:
+ example.com uucp:uucp-host
+ .example.com uucp:uucp-host
+
+ See the transport(5) manual page for more details.
+
+ * Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ttrraannssppoorrtt" whenever you change
+ the ttrraannssppoorrtt file.
+
+ * Enable ttrraannssppoorrtt table lookups:
+
+ /etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+
+ Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
+ files. To find out what map types Postfix supports, use the command
+ "ppoossttccoonnff --mm".
+
+ * Add example.com to the list of domains that your site is willing to relay
+ mail for.
+
+ /etc/postfix/main.cf:
+ relay_domains = example.com ...other relay domains...
+
+ See the relay_domains configuration parameter description for details.
+
+ * Execute the command "ppoossttffiixx rreellooaadd" to make the changes effective.
+
+SSeettttiinngg uupp aa PPoossttffiixx LLAANN ttoo UUUUCCPP ggaatteewwaayy
+
+Here is how to relay mail from a LAN via UUCP to the Internet. See the Internet
+to UUCP gateway section for the other side of the story.
+
+ * You need an rrmmaaiill program that extracts the sender address from mail that
+ arrives via UUCP, and that feeds the mail into the Postfix sseennddmmaaiill
+ command. Most UNIX systems come with an rrmmaaiill utility. If you're in a
+ pinch, try the one bundled with the Postfix source code in the aauuxxiilliiaarryy//
+ rrmmaaiill directory.
+
+ * Specify that all remote mail must be sent via the uuuuccpp mail transport to
+ your UUCP gateway host, say, uucp-gateway:
+
+ /etc/postfix/main.cf:
+ relayhost = uucp-gateway
+ default_transport = uucp
+
+ Postfix 2.0 and later also allows the following more succinct form:
+
+ /etc/postfix/main.cf:
+ default_transport = uucp:uucp-gateway
+
+ * Define a pipe(8) based message delivery transport for mail delivery via
+ UUCP:
+
+ /etc/postfix/master.cf:
+ uucp unix - n n - - pipe
+ flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
+ ($recipient)
+
+ This runs the uuuuxx command to place outgoing mail into the UUCP queue. It
+ substitutes the next-hop hostname (uucp-gateway, or whatever you specified)
+ and the recipients before executing the command. The uuuuxx command is
+ executed without assistance from the shell, so there are no problems with
+ shell meta characters.
+
+ * Execute the command "ppoossttffiixx rreellooaadd" to make the changes effective.
+
diff --git a/README_FILES/VERP_README b/README_FILES/VERP_README
new file mode 100644
index 0000000..a721ece
--- /dev/null
+++ b/README_FILES/VERP_README
@@ -0,0 +1,186 @@
+PPoossttffiixx VVEERRPP HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPoossttffiixx VVEERRPP ssuuppppoorrtt
+
+Postfix versions 1.1 and later support variable envelope return path addresses
+on request. When VERP style delivery is requested, each recipient of a message
+receives a customized copy of the message, with his/her own recipient address
+encoded in the envelope sender address.
+
+For example, when VERP style delivery is requested, Postfix delivers mail from
+"owner-listname@origin" for a recipient "user@domain", with a sender address
+that encodes the recipient as follows:
+
+ owner-listname+user=domain@origin
+
+Thus, undeliverable mail can reveal the undeliverable recipient address without
+requiring the list owner to parse bounce messages.
+
+The VERP concept was popularized by the qmail MTA and by the ezmlm mailing list
+manager. See http://cr.yp.to/proto/verp.txt for the ideas behind this concept.
+
+Topics covered in this document:
+
+ * Postfix VERP configuration parameters
+ * Using VERP with majordomo etc. mailing lists
+ * VERP support in the Postfix SMTP server
+ * VERP support in the Postfix sendmail command
+ * VERP support in the Postfix QMQP server
+
+PPoossttffiixx VVEERRPP ccoonnffiigguurraattiioonn ppaarraammeetteerrss
+
+With Postfix, the whole process is controlled by four configuration parameters.
+
+default_verp_delimiters (default value: +=)
+ What VERP delimiter characters Postfix uses when VERP style delivery is
+ requested but no explicit delimiters are specified.
+
+verp_delimiter_filter (default: -+=)
+ What characters Postfix accepts as VERP delimiter characters on the
+ sendmail command line and in SMTP commands. Many characters must not be
+ used as VERP delimiter characters, either because they already have a
+ special meaning in email addresses (such as the @ or the %), because they
+ are used as part of a username or domain name (such as alphanumerics), or
+ because they are non-ASCII or control characters. And who knows, some
+ characters may tickle bugs in vulnerable software, and we would not want
+ that to happen.
+
+smtpd_authorized_verp_clients (default value: none)
+ What SMTP clients are allowed to request VERP style delivery. The Postfix
+ QMQP server uses its own access control mechanism, and local submission
+ (via /usr/sbin/sendmail etc.) is always authorized. To authorize a host,
+ list its name, IP address, subnet (net/mask) or parent .domain.
+
+ With Postfix versions 1.1 and 2.0, this parameter is called
+ authorized_verp_clients (default: $mynetworks).
+
+disable_verp_bounces (default: no)
+ Send one bounce report for multi-recipient VERP mail, instead of one bounce
+ report per recipient. The default, one per recipient, is what ezmlm needs.
+
+UUssiinngg VVEERRPP wwiitthh mmaajjoorrddoommoo eettcc.. mmaaiilliinngg lliissttss
+
+In order to make VERP useful with majordomo etc. mailing lists, you would
+configure the list manager to submit mail according to one of the following two
+forms:
+
+Postfix 2.3 and later:
+
+ % sendmail -XV -f owner-listname other-arguments...
+
+ % sendmail -XV+= -f owner-listname other-arguments...
+
+Postfix 2.2 and earlier (Postfix 2.3 understands the old syntax for backwards
+compatibility, but will log a warning that reminds you of the new syntax):
+
+ % sendmail -V -f owner-listname other-arguments...
+
+ % sendmail -V+= -f owner-listname other-arguments...
+
+The first form uses the default main.cf VERP delimiter characters. The second
+form allows you to explicitly specify the VERP delimiter characters. The
+example shows the recommended values.
+
+This text assumes that you have set up an owner-listname alias that routes
+undeliverable mail to a real person:
+
+ /etc/aliases:
+ owner-listname: yourname+listname
+
+In order to process bounces we are going to make extensive use of address
+extension tricks.
+
+You need to tell Postfix that + is the separator between an address and its
+optional address extension, that address extensions are appended to .forward
+file names, and that address extensions are to be discarded when doing alias
+expansions:
+
+ /etc/postfix/main.cf:
+ recipient_delimiter = +
+ forward_path = $home/.forward${recipient_delimiter}${extension},
+ $home/.forward
+ propagate_unmatched_extensions = canonical, virtual
+
+(the last two parameter settings are default settings).
+
+You need to set up a file named .forward+listname with the commands that
+process all the mail that is sent to the owner-listname address:
+
+ ~/.forward+listname:
+ "|/some/where/command ..."
+
+With this set up, undeliverable mail for user@domain will be returned to the
+following address:
+
+ owner-listname+user=domain@your.domain
+
+which is processed by the command in your .forward+listname file. The message
+should contain, among others, a To: header with the encapsulated recipient
+sender address:
+
+ To: owner-listname+user=domain@your.domain
+
+It is left as an exercise for the reader to parse the To: header line and to
+pull out the user=domain part from the recipient address.
+
+VVEERRPP ssuuppppoorrtt iinn tthhee PPoossttffiixx SSMMTTPP sseerrvveerr
+
+The Postfix SMTP server implements a command XVERP to enable VERP style
+delivery. The syntax allows two forms:
+
+ MAIL FROM: XVERP
+
+ MAIL FROM: XVERP=+=
+
+The first form uses the default main.cf VERP delimiters, the second form
+overrides them explicitly. The values shown are the recommended ones.
+
+You can use the smtpd_command_filter feature to append XVERP to SMTP commands
+from legacy software. This requires Postfix 2.7 or later.
+
+ /etc/postfix/main.cf:
+ smtpd_command_filter = pcre:/etc/postfix/append_verp.pcre
+ smtpd_authorized_verp_clients = $mynetworks
+
+ /etc/postfix/append_verp.pcre:
+ /^(MAIL FROM:.*)/ $1 XVERP
+
+VVEERRPP ssuuppppoorrtt iinn tthhee PPoossttffiixx sseennddmmaaiill ccoommmmaanndd
+
+The Postfix sendmail command has a -V flag to request VERP style delivery.
+Specify one of the following two forms:
+
+Postfix 2.3 and later:
+
+ % sendmail -XV -f owner-listname ....
+
+ % sendmail -XV+= -f owner-listname ....
+
+Postfix 2.2 and earlier (Postfix 2.3 understands the old syntax for backwards
+compatibility, but will log a warning that reminds you of the new syntax):
+
+ % sendmail -V -f owner-listname ....
+
+ % sendmail -V+= -f owner-listname ....
+
+The first form uses the default main.cf VERP delimiters, the second form
+overrides them explicitly. The values shown are the recommended ones.
+
+VVEERRPP ssuuppppoorrtt iinn tthhee PPoossttffiixx QQMMQQPP sseerrvveerr
+
+When the Postfix QMQP server receives mail with an envelope sender address of
+the form:
+
+ listname-@your.domain-@[]
+
+Postfix generates sender addresses "listname-user=domain@your.domain", using "-
+=" as the VERP delimiters because qmail/ezmlm expect this.
+
+More generally, a sender address of "prefix@origin-@[]" requests VERP style
+delivery with sender addresses of the form "prefixuser=domain@origin". However,
+Postfix allows only VERP delimiters that are specified with the
+verp_delimiter_filter parameter. In particular, the "=" delimiter is required
+for qmail compatibility (see the qmail addresses(5) manual page for details).
+
diff --git a/README_FILES/VIRTUAL_README b/README_FILES/VIRTUAL_README
new file mode 100644
index 0000000..6f470ee
--- /dev/null
+++ b/README_FILES/VIRTUAL_README
@@ -0,0 +1,483 @@
+PPoossttffiixx VViirrttuuaall DDoommaaiinn HHoossttiinngg HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhiiss ddooccuummeenntt
+
+This document requires Postfix version 2.0 or later.
+
+This document gives an overview of how Postfix can be used for hosting multiple
+Internet domains, both for final delivery on the machine itself and for the
+purpose of forwarding to destinations elsewhere.
+
+The text not only describes delivery mechanisms that are built into Postfix,
+but also gives pointers for using non-Postfix mail delivery software.
+
+The following topics are covered:
+
+ * Canonical versus hosted versus other domains
+ * Local files versus network databases
+ * As simple as can be: shared domains, UNIX system accounts
+ * Postfix virtual ALIAS example: separate domains, UNIX system accounts
+ * Postfix virtual MAILBOX example: separate domains, non-UNIX accounts
+ * Non-Postfix mailbox store: separate domains, non-UNIX accounts
+ * Mail forwarding domains
+ * Mailing lists
+ * Autoreplies
+
+CCaannoonniiccaall vveerrssuuss hhoosstteedd vveerrssuuss ootthheerr ddoommaaiinnss
+
+Most Postfix systems are 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
+ddeessttiinnaattiioonn for any number of additional domains. These domains are called
+hosted, because they are not directly associated with the name of the machine
+itself. Hosted domains are usually implemented with the virtual alias domain
+address class and/or with the virtual mailbox domain address class, as defined
+in the ADDRESS_CLASS_README file.
+
+But wait! There is more. Postfix can be configured as a backup MX host for
+other domains. In this case Postfix is nnoott tthhee ffiinnaall ddeessttiinnaattiioonn for those
+domains. It merely queues the mail when the primary MX host is down, and
+forwards the mail when the primary MX host becomes available. This function is
+implemented with the relay domain address class, as defined in the
+ADDRESS_CLASS_README file.
+
+Finally, Postfix can be configured as a transit host for sending mail across
+the internet. Obviously, Postfix is not final destination for such mail. This
+function is available only for authorized clients and/or users, and is
+implemented by the default domain address class, as defined in the
+ADDRESS_CLASS_README file.
+
+LLooccaall ffiilleess vveerrssuuss nneettwwoorrkk ddaattaabbaasseess
+
+The examples in this text use table lookups from local files such as DBM or
+Berkeley DB. These are easy to debug with the ppoossttmmaapp command:
+
+ Example: postmap -q info@example.com hash:/etc/postfix/virtual
+
+See the documentation in LDAP_README, MYSQL_README and PGSQL_README for how to
+replace local files by databases. The reader is strongly advised to make the
+system work with local files before migrating to network databases, and to use
+the ppoossttmmaapp command to verify that network database lookups produce the exact
+same results as local file lookup.
+
+ Example: postmap -q info@example.com ldap:/etc/postfix/virtual.cf
+
+AAss ssiimmppllee aass ccaann bbee:: sshhaarreedd ddoommaaiinnss,, UUNNIIXX ssyysstteemm aaccccoouunnttss
+
+The simplest method to host an additional domain is to add the domain name to
+the domains listed in the Postfix mydestination configuration parameter, and to
+add the user names to the UNIX password file.
+
+This approach makes no distinction between canonical and hosted domains. Each
+username can receive mail in every domain.
+
+In the examples we will use "example.com" as the domain that is being hosted on
+the local Postfix machine.
+
+ /etc/postfix/main.cf:
+ mydestination = $myhostname localhost.$mydomain ... example.com
+
+The limitations of this approach are:
+
+ * A total lack of separation: mail for info@my.host.name is delivered to the
+ same UNIX system account as mail for info@example.com.
+ * With users in the UNIX password file, administration of large numbers of
+ users becomes inconvenient.
+
+The examples that follow provide solutions for both limitations.
+
+PPoossttffiixx vviirrttuuaall AALLIIAASS eexxaammppllee:: sseeppaarraattee ddoommaaiinnss,, UUNNIIXX ssyysstteemm aaccccoouunnttss
+
+With the approach described in this section, every hosted domain can have its
+own info etc. email address. However, it still uses UNIX system accounts for
+local mailbox deliveries.
+
+With virtual alias domains, each hosted address is aliased to a local UNIX
+system account or to a remote address. The example below shows how to use this
+mechanism for the example.com domain.
+
+ 1 /etc/postfix/main.cf:
+ 2 virtual_alias_domains = example.com ...other hosted domains...
+ 3 virtual_alias_maps = hash:/etc/postfix/virtual
+ 4
+ 5 /etc/postfix/virtual:
+ 6 postmaster@example.com postmaster
+ 7 info@example.com joe
+ 8 sales@example.com jane
+ 9 # Uncomment entry below to implement a catch-all address
+ 10 # @example.com jim
+ 11 ...virtual aliases for more domains...
+
+Notes:
+
+ * Line 2: the virtual_alias_domains setting tells Postfix that example.com is
+ a so-called virtual alias domain. If you omit this setting then Postfix
+ will reject mail (relay access denied) or will not be able to deliver it
+ (mail for example.com loops back to myself).
+
+ NEVER list a virtual alias domain name as a mydestination domain!
+
+ * Lines 3-8: the /etc/postfix/virtual file contains the virtual aliases. With
+ the example above, mail for postmaster@example.com goes to the local
+ postmaster, while mail for info@example.com goes to the UNIX account joe,
+ and mail for sales@example.com goes to the UNIX account jane. Mail for all
+ other addresses in example.com is rejected with the error message "User
+ unknown".
+
+ * Line 10: the commented out entry (text after #) shows how one would
+ implement a catch-all virtual alias that receives mail for every
+ example.com address not listed in the virtual alias file. This is not
+ without risk. Spammers nowadays try to send mail from (or mail to) every
+ possible name that they can think of. A catch-all mailbox is likely to
+ receive many spam messages, and many bounces for spam messages that were
+ sent in the name of anything@example.com.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
+file, and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
+
+Note: virtual aliases can resolve to a local address or to a remote address, or
+both. They don't have to resolve to UNIX system accounts on your machine.
+
+More details about the virtual alias file are given in the virtual(5) manual
+page, including multiple addresses on the right-hand side.
+
+Virtual aliasing solves one problem: it allows each domain to have its own info
+mail address. But there still is one drawback: each virtual address is aliased
+to a UNIX system account. As you add more virtual addresses you also add more
+UNIX system accounts. The next section eliminates this problem.
+
+PPoossttffiixx vviirrttuuaall MMAAIILLBBOOXX eexxaammppllee:: sseeppaarraattee ddoommaaiinnss,, nnoonn--UUNNIIXX aaccccoouunnttss
+
+As a system hosts more and more domains and users, it becomes less desirable to
+give every user their own UNIX system account.
+
+With the Postfix virtual(8) mailbox delivery agent, every recipient address can
+have its own virtual mailbox. Unlike virtual alias domains, virtual mailbox
+domains do not need the clumsy translation from each recipient addresses into a
+different address, and owners of a virtual mailbox address do not need to have
+a UNIX system account.
+
+The Postfix virtual(8) mailbox delivery agent looks up the user mailbox
+pathname, uid and gid via separate tables that are searched with the
+recipient's mail address. Maildir style delivery is turned on by terminating
+the mailbox pathname with "/".
+
+If you find the idea of multiple tables bothersome, remember that you can
+migrate the information (once it works), to an SQL database. If you take that
+route, be sure to review the "local files versus databases" section at the top
+of this document.
+
+Here is an example of a virtual mailbox domain "example.com":
+
+ 1 /etc/postfix/main.cf:
+ 2 virtual_mailbox_domains = example.com ...more domains...
+ 3 virtual_mailbox_base = /var/mail/vhosts
+ 4 virtual_mailbox_maps = hash:/etc/postfix/vmailbox
+ 5 virtual_minimum_uid = 100
+ 6 virtual_uid_maps = static:5000
+ 7 virtual_gid_maps = static:5000
+ 8 virtual_alias_maps = hash:/etc/postfix/virtual
+ 9
+ 10 /etc/postfix/vmailbox:
+ 11 info@example.com example.com/info
+ 12 sales@example.com example.com/sales/
+ 13 # Comment out the entry below to implement a catch-all.
+ 14 # @example.com example.com/catchall
+ 15 ...virtual mailboxes for more domains...
+ 16
+ 17 /etc/postfix/virtual:
+ 18 postmaster@example.com postmaster
+
+Notes:
+
+ * Line 2: The virtual_mailbox_domains setting tells Postfix that example.com
+ is a so-called virtual mailbox domain. If you omit this setting then
+ Postfix will reject mail (relay access denied) or will not be able to
+ deliver it (mail for example.com loops back to myself).
+
+ NEVER list a virtual MAILBOX domain name as a mydestination domain!
+
+ NEVER list a virtual MAILBOX domain name as a virtual ALIAS domain!
+
+ * Line 3: The virtual_mailbox_base parameter specifies a prefix for all
+ virtual mailbox pathnames. This is a safety mechanism in case someone makes
+ a mistake. It prevents mail from being delivered all over the file system.
+
+ * Lines 4, 10-15: The virtual_mailbox_maps parameter specifies the lookup
+ table with mailbox (or maildir) pathnames, indexed by the virtual mail
+ address. In this example, mail for info@example.com goes to the mailbox at
+ /var/mail/vhosts/example.com/info while mail for sales@example.com goes to
+ the maildir located at /var/mail/vhosts/example.com/sales/.
+
+ * Line 5: The virtual_minimum_uid specifies a lower bound on the mailbox or
+ maildir owner's UID. This is a safety mechanism in case someone makes a
+ mistake. It prevents mail from being written to sensitive files.
+
+ * Lines 6, 7: The virtual_uid_maps and virtual_gid_maps parameters specify
+ that all the virtual mailboxes are owned by a fixed uid and gid 5000. If
+ this is not what you want, specify lookup tables that are searched by the
+ recipient's mail address.
+
+ * Line 14: The commented out entry (text after #) shows how one would
+ implement a catch-all virtual mailbox address. Be prepared to receive a lot
+ of spam, as well as bounced spam that was sent in the name of
+ anything@example.com.
+
+ NEVER put a virtual MAILBOX wild-card in the virtual ALIAS file!!
+
+ * Lines 8, 17, 18: As you see, it is possible to mix virtual aliases with
+ virtual mailboxes. We use this feature to redirect mail for example.com's
+ postmaster address to the local postmaster. You can use the same mechanism
+ to redirect an address to a remote address.
+
+ * Line 18: This example assumes that in main.cf, $myorigin is listed under
+ the mydestination parameter setting. If that is not the case, specify an
+ explicit domain name on the right-hand side of the virtual alias table
+ entries or else mail will go to the wrong domain.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
+file, execute "ppoossttmmaapp //eettcc//ppoossttffiixx//vvmmaaiillbbooxx" after changing the vmailbox file,
+and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
+
+Note: mail delivery happens with the recipient's UID/GID privileges specified
+with virtual_uid_maps and virtual_gid_maps. Postfix 2.0 and earlier will not
+create mailDIRs in world-writable parent directories; you must create them in
+advance before you can use them. Postfix may be able to create mailBOX files by
+itself, depending on parent directory write permissions, but it is safer to
+create mailBOX files ahead of time.
+
+More details about the virtual mailbox delivery agent are given in the virtual
+(8) manual page.
+
+NNoonn--PPoossttffiixx mmaaiillbbooxx ssttoorree:: sseeppaarraattee ddoommaaiinnss,, nnoonn--UUNNIIXX aaccccoouunnttss
+
+This is a variation on the Postfix virtual mailbox example. Again, every hosted
+address can have its own mailbox. However, most parameters that control the
+virtual(8) delivery agent are no longer applicable: only
+virtual_mailbox_domains and virtual_mailbox_maps stay in effect. These
+parameters are needed to reject mail for unknown recipients.
+
+While non-Postfix software is being used for final delivery, some Postfix
+concepts are still needed in order to glue everything together. For additional
+background on this glue you may want to take a look at the virtual mailbox
+domain class as defined in the ADDRESS_CLASS_README file.
+
+The text in this section describes what things should look like from Postfix's
+point of view. See CYRUS_README or MAILDROP_README for specific information
+about Cyrus or about Courier maildrop.
+
+Here is an example for a hosted domain example.com that delivers to a non-
+Postfix delivery agent:
+
+ 1 /etc/postfix/main.cf:
+ 2 virtual_transport = ...see below...
+ 3 virtual_mailbox_domains = example.com ...more domains...
+ 4 virtual_mailbox_maps = hash:/etc/postfix/vmailbox
+ 5 virtual_alias_maps = hash:/etc/postfix/virtual
+ 6
+ 7 /etc/postfix/vmailbox:
+ 8 info@example.com whatever
+ 9 sales@example.com whatever
+ 10 # Comment out the entry below to implement a catch-all.
+ 11 # Configure the mailbox store to accept all addresses.
+ 12 # @example.com whatever
+ 13 ...virtual mailboxes for more domains...
+ 14
+ 15 /etc/postfix/virtual:
+ 16 postmaster@example.com postmaster
+
+Notes:
+
+ * Line 2: With delivery to a non-Postfix mailbox store for hosted domains,
+ the virtual_transport parameter usually specifies the Postfix LMTP client,
+ or the name of a master.cf entry that executes non-Postfix software via the
+ pipe delivery agent. Typical examples (use only one):
+
+ virtual_transport = lmtp:unix:/path/name (uses UNIX-domain socket)
+ virtual_transport = lmtp:hostname:port (uses TCP socket)
+ virtual_transport = maildrop: (uses pipe(8) to command)
+
+ Postfix comes ready with support for LMTP. And an example maildrop delivery
+ method is already defined in the default Postfix master.cf file. See the
+ MAILDROP_README document for more details.
+
+ * Line 3: The virtual_mailbox_domains setting tells Postfix that example.com
+ is delivered via the virtual_transport that was discussed in the previous
+ paragraph. If you omit this virtual_mailbox_domains setting then Postfix
+ will either reject mail (relay access denied) or will not be able to
+ deliver it (mail for example.com loops back to myself).
+
+ NEVER list a virtual MAILBOX domain name as a mydestination domain!
+
+ NEVER list a virtual MAILBOX domain name as a virtual ALIAS domain!
+
+ * Lines 4, 7-13: The virtual_mailbox_maps parameter specifies the lookup
+ table with all valid recipient addresses. The lookup result value is
+ ignored by Postfix. In the above example, info@example.com and
+ sales@example.com are listed as valid addresses; other mail for example.com
+ is rejected with "User unknown" by the Postfix SMTP server. It's left up to
+ the non-Postfix delivery agent to reject non-existent recipients from local
+ submission or from local alias expansion. If you intend to use LDAP, MySQL
+ or PgSQL instead of local files, be sure to review the "local files versus
+ databases" section at the top of this document!
+
+ * Line 12: The commented out entry (text after #) shows how one would inform
+ Postfix of the existence of a catch-all address. Again, the lookup result
+ is ignored by Postfix.
+
+ NEVER put a virtual MAILBOX wild-card in the virtual ALIAS file!!
+
+ Note: if you specify a wildcard in virtual_mailbox_maps, then you still
+ need to configure the non-Postfix mailbox store to receive mail for any
+ address in that domain.
+
+ * Lines 5, 15, 16: As you see above, it is possible to mix virtual aliases
+ with virtual mailboxes. We use this feature to redirect mail for
+ example.com's postmaster address to the local postmaster. You can use the
+ same mechanism to redirect any addresses to a local or remote address.
+
+ * Line 16: This example assumes that in main.cf, $myorigin is listed under
+ the mydestination parameter setting. If that is not the case, specify an
+ explicit domain name on the right-hand side of the virtual alias table
+ entries or else mail will go to the wrong domain.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
+file, execute "ppoossttmmaapp //eettcc//ppoossttffiixx//vvmmaaiillbbooxx" after changing the vmailbox file,
+and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
+
+MMaaiill ffoorrwwaarrddiinngg ddoommaaiinnss
+
+Some providers host domains that have no (or only a few) local mailboxes. The
+main purpose of these domains is to forward mail elsewhere. The following
+example shows how to set up example.com as a mail forwarding domain:
+
+ 1 /etc/postfix/main.cf:
+ 2 virtual_alias_domains = example.com ...other hosted domains...
+ 3 virtual_alias_maps = hash:/etc/postfix/virtual
+ 4
+ 5 /etc/postfix/virtual:
+ 6 postmaster@example.com postmaster
+ 7 joe@example.com joe@somewhere
+ 8 jane@example.com jane@somewhere-else
+ 9 # Uncomment entry below to implement a catch-all address
+ 10 # @example.com jim@yet-another-site
+ 11 ...virtual aliases for more domains...
+
+Notes:
+
+ * Line 2: The virtual_alias_domains setting tells Postfix that example.com is
+ a so-called virtual alias domain. If you omit this setting then Postfix
+ will reject mail (relay access denied) or will not be able to deliver it
+ (mail for example.com loops back to myself).
+
+ NEVER list a virtual alias domain name as a mydestination domain!
+
+ * Lines 3-11: The /etc/postfix/virtual file contains the virtual aliases.
+ With the example above, mail for postmaster@example.com goes to the local
+ postmaster, while mail for joe@example.com goes to the remote address
+ joe@somewhere, and mail for jane@example.com goes to the remote address
+ jane@somewhere-else. Mail for all other addresses in example.com is
+ rejected with the error message "User unknown".
+
+ * Line 10: The commented out entry (text after #) shows how one would
+ implement a catch-all virtual alias that receives mail for every
+ example.com address not listed in the virtual alias file. This is not
+ without risk. Spammers nowadays try to send mail from (or mail to) every
+ possible name that they can think of. A catch-all mailbox is likely to
+ receive many spam messages, and many bounces for spam messages that were
+ sent in the name of anything@example.com.
+
+Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" after changing the virtual
+file, and execute the command "ppoossttffiixx rreellooaadd" after changing the main.cf file.
+
+More details about the virtual alias file are given in the virtual(5) manual
+page, including multiple addresses on the right-hand side.
+
+MMaaiilliinngg lliissttss
+
+The examples that were given above already show how to direct mail for virtual
+postmaster addresses to a local postmaster. You can use the same method to
+direct mail for any address to a local or remote address.
+
+There is one major limitation: virtual aliases and virtual mailboxes can't
+directly deliver to mailing list managers such as majordomo. The solution is to
+set up virtual aliases that direct virtual addresses to the local delivery
+agent:
+
+ /etc/postfix/main.cf:
+ virtual_alias_maps = hash:/etc/postfix/virtual
+
+ /etc/postfix/virtual:
+ listname-request@example.com listname-request
+ listname@example.com listname
+ owner-listname@example.com owner-listname
+
+ /etc/aliases:
+ listname: "|/some/where/majordomo/wrapper ..."
+ owner-listname: ...
+ listname-request: ...
+
+This example assumes that in main.cf, $myorigin is listed under the
+mydestination parameter setting. If that is not the case, specify an explicit
+domain name on the right-hand side of the virtual alias table entries or else
+mail will go to the wrong domain.
+
+More information about the Postfix local delivery agent can be found in the
+local(8) manual page.
+
+Why does this example use a clumsy virtual alias instead of a more elegant
+transport mapping? The reason is that mail for the virtual mailing list would
+be rejected with "User unknown". In order to make the transport mapping work
+one would still need a bunch of virtual alias or virtual mailbox table entries.
+
+ * In case of a virtual alias domain, there would need to be one identity
+ mapping from each mailing list address to itself.
+ * In case of a virtual mailbox domain, there would need to be a dummy mailbox
+ for each mailing list address.
+
+AAuuttoorreepplliieess
+
+In order to set up an autoreply for virtual recipients while still delivering
+mail as normal, set up a rule in a virtual alias table:
+
+ /etc/postfix/main.cf:
+ virtual_alias_maps = hash:/etc/postfix/virtual
+
+ /etc/postfix/virtual:
+ user@domain.tld user@domain.tld, user@domain.tld@autoreply.mydomain.tld
+
+This delivers mail to the recipient, and sends a copy of the mail to the
+address that produces automatic replies. The address can be serviced on a
+different machine, or it can be serviced locally by setting up a transport map
+entry that pipes all mail for autoreply.mydomain.tld into some script that
+sends an automatic reply back to the sender.
+
+DO NOT list autoreply.mydomain.tld in mydestination!
+
+ /etc/postfix/main.cf:
+ transport_maps = hash:/etc/postfix/transport
+
+ /etc/postfix/transport:
+ autoreply.mydomain.tld autoreply:
+
+ /etc/postfix/master.cf:
+ # =============================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =============================================================
+ autoreply unix - n n - - pipe
+ flags= user=nobody argv=/path/to/autoreply $sender $mailbox
+
+This invokes /path/to/autoreply with the sender address and the user@domain.tld
+recipient address on the command line.
+
+For more information, see the pipe(8) manual page, and the comments in the
+Postfix master.cf file.
+
diff --git a/README_FILES/XCLIENT_README b/README_FILES/XCLIENT_README
new file mode 100644
index 0000000..ecee27b
--- /dev/null
+++ b/README_FILES/XCLIENT_README
@@ -0,0 +1,189 @@
+PPoossttffiixx XXCCLLIIEENNTT HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhee XXCCLLIIEENNTT eexxtteennssiioonn ttoo SSMMTTPP
+
+When an SMTP server announces support for the XCLIENT command, an SMTP client
+may send information that overrides one or more client-related session
+attributes. The XCLIENT command targets the following problems:
+
+ 1. Access control tests. SMTP server access rules are difficult to verify when
+ decisions can be triggered only by remote clients. In order to facilitate
+ access rule testing, an authorized SMTP client test program needs the
+ ability to override the SMTP server's idea of the SMTP client hostname,
+ network address, and other client information, for the entire duration of
+ an SMTP session.
+
+ 2. Client software that downloads mail from an up-stream mail server and
+ injects it into a local MTA via SMTP. In order to take advantage of the
+ local MTA's SMTP server access rules, the client software needs the ability
+ to override the SMTP server's idea of the remote client name, client
+ address and other information. Such information can typically be extracted
+ from the up-stream mail server's Received: message header.
+
+ 3. Post-filter access control and logging. With Internet->filter->MTA style
+ content filter applications, the filter can be simplified if it can
+ delegate decisions concerning mail relay and other access control to the
+ MTA. This is especially useful when the filter acts as a transparent proxy
+ for SMTP commands. This requires that the filter can override the MTA's
+ idea of the SMTP client hostname, network address, and other information.
+
+XXCCLLIIEENNTT CCoommmmaanndd ssyynnttaaxx
+
+An example client-server conversation is given at the end of this document.
+
+In SMTP server EHLO replies, the keyword associated with this extension is
+XCLIENT. It is followed by the names of the attributes that the XCLIENT
+implementation supports.
+
+The XCLIENT command may be sent at any time, except in the middle of a mail
+delivery transaction (i.e. between MAIL and DOT, or MAIL and RSET). The XCLIENT
+command may be pipelined when the server supports ESMTP command pipelining. To
+avoid triggering spamware detectors, the command should be sent at the end of a
+command group.
+
+The syntax of XCLIENT requests is described below. Upper case and quoted
+strings specify terminals, lowercase strings specify meta terminals, and SP is
+whitespace. Although command and attribute names are shown in upper case, they
+are in fact case insensitive.
+
+ xclient-command = XCLIENT 1*( SP attribute-name"="attribute-value )
+
+ attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | LOGIN )
+
+ attribute-value = xtext
+
+ * Attribute values are xtext encoded as per RFC 1891.
+
+ * The NAME attribute specifies an SMTP client hostname (not an SMTP client
+ address), [UNAVAILABLE] when client hostname lookup failed due to a
+ permanent error, or [TEMPUNAVAIL] when the lookup error condition was
+ transient.
+
+ * The ADDR attribute specifies an SMTP client numerical IPv4 network address,
+ an IPv6 address prefixed with IPV6:, or [UNAVAILABLE] when the address
+ information is unavailable. Address information is not enclosed with [].
+
+ * The PORT attribute specifies the SMTP client TCP port number as a decimal
+ number, or [UNAVAILABLE] when the information is unavailable.
+
+ * The PROTO attribute specifies either SMTP or ESMTP.
+
+ * The HELO attribute specifies an SMTP HELO parameter value, or the value
+ [UNAVAILABLE] when the information is unavailable.
+
+ * The LOGIN attribute specifies a SASL login name, or the value [UNAVAILABLE]
+ when the information is unavailable.
+
+Note 1: syntactically valid NAME and HELO attribute-value elements can be up to
+255 characters long. The client must not send XCLIENT commands that exceed the
+512 character limit for SMTP commands. To avoid exceeding the limit the client
+should send the information in multiple XCLIENT commands; for example, send
+NAME and ADDR last, after HELO and PROTO. Once ADDR is sent, the client is
+usually no longer authorized to send XCLIENT commands.
+
+Note 2: [UNAVAILABLE], [TEMPUNAVAIL] and IPV6: may be specified in upper case,
+lower case or mixed case.
+
+Note 3: Postfix implementations prior to version 2.3 do not xtext encode
+attribute values. Servers that wish to interoperate with these older
+implementations should be prepared to receive unencoded information.
+
+Note 4: Some Postfix implementations do not implement the PORT or LOGIN
+attributes.
+
+XXCCLLIIEENNTT SSeerrvveerr rreessppoonnssee
+
+Upon receipt of a correctly formatted XCLIENT command, the server resets state
+to the initial SMTP greeting protocol stage. Depending on the outcome of
+optional access decisions, the server responds with 220 or with a suitable
+rejection code.
+
+For practical reasons it is not always possible to reset the complete server
+state to the initial SMTP greeting protocol stage:
+
+ * TLS session information may not be reset, because turning off TLS leaves
+ the connection in an undefined state. Consequently, the server may not
+ announce STARTTLS when TLS is already active, and access decisions may be
+ influenced by client certificate information that was received prior to the
+ XCLIENT command.
+
+ * The SMTP server must not reset attributes that were received with the last
+ XCLIENT command. This includes HELO or PROTO attributes.
+
+NOTE: Postfix implementations prior to version 2.3 do not jump back to the
+initial SMTP greeting protocol stage. These older implementations will not
+correctly simulate connection-level access decisions under some conditions.
+
+XXCCLLIIEENNTT sseerrvveerr rreeppllyy ccooddeess
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |CCooddee |MMeeaanniinngg |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |220 |success |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |421 |unable to proceed, disconnecting |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |501 |bad command parameter syntax |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |503 |mail transaction in progress |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |550 |insufficient authorization |
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |other|connection rejected by connection-level access decision|
+ |_ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+XXCCLLIIEENNTT EExxaammppllee
+
+In the example, the client impersonates a mail originating system by passing
+all SMTP client information via the XCLIENT command. Information sent by the
+client is shown in bold font.
+
+ 220 server.example.com ESMTP Postfix
+ EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+ 250-server.example.com
+ 250-PIPELINING
+ 250-SIZE 10240000
+ 250-VRFY
+ 250-ETRN
+ 250-XCLIENT NAME ADDR PROTO HELO
+ 250 8BITMIME
+ XXCCLLIIEENNTT NNAAMMEE==ssppiikkee..ppoorrccuuppiinnee..oorrgg AADDDDRR==116688..110000..118899..22
+ 220 server.example.com ESMTP Postfix
+ EEHHLLOO ssppiikkee..ppoorrccuuppiinnee..oorrgg
+ 250-server.example.com
+ 250-PIPELINING
+ 250-SIZE 10240000
+ 250-VRFY
+ 250-ETRN
+ 250-XCLIENT NAME ADDR PROTO HELO
+ 250 8BITMIME
+ MMAAIILL FFRROOMM::<>
+ 250 Ok
+ RRCCPPTT TTOO::<>
+ 250 Ok
+ DDAATTAA
+ 354 End data with .
+ .. .. ..mmeessssaaggee ccoonntteenntt.. .. ..
+ ..
+ 250 Ok: queued as 763402AAE6
+ QQUUIITT
+ 221 Bye
+
+SSeeccuurriittyy
+
+The XCLIENT command changes audit trails and/or SMTP client access permissions.
+Use of this command must be restricted to authorized SMTP clients.
+
+SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg
+
+XCLIENT attributes persist until the end of an SMTP session. If one session is
+used to deliver mail on behalf of different SMTP clients, the XCLIENT
+attributes need to be reset as appropriate before each MAIL FROM command.
+
+RReeffeerreenncceess
+
+Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891,
+January 1996.
+
diff --git a/README_FILES/XFORWARD_README b/README_FILES/XFORWARD_README
new file mode 100644
index 0000000..84802ed
--- /dev/null
+++ b/README_FILES/XFORWARD_README
@@ -0,0 +1,179 @@
+PPoossttffiixx XXFFOORRWWAARRDD HHoowwttoo
+
+-------------------------------------------------------------------------------
+
+PPuurrppoossee ooff tthhee XXFFOORRWWAARRDD eexxtteennssiioonn ttoo SSMMTTPP
+
+When an SMTP server announces support for the XFORWARD command, an SMTP client
+may send information that overrides one or more client-related logging
+attributes. The XFORWARD command targets the following problem:
+
+ * Logging after SMTP-based content filter. With the deployment of Internet-
+ >MTA1->filter->MTA2 style content filter applications, the logging of
+ client and message identifying information changes when MTA1 gives the mail
+ to the content filter. To simplify the interpretation of MTA2 logging, it
+ would help if MTA1 could forward remote client and/or message identifying
+ information through the content filter to MTA2, so that the information
+ could be logged as part of mail handling transactions.
+
+This extension is implemented as a separate ESMTP command, and can be used to
+transmit client or message attributes incrementally. It is not implemented by
+passing additional parameters via the MAIL FROM command, because doing so would
+require extending the MAIL FROM command length limit by another 600 or more
+characters beyond the space that is already needed to support other extensions
+such as AUTH and DSN.
+
+XXFFOORRWWAARRDD CCoommmmaanndd ssyynnttaaxx
+
+An example of a client-server conversation is given at the end of this
+document.
+
+In SMTP server EHLO replies, the keyword associated with this extension is
+XFORWARD. The keyword is followed by the names of the attributes that the
+XFORWARD implementation supports.
+
+After receiving the server's announcement for XFORWARD support, the client may
+send XFORWARD requests at any time except in the middle of a mail delivery
+transaction (i.e. between MAIL and RSET or DOT). The command may be pipelined
+when the server supports ESMTP command pipelining.
+
+The syntax of XFORWARD requests is described below. Upper case and quoted
+strings specify terminals, lowercase strings specify meta terminals, and SP is
+whitespace. Although command and attribute names are shown in upper case, they
+are in fact case insensitive.
+
+ xforward-command = XFORWARD 1*( SP attribute-name"="attribute-value )
+
+ attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | IDENT | SOURCE )
+
+ attribute-value = xtext
+
+ * Attribute values are xtext encoded as per RFC 1891.
+
+ * The NAME attribute specifies the up-stream hostname, or [UNAVAILABLE] when
+ the information is unavailable. The hostname may be a non-DNS hostname.
+
+ * The ADDR attribute specifies the up-stream network address: a numerical
+ IPv4 network address, an IPv6 address prefixed with IPV6:, or [UNAVAILABLE]
+ when the address information is unavailable. Address information is not
+ enclosed with [].
+
+ * The PORT attribute specifies an up-stream client TCP port number in
+ decimal, or [UNAVAILABLE] when the information is unavailable.
+
+ * The PROTO attribute specifies the mail protocol for receiving mail from the
+ up-stream host. This may be an SMTP or non-SMTP protocol name of up to 64
+ characters, or [UNAVAILABLE] when the information is unavailable.
+
+ * The HELO attribute specifies the hostname that the up-stream host announced
+ itself with (not necessarily via the SMTP HELO command), or [UNAVAILABLE]
+ when the information is unavailable. The hostname may be a non-DNS
+ hostname.
+
+ * The IDENT attribute specifies a local message identifier on the up-stream
+ host, or [UNAVAILABLE] when the information is unavailable. The down-stream
+ MTA may log this information together with its own local message identifier
+ to facilitate message tracking across MTAs.
+
+ * The SOURCE attribute specifies LOCAL when the message was received from a
+ source that is local with respect to the up-stream host (for example, the
+ message originated from the up-stream host itself), REMOTE for all other
+ mail, or [UNAVAILABLE] when the information is unavailable. The down-stream
+ MTA may decide to enable features such as header munging or address
+ qualification with mail from local sources but not other sources.
+
+Note 1: an attribute-value element must not be longer than 255 characters
+(specific attributes may impose shorter lengths). After xtext decoding,
+attribute values must not contain control characters, non-ASCII characters,
+whitespace, or other characters that are special in message headers.
+
+Note 2: DNS hostnames can be up to 255 characters long. The XFORWARD client
+implementation must not send XFORWARD commands that exceed the 512 character
+limit for SMTP commands.
+
+Note 3: [UNAVAILABLE] may be specified in upper case, lower case or mixed case.
+
+Note 4: Postfix implementations prior to version 2.3 do not xtext encode
+attribute values. Servers that wish to interoperate with these older
+implementations should be prepared to receive unencoded information.
+
+XXFFOORRWWAARRDD SSeerrvveerr ooppeerraattiioonn
+
+The server maintains a set of XFORWARD attributes with forwarded information,
+in addition the current SMTP session attributes. Normally, all XFORWARD
+attributes are in the undefined state, and the server uses the current SMTP
+session attributes for logging purposes.
+
+Upon receipt of an initial XFORWARD command, the SMTP server initializes all
+XFORWARD attributes to [UNAVAILABLE]. With each valid XFORWARD command, the
+server updates XFORWARD attributes with the specified values.
+
+The server must not mix client attributes from XFORWARD with client attributes
+from the current SMTP session.
+
+At the end of each MAIL FROM transaction (i.e. RSET or DOT), the server resets
+all XFORWARD attributes to the undefined state, and is ready to receive another
+initial XFORWARD command.
+
+XXFFOORRWWAARRDD SSeerrvveerr rreeppllyy ccooddeess
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ |CCooddee|MMeeaanniinngg |
+ |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |250 |success |
+ |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |421 |unable to proceed, disconnecting|
+ |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |501 |bad command parameter syntax |
+ |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |503 |mail transaction in progress |
+ |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+ |550 |insufficient authorization |
+ |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
+XXFFOORRWWAARRDD EExxaammppllee
+
+In the following example, information sent by the client is shown in bold font.
+
+ 220 server.example.com ESMTP Postfix
+ EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+ 250-server.example.com
+ 250-PIPELINING
+ 250-SIZE 10240000
+ 250-VRFY
+ 250-ETRN
+ 250-XFORWARD NAME ADDR PROTO HELO
+ 250 8BITMIME
+ XXFFOORRWWAARRDD NNAAMMEE==ssppiikkee..ppoorrccuuppiinnee..oorrgg AADDDDRR==116688..110000..118899..22 PPRROOTTOO==EESSMMTTPP
+ 250 Ok
+ XXFFOORRWWAARRDD HHEELLOO==ssppiikkee..ppoorrccuuppiinnee..oorrgg
+ 250 Ok
+ MMAAIILL FFRROOMM::<>
+ 250 Ok
+ RRCCPPTT TTOO::<>
+ 250 Ok
+ DDAATTAA
+ 354 End data with .
+ .. .. ..mmeessssaaggee ccoonntteenntt.. .. ..
+ ..
+ 250 Ok: queued as 3CF6B2AAE8
+ QQUUIITT
+ 221 Bye
+
+SSeeccuurriittyy
+
+The XFORWARD command changes audit trails. Use of this command must be
+restricted to authorized clients.
+
+SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg
+
+SMTP connection caching makes it possible to deliver multiple messages within
+the same SMTP session. The XFORWARD attributes are reset after the MAIL FROM
+transaction completes (after RSET or DOT), so there is no risk of information
+leakage.
+
+RReeffeerreenncceess
+
+Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891,
+January 1996.
+
diff --git a/RELEASE_NOTES b/RELEASE_NOTES
new file mode 100644
index 0000000..0b51dee
--- /dev/null
+++ b/RELEASE_NOTES
@@ -0,0 +1,102 @@
+This is the Postfix 3.1 (experimental) release.
+
+The stable Postfix release is called postfix-3.0.x where 3=major
+release number, 0=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-3.1-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 2.11 or earlier, read RELEASE_NOTES-3.0
+before proceeding.
+
+Incompatible change with Postfix snapshot 20150721
+--------------------------------------------------
+
+As of the middle of 2015, all supported Postfix releases no longer
+enable "export" grade ciphers for opportunistic TLS, and no longer
+use the deprecated SSLv2 and SSLv3 protocols for mandatory or
+opportunistic TLS.
+
+These changes are very unlikely to cause problems with server-to-server
+communication over the Internet, but they may result in interoperability
+problems with ancient client or server implementations on internal
+networks. To address this problem, you can revert the changes with:
+
+Postfix SMTP client settings:
+
+ lmtp_tls_ciphers = export
+ smtp_tls_ciphers = export
+ lmtp_tls_protocols = !SSLv2
+ smtp_tls_protocols = !SSLv2
+ lmtp_tls_mandatory_protocols = !SSLv2
+ smtp_tls_mandatory_protocols = !SSLv2
+
+Postfix SMTP server settings:
+
+ smtpd_tls_ciphers = export
+ smtpd_tls_protocols =
+ smtpd_tls_mandatory_protocols = !SSLv2
+
+These settings, if put in main.cf, affect all Postfix SMTP client
+or server communication, which may be undesirable. To be more
+selective, use "-o name=value" parameter overrides on specific
+services in master.cf. Execute the command "postfix reload" to make
+the changes effective.
+
+Major changes with snaphot 20150710
+===================================
+
+postscreen support for the TTL of DNSBL and DNSWL lookup results
+----------------------------------------------------------------
+
+Historically, the default setting "postscreen_dnsbl_ttl = 1h" assumes
+that a "not found" result from a DNSBL server will be valid for one
+hour. This may have been adequate five years ago when postscreen
+was first implemented, but nowadays, that one hour can result in
+missed opportunities to block new spambots.
+
+To address this, postscreen now respects the TTL of DNSBL "not
+found" replies, as well as the TTL of DNSWL replies (both "found"
+and "not found"). The TTL for a "not found" reply is determined
+according to RFC 2308 (the TTL of an SOA record in the reply).
+
+Support for DNSBL or DNSWL reply TTL values is controlled by two
+configuration parameters:
+
+postscreen_dnsbl_min_ttl (default: 60 seconds).
+
+ This parameter specifies a minimum for the amount of time that
+ a DNSBL or DNSWL result will be cached in the postscreen_cache_map.
+ This prevents an excessive number of postscreen cache updates
+ when a DNSBL or DNSWL server specifies a very small reply TTL.
+
+postscreen_dnsbl_max_ttl (default: $postscreen_dnsbl_ttl or 1 hour)
+
+ This parameter specifies a maximum for the amount of time that
+ a DNSBL or DNSWL result will be cached in the postscreen_cache_map.
+ This prevents cache pollution when a DNSBL or DNSWL server
+ specifies a very large reply TTL.
+
+The postscreen_dnsbl_ttl parameter is now obsolete, and has become
+a default value for the new postscreen_dnsbl_max_ttl parameter.
+
+Destination-independent delivery rate delay
+-------------------------------------------
+
+Support to enforce a destination-independent delay between email
+deliveries. The following example inserts 20 seconds of delay
+between deliveries with the SMTP transport, limiting the delivery
+rate to at most three messages per minute.
+
+/etc/postfix/main.cf:
+ smtp_transport_rate_delay = 20s
+
+For details, see the description of default_transport_rate_delay
+and transport_transport_rate_delay in the postconf(5) manpage.
diff --git a/RELEASE_NOTES-1.0 b/RELEASE_NOTES-1.0
new file mode 100644
index 0000000..9fcf519
--- /dev/null
+++ b/RELEASE_NOTES-1.0
@@ -0,0 +1,746 @@
+This is the first official Postfix release that is not called BETA.
+May it help the people who cannot get BETA software past their
+management.
+
+Release 20010228 differs from snapshot 20010228 in that the virtual
+delivery agent and nqmgr queue manager are left out. That software
+will become part of the official release when it has not changed
+in a while.
+
+In the text below, incompatible changes are labeled with the Postfix
+version that introduced the change. If you upgrade from a later
+Postfix version, then you do not have to worry about that particular
+incompatibility.
+
+Major incompatible changes with release-20010228
+================================================
+
+[snapshot-20010225] POSTFIX NO LONGER RELAYS MAIL FOR CLIENTS IN
+THE ENTIRE CLASS A/B/C NETWORK. To get the old behavior, specify
+"mynetworks_style = class" in the main.cf file. The default
+(mynetworks_style = subnet) is to relay for clients in the local
+IP subnet. See conf/main.cf.
+
+[snapshot-20001005, snapshot-20010225] You must execute "postfix
+stop" before installing this release. Some recommended parameter
+settings have changed, and a new entry must be added to the master.cf
+file before you can start Postfix again.
+
+1 - The recommended Postfix configuration no longer uses flat
+ directories for the "incoming" "active", "bounce", and "defer"
+ queue directories. The "flush" directory for the new "flush"
+ service directory should not be flat either.
+
+ Upon start-up, Postfix checks if the hash_queue_names configuration
+ parameter is properly set up, and will add any queue directory
+ names that are missing.
+
+2 - In order to improve performance of one-to-one mail deliveries
+ the queue manager will now look at up to 10000 queue files
+ (was: 1000). The default qmgr_message_active_limit setting
+ was changed accordingly.
+
+ If you have a non-default qmgr_message_active_limit in main.cf,
+ you may want adjust it.
+
+3 - The new "flush" service needs to be configured in master.cf.
+
+ Upon start-up, Postfix checks if the new "flush" service is
+ configured in the master.cf file, and will add an entry if it
+ is missing.
+
+Should you wish to back out to a previous Postfix release there is
+no need to undo the above queue configuration changes.
+
+[snapshot-20000921] The protocol between queue manager and delivery
+agents has changed. This means that you cannot mix the Postfix
+queue manager or delivery agents with those of Postfix versions
+prior to 20000921. This change does not affect Postfix queue file
+formats.
+
+[snapshot-20000529] This release introduces an incompatible queue
+file format change ONLY when content filtering is enabled (see text
+in FILTER_README). Old Postfix queue files will work fine, but
+queue files with the new content filtering info will not work with
+Postfix versions before 20000529. Postfix logs a warning and moves
+incompatible queue files to the "corrupt" mail queue subdirectory.
+
+Minor incompatible changes with release-20010228
+================================================
+
+[snapshot-20010225] The incoming and deferred queue directories
+are now hashed by default. This improves the performance considerably
+under heavy load, at the cost of a small but noticeable slowdown
+when one runs "mailq" on an unloaded system.
+
+[snapshot-20010222] Postfix no longer automatically delivers
+recipients one at a time when their domain is listed in $mydestination.
+This change solves delivery performance problems with delivery via
+LMTP, with virus scanning, and with firewall relays that forward
+all mail for $mydestination to an inside host.
+
+The "one recipient at a time" delivery behavior is now controlled
+by the per-transport recipient limit (xxx_destination_recipient_limit,
+where xxx is the name of the delivery mechanism). This parameter
+controls the number of recipients that can be sent in one delivery
+(surprise).
+
+The setting of the per-transport recipient limit also controls the
+meaning of the per-transport destination concurrency limit (named
+xxx_destination_concurrency_limit, where xxx is again the name of
+the delivery mechanism):
+
+ 1) When the per-transport recipient limit is 1 (i.e., send one
+ recipient per delivery), the per-transport destination concurrency
+ limit controls the number of simultaneous deliveries to the
+ same recipient. This is the default behavior for delivery via
+ the Postfix local delivery agent.
+
+ 2) When the per-transport recipient limit is > 1 (i.e., send
+ multiple recipients per delivery), the per-transport destination
+ concurrency limit controls the number of simultaneous deliveries
+ to the same domain. This is the default behavior for all other
+ Postfix delivery agents.
+
+[snapshot-20010128] The Postfix local delivery agent now enforces
+mailbox file size limits (default: mailbox_size_limit = 51200000).
+This limit affects all file write access by the local delivery
+agent or by a process run by the local delivery agent. The purpose
+of this parameter is to act as a safety for run-away software. It
+cannot be a substitute for a file quota management system. Specify
+a limit of 0 to disable.
+
+[snapshot-20010128] REJECT in header/body_checks is now flagged as
+policy violation rather than bounce, for consistency in postmaster
+notifications.
+
+[snapshot-20010128] The default RBL (real-time blackhole lists)
+domain examples have been changed from *.vix.com to *.mail-abuse.org.
+
+[snapshot-20001210] Several interfaces of libutil and libglobal
+routines have changed. This may break third-party code written
+for Postfix. In particular, the safe_open() routine has changed,
+the way the preferred locking method is specified in the sys_defs.h
+file, as well as all routines that perform file locking. When
+compiling third-party code written for Postfix, the incompatibilities
+will be detected by the compiler provided that #include file
+dependencies are properly maintained.
+
+[snapshot-20001210] When delivering to /file/name (as directed in
+an alias or .forward file), the local delivery agent now logs a
+warning when it is unable to create a /file/name.lock file. Mail
+is still delivered as before.
+
+[snapshot-20001210] The "sun_mailtool_compatibility" feature is
+going away (a compatibility mode that turns off kernel locks on
+mailbox files). It still works, but a warning is logged. Instead
+of using "sun_mailtool_compatibility", specify the mailbox locking
+strategy as "mailbox_delivery_lock = dotlock".
+
+[snapshot-20001210] The Postfix SMTP client now skips SMTP server
+replies that do not start with "CODE SPACE" or with "CODE HYPHEN"
+and flags them as protocol errors. Older Postfix SMTP clients
+silently treated "CODE TEXT" as "CODE SPACE TEXT", i.e. as a valid
+SMTP reply.
+
+[snapshot-20001121] On RedHat Linux 7.0, you must install the
+db3-devel RPM before you can compile the Postfix source code.
+
+[snapshot-20000924] The postmaster address in the "sorry" text at
+the top of bounced mail is now just postmaster, not postmaster@machine.
+The idea is to refer users to their own postmaster.
+
+[snapshot-20000921] The notation of [host:port] in transport tables
+etc. is going away but it is still supported. The preferred form
+is now [host]:port. This change is necessary to support IPV6
+address forms which use ":" as part of a numeric IP address. In a
+future release, Postfix will log a warning when it encounters the
+[host:port] form.
+
+[snapshot-20000921] In mail headers, Errors-To:, Reply-To: and
+Return-Receipt: addresses are now rewritten as a sender address
+(was: recipient).
+
+[snapshot-20000921] Postfix no longer inserts Sender: message
+headers.
+
+[snapshot-20000921] The queue manager now logs the original number
+of recipients when opening a queue file (example: from=<>, size=3502,
+nrcpt=1).
+
+[snapshot-20000921] The local delivery agent no longer appends a
+blank line to mail that is delivered to external command.
+
+[snapshot-20000921] The pipe delivery agent no longer appends a
+blank line when the F flag is specified (in the master.cf file).
+Specify the B flag if you need that blank line.
+
+[snapshot-20000507] As required by RFC 822, Postfix now inserts a
+generic destination message header when no destination header is
+present. The text is specified via the undisclosed_recipients_header
+configuration parameter (default: "To: undisclosed-recipients:;").
+
+[snapshot-20000507] The Postfix sendmail command treats a line with
+only `.' as the end of input, for the sake of sendmail compatibility.
+To disable this feature, specify the sendmail-compatible `-i' or
+`-oi' flags on the sendmail command line.
+
+[snapshot-20000507] For the sake of Sendmail compatibility, the
+Postfix SMTP client skips over SMTP servers that greet with a 4XX
+or 5XX reply code, treating them as unreachable servers. To obtain
+prior behavior (4XX=retry, 5XX=bounce), specify "smtp_skip_4xx_greeting
+= no" and "smtp_skip_5xx_greeting = no".
+
+Major changes with release-20010228
+===================================
+
+Postfix produces DSN formatted bounced/delayed mail notifications.
+The human-readable text still exists, so that users will not have
+to be unnecessarily confused by all the ugliness of RFC 1894. Full
+DSN support will be later.
+
+This release introduces full content filtering through an external
+process. This involves an incompatible change in queue file format.
+Mail is delivered to content filtering software via an existing
+mail delivery agent, and is re-injected into Postfix via an existing
+mail submission agent. See examples in the FILTER_README file.
+Depending on how the filter is implemented, you can expect to lose
+a factor of 2 to 4 in delivery performance of SMTP transit mail,
+more if the content filtering software needs lots of CPU or memory.
+
+Specify "body_checks = regexp:/etc/postfix/body_checks" for a quick
+and dirty emergency content filter that looks at non-header lines
+one line at a time (including MIME headers inside the message body).
+Details in conf/sample-filter.cf.
+
+The header_checks and body_checks features can be used to strip
+out unwanted data. Specify IGNORE on the right-hand side and the
+data will disappear from the mail.
+
+Support for SASL (RFC 2554) authentication in the SMTP server and
+in the SMTP and LMTP clients. See the SASL_README file for more
+details. This file still needs better examples.
+
+Postfix now ships with an LMTP delivery agent that can deliver over
+local/remote TCP sockets and over local UNIX-domain sockets. The
+LMTP_README file gives example, but still needs to be revised.
+
+Fast "ETRN" and "sendmail -qR". Postfix maintains per-destination
+logfiles with information about what mail is queued for selected
+destinations. See the file ETRN_README for details.
+
+The mailbox locking style is now fully configurable at runtime.
+The new configuration parameter is called "mailbox_delivery_lock".
+Depending on the operating system type, mailboxes can be locked
+with one or more of "flock", "fcntl" or "dotlock". The command
+"postconf -l" shows the available locking styles. The default
+mailbox locking style is system dependent. This change affects
+all mailbox and all "/file/name" deliveries by the Postfix local
+delivery agent.
+
+Minor changes with release-20010228
+===================================
+
+You can now specify multiple SMTP destinations in the relayhost
+and fallback_relay configuration parameters. The destinations are
+tried in the specified order. Specify host or host:port (perform
+MX record lookups), [host] or [host]:port (no MX record lookups),
+[address] or [address]:port (numerical IP address).
+
+The "mailbox_transport" and "fallback_transport" parameters now
+understand the form "transport:nexthop", with suitable defaults
+when either transport or nexthop are omitted, just like in the
+Postfix transport map. This allows you to specify for example,
+"mailbox_transport = lmtp:unix:/file/name".
+
+The local_transport and default_transport configuration parameters
+can now be specified in transport:destination notation, just like
+the mailbox_transport and fallback_transport parameters. The
+:destination part is optional. However, these parameters take only
+one destination, unlike relayhost and fallback-relay which take
+any number of destinations.
+
+More general virtual domain support. Postfix now supports both
+Sendmail-style virtual domains and Postfix-style virtual domains.
+Details and examples are given in the revised virtual manual page.
+
+- With Sendmail-style virtual domains, local users/aliases/mailing
+ lists are visible as localname@virtual.domain. This is convenient
+ if you want to host mailing lists under virtual domains.
+
+- With Postfix-style virtual domains, local users/aliases/mailing
+ lists are not visible as localname@virtual.domain. Each virtual
+ domain has its own separate name space.
+
+More general "soft bounce" feature. Specify "soft_bounce = yes"
+in main.cf to prevent the SMTP server from bouncing mail while you
+are testing configurations. Until this release the SMTP server was
+not aware of soft bounces.
+
+Workarounds for non-standard RFC 2554 (AUTH command) implementations.
+Specify "broken_sasl_auth_clients = yes" to enable SMTP server
+support for old Microsoft client applications. The Postfix SMTP
+client supports non-standard RFC 2554 servers by default.
+
+All time-related configuration parameters now accept a one-letter
+suffix to indicate the time unit (s: second, m: minute, h: hour,
+d: day, w: week). The exceptions are the LDAP and MYSQL modules
+which are maintained separately.
+
+New "import_environment" and "export_environment" configuration
+parameters provide explicit control over what environment variables
+Postfix will import, and what environment variables Postfix will
+pass on to a non-Postfix process.
+
+In order to improve performance of one-to-one deliveries, Postfix
+by default now looks at up to 10000 messages at a time (was: 1000).
+
+Specify "syslog_facility = log_local1" etc. to separate the logging
+from multiple Postfix instances. However, a non-default logging
+facility takes effect only after process initialization. Errors
+during command-line parsing are still logged with the default syslog
+facility, as are errors while processing the main.cf file.
+
+Postfix now strips out Content-Length: headers in incoming mail to
+avoid confusion in mail user agents.
+
+Specify "require_home_directory = yes" to prevent mail from being
+delivered to a user whose home directory is not mounted. This
+feature is implemented by the Postfix local delivery agent.
+
+The pipe mailer has a size limit (size=nnn) command-line argument.
+
+The pipe delivery agent has a configurable end-of-line attribute.
+Specify "pipe ... eol=\r\n" for delivery mechanisms that require
+CRLF record delimiters. The eol attribute understands the following
+C-style escape sequences: \a \b \f \n \r \t \v \nnn \\.
+
+In master.cf you can selectively override main.cf configuration
+parameters, for example: "smtpd -o myhostname=foo.com".
+
+In main.cf, specify "smtp_bind_address=x.x.x.x" to bind SMTP
+connections to a specific local interface. Or override the default
+setting in master.cf with "smtp -o smtp_bind_address=x.x.x.x".
+For now, you must specify a numeric IP address.
+
+Questionable feature: with "smtp_always_send_ehlo = yes", the SMTP
+client sends EHLO regardless of the content of the SMTP server's
+greeting.
+
+Specify "-d key" to postalias or postmap in order to remove one
+key. This still needs to be generalized to multi-key removal (e.g.,
+read keys from stdin).
+
+Comments in Postfix configuration files no longer contain troff
+formatting codes. The text is now generated from prototype files
+in a new "proto" subdirectory.
+
+Major changes with postfix-19991231:
+====================================
+
+- It is now much more difficult to configure Postfix as an open
+relay. The SMTP server requires that "smtpd_recipient_restrictions"
+contains at least one restriction that by default refuses mail (as
+is the default). There were too many accidents with changes to
+the UCE restrictions.
+
+- The relay_domains parameter no longer needs to contain $virtual_maps.
+
+- Overhauled FAQ (html/faq.html) with many more examples.
+
+- Updated UCE documentation (html/uce.html) with more examples.
+More UCE configuration examples in sample configuration files.
+
+- Several little improvements to the installation procedure:
+relative symlinks, configurable directory for scratch files so the
+installation can be done without write access to the build tree.
+
+- Updated LDAP client code (John Hensley).
+
+- Updated mysql client code (Scott Cotton).
+
+- The SMTP server now rejects mail for unknown users in virtual
+domains that are defined by Postfix virtual maps.
+
+- The SMTP server can reject mail for unknown local users. Specify
+"local_recipient_maps = $alias_maps, unix:passwd.byname" if your
+local mail is delivered by a UNIX-style local delivery agent. See
+example in conf/main.cf.
+
+- Use "disable_vrfy_command = yes" to disable the SMTP VRFY command.
+This prevents some forms of address harvesting.
+
+- The sendmail "-f" option now understands and even understands
+forms with RFC 822-style comments.
+
+- New "qmgr_fudge_factor" parameter allows you to balance mailing
+list performance against response time for one-to-one mail. The
+fudge factor controls what percentage of delivery resources Postfix
+will devote to one message. With 100%, delivery of one message
+does not begin before delivery of the previous message is completed.
+This is good for list performance, bad for one-to-one mail. With
+10%, response time for one-to-one mail improves much, but list
+performance suffers: in the worst case, people near the start of a
+mailing list get a burst of postings today, while people near the
+end of the list get that same burst of postings a whole day later.
+
+- It is now relatively safe to configure 550 status codes for the
+main.cf unknown_address_reject_code or unknown_client_reject_code
+parameters. The SMTP server now always sends a 450 (try again)
+reply code when an UCE restriction fails due to a soft DNS error,
+regardless of what main.cf specifies.
+
+- The RBL checks now show the content of TXT records (Simon J Mudd).
+
+- The Postfix SMTP server now understands a wider range of illegal
+address forms in MAIL FROM and RCPT TO commands. In order to disable
+illegal forms, specify "strict_rfc821_envelopes = yes". This also
+disables support for MAIL FROM and RCPT TO addresses without <>.
+
+- Per-client/helo/sender/recipient UCE restrictions (fully-recursive
+UCE restriction parser). See the RESTRICTION_CLASS file for details.
+
+- Use "postmap -q key" or "postalias -q key" for testing Postfix
+lookup tables or alias files.
+
+- Use "postconf -e name=value..." to edit the main.cf file. This
+is easier and safer than editing the main.cf file by hand. The
+edits are done on a temporary copy that is renamed into place.
+
+- Use "postconf -m" to display all supported lookup table types
+(Scott Cotton).
+
+- New "permit_auth_destination" UCE restriction for finer-grained
+access control (Jesper Skriver).
+
+Incompatible changes with postfix-19990906
+==========================================
+
+- On systems that use user.lock files to protect system mailboxes
+against simultaneous updates, Postfix now uses /file/name.lock
+files while delivering to files specified in aliases/forward/include
+files. This is a no-op when the recipient lacks directory write
+permission.
+
+- The LDAP client code no longer looks up a name containing "*"
+because it could be abused. See the LDAP_README file for how to
+restore previous behavior.
+
+- The Postfix to PCRE interface now expects PCRE version 2.08.
+Postfix is no longer compatible with PCRE versions prior to 2.06.
+
+Major changes with postfix-19990906
+===================================
+
+Several bugfixes, none related to security. See the HISTORY file
+for a complete list of changes.
+
+- Postfix is now distributed under IBM Public License Version 1.0
+which does not carry the controversial termination clause. The new
+license does have a requirement that contributors make source code
+available.
+
+- INSTALL.sh install/upgrade procedure that replaces existing
+programs and shell scripts instead of overwriting them, and that
+leaves existing queue files and configuration files alone.
+
+- The ugly Delivered-To: header can now be turned off selectively.
+The default setting is: "prepend_delivered_header = command, file,
+forward". Turning off the Delivered-To: header when forwarding
+mail is not recommended.
+
+- mysql client support by Scott Cotton and Joshua Marcus, Internet
+Consultants Group, Inc. See the file MYSQL_README for instructions.
+
+- reject_unauth_destination SMTP recipient restriction that rejects
+destinations not in $relay_domains. Unlike the check_relay_domains
+restriction, reject_unauth_destination ignores the client hostname.
+By Lamont Jones of Hewlett-Packard.
+
+- reject_unauth_pipelining SMTP *anything* restriction to stop mail
+from spammers that improperly use SMTP command pipelining to speed
+up their deliveries.
+
+- Postfix "sendmail" now issues a warning and drops privileges if
+installed set-uid root.
+
+- No more duplicate delivery when "postfix reload" is immediately
+followed by "sendmail -q".
+
+- No more "invalid argument" errors when a Postfix daemon opens a
+DB/DBM file while some other process is changing the file.
+
+- Portability to the Mac OS X Server, Reliant Unix, AIX 3.2.5 and
+Ultrix 4.3.
+
+Incompatible changes with postfix-19990601:
+===========================================
+
+- The SMTP server now delays all UCE restrictions until the RCPT
+TO, VRFY or ETRN command. This makes the restrictions more useful,
+because many SMTP clients do not expect negative responses earlier
+in the protocol. In order to restore the old behavior, specify
+"smtpd_delay_reject = no" in /etc/postfix/main.cf.
+
+- The Postfix local delivery agent no longer automatically propagates
+address extensions to aliases/include/forward addresses. Specify
+"propagate_unmatched_extensions = canonical, virtual, alias, forward,
+include" to restore the old behavior.
+
+- The Postfix local delivery agent no longer does $name expansion
+on words found in the mailbox_command configuration parameter. This
+makes it easier to specify shell syntax. See conf/main.cf.
+
+- The luser_relay syntax has changed. You can specify one address;
+it is subjected to $user, etc. expansions. See conf/main.cf.
+
+- File system reorganization: daemon executables are now in the
+libexec subdirectory, command executables in the bin subdirectory.
+The INSTALL instructions now recommend installing daemons and
+commands into separate directories.
+
+Major changes with postfix-19990601:
+=====================================
+
+- New USER, EXTENSION, LOCAL, DOMAIN and RECIPIENT environment
+variables for delivery to command (including mailbox_command) by
+the local delivery agent. As you might expect, the information is
+censored. The list of acceptable characters is specified with the
+command_expansion_filter configuration parameter. Unacceptable
+characters are replaced by underscores. See html/local.8.html.
+
+- Specify "forward_path = /var/forward/$user" to avoid looking up
+.forward files in user home directories. The default value is
+$home/.forward$recipient_delimiter$extension, $home/.forward.
+Initial code by Philip A. Prindeville, Mirapoint, Inc., USA.
+
+- Conditional $name expansion in forward_path and luser_relay.
+Available names are: $user (bare user name) $shell (user login
+shell), $home (user home directory), $local (everything to the left
+of @), $extension (optional address extension), $domain (everything
+to the right of @), $recipient (the complete address) and
+$recipient_delimiter. A simple $name expands as usual. ${name?value}
+expands to value when $name is defined. ${name:value} expands to
+value when $name is not defined. With ${name?value} and ${name:value},
+the value is subject to another iteration of $name expansion.
+
+- POSIX regular expression support, enabled by default on 4.4BSD,
+LINUX, HP-UX, and Solaris 2.5 and later. See conf/sample-regexp.cf.
+Initial code by Lamont Jones, Hewlett-Packard, borrowing heavily
+from the PCRE implementation by Andrew McNamara, connect.com.au
+Pty. Ltd., Australia.
+
+- Regular expression checks for message headers. This requires
+support for POSIX or for PCRE regular expressions. Specify
+"header_checks = regexp:/file/name" or "header_checks = pcre:/file/name",
+and specify "/^header-name: badstuff/ REJECT" in the pattern file
+(patterns are case-insensitive by default). Code by Lamont Jones,
+Hewlett-Packard. It is to be expected that full content filtering
+will be delegated to an external command.
+
+- Regular expression support for all lookup tables, including access
+control (full mail addresses only), address rewriting (canonical/virtual,
+full mail addresses only) and transport tables (full domain names
+only). However, regular expressions are not allowed for aliases,
+because that would open up security exposures.
+
+- Automatic detection of changes to DB or DBM lookup tables. This
+eliminates the need to run "postfix reload" after each change to
+the SMTP access table, or to the canonical, virtual, transport or
+aliases tables.
+
+- New error mailer. Specify ".domain.name error:domain is undeliverable"
+in the transport table to bounce mail for entire domains.
+
+- No more Postfix lockups on Solaris (knock on wood). The code no
+longer uses Solaris UNIX-domain sockets, because they are still
+broken, even with Solaris 7.
+
+- Workaround for the Solaris mailtool, which keeps an exclusive
+kernel lock on the mailbox while its window is not iconified (specify
+"sun_mailtool_compatibility = yes" in main.cf).
+
+- Questionable workaround for Solaris, which reportedly loses
+long-lived exclusive locks that are held by the master daemon.
+
+- New reject_unknown_{sender,recipient}_domain restrictions for
+sender and recipient mail addresses that distinguish between soft
+errors (always 450) and hard errors (unknown_address_reject_code,
+default 450).
+
+- MIME-encapsulated bounce messages, making it easier to recover
+bounced mail. Initial implementation by Philip A. Prindeville,
+Mirapoint, Inc., USA. Support for RFC 1892 (multipart/report) and
+RFC 1894 (DSN) will have to wait until Postfix internals have been
+revised to support RFC 1893.
+
+- Separately configurable "postmaster" addresses for single bounces
+(bounce_notice_recipient), double bounces (2bounce_notice_recipient),
+delayed mail (delay_notice_recipient), and for mailer error reports
+(error_notice_recipient). See conf/main.cf.
+
+- Questionable feature: specify "best_mx_transport = local" if
+this machine is the best MX host for domains not in mydestinations.
+
+Incompatible changes with postfix-19990317:
+===========================================
+
+- You MUST install the new version of /etc/postfix/postfix-script.
+
+- The pipe mailer "flags" syntax has changed. You now explicitly
+MUST specify the R flag in order to generate a Return-Path: message
+header (as needed by, for example, cyrus).
+
+Major changes with postfix-19990317:
+====================================
+
+A detailed record of changes is given in the HISTORY file.
+
+- Less postmaster mail. Undeliverable bounce messages (double
+bounces) are now discarded. Specify "notify_classes = 2bounce..."
+to get copies of double bounces. Specify "notify_classes = bounce..."
+to get copies of normal and double bounces.
+
+- Improved LDAP client code by John Hensley of Merit Network, USA.
+See LDAP_README for details.
+
+- Perl-compatible regular expression support for lookup maps by
+Andrew McNamara, connect.com.au Pty. Ltd., Australia.. Example:
+"check_recipient_access pcre:/etc/postfix/sample-pcre.cf". Regular
+expressions provide a powerful tool not only for SMTP access control
+but also for address rewriting. See PCRE_README for details.
+
+- Automatic notification of delayed mail (disabled by default).
+With "delay_warning_time = 4", Postfix informs senders when mail
+has not been delivered after 4 hours. Initial version of the code
+by Daniel Eisenbud, University of California at Berkeley. In order
+to get postmaster copies of such warnings, specify "notify_classes
+= delay...".
+
+- More configurable local delivery: "mail_spool_directory" to
+specify the UNIX mail spool directory; "mailbox_transport" to
+delegate all mailbox delivery to, for example, cyrus, and
+"fallback_transport" to delegate delivery of only non-UNIX users.
+And all this without losing local aliases and local .forward
+processing. See config/main.cf and config/master.cf.
+
+- Several changes to improve Postfix behavior under worst-case
+conditions (frequent Postfix restarts/reloads combined with lots
+if inbound mail, intermittent connectivity problems, SMTP servers
+that become comatose after receiving QUIT).
+
+- More NFS-friendly mailbox delivery. The local delivery agent
+now avoids using root privileges where possible.
+
+- For sites that do not receive mail at all, mydestination can now
+be an empty string. Be sure to set up a transport table entry to
+prevent mail from looping.
+
+- New "postsuper" utility to clean up stale files from Postfix
+queues.
+
+- Workaround for BSD select() collisions that cause performance
+problems on large BSD systems.
+
+- Several questionable but useful features to capture mail:
+"always_bcc = address" to capture a copy of every message that
+enters the system, and "luser_relay = address" to capture mail for
+unknown recipients (does not work when mailbox_transport or
+fallback_transport are being used).
+
+- Junk mail controls: new reject_non_fqdn_{hostname,sender,recipient}
+restrictions to reject non-FQDN arguments in HELO, MAIL FROM and
+RCPT TO commands, and stricter checking of numeric HELO arguments.
+
+- "fallback_relay" feature for sites that use DNS but that can't
+talk to the entire world. The fall-back relay gets the mail when
+a destination is not found in the DNS or when the destination is
+found but not reachable.
+
+- Several questionable controls that can help to keep mail going:
+specify "smtp_skip_4xx_greeting = yes" to skip SMTP servers that
+greet with 4XX, "ignore_mx_lookup_error = yes" to look up an A
+record when a DNS server does not respond to an MX query.
+
+Incompatible changes with postfix-beta-19990122-pl01:
+=====================================================
+
+None.
+
+Major changes with postfix-beta-19990122-pl01:
+==============================================
+
+- Restrict who may use ETRN and what domains may be specified.
+Example: "smtpd_etrn_restrictions = permit_mynetworks, reject".
+
+- BIFF notifications. For compatibility reasons this feature is
+on by default. Specify "biff = no" in main.cf if your machine has
+lots of shell users.
+
+- With "soft_bounce = yes", defer delivery instead of bouncing
+mail. This is a safety net for configuration errors with delivery
+agents. It has no effect on errors in virtual maps, canonical maps,
+or in junk mail restrictions.
+
+- Specify "owner_request_special = no" to turn off special treatment
+of owner-foo and foo-request addresses.
+
+Incompatible changes with postfix-beta-19990122:
+================================================
+
+- The syntax of the transport table has changed. An entry like:
+
+ customer.org smtp:[gateway.customer.org]
+
+ no longer forwards mail for anything.customer.org. For that you
+ need to specify:
+
+ customer.org smtp:[gateway.customer.org]
+ .customer.org smtp:[gateway.customer.org]
+
+ This change makes transport tables more compatible with
+ sendmail mailer tables.
+
+- The format of syslog records has changed. A client is now always
+logged as hostname[address]; the pickup daemon logs queue file uid
+and sender address.
+
+Major changes with postfix-beta-19990122:
+=========================================
+
+- Junk mail restrictions can now be postponed to the RCPT TO command.
+Specify: "smtpd_recipient_restrictions = reject_maps_rbl...".
+
+- More flexible interface for delivery to e.g., cyrus IMAP without
+need for PERL scripts to munge recipient addresses. In addition to
+$sender, $nexthop and $recipient, the pipe mailer now also supports
+$user, $extension and $mailbox.
+
+- New mail now has precedence over deferred mail, plus some other
+tweaks to make bulk mail go faster. But it ain't no cure for massive
+network outages.
+
+- Watchdog timer for systems that cause the Postfix queue manager
+to lock up, so it recovers without human intervention.
+
+- Delivery to qmail-style maildir files, which is good for NFS
+environments. Specify "home_mailbox = Maildir/", or specify
+/file/name/ in aliases or in .forward files. The trailing / is
+required to turn on maildir delivery.
+
+- Incremental updates of aliases and maps. Specify "postmap -i
+mapname" and it will read new entries from stdin.
+
+- Newaliases will now update more than one alias database.
+Specify the names with the main.cf "alias_database" parameter.
+
+- Address masquerading exceptions to prevent users from being
+masqueraded. Specify "masquerade_exceptions = root".
+
+- A pipelined SMTP client. Deliveries to Postfix, qmail, LSOFT,
+zmailer, and exim (once it's fixed) speed up by some 30% for short
+messages with one recipient, with more for multi-recipient mails.
+
+- Hook for local delivery to "|command" via the smrsh restricted
+shell, to restrict what commands may be used in .forward etc. files.
+Specify "local_command_shell = /some/where/smrsh -c".
diff --git a/RELEASE_NOTES-1.1 b/RELEASE_NOTES-1.1
new file mode 100644
index 0000000..c6f4611
--- /dev/null
+++ b/RELEASE_NOTES-1.1
@@ -0,0 +1,1087 @@
+In the text below, incompatible changes are labeled with the Postfix
+snapshot that introduced the change. If you upgrade from a later
+Postfix version, then you do not have to worry about that particular
+incompatibility.
+
+Official Postfix releases are called a.b.c where a=major release
+number, b=minor release number, c=patchlevel. Snapshot releases
+are now called a.b.c-yyyymmdd where yyyymmdd is the release date
+(yyyy=year, mm=month, dd=day). The mail_release_date configuration
+parameter contains the release date (both for official release and
+snapshot release). Patches change the patchlevel and the release
+date. Snapshots change only the release date, unless they include
+the same bugfixes as a patch release.
+
+Incompatible changes with Postfix version 1.1.0 (released 20020117)
+===================================================================
+
+Changes are listed in order of decreasing importance, not release
+date.
+
+[snapshot-20010709] This release introduces a new queue file record
+type that is used only for messages that actually use VERP (variable
+envelope return path) support. With this sole exception, the queue
+file format is entirely backwards compatible with the previous
+official Postfix release (20010228, a.k.a. Postfix 1.0.0).
+
+[snapshot-20020106] This release modifies the existing master.cf
+file. The local pickup service is now unprivileged, and the cleanup
+and flush service are now "public". Should you have to back out to
+a previous release, then you must 1) edit the master.cf file, make
+the pickup service "privileged", and make the cleanup and flush
+services "private"; 2) "chmod 755 /var/spool/postfix/public". To
+revert to a world-writable mail submission directory, "chmod 1733
+/var/spool/postfix/maildrop".
+
+[snapshot-20020106, snapshot-20010808, snapshot-20011103,
+snapshot-20011121] You must stop and restart Postfix because of
+incompatible changes in the local Postfix security model and in
+the Postfix internal protocols. Old and new components will not
+work together.
+
+[snapshot-20020106] Simpler local Postfix security model.
+
+- No world-writable maildrop directory. Postfix now always uses
+ the set-gid postdrop command for local mail submissions. The
+ local mail pickup daemon is now an unprivileged process.
+
+- No world-accessible pickup and queue manager server FIFOs.
+
+- New set-gid postqueue command for the queue list/flush operations
+ that used to implemented by the Postfix sendmail command.
+
+[snapshot-20020106..15] Simpler Postfix installation and upgrading.
+
+- All installation settings are now kept in the main.cf file, and
+ better default settings are now generated for system dependent
+ pathnames such as sendmail_path etc. The install.cf file is no
+ longer used, except when upgrading from an older Postfix version.
+
+- Non-default installation parameter settings can (but do not have
+ to) be specified on the "make install" or "make upgrade" command
+ line as name=value arguments.
+
+- New postfix-files database (in /etc/postfix) with (pathname,
+ owner, permission) information about all Postfix-related files.
+
+- New postfix-install script replaces the awkward INSTALL.sh script.
+ This is driven by the postfix-files database. It has better
+ support for building packages for distribution to other systems.
+ See PACKAGE_README for details.
+
+- New post-install script (in /etc/postfix) for post-installation
+ maintenance of directory/file permissions and ownership (this is
+ used by "postfix check"). Example:
+
+ # postfix stop
+ # post-install set-permissions mail_owner=username setgid_group=groupname
+ # postfix start
+
+[snapshot-20020106] Postfix will not run if it detects that the
+postfix user or group ID are shared with other accounts on the
+system. The checks aren't exhaustive (that would be too resource
+consuming) but should be sufficient to encourage packagers and
+developers to do the right thing. To fix the problem, use the above
+post-install command, after you have created the appropriate new
+mail_owner or setgid_group user or group IDs.
+
+[snapshot-20020106] If you run multiple Postfix instances on the
+same machine you now have to specify their configuration directories
+in the default main.cf file as "alternate_config_directories =
+/dir1 /dir2 ...". Otherwise, some Postfix commands will no longer
+work: the set-group ID postdrop command for mail submission and
+the set-group ID postqueue command for queue listing/flushing.
+
+[snapshot-20010808] The default setting for the maps_rbl_domains
+parameter is now "empty", because mail-abuse.org has become a
+subscription-based service. The names of the RBL parameters haven't
+changed.
+
+[snapshot-20020106] Postfix SMTP access maps will no longer return
+OK for non-local multi-domain recipient mail addresses (user@dom1@dom2,
+user%dom1@dom2, etcetera); the lookup now returns DUNNO (undetermined).
+Non-local multi-domain recipient addresses were already prohibited
+from matching the permit_mx_backup and the relay_domains-based
+restrictions.
+
+[snapshot-20011210] Stricter checking of Postfix chroot configurations.
+The Postfix startup procedure now warns if "system" directories
+(etc, bin, lib, usr) under the Postfix top-level queue directory
+are not owned by the super-user (usually the result of well-intended,
+but misguided, applications of "chown -R postfix /var/spool/postfix).
+
+[snapshot-20011008] The Postfix SMTP server now rejects requests
+with a generic "try again later" status (451 Server configuration
+error) when it detects an error in smtp_{client, helo, sender,
+recipient, etrn}_restrictions settings. More details about the
+problem are logged to the syslogd; sending such information to
+random clients would be inappropriate.
+
+[snapshot-20011008] Postfix no longer flushes the entire mail queue
+after receiving an ETRN request for a random domain name. Requests
+for domains that do not match $fast_flush_domains are now rejected
+instead.
+
+[snapshot-20011226] Postfix configuration file comments no longer
+continue on the next line when that next line starts with whitespace.
+This change avoids surprises, but it may cause unexpected behavior
+with existing, improperly formatted, configuration files. Caveat
+user. Comment lines are allowed to begin with whitespace. Multi-line
+input is no longer terminated by a comment line, by an all whitespace
+line, or by an empty line.
+
+[snapshot-20010714] Postfix delivery agents now refuse to create
+a missing maildir or mail spool subdirectory when its parent
+directory is world writable. This is necessary to prevent security
+problems with maildirs or with hashed mailboxes under a world
+writable mail spool directory.
+
+[snapshot-20010525] As per RFC 2821, the Postfix SMTP client now
+always sends EHLO at the beginning of an SMTP session. Specify
+"smtp_always_send_ehlo = no" for the old behavior, which is to send
+EHLO only when the server greeting banner contains the word ESMTP.
+
+[snapshot-20010525] As per RFC 2821, an EHLO command in the middle
+of an SMTP session resets the Postfix SMTP server state just like
+RSET. This behavior cannot be disabled.
+
+[snapshot-20010709] The SMTP client now by default breaks lines >
+2048 characters, to avoid mail delivery problems with fragile SMTP
+server software. To get the old behavior back, specify "smtp_break_lines
+= no" in the Postfix main.cf file.
+
+[snapshot-20010709] With recipient_delimiter=+ (or any character
+other than -) Postfix will now recognize address extensions even
+with owner-foo+extension addresses. This change was necessary to
+make VERP useful for mailing list bounce processing.
+
+[snapshot-20010610] The Postfix pipe delivery agent no longer
+automatically case-folds the expansion of $user, $extension or
+$mailbox command-line macros. Specify the 'u' flag to get the old
+behavior.
+
+[snapshot-20011210] The Postfix sendmail command no longer exits
+with status 1 when mail submission fails, but instead returns a
+sendmail-compatible status code as defined in /usr/include/sysexits.h.
+
+Major changes with Postfix version 1.1.0 (Released 20020117)
+============================================================
+
+Changes are listed in order of decreasing importance, not release
+date.
+
+The nqmgr queue manager is now bundled with Postfix. It implements
+a smarter scheduling strategy that allows ordinary mail to slip
+past mailing list mail, resulting in better response. This queue
+manager is expected to become the default queue manager shortly.
+
+[snapshot-20010709, snapshot-20010808] VERP (variable envelope
+return path) support. This is enabled by default, including in
+the SMTP server. See the VERP_README file for instructions. Specify
+"disable_verp_bounces = yes" to have Postfix send one RFC-standard,
+non-VERP, bounce report for multi-recipient mail, even when VERP
+style delivery was requested. This reduces the explosive behavior
+of bounces when sending mail to a list.
+
+[snapshot-20010709] QMQP server support, so that Postfix can be
+used as a backend mailer for the ezmlm-idx mailing list manager.
+You still need qmail to drive ezmlm and to process mailing list
+bounces. The QMQP service is disabled by default. To enable, follow
+the instructions in the QMQP_README file.
+
+[snapshot-20010709] You can now reject unknown virtual(8) recipients
+at the SMTP port by specifying a "domain.name whatever" entry in
+the tables specified with virtual_mailbox_maps, similar to Postfix
+virtual(5) domains. [virtual(8) is the Postfix virtual delivery
+agent, virtual(5) is the Postfix virtual map. The two implement
+virtual domains in a very different manner.]
+
+[snapshot-20011121] Configurable host/domain name wildcard matching
+behavior: choice between "pattern `domain.name' matches string
+`host.domain.name'" (this is to be deprecated in the future) and
+"pattern `.domain.name' matches string `host.domain.name'" (this
+is to be preferred in the future). The configuration parameter
+"parent_domain_matches_subdomains" specifies which Postfix features
+use the behavior that will become deprecated.
+
+[snapshot-20010808] Variable coupling between message receiving
+rates and message delivery rates. When the message receiving rate
+exceeds the message delivery rate, an SMTP server will pause for
+$in_flow_delay seconds before accepting a message. This delay
+gives Postfix a chance catch up and access the disk, while still
+allowing new mail to arrive. This feature currently has effect
+only when mail arrives via a small number of SMTP clients.
+
+[snapshot-20010610, snapshot-20011121, snapshot-20011210] Workarounds
+for a bug in old versions of the CISCO PIX firewall software that
+caused mail to be resent repeatedly. The workaround has no effect
+for other mail deliveries. The workaround is turned off when mail
+is queued for less than $smtp_pix_workaround_threshold_time seconds
+(default: 500 seconds) so that the workaround is normally enabled
+only for deferred mail. The delay before sending . is now
+controlled by the $smtp_pix_workaround_delay_time setting (default:
+10 seconds).
+
+[snapshot-20011226] Postfix will now do null address lookups in
+SMTPD access maps. If your access maps cannot store or look up
+null string key values, specify "smtpd_null_access_lookup_key =
+<>" and the null sender address will be looked up as <> instead.
+
+[snapshot-20011210] More usable virtual delivery agent, thanks to
+a new "static" map type by Jeff Miller that always returns its map
+name as the lookup result. This eliminates the need for per-recipient
+user ID and group ID tables. See the VIRTUAL_README file for more
+details.
+
+[snapshot-20011125] Anti-sender spoofing. New main.cf parameter
+smtpd_sender_login_maps that specifies the (SASL) login name that
+owns a MAIL FROM sender address. Specify a regexp table in order
+to require a simple one-to-one mapping. New SMTPD restriction
+reject_sender_login_mismatch that refuses a MAIL FROM address when
+$smtpd_sender_login_maps specifies an owner but the client is not
+(SASL) logged in as the MAIL FROM address owner, or when a client
+is (SASL) logged in but does not own the address according to
+$smtpd_sender_login_maps.
+
+[snapshot-20011121] The mailbox_command_maps parameter allows you
+to configure the external delivery command per user (local delivery
+agent only). This feature has precedence over the mailbox_command
+and home_mailbox settings.
+
+[snapshot-20011121] New "warn_if_reject" smtpd UCE restriction that
+only warns if the restriction that follows would reject mail. Look
+for file records that contain the string "reject_warning".
+
+[snapshot-20011127] New header/body_check result "WARN" to make
+Postfix log a warning about a header/body line without rejecting
+the content.
+
+[snapshot-20011103] In header/body_check files, REJECT can now be
+followed by text that is sent to the originator. That feature was
+stuck waiting for years, pending the internal protocol revision.
+
+[snapshot-20011008] The permit_mx_backup feature allows you to
+specify network address blocks via the permit_mx_backup_networks
+parameter. This requires that the primary MX hosts for the given
+destination match the specified network blocks. When no value is
+given for permit_mx_backup_networks, Postfix will accept mail
+whenever the local MTA is listed in the DNS as an MX relay host
+for a destination, even when you never gave permission to do so.
+
+[snapshot-20010709] Specify "mail_spool_directory = /var/mail/"
+(note the trailing "/" character) to enable maildir format for
+/var/mail/username.
+
+[snapshot-20010808] Finer control over address masquerading. The
+masquerade_classes parameter now controls header and envelope sender
+and recipient addresses. With earlier Postfix versions, address
+masquerading rewrote all addresses except for the envelope recipient.
+
+[snapshot-20010610] The pipe mail delivery agent now supports proper
+quoting of white space and other special characters in the expansions
+of the $sender and $recipient command-line macros. This was necessary
+for correct operation of the "simple" content filter, and is also
+recommended for delivery via UUCP or BSMTP.
+
+[snapshot-20010610] The pipe mail delivery agent now supports case
+folding the localpart and/or domain part of expansions of the
+$nexthop, $recipient, $user, $extension or $mailbox command-line
+macros. This is recommended for mail delivery via UUCP. Bug: $nexthop
+is always case folded because of problems in the queue manager
+code.
+
+[snapshot-20010525] This release contains many little revisions of
+little details in the light of the new RFC 2821 and RFC 2822
+standards. Changes that may affect interoperability are listed
+above under "incompatible changes". Other little details are
+discussed in comments in the source code.
+
+[snapshot-20010502] The Postfix SMTP client now by default randomly
+shuffles destination IP addresses of equal preference (whether
+obtained via MX lookup or otherwise). Reportedly, this is needed
+for sites that use Bernstein's dnscache program. Specify
+"smtp_randomize_addresses = no" to disable this behavior. Based on
+shuffling code by Aleph1.
+
+[snapshot-20011127] New parameter smtpd_noop_commands to specify
+a list of commands that the Postfix SMTP server treats as NOOP
+commands (no syntax check, no state change). This is a workaround
+for misbehaving clients that send unsupported commands such as
+ONEX.
+
+[snapshot-20010502] "postmap -q -" and "postmap -d -" read key
+values from standard input, which makes it easier to drive them
+from another program. The same feature was added to the postalias
+command.
+
+[snapshot-20010502] The postsuper command now has a command-line
+option to delete queue files. In principle this command can be
+used while Postfix is running, but there is a possibility of deleting
+the wrong queue file when Postfix deletes a queue file and reuses
+the queue ID for a new message. In that case, postsuper will delete
+the new message.
+
+[snapshot-20010525] The postsuper queue maintenance tool now renames
+files whose name (queue ID) does not match the message file inode
+number. This is necessary after a Postfix mail queue is restored
+from another machine or from backups. The feature is selected with
+the -s option, which is the default, and runs whenever Postfix is
+started.
+
+[snapshot-20010525] The postsuper queue maintenance tool has a new
+-r (requeue) option for subjecting some or all queue files to
+another iteration of address rewriting. This is useful after the
+virtual or canonical maps have changed.
+
+[snapshot-20010525] The postsuper queue maintenance tool was extended
+with options to read queue IDs from standard input. This makes the
+tool easier to drive from scripts.
+
+[snapshot-20010329] Better support for running multiple Postfix
+instances on one machine. Each instance can be recognized by its
+logging (defaults: "syslog_name = postfix", "syslog_facility =
+mail").
+
+Major incompatible changes with release-20010228 Patch 01 (a.k.a. Postfix 1.0.1)
+================================================================================
+
+This release changes the names of the "fast ETRN" logfiles with
+delayed mail per destination. These files are maintained by the
+Postfix "fast flush" daemon. The old scheme failed with addresses
+of the form user@[ip.address] and user@a.domain.name. In order to
+populate the new "fast ETRN" logfiles, execute the command "sendmail
+-q". The old "fast ETRN" logfiles go away by themselves (default:
+after 7 days).
+
+Major incompatible changes with release-20010228 (a.k.a. Postfix 1.0.0)
+=======================================================================
+
+[snapshot-20010225] POSTFIX NO LONGER RELAYS MAIL FOR CLIENTS IN
+THE ENTIRE CLASS A/B/C NETWORK. To get the old behavior, specify
+"mynetworks_style = class" in the main.cf file. The default
+(mynetworks_style = subnet) is to relay for clients in the local
+IP subnet. See conf/main.cf.
+
+[snapshot-20001005, snapshot-20010225] You must execute "postfix
+stop" before installing this release. Some recommended parameter
+settings have changed, and a new entry must be added to the master.cf
+file before you can start Postfix again.
+
+1 - The recommended Postfix configuration no longer uses flat
+ directories for the "incoming" "active", "bounce", and "defer"
+ queue directories. The "flush" directory for the new "flush"
+ service directory should not be flat either.
+
+ Upon start-up, Postfix checks if the hash_queue_names configuration
+ parameter is properly set up, and will add any queue directory
+ names that are missing.
+
+2 - In order to improve performance of one-to-one mail deliveries
+ the queue manager will now look at up to 10000 queue files
+ (was: 1000). The default qmgr_message_active_limit setting
+ was changed accordingly.
+
+ If you have a non-default qmgr_message_active_limit in main.cf,
+ you may want adjust it.
+
+3 - The new "flush" service needs to be configured in master.cf.
+
+ Upon start-up, Postfix checks if the new "flush" service is
+ configured in the master.cf file, and will add an entry if it
+ is missing.
+
+Should you wish to back out to a previous Postfix release there is
+no need to undo the above queue configuration changes.
+
+[snapshot-20000921] The protocol between queue manager and delivery
+agents has changed. This means that you cannot mix the Postfix
+queue manager or delivery agents with those of Postfix versions
+prior to 20000921. This change does not affect Postfix queue file
+formats.
+
+[snapshot-20000529] This release introduces an incompatible queue
+file format change ONLY when content filtering is enabled (see text
+in FILTER_README). Old Postfix queue files will work fine, but
+queue files with the new content filtering info will not work with
+Postfix versions before 20000529. Postfix logs a warning and moves
+incompatible queue files to the "corrupt" mail queue subdirectory.
+
+Minor incompatible changes with release-20010228
+================================================
+
+[snapshot-20010225] The incoming and deferred queue directories
+are now hashed by default. This improves the performance considerably
+under heavy load, at the cost of a small but noticeable slowdown
+when one runs "mailq" on an unloaded system.
+
+[snapshot-20010222] Postfix no longer automatically delivers
+recipients one at a time when their domain is listed in $mydestination.
+This change solves delivery performance problems with delivery via
+LMTP, with virus scanning, and with firewall relays that forward
+all mail for $mydestination to an inside host.
+
+The "one recipient at a time" delivery behavior is now controlled
+by the per-transport recipient limit (xxx_destination_recipient_limit,
+where xxx is the name of the delivery mechanism). This parameter
+controls the number of recipients that can be sent in one delivery
+(surprise).
+
+The setting of the per-transport recipient limit also controls the
+meaning of the per-transport destination concurrency limit (named
+xxx_destination_concurrency_limit, where xxx is again the name of
+the delivery mechanism):
+
+ 1) When the per-transport recipient limit is 1 (i.e., send one
+ recipient per delivery), the per-transport destination concurrency
+ limit controls the number of simultaneous deliveries to the
+ same recipient. This is the default behavior for delivery via
+ the Postfix local delivery agent.
+
+ 2) When the per-transport recipient limit is > 1 (i.e., send
+ multiple recipients per delivery), the per-transport destination
+ concurrency limit controls the number of simultaneous deliveries
+ to the same domain. This is the default behavior for all other
+ Postfix delivery agents.
+
+[snapshot-20010128] The Postfix local delivery agent now enforces
+mailbox file size limits (default: mailbox_size_limit = 51200000).
+This limit affects all file write access by the local delivery
+agent or by a process run by the local delivery agent. The purpose
+of this parameter is to act as a safety for run-away software. It
+cannot be a substitute for a file quota management system. Specify
+a limit of 0 to disable.
+
+[snapshot-20010128] REJECT in header/body_checks is now flagged as
+policy violation rather than bounce, for consistency in postmaster
+notifications.
+
+[snapshot-20010128] The default RBL (real-time blackhole lists)
+domain examples have been changed from *.vix.com to *.mail-abuse.org.
+
+[snapshot-20001210] Several interfaces of libutil and libglobal
+routines have changed. This may break third-party code written
+for Postfix. In particular, the safe_open() routine has changed,
+the way the preferred locking method is specified in the sys_defs.h
+file, as well as all routines that perform file locking. When
+compiling third-party code written for Postfix, the incompatibilities
+will be detected by the compiler provided that #include file
+dependencies are properly maintained.
+
+[snapshot-20001210] When delivering to /file/name (as directed in
+an alias or .forward file), the local delivery agent now logs a
+warning when it is unable to create a /file/name.lock file. Mail
+is still delivered as before.
+
+[snapshot-20001210] The "sun_mailtool_compatibility" feature is
+going away (a compatibility mode that turns off kernel locks on
+mailbox files). It still works, but a warning is logged. Instead
+of using "sun_mailtool_compatibility", specify the mailbox locking
+strategy as "mailbox_delivery_lock = dotlock".
+
+[snapshot-20001210] The Postfix SMTP client now skips SMTP server
+replies that do not start with "CODE SPACE" or with "CODE HYPHEN"
+and flags them as protocol errors. Older Postfix SMTP clients
+silently treated "CODE TEXT" as "CODE SPACE TEXT", i.e. as a valid
+SMTP reply.
+
+[snapshot-20001121] On RedHat Linux 7.0, you must install the
+db3-devel RPM before you can compile the Postfix source code.
+
+[snapshot-20000924] The postmaster address in the "sorry" text at
+the top of bounced mail is now just postmaster, not postmaster@machine.
+The idea is to refer users to their own postmaster.
+
+[snapshot-20000921] The notation of [host:port] in transport tables
+etc. is going away but it is still supported. The preferred form
+is now [host]:port. This change is necessary to support IPV6
+address forms which use ":" as part of a numeric IP address. In a
+future release, Postfix will log a warning when it encounters the
+[host:port] form.
+
+[snapshot-20000921] In mail headers, Errors-To:, Reply-To: and
+Return-Receipt: addresses are now rewritten as a sender address
+(was: recipient).
+
+[snapshot-20000921] Postfix no longer inserts Sender: message
+headers.
+
+[snapshot-20000921] The queue manager now logs the original number
+of recipients when opening a queue file (example: from=<>, size=3502,
+nrcpt=1).
+
+[snapshot-20000921] The local delivery agent no longer appends a
+blank line to mail that is delivered to external command.
+
+[snapshot-20000921] The pipe delivery agent no longer appends a
+blank line when the F flag is specified (in the master.cf file).
+Specify the B flag if you need that blank line.
+
+[snapshot-20000507] As required by RFC 822, Postfix now inserts a
+generic destination message header when no destination header is
+present. The text is specified via the undisclosed_recipients_header
+configuration parameter (default: "To: undisclosed-recipients:;").
+
+[snapshot-20000507] The Postfix sendmail command treats a line with
+only `.' as the end of input, for the sake of sendmail compatibility.
+To disable this feature, specify the sendmail-compatible `-i' or
+`-oi' flags on the sendmail command line.
+
+[snapshot-20000507] For the sake of Sendmail compatibility, the
+Postfix SMTP client skips over SMTP servers that greet with a 4XX
+or 5XX reply code, treating them as unreachable servers. To obtain
+prior behavior (4XX=retry, 5XX=bounce), specify "smtp_skip_4xx_greeting
+= no" and "smtp_skip_5xx_greeting = no".
+
+Major changes with release-20010228
+===================================
+
+Postfix produces DSN formatted bounced/delayed mail notifications.
+The human-readable text still exists, so that users will not have
+to be unnecessarily confused by all the ugliness of RFC 1894. Full
+DSN support will be later.
+
+This release introduces full content filtering through an external
+process. This involves an incompatible change in queue file format.
+Mail is delivered to content filtering software via an existing
+mail delivery agent, and is re-injected into Postfix via an existing
+mail submission agent. See examples in the FILTER_README file.
+Depending on how the filter is implemented, you can expect to lose
+a factor of 2 to 4 in delivery performance of SMTP transit mail,
+more if the content filtering software needs lots of CPU or memory.
+
+Specify "body_checks = regexp:/etc/postfix/body_checks" for a quick
+and dirty emergency content filter that looks at non-header lines
+one line at a time (including MIME headers inside the message body).
+Details in conf/sample-filter.cf.
+
+The header_checks and body_checks features can be used to strip
+out unwanted data. Specify IGNORE on the right-hand side and the
+data will disappear from the mail.
+
+Support for SASL (RFC 2554) authentication in the SMTP server and
+in the SMTP and LMTP clients. See the SASL_README file for more
+details. This file still needs better examples.
+
+Postfix now ships with an LMTP delivery agent that can deliver over
+local/remote TCP sockets and over local UNIX-domain sockets. The
+LMTP_README file gives example, but still needs to be revised.
+
+Fast "ETRN" and "sendmail -qR". Postfix maintains per-destination
+logfiles with information about what mail is queued for selected
+destinations. See the file ETRN_README for details.
+
+The mailbox locking style is now fully configurable at runtime.
+The new configuration parameter is called "mailbox_delivery_lock".
+Depending on the operating system type, mailboxes can be locked
+with one or more of "flock", "fcntl" or "dotlock". The command
+"postconf -l" shows the available locking styles. The default
+mailbox locking style is system dependent. This change affects
+all mailbox and all "/file/name" deliveries by the Postfix local
+delivery agent.
+
+Minor changes with release-20010228
+===================================
+
+You can now specify multiple SMTP destinations in the relayhost
+and fallback_relay configuration parameters. The destinations are
+tried in the specified order. Specify host or host:port (perform
+MX record lookups), [host] or [host]:port (no MX record lookups),
+[address] or [address]:port (numerical IP address).
+
+The "mailbox_transport" and "fallback_transport" parameters now
+understand the form "transport:nexthop", with suitable defaults
+when either transport or nexthop are omitted, just like in the
+Postfix transport map. This allows you to specify for example,
+"mailbox_transport = lmtp:unix:/file/name".
+
+The local_transport and default_transport configuration parameters
+can now be specified in transport:destination notation, just like
+the mailbox_transport and fallback_transport parameters. The
+:destination part is optional. However, these parameters take only
+one destination, unlike relayhost and fallback-relay which take
+any number of destinations.
+
+More general virtual domain support. Postfix now supports both
+Sendmail-style virtual domains and Postfix-style virtual domains.
+Details and examples are given in the revised virtual manual page.
+
+- With Sendmail-style virtual domains, local users/aliases/mailing
+ lists are visible as localname@virtual.domain. This is convenient
+ if you want to host mailing lists under virtual domains.
+
+- With Postfix-style virtual domains, local users/aliases/mailing
+ lists are not visible as localname@virtual.domain. Each virtual
+ domain has its own separate name space.
+
+More general "soft bounce" feature. Specify "soft_bounce = yes"
+in main.cf to prevent the SMTP server from bouncing mail while you
+are testing configurations. Until this release the SMTP server was
+not aware of soft bounces.
+
+Workarounds for non-standard RFC 2554 (AUTH command) implementations.
+Specify "broken_sasl_auth_clients = yes" to enable SMTP server
+support for old Microsoft client applications. The Postfix SMTP
+client supports non-standard RFC 2554 servers by default.
+
+All time-related configuration parameters now accept a one-letter
+suffix to indicate the time unit (s: second, m: minute, h: hour,
+d: day, w: week). The exceptions are the LDAP and MYSQL modules
+which are maintained separately.
+
+New "import_environment" and "export_environment" configuration
+parameters provide explicit control over what environment variables
+Postfix will import, and what environment variables Postfix will
+pass on to a non-Postfix process.
+
+In order to improve performance of one-to-one deliveries, Postfix
+by default now looks at up to 10000 messages at a time (was: 1000).
+
+Specify "syslog_facility = log_local1" etc. to separate the logging
+from multiple Postfix instances. However, a non-default logging
+facility takes effect only after process initialization. Errors
+during command-line parsing are still logged with the default syslog
+facility, as are errors while processing the main.cf file.
+
+Postfix now strips out Content-Length: headers in incoming mail to
+avoid confusion in mail user agents.
+
+Specify "require_home_directory = yes" to prevent mail from being
+delivered to a user whose home directory is not mounted. This
+feature is implemented by the Postfix local delivery agent.
+
+The pipe mailer has a size limit (size=nnn) command-line argument.
+
+The pipe delivery agent has a configurable end-of-line attribute.
+Specify "pipe ... eol=\r\n" for delivery mechanisms that require
+CRLF record delimiters. The eol attribute understands the following
+C-style escape sequences: \a \b \f \n \r \t \v \nnn \\.
+
+In master.cf you can selectively override main.cf configuration
+parameters, for example: "smtpd -o myhostname=foo.com".
+
+In main.cf, specify "smtp_bind_address=x.x.x.x" to bind SMTP
+connections to a specific local interface. Or override the default
+setting in master.cf with "smtp -o smtp_bind_address=x.x.x.x".
+For now, you must specify a numeric IP address.
+
+Questionable feature: with "smtp_always_send_ehlo = yes", the SMTP
+client sends EHLO regardless of the content of the SMTP server's
+greeting.
+
+Specify "-d key" to postalias or postmap in order to remove one
+key. This still needs to be generalized to multi-key removal (e.g.,
+read keys from stdin).
+
+Comments in Postfix configuration files no longer contain troff
+formatting codes. The text is now generated from prototype files
+in a new "proto" subdirectory.
+
+Major changes with postfix-19991231:
+====================================
+
+- It is now much more difficult to configure Postfix as an open
+relay. The SMTP server requires that "smtpd_recipient_restrictions"
+contains at least one restriction that by default refuses mail (as
+is the default). There were too many accidents with changes to
+the UCE restrictions.
+
+- The relay_domains parameter no longer needs to contain $virtual_maps.
+
+- Overhauled FAQ (html/faq.html) with many more examples.
+
+- Updated UCE documentation (html/uce.html) with more examples.
+More UCE configuration examples in sample configuration files.
+
+- Several little improvements to the installation procedure:
+relative symlinks, configurable directory for scratch files so the
+installation can be done without write access to the build tree.
+
+- Updated LDAP client code (John Hensley).
+
+- Updated mysql client code (Scott Cotton).
+
+- The SMTP server now rejects mail for unknown users in virtual
+domains that are defined by Postfix virtual maps.
+
+- The SMTP server can reject mail for unknown local users. Specify
+"local_recipient_maps = $alias_maps, unix:passwd.byname" if your
+local mail is delivered by a UNIX-style local delivery agent. See
+example in conf/main.cf.
+
+- Use "disable_vrfy_command = yes" to disable the SMTP VRFY command.
+This prevents some forms of address harvesting.
+
+- The sendmail "-f" option now understands and even understands
+forms with RFC 822-style comments.
+
+- New "qmgr_fudge_factor" parameter allows you to balance mailing
+list performance against response time for one-to-one mail. The
+fudge factor controls what percentage of delivery resources Postfix
+will devote to one message. With 100%, delivery of one message
+does not begin before delivery of the previous message is completed.
+This is good for list performance, bad for one-to-one mail. With
+10%, response time for one-to-one mail improves much, but list
+performance suffers: in the worst case, people near the start of a
+mailing list get a burst of postings today, while people near the
+end of the list get that same burst of postings a whole day later.
+
+- It is now relatively safe to configure 550 status codes for the
+main.cf unknown_address_reject_code or unknown_client_reject_code
+parameters. The SMTP server now always sends a 450 (try again)
+reply code when an UCE restriction fails due to a soft DNS error,
+regardless of what main.cf specifies.
+
+- The RBL checks now show the content of TXT records (Simon J Mudd).
+
+- The Postfix SMTP server now understands a wider range of illegal
+address forms in MAIL FROM and RCPT TO commands. In order to disable
+illegal forms, specify "strict_rfc821_envelopes = yes". This also
+disables support for MAIL FROM and RCPT TO addresses without <>.
+
+- Per-client/helo/sender/recipient UCE restrictions (fully-recursive
+UCE restriction parser). See the RESTRICTION_CLASS file for details.
+
+- Use "postmap -q key" or "postalias -q key" for testing Postfix
+lookup tables or alias files.
+
+- Use "postconf -e name=value..." to edit the main.cf file. This
+is easier and safer than editing the main.cf file by hand. The
+edits are done on a temporary copy that is renamed into place.
+
+- Use "postconf -m" to display all supported lookup table types
+(Scott Cotton).
+
+- New "permit_auth_destination" UCE restriction for finer-grained
+access control (Jesper Skriver).
+
+Incompatible changes with postfix-19990906
+==========================================
+
+- On systems that use user.lock files to protect system mailboxes
+against simultaneous updates, Postfix now uses /file/name.lock
+files while delivering to files specified in aliases/forward/include
+files. This is a no-op when the recipient lacks directory write
+permission.
+
+- The LDAP client code no longer looks up a name containing "*"
+because it could be abused. See the LDAP_README file for how to
+restore previous behavior.
+
+- The Postfix to PCRE interface now expects PCRE version 2.08.
+Postfix is no longer compatible with PCRE versions prior to 2.06.
+
+Major changes with postfix-19990906
+===================================
+
+Several bugfixes, none related to security. See the HISTORY file
+for a complete list of changes.
+
+- Postfix is now distributed under IBM Public License Version 1.0
+which does not carry the controversial termination clause. The new
+license does have a requirement that contributors make source code
+available.
+
+- INSTALL.sh install/upgrade procedure that replaces existing
+programs and shell scripts instead of overwriting them, and that
+leaves existing queue files and configuration files alone.
+
+- The ugly Delivered-To: header can now be turned off selectively.
+The default setting is: "prepend_delivered_header = command, file,
+forward". Turning off the Delivered-To: header when forwarding
+mail is not recommended.
+
+- mysql client support by Scott Cotton and Joshua Marcus, Internet
+Consultants Group, Inc. See the file MYSQL_README for instructions.
+
+- reject_unauth_destination SMTP recipient restriction that rejects
+destinations not in $relay_domains. Unlike the check_relay_domains
+restriction, reject_unauth_destination ignores the client hostname.
+By Lamont Jones of Hewlett-Packard.
+
+- reject_unauth_pipelining SMTP *anything* restriction to stop mail
+from spammers that improperly use SMTP command pipelining to speed
+up their deliveries.
+
+- Postfix "sendmail" now issues a warning and drops privileges if
+installed set-uid root.
+
+- No more duplicate delivery when "postfix reload" is immediately
+followed by "sendmail -q".
+
+- No more "invalid argument" errors when a Postfix daemon opens a
+DB/DBM file while some other process is changing the file.
+
+- Portability to the Mac OS X Server, Reliant Unix, AIX 3.2.5 and
+Ultrix 4.3.
+
+Incompatible changes with postfix-19990601:
+===========================================
+
+- The SMTP server now delays all UCE restrictions until the RCPT
+TO, VRFY or ETRN command. This makes the restrictions more useful,
+because many SMTP clients do not expect negative responses earlier
+in the protocol. In order to restore the old behavior, specify
+"smtpd_delay_reject = no" in /etc/postfix/main.cf.
+
+- The Postfix local delivery agent no longer automatically propagates
+address extensions to aliases/include/forward addresses. Specify
+"propagate_unmatched_extensions = canonical, virtual, alias, forward,
+include" to restore the old behavior.
+
+- The Postfix local delivery agent no longer does $name expansion
+on words found in the mailbox_command configuration parameter. This
+makes it easier to specify shell syntax. See conf/main.cf.
+
+- The luser_relay syntax has changed. You can specify one address;
+it is subjected to $user, etc. expansions. See conf/main.cf.
+
+- File system reorganization: daemon executables are now in the
+libexec subdirectory, command executables in the bin subdirectory.
+The INSTALL instructions now recommend installing daemons and
+commands into separate directories.
+
+Major changes with postfix-19990601:
+=====================================
+
+- New USER, EXTENSION, LOCAL, DOMAIN and RECIPIENT environment
+variables for delivery to command (including mailbox_command) by
+the local delivery agent. As you might expect, the information is
+censored. The list of acceptable characters is specified with the
+command_expansion_filter configuration parameter. Unacceptable
+characters are replaced by underscores. See html/local.8.html.
+
+- Specify "forward_path = /var/forward/$user" to avoid looking up
+.forward files in user home directories. The default value is
+$home/.forward$recipient_delimiter$extension, $home/.forward.
+Initial code by Philip A. Prindeville, Mirapoint, Inc., USA.
+
+- Conditional $name expansion in forward_path and luser_relay.
+Available names are: $user (bare user name) $shell (user login
+shell), $home (user home directory), $local (everything to the left
+of @), $extension (optional address extension), $domain (everything
+to the right of @), $recipient (the complete address) and
+$recipient_delimiter. A simple $name expands as usual. ${name?value}
+expands to value when $name is defined. ${name:value} expands to
+value when $name is not defined. With ${name?value} and ${name:value},
+the value is subject to another iteration of $name expansion.
+
+- POSIX regular expression support, enabled by default on 4.4BSD,
+LINUX, HP-UX, and Solaris 2.5 and later. See conf/sample-regexp.cf.
+Initial code by Lamont Jones, Hewlett-Packard, borrowing heavily
+from the PCRE implementation by Andrew McNamara, connect.com.au
+Pty. Ltd., Australia.
+
+- Regular expression checks for message headers. This requires
+support for POSIX or for PCRE regular expressions. Specify
+"header_checks = regexp:/file/name" or "header_checks = pcre:/file/name",
+and specify "/^header-name: badstuff/ REJECT" in the pattern file
+(patterns are case-insensitive by default). Code by Lamont Jones,
+Hewlett-Packard. It is to be expected that full content filtering
+will be delegated to an external command.
+
+- Regular expression support for all lookup tables, including access
+control (full mail addresses only), address rewriting (canonical/virtual,
+full mail addresses only) and transport tables (full domain names
+only). However, regular expressions are not allowed for aliases,
+because that would open up security exposures.
+
+- Automatic detection of changes to DB or DBM lookup tables. This
+eliminates the need to run "postfix reload" after each change to
+the SMTP access table, or to the canonical, virtual, transport or
+aliases tables.
+
+- New error mailer. Specify ".domain.name error:domain is undeliverable"
+in the transport table to bounce mail for entire domains.
+
+- No more Postfix lockups on Solaris (knock on wood). The code no
+longer uses Solaris UNIX-domain sockets, because they are still
+broken, even with Solaris 7.
+
+- Workaround for the Solaris mailtool, which keeps an exclusive
+kernel lock on the mailbox while its window is not iconified (specify
+"sun_mailtool_compatibility = yes" in main.cf).
+
+- Questionable workaround for Solaris, which reportedly loses
+long-lived exclusive locks that are held by the master daemon.
+
+- New reject_unknown_{sender,recipient}_domain restrictions for
+sender and recipient mail addresses that distinguish between soft
+errors (always 450) and hard errors (unknown_address_reject_code,
+default 450).
+
+- MIME-encapsulated bounce messages, making it easier to recover
+bounced mail. Initial implementation by Philip A. Prindeville,
+Mirapoint, Inc., USA. Support for RFC 1892 (multipart/report) and
+RFC 1894 (DSN) will have to wait until Postfix internals have been
+revised to support RFC 1893.
+
+- Separately configurable "postmaster" addresses for single bounces
+(bounce_notice_recipient), double bounces (2bounce_notice_recipient),
+delayed mail (delay_notice_recipient), and for mailer error reports
+(error_notice_recipient). See conf/main.cf.
+
+- Questionable feature: specify "best_mx_transport = local" if
+this machine is the best MX host for domains not in mydestinations.
+
+Incompatible changes with postfix-19990317:
+===========================================
+
+- You MUST install the new version of /etc/postfix/postfix-script.
+
+- The pipe mailer "flags" syntax has changed. You now explicitly
+MUST specify the R flag in order to generate a Return-Path: message
+header (as needed by, for example, cyrus).
+
+Major changes with postfix-19990317:
+====================================
+
+A detailed record of changes is given in the HISTORY file.
+
+- Less postmaster mail. Undeliverable bounce messages (double
+bounces) are now discarded. Specify "notify_classes = 2bounce..."
+to get copies of double bounces. Specify "notify_classes = bounce..."
+to get copies of normal and double bounces.
+
+- Improved LDAP client code by John Hensley of Merit Network, USA.
+See LDAP_README for details.
+
+- Perl-compatible regular expression support for lookup maps by
+Andrew McNamara, connect.com.au Pty. Ltd., Australia.. Example:
+"check_recipient_access pcre:/etc/postfix/sample-pcre.cf". Regular
+expressions provide a powerful tool not only for SMTP access control
+but also for address rewriting. See PCRE_README for details.
+
+- Automatic notification of delayed mail (disabled by default).
+With "delay_warning_time = 4", Postfix informs senders when mail
+has not been delivered after 4 hours. Initial version of the code
+by Daniel Eisenbud, University of California at Berkeley. In order
+to get postmaster copies of such warnings, specify "notify_classes
+= delay...".
+
+- More configurable local delivery: "mail_spool_directory" to
+specify the UNIX mail spool directory; "mailbox_transport" to
+delegate all mailbox delivery to, for example, cyrus, and
+"fallback_transport" to delegate delivery of only non-UNIX users.
+And all this without losing local aliases and local .forward
+processing. See config/main.cf and config/master.cf.
+
+- Several changes to improve Postfix behavior under worst-case
+conditions (frequent Postfix restarts/reloads combined with lots
+if inbound mail, intermittent connectivity problems, SMTP servers
+that become comatose after receiving QUIT).
+
+- More NFS-friendly mailbox delivery. The local delivery agent
+now avoids using root privileges where possible.
+
+- For sites that do not receive mail at all, mydestination can now
+be an empty string. Be sure to set up a transport table entry to
+prevent mail from looping.
+
+- New "postsuper" utility to clean up stale files from Postfix
+queues.
+
+- Workaround for BSD select() collisions that cause performance
+problems on large BSD systems.
+
+- Several questionable but useful features to capture mail:
+"always_bcc = address" to capture a copy of every message that
+enters the system, and "luser_relay = address" to capture mail for
+unknown recipients (does not work when mailbox_transport or
+fallback_transport are being used).
+
+- Junk mail controls: new reject_non_fqdn_{hostname,sender,recipient}
+restrictions to reject non-FQDN arguments in HELO, MAIL FROM and
+RCPT TO commands, and stricter checking of numeric HELO arguments.
+
+- "fallback_relay" feature for sites that use DNS but that can't
+talk to the entire world. The fall-back relay gets the mail when
+a destination is not found in the DNS or when the destination is
+found but not reachable.
+
+- Several questionable controls that can help to keep mail going:
+specify "smtp_skip_4xx_greeting = yes" to skip SMTP servers that
+greet with 4XX, "ignore_mx_lookup_error = yes" to look up an A
+record when a DNS server does not respond to an MX query.
+
+Incompatible changes with postfix-beta-19990122-pl01:
+=====================================================
+
+None.
+
+Major changes with postfix-beta-19990122-pl01:
+==============================================
+
+- Restrict who may use ETRN and what domains may be specified.
+Example: "smtpd_etrn_restrictions = permit_mynetworks, reject".
+
+- BIFF notifications. For compatibility reasons this feature is
+on by default. Specify "biff = no" in main.cf if your machine has
+lots of shell users.
+
+- With "soft_bounce = yes", defer delivery instead of bouncing
+mail. This is a safety net for configuration errors with delivery
+agents. It has no effect on errors in virtual maps, canonical maps,
+or in junk mail restrictions.
+
+- Specify "owner_request_special = no" to turn off special treatment
+of owner-foo and foo-request addresses.
+
+Incompatible changes with postfix-beta-19990122:
+================================================
+
+- The syntax of the transport table has changed. An entry like:
+
+ customer.org smtp:[gateway.customer.org]
+
+ no longer forwards mail for anything.customer.org. For that you
+ need to specify:
+
+ customer.org smtp:[gateway.customer.org]
+ .customer.org smtp:[gateway.customer.org]
+
+ This change makes transport tables more compatible with
+ sendmail mailer tables.
+
+- The format of syslog records has changed. A client is now always
+logged as hostname[address]; the pickup daemon logs queue file uid
+and sender address.
+
+Major changes with postfix-beta-19990122:
+=========================================
+
+- Junk mail restrictions can now be postponed to the RCPT TO command.
+Specify: "smtpd_recipient_restrictions = reject_maps_rbl...".
+
+- More flexible interface for delivery to e.g., cyrus IMAP without
+need for PERL scripts to munge recipient addresses. In addition to
+$sender, $nexthop and $recipient, the pipe mailer now also supports
+$user, $extension and $mailbox.
+
+- New mail now has precedence over deferred mail, plus some other
+tweaks to make bulk mail go faster. But it ain't no cure for massive
+network outages.
+
+- Watchdog timer for systems that cause the Postfix queue manager
+to lock up, so it recovers without human intervention.
+
+- Delivery to qmail-style maildir files, which is good for NFS
+environments. Specify "home_mailbox = Maildir/", or specify
+/file/name/ in aliases or in .forward files. The trailing / is
+required to turn on maildir delivery.
+
+- Incremental updates of aliases and maps. Specify "postmap -i
+mapname" and it will read new entries from stdin.
+
+- Newaliases will now update more than one alias database.
+Specify the names with the main.cf "alias_database" parameter.
+
+- Address masquerading exceptions to prevent users from being
+masqueraded. Specify "masquerade_exceptions = root".
+
+- A pipelined SMTP client. Deliveries to Postfix, qmail, LSOFT,
+zmailer, and exim (once it's fixed) speed up by some 30% for short
+messages with one recipient, with more for multi-recipient mails.
+
+- Hook for local delivery to "|command" via the smrsh restricted
+shell, to restrict what commands may be used in .forward etc. files.
+Specify "local_command_shell = /some/where/smrsh -c".
diff --git a/RELEASE_NOTES-2.0 b/RELEASE_NOTES-2.0
new file mode 100644
index 0000000..586f2d7
--- /dev/null
+++ b/RELEASE_NOTES-2.0
@@ -0,0 +1,853 @@
+==============================================================
+NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
+==============================================================
+Before upgrading from Postfix 1.1 you must stop Postfix ("postfix
+stop"). Some internal protocols have changed. No mail will be
+lost if you fail to stop and restart Postfix, but Postfix won't be
+able to receive any new mail, either.
+==============================================================
+NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
+==============================================================
+
+In the text below, changes are labeled with the Postfix snapshot
+that introduced the change, and whether the change introduced a
+feature, an incompatibility, or whether the feature is obsolete.
+If you upgrade from a later Postfix version, then you do not have
+to worry about incompatibilities introduced in earlier versions.
+
+Official Postfix releases are called a.b.c where a=major release
+number, b=minor release number, c=patchlevel. Snapshot releases
+are now called a.b.c-yyyymmdd where yyyymmdd is the release date
+(yyyy=year, mm=month, dd=day). The mail_release_date configuration
+parameter contains the release date (both for official release and
+snapshot release). Patches change the patchlevel and the release
+date. Snapshots change only the release date, unless they include
+the same bugfixes as a patch release.
+
+Major changes with Postfix version 2.0.0 (released 20021222, 20021223)
+======================================================================
+
+First comes the bad news - things that may break when you upgrade
+from Postfix 1.1. Then comes the good news - things that evolved
+in snapshots over the past year.
+
+For the release notes of Postfix 1.1 and earlier, see the
+RELEASE_NOTES-1.1 file.
+
+Unknown Recipients are now rejected by default
+==============================================
+
+[Incompatibility 20021209] The Postfix SMTP server now rejects mail
+for $mydestination domain recipients that it does not know about.
+This keeps undeliverable mail out of your queue.
+
+[Incompatibility 20021209] To avoid losing mail when upgrading from
+Postfix 1.1, you need to review the LOCAL_RECIPIENT_README file if
+one of the following is true:
+
+- You define $mydestination domain recipients in files other than
+ /etc/passwd or /etc/aliases. For example, you define $mydestination
+ domain recipients in the $virtual_mailbox_maps files.
+- You run the Postfix SMTP server chrooted (see master.cf).
+- You redefined the local delivery agent in master.cf.
+- You redefined the "local_transport" setting in main.cf.
+- You use the mailbox_transport feature of the Postfix local delivery agent.
+- You use the fallback_transport feature of the Postfix local delivery agent.
+- You use the luser_relay feature of the Postfix local delivery agent.
+
+Name change of virtual domain tables
+====================================
+
+This release introduces separation of lookup tables for addresses
+and for domain names of virtual domains.
+
+[Incompat 20021209] the virtual_maps parameter is replaced by
+virtual_alias_maps (for address lookups) and virtual_alias_domains
+(for the names of what were formerly called "Postfix-style virtual
+domains").
+
+ For backwards compatibility with Postfix version 1.1, the new
+ virtual_alias_maps parameter defaults to $virtual_maps, and the
+ new virtual_alias_domains parameter defaults to $virtual_alias_maps.
+ This means that you can still keep all information about a domain
+ in one file, just like before.
+
+For details, see the virtual(5) and sample-virtual.cf files.
+
+[Incompat 20021209] the virtual_mailbox_maps parameter now has a
+companion parameter called virtual_mailbox_domains (for the names
+of domains served by the virtual delivery agent). virtual_mailbox_maps
+is now used for address lookups only.
+
+ For backwards compatibility with Postfix version 1.1,, the new
+ virtual_mailbox_domains parameter defaults to $virtual_mailbox_maps.
+ This means that you can still keep all information about a domain
+ in one file, just like before.
+
+For details, see the VIRTUAL_README file.
+
+[Incompat 20021209] If you use the "advanced content filter"
+technique, you MUST NOT override the virtual aliases and virtual
+mailbox settings in the SMTP server that receives mail from the
+content filter, or else mail for virtual recipients will be rejected
+with "User unknown".
+
+For details, see the FILTER_README file.
+
+Incompatible queue file format changes
+======================================
+
+[Incompat 20020527] Queue files created with the header/body_checks
+"FILTER" feature are not compatible with "postqueue -r" (move queue
+files back to the maildrop directory) of previous Postfix releases.
+
+[Incompat 20020512] Postfix queue files contain records that are
+incompatible with "postqueue -r" on all Postfix versions prior to
+1.1 and release candidates. This happens whenever the sender
+specifies MIME body type information via the SMTP `MAIL FROM'
+command, via the `sendmail -B' command line option, or via the
+Content-Transfer-Encoding: message header.
+
+[Incompat 20020512] Postfix queue files may contain records that
+are incompatible with "postqueue -r" on previous 1.1 Postfix versions
+and release candidates. This happens whenever the sender specifies
+the MIME body type only via the Content-Transfer-Encoding: message
+header, and not via `MAIL FROM' or `sendmail -B'.
+
+Features that are going away
+============================
+
+[Obsolete 20021209] Sendmail-style virtual domains are no longer
+documented. This part of Postfix was too confusing.
+
+[Obsolete 20021209] The "reject_maps_rbl" restriction is going
+away. The SMTP server now logs a warning and suggests using the
+more flexible "reject_rbl_client" feature instead.
+
+[Obsolete 20021209] The "check_relay_domains" restriction is going
+away. The SMTP server logs a warning and suggests using the more
+robust "reject_unauth_destination" instead. This means that Postfix
+by default no longer grants relay permissions on the basis of the
+client hostname, and that relay clients must be authorized via
+other means such as permit_mynetworks.
+
+[Obsolete 20020917] In regexp lookup tables, the form /pattern1/!/pattern2/
+is going away. Use the cleaner and more flexible "if !/pattern2/..endif"
+form. The old form still exists but is no longer documented, and
+causes a warning (suggesting to use the new format) to be logged.
+For details, see "man regexp_table".
+
+[Obsolete 20020819] The qmgr_site_hog_factor feature is gone (this
+would defer mail delivery for sites that occupy too much space in
+the active queue, and be a real performance drain due to excessive
+disk I/O). The new qmgr_clog_warn_time feature (see below) provides
+more useful suggestions for dealing with Postfix congestion.
+
+[Obsolete 20020819] The "permit_naked_ip_address" restriction on
+HELO command syntax is unsafe when used with most smtpd_XXX_restrictions
+and will go away. Postfix logs a warning, suggesting to use
+"permit_mynetworks" instead.
+
+MIME support
+============
+
+[Feature 20020527] Postfix now has real MIME support. This improves
+content filtering efficiency and accuracy, and improves inter-operability
+with mail systems that cannot receive 8-bit mail. See conf/sample-mime.cf
+for details.
+
+[Feature 20020527] Postfix header_checks now properly recognize
+MIME headers in attachments. This is much more efficient than
+previous versions that recognized MIME headers via body_checks.
+MIME headers are now processed one multi-line header at a time,
+instead of one body line at a time. To get the old behavior,
+specify "disable_mime_input_processing = yes". More details in
+conf/sample-filter.cf.
+
+[Feature 20020527] Postfix now has three classes of header patterns:
+header_checks (for primary message headers except MIME headers),
+mime_header_checks (for MIME headers), and nested_header_checks
+(for headers of attached email messages except MIME headers). By
+default, all headers are matched with header_checks.
+
+[Feature 20020527] The Postfix SMTP client will now convert 8BITMIME
+mail to 7BIT when delivering to an SMTP server that does not announce
+8BITMIME support. To disable, specify "disable_mime_output_conversion
+= yes". However, this conversion is required by RFC standards.
+
+[Feature 20020528] Postfix can enforce specific aspects of the MIME
+standards while receiving mail.
+
+* Specify "strict_7bit_headers = yes" to disallow 8-bit characters
+ in message headers. These are always illegal.
+
+* Specify "strict_8bitmime_body = yes" to block mail with 8-bit
+ content that is not properly labeled as 8-bit MIME. This blocks
+ mail from poorly written mail software, including (bounces from
+ qmail, bounces from Postfix before snapshot 20020514, and Majordomo
+ approval requests) that contain valid 8BITMIME mail.
+
+* Specify "strict_8bitmime = yes" to turn on both strict_7bit_headers
+ and strict_8bitmime_body.
+
+* Specify "strict_mime_encoding_domain = yes" to block mail from
+ poorly written mail software. More details in conf/sample-mime.cf.
+
+[Incompat 20020527] Postfix now rejects mail if the MIME multipart
+structure is nested more than mime_nesting_limit levels (default:
+100) when MIME input processing is enabled while receiving mail, or
+when Postfix is performing 8BITMIME to 7BIT conversion while
+delivering mail.
+
+[Incompat 20020527] Postfix now recognizes "name :" as a valid
+message header, but normalizes it to "name:" for consistency
+(actually, there is so much code in Postfix that would break with
+"name :" that there is little choice, except to not recognize "name
+:" headers).
+
+[Incompat 20020512] Postfix queue files contain records that are
+incompatible with "postqueue -r" on all Postfix versions prior to
+1.1 and release candidates. This happens whenever the sender
+specifies MIME body type information via the SMTP `MAIL FROM'
+command, via the `sendmail -B' command line option, or via the
+Content-Transfer-Encoding: message header.
+
+[Incompat 20020512] Postfix queue files may contain records that
+are incompatible with "postqueue -r" on previous 1.1 Postfix versions
+and release candidates. This happens whenever the sender specifies
+the MIME body type only via the Content-Transfer-Encoding: message
+header, and not via `MAIL FROM' or `sendmail -B'.
+
+[Feature 20020512] The Postfix SMTP and LMTP clients now properly
+pass on the MIME body type information (7BIT or 8BITMIME), provided
+that the sender properly specifies MIME body type information via
+the SMTP MAIL FROM command, via the sendmail -B command line option,
+or via MIME message headers. This includes mail that is returned
+as undeliverable.
+
+Improved performance
+====================
+
+[Incompat 20021209] The default queue directory hash_queue_depth
+setting is reduced to 1 level of subdirectories per Postfix queue.
+This improves "mailq" performance on most systems, but can result
+in poorer worst-case performance on systems with lots of mail in
+the queue.
+
+[Incompat 20021209] The Postfix SMTP client no longer expands CNAMEs
+in MAIL FROM or RCPT TO addresses (as permitted by RFC 2821). This
+eliminates one DNS lookup per sender and recipient, and can make
+a dramatic difference when sending mailing list mail via a relayhost.
+
+[Incompat 20021209] The Postfix installation procedure no longer
+sets the "chattr +S" bit on Linux queue directories. Wietse has
+gotten too annoyed with naive reviewers who complain about performance
+without having a clue of what they are comparing.
+
+[Feature 20021209] On mail gateway systems, separation of inbound
+mail relay traffic from outbound traffic. This eliminates a problem
+where inbound mail deliveries could become resource starved in the
+presence of a high volume of outbound mail.
+
+[Feature 20021013] The body_checks_size_limit parameter limits the
+amount of text per message body segment (or attachment, if you
+prefer to use that term) that is subjected to body_checks inspection.
+The default limit is 50 kbytes. This speeds up the processing of
+mail with large attachments.
+
+[Feature 20020917] Speedups of regexp table lookups by optimizing
+for the $number substitutions that are actually present in the
+right-hand side. Based on a suggestion by Liviu Daia.
+
+[Feature 20020917] Speedups of regexp and pcre tables, using
+IF..ENDIF support. Based on an idea by Bert Driehuis. To protect
+a block of patterns, use:
+
+ if /pattern1/
+ /pattern2/ result2
+ /pattern3/ result3
+ endif
+
+IF..ENDIF can nest. Don't specify blanks at the beginning of lines
+inside IF..ENDIF, because lines beginning with whitespace are
+appended to the previous line. More details about the syntax are
+given in the pcre_table(5) and regexp_table(5) manual pages.
+
+[Feature 20020717] The default timeout for establishing an SMTP
+connection has been reduced to 30 seconds, because many system
+TCP/IP stacks have an atrociously large default timeout value.
+
+[Feature 20020505] Finer control over Berkeley DB memory usage,
+The parameter "berkeley_db_create_buffer_size" (default: 16 MBytes)
+specifies the buffer size for the postmap and postalias commands.
+The parameter "berkeley_db_read_buffer_size" (default: 128 kBytes)
+specifies the buffer size for all other applications. Specify
+"berkeley_db_read_buffer_size = 1048576" to get the old read buffer
+size. Contributed by Victor Duchovni. For more information, see
+the last paragraphs of the DB_README file.
+
+[Incompat 20021211] The default process limit is doubled from 50
+to 100. The default limits on the number of active queue files or
+recipients are doubled from 10000 to 20000. The default concurrency
+for parallel delivery to the same destination is doubled from 10
+to 20.
+
+Improved compatibility
+======================
+
+[Feature 20020527] The Postfix SMTP client will now convert 8BITMIME
+mail to 7BIT when delivering to an SMTP server that does not announce
+8BITMIME support. To disable, specify "disable_mime_output_conversion
+= yes". However, this conversion is required by RFC standards.
+
+[Feature 20020512] The Postfix SMTP and LMTP clients now properly
+pass on the MIME body type information (7BIT or 8BITMIME), provided
+that the sender properly specifies MIME body type information via
+the SMTP MAIL FROM command, via the sendmail -B command line option,
+or via MIME message headers. This includes mail that is returned
+as undeliverable.
+
+[Incompat 20020326] The Postfix SMTP client now breaks message
+header or body lines that are longer than $smtp_line_length_limit
+characters (default: 990). Earlier Postfix versions broke lines
+at $line_length_limit characters (default: 2048). Postfix versions
+before 20010611 did not break long lines at all. Reportedly, some
+mail servers refuse to receive mail with lines that exceed the 1000
+character limit that is specified by the SMTP standard.
+
+[Incompat 20020326] The Postfix SMTP client now breaks long message
+header or body lines by inserting . Earlier
+Postfix versions broke long lines by inserting only. This
+broke MIME encapsulation, causing MIME attachments to "disappear"
+with Postfix versions after 20010611.
+
+[Incompat 20020326] Postfix now discards text when a logical message
+header exceeds $header_size_limit characters (default: 102400).
+Earlier Postfix versions would place excess text, and all following
+text, in the message body. The same thing was done when a physical
+header line exceeded $line_length_limit characters (default: 2048).
+Both behaviors broke MIME encapsulation, causing MIME attachments
+to "disappear" with all previous Postfix versions.
+
+[Incompat 20021015] The Postfix LMTP client no longer lowercases email
+addresses in MAIL FROM and RCPT TO commands.
+
+[Incompat 20021013] The default Linux kernel lock style for mailbox
+delivery is changed from flock() to fcntl(). This has no impact if
+your system uses procmail for local delivery, if you use maildir-style
+mailboxes, or when mailbox access software locks mailboxes with
+username.lock files (which is usually the case with non-maildir
+mailboxes).
+
+Address classes
+===============
+
+[Feature 20021209] This release introduces the concept of address
+domain classes, each having its own default mail delivery transport:
+
+ Destination matches Default transport Default name
+ ==============================================================
+ $mydestination or
+ $inet_interfaces $local_transport local
+ $virtual_alias_domains (not applicable) (not applicable)
+ $virtual_mailbox_domains $virtual_transport virtual
+ $relay_domains $relay_transport relay
+ other $default_transport smtp
+
+The benefits of these changes are:
+
+- You no longer need to specify all the virtual(8) domains in the
+ Postfix transport map. The virtual(8) delivery agent has
+ become a first-class citizen just like local(8) or smtp(8).
+
+- On mail gateway systems, separation of inbound mail relay traffic
+ from outbound traffic. This eliminates a problem where inbound
+ mail deliveries could become resource starved in the presence of
+ a high volume of outbound mail.
+
+- The SMTP server rejects unknown recipients in a more consistent
+ manner than was possible with previous Postfix versions.
+
+See the ADDRESS_CLASS_README file for a description of address
+classes, their benefits, and their incompatibilities.
+
+New relay transport in master.cf
+================================
+
+[Incompat 20021209] Postfix no longer defaults to the "smtp"
+transport for all non-local destinations. In particular, Postfix
+now uses the "relay" mail delivery transport for delivery to domains
+matching $relay_domains. This may affect your defer_transports
+settings.
+
+On mail gateway systems, this allows us to separate inbound mail
+relay traffic from outbound traffic, and thereby eliminate a problem
+where inbound mail deliveries could become resource starved in the
+presence of a high volume of outbound mail.
+
+[Incompat 20021209] This release adds a new "relay" service to the
+Postfix master.cf file. This is a clone of the "smtp" service. If
+your Postfix is unable to connect to the "relay" service then you
+have not properly followed the installation procedure.
+
+Revision of RBL blacklisting code
+=================================
+
+[Feature 20020923] Complete rewrite of the RBL blacklisting code.
+The names of RBL restrictions are now based on a suggestion that
+was made by Liviu Daia in October 2001. See conf/sample-smtpd.cf
+or html/uce.html for details.
+
+[Feature 20020923] "reject_rbl_client rbl.domain.tld" for client
+IP address blacklisting. Based on code by LaMont Jones. The old
+"reject_maps_rbl" is now implemented as a wrapper around the
+reject_rbl_client code, and logs a warning that "reject_maps_rbl"
+is going away. To upgrade, specify "reject_rbl_client domainname"
+once for each domain name that is listed in maps_rbl_domains.
+
+[Feature 20020923] "reject_rhsbl_sender rbl.domain.tld" for sender
+domain blacklisting. Also: reject_rhsbl_client and reject_rhsbl_recipient
+for client and recipient domain blacklisting.
+
+[Feature 20020923] "rbl_reply_maps" configuration parameter for
+lookup tables with template responses per RBL server. Based on code
+by LaMont Jones. If no reply template is found the default template
+is used as specified with the default_rbl_reply configuration
+parameter. The template responses support $name expansion of
+client, helo, sender, recipient and RBL related attributes.
+
+[Incompat 20020923] The default RBL "reject" server reply now
+includes an indication of *what* is being rejected: Client host,
+Helo command, Sender address, or Recipient address. This also
+changes the logfile format.
+
+[Feature 20020923] "smtpd_expansion_filter" configuration parameter
+to control what characters are allowed in the expansion of template
+RBL reply $name macros. Characters outside the allowed set are
+replaced by "_".
+
+More sophisticated handling of UCE-related DNS lookup errors
+============================================================
+
+[Feature 20020906] More sophisticated handling of UCE-related DNS
+lookup errors. These cause Postfix to not give up so easily, so
+that some deliveries will not have to be deferred after all.
+
+[Feature 20020906] The SMTP server sets a defer_if_permit flag when
+an UCE reject restriction fails due to a temporary (DNS) problem,
+to prevent unwanted mail from slipping through. The defer_if_permit
+flag is tested at the end of the ETRN and recipient restrictions.
+
+[Feature 20020906] A similar flag, defer_if_reject, is maintained
+to prevent mail from being rejected because a whitelist operation
+(such as permit_mx_backup) fails due to a temporary (DNS) problem.
+
+[Feature 20020906] The permit_mx_backup restriction is made more
+strict. With older versions, some DNS failures would cause mail to
+be accepted anyway, and some DNS failures would cause mail to be
+rejected by later restrictions in the same restriction list. The
+improved version will defer delivery when Postfix could make the
+wrong decision.
+
+- After DNS lookup failure, permit_mx_backup will now accept the
+request if a subsequent restriction would cause the request to be
+accepted anyway, and will defer the request if a subsequent
+restriction would cause the request to be rejected.
+
+- After DNS lookup failure, reject_unknown_hostname (the hostname
+given in HELO/EHLO commands) reject_unknown_sender_domain and
+reject_unknown_recipient_domain will now reject the request if a
+subsequent restriction would cause the request to be rejected
+anyway, and will defer the request if a subsequent restriction
+would cause the request to be accepted.
+
+[Feature 20020906] Specify "smtpd_data_restrictions =
+reject_unauth_pipelining" to block mail from SMTP clients that send
+message content before Postfix has replied to the SMTP DATA command.
+
+Other UCE related changes
+=========================
+
+[Feature 20020717] The SMTP server reject_unknown_{sender,recipient}_domain
+etc. restrictions now also attempt to look up AAAA (IPV6 address)
+records.
+
+[Incompat 20020513] In order to allow user@domain@domain addresses
+from untrusted systems, specify "allow_untrusted_routing = yes" in
+main.cf. This opens opportunities for mail relay attacks when
+Postfix provides backup MX service for Sendmail systems.
+
+[Incompat 20020514] For safety reasons, the permit_mx_backup
+restriction no longer accepts mail for user@domain@domain. To
+recover the old behavior, specify "allow_untrusted_routing = yes"
+and live with the risk of becoming a relay victim.
+
+[Incompat 20020509] The Postfix SMTP server no longer honors OK
+access rules for user@domain@postfix-style.virtual.domain, to close
+a relaying loophole with postfix-style virtual domains that have
+@domain.name catch-all patterns.
+
+[Incompat 20020201] In Postfix SMTPD access tables, Postfix now
+uses <> as the default lookup key for the null address, in order
+to work around bugs in some Berkeley DB implementations. This
+behavior is controlled with the smtpd_null_access_lookup_key
+configuration parameter.
+
+Changes in transport table lookups
+==================================
+
+[Feature 20020610] user@domain address lookups in the transport
+map. This feature also understands address extensions. Transport
+maps still support lookup keys in the form of domain names, but
+only with non-regexp tables. Specify mailer-daemon@my.host.name
+in order to match the null address. More in the transport(5) manual
+page.
+
+[Feature 20020505] Friendlier behavior of Postfix transport tables.
+There is a new "*" wildcard pattern that always matches. The
+meaning of null delivery transport AND nexhop information field
+has changed to "do not modify": use the information that would be
+used if the transport table did not exist. This change makes it
+easier to route intranet mail (everything under my.domain) directly:
+you no longer need to specify explicit "local" transport table
+entries for every domain name that resolves to the local machine.
+For more information, including examples, see the updated transport(5)
+manual page.
+
+[Incompat 20020610] Regexp/PCRE-based transport maps now see the
+entire recipient address instead of only the destination domain
+name.
+
+[Incompat 20020505, 20021215] The meaning of null delivery transport
+and nexhop fields has changed incompatibly.
+
+- A null delivery transport AND nexthop information field means
+"do not modify": use the delivery transport or nexthop information
+that would be used if no transport table did not exist.
+
+- The delivery transport is not changed with a null delivery
+transport field and non-null nexthop field.
+
+- The nexthop is reset to the recipient domain with a non-null
+transport field and a null nexthop information field.
+
+Address manipulation changes
+============================
+
+[Incompat 20020717] Postfix no longer strips multiple '.' characters
+from the end of an email address or domain name. Only one '.' is
+tolerated.
+
+[Feature 20020717] The masquerade_domains feature now supports
+exceptions. Prepend a ! character to a domain name in order to
+not strip its subdomain structure. More information in
+conf/sample-rewrite.cf.
+
+[Feature 20020717] The Postfix virtual delivery agent supports
+catch-all entries (@domain.tld) in lookup tables. These match users
+that do not have a specific user@domain.tld entry. The virtual
+delivery agent now ignores address extensions (user+foo@domain.tld)
+when searching its lookup tables, but displays the extensions in
+Delivered-To: message headers.
+
+[Feature 20020610] user@domain address lookups in the transport
+map. This feature also understands address extensions. Transport
+maps still support lookup keys in the form of domain names, but
+only with non-regexp tables. Specify mailer-daemon@my.host.name
+in order to match the null address. More in the transport(5) manual
+page.
+
+[Incompat 20020610] Regexp/PCRE-based transport maps now see the
+entire recipient address instead of only the destination domain
+name.
+
+[Incompat 20020513] In order to allow user@domain@domain addresses
+from untrusted systems, specify "allow_untrusted_routing = yes" in
+main.cf. This opens opportunities for mail relay attacks when
+Postfix provides backup MX service for Sendmail systems.
+
+[Incompat 20020509] The Postfix SMTP server no longer honors OK
+access rules for user@domain@postfix-style.virtual.domain, to close
+a relaying loophole with postfix-style virtual domains that have
+@domain.name catch-all patterns.
+
+[Incompat 20020509] The appearance of user@domain1@domain2 addresses
+has changed. In mail headers, such addresses are now properly
+quoted as "user@domain1"@domain2. As a side effect, this quoted
+form is now also expected on the left-hand side of virtual and
+canonical lookup tables, but only by some of the Postfix components.
+For now, it is better not to use user@domain1@domain2 address forms
+on the left-hand side of lookup tables.
+
+Regular expression and PCRE related changes
+===========================================
+
+[Feature 20021209] Regular expression maps are now allowed with
+local delivery agent alias tables and with all virtual delivery
+agent lookup tables. However, regular expression substitution of
+$1 etc. is still forbidden for security reasons.
+
+[Obsolete 20020917] In regexp lookup tables, the form /pattern1/!/pattern2/
+is going away. Use the cleaner and more flexible "if !/pattern2/..endif"
+form. The old form still exists but is no longer documented, and
+causes a warning (suggesting to use the new format) to be logged.
+
+[Incompat 20020610] Regexp/PCRE-based transport maps now see the
+entire recipient address instead of only the destination domain
+name.
+
+[Incompat 20020528] With PCRE pattern matching, the `.' metacharacter
+now matches all characters including newline characters. This makes
+PCRE pattern matching more convenient to use with multi-line message
+headers, and also makes PCRE more compatible with regexp pattern
+matching. The pcre_table(5) manual page has been greatly revised.
+
+New mail "HOLD" action and "hold" queue
+=======================================
+
+[Feature 20020819] New "hold" queue for mail that should not be
+delivered. "postsuper -h" puts mail on hold, and "postsuper -H"
+releases mail, moving mail that was "on hold" to the deferred queue.
+
+[Feature 20020821] HOLD and DISCARD actions in SMTPD access tables.
+As with the header/body version of the same, these actions apply
+to all recipients of the same queue file.
+
+[Feature 20020819] New header/body HOLD action that causes mail to
+be placed on the "hold" queue. Presently, all you can do with mail
+"on hold" is to examine it with postcat, to take it "off hold" with
+"postsuper -H", or to destroy it with "postsuper -d". See
+conf/sample-filter.cf.
+
+[Incompat 20020819] In mailq output, the queue ID is followed by
+the ! character when the message is in the "hold" queue (see below).
+This may break programs that process mailq output.
+
+Content filtering
+=================
+
+[Feature 20020823] Selective content filtering. In in SMTPD access
+tables, specify "FILTER transport:nexthop" for mail that needs
+filtering. More info about content filtering is in the Postfix
+FILTER_README file. This feature overrides the main.cf content_filter
+setting. Presently, this applies to all the recipients of a queue
+file.
+
+[Feature 20020527] Selective content filtering. In header/body_check
+patterns, specify "FILTER transport:nexthop" for mail that needs
+filtering. This requires different cleanup servers before and after
+the filter, with header/body checks turned off in the second cleanup
+server. More info about content filtering is in the Postfix
+FILTER_README file. This feature overrides the main.cf content_filter
+setting. Presently, this applies to all the recipients of a queue
+file.
+
+[Feature 20020527] Postfix now has real MIME support. This improves
+content filtering efficiency and accuracy, and improves inter-operability
+with mail systems that cannot receive 8-bit mail. See conf/sample-mime.cf
+for details.
+
+[Feature 20020527] Postfix header_checks now properly recognize
+MIME headers in attachments. This is much more efficient than
+previous versions that recognized MIME headers via body_checks.
+MIME headers are now processed one multi-line header at a time,
+instead of one body line at a time. To get the old behavior,
+specify "disable_mime_input_processing = yes". More details in
+conf/sample-filter.cf.
+
+[Feature 20020527] Postfix now has three classes of header patterns:
+header_checks (for primary message headers except MIME headers),
+mime_header_checks (for MIME headers), and nested_header_checks
+(for headers of attached email messages except MIME headers). By
+default, all headers are matched with header_checks.
+
+[Feature 20021013] The body_checks_size_limit parameter limits the
+amount of text per message body segment (or attachment, if you
+prefer to use that term) that is subjected to body_checks inspection.
+The default limit is 50 kbytes. This speeds up the processing of
+mail with large attachments.
+
+[Feature 20020917] Speedups of regexp table lookups by optimizing
+for the $number substitutions that are actually present in the
+right-hand side. Based on a suggestion by Liviu Daia.
+
+[Feature 20020917] Speedups of regexp and pcre tables, using
+IF..ENDIF support. Based on an idea by Bert Driehuis. To protect
+a block of patterns, use:
+
+ if /pattern1/
+ /pattern2/ result2
+ /pattern3/ result3
+ endif
+
+IF..ENDIF can nest. Don't specify blanks at the beginning of lines
+inside IF..ENDIF, because lines beginning with whitespace are
+appended to the previous line. More details about the syntax are
+given in the pcre_table(5) and regexp_table(5) manual pages.
+
+Postmap/postalias/newaliases changes
+====================================
+
+[Incompat 20020505] The postalias command now copies the source
+file read permissions to the result file when creating a table for
+the first time. Until now, the result file was created with default
+read permissions. This change makes postalias more similar to
+postmap.
+
+[Incompat 20020505] The postalias and postmap commands now drop
+super-user privileges when processing a non-root source file. The
+file is now processed as the source file owner, and the owner must
+therefore have permission to update the result file. Specify the
+"-o" flag to get the old behavior (process non-root files with root
+privileges).
+
+[Incompat 20020122] When the postmap command creates a non-existent
+result file, the new file inherits the group/other read permissions
+of the source file.
+
+Assorted changes
+================
+
+[Feature 20021028] The local(8) and virtual(8) delivery agents now record
+the original recipient address in the X-Original-To: message header.
+This header can also be emitted by the pipe(8) delivery agent.
+
+[Incompat 20021028] With "domain in one mailbox", one message with
+multiple recipients is no longer delivered only once. It is now
+delivered as one copy for each original recipient, with the original
+recipient address listed in the X-Original-To: message header.
+
+[Feature 20021024] New proxy_interfaces parameter, for sites behind a
+network address translation gateway or other type of proxy. You
+should specify all the proxy network addresses here, to avoid avoid
+mail delivery loops.
+
+[Feature 20021013] Updated MacOS X support by Gerben Wierda. See
+the auxiliary/MacOSX directory.
+
+[Incompat 20021013] Subtle change in ${name?result} macro expansions:
+the expansion no longer happens when $name is an empty string. This
+probably makes more sense than the old behavior.
+
+[Incompat 20020917] The relayhost setting now behaves as documented,
+i.e. you can no longer specify multiple destinations.
+
+[Incompatibility 20021219] The use of the XVERP extension in the
+SMTP MAIL FROM command is now restricted to SMTP clients that match
+the hostnames, domains or networks listed with the authorized_verp_clients
+parameter (default: $mynetworks).
+
+[Feature 20020819] When the Postfix local delivery agent detects
+a mail delivery loop (usually the result of mis-configured mail
+pickup software), the undeliverable mail is now sent to the mailing
+list owner instead of the envelope sender address (usually the
+original poster who has no guilt, and who cannot fix the problem).
+
+[Warning 20020819] The Postfix queue manager now warns when mail
+for some destination is piling up in the active queue, and suggests
+a variety of remedies to speed up delivery (increase per-destination
+concurrency limit, increase active queue size, use a separate
+delivery transport, increase per-transport process limit). The
+qmgr_clog_warn_time parameter controls the time between warnings.
+To disable these warnings, specify "qmgr_clog_warn_time = 0".
+
+[Warning 20020717] The Postfix SMTP client now logs a warning when
+the same domain is listed in main.cf:mydestination as well as a
+Postfix-style virtual map. Such a mis-configuration may cause mail
+for users to be rejected with "user unknown".
+
+[Feature 20020331] A new smtp_helo_name parameter that specifies
+the hostname to be used in HELO or EHLO commands; this can be more
+convenient than changing the myhostname parameter setting.
+
+[Feature 20020331] Choice between multiple instances of internal
+services: bounce, cleanup, defer, error, flush, pickup, queue,
+rewrite, showq. This allows you to use different cleanup server
+settings for different SMTP server instances. For example, specify
+in the master.cf file:
+
+ localhost:10025 ... smtpd -o cleanup_service_name=cleanup2 ...
+ cleanup2 ... cleanup -o header_checks= body_checks= ...
+
+Logfile format changes
+======================
+
+[Incompat 20021209] The Postfix SMTP client no longer expands CNAMEs
+in MAIL FROM addresses (as permitted by RFC 2821) before logging
+the recipient address.
+
+[Incompat 20021028] The Postfix SMTP server UCE reject etc. logging
+now includes the queue ID, the mail protocol (SMTP or ESMTP), and
+the hostname that was received with the HELO or EHLO command, if
+available.
+
+[Incompat 20021028] The Postfix header/body_checks logging now
+includes the mail protocol (SMTP, ESMTP, QMQP) and the hostname
+that was received with the SMTP HELO or EHLO command, if available.
+
+[Incompat 20021028] The Postfix status=sent/bounced/deferred logging
+now shows the original recipient address (as received before any
+address rewriting or aliasing). The original recipient address is
+logged only when it differs from the final recipient address.
+
+[Incompat 20020923] The default RBL "reject" server reply now
+includes an indication of *what* is being rejected: Client host,
+Helo command, Sender address, or Recipient address. This also
+changes the logfile format.
+
+LDAP related changes
+====================
+
+[Incompat 20020819] LDAP API version 1 is no longer supported. The
+memory allocation and deallocation strategy has changed too much
+to maintain both version 1 and 2 at the same time.
+
+[Feature 20020513] Updated LDAP client module with better handling
+of dead LDAP servers, and with configurable filtering of query
+results.
+
+SASL related changes
+====================
+
+[Incompat 20020819] The smtpd_sasl_local_domain setting now defaults
+to the null string, rather than $myhostname. This seems to work
+better with Cyrus SASL version 2. This change may cause incompatibility
+with the saslpasswd2 command.
+
+[Feature 20020331] Support for the Cyrus SASL version 2 library,
+contributed by Jason Hoos. This adds some new functionality that
+was not available in Cyrus SASL version 1, and provides bit-rot
+insurance for the time when Cyrus SASL version 1 eventually stops
+working.
+
+Berkeley DB related changes
+===========================
+
+[Feature 20020505] Finer control over Berkeley DB memory usage,
+The parameter "berkeley_db_create_buffer_size" (default: 16 MBytes)
+specifies the buffer size for the postmap and postalias commands.
+The parameter "berkeley_db_read_buffer_size" (default: 256 kBytes)
+specifies the buffer size for all other applications. Specify
+"berkeley_db_read_buffer_size = 1048576" to get the old read buffer
+size. For more information, see the last paragraphs of the DB_README
+file.
+
+[Incompat 20020201] In Postfix SMTPD access tables, Postfix now
+uses <> as the default lookup key for the null address, in order
+to work around bugs in some Berkeley DB implementations. This
+behavior is controlled with the smtpd_null_access_lookup_key
+configuration parameter.
+
+[Incompat 20020201] Postfix now detects if the run-time Berkeley
+DB library routines do not match the major version number of the
+compile-time include file that was used for compiling Postfix. The
+software issues a warning and aborts in case of a discrepancy. If
+it didn't, the software was certain to crash with a segmentation
+violation.
+
+Assorted workarounds
+====================
+
+[Incompat 20020201] On SCO 3.2 UNIX, the input rate flow control
+is now turned off by default, because of limitations in the SCO
+UNIX kernel.
diff --git a/RELEASE_NOTES-2.1 b/RELEASE_NOTES-2.1
new file mode 100644
index 0000000..c25b28b
--- /dev/null
+++ b/RELEASE_NOTES-2.1
@@ -0,0 +1,581 @@
+In the text below, incompatible changes are labeled with the Postfix
+snapshot that introduced the change. If you upgrade from a later
+Postfix version, then you do not have to worry about that particular
+incompatibility.
+
+The official Postfix release is called 2.1.x where 2=major release
+number, 1=minor release number, x=patchlevel. Snapshot releases
+are called 2.2-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). The mail_release_date configuration parameter
+contains the release date (both for official release and snapshot
+release). Patches are issued for the official release and change
+the patchlevel and the release date. Patches are never issued for
+snapshot releases.
+
+Major changes - critical
+------------------------
+
+If you run Postfix 2.0 or earlier then you must stop Postfix before
+upgrading. The master-child protocols have changed between Postfix
+1.1 and 2.0, and version 2.1 sometimes writes queue files that the
+2.0 and earlier queue managers complain about. If this happens move
+the files from the corrupt directory to the maildrop directory and
+give them another chance.
+
+[Incompat 20021119] The Postfix upgrade procedure will add two new
+services to your master.cf file: "trace" and "verify". These servers
+can run inside a chroot jail, have no interaction with users, and
+don't talk to the network. If Postfix complains that "trace" and
+"verify" are not found, you made the error of copying your old
+Postfix configuration files over the new ones. Execute "postfix
+upgrade-configuration" to repair the Postfix configuration files.
+
+[Incompat 20040331] Support for the non-standard Errors-To: message
+header is removed. This also helps to stop potential attacks that
+rely on bouncing mail to a destination that is not directly reachable
+by the attacker. Specify "enable_errors_to = yes" to get the old
+behavior.
+
+Queue files written by Postfix 2.1 may contain information that
+is incompatible with older Postfix versions:
+
+[Incompat 20040120] Queue files creates with "sendmail -v" are no
+longer compatible with Postfix versions 2.0 and earlier. A new
+record type, "killed", was introduced in order to avoid repeated
+mail delivery reports from mail that could not be delivered due to
+a temporary error condition.
+
+[Incompat 20030125] This release adds a new queue file record type
+for the address specified in "REDIRECT user@domain" actions in
+access maps or header/body_checks. Queue files with these records
+will be rejected by older Postfix versions.
+
+[Feature 20040120] The new queue manager nqmgr has become the
+default qmgr queue manager. For a limited time the old queue manager
+remains available under the name oqmgr. The name nqmgr still works
+but will cause a warning to be logged.
+
+[Incompat 20040413] The Postfix SMTP server no longer accepts mail
+from or to an address ending in "@", including address forms that
+rewrite into an address that ends in "@"). Specify "resolve_null_domain
+= yes" to get the old behavior.
+
+[Incompat 20031226] Postfix no longer allows mail addresses with
+bare numeric IP addresses (user@1.2.3.4). This is not configurable.
+The form user@[ipaddress] is still allowed.
+
+[Incompat 20031226] Bounce messages now have a separate queue life
+time. This is controlled by the bounce_queue_lifetime parameter.
+
+[Incompat 20031019] The authorized_verp_clients parameter was
+renamed to smtpd_authorized_verp_clients, and the default value
+was changed to disable this feature. You now have to turn it on
+explicitly.
+
+Major changes - build environment
+---------------------------------
+
+[Incompat 20030112] The Postfix build procedure now uses the
+pcre-config utility (part of PCRE version 3) to find out the
+pathnames of the PCRE include file and object library, instead of
+probing /usr/include and/or /usr/lib. To build with PCRE version
+2 support you will have to specify pathnames as described in
+PCRE_README. To build without PCRE support, specify: make Makefiles
+CCARGS="-DNO_PRCE".
+
+Major changes - documentation
+-----------------------------
+
+[Feature 20040331] Complete documentation rewrite. All parameters
+are now described in postconf(5), and all commands and daemons are
+shown in their proper context in the OVERVIEW document.
+- All documents come as HTML and ASCII text.
+- All HTML documents have hyperlinks for every parameter name,
+ for every Postfix manual page, and for every README file.
+- All documents specify what feature is available in what release.
+- The sample-*.cf configuration files no longer exist. The information
+ is now available in HTML documents, README files and UNIX man pages).
+- The mumble_table example configuration files no longer exist.
+
+[Incompat 20040413] The LMTP, Cyrus and Qmail related README files will
+not be included in the Postfix version 2.1 distribution. They will
+be made available via http://www.postfix.org/, and in Postfix 2.2
+snapshots.
+
+[Feature 20040413] You can install documentation in HTML format
+besides the README files. Installation of README files is now
+optional.
+
+Major changes - access control
+------------------------------
+
+[Feature 20031215] Easier debugging of SMTPD access restrictions.
+The SMTP command "xclient name=xxx addr=yyy" changes Postfix's idea
+of the remote client name and address, so that you can pretend to
+connect from anywhere on the Internet. Use of this command is
+restricted to clients that match the list of names or addresses
+specified with the smtpd_authorized_xclient_hosts parameter. By
+default, XCLIENT is not accepted from anywhere. More details are
+in the XCLIENT_README file.
+
+[Feature 20030715] Support for multi-valued RBL lookup results.
+For example, specify "reject_rbl_client foo.bar.tld=127.0.0.3" to
+reject clients that are listed with a "127.0.0.3" address record.
+More information is in the postconf(5) manual page.
+
+[Feature 20030917] New "check_{helo,sender,recipient}_{ns,mx}_access
+type:table" restrictions that apply the specified access table to
+the NS or MX hosts of the host/domain given in HELO, EHLO, MAIL
+FROM or RCPT TO commands. More information is in the postconf(5)
+manual page.
+
+This can be used to block mail from so-called spammer havens (all
+domains that are served by the same DNS server, all domains that
+resolve to the same MX host), from sender addresses that resolve
+to Verisign's wild-card mail responder, or from domains that claim
+to have mail servers in reserved networks such as 127.0.0.1.
+
+Note: OK actions are not allowed for security reasons. Instead of
+OK, use DUNNO in order to exclude specific hosts from blacklists.
+If an OK result is found for an NS or MX host, Postfix rejects the
+SMTP command with "451 Server configuration error".
+
+[Feature 20040413] Support for a "WARN text..." feature in SMTPD
+access tables, just like the WARN feature in header/body_checks.
+
+[Feature 20040122] New "PREPEND headername: headervalue" action in
+Postfix access maps. Primarily intended for tagging mail by for
+example, an external SMTPD policy server. See access(5).
+
+[Feature 20040124] New "PREPEND text" action in Postfix header/body_checks
+maps. This action prepends a header or body line immediately before
+the line that triggers the action. See header_checks(5) for details.
+
+[Feature 20030125] New "REDIRECT user@domain" action for access
+maps and header/body_checks that overrides all the originally
+specified recipients of a message. Wietse would never recommend
+that people use this to redirect (bounced) SPAM to the beneficiaries
+of an advertisement campaign. See access(5) and header_checks(5).
+
+[Feature 20031215] The reject_sender_login_mismatch feature (used
+with SASL authenticated logins) is now implemented in terms of more
+basic restrictions: reject_unauth_sender_login_mismatch (reject
+mail when $sender_login_maps lists an owner for the sender address
+but the SMTP client is not SASL authenticated) and
+reject_auth_sender_login_mismatch (reject mail when the sender
+address is not owned by the SASL authenticated user). The
+sender_login_maps now support multiple owners per sender address.
+See postconf(5) for details.
+
+Major changes - address verification
+------------------------------------
+
+[Feature 20021119] Address verification blocks mail from or to
+addresses that are not deliverable. This is turned on with the
+reject_unverified_sender UCE restriction. Addresses are verified
+by probing, that is, by sending mail that is not actually delivered
+(SMTP interruptus). Detailed information is in the
+ADDRESS_VERIFICATION_README file.
+
+Address verification can follow a different route than ordinary
+mail, typically to avoid sending probes to a relay host. To make
+this possible, the address resolver supports multiple personalities.
+For more detail see the ADDRESS_VERIFICATION_README file.
+
+New "sendmail -bv" option. Postfix probes the specified recipient
+addresses without actually delivering mail, and sends back an email
+delivery report. This is useful for testing address rewriting and
+address routing, and shows the final envelope and header addresses.
+This feature currently does not access or update the sender address
+verification database.
+
+Major changes - content inspection
+----------------------------------
+
+[Feature 20030704] The Postfix SMTP server can be configured to
+send all mail into a real-time content filter that inspects mail
+BEFORE it is queued. See the SMTPD_PROXY_README file for details.
+
+[Feature 20031022] Improved logging by Postfix daemons behind an
+SMTP-based proxy filter. The logging now shows the remote client
+name and address, instead of localhost[127.0.0.1]. This uses the
+new SMTP command "XFORWARD addr=client-address name=client-hostname",
+which specifies remote client information for logging purposes.
+This command is restricted to clients that match the list of names
+or addresses specified with the smtpd_authorized_xforward_hosts
+parameter. By default, XFORWARD is not accepted from anywhere.
+For an example, see the SMTPD_PROXY_README file.
+
+[Feature 20030706] New receive_override_options parameter that
+eliminates the need for different cleanup service instances before
+and after an external content filter. One parameter controls what
+happens before or after the content filter: rejecting unknown
+recipients, canonical mapping, virtual alias expansion, masquerading,
+automatic BCC recipients and header/body checks. See postconf(5)
+for the fine details.
+
+[Feature 20040124] New "PREPEND text" action in Postfix header/body_checks
+maps. This action prepends a header or body line immediately before
+the line that triggers the action. See header_checks(5) for details.
+
+[Feature 20030125] New "REDIRECT user@domain" action for access maps
+and header/body_checks that overrides all the originally specified
+recipients of a message. Wietse would never recommend that people
+use this to redirect (bounced) SPAM to the beneficiaries of an
+advertisement campaign. See header_checks(5) and access(5).
+
+[Incompat 20030915] In header/body_checks actions, the OK action
+is being phased out, and the DUNNO action is being phased in. Both
+actions still work and do the same thing, but hopefully DUNNO causes
+less confusion. See header_checks(5) for details.
+
+Major changes - policy delegation
+---------------------------------
+
+[Feature 20030715] Support for SMTP access policy delegation to an
+external server. Greylisting and SPF are provided as examples.
+See the SMTPD_POLICY_README file for further information.
+
+Major changes - client rate limiting
+------------------------------------
+
+Note: this feature is not included with Postfix 2.1, but it is
+documented here so that the information will not be lost.
+
+[Feature 20031111] Preliminary defense against SMTP clients that
+hammer an SMTP server with too many connections. By default, the
+number of simultaneous connections per client is limited to half
+the default process limit, and no limit is imposed on the number
+of successive connections per time unit that a client is allowed
+to make.
+
+The new anvil server maintains the connection statistics, and logs
+the maximum connection count and connection rate per client every
+anvil_status_update_time seconds (10 minutes), or when it terminates
+(when there is no work to be done, or when "postfix reload" was
+issued). Once you have an idea what the numbers look like, you can
+clamp down the limits for your system.
+
+The relevant main.cf configuration parameters are: smtpd_client-
+connection_count_limit for the number of simultaneous connections
+per client, and smtpd_client_connection_rate_limit for the number
+of successive connections per unit time and client. The time unit
+is specified with the anvil_rate_time_unit parameter, and is one
+minute by default.
+
+When Postfix rejects a client, it sends a 450 status code and
+disconnects, and logs a warning with the client name/address and
+the service name from master.cf. You can, for example, capture this
+information with a logfile watching program that updates a firewall
+rule (such a watcher program is not included with Postfix).
+
+To avoid rejecting authorized hosts, the smtpd_client_connection-
+limit_exceptions parameter takes a list of network/netmask expressions,
+hostnames or .domain names that are excluded from these restrictions.
+By default, all clients in $mynetworks are excluded; you will
+probably want to use a more restrictive setting.
+
+For further information, see: smtpd(8) and anvil(8).
+
+Major changes - configuration management
+----------------------------------------
+
+[Feature 20040413] New postfix(1) command features:
+
+- "postfix set-permissions" corrects Postfix file and directory
+ permissions and allows you to change mail_owner or setgid_group
+ settings after Postfix is installed.
+
+- "postfix upgrade-configuration" fixes Postfix systems after people
+ copy over their old configuration files after installing a new
+ Postfix system.
+
+See postfix(1) for details.
+
+[Incompat 20040120] The format of the postfix-files file has changed.
+There is a new type for hard links. With hard or symbolic link
+entries, the first field is now the destination pathname and the
+"owner" field is now the origin pathname, while "group" and
+"permissions" are ignored.
+
+Major changes - core functionality
+----------------------------------
+
+[Feature 20030704] New enable_original_recipient parameter (default:
+yes) to control whether Postfix keeps track of original recipient
+address information. If this is turned off Postfix produces no
+X-Original-To: headers and ignores the original recipient when
+eliminating duplicates after virtual alias expansion. Code by Victor
+Duchovni.
+
+[Feature 20030417] Automatic BCC recipients depending on sender or
+recipient address. The configuration parameters in question are
+"sender_bcc_maps" and "recipient_bcc_maps". See postconf(5).
+
+[Incompat 20030415] Too many people mess up their net/mask patterns,
+causing open mail relay problems. Postfix processes now abort when
+given a net/mask pattern with a non-zero host portion (for example,
+168.100.189.2/28), and suggest to specify the proper net/mask
+pattern instead (for example, 168.100.189.0/28).
+
+[Feature 20030415] Workaround for file system clock drift that
+caused Postfix to ignore new mail (this could happen with file
+systems mounted from a server). Postfix now logs a warning and
+proceeds with only slightly reduced performance, instead of ignoring
+new mail.
+
+Major changes - database support
+--------------------------------
+
+Liviu Daia took the lead in a revision of the LDAP, MySQL and
+PostgreSQL clients. Credits also go to Victor Duchovni and to
+Lamont Jones.
+
+[Feature 20030915] LDAP parameters can now be defined in external
+files. Specify the LDAP maps in main.cf as
+ ldap:/path/to/ldap.cf
+and write the LDAP parameters in /path/to/ldap.cf, without the
+"ldapsource_" prefix. This makes it possible to securely store
+bind passwords for plain auth outside of main.cf (which must be
+world readable). The old syntax still works, for backwards
+compatibility.
+
+[Feature 20030915] Support for LDAP URLs in the LDAP parameter
+"server_host", if Postfix is linked against OpenLDAP. LDAP hosts,
+ports, and connection protocols to be used as LDAP sources can be
+specified as a blank-separated list of LDAP URLs in "server_host".
+As with OpenLDAP, specifying a port in a LDAP URL overrides
+"server_port". Examples:
+ server_host = ldap://ldap.itd.umich.edu
+ server_host = ldaps://ldap.itd.umich.edu:636
+ server_host = ldapi://%2Fsome%2Fpath
+
+[Feature 20030915] The LDAP SSL scheme ldaps:// is available if
+OpenLDAP was compiled with SSL support. New parameters "tls_ca_cert_dir",
+"tls_ca_cert_file", "tls_cert", "tls_key", "tls_require_cert",
+"tls_random_file", "tls_cipher_suite" control the certificates,
+source of random numbers, and cipher suites used for SSL connections.
+See LDAP_README for further information.
+
+[Feature 20030915] Support for STARTTLS command in LDAP, if Postfix
+is linked against OpenLDAP and OpenLDAP was compiled with SSL
+support. STARTTLS is controlled by the "start_tls" parameter.
+The above parameters for certificates, source of random numbers,
+and cipher suites also apply. See LDAP_README for further information.
+
+[Incompat 20030704] Support for client side LDAP caching is gone.
+OpenLDAP 2.1.13 and later no longer support it, and the feature
+never worked well. Postfix now ignores cache controlling parameters
+in an LDAP configuration file and logs a warning.
+
+[Feature 20030415] PostgreSQL table lookups. Specify "pgsql:/file/name"
+where "/file/name" defines the database. See "man pgsql_table" for
+examples, and the PGSQL_README file for general information.
+
+Major changes - internals
+-------------------------
+
+[Incompat 20040120] The format of the postfix-files file has changed.
+There is a new type for hard links. With hard or symbolic link
+entries, the first field is now the destination pathname and the
+"owner" field is now the origin pathname, while "group" and
+"permissions" are ignored.
+
+[Incompat 20040120] The LDAP and SQL client source code is moved
+to the global directory in order to eliminate reversed dependencies.
+
+[Feature 20030606] Complete rewrite of the queue file record reading
+loops in the pickup, cleanup and in the queue manager daemons. This
+code had deteriorated over time. The new code eliminates an old
+problem where the queue manager had to read most queue file records
+twice in the case of an alias/include file expansion with more than
+qmgr_message_recipient_limit recipients.
+
+[Feature 20030125] Code cleanup up of queue manager internals.
+Queue names are no longer mixed up with the next-hop destination,
+and the address resolver loop is now easier to understand.
+
+[Feature 20030104] Multi-server daemons (servers that accept
+simultaneous connections from multiple clients) will now stop
+accepting new connections after serving $max_use clients. This
+allows multi-server daemons to automatically restart even on busy
+mail systems.
+
+[Feature 20030104] Clients of multi-server daemons such as
+trivial-rewrite and the new proxymap service now automatically
+disconnect after $ipc_ttl seconds of activity (default: 1000s).
+This allows multi-server daemons to automatically restart even on
+busy mail systems.
+
+[Incompat 20021119] The file format of bounce/defer logfiles has
+changed from the old one-line ad-hoc format to a more structured
+multi-line format. For backwards compatibility, Postfix now creates
+bounce/defer logfile entries that contain both the old and the new
+format, so that you can go back to an older Postfix release without
+losing information. Old Postfix versions will warn about malformed
+logfile entries, but should work properly. To disable backwards
+compatibility specify "backwards_bounce_logfile_compatibility =
+no" in main.cf.
+
+[Feature 20021119] Both "sendmail -bv" and "sendmail -v" use the
+new "trace" daemon that is automatically added to master.cf when
+you upgrade.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20040413] The postmap and postalias commands now report
+errors to syslogd in addition to reporting them to the standard
+error output. This makes logfile analysis easier.
+
+[Incompat 20031203] Many SMTPD "reject" logfile entries now show
+NOQUEUE instead of a queue ID. This is because Postfix no longer
+creates a queue file before the SMTP server has received a valid
+recipient.
+
+Major changes - lookup table support
+------------------------------------
+
+[Feature 20030704] New CIDR-based lookup table, remotely based on
+code by Jozsef Kadlecsik. For details and examples, see "man
+cidr_table".
+
+[Feature 20030704] The TCP-based table lookup protocol is finished.
+For details and examples, see "man tcp_table". This will allow you
+to implement your own greylisting, or to do your own open proxy
+tests before accepting mail. This table will not be included with
+Postfix 2.1 because the protocol is obsoleted by the policy delegation
+(see elsewhere in this document) which does a much better job.
+
+[Feature 20030704] Support for !/pattern/ (negative matches) in
+PCRE lookup tables by Victor Duchovni. See "man pcre_table" and
+"man regexp_table" for more.
+
+Major changes - resource control
+--------------------------------
+
+[Incompat 20031022] The Postfix SMTP server no longer accepts mail
+when the amount of free queue space is less than 1.5 times the
+message_size_limit value.
+
+Major changes - security
+------------------------
+
+[Incompat 20040413] The Postfix SMTP server no longer accepts mail
+from or to an address ending in "@", including address forms that
+rewrite into an address that ends in "@"). Specify "resolve_null_domain
+= yes" to get the old behavior.
+
+[Incompat 20040331] Support for the non-standard Errors-To: message
+header is removed. This also helps to stop potential attacks that
+rely on bouncing mail to a destination that is not directly reachable
+by the attacker. Specify ""enable_errors_to = yes" to get the old
+behavior.
+
+[Incompat 20040331] Tarpit delays are reduced. The Postfix SMTP
+server no longer delays responses until the client has made
+$smtpd_soft_error_limit errors, and the delay is fixed at
+$smtpd_error_sleep_time seconds. Postfix still disconnects after
+$smtpd_hard_error_limit errors.
+
+[Incompat 20040120] The SMTP server can reject non-existent sender
+addresses in a local, virtual or relay domain; specify
+"reject_unlisted_sender=yes" in order to require that a sender
+address passes the same "user unknown" test as a recipient would
+have to pass. This is optional in Postfix 2.1, likely to be turned
+on by default in Postfix 2.2.
+
+[Incompat 20031226] Postfix no longer allows mail addresses with
+bare numeric IP addresses (user@1.2.3.4). This is not configurable.
+The form user@[ipaddress] is still allowed.
+
+[Incompat 20030305] Postfix truncates non-address information in message
+address headers (comments, etc.) to 250 characters per address, in
+order to protect vulnerable Sendmail systems against exploitation
+of a remote buffer overflow problem (CERT advisory CA-2003-07).
+
+[Incompat 20030227] The smtpd_hard_error_limit and smtpd_soft_error_limit
+values now behave as documented, that is, smtpd_hard_error_limit=1
+causes Postfix to disconnect upon the first client error. Previously,
+there was an off-by-one error causing Postfix to change behavior
+after smtpd_hard/soft_error_limit+1 errors.
+
+Major changes - smtp client
+---------------------------
+
+[Incompat 20031223] The SMTP client now tries to connect to an
+alternate MX address when a delivery attempt fails **after the
+initial SMTP handshake**. This includes both broken connections
+and 4XX SMTP replies. To get the old behavior, specify
+"smtp_mx_session_limit = 1" in main.cf.
+
+[Feature 20031223] The SMTP client now tries to connect to an
+alternate MX address when a delivery attempt fails after the
+initial SMTP handshake. This includes both broken connections
+and 4XX SMTP replies.
+
+As a benefit, fallback_relay now works as promised, not just for
+sessions that fail during the initial handshake.
+
+The new SMTP client connection management is controlled by two new
+configuration parameters:
+
+- smtp_mx_address_limit (default unlimited): the number of MX (mail
+ exchanger) IP addresses that can result from mail exchanger
+ lookups.
+
+- smtp_mx_session_limit (default 2): the number of SMTP sessions
+ per delivery request before giving up or delivering to a fall-back
+ relay, ignoring IP addresses that fail to complete the SMTP
+ initial handshake.
+
+[Incompat 20031022] Postfix no longer retries delivery when no MX
+host has a valid A record, for compatibility with many other MTAs.
+This change is made in anticipation of a possible Verisign "wild-card
+MX record without A record" for unregistered domains. To get the
+old behavior, specify "smtp_defer_if_no_mx_address_found = yes".
+
+[Incompat 20031022] The Postfix SMTP client no longer looks in
+/etc/hosts by default. To get the old behavior, specify
+"smtp_host_lookup = dns, native".
+
+[Feature 20030417] Support for sending mail to hosts not in the
+DNS, without having to turn off DNS lookups. The "smtp_host_lookup"
+parameter controls how the Postfix SMTP client looks up hosts. In
+order to use /etc/hosts besides DNS, specify "smtp_host_lookup =
+dns, native". The default is to use DNS only.
+
+Major changes - user interface
+------------------------------
+
+[Incompat 20040418] The non-delivery report format has changed.
+The "sorry" message and the DSN formatted report now include the
+original recipient address, when that address is different from
+the final recipient address. This makes it easier to diagnose some
+mail delivery problems that happen after mail forwarding.
+
+[Incompat 20031223] In mailq (queue listing) output, there no longer
+is space between a short queue ID and the "*" (delivery in progress)
+or ! (mail on hold) status indicator. This makes the output easier
+to parse.
+
+[Incompat 20030417] "sendmail -t" no longer complains when recipients
+are given on the command line. Instead, it now adds recipients from
+headers to the recipients from the command-line.
+
+[Incompat 20030126] The maildir file naming algorithm has changed
+according to an updated version of http://cr.yp.to/proto/maildir.html.
+The name is now TIME.VdevIinum.HOST
+
+[Incompat 20021119] The behavior of "sendmail -v" has changed. One
+-v option now produces one email report with the status of each
+recipient. Multiple -v options behave as before: turn on verbose
+logging in the sendmail and postdrop commands.
+
+[Feature 20021119] New "sendmail -bv" option. Postfix probes the
+specified recipient addresses without actually delivering mail,
+and sends back an email delivery report. This is useful for testing
+address rewriting and address routing of both envelope and header
+addresses. This feature currently does not access or update the
+sender address verification database.
+
diff --git a/RELEASE_NOTES-2.10 b/RELEASE_NOTES-2.10
new file mode 100644
index 0000000..1140ce1
--- /dev/null
+++ b/RELEASE_NOTES-2.10
@@ -0,0 +1,268 @@
+The stable Postfix release is called postfix-2.10.x where 2=major
+release number, 10=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.11-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 2.8 or earlier, read RELEASE_NOTES-2.9
+before proceeding.
+
+Major changes - laptop-friendliness
+-----------------------------------
+
+[Incompat 20120924] Postfix no longer uses FIFOs to emulate UNIX-domain
+sockets on Solaris 9 (Vintage 2002!) and later. If you install
+Postfix for the first time on an older Solaris system, edit the
+master.cf file and replace "unix" with "fifo" for the pickup and
+qmgr services.
+
+[Feature 20120924] the default master.cf file now uses "unix" instead
+of "fifo" for the pickup and qmgr services. This avoids periodic
+disk drive spin-up.
+
+Major changes - permit logging
+------------------------------
+
+[Feature 20120303] [Feature 20120303] New control for "permit"
+logging in smtpd_mumble_restrictions (by default, the SMTP server
+logs "reject" actions but not "permit" actions). Specify
+"smtpd_log_access_permit_actions = static:all" to log all "permit"-style
+actions, or specify a list of explicit action names. More details
+are in the postconf(5) manpage.
+
+Major changes - postconf
+------------------------
+
+[Incompat 20121224] The postconf command produces more warnings:
+
+- An attempt to modify a read-only parameter (process_name, process_id)
+ in main.cf or master.cf.
+
+- An undefined $name in a parameter value in main.cf or master.cf
+ (except for backwards-compatibility parameters such as $virtual_maps).
+
+[Feature 20121224] The postconf command has been updated to make
+trouble-shooting (and support) easier. In summary, use "postconf
+-Mxf" and "postconf -nxf" to review master.cf and main.cf parameter
+settings with expanded parameter values.
+
+- "postconf -x" now expands $name in main.cf and master.cf parameter
+ values.
+
+- postconf warns about attempts to modify a read-only parameter
+ (process_name, process_id) in main.cf or master.cf.
+
+- postconf warns about an undefined $name in a parameter value in
+ main.cf or master.cf (except for backwards-compatibility parameters
+ such as $virtual_maps).
+
+[Feature 20121227]
+
+- "postconf -o name=value" overrides main.cf parameter settings.
+ This can be used, for example, to examine stress-dependent settings
+ with "postconf -x -o stress=yes".
+
+Major changes - postscreen
+--------------------------
+
+[Incompat 20121123] The postscreen deep protocol tests now log the
+last command before a protocol error ("UNIMPLEMENTED" when the last
+command is not implemented, "CONNECT" when there was no prior
+command). The changed logfile messages are:
+
+NON-SMTP COMMAND from [address]:port after command: text
+BARE NEWLINE from [address]:port after command
+COMMAND TIME LIMIT from [address]:port after command
+COMMAND COUNT LIMIT from [address]:port after command
+COMMAND LENGTH LIMIT from [address]:port after command
+
+Major changes - load-balancer support
+-------------------------------------
+
+[Incompat 20120625] The postscreen(8)-to-smtpd(8) protocol has
+changed. To avoid "cannot receive connection attributes" warnings
+and dropped connections, execute the command "postfix reload". No
+mail will be lost as long as the remote SMTP client tries again
+later.
+
+[Feature 20120625] Support for upstream proxy agent in the postscreen(8)
+and smtpd(8) daemons. To enable the haproxy protocol, specify one
+of the following:
+
+ postscreen_upstream_proxy_protocol = haproxy
+ smtpd_upstream_proxy_protocol = haproxy
+
+Note 1: smtpd_upstream_proxy_protocol can't be used in smtpd processes
+that are behind postscreen. Configure postscreen_upstream_proxy_protocol
+instead.
+
+Note 2: To use the nginx proxy with smtpd(8), enable the XCLIENT
+protocol with smtpd_authorized_xclient_hosts. This supports SASL
+authentication in the proxy agent (Postfix 2.9 and later).
+
+Major changes - relay safety
+----------------------------
+
+[Incompat 20130613] New smtpd_relay_restrictions parameter built-in
+default settings:
+
+ smtpd_relay_restrictions =
+ permit_mynetworks
+ permit_sasl_authenticated
+ defer_unauth_destination
+
+This safety net prevents open relay problems due to mistakes
+with spam filter rules in smtpd_recipient_restrictions.
+
+If your site has a complex mail relay policy configured under
+smtpd_recipient_restrictions, this safety net may defer mail that
+Postfix should accept.
+
+To fix this safety net, take one of the following actions:
+
+- Set smtpd_relay_restrictions empty, and keep using the existing
+ mail relay authorization policy in smtpd_recipient_restrictions.
+
+- Copy the existing mail relay authorization policy from
+ smtpd_recipient_restrictions to smtpd_relay_restrictions.
+
+There is no need to change the value of smtpd_recipient_restrictions.
+
+[Feature 20130613] This version introduces the smtpd_relay_restrictions
+feature for mail relay control. The new built-in default settings
+are:
+
+ smtpd_relay_restrictions =
+ permit_mynetworks
+ permit_sasl_authenticated
+ defer_unauth_destination
+
+ smtpd_recipient_restrictions =
+ ( optional spam blocking rules would go here )
+
+For comparison, this is the Postfix before 2.10 default:
+
+ smtpd_recipient_restrictions =
+ permit_mynetworks
+ reject_unauth_destination
+ ( optional spam blocking rules would go here )
+
+With Postfix versions before 2.10, the mail relay policy and spam
+blocking policy were combined under smtpd_recipient_restrictions,
+resulting in error-prone configuration.
+
+As of Postfix 2.10, the mail relay policy is preferably implemented
+with smtpd_relay_restrictions, so that a permissive spam blocking
+policy under smtpd_recipient_restrictions will not unexpectedly
+result in a permissive mail relay policy.
+
+As of Postfix 2.10.0 the smtpd_relay_restrictions parameter built-in
+default settings are:
+
+ smtpd_relay_restrictions =
+ permit_mynetworks
+ permit_sasl_authenticated
+ defer_unauth_destination
+
+If your site has a complex mail relay policy configured under
+smtpd_recipient_restrictions, this safety net may defer mail that
+Postfix should accept.
+
+To migrate from an earlier Postfix release with the least amount
+of pain:
+
+- Set smtpd_relay_restrictions empty, and keep using the existing
+ mail relay authorization policy in smtpd_recipient_restrictions.
+
+- There is no need to change the value of smtpd_recipient_restrictions.
+
+To take advantage of the new smtpd_relay_restrictions feature:
+
+- Copy the existing mail relay authorization policy from
+ smtpd_recipient_restrictions to smtpd_relay_restrictions.
+
+- There is no need to change the value of smtpd_recipient_restrictions.
+
+Major changes - start-up
+------------------------
+
+[Feature 20120306] New master "-w" option, to wait for master daemon
+process initialization to complete. This feature returns an error
+exit status if master daemon initialization fails, or if it does
+not complete in a reasonable amount of time. The exit status is
+used by "postfix start" to provide more accurate information to
+system start-up scripts.
+
+Major changes - tls
+-------------------
+
+[Incompat 20130203] Thanks to OpenSSL documentation, the Postfix
+2.9.0..2.9.5 SMTP client and server server used an incorrect procedure
+to compute TLS certificate PUBLIC-KEY fingerprints (these may be
+used in the check_ccert_access and in smtp_tls_policy_maps features).
+Support for certificate PUBLIC-KEY finger prints was introduced
+with Postfix 2.9; there is no known problem with the certificate
+fingerprint algorithms available since Postfix 2.2.
+
+Certificate PUBLIC-KEY finger prints may be used in the Postfix
+SMTP server (with "check_ccert_access") and in the Postfix SMTP
+client (with the "fingerprint" security level).
+
+Specify "tls_legacy_public_key_fingerprints = yes" temporarily,
+pending a migration from configuration files with incorrect Postfix
+2.9.0..2.9.5 certificate PUBLIC-KEY finger prints, to the correct
+fingerprints used by Postfix 2.9.6 and later.
+
+To compute the correct PUBLIC-KEY finger prints:
+
+# OpenSSL 1.0 with all certificates and SHA-1 fingerprints.
+$ openssl x509 -in cert.pem -noout -pubkey | \
+ openssl pkey -pubin -outform DER | \
+ openssl dgst -sha1 -c
+
+# OpenSSL 0.9.8 with RSA certificates and MD5 fingerprints.
+$ openssl x509 -in cert.pem -noout -pubkey | \
+ openssl rsa -pubin -outform DER | \
+ openssl dgst -md5 -c
+
+[Feature 20120422] This release adds support to turn off the TLSv1.1
+and TLSv1.2 protocols. Introduced with OpenSSL version 1.0.1, these
+are known to cause inter-operability problems with for example
+hotmail.
+
+The radical workaround is to temporarily turn off problematic
+protocols globally:
+
+/etc/postfix/main.cf:
+ smtp_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
+ smtp_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
+
+ smtpd_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
+ smtpd_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
+
+However, it may be better to temporarily turn off problematic
+protocols for broken sites only:
+
+/etc/postfix/main.cf:
+ smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
+
+/etc/postfix/tls_policy:
+ example.com may protocols=!SSLv2:!TLSv1.1:!TLSv1.2
+
+Important:
+
+- Note the use of ":" instead of comma or space. Also, note that
+ there is NO space around the "=" in "protocols=".
+
+- The smtp_tls_policy_maps lookup key must match the "next-hop"
+ destination that is given to the Postfix SMTP client. If you
+ override the next-hop destination with transport_maps, relayhost,
+ sender_dependent_relayhost_maps, or otherwise, you need to specify
+ the same destination for the smtp_tls_policy_maps lookup key.
diff --git a/RELEASE_NOTES-2.11 b/RELEASE_NOTES-2.11
new file mode 100644
index 0000000..2cf3939
--- /dev/null
+++ b/RELEASE_NOTES-2.11
@@ -0,0 +1,280 @@
+The stable Postfix release is called postfix-2.11.x where 2=major
+release number, 11=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.12-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 2.9 or earlier, read RELEASE_NOTES-2.10
+before proceeding.
+
+Major changes - tls
+-------------------
+
+[Documentation 20131218] The new FORWARD_SECRECY_README document
+conveniently presents all information about Postfix "perfect" forward
+secrecy support in one place: what forward secrecy is, how to tweak
+settings, and what you can expect to see when Postfix uses ciphers
+with forward secrecy.
+
+[Feature 20130602] Support for PKI-less TLS server certificate
+verification, where the CA public key or the server certificate is
+identified via DNSSEC lookup.
+
+This feature introduces new TLS security levels called "dane" and
+"dane-only" (DNS-based Authentication of Named Entities) that use
+DNSSEC to look up CA or server certificate information. The details
+of DANE core protocols are still evolving, as are the details of
+how DANE should be used in the context of SMTP. Postfix implements
+what appears to be a "rational" subset of the DANE profiles that
+is suitable for SMTP.
+
+The problem with conventional PKI is that there are literally
+hundreds of organizations world-wide that can provide a certificate
+in anyone's name. There have been widely-published incidents in
+recent history where a certificate authority gave out an inappropriate
+certificate (e.g., a certificate in the name of Microsoft to someone
+who did not represent Microsoft), where a CA was compromised (e.g.,
+DigiNotar, Comodo), or where a CA made operational mistakes (e.g.,
+TURKTRUST). Another concern is that a legitimate CA might be coerced
+to provide a certificate that allows its government to play
+man-in-the-middle on TLS traffic and observe the plaintext.
+
+Major changes - LMDB database support
+-------------------------------------
+
+LMDB is a memory-mapped database that was originally developed as
+part of OpenLDAP. The Postfix LMDB driver was originally contributed
+by Howard Chu, LMDB's creator.
+
+LMDB can be used for all Postfix lookup tables and caches. It is
+the first persistent Postfix database that can be shared among
+multiple writers such as postscreen daemons (Postfix already supported
+shared non-persistent memcached caches). See lmdb_table(5) and
+LMDB_README for further information, including how to access Postfix
+LMDB databases with non-Postfix programs.
+
+Postfix currently requires LMDB version 0.9.11 or later. The minimum
+version may change over time in the light of deployment experience.
+
+Major changes - postscreen whitelisting
+---------------------------------------
+
+[Feature 20130512] Allow a remote SMTP client to skip postscreen(8)
+tests based on its postscreen_dnsbl_sites score.
+
+Specify a negative "postscreen_dnsbl_whitelist_threshold" value to
+enable this feature. When a client passes the threshold value
+without having failed other tests, all pending or disabled tests
+are flagged as completed.
+
+This feature can mitigate the email delays due to "after 220 greeting"
+protocol tests, which otherwise require that a client reconnects
+before it can deliver mail. Some providers such as Google don't
+retry from the same IP address. This can result in large email
+delivery delays.
+
+Major changes - recipient_delimiter
+-----------------------------------
+
+[Feature 20130405] The recipient_delimiter parameter can now specify
+a set of characters. A user name is now separated from its address
+extension by the first character that matches the recipient_delimiter
+set.
+
+For example, specify "recipient_delimiter = +-" to support both the
+Postfix-style "+" and the qmail-style "-" extension delimiter.
+
+As before, this implementation recognizes one delimiter character
+per email address, and one address extension per email address.
+
+Major changes - smtpd access control
+------------------------------------
+
+[Feature 20131031] The check_sasl_access feature can be used to
+block hijacked logins. Like other check_mumble_access features it
+queries a lookup table (in this case with the SASL login name), and
+it supports the same actions as any Postfix access(5) table.
+
+[Feature 20130924] The reject_known_sender_login_mismatch feature
+applies reject_sender_login_mismatch only to MAIL FROM addresses
+that are known in $smtpd_sender_login_maps.
+
+Major changes - MacOS X
+-----------------------
+
+[Feature 20130325] Full support for kqueue() event handling which
+scales better with large numbers of file handles, plus a workaround
+for timeout handling on file handles (such as /dev/urandom) that
+still do not correctly support poll().
+
+Major changes - master
+----------------------
+
+[Incompat 20131217] The master_service_disable parameter value
+syntax has changed: use "service/type" instead of "service.type".
+The new form is consistent with postconf(1) namespaces for master.cf.
+The old form is still supported to avoid breaking existing
+configurations.
+
+Major changes - milter
+----------------------
+
+[Feature 20131126] Support for ESMTP parameters "NOTIFY" and "ORCPT"
+in the SMFIR_ADDRCPT_PAR (add recipient with parameters) request.
+Credits: Andrew Ayer.
+
+Major changes - mysql
+---------------------
+
+[Feature 20131117] MySQL client support for option_file, option_group,
+tls_cert_file, tls_key_file, tls_CAfile, tls_CApath, tls_verify_cert.
+Credits: Gareth Palmer.
+
+Major changes - postconf
+------------------------
+
+[Feature 20131217] Support for advanced master.cf query and update
+operations. This was implemented primarily to support automated
+system management tools.
+
+The goal is to make all Postfix master.cf details accessible as
+lists of "name=value" pairs, where the names are organized into
+structured name spaces. This allows other programs to query
+information or request updates, without having to worry about the
+exact layout of master.cf files.
+
+Managing master.cf service attributes
+-------------------------------------
+
+First, an example that shows the smtp/inet service in the traditional
+form:
+
+ $ postconf -M smtp/inet
+ smtp inet n - n - - smtpd
+
+Different variants of this command show different amounts of output.
+For example, "postconf -M smtp" enumerates all services that have
+a name "smtp" and any service type ("inet", "unix", etc.), and
+"postconf -M" enumerates all master.cf services.
+
+General rule: each name component that is not present becomes a "*"
+wildcard.
+
+Coming back to the above example, the postconf -F option can now
+enumerate the smtp/inet service fields as follows:
+
+ $ postconf -F smtp/inet
+ smtp/inet/service = smtp
+ smtp/inet/type = inet
+ smtp/inet/private = n
+ smtp/inet/unprivileged = -
+ smtp/inet/chroot = n
+ smtp/inet/wakeup = -
+ smtp/inet/process_limit = -
+ smtp/inet/command = smtpd
+
+This form makes it very easy to change one field in master.cf.
+For example to turn on chroot on the smtp/inet service you use:
+
+ $ postconf -F smtp/inet/chroot=y
+ $ postfix reload
+
+Moreover, with "-F" you can specify "*" for service name or service
+type to get a wild-card match. For example, to turn off chroot on
+all Postfix daemons, use this:
+
+ $ postconf -F '*/*/chroot=n'
+ $ postfix reload
+
+Managing master.cf service "-o parameter=value" settings
+--------------------------------------------------------
+
+For a second example, let's look at the submission service. This
+service typically has multiple "-o parameter=value" overrides. First
+the traditional view:
+
+ $ postconf -Mf submission
+ submission inet n - n - - smtpd
+ -o smtpd_tls_security_level=encrypt
+ -o smtpd_sasl_auth_enable=yes
+ ...
+
+The postconf -P option can now enumerate these parameters as follows:
+
+ $ postconf -P submission
+ submission/inet/smtpd_sasl_auth_enable = yes
+ submission/inet/smtpd_tls_security_level = encrypt
+ ...
+
+Again, this form makes it very easy to modify one parameter
+setting. For example, to change the smtpd_tls_security_level setting
+for the submission/inet service:
+
+ $ postconf -P 'submission/inet/smtpd_tls_security_level=may'
+
+You can create or remove a parametername=parametervalue setting:
+
+Create:
+ $ postconf -P 'submission/inet/parametername=parametervalue'
+
+Remove:
+ $ postconf -PX submission/inet/parametername
+
+Finally, always execute "postfix reload" after updating master.cf.
+
+Managing master.cf service entries
+----------------------------------
+
+Finally, adding master.cf entries is possible, but currently this
+does not yet have "advanced" support. It can only be done at the
+level of the traditional master.cf file format.
+
+Suppose that you need to configure a Postfix SMTP client that will
+handle slow email deliveries. To implement this you need to clone
+the smtp/unix service settings and create a new delay/unix service.
+
+First, you would enumerate the smtp/unix service like this:
+
+ $ postconf -M smtp/unix
+ smtp unix - - n - - smtp
+
+Then you would copy those fields (except the first field) by hand
+to create the delay/unix service:
+
+ $ postconf -M delay/unix="delay unix - - n - - smtp"
+
+To combine the above steps in one command:
+
+ $ postconf -M delay/unix="`postconf -M smtp/unix|awk '{$1 = "delay"}'`"
+
+This is perhaps not super-convenient for manual cloning, but it
+should be sufficient for programmatic configuration management.
+
+Again, always execute "postfix reload" after updating master.cf.
+
+Deleting or commenting out master.cf entries
+--------------------------------------------
+
+The -X (delete entry) and -# (comment out entry) options already
+exist for main.cf, and they now also work work for entire master.cf
+entries:
+
+Remove main.cf or master.cf entry:
+ $ postconf -X parametername
+ $ postconf -MX delay/unix
+
+Comment out main.cf or master.cf entry:
+ $ postconf -# parametername
+ $ postconf -M# delay/unix
+
+As with main.cf, there is no support to "undo" master.cf changes
+that are made with -X or -#.
+
+Again, always execute "postfix reload" after updating master.cf.
diff --git a/RELEASE_NOTES-2.2 b/RELEASE_NOTES-2.2
new file mode 100644
index 0000000..e7e2cd8
--- /dev/null
+++ b/RELEASE_NOTES-2.2
@@ -0,0 +1,443 @@
+The stable Postfix release is called postfix-2.2.x where 2=major
+release number, 2=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.3-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+Main changes with Postfix version 2.2
+-------------------------------------
+
+This is a summary of the changes. These and more are detailed in
+the following sections of this document.
+
+- TLS and IPv6 support are now built into Postfix, based on code
+from third-party patches.
+
+- Extended query interface for LDAP, MySQL and PostgreSQL with free
+form SQL queries, and domain filters to reduce unnecessary lookups.
+
+- SMTP client-side connection reuse. This can dramatically speed
+up deliveries to high-volume destinations that have some servers
+that respond, and some non-responding mail servers.
+
+- By default, Postfix no longer rewrites message headers in mail
+from remote clients. This includes masquerading, canonical mapping,
+replacing "!" and "%" by "@", and appending the local domain to
+incomplete addresses. Thus, spam from poorly written software no
+longer looks like it came from a local user.
+
+- When your machine does not have its own domain name, Postfix can
+now replace your "home network" email address by your ISP account
+in outgoing SMTP mail, while leaving your email address unchanged
+when sending mail to someone on the local machine.
+
+- Compatibility workarounds: you can now selectively turn off ESMTP
+features such as AUTH or STARTTLS in the Postfix SMTP client or
+server, without having to "dumb down" other mail deliveries, and
+without having to use transport maps for outgoing mail.
+
+- Remote SMTP client resource control (the anvil server). This
+allows you to limit the number of connections, or the number of
+MAIL FROM and RCPT TO commands that an SMTP client can send per
+unit time.
+
+- Support for CDB, SDBM and NIS+ databases is now built into Postfix
+(but the CDB and SDBM libraries are not).
+
+- New SMTP access control features, and more.
+
+Major changes - critical
+------------------------
+
+BEFORE upgrading from an older release you MUST stop Postfix, unless
+you're running a Postfix 2.2 snapshot release that already has
+Postfix 2.2 IPV6 and TLS support.
+
+AFTER upgrading from an older release DO NOT copy the old
+master.cf/main.cf files over the new files. Instead, you MUST let
+the Postfix installation procedure update the existing configuration
+files with new service entries.
+
+[Incompat 20041118] The master-child protocol has changed. The
+Postfix master daemon will log warnings about partial status updates
+if you don't stop and start Postfix.
+
+[Incompat 20041023, 20041009] The queue manager to delivery agent
+protocol has changed. Mail will remain queued if you do not restart
+the queue manager.
+
+[Incompat 20050111] The upgrade procedure adds the tlsmgr service
+to the master.cf file. This service entry is not compatible with
+the Postfix/TLS patch.
+
+[Feature 20040919] The upgrade procedure adds the discard service
+to the master.cf file.
+
+[Feature 20040720] The upgrade procedure adds the scache (shared
+connection cache) service to the master.cf file.
+
+Major changes - IPv6 support
+----------------------------
+
+[Feature 20050111] Postfix version 2.2 IP version 6 support based
+on the Postfix/IPv6 patch by Dean Strik and others. IPv6 support
+is always compiled into Postfix on systems that have Postfix
+compatible IPv6 support. On other systems Postfix will simply use
+IP version 4 just like it did before. See the IPV6_README document
+for what systems are supported, and how to turn on IPv6 in main.cf.
+
+[Incompat 20050111] Postfix version 2.2 IPv6 support differs from
+the Postfix/IPv6 patch by Dean Strik in a few minor ways.
+
+- Network protocol support including DNS lookup is selected with
+the inet_protocols parameter instead of the inet_interfaces parameter.
+This is needed so that Postfix will not attempt to deliver mail via
+IPv6 when the system has no IPv6 connectivity.
+
+- The lmtp_bind_address6 feature was omitted. The Postfix LMTP
+client will be absorbed into the SMTP client, so there is no reason
+to keep adding features to the LMTP client.
+
+- The CIDR-based address matching code was rewritten. The new
+behavior is believed to be closer to expectation. The results may
+be incompatible with that of the Postfix/IPv6 patch.
+
+[Incompat 20050117] The Postfix SMTP server now requires that IPv6
+addresses in SMTP commands are specified as [ipv6:ipv6address], as
+described in RFC 2821.
+
+Major changes - TLS support
+---------------------------
+
+[Feature 20041210] Postfix version 2.2 TLS support, based on the
+Postfix/TLS patch by Lutz Jaenicke. TLS support is not compiled
+in by default. For more information about Postfix 2.2 TLS support,
+see the TLS_README document.
+
+[Incompat 20041210] Postfix version 2.2 TLS support differs from
+the Postfix/TLS patch by Lutz Jaenicke in a few minor ways.
+
+- main.cf: Use btree instead of sdbm for TLS session cache databases.
+
+ Session caches are now accessed only by the tlsmgr(8) process,
+ so there are no concurrency issues. Although Postfix still has
+ an SDBM client, the SDBM library (1000 lines of code) is no longer
+ included with Postfix.
+
+ TLS session caches can use any database that can store objects
+ of several kbytes or more, and that implements the sequence
+ operation. In most cases, btree databases should be adequate.
+
+ NOTE: You cannot use dbm databases. TLS session objects are too
+ large.
+
+- master.cf: Specify unix instead of fifo for the tlsmgr service type.
+ This change is automatically made by the Postfix upgrade procedure.
+
+ The smtp(8) and smtpd(8) processes use a client-server protocol
+ in order to access the tlsmgr(8)'s pseudo-random number generation
+ (PRNG) pool, and in order to access the TLS session cache databases.
+ Such a protocol cannot be run across fifos.
+
+[Feature 20050209] The Postfix SMTP server policy delegation protocol
+now supplies TLS client certificate information after successful
+verification. The new policy delegation protocol attribute names
+are ccert_subject, ccert_issuer and ccert_fingerprint.
+
+[Feature 20050208] New "check_ccert_maps maptype:mapname" feature
+to enforce access control based on hexadecimal client certificate
+fingerprints.
+
+Major changes - SMTP client connection cache
+--------------------------------------------
+
+[Feature 20040720] SMTP client-side connection caching. Instead of
+disconnecting immediately after a mail transaction, the Postfix
+SMTP client can save the open connection to the scache(8) connection
+cache daemon, so that any SMTP client process can reuse that session
+for another mail transaction. See the CONNECTION_CACHE_README
+document for a description of configuration and implementation.
+
+This feature introduces the scache (connection cache) server, which
+is added to your master.cf file when you upgrade Postfix.
+
+[Feature 20040729] Opportunistic SMTP connection caching. When a
+destination has a high volume of mail in the active queue, SMTP
+connection caching is enabled automatically. This is controlled
+with a new configuration parameter "smtp_connection_cache_on_demand"
+(default: yes).
+
+[Feature 20040723] Per-destination SMTP connection caching. This
+is enabled with the smtp_connection_cache_destinations parameter.
+The parameter requires "bare" domain names or IP addresses without
+"[]" or TCP port, to avoid a syntax conflict between host:port and
+maptype:mapname entries.
+
+[Feature 20040721] The scache(8) connection cache manager logs cache
+hit and miss statistics every $connection_cache_status_update_time
+seconds (default: 600s). It reports the hit and miss rates for
+lookups by domain, as well as for lookups by network address.
+
+Major changes - address rewriting
+---------------------------------
+
+[Feature 20050206] Support for address rewriting in outgoing SMTP
+mail (headers and envelopes). This is useful for sites that have a
+fantasy Internet domain name such as localdomain.local. Mail
+addresses that use fantasy domain names are often rejected by mail
+servers.
+
+The smtp_generic_maps feature allows you to replace a local mail
+address (user@localdomain.local) by a valid Internet address
+(account@isp.example) when mail is sent across the Internet. The
+feature has no effect on mail that is sent between accounts on the
+local machine. The syntax is described in generic(5) and a detailed
+example is in the STANDARD_CONFIGURATION_README document, the section
+titled "Postfix on hosts without a real Internet hostname".
+
+[Feature 20041023] By default, Postfix no longer rewrites message
+headers in mail from remote clients. This includes masquerading,
+canonical mapping, replacing "!" and "%" by "@", and appending the
+local domain to incomplete addresses. Thus, spam from poorly written
+software no longer looks like it came from a local user.
+
+By default, Postfix rewrites message header addresses only when the
+client IP address matches the local machine's interface addresses,
+or when mail is submitted with the Postfix sendmail(1) command.
+
+Postfix rewrites message headers in mail from other clients only
+when the remote_header_rewrite_domain parameter specifies a domain
+name (such as "domain.invalid"); this domain is appended to incomplete
+addresses. Rewriting also includes masquerading, canonical mapping,
+and replacing "!" and "%" by "@".
+
+To get the behavior before Postfix 2.2 (always append Postfix's own
+domain to incomplete addresses in message headers, always subject
+message headers to canonical mapping, address masquerading, and
+always replace "!" and "%" by "@") specify:
+
+/etc/postfix/main.cf:
+ local_header_rewrite_clients = static:all
+
+If you must rewrite headers in mail from specific clients then you
+can specify, for example,
+
+/etc/postfix/main.cf:
+ local_header_rewrite_clients = permit_mynetworks,
+ permit_sasl_authenticated, permit_tls_clientcerts,
+ check_address_map hash:/etc/postfix/pop-before-smtp
+
+Postfix always appends local domain information to envelope addresses
+(as opposed to header addresses), because an unqualified envelope
+address is effectively local for the purpose of delivery, and for
+the purpose of replying to it.
+
+Full details are given in ADDRESS_REWRITING_README, and in the
+postconf(5) manual. For best results, point your browser at the
+ADDRESS_REWRITING_README.html file and navigate to the section
+titled " To rewrite message headers or not, or to label as invalid".
+
+[Incompat 20050212] When header address rewriting is enabled, Postfix
+now updates a message header only when at least one address in that
+header is modified. Older Postfix versions first parse and then
+un-parse a header so that there may be subtle changes in formatting,
+such as the amount of whitespace between tokens.
+
+[Incompat 20050227] Postfix no longer changes message header labels.
+Thus, FROM: or CC: are no longer replaced by From: or Cc:.
+
+[Feature 20040827] Finer control over canonical mapping with
+canonical_classes, sender_canonical_classes and
+recipient_canonical_classes. These specify one or more of
+envelope_sender, header_sender, envelope_recipient or header_recipient.
+The default settings are backwards compatible.
+
+Major changes - SMTP compatibility controls
+-------------------------------------------
+
+[Feature 20041218] Fine control for SMTP inter-operability problems,
+by discarding keywords that are sent or received with the EHLO
+handshake. Typically one would discard "pipelining", "starttls",
+or "auth" to work around systems with a broken implementation.
+Specify a list of EHLO keywords with the smtp(d)_discard_ehlo_keywords
+parameters, or specify one or more lookup tables, indexed by remote
+network address, with the smtp(d)_discard_ehlo_keyword_address_maps
+parameters.
+
+Note: this feature only discards words from the EHLO conversation;
+it does not turn off the actual features in the SMTP server.
+
+Major changes - database support
+--------------------------------
+
+[Feature 20050209] Extended LDAP, MySQL and PgSQL query interface
+with free form SQL queries, the domain filter optimization that was
+already available with LDAP and more. This code was worked on by
+many people but Victor Duchovni took the lead. See the respective
+{LDAP,MYSQL,PGSQL}_README and {ldap,mysql,pgsql}_table documents.
+
+[Feature 20041210] You can now dump an entire database with the new
+postmap/postalias "-s" option. This works only for database types
+with Postfix sequence operator support: hash, btree, dbm, and sdbm.
+
+[Feature 20041208] Support for CDB databases by Michael Tokarev.
+This supports both Michael's tinycdb and Daniel Bernstein's cdb
+implementations, but neither of the two implementations is bundled
+with Postfix.
+
+[Feature 20041023] The NIS+ client by Geoff Gibbs is now part of
+the Postfix source tree. Details are given in the nisplus_table(5)
+manual page.
+
+[Feature 20040827] Easier use of the proxymap(8) service with the
+virtual(8) delivery agent. The virtual(8) delivery agent will
+silently open maps directly when those maps can't be proxied for
+security reasons. This means you can now specify "virtual_mailbox_maps
+= proxy:mysql:whatever" without triggering a fatal error in the
+virtual(8) delivery agent.
+
+Major changes - remote SMTP client resource control
+---------------------------------------------------
+
+[Incompat 20041009] The smtpd_client_connection_limit_exceptions
+parameter is renamed to smtpd_client_event_limit_exceptions. Besides
+connections it now also applies to per-client message rate and
+recipient rate limits.
+
+[Feature 20041009] Per SMTP client message rate and recipient rate
+limits. These limit the number of MAIL FROM or RCPT TO requests
+regardless of whether or not Postfix would have accepted them
+otherwise. The user interface (smtpd_client_message_rate_limit and
+smtpd_client_recipient_rate_limit) is similar to that of the existing
+per SMTP client connection rate limit, and the same warnings apply:
+these features are to be used to stop abuse, and must not be used
+to regulate legitimate mail. More details can be found in the
+postconf(5) manual.
+
+Major changes - remote SMTP client access control
+-------------------------------------------------
+
+[Feature 20050209] The Postfix SMTP server policy delegation protocol
+now supplies TLS client certificate information after successful
+verification. The new policy delegation protocol attribute names
+are ccert_subject, ccert_issuer and ccert_fingerprint.
+
+[Feature 20050208] New "check_ccert_maps maptype:mapname" feature
+to enforce access control based on hexadecimal client certificate
+fingerprints.
+
+[Feature 20050203] New "permit_inet_interfaces" access restriction
+to allow access from local IP addresses only. This is used for the
+default, purist, setting of local_header_rewrite_clients (rewrite
+only headers in mail from this machine).
+
+[Feature 20050203] New "sleep time-in-seconds" pseudo access
+restriction to block zombie clients with reject_unauthorized_pipelining
+before the Postfix SMTP server sends the SMTP greeting. See postconf(5)
+for example. This feature is not available the stable Postfix 2.2
+release, but it is documented here so that it will not get lost.
+
+[Feature 20041118] New "smtpd_end_of_data_restrictions" feature
+that is invoked after the client terminates the SMTP DATA command.
+The syntax is the same as with "smtpd_data_restrictions". In the
+SMTPD policy delegation request, the message size is the actual
+byte count of the message content, instead of the message size
+announced by the client in the MAIL FROM command.
+
+Major changes - SASL authentication
+-----------------------------------
+
+[Feature 20040827] Better SMTP client control over the use of SASL
+mechanisms. New smtp_sasl_mechanism_filter mechanism to shorten the
+list of SASL mechanisms from a remote server to just those that the
+local SASL library can actually use.
+
+Major changes - header/body patterns
+------------------------------------
+
+[Feature 20050205] REPLACE action in header_checks and body_checks,
+to replace a message header or body line. See header_checks(5) for
+details.
+
+Major changes - local delivery
+------------------------------
+
+[Feature 20040621] Control over the working directory when executing
+an external command. With the pipe(8) mailer, specify directory=pathname,
+and with local(8) specify "command_execution_directory = expression"
+where "expression" is subject to $home etc. macro expansion. The
+result of macro expansion is restricted by the set of characters
+specified with execution_directory_expansion_filter.
+
+Major changes - mail delivery attributes
+----------------------------------------
+
+[Feature 20041218] More client attributes for delivery to command
+with the local(8) and pipe(8) delivery agents: client_hostname,
+client_address, client_protocol, client_helo, sasl_method, sasl_sender,
+and sasl_username. With local(8), attribute names must be specified
+in upper case.
+
+Major changes - package creation
+--------------------------------
+
+[Feature 20050203] To create a ready-to-install package for
+distribution to other systems you can now use "make package" or
+"make non-interactive-package", instead of invoking the internal
+postfix-install script by hand. See the PACKAGE_README file for
+details.
+
+Major changes - performance
+---------------------------
+
+[Incompat 20050117] Only the deferred and defer queue directories
+are now hashed by default, instead of eight queue directories. This
+may speed up Postfix boot time on low-traffic systems without
+compromising performance under high load too much. Hashing must be
+turned on for the defer and deferred queue directories, because
+those directories contain lots of files when undeliverable mail is
+backing up.
+
+[Incompat 20040720] The default SMTP/LMTP timeouts for sending RSET
+are reduced to 20s.
+
+Major changes - miscellaneous
+-----------------------------
+
+[Feature 20050203] Safety: Postfix no longer tries to send mail to
+the fallback_relay when the local machine is MX host for the mail
+destination. See the postconf(5) description of the fallback_relay
+feature for details.
+
+[Incompat 20041023] Support for the non-standard Errors-To: return
+addresses is now removed from Postfix. It was already disabled by
+default with Postfix version 2.1. Since Errors-To: is non-standard,
+there was no guarantee that it would have the desired effect with
+other MTAs.
+
+[Feature 20040919] A new discard(8) mail delivery agent that makes
+throwing away mail easier and more efficient. It's the Postfix
+equivalent of /dev/null for mail deliveries. On the mail receiving
+side, Postfix already has a /dev/null equivalent in the form of the
+DISCARD action in access maps and header_body_checks.
+
+[Feature 20040919] Access control for local mail submission, for
+listing the queue, and for flushing the queue. These features are
+controlled with authorized_submit_users, authorized_mailq_users,
+and with authorized_flush_users, respectively. The last two controls
+are always permitted for the super-user and for the mail system
+owner. More information is in the postconf(5) manual.
+
+[Incompat 20040829] When no recipients are specified on the command
+line or via the -t option, the Postfix sendmail command terminates
+with status EX_USAGE and produces an error message instead of
+accepting the mail first and bouncing it later. This gives more
+direct feedback in case of a common client configuration error.
+
diff --git a/RELEASE_NOTES-2.3 b/RELEASE_NOTES-2.3
new file mode 100644
index 0000000..a1ac8c0
--- /dev/null
+++ b/RELEASE_NOTES-2.3
@@ -0,0 +1,761 @@
+The stable Postfix release is called postfix-2.3.x where 2=major
+release number, 3=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.4-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+Critical notes
+--------------
+
+See RELEASE_NOTES_2.2 if you upgrade from Postfix 2.1 or earlier.
+
+Some Postfix internal protocols have changed. You need to "postfix
+reload" or restart Postfix, otherwise many servers will log warning
+messages like "unexpected attribute xxx" or "problem talking to
+service yyy", and mail will not be delivered.
+
+The Sendmail-compatible Milter support introduces three new queue
+file record types. As long as you leave this feature turned off,
+you can still go back to Postfix version 2.2 without losing mail
+that was received by Postfix 2.3.
+
+Major changes - DNS lookups
+---------------------------
+
+[Incompat 20050726] Name server replies that contain a malformed
+hostname are now flagged as permanent errors instead of transient
+errors. This change works around a questionable proposal to use
+syntactically invalid hostnames in MX records.
+
+Major changes - DSN
+-------------------
+
+[Feature 20050615] DSN support as described in RFC 3461 .. RFC 3464.
+This gives senders control over successful and failed delivery
+notifications. DSN involves extra parameters to the SMTP "MAIL
+FROM" and "RCPT TO" commands, as well as extra Postfix sendmail
+command line options for mail submission.
+
+See DSN_README for details. Some implementation notes can be found
+in implementation-notes/DSN.
+
+[Incompat 20050615] The new DSN support conflicts with VERP support.
+For Sendmail compatibility, Postfix now uses the sendmail -V command
+line option for DSN. To request VERP style delivery, you must now
+specify -XV instead of -V. The Postfix sendmail command will
+recognize if you try to use -V for VERP-style delivery. It will
+usually do the right thing, and remind you of the new syntax.
+
+[Incompat 20050828] Postfix no longer sends DSN SUCCESS notification
+after virtual alias expansions when the cleanup server rejects the
+content or size of mail that was submitted with the Postfix sendmail
+command, mail that was forwarded with the local(8) delivery agent,
+or mail that was re-queued with "postsuper -r". Since all the
+recipients are reported as failed, the SUCCESS notification seems
+redundant.
+
+Major changes - LMTP client
+---------------------------
+
+See the "SASL authentication" and "TLS" sections for changes related
+to SASL authentication and TLS support, respectively.
+
+[Feature 20051208] The SMTP client now implements the LMTP protocol.
+Most but not all smtp_xxx parameters now have an lmtp_xxx equivalent.
+This means there are lot of new LMTP features, including support
+for TLS and for the shared connection cache. See the "SMTP client"
+section for details.
+
+[Incompat 20051208] The LMTP client now reports the server as
+"myhostname[/path/name]". With the real server hostname in delivery
+status reports, the information will be more useful.
+
+Major changes - Milter support
+------------------------------
+
+[Feature 20060515] Milter (mail filter) application support,
+compatible with Sendmail version 8.13.6 and earlier. This allows
+you to run a large number of plug-ins to reject unwanted mail, and
+to sign mail with for example domain keys. All Milter functions are
+implemented except replacing the message body, which will be added
+later. Milters are before-queue filters, so they don't change the
+queue ID.
+
+See the MILTER_README document for a discussion of how to use Milter
+support with Postfix, and limitations of the current implementation.
+
+The Sendmail-compatible Milter support introduces three new queue
+file record types. As long as you leave this feature turned off,
+you can still go back to Postfix version 2.2 without losing mail
+that was received by Postfix 2.3.
+
+[Incompat 20060515] Milter support introduces new logfile event
+types: milter-reject, milter-discard and milter-hold, that identify
+actions from Milter applications. This may affect logfile processing
+software.
+
+Major changes - SASL authentication
+-----------------------------------
+
+[Feature 20051220] Plug-in support for SASL authentication in the
+SMTP server and in the SMTP/LMTP client. With this, Postfix can
+support multiple SASL implementations without source code patches.
+Some distributors may even make SASL support a run-time linking
+option, just like they already do with Postfix lookup tables.
+
+Hints and tips for plug-in developers are in the xsasl/README file.
+
+For backwards compatibility the default plug-in type is Cyrus SASL,
+so everything should behave like it did before. Some error messages
+are slightly different, but these are generally improvements.
+
+The "postconf -a" command shows what plug-in implementations are
+available for the SMTP server, and "postconf -A" does the same for
+the SMTP/LMTP client. Plug-in implementations are selected with
+the smtpd_sasl_type, smtp_sasl_type and lmtp_sasl_type configuration
+parameters.
+
+Other new configuration parameters are smtpd_sasl_path, smtp_sasl_path
+and lmtp_sasl_path. These are better left alone; they are introduced
+for the convenience of other SASL implementations.
+
+[Feature 20051222] Dovecot SASL support (SMTP server only). Details
+can be found in the SASL_README document.
+
+[Incompat 20051220] The Postfix-with-Cyrus-SASL build procedure has
+changed. You now need to specify -DUSE_CYRUS_SASL in addition to
+-DUSE_SASL_AUTH or else you end up without any Cyrus SASL support.
+The error messages are:
+
+ unsupported SASL server implementation: cyrus
+ unsupported SASL client implementation: cyrus
+
+[Feature 20051125] This snapshot adds support for sender-dependent
+ISP accounts.
+
+- Sender-dependent smarthost lookup tables. The maps are searched
+ with the sender address and with the sender @domain. The result
+ overrides the global relayhost setting, but otherwise has identical
+ behavior. See the postconf(5) manual page for more details.
+
+ Example:
+ /etc/postfix/main.cf:
+ sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
+
+- Sender-dependent SASL authentication support. This disables SMTP
+ connection caching to ensure that mail from different senders
+ will use the correct authentication credentials. The SMTP SASL
+ password file is first searched by sender address, and then by
+ the remote domain and hostname as usual.
+
+ Example:
+ /etc/postfix/main.cf:
+ smtp_sasl_auth_enable = yes
+ smtp_sender_dependent_authentication = yes
+ smtp_sasl_password_maps = hash:/etc/postfix/sasl_pass
+
+[Incompat 20060707] The SMTP/LMTP client now defers delivery when
+a SASL password exists but the server does not announce support for
+SASL authentication. This can happen with servers that announce
+SASL support only when TLS is turned on. When an opportunistic TLS
+handshake fails, Postfix >= 2.3 retries delivery in plaintext, and
+the remote server rejects mail from the unauthenticated client.
+Specify "smtp_sasl_auth_enforce = no" to deliver mail anyway.
+
+Major changes - SMTP client
+---------------------------
+
+See the "SASL authentication" and "TLS" sections for changes related
+to SASL authentication and TLS support, respectively.
+
+[Feature 20051208] The SMTP client now implements the LMTP protocol.
+Most but not all smtp_xxx parameters now have an lmtp_xxx equivalent.
+This means there are lot of new LMTP features, including support
+for TLS and for the shared connection cache.
+
+[Incompat 20060112] The Postfix SMTP/LMTP client by default no
+longer allows DNS CNAME records to override the server hostname
+that is used for logging, SASL password lookup, TLS policy selection
+and TLS server certificate verification. Specify
+"smtp_cname_overrides_servername = yes" to get the old behavior.
+
+[Incompat 20060103] The Postfix SMTP/LMTP client no longer defers
+mail delivery when it receives a malformed SMTP server reply in a
+session with command pipelining. When helpful warnings are enabled,
+it will suggest that command pipelining be disabled for the affected
+destination.
+
+[Incompat 20051208] The fallback_relay feature is renamed to
+smtp_fallback_relay, to make clear that the combined SMTP/LMTP
+client uses this setting only for SMTP deliveries. The old name
+still works.
+
+[Incompat 20051106] The relay=... logging has changed and now
+includes the remote SMTP server port number as hostname[hostaddr]:port.
+
+[Incompat 20051026] The smtp_connection_cache_reuse_limit parameter
+(which limits the number of deliveries per SMTP connection) is
+replaced by the new smtp_connection_reuse_time_limit parameter (the
+time after which a connection is no longer stored into the connection
+cache).
+
+[Feature 20051026] This snapshot addresses a performance stability
+problem with remote SMTP servers. The problem is not specific to
+Postfix: it can happen when any MTA sends large amounts of SMTP
+email to a site that has multiple MX hosts. The insight that led
+to the solution, as well as an initial implementation, are due to
+Victor Duchovni.
+
+The problem starts when one of a set of MX hosts becomes slower
+than the rest. Even though SMTP clients connect to fast and slow
+MX hosts with equal probability, the slow MX host ends up with more
+simultaneous inbound connections than the faster MX hosts, because
+the slow MX host needs more time to serve each client request.
+
+The slow MX host becomes a connection attractor. If one MX host
+becomes N times slower than the rest, it dominates mail delivery
+latency unless there are more than N fast MX hosts to counter the
+effect. And if the number of MX hosts is smaller than N, the mail
+delivery latency becomes effectively that of the slowest MX host
+divided by the total number of MX hosts.
+
+The solution uses connection caching in a way that differs from
+Postfix 2.2. By limiting the amount of time during which a connection
+can be used repeatedly (instead of limiting the number of deliveries
+over that connection), Postfix not only restores fairness in the
+distribution of simultaneous connections across a set of MX hosts,
+it also favors deliveries over connections that perform well, which
+is exactly what we want.
+
+The smtp_connection_reuse_time_limit feature implements the connection
+reuse time limit as discussed above. It limits the amount of time
+after which an SMTP connection is no longer stored into the connection
+cache. The default limit, 300s, can result in a huge number of
+deliveries over a single connection.
+
+This solution will be complete when Postfix logging is updated to
+include information about the number of times that a connection was
+used. This information is needed to diagnose inter-operability
+problems with servers that exhibit bugs when they receive multiple
+messages over the same connection.
+
+[Incompat 20050627] The Postfix SMTP client no longer applies the
+smtp_mx_session_limit to non-permanent errors during the TCP, SMTP,
+HELO or TLS handshake. Previous versions did that only with TCP
+and SMTP handshake errors.
+
+[Incompat 20050622] The Postfix SMTP client by default limits the
+number of MX server addresses to smtp_mx_address_limit=5. Previously
+this limit was disabled by default. The new limit prevents Postfix
+from spending lots of time trying to connect to lots of bogus MX
+servers.
+
+Major changes - SMTP server
+---------------------------
+
+See the "SASL authentication" and "TLS" sections for changes related
+to SASL authentication and TLS support, respectively.
+
+[Feature 20051222] To accept the non-compliant user@ipaddress form,
+specify "resolve_numeric_domain = yes". Postfix will deliver the
+mail to user@[ipaddress] instead.
+
+[Incompat 20051202] The Postfix SMTP server now refuses to receive
+mail from the network if it isn't running with postfix mail_owner
+privileges. This prevents surprises when, for example, "sendmail
+-bs" is configured to run as root from xinetd.
+
+[Incompat 20051121] Although the permit_mx_backup feature still
+accepts mail for authorized destinations (see permit_mx_backup for
+definition), with all other destinations it now requires that the
+local MTA is listed as non-primary MX server. This prevents mail
+loop problems when someone points their primary MX record at a
+Postfix system.
+
+[Feature 20051011] Optional suppression of remote SMTP client
+hostname lookup and hostname verification. Specify "smtpd_peername_lookup
+= no" to eliminate DNS lookup latencies, but do so only under extreme
+conditions, as it makes Postfix logging less informative.
+
+[Feature 20050724] SMTPD Access control based on the existence of
+an address->name mapping, with reject_unknown_reverse_client_hostname.
+There is no corresponding access table lookup feature, because the
+name is not validated in any way (except that it has proper syntax).
+
+Several confusing SMTPD access restrictions were renamed:
+
+ reject_unknown_client -> reject_unknown_client_hostname,
+ reject_unknown_hostname -> reject_unknown_helo_hostname,
+ reject_invalid_hostname -> reject_invalid_helo_hostname,
+ reject_non_fqdn_hostname -> reject_non_fqdn_helo_hostname.
+
+The old names are still recognized and documented.
+
+Major changes - TLS
+-------------------
+
+Major revisions were made to Postfix TLS support; see TLS_README
+for the details. For backwards compatibility, the old TLS policy
+user interface will be kept intact for a few releases so that sites
+can upgrade Postfix without being forced to use a different TLS
+policy mechanism.
+
+[Feature 20060614] New concept: TLS security levels ("none", "may",
+"encrypt", "verify" or "secure") in the Postfix SMTP client. You
+can specify the TLS security level via the smtp_tls_security_level
+parameter. This is more convenient than controlling TLS with the
+multiple smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername,
+parameters.
+
+[Feature 20060709] TLS security levels ("none", "may", "encrypt")
+in the Postfix SMTP server. You specify the security level with the
+smtpd_tls_security_level parameter. This overrides the multiple
+smtpd_use_tls and smtpd_enforce_tls parameters. When one of the
+unimplemented "verify" or "secure" levels is specified, the Postfix
+SMTP server logs a warning and uses "encrypt" instead.
+
+[Feature 20060123] A new per-site TLS policy mechanism for the
+Postfix SMTP client that supports the new TLS security levels,
+and that eliminates DNS spoofing attacks more effectively.
+
+[Feature 20060626] Both the Postfix SMTP client and server can be
+configured without a client or server certificate. An SMTP server
+without certificate can use only anonymous ciphers, and will not
+inter-operate with most clients.
+
+The Postfix SMTP server supports anonymous ciphers when 1) no client
+certificates are requested or required, and 2) the administrator
+has not excluded the "aNULL" OpenSSL cipher type with the
+smtpd_tls_exclude_ciphers parameter.
+
+The Postfix SMTP client supports anonymous ciphers when 1) no server
+certificate is required and 2) the administrator has not excluded
+the "aNULL" OpenSSL cipher type with the smtp_tls_exclude_ciphers
+parameter.
+
+[Incompat 20060707] The SMTPD policy client now encodes the
+ccert_subject and ccert_issuer attributes as xtext. Some characters
+are represented by +XX, where XX is the two-digit hexadecimal
+representation of the character value.
+
+[Feature 20060614] The smtpd_tls_protocols parameter restricts the
+list of TLS protocols supported by the SMTP server. This is
+recommended for use with MSA configurations only. It should not
+be used with MX hosts that receive mail from the Internet, as it
+reduces inter-operability.
+
+[Incompat 20060614] The smtp_tls_cipherlist parameter only applies
+when TLS is mandatory. It is ignored with opportunistic TLS sessions.
+
+[Incompat 20060614] At (lmtp|smtp|smtpd)_tls_loglevel >= 2, Postfix
+now also logs TLS session cache activity. Use level 2 and higher
+for debugging only; use levels 0 or 1 as production settings.
+
+[Incompat 20060207] The Postfix SMTP server no longer complains
+when TLS support is not compiled in while permit_tls_clientcerts,
+permit_tls_all_clientcerts, or check_ccert_access are specified in
+main.cf. These features now are effectively ignored. However, the
+reject_plaintext_session feature is not ignored and will reject
+plain-text mail.
+
+[Feature 20060123] Some obscure behavior was eliminated from the
+smtp_tls_per_site feature, without changes to the user interface.
+Some Postfix internals had to be re-structured for the new TLS
+policy mechanism; for this, smtp_tls_per_site had to be re-implemented.
+The obscure behavior was found during compatibility testing.
+
+[Feature 20051011] Optional protection against SMTP clients that
+hammer the server with too many new (i.e. uncached) SMTP-over-TLS
+sessions. Cached sessions are much less expensive in terms of CPU
+cycles. Use the smtpd_client_new_tls_session_rate_limit parameter
+to specify a limit that is at least the inbound client concurrency
+limit, or else you may deny legitimate service requests.
+
+Major changes - VERP
+--------------------
+
+[Incompat 20050615] The new DSN support conflicts with VERP support.
+For Sendmail compatibility, Postfix now uses the sendmail -V command
+line option for DSN. In order to request VERP style delivery, you
+must now specify -XV instead of -V. The Postfix sendmail command
+will recognize if you try to use -V for VERP-style delivery. It
+will do the right thing and will remind you of the new syntax.
+
+Major changes - XCLIENT and XFORWARD
+------------------------------------
+
+[Incompat 20060611] The SMTP server XCLIENT implementation has
+changed. The SMTP server now resets state to the initial server
+greeting stage, immediately before the EHLO/HELO greeting. This
+was needed to correctly simulate the effect of connection-level
+access restrictions. Without this change, XCLIENT would not work
+at all with Milter applications.
+
+[Incompat 20060611] The SMTP server XCLIENT and XFORWARD commands
+now expect that attributes are xtext encoded (RFC 1891). For backwards
+compatibility they will also accept unencoded attribute values. The
+XFORWARD client code in the SMTP client and in the SMTPD_PROXY
+client now always encode attribute values. This change will have a
+visible effect only for malformed hostname and helo parameter values.
+
+For more details, see the XCLIENT_README and XFORWARD_README
+documents.
+
+Major changes - address manipulation
+------------------------------------
+
+[Incompat 20060123] Postfix now preserves uppercase information
+while mapping addresses with canonical, virtual, relocated or generic
+maps; this happens even with $number substitutions in regular
+expression maps. However, the local(8) and virtual(8) delivery
+agents still fold addresses to lower case.
+
+As a side effect, Postfix now also does a better job at being case
+insensitive where it should be, for example while searching per-host
+TLS policies or SASL passwords.
+
+By default, Postfix now folds the search string to lowercase only
+with tables that have fixed-case lookup fields such as btree:,
+hash:, dbm:, ldap:, or *sql:. The search string is no longer case
+folded with tables whose lookup fields can match both upper or lower
+case, such as regexp:, pcre:, or cidr:.
+
+For safety reasons, Postfix no longer allows $number substitution
+in regexp: or pcre: transport tables or per-sender relayhost tables.
+
+Major changes - bounce message templates
+----------------------------------------
+
+[Feature 20051113] Configurable bounce messages, based on a format
+that was developed by Nicolas Riendeau. The file with templates is
+specified with the bounce_template_file parameter. Details are in
+the bounce(5) manual page, and examples of the built-in templates
+can be found in $config_directory/bounce.cf.default. The template
+for the default bounce message looks like this:
+
+ failure_template = <
+
+ If you do so, please include this problem report. You can
+ delete your own text from the attached returned message.
+
+ The $mail_name program
+ EOF
+
+Major changes - built-in filters
+--------------------------------
+
+[Feature 20050828] Configurable filters to reject or remove unwanted
+characters in email content. The message_reject_characters and
+message_strip_characters parameters understand the usual C-like
+escape sequences: \a \b \f \n \r \t \v \ddd (up to three octal
+digits) and \\.
+
+[Incompat 20050828] When a header/body_checks rule or when
+message_reject_characters rejects mail that was submitted with the
+Postfix sendmail command (or re-queued with "postsuper -r"), the
+returned message is now limited to just the message headers, to
+avoid the risk of exposure to harmful content in the message body
+or attachments.
+
+Major changes - database support
+--------------------------------
+
+[Incompat 20060611] The PostgreSQL client was updated after the
+PostgreSQL developers made major database API changes in response
+to SQL injection problems. This breaks support for PGSQL versions
+prior to 8.1.4, 8.0.8, 7.4.13, and 7.3.15. Support for these requires
+major code changes which are not possible in the time that is left
+for completing the Postfix 2.3 stable release.
+
+Major changes - enhanced status codes
+-------------------------------------
+
+[Feature 20050328] This release introduces support for RFC 3463
+enhanced status codes. For example, status code 5.1.1 means
+"recipient unknown". Postfix recognizes enhanced status codes in
+remote server replies, generates enhanced status codes while handling
+email, and reports enhanced status codes in non-delivery notifications.
+This improves the user experience with mail clients that translate
+enhanced status codes into text in the user's own language.
+
+You can, but don't have to, specify RFC 3463 enhanced status codes
+in the output from commands that receive mail from a pipe. If a
+command terminates with non-zero exit status, and an enhanced status
+code is present at the beginning of the command output, then that
+status code takes precedence over the non-zero exit status.
+
+You can, but don't have to, specify RFC 3463 enhanced status codes
+in Postfix access maps, header/body_checks REJECT actions, or in
+RBL replies. For example:
+
+ REJECT 5.7.1 You can't go here from there
+
+The status 5.7.1 means "no authorization, message refused", and is
+the default for access maps, header/body_checks REJECT actions, and
+for RBL replies.
+
+[Feature 20050328] If you specify your own enhanced status code,
+the Postfix SMTP server will automatically change a leading '5'
+digit (hard error) into '4' where appropriate. This is needed, for
+example, with soft_bounce=yes.
+
+[Feature 20050510] This release improves usability of enhanced
+status codes in Postfix access tables, RBL reply templates and in
+transport maps that use the error(8) delivery agent.
+
+- When the SMTP server rejects a sender address, it transforms a
+ recipient DSN status (e.g., 4.1.1-4.1.6) into the corresponding
+ sender DSN status, and vice versa.
+
+- When the SMTP server rejects non-address information (such as the
+ HELO command parameter or the client hostname/address), it
+ transforms a sender or recipient DSN status into a generic
+ non-address DSN status (e.g., 4.0.0).
+
+These transformations are needed when the same access table or RBL
+reply template are used for client, helo, sender, or recipient
+restrictions; or when the same error(8) mailer information is used
+for both senders and recipients.
+
+Major changes - local alias expansion
+-------------------------------------
+
+[Incompat 20051011] The Postfix local(8) delivery agent no longer
+updates its idea of the Delivered-To: address while it expands
+aliases or .forward files. With deeply nested aliases or .forward
+files, this can greatly reduce the number of queue files and cleanup
+process instances. To get the earlier behavior, specify
+"frozen_delivered_to = no".
+
+The frozen_delivered_to feature can help to alleviate a long-standing
+problem with multiple deliveries to recipients that are listed
+multiple times in a hierarchy of nested aliases. For this to work,
+only the top-level alias should have an owner- alias, and none of
+the subordinate aliases.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20060515] Milter support introduces new logfile event
+types: milter-reject, milter-discard and milter-hold, that identify
+actions from Milter applications. This may affect logfile processing
+software.
+
+[Incompat 20051106] The relay=... logging has changed and now
+includes the remote SMTP server port number as hostname[hostaddr]:port.
+
+[Incompat 20060112] The Postfix SMTP/LMTP client by default no
+longer allows DNS CNAME records to override the server hostname
+that is used for logging, SASL password lookup, TLS policy selection
+and TLS server certificate verification. Specify
+"smtp_cname_overrides_servername = yes" to get the old behavior.
+
+[Incompat 20051105] All delay logging now has sub-second resolution,
+including the over-all "delay=nnn" logging. A patch is available
+for pflogsumm (pflogsumm-conn-delays-dsn-patch). The qshape script
+has been updated (auxiliary/qshape/qshape.pl).
+
+[Feature 20051103] This release makes a beginning with a series of
+new attributes in Postfix logfile records.
+
+- Better insight into the nature of performance bottle necks, with
+ detailed logging of delays in various stages of message delivery.
+ Postfix logs additional delay information as "delays=a/b/c/d"
+ where a=time before queue manager, including message transmission;
+ b=time in queue manager; c=connection setup time including DNS,
+ HELO and TLS; d=message transmission time.
+
+- Logging of the connection reuse count when SMTP connections are
+ used for more than one message delivery. This information is
+ needed because Postfix can now reuse connections hundreds of times
+ or more. Logging of the connection reuse count can help to diagnose
+ inter-operability problems with servers that suffer from memory
+ leaks or other resource leaks.
+
+At this point the Postfix logging for a recipient looks like this:
+
+ Nov 3 16:04:31 myname postfix/smtp[30840]: 19B6B2900FE:
+ to=, orig_to=,
+ relay=mail.example.com[1.2.3.4], conn_use=2, delay=0,
+ delays=0/0.01/0.05/0.1, dsn=2.0.0, status=sent (250 2.0.0 Ok)
+
+The following two logfile fields may or may not be present:
+
+ orig_to This is omitted when the address did not change.
+ conn_use This is omitted when a connection is used once.
+
+[Incompat 20050503] The format of some "warning:" messages in the
+maillog has changed so that they are easier to sort:
+
+- The logging now talks about "access table", instead of using three
+ different expressions "access table", "access map" and "SMTPD
+ access map" for the same thing.
+
+- "non-SMTP command" is now logged BEFORE the client name/address
+ and the offending client input, instead of at the end.
+
+[Incompat 20050328] The logging format has changed. Postfix delivery
+agents now log the RFC 3463 enhanced status code as "dsn=x.y.z"
+where y and z can be up to three digits each.
+
+[Incompat 20051208] The LMTP client now reports the server as
+"myhostname[/path/name]". With the real server hostname in delivery
+status reports, the information will be more useful.
+
+Major changes - performance
+---------------------------
+
+[Incompat 20051105] All delay logging now has sub-second resolution,
+including the over-all "delay=nnn" logging. A patch is available
+for pflogsumm (pflogsumm-conn-delays-dsn-patch). The qshape script
+has been updated (auxiliary/qshape/qshape.pl).
+
+[Incompat 20050622] The Postfix SMTP client by default limits the
+number of MX server addresses to smtp_mx_address_limit=5. Previously
+this limit was disabled by default. The new limit prevents Postfix
+from spending lots of time trying to connect to lots of bogus MX
+servers.
+
+[Feature 20051026] This snapshot addresses a performance stability
+problem with remote SMTP servers. The problem is not specific to
+Postfix: it can happen when any MTA sends large amounts of SMTP
+email to a site that has multiple MX hosts. The insight that led
+to the solution, as well as an initial implementation, are due to
+Victor Duchovni.
+
+The problem starts when one of a set of MX hosts becomes slower
+than the rest. Even though SMTP clients connect to fast and slow
+MX hosts with equal probability, the slow MX host ends up with more
+simultaneous inbound connections than the faster MX hosts, because
+the slow MX host needs more time to serve each client request.
+
+The slow MX host becomes a connection attractor. If one MX host
+becomes N times slower than the rest, it dominates mail delivery
+latency unless there are more than N fast MX hosts to counter the
+effect. And if the number of MX hosts is smaller than N, the mail
+delivery latency becomes effectively that of the slowest MX host
+divided by the total number of MX hosts.
+
+The solution uses connection caching in a way that differs from
+Postfix 2.2. By limiting the amount of time during which a connection
+can be used repeatedly (instead of limiting the number of deliveries
+over that connection), Postfix not only restores fairness in the
+distribution of simultaneous connections across a set of MX hosts,
+it also favors deliveries over connections that perform well, which
+is exactly what we want.
+
+The smtp_connection_reuse_time_limit feature implements the connection
+reuse time limit as discussed above. It limits the amount of time
+after which an SMTP connection is no longer stored into the connection
+cache. The default limit, 300s, can result in a huge number of
+deliveries over a single connection.
+
+This solution will be complete when Postfix logging is updated to
+include information about the number of times that a connection was
+used. This information is needed to diagnose inter-operability
+problems with servers that exhibit bugs when they receive multiple
+messages over the same connection.
+
+[Feature 20051011] Optional protection against SMTP clients that
+hammer the server with too many new (i.e. uncached) SMTP-over-TLS
+sessions. Cached sessions are much less expensive in terms of CPU
+cycles. Use the smtpd_client_new_tls_session_rate_limit parameter
+to specify a limit that is at least the inbound client concurrency
+limit, or else you may deny legitimate service requests.
+
+[Feature 20051011] Optional suppression of remote SMTP client
+hostname lookup and hostname verification. Specify "smtpd_peername_lookup
+= no" to eliminate DNS lookup latencies, but do so only under extreme
+conditions, as it makes Postfix logging less informative.
+
+Major changes - portability
+---------------------------
+
+[Incompat 20050716] Internal interfaces have changed; this may break
+third-party patches because the types of function arguments and of
+result values have changed. The types of buffer lengths and offsets
+were changed from "int" or "unsigned int" (32 bit on 32-bit and
+LP64 systems) to "ssize_t" or "size_t" (64 bit on LP64 systems, 32
+bit on 32-bit systems).
+
+This change makes no difference in Postfix behavior on 32-bit
+systems. On LP64 systems, however, this change not only eliminates
+some obscure portability bugs, it also eliminates unnecessary
+conversions between 32/64 bit integer types, because many system
+library routines take "(s)size_t" arguments or return "(s)size_t"
+values.
+
+This change may break software on LP64 systems 1) when Postfix is
+linked with pre-compiled code that was compiled with old Postfix
+interface definitions and 2) when compiling Postfix source that was
+modified by a third-party patch: incorrect code will be generated
+when the patch passes the wrong integer argument type in contexts
+that disable automatic argument type conversions. Examples of such
+contexts are formatting with printf-like arguments, and invoking
+functions that write Postfix request or reply attributes across
+inter-process communication channels. Unfortunately, gcc reports
+"(unsigned) int" versus "(s)size_t" format string argument mis-matches
+only on LP64 systems.
+
+Major changes - safety
+----------------------
+
+[Incompat 20051121] Although the permit_mx_backup feature still
+accepts mail for authorized destinations (see permit_mx_backup for
+definition), with all other destinations it now requires that the
+local MTA is listed as non-primary MX. This prevents mail loop
+problems when someone points the primary MX record at a Postfix
+system.
+
+[Incompat 20051011] The Postfix local(8) delivery agent no longer
+updates its idea of the Delivered-To: address while it expands
+aliases or .forward files. With deeply nested aliases or .forward
+files, this can greatly reduce the number of queue files and cleanup
+process instances. To get the earlier behavior, specify
+"frozen_delivered_to = no".
+
+The frozen_delivered_to feature can help to alleviate a long-standing
+problem with multiple deliveries to recipients that are listed
+multiple times in a hierarchy of nested aliases. For this to work,
+only the top-level alias should have an owner- alias, and none of
+the subordinate aliases.
+
+[Incompat 20050828] When a header/body_checks rule or when
+message_reject_characters rejects mail that was submitted with the
+Postfix sendmail command (or re-queued with "postsuper -r"), the
+returned message is now limited to just the message headers, to
+avoid the risk of exposure to harmful content in the message body
+or attachments.
+
+[Incompat 20051202] The Postfix SMTP server now refuses to receive
+mail from the network if it isn't running with postfix mail_owner
+privileges. This prevents surprises when, for example, "sendmail
+-bs" is configured to run as root from xinetd.
+
+[Incompat 20060123] For safety reasons, Postfix no longer allows
+$number substitution in regexp: or pcre: transport tables or
+per-sender relayhost tables.
+
+[Incompat 20060112] The Postfix SMTP/LMTP client by default no
+longer allows DNS CNAME records to override the server hostname
+that is used for logging, SASL password lookup, TLS policy selection
+and TLS server certificate verification. Specify
+"smtp_cname_overrides_servername = yes" to get the old behavior.
diff --git a/RELEASE_NOTES-2.4 b/RELEASE_NOTES-2.4
new file mode 100644
index 0000000..e56972d
--- /dev/null
+++ b/RELEASE_NOTES-2.4
@@ -0,0 +1,198 @@
+The stable Postfix release is called postfix-2.4.x where 2=major
+release number, 4=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.5-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+Major changes - critical
+------------------------
+
+See RELEASE_NOTES-2.3 if you upgrade from Postfix 2.2 or earlier.
+
+[Incompat 20070122] To take advantage of the new support for BSD
+kqueue, Linux epoll, or Solaris /dev/poll, you must restart (not
+reload) Postfix after upgrading from Postfix 2.3.
+
+[Incompat 20061209] If you upgrade Postfix without restarting, you
+MUST execute "postfix reload", otherwise the queue manager may log
+a warnings with:
+
+ warning: connect to transport retry: Connection refused
+
+[Incompat 20061209] The upgrade procedure adds a new "retry" service
+to the master.cf file. If you make the mistake of copying old
+Postfix configuration files over the new files, the queue manager
+may log warnings with:
+
+ warning: connect to transport retry: Connection refused
+
+To fix your master.cf file, use "postfix upgrade-configuration"
+followed by "postfix reload".
+
+Major changes - safety
+----------------------
+
+[Incompat 20070222] As a safety measure, Postfix now by default
+creates mailbox dotlock files on all systems. This prevents problems
+with GNU POP3D which subverts kernel locking by creating a new
+mailbox file and deleting the old one.
+
+Major changes - Milter support
+------------------------------
+
+[Feature 20070121] The support for Milter header modification
+requests was revised. With minimal change in the on-disk representation,
+the code was greatly simplified, and regression tests were updated
+to ensure that old errors were not re-introduced. The queue file
+format is entirely backwards compatible with Postfix 2.3.
+
+[Feature 20070116] Support for Milter requests to replace the message
+body. Postfix now implements all the header/body modification
+requests that are available with Sendmail 8.13.
+
+[Incompat 20070116] A new field is added to the queue file "size"
+record that specifies the message content length. Postfix 2.3 and
+older Postfix 2.4 snapshots will ignore this field, and will report
+the message size as it was before the body was replaced.
+
+Major changes - TLS support
+---------------------------
+
+[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
+attributes (client ccert_subject, ccert_issuer) only after successful
+client certificate verification. The reason is that the certification
+verification status itself is not available in the policy request.
+
+[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
+fingerprint information even when the certificate itself was not
+verified.
+
+[Incompat 20061214] The remote SMTP client TLS certificate fingerprint
+can be used for access control even when the certificate itself was
+not verified.
+
+[Incompat 20061006] The format of SMTP server TLS session cache
+lookup keys has changed. The lookup key now includes the master.cf
+service name.
+
+Major changes - performance
+---------------------------
+
+[Feature 20070212] Better support for systems that run thousands
+of Postfix processes. Postfix now supports FreeBSD kqueue(2),
+Solaris poll(7d) and Linux epoll(4) as more scalable alternatives
+to the traditional select(2) system call, and uses poll(2) when
+examining a single file descriptor for readability or writability.
+These features are supported on sufficiently recent versions of
+FreeBSD, NetBSD, OpenBSD, Solaris and Linux; support for other
+systems will be added as evidence becomes available that usable
+implementations exist.
+
+[Incompat 20070201] Some default settings have been adjusted to
+better match contemporary requirements:
+
+- queue_run_delay and minimal_backoff_time were reduced from 1000s
+ to 300s so that deliveries are retried earlier after the first
+ failure.
+
+- ipc_idle was reduced from 100s to 5s, so that tlsmgr and scache
+ clients will more quickly release unused file handles.
+
+[Feature 20061209] Improved worst-case (old and new) queue manager
+performance when deferring or bouncing large amounts of mail. Instead
+of talking to the bounce or defer service synchronously, this work
+is now done in the background by the error or retry service.
+
+[Feature 20061209] Improved worst-case (new) queue manager performance
+when delivering multi-recipient mail. The queue manager now proactively
+reads recipients from the queue file, instead of waiting for the
+slowest deliveries to complete before reading in new recipients.
+This introduces two parameters: default_recipient_refill_limit (how
+many recipient slots to refill at a time) and
+default_recipient_refill_delay (how long to wait between refill
+operations). These two parameters act as defaults for optional
+per-transport settings.
+
+Major changes - delivery status notifications
+---------------------------------------------
+
+[Incompat 20061209] Small changes were made to the default bounce
+message templates, to prevent HTML-aware software from hiding or
+removing the text "", and producing misleading text.
+
+[Incompat 20060806] Postfix no longer announces its name in delivery
+status notifications. Users believe that Wietse provides a free
+help desk service that solves all their email problems.
+
+Major changes - ETRN support
+----------------------------
+
+[Feature 20061217] More precise queue flushing with the ETRN,
+"postqueue -s site", and "sendmail -qRsite" commands, after
+minimization of race conditions. New per-queue-file flushing with
+"postqueue -i queueid" and "sendmail -qIqueueid".
+
+Major changes - small office/home office support
+------------------------------------------------
+
+[Incompat 20061217] Postfix no longer requires a domain name. It
+uses "localdomain" as the default Internet domain name when no
+domain is specified via main.cf or via the machine's hostname.
+
+Major changes - SMTP access control
+-----------------------------------
+
+[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
+attributes (client ccert_subject, ccert_issuer) only after successful
+client certificate verification. The reason is that the certification
+verification status itself is not available in the policy request.
+
+[Incompat 20061214] The check_smtpd_policy client sends TLS certificate
+fingerprint information even when the certificate itself was not
+verified.
+
+[Incompat 20061214] The remote SMTP client TLS certificate fingerprint
+can be used for
+access control even when the certificate itself was not verified.
+
+[Incompat 20061209] The Postfix installation procedure no longer
+updates main.cf with "unknown_local_recipient_reject_code = 450".
+Four years after the introduction of mandatory recipient validation,
+this transitional tool is no longer neeed.
+
+Major changes - workarounds
+---------------------------
+
+[Incompat 20070222] As a safety measure, Postfix now by default
+creates mailbox dotlock files on all systems. This prevents problems
+with GNU POP3D which subverts kernel locking by creating a new
+mailbox file and deleting the old one.
+
+[Feature 20061209] Better interoperability with non-conforming SMTP
+servers that reply and disconnect before Postfix has sent the
+complete message content.
+
+[Feature 20061209] Better support for queue file systems on file
+servers with drifting clocks. Clock skew can be a problem, because
+Postfix does not deliver mail until the local clock catches up with
+the queue file's last modification time stamp. On systems with
+usable futimes() or equivalent (Solaris, *BSD, MacOS, but not Linux),
+Postfix now always explicitly sets the queue file last modification
+time stamps while creating a queue file. On systems without usable
+futimes() (Linux, and ancient versions of Solaris, SunOS and *BSD)
+Postfix keeps using the slower utime() system call to update queue
+file time stamps when the file system clock is off with respect to
+the local system clock, and logs a warning.
+
+[Feature 20061006] Individual CISCO PIX bug workarounds are now
+on/off configurable. This introduces new parameters: smtp_pix_workarounds
+(default: disable_esmtp, delay_dotcrlf) and smtp_pix_workaround_maps
+(workarounds indexed by server IP address). The default settings
+are backwards compatible.
diff --git a/RELEASE_NOTES-2.5 b/RELEASE_NOTES-2.5
new file mode 100644
index 0000000..f560d3b
--- /dev/null
+++ b/RELEASE_NOTES-2.5
@@ -0,0 +1,376 @@
+The stable Postfix release is called postfix-2.5.x where 2=major
+release number, 5=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.6-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+Incompatibility with Postfix 2.3 and earlier
+--------------------------------------------
+
+If you upgrade from Postfix 2.3 or earlier, read RELEASE_NOTES-2.4
+before proceeding.
+
+Major changes - critical
+------------------------
+
+[Incompat 20071224] The protocol to send Milter information from
+smtpd(8) to cleanup(8) processes was cleaned up. If you use the
+Milter feature, and upgrade a live Postfix system, you may see an
+"unexpected record type" warning from a cleanup(8) server process.
+To prevent this, execute the command "postfix reload". The
+incompatibility affects only systems that use the Milter feature.
+It does not cause loss of mail, just a minor delay until the remote
+SMTP client retries.
+
+[Incompat 20071212] The allow_min_user feature now applies to both
+sender and recipient addresses in SMTP commands. With earlier Postfix
+versions, only recipients were subject to the allow_min_user feature,
+and the restriction took effect at mail delivery time, causing mail
+to be bounced later instead of being rejected immediately.
+
+[Incompat 20071206] The "make install" and "make upgrade" procedures
+now create a Postfix-owned directory for Postfix-writable data files
+such as caches and random numbers. The location is specified with
+the "data_directory" parameter (default: "/var/lib/postfix"), and
+the ownership is specified with the "mail_owner" parameter.
+
+[Incompat 20071206] The tlsmgr(8) and verify(8) servers no longer
+use root privileges when opening the address_verify_map,
+*_tls_session_cache_database, and tls_random_exchange_name cache
+files. This avoids a potential security loophole where the ownership
+of a file (or directory) does not match the trust level of the
+content of that file (or directory).
+
+[Incompat 20071206] The tlsmgr(8) and verify(8) cache files should
+now be stored as Postfix-owned files under the Postfix-owned
+data_directory. As a migration aid, attempts to open these files
+under a non-Postfix directory are redirected to the Postfix-owned
+data_directory, and a warning is logged.
+
+This is an example of the warning messages:
+
+ Dec 6 12:56:22 bristle postfix/tlsmgr[7899]: warning: request
+ to update file /etc/postfix/prng_exch in non-postfix directory
+ /etc/postfix
+
+ Dec 6 12:56:22 bristle postfix/tlsmgr[7899]: warning: redirecting
+ the request to postfix-owned data_directory /var/lib/postfix
+
+If you wish to continue using a pre-existing tls_random_exchange_name
+or address_verify_map file, move it to the Postfix-owned data_directory
+and change ownership from root to Postfix (that is, change ownership
+to the account specified with the mail_owner configuration parameter).
+
+[Feature 20071205] The "make install" and "make upgrade" procedures
+now create a Postfix-owned directory for Postfix-writable data files
+such as caches and random numbers. The location is specified with
+the "data_directory" parameter (default: "/var/lib/postfix"), and
+the ownership is specified with the "mail_owner" parameter.
+
+[Incompat 20071203] The "make upgrade" procedure adds a new service
+"proxywrite" to the master.cf file, for read/write lookup table
+access. If you copy your old configuration file over the updated
+one, you may see warnings in the maillog file like this:
+
+ connect #xx to subsystem private/proxywrite: No such file or directory
+
+To recover, run "postfix upgrade-configuration" again.
+
+[Incompat 20070613] The pipe(8) delivery agent no longer allows
+delivery with the same group ID as the main.cf postdrop group.
+
+Major changes - malware defense
+-------------------------------
+
+[Feature 20080107] New "pass" service type in master.cf. Written
+years ago, this allows future front-end daemons to accept all
+connections from the network, and to hand over connections from
+well-behaved clients to Postfix. Since this feature uses file
+descriptor passing, it imposes no overhead once a connection is
+handed over to Postfix. See master(5) for a few details.
+
+[Feature 20070911] Stress-adaptive behavior. When a "public" network
+service runs into an "all processes are busy" condition, the master(8)
+daemon logs a warning, restarts the service, and runs it with "-o
+stress=yes" on the command line (under normal conditions it runs
+the service with "-o stress=" on the command line). This can be
+used to make main.cf parameter settings stress dependent, for
+example:
+
+/etc/postfix/main.cf:
+ smtpd_timeout = ${stress?10}${stress:300}
+ smtpd_hard_error_limit = ${stress?1}${stress:20}
+
+Translation: under conditions of stress, use an smtpd_timeout value
+of 10 seconds instead of 300, and use smtpd_hard_error_limit of 1
+instead of 20. The syntax is explained in the postconf(5) manpage.
+
+The STRESS_README file gives examples of how to mitigate flooding
+problems.
+
+Major changes - tls support
+---------------------------
+
+[Incompat 20080109] TLS logging output has changed to make it more
+useful. Existing logfile parser regular expressions may need
+adjustment.
+
+- More log entries include the "hostnamename[ipaddress]" of the
+ remote SMTP peer.
+
+- Certificate trust chain error reports show only the first
+ error certificate (closest to the trust chain root), and the
+ reporting is more human-readable for the most likely errors.
+
+- After the completion of the TLS handshake, the session is logged
+ with TLS loglevel >= 1 as either "Untrusted", "Trusted" or
+ "Verified" (SMTP client only).
+ - "Untrusted" means that the certificate trust chain is invalid,
+ or that the root CA is not trusted.
+ - "Trusted" means that the certificate trust chain is valid, and
+ that the root CA is trusted.
+ - "Verified" means that the certificate meets the SMTP client's
+ matching criteria for the destination:
+ - In the case of a destination name match, "Verified" also
+ implies "Trusted".
+ - In the case of a fingerprint match, CA trust is not applicable.
+
+- The logging of protocol states with TLS loglevel >= 2 no longer
+ reports bogus error conditions when OpenSSL asks Postfix to refill
+ (or flush) network I/O buffers. This loglevel is for debugging
+ only; use 0 or 1 in production configurations.
+
+[Feature 20080109] The Postfix SMTP client has a new "fingerprint"
+security level. This avoids dependencies on CAs, and relies entirely
+on bi-lateral exchange of public keys (really self-signed or private
+CA signed X.509 public key certificates). Scalability is clearly
+limited. For details, see the fingerprint discussion in TLS_README.
+
+[Feature 20080109] The Postfix SMTP server can now use SHA1 instead
+of MD5 to compute remote SMTP client certificate fingerprints. For
+backwards compatibility, the default algorithm is MD5. For details,
+see the "smtpd_tls_fingerprint_digest" parameter in the postconf(5)
+manual.
+
+[Feature 20080109] The maximum certificate trust chain depth
+(verifydepth) is finally implemented in the Postfix TLS library.
+Previously, the parameter had no effect. The default depth was
+changed to 9 (the OpenSSL default) for backwards compatibility.
+
+If you have explicity limited the verification depth in main.cf,
+check that the configured limit meets your needs. See the
+"lmtp_tls_scert_verifydepth", "smtp_tls_scert_verifydepth" and
+"smtpd_tls_ccert_verifydepth" parameters in the postconf(5) manual.
+
+[Feature 20080109] The selection of SSL/TLS protocols for mandatory
+TLS can now use exclusion rather than inclusion. Either form is
+acceptable; see the "lmtp_tls_mandatory_protocols",
+"smtp_tls_mandatory_protocols" and "smtpd_tls_mandatory_protocols"
+parameters in the postconf(5) manual.
+
+Major changes - scheduler
+-------------------------
+
+[Feature 20071130] Revised queue manager with separate mechanisms
+for per-destination concurrency control and for dead destination
+detection. The concurrency control supports less-than-1 feedback
+to allow for more gradual concurrency adjustments, and uses hysteresis
+to avoid rapid oscillations. A destination is declared "dead" after
+a configurable number of pseudo-cohorts(*) reports connection or
+handshake failure.
+
+(*) A pseudo-cohort is a number of delivery requests equal to a
+ destination's delivery concurrency.
+
+The drawbacks of the old +/-1 feedback scheduler are a) overshoot
+due to exponential delivery concurrency growth with each pseudo-cohort(*)
+(5-10-20...); b) throttling down to zero concurrency after a single
+pseudo-cohort(*) failure. The latter was especially an issue with
+low-concurrency channels where a single failure could be sufficient
+to mark a destination as "dead", and suspend further deliveries.
+
+New configuration parameters: destination_concurrency_feedback_debug,
+default_destination_concurrency_positive_feedback,
+default_destination_concurrency_negative_feedback,
+default_destination_concurrency_failed_cohort_limit, as well as
+transport-specific versions of the same.
+
+The default parameter settings are backwards compatible with older
+Postfix versions. This may change after better defaults are field
+tested.
+
+The updated SCHEDULER_README document describes the theory behind
+the new concurrency scheduler, as well as Patrik Rak's preemptive
+job scheduler. See postconf(5) for more extensive descriptions of
+the configuration parameters.
+
+Major changes - small/home office
+---------------------------------
+
+[Feature 20080115] Preliminary SOHO_README document that combines
+bits and pieces from other document in one place, so that it is
+easier to find. This document describes the "mail sending" side
+only.
+
+[Feature 20071202] Output rate control in the queue manager. For
+example, specify "smtp_destination_rate_delay = 5m", to pause five
+minutes between message deliveries. More information in the postconf(5)
+manual under "default_destination_rate_delay".
+
+Major changes - smtp client
+---------------------------
+
+[Incompat 20080114] The Postfix SMTP client now by default defers
+mail after a remote SMTP server rejects a SASL authentication
+attempt. Specify "smtp_sasl_auth_soft_bounce = no" for the old
+behavior.
+
+[Feature 20080114] The Postfix SMTP client can now avoid making
+repeated SASL login failures with the same server, username and
+password. To enable this safety feature, specify for example
+"smtp_sasl_auth_cache_name = proxy:btree:/var/lib/postfix/sasl_auth_cache"
+(access through the proxy service is required). Instead of trying
+to SASL authenticate, the Postfix SMTP client defers or bounces
+mail as controlled with the new smtp_sasl_auth_soft_bounce configuration
+parameter.
+
+[Feature 20071111] Header/body checks are now available in the SMTP
+client, after the implementation was moved from the cleanup server
+to a library module. The SMTP client provides only actions that
+don't change the message delivery time or destination: warn, replace,
+prepend, ignore, dunno, ok.
+
+[Incompat 20070614] By default, the Postfix Cyrus SASL client no
+longer sends a SASL authoriZation ID (authzid); it sends only the
+SASL authentiCation ID (authcid) plus the authcid's password. Specify
+"send_cyrus_sasl_authzid = yes" to get the old behavior.
+
+Major changes - smtp server
+---------------------------
+
+[Feature 20070724] Not really major. New support for RFC 3848
+(Received: headers with ESMTPS, ESMTPA, or ESMTPSA); updated SASL
+support according to RFC 4954, resulting in small changes to SMTP
+reply codes and (DSN) enhanced status codes.
+
+Major changes - milter
+----------------------
+
+[Incompat 20071224] The protocol to send Milter information from
+smtpd(8) to cleanup(8) processes was cleaned up. If you use the
+Milter feature, and upgrade a live Postfix system, you may see an
+"unexpected record type" warning from a cleanup(8) server process.
+To prevent this, execute the command "postfix reload". The
+incompatibility affects only systems that use the Milter feature.
+It does not cause loss of mail, just a minor delay until the remote
+SMTP client retries.
+
+[Feature 20071221] Support for most of the Sendmail 8.14 Milter
+protocol features.
+
+To enable the new features specify "milter_protocol = 6" and link
+the filter application with a libmilter library from Sendmail 8.14
+or later.
+
+Sendmail 8.14 Milter features supported at this time:
+
+- NR_CONN, NR_HELO, NR_MAIL, NR_RCPT, NR_DATA, NR_UNKN, NR_HDR,
+ NR_EOH, NR_BODY: The filter can tell Postfix that it won't reply
+ to some of the SMTP events that Postfix sends. This makes the
+ protocol less chatty and improves performance.
+
+- SKIP: The filter can tell Postfix to skip sending the rest of
+ the message body, which also improves performance.
+
+- HDR_LEADSPC: The filter can request that Postfix does not delete
+ the first space character between header name and header value
+ when sending a header to the filter, and that Postfix does not
+ insert a space character between header name and header value
+ when receiving a header from the filter. This fixes a limitation
+ in the old Milter protocol that can break DKIM and DK signatures.
+
+- SETSYMLIST: The filter can override one or more of the main.cf
+ milter_xxx_macros parameter settings.
+
+Sendmail 8.14 Milter features not supported at this time:
+
+- RCPT_REJ: report rejected recipients to the mail filter.
+
+- CHGFROM: replace sender, with optional ESMTP command parameters.
+
+- ADDRCPT_PAR: add recipient, with optional ESMTP command parameters.
+
+It is unclear when (if ever) the missing features will be implemented.
+SMFIP_RCPT_REJ requires invasive changes in the SMTP server recipient
+processing and error handling. SMFIR_CHGFROM and SMFIR_ADDRCPT_PAR
+require ESMTP command-line parsing in the cleanup server. Unfortunately,
+Sendmail's documentation does not specify what ESMTP options are
+supported, but only discusses examples of things that don't work.
+
+Major changes - address verification
+------------------------------------
+
+[Incompat 20070514] The default sender address for address verification
+probes was changed from "postmaster" to "double-bounce", so that
+the Postfix SMTP server no longer causes surprising behavior by
+excluding "postmaster" from SMTP server access controls.
+
+Major changes - ldap
+--------------------
+
+[Incompat 20071216] Due to an incompatible API change between
+OpenLDAP 2.0.11 and 2.0.12, an LDAP client compiled for OpenLDAP
+version <= 2.0.11 will refuse to work with an OpenLDAP library
+version >= 2.0.12 and vice versa.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20080109] TLS logging output has changed to make it more
+useful. Existing logfile parser regular expressions may need
+adjustment.
+
+- More log entries include the "hostnamename[ipaddress]" of the
+ remote SMTP peer.
+
+- Certificate trust chain error reports show only the first
+ error certificate (closest to the trust chain root), and the
+ reporting is more human-readable for the most likely errors.
+
+- After the completion of the TLS handshake, the session is logged
+ with TLS loglevel >= 1 as either "Untrusted", "Trusted" or
+ "Verified" (SMTP client only).
+ - "Untrusted" means that the certificate trust chain is invalid,
+ or that the root CA is not trusted.
+ - "Trusted" means that the certificate trust chain is valid, and
+ that the root CA is trusted.
+ - "Verified" means that the certificate meets the SMTP client's
+ matching criteria for the destination:
+ - In the case of a destination name match, "Verified" also
+ implies "Trusted".
+ - In the case of a fingerprint match, CA trust is not applicable.
+
+- The logging of protocol states with TLS loglevel >= 2 no longer
+ reports bogus error conditions when OpenSSL asks Postfix to refill
+ (or flush) network I/O buffers. This loglevel is for debugging
+ only; use 0 or 1 in production configurations.
+
+[Incompat 20071216] The SMTP "transcript of session" email now
+includes the remote SMTP server TCP port number.
+
+Major changes - loop detection
+------------------------------
+
+[Incompat 20070422] [Incompat 20070422] When the pipe(8) delivery
+agent is configured to create the optional Delivered-To: header,
+it now first checks if that same header is already present in the
+message. If so, the message is returned as undeliverable. This test
+should have been included with Postfix 2.0 when Delivered-To: support
+was added to the pipe(8) delivery agent.
diff --git a/RELEASE_NOTES-2.6 b/RELEASE_NOTES-2.6
new file mode 100644
index 0000000..ff07431
--- /dev/null
+++ b/RELEASE_NOTES-2.6
@@ -0,0 +1,300 @@
+The stable Postfix release is called postfix-2.6.x where 2=major
+release number, 6=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.7-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 2.4 or earlier, read RELEASE_NOTES-2.5
+before proceeding.
+
+Major changes - multi-instance support
+--------------------------------------
+
+[Feature 20090121] Support for managing multiple Postfix instances.
+This can automatically apply your "postfix start" etc. command to
+multiple Postfix instances, including upgrades to new Postfix
+versions. Multi-instance support allows you to do the following
+and more:
+
+- Simplify post-queue content filter configuration by using separate
+ Postfix instances before and after the filter. This simplifies
+ trouble shooting and performance tuning.
+
+- Implement per-user content filters (or no filter) via transport
+ map lookups instead of content_filter settings. Mail for some
+ users can be sent directly from the before-filter instance to the
+ after-filter instance.
+
+- Test new configuration settings (on a different server IP address
+ or TCP port) without disturbing production instances.
+
+- Each additional Postfix instance uses a few files and directories,
+ plus memory for an extra master daemon and queue manager. The
+ pickup daemon is needed only if you use local submission or
+ "postsuper -r".
+
+Best of all, nothing changes when you use only one Postfix instance.
+
+The MULTI_INSTANCE_README file presents an introduction to
+multi-instance management. Multi-instance support is based on an
+API that is described in the postfix-wrapper(5) manual page.
+
+Major changes - milter support
+------------------------------
+
+[Feature 20090428] The following improvements have been made to the
+Milter implementation:
+
+- Improved compatibility of the {mail_addr} and {rcpt_addr} macros.
+
+- Support for the {mail_host}, {mail_mailer}, {rcpt_host} and
+{rcpt_mailer} macros.
+
+- Milter applications can now request rejected recipients with the
+SMFIP_RCPT_REJ feature. Rejected recipients are reported with
+{rcpt_mailer} = "error", {rcpt_host} = enhanced status code, and
+{rcpt_addr} = descriptive text. This feature requires "milter_protocol
+= 6" or higher (default as of Postfix 2.6).
+
+- Milters can now replace the envelope sender address with the
+SMFIR_CHGFROM request, and can add recipients with SMFIR_ADDRCPT_PAR.
+These implementations ignore ESMTP command parameters and log a
+warning message as follows:
+
+ warning: 100B22B3293: cleanup_chg_from: ignoring ESMTP arguments "whatever"
+ warning: 100B22B3293: cleanup_add_rcpt: ignoring ESMTP arguments "whatever"
+
+[Incompat 20090428] The default milter_protocol setting is increased
+from 2 to 6; this enables all available features up to and including
+Sendmail 8.14.0. The new milter_protocol setting may break
+compatibility with older Milter libraries or applications, and may
+cause Postfix to log warning messages such as:
+
+ warning: milter inet:host:port: can't read packet header: Unknown error : 0
+
+ warning: milter inet:host:port: can't read packet header: Success
+
+ warning: milter inet:host:port: can't read SMFIC_DATA reply
+ packet header: No such file or directory
+
+To restore compatibility, specify "milter_protocol = 2" in main.cf.
+
+Major changes - security
+------------------------
+
+[Incompat 20080726] When a mailbox file is not owned by its recipient,
+the local and virtual delivery agents now log a warning and defer
+delivery. Specify "strict_mailbox_ownership = no" to ignore such
+ownership discrepancies.
+
+Major changes - smtp server
+---------------------------
+
+[Feature 20080212] check_reverse_client_hostname_access, to make
+access decisions based on the unverified client hostname. For
+safety reasons an OK result is not allowed.
+
+[Feature 20090210] With "reject_tempfail_action = defer", the Postfix
+SMTP server immediately replies with a 4xx status after some temporary
+error, instead of executing an implicit "defer_if_permit" action.
+
+[Feature 20090215] The Postfix SMTP server automatically hangs up
+after replying with "521". This makes overload handling more
+effective. See also RFC 1846 for prior art on this topic.
+
+[Feature 20090228] The Postfix SMTP server maintains a per-session
+"improper command pipelining detected" flag. This flag can be tested
+at any time with reject_unauth_pipelining, and is raised whenever
+a client command is followed by unexpected commands or message
+content. The Postfix SMTP server logs the first command pipelining
+transgression as "improper command pipelining after from
+[]".
+
+[Feature 20090212] Stress-dependent behavior is enabled by default.
+Under conditions of overload, smtpd_timeout is reduced from 300s
+to 10s, smtpd_hard_error_limit is reduced from 20 to 1, and
+smtpd_junk_command_limit is reduced from 100 to 1. This will reduce
+the impact of overload for most legitimate mail.
+
+[Feature 20080629] The Postfix SMTP server's SASL authentication
+was re-structured. With "smtpd_tls_auth_only = yes", SASL support
+is now activated only after a successful TLS handshake. Earlier
+Postfix SMTP server versions could complain about unavailable SASL
+mechanisms during the plaintext phase of the SMTP protocol.
+
+[Incompat 20080510] In the policy delegation protocol, certificate
+common name attributes are now xtext encoded UTF-8. The xtext decoded
+attributes may contain any UTF-8 value except non-printable ASCII
+characters.
+
+Major changes - performance
+---------------------------
+
+[Feature 20090215] The Postfix SMTP server automatically hangs up
+after replying with "521". This makes overload handling more
+effective. See also RFC 1846 for prior art on this topic.
+
+[Feature 20090212] Stress-dependent behavior is enabled by default.
+Under conditions of overload, smtpd_timeout is reduced from 300s
+to 10s, smtpd_hard_error_limit is reduced from 20 to 1, and
+smtpd_junk_command_limit is reduced from 100 to 1. This will reduce
+the negative impact of server overload for most legitimate mail.
+
+[Feature 20090109] Specify "tcp_windowsize = 65535" (or less) to
+work around routers with broken TCP window scaling implementations.
+This is perhaps more convenient than collecting tcpdump output and
+tuning kernel parameters by hand. With Postfix TCP servers (smtpd(8),
+qmqpd(8)), this feature is implemented by the Postfix master(8)
+daemon.
+
+To change this parameter without stopping Postfix, you need to first
+terminate all Postfix TCP servers:
+
+ # postconf -e master_service_disable=inet
+ # postfix reload
+
+This immediately terminates all processes that accept network
+connections. Then you enable Postfix TCP servers with the updated
+tcp_windowsize setting:
+
+ # postconf -e tcp_windowsize=65535 master_service_disable=
+ # postfix reload
+
+If you skip these steps with a running Postfix system, then the
+tcp_windowsize change will work only for Postfix TCP clients (smtp(8),
+lmtp(8)).
+
+Of course you can also do "postfix stop" and "postfix start",
+but that is more disruptive.
+
+Major changes - tls
+-------------------
+
+[Incompat 20090428] The Postfix SMTP client(!) no longer tries to
+use the obsolete SSLv2 protocol by default, as this may prevent the
+use of modern SSL features. Lack of SSLv2 support should never be
+a problem, since SSLv3 was defined in 1996, and TLSv1 in 1999. You
+can undo the change by specifying empty main.cf values for
+smtp_tls_protocols and lmtp_tls_protocols. The Postfix SMTP server
+maintains SSLv2 support for backwards compatibility with ancient
+clients.
+
+[Feature 20081010] Controls for the protocols and ciphers that
+Postfix will use with opportunistic TLS. The smtp_tls_protocols,
+smtp_tls_ciphers, and equivalent parameters for lmtp and smtpd
+provide global settings; the SMTP client TLS policy table provides
+ciphers and protocols settings for specific peers. Code by Victor
+Duchovni. Details are given in the TLS_README and postconf(5)
+documents.
+
+[Feature 20081108] Elliptic curve support. This requires OpenSSL
+version 0.9.9 or later.
+
+Major changes - address verification
+------------------------------------
+
+[Incompat 20080428] Postfix SMTP server replies for address
+verification have changed. unverified_recipient_reject_code and
+unverified_sender_reject_code now handle "5XX" rejects only. The
+"4XX" rejects are now controlled with unverified_sender_defer_code
+and unverified_recipient_defer_code.
+
+[Feature 20080428] Finer control over the way Postfix reports address
+verification failures to remote SMTP clients.
+
+- unverified_sender/recipient_defer_code: the numerical Postfix
+ SMTP server reply code when address verification failed due
+ to some temporary error.
+
+- unverified_sender/recipient_reject_reason: fixed text that Postfix
+ will send to the remote SMTP client, instead of sending actual
+ address verification details.
+
+Major changes - dsn
+-------------------
+
+[Feature 20090307] New "lmtp_assume_final = yes" flag to send correct
+DSN "success" notifications when LMTP delivery is "final" as opposed
+to delivery into a content filter.
+
+Major changes - file organization
+---------------------------------
+
+[Incompat 20080207] According to discussions on the mailing list,
+too many people are breaking newly installed Postfix by overwriting
+the new /etc/postfix files with versions from an older release, and
+end up with a broken configuration that cannot repair itself. For
+this reason, postfix-script, postfix-files and post-install are
+moved away from /etc/postfix to $daemon_directory.
+
+Major changes - header rewriting
+--------------------------------
+
+[Incompat 20090330] Postfix now adds (Resent-) From:, Date:,
+Message-ID: or To: headers only when clients match
+$local_header_rewrite_clients. Specify "always_add_missing_headers
+= yes" for backwards compatibility. Adding such headers can break
+DKIM signatures that cover headers that are not present. For
+compatibility with existing logfile processing software, Postfix
+will log ``message-id=<>'' for messages without Message-Id header.
+
+Major changes - lmtp client
+---------------------------
+
+[Feature 20090307] New "lmtp_assume_final = yes" flag to send correct
+DSN "success" notifications when LMTP delivery is "final" as opposed
+to delivery into a content filter.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20090330] Postfix now adds (Resent-) From:, Date:,
+Message-ID: or To: headers only when clients match
+$local_header_rewrite_clients. Specify "always_add_missing_headers
+= yes" for backwards compatibility. Adding such headers can break
+DKIM signatures that cover headers that are not present.
+
+This changes the appearance of Postfix logging: to preserve
+compatibility with existing logfile processing software, Postfix
+will log ``message-id=<>'' for messages without Message-Id header.
+
+Major changes - mime
+--------------------
+
+[Feature 20080324] When the "postmap -q -" command reads lookup
+keys from standard input, it now understands RFC822 and MIME message
+format. Specify -h or -b to use headers or body lines as lookup
+keys, and specify -hm or -bm to simulate header_checks or body_checks.
+
+Major changes - miscellaneous
+-----------------------------
+
+[Feature 20090109] Support to selectively disable master(8) listener
+ports by service type or by service name + type. Specify a list of
+service types ("inet", "unix", "fifo", or "pass") or "name.type"
+tuples, where "name" is the first field of a master.cf entry and
+"type" is a service type. Examples: to turn off the main SMTP
+listener port, use "master_service_disable = smtp.inet"; to turn
+off all TCP/IP listeners, use "master_service_disable = inet".
+Changing this parameter requires "postfix reload".
+
+Major changes - sasl
+--------------------
+
+[Feature 20090418] The Postfix SMTP server passes more information
+to the Dovecot authentication server: the "TLS is active" flag, the
+server IP address, and the client IP address.
+
+[Feature 20080629] The Postfix SMTP server's SASL authentication
+was re-structured. With "smtpd_tls_auth_only = yes", SASL support
+is now activated only after a successful TLS handshake. Earlier
+Postfix SMTP server versions could complain about unavailable SASL
+mechanisms during the plaintext phase of the SMTP protocol.
+
diff --git a/RELEASE_NOTES-2.7 b/RELEASE_NOTES-2.7
new file mode 100644
index 0000000..8632638
--- /dev/null
+++ b/RELEASE_NOTES-2.7
@@ -0,0 +1,175 @@
+The stable Postfix release is called postfix-2.7.x where 2=major
+release number, 7=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.8-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 2.5 or earlier, read RELEASE_NOTES-2.6
+before proceeding.
+
+Major changes - performance
+---------------------------
+
+[Feature 20100101] Periodic cache cleanup for the verify(8) cache
+database. The time between cache cleanup runs is controlled with
+the address_verify_cache_cleanup_interval (default: 12h) parameter.
+Cache cleanup increases the database access latency, so this should
+not be run more often than necessary.
+
+[Feature 20091109] Improved before-queue filter performance. With
+"smtpd_proxy_options = speed_adjust", the Postfix SMTP server
+receives the entire message before it connects to a before-queue
+content filter. This means you can run more SMTP server processes
+with the same number of running content filter processes, and thus,
+handle more mail. This feature is off by default until it is proven
+to create no new problems.
+
+This addresses a concern of people in Europe who want to reject all
+bad mail with a before-queue filter. The alternative, an after-queue
+filter, means they would have to discard bad mail (which is illegal)
+or bounce bad mail (which violates good network citizenship).
+
+NOTE 1: When this feature is turned on, a filter cannot selectively
+reject recipients of a multi-recipient message. It is OK to reject
+all recipients of the same multi-recipient message, as is deferring
+or accepting all recipients of the same multi-recipient message.
+
+NOTE 2: This feature increases the minimum amount of free queue
+space by $message_size_limit. The extra space is needed to save the
+message to a temporary file.
+
+To keep the performance overhead low, the same temporary file is
+reused with successive mail transactions (the file is of course
+truncated before reuse, so there is no information leakage).
+
+Major changes - sender reputation
+---------------------------------
+
+[Feature 20100117] The FILTER action in access maps or header/body_checks
+now supports sender reputation schemes that dynamically choose the
+SMTP source IP address. Typically, mail is split into classes, and
+all mail in class X is sent out from an SMTP client IP address that
+is reserved for class X.
+
+This is implemented by specifying FILTER actions with empty next-hop
+destinations in access maps or header/body_checks, and by configuring
+in master.cf one Postfix SMTP client for each SMTP source IP address,
+where each client has its own "-o myhostname" and "-o smtp_bind_address"
+settings.
+
+[Feature 20091209] sender_dependent_default_transport_maps, a
+per-sender override for default_transport. The original motivation
+is to use different output channels (with different source IP
+addresses) for different sender addresses, in order to keep their
+IP-based reputations separate from each other.
+
+The result value syntax is that of default_transport, not transport_maps.
+Thus, sender_dependent_default_transport_maps does not support the
+special transport_maps result value syntax for null transport, null
+nexthop, or null email address.
+
+This feature makes sender_dependent_relayhost_maps pretty much
+redundant (though sender_dependent_relayhost_maps will often be
+easier to use because that is the only thing people want to override).
+
+Major changes - address verification
+------------------------------------
+
+[Incompat 20100101] The verify(8) service now uses a persistent
+cache by default (address_verify_map = btree:$data_directory/verify_cache).
+To disable, specify "address_verify_map =" in main.cf.
+
+When periodic cache cleanup is enabled (the default), the verify(8)
+server now requires that the cache database supports the "delete"
+and "sequence" operations. To disable periodic cache cleanup specify
+a zero address_verify_cache_cleanup_interval value.
+
+[Feature 20100101] Periodic cache cleanup for the verify(8) cache
+database. The time between cache cleanup runs is controlled with
+the address_verify_cache_cleanup_interval (default: 12h) parameter.
+Cache cleanup increases the database access latency, so this should
+not be run more often than necessary.
+
+Major changes - content filter
+------------------------------
+
+[Incompat 20100117] The meaning of an empty filter next-hop destination
+has changed (for example, "content_filter = foo:" or "FILTER foo:").
+Postfix now uses the recipient domain, instead of using $myhostname
+as in Postfix 2.6 and earlier. To restore the old behavior specify
+"default_filter_nexthop = $myhostname", or specify a non-empty
+next-hop content filter destination.
+
+This compatibility option is not needed with SMTP-based content
+filters, because these always have an explicit next-hop destination.
+
+With pipe-based filters that specify no next-hop destination, the
+compatibility option restores the FIFO order of deliveries. Without
+the compatibility option, the delivery order for filters without
+next-hop destination changes to round-robin domain selection.
+
+[Feature 20100117] The FILTER action in access maps or header/body_checks
+now supports sender reputation schemes that dynamically choose the
+SMTP source IP address. Typically, mail is split into classes, and
+all mail in class X is sent out from an SMTP client IP address that
+is reserved for class X.
+
+This is implemented by specifying FILTER actions with empty next-hop
+destinations in access maps or header/body_checks, and by configuring
+in master.cf one Postfix SMTP client for each SMTP source IP address,
+where each client has its own "-o myhostname" and "-o smtp_bind_address"
+settings.
+
+[Feature 20091109] Improved before-queue filter performance. With
+"smtpd_proxy_options = speed_adjust", the Postfix SMTP server
+receives the entire message before it connects to a before-queue
+content filter. This means you can run more SMTP server processes
+with the same number of running content filter processes, and thus,
+handle more mail. This feature is off by default until it is proven
+to create no new problems.
+
+This addresses a concern of people in Europe who want to reject all
+bad mail with a before-queue filter. The alternative, an after-queue
+filter, means they would have to discard bad mail (which is illegal)
+or bounce bad mail (which violates good network citizenship).
+
+NOTE 1: When this feature is turned on, a filter cannot selectively
+reject recipients of a multi-recipient message. It is OK to reject
+all recipients of the same multi-recipient message, as is deferring
+or accepting all recipients of the same multi-recipient message.
+
+NOTE 2: This feature increases the minimum amount of free queue
+space by $message_size_limit. The extra space is needed to save the
+message to a temporary file.
+
+To keep the performance overhead low, the same temporary file is
+reused with successive mail transactions (the file is of course
+truncated before reuse, so there is no information leakage).
+
+Major changes - milter
+----------------------
+
+[Feature 20090606] Support for header checks on Milter-generated
+message headers. This can be used, for example, to control mail
+flow with Milter-generated headers that carry indicators for badness
+or goodness. For details, see the postconf(5) section for
+"milter_header_checks". Currently, all header_checks features are
+implemented except PREPEND.
+
+Major changes - multi-instance support
+--------------------------------------
+
+[Incompat 20090606] The "postmulti -e destroy" command no longer
+attempts to remove files that are created AFTER "postmulti -e
+create". It still works as expected immediately after creating an
+instance by mistake. Trying to automatically remove other files
+is too risky because Postfix-owned directories are by design not
+trusted.
+
diff --git a/RELEASE_NOTES-2.8 b/RELEASE_NOTES-2.8
new file mode 100644
index 0000000..622577f
--- /dev/null
+++ b/RELEASE_NOTES-2.8
@@ -0,0 +1,383 @@
+The stable Postfix release is called postfix-2.8.x where 2=major
+release number, 8=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.9-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 2.6 or earlier, read RELEASE_NOTES-2.7
+before proceeding.
+
+Major changes - restart Postfix
+-------------------------------
+
+If you upgrade from Postfix 2.6 or earlier, you must execute "postfix
+stop" and "postfix start" before you can use the postscreen(8)
+daemon. This is needed because the Postfix 2.6 "pass" master service
+type did not work reliably on some systems.
+
+If you upgrade from Postfix 2.7, or from Postfix 2.8 before July
+25, 2010, you must execute "postfix reload" (or "postfix stop"
+followed by "postfix start"). This is needed because the queue
+manager to delivery agent protocol has changed. Failure to do this
+results in repeated logging of warnings with:
+
+ warning: unexpected attribute rewrite_context ...
+
+If the warning does not go away after restarting Postfix, examine
+the output from this command:
+
+ strings -af /usr/libexec/postfix/* | grep mail_version=
+
+(where /usr/libexec/postfix is the value of main.cf:daemon_directory)
+and update the executables that have a version string that differs
+from the other programs.
+
+Major changes - DNSBL/DNSWL support
+-----------------------------------
+
+[Feature 20101126] Support for address patterns in DNS blacklist
+and whitelist lookup results.
+
+For example, "reject_rbl_client example.com=127.0.0.[2;4;6..8]"
+will reject clients when the lookup result is 127.0.0.2, 127.0.0.4,
+127.0.0.6, 127.0.0.7, or 127.0.0.8.
+
+The setting "postscreen_dnsbl_sites = example.com=127.0.0.[2;4;6..8]"
+rejects the same clients.
+
+An IPv4 address pattern has four fields separated by ".". Each
+field is either a decimal number, or a sequence inside "[]" that
+contains one or more ";"-separated decimal numbers or number..number
+ranges.
+
+Thus, any pattern field can be a sequence inside "[]", but a "[]"
+sequence cannot span multiple address fields, and a pattern field
+cannot contain both a number and a "[]" sequence at the same time.
+
+This means that the pattern 1.2.[3.4] is not valid (the sequence
+[3.4] cannot span two address fields) and the pattern 1.2.3.3[6..9]
+is also not valid (the last field cannot be both number 3 and
+sequence [6..9] at the same time).
+
+The syntax for IPv4 patterns is as follows:
+
+v4pattern = v4field "." v4field "." v4field "." v4field
+v4field = v4octet | "[" v4sequence "]"
+v4octet = any decimal number in the range 0 through 255
+v4sequence = v4seq_member | v4sequence ";" v4seq_member
+v4seq_member = v4octet | v4octet ".." v4octet
+
+[Feature 20101105] The Postfix SMTP server now supports DNS-based
+whitelisting with several safety features: permit_dnswl_client
+whitelists a client by IP address, and permit_rhswl_client whitelists
+a client by its hostname. These features use the same syntax as
+reject_rbl_client and reject_rhsbl_client, respectively. The main
+difference is that they return PERMIT instead of REJECT.
+
+Whitelisting is primarily a tool to reduce the false positive rate
+of DNS blocklist lookups. Client name whitelisting should not be
+used to make exceptions to access rules. The reason is that client
+name lookup can fail unpredictably due to some temporary outage.
+
+For safety reasons, permit_dnswl_client and permit_rhswl_client are
+silently ignored when they would override reject_unauth_destination.
+Also for safety reasons, the result is DEFER_IF_REJECT when DNS
+whitelist lookup fails (this result will be made configurable).
+
+Major changes - sqlite support
+------------------------------
+
+[Feature 20100617] Support for read-only sqlite database access,
+with code by Axel Steiner and documentation by Jesus Garcia Crespo.
+See SQLITE_README and sqlite_table(5) for details.
+
+Major changes - Milter support
+-------------------------------
+
+[Incompat 20101103] Postfix now requests default delivery status
+notifications when adding a recipient with the Milter smfi_addrcpt
+action, instead of "never notify" as with Postfix automatically-added
+recipients (always_bcc and sender/recipient_bcc_maps).
+
+Major changes - alias expansion
+-------------------------------
+
+[Incompat 20101202] Postfix now reports a temporary delivery error
+when the result of virtual alias expansion would exceed the
+virtual_alias_recursion_limit or virtual_alias_expansion_limit.
+Previously, Postfix would silently drop the excess recipients and
+deliver the message.
+
+[Incompat 20101006] To avoid repeated delivery to mailing lists
+with pathological nested alias configurations, the local(8) delivery
+agent now keeps the owner-alias attribute of a parent alias, when
+delivering mail to a child alias that does not have its own owner
+alias.
+
+With this change, local addresses from that child alias will be
+written to a new queue file, and a temporary error with one local
+address will no longer result in repeated delivery to other mailing
+list members. Specify "reset_owner_alias = yes" for the older,
+more fragile, behavior.
+
+The postconf(5) manpage entry for "reset_owner_alias" has more
+background information on this issue.
+
+Major changes - dns lookup
+--------------------------
+
+[Incompat 20100827] The Postfix SMTP client no longer appends the
+local domain when looking up a DNS name without ".". Specify
+"smtp_dns_resolver_options = res_defnames" to get the old behavior,
+which may produce unexpected results.
+
+Major changes - logging
+-----------------------
+
+[Incompat 20100728] The format of the "postfix/smtpd[pid]: queueid:
+client=host[addr]" logfile record has changed. When available, the
+before-filter client information and the before-filter queue ID are
+now appended to the end of the record.
+
+[Feature 20100728] Improved message tracking across SMTP-based
+content filters. The logging example below is from an after-filter
+SMTP server. Here, 951F692462F is a before-filter queue ID,
+hades.porcupine.org is a before-filter SMTP client, while 6B4A9924782
+is the after-filter queue ID, and localhost[127.0.0.1] is the
+SMTP-based content filter that sends mail into the after-filter
+SMTP server.
+
+ postfix/smtpd[4074]: 6B4A9924782:
+ client=localhost[127.0.0.1],
+ orig_queue_id=951F692462F
+ orig_client=hades.porcupine.org[168.100.189.10]
+
+Major changes - reply footer
+----------------------------
+
+[Feature 20110105] The SMTP server now supports contact information
+that is appended to "reject" responses. This includes SMTP server
+responses that aren't logged to the maillog file, such as responses
+to syntax errors, or unsupported commands.
+
+Example:
+ smtpd_reject_footer = For assistance, call 800-555-0101.
+
+Server response:
+ 550-5.5.1 Recipient address rejected: User unknown
+ 550 5.5.1 For assistance, call 800-555-0101.
+
+This feature supports macro expansion ($client_address, $localtime,
+etc.), as documented in the postconf(5) manpage.
+
+This feature is also supported as postscreen_reject_footer using
+the same setting as smtpd_reject_footer by default.
+
+Major changes - rfc compliance
+------------------------------
+
+[Incompat 20101206] Postfix by default no longer adds a "To:
+undisclosed-recipients:;" header when no recipient specified in the
+message header. The Internet mail RFCs have supported messages
+without recipient header for almost 10 years now.
+
+For backwards compatibility, specify:
+
+/etc/postfix/main.cf
+ undisclosed_recipients_header = To: undisclosed-recipients:;
+
+Note: both the ":" and ";" are required.
+
+Major changes - tls support
+---------------------------
+
+[Incompat 20110102] The Postfix SMTP server now always re-computes
+the SASL mechanism list after successful completion of the STARTTLS
+command. Earlier versions only re-computed the mechanism list when
+the values of smtp_sasl_tls_security_options and smtp_sasl_security_options
+differ. This could produce incorrect results, because the Dovecot
+authentication server may change responses when the SMTP session
+is encrypted.
+
+[Incompat 20110102] The smtpd_starttls_timeout default value is now
+stress-dependent. By default, TLS negotiations must now complete
+under overload in 10s instead of 300s.
+
+[Feature 20101223] The new tls_disable_workarounds parameter specifies
+a list or bit-mask of OpenSSL bug work-arounds to disable. This may
+be necessary if one of the work-arounds enabled by default in OpenSSL
+proves to pose a security risk, or introduces an unexpected
+interoperability issue. Some bug work-arounds known to be problematic
+are disabled in the default value of the parameter when linked with
+an OpenSSL library that could be vulnerable. See postconf(5) and
+TLS_README for details.
+
+With "tls_preempt_cipherlist = yes" the Postfix SMTP server will
+choose its most preferred cipher that is supported (offered) by the
+client. This can lead to a more secure or performant cipher choice,
+but may also introduce interoperability problems when a client
+announces support for a cipher that does not work. See postconf(5)
+and TLS_README for details.
+
+[Feature 20101217] The lower-level code in the TLS engine was
+simplified by removing an unnecessary layer of data copying. OpenSSL
+now writes directly to the network. The difference in performance
+should be hardly noticeable.
+
+[Incompat 20100610] Postfix no longer appends the system-supplied
+default CA certificates to the lists specified with *_tls_CAfile
+or with *_tls_CApath. This prevents third-party certificates from
+getting mail relay permission with the permit_tls_all_clientcerts
+feature.
+
+Unfortunately this change may cause compatibility problems when
+configurations rely on certificate verification for other purposes.
+Specify "tls_append_default_CA = yes" for backwards compatibility.
+
+Major changes - postscreen
+--------------------------
+
+See html/POSTSCREEN_README.html for an introduction to postscreen
+(or the text version, README_FILES/POSTSCREEN_README). The text
+below summarizes milestones in reverse chronological order.
+
+[Incompat 20110111] The postscreen_access_list feature replaces the
+postscreen_whitelist_networks and postscreen_blacklist_networks
+features. Reason: CIDR-style access maps are some 100x faster than
+the code that implemented the postscreen_white/blacklist_networks
+support. CIDR maps can match about 100 million CIDR patterns/second
+on a modern CPU, which is not blindingly fast but adequate for the
+near future.
+
+[Feature 20110102] STARTTLS support for the postscreen(8) daemon.
+This is implemented by a new tlsproxy(8) daemon that you will need
+to enable in master.cf (see POSTSCREEN_README for instructions).
+tlsproxy(8) implements its own tlsproxy_mumble versions of TLS-related
+smtpd_mumble parameters. This leaves no confusion about which
+parameters will affect tlsproxy(8) behavior, but it adds another
+25 parameters to the documentation.
+
+[Incompat 20100912] If your DNSBL queries have a "secret" in the
+domain name, you must now censor this information from the postscreen(8)
+SMTP replies. For example:
+
+ /etc/postfix/main.cf:
+ postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
+
+ /etc/postfix/dnsbl_reply:
+ # Secret DNSBL name Name in postscreen(8) replies
+ secret.zen.spamhaus.org zen.spamhaus.org
+
+The texthash: format is similar to hash: except that there is no need to
+run postmap(1) before the file can be used, and that it does not detect
+changes after the file is read. It is new with Postfix version 2.8.
+
+[Incompat 20100912] The postscreen "continue" action is now called
+"ignore". The old name is still supported but no longer documented.
+
+[Incompat 20100912] The postscreen_hangup_action parameter was
+removed. Postscreen now always behaves as if "postscreen_hangup_action
+= drop".
+
+[Incompat 20100912] The postscreen_cache_retention_time default was
+increased from 1d to 7d, to avoid deleting results from expensive
+deep SMTP protocol tests too quickly.
+
+[Feature 20100912] SMTP protocol engine for deep protocol tests,
+and for logging the helo/sender/recipient information when postscreen
+rejects an attempt to deliver mail.
+
+The postscreen SMTP protocol engine implements a number of deep
+protocol tests and defers or rejects all attempts to deliver mail.
+The first test detects unauthorized SMTP command pipelining (an
+SMTP client sends multiple commands, instead of sending one command
+and waiting for the server response); a second deep protocol test
+implements the Postfix SMTP server's smtpd_forbidden_commands feature
+(a client sends commands such as CONNECT, GET, POST); and a third
+deep protocol test detects spambots that send SMTP commands that
+end in newline instead of carriage-return/newline. Real spambots
+rarely make this mistake, but poorly-written software often does.
+
+Deep protocol tests are disabled by default, because the built-in
+SMTP engine cannot not hand off the "live" connection from a good
+SMTP client to a Postfix SMTP server process. To work around this,
+postscreen(8) defers attempts to deliver mail with a 4XX status,
+and waits for the client to disconnect. The next time a good client
+connects, it will be allowed to talk to a Postfix SMTP server process
+to deliver mail.
+
+[Feature 20100830] Postscreen DNSBL support is extended with optional
+fixed-string filters, with optional integral weight factors, and
+with an adjustable threshold to block SMTP clients with DNSBL score
+>= that threshold. Reply filters will be implemented later.
+
+The updated postscreen configuration syntax is:
+
+ postscreen_dnsbl_sites = domain[=ipaddr][*weight] ...
+ postscreen_dnsbl_threshold = score
+
+Elements inside [] are optional, ipaddr is an IPv4 address, and
+weight and score are integral numbers. The [] are not part of the
+postscreen_dnsbl_sites input. By default, weight and score are
+equal to 1, and entries without filter will match any non-error
+DNSBL reply. Use a negative weight value for whitelisting.
+
+Examples:
+
+To use example.com as a high-confidence blocklist, and to block
+mail with example.net and example.org only when both agree, use:
+
+ postscreen_dnsbl_threshold = 2
+ postscreen_dnsbl_sites = example.com*2, example.net, example.org
+
+To filter only DNSBL replies containing 127.0.0.4, use:
+
+ postscreen_dnsbl_sites = example.com=127.0.0.4
+
+See also postconf(5) for the fine details.
+
+[Incompat 20100101] When periodic cache cleanup is enabled (the
+default), the postscreen(8) server now requires that the cache
+database supports the "delete" and "sequence" operations. To disable
+periodic cache cleanup specify a zero postscreen_cache_cleanup_interval
+value.
+
+[Feature 20100101] Periodic cache cleanup for the postscreen(8)
+cache database. The time between cache cleanup runs is controlled
+with the postscreen_cache_cleanup_interval (default: 12h) parameter.
+Cache cleanup increases the database access latency, so this should
+not be run more often than necessary.
+
+In addition, the postscreen_cache_retention_time (default: 1d)
+parameter specifies how long to keep an expired entry in the cache.
+This prevents a client from being logged as "NEW" after its record
+expired only a little while ago.
+
+[Feature 20091008] Prototype postscreen(8) server that runs a number
+of time-consuming checks in parallel for all incoming SMTP connections,
+before clients are allowed to talk to a real Postfix SMTP server.
+It detects clients that start talking too soon, or clients that
+appear on DNS blocklists, or clients that hang up without sending
+any command.
+
+By doing these checks in a single postscreen(8) process, Postfix
+can avoid wasting one SMTP server process per connection. A side
+benefit of postscreen(8)'s DNSBL lookups is that DNS records are
+already cached before the Postfix SMTP server looks them up later.
+
+postscreen(8) maintains a temporary whitelist of positive decisions.
+Once an SMTP client is whitelisted, it is immediately forwarded to
+a real Postfix SMTP server process without further checking.
+
+By default, the program logs only statistics, and it does not run
+any checks on clients in mynetworks (primarily, to avoid problems
+with buggy SMTP implementations in network appliances). The logging
+function alone is already useful for research.
+
diff --git a/RELEASE_NOTES-2.9 b/RELEASE_NOTES-2.9
new file mode 100644
index 0000000..e30a34d
--- /dev/null
+++ b/RELEASE_NOTES-2.9
@@ -0,0 +1,352 @@
+The stable Postfix release is called postfix-2.9.x where 2=major
+release number, 9=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-2.10-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 2.7 or earlier, read RELEASE_NOTES-2.8
+before proceeding.
+
+Major changes - critical
+------------------------
+
+[Incompat 20110321] You need to "postfix reload" after upgrade from
+snapshot 20110320 or earlier. The hash_queue_names algorithm was
+changed to provide better performance with long queue IDs.
+
+[Incompat 20110313] Use "postfix reload" after "make upgrade" on a
+running Postfix system. This is needed because the protocol between
+postscreen(8) and dnsblog(8) has changed.
+
+Major changes - library API
+---------------------------
+
+[Incompat 20110130] The VSTREAM error flags are now split into
+separate read and write error flags. As a result of this change,
+all programs that use Postfix VSTREAMs MUST be recompiled.
+
+Major changes - compatibility
+-----------------------------
+
+[Incompat 20111012] For consistency with the SMTP standard, the
+(client-side) smtp_line_length_limit default value was increased
+from 990 characters to 999 (i.e. 1000 characters including ).
+Specify "smtp_line_length_limit = 990" to restore historical Postfix
+behavior.
+
+[Incompat 20111012] To simplify integration with third-party
+applications, the Postfix sendmail command now always transforms
+all input lines ending in into UNIX format (lines ending
+in ). Specify "sendmail_fix_line_endings = strict" to restore
+historical Postfix behavior (i.e. convert all input lines ending
+in only if the first line ends in ).
+
+[Incompat 20111106] To work around broken remote SMTP servers, the
+Postfix SMTP client by default no longer appends the "AUTH=<>"
+option to the MAIL FROM command. Specify "smtp_send_dummy_mail_auth
+= yes" to restore the old behavior.
+
+Major changes - gradual degradation
+-----------------------------------
+
+[Incompat 20120114] Logfile-based alerting systems may need to be
+updated to look for "error" messages in addition to "fatal" messages.
+Specify "daemon_table_open_error_is_fatal = yes" to get the historical
+behavior (immediate termination with "fatal" message).
+
+[Feature 20120114] Instead of terminating immediately with a "fatal"
+message when a database file can't be opened, a Postfix daemon
+program now logs an "error" message, and continues execution with
+reduced functionality. For the sake of sanity, the number of
+"errors" over the life of a process is limited to 13.
+
+Features that don't depend on the unavailable table will continue
+to work; attempts to use features that depend on the table will
+fail, and will be logged with a "warning" message.
+
+[Feature 20120108] Instead of terminating with a fatal error, the
+LDAP, *SQL and memcache clients now handle table lookup errors in
+the "domain" feature, instead of terminating with a fatal error.
+
+[Feature 20120102] Degrade gradually when some or all network
+protocols specified with inet_protocols are unavailable, instead
+of terminating with a fatal error. This eliminates build errors on
+non-standard systems where opening an IPv4 socket results in an
+error, and on non-standard systems where opening an IPv6 socket
+results in an error. In the worst case, the master daemon will log
+a message that it disables all type "inet" services. This will still
+allow local submission and local delivery.
+
+[Feature 20111222] Instead of terminating with a fatal error, the
+Postfix SMTP server now handles errors with database lookups in
+mynetworks, TLS client certificate tables, debug_peer_list,
+smtpd_client_event_limit_exceptions, permit_mx_backup_networks and
+local_header_rewrite_clients, and reports "server local data error"
+or "temporary lookup error".
+
+[Feature 20111229] Instead of terminating with a fatal error, the
+trivial-rewrite server now handles errors with database lookups in
+virtual_alias_domains, relay_domains, virtual_mailbox_domains. This
+means fewer occasions where trivial-rewrite clients (such as the
+SMTP server) will appear to hang.
+
+Major changes - long queue IDs
+------------------------------
+
+Postfix 2.9 introduces support for non-repeating queue IDs (also
+used as queue file names). These names are encoded in a mix of upper
+case, lower case and decimal digit characters. Long queue IDs are
+disabled by default to avoid breaking tools that parse logfiles and
+that expect queue IDs with the smaller [A-F0-9] character set.
+
+[Incompat 20110320] If you enable support for long queue file names,
+you need to be aware that these file names are not compatible with
+Postfix <= 2.8. If you must migrate back to Postfix <= 2.8, you
+must first convert all long queue file names into short names,
+otherwise the old Postfix version will complain.
+
+The conversion procedure before migration to Postfix <= 2.8 is:
+
+ # postfix stop
+ # postconf enable_long_queue_ids=no
+ # postsuper
+
+Run the postsuper command repeatedly until it no longer reports
+queue file name changes.
+
+[Feature 20110320] Support for long, non-repeating, queue IDs (queue
+file names). The benefit of non-repeating names is simpler logfile
+analysis, and easier queue migration (if you don't merge different
+queues, there is no need to run "postsuper" to change queue file
+names that don't match their message file inode number).
+
+Specify "enable_long_queue_ids = yes" to enable the feature. This
+does not change the names of existing queue files. See postconf(5)
+or postconf.5.html#enable_long_queue_ids for a detailed description
+of the differences with the old short queue IDs.
+
+This changes new Postfix queue IDs from the short form 0FCEE9247A9
+into the longer form 3Ps0FS1Zhtz1PFjb, and changes new Message-ID
+header values from YYMMDDHHMMSS.queueid@myhostname into the shorter
+form queueid@myhostname.
+
+Major changes - memcache
+------------------------
+
+[Feature 20111209] memcache lookup and update support. This provides
+a way to share postscreen(8) or verify(8) caches between Postfix
+instances. See MEMCACHE_README and memcache_table(5) for details
+and limitations.
+
+[Feature 20111213] Support for a persistent backup database in the
+memcache client. The memcache client updates the memcache whenever
+it looks up or modifies information in the persistent database.
+
+Major changes - postconf
+------------------------
+
+The postconf command was restructured - it now warns about unused
+parameter name=value settings in main.cf or master.cf (likely to
+be mistakes), it now understands "dynamic" parameter names such as
+parameters whose name depends on the name of a master.cf entry, and
+it can display main.cf and master.cf in a more user-friendly format.
+
+[Feature 20120117] support for legacy database parameter names
+(main.cf parameter names that are generated by prepending a suffix
+to the database name).
+
+[Feature 20111118] The "postconf -M" (display master.cf) command
+now supports filtering. For example, specify "postconf -M inet"
+to display only services that listen on the network.
+
+[Feature 20111113] postconf support to warn about unused "name=value"
+entries in main.cf, and about unused "-o name=value" entries in
+master.cf. This should help to eliminate common errors with mis-typed
+names.
+
+[Feature 20111108] postconf support for parameter names that are
+generated automatically from master.cf entries (delivery agents,
+spawn services), and for parameter names that are defined with
+main.cf smtpd_restriction_classes.
+
+[Feature 20111106] "postconf -M" support to print master.cf entries,
+and "postconf -f" support to fold long main.cf or master.cf lines
+for human readability.
+
+Major changes - trickle defense
+-------------------------------
+
+[Feature 20110212] Support for per-record deadlines. These change
+the behavior of Postfix timeout parameters, from a time limit per
+read or write system call, to a time limit to send or receive a
+complete record (an SMTP command line, SMTP response line, SMTP
+message content line, or TLS protocol message). This limits the
+impact from hostile peers that trickle data one byte at a time.
+
+The new configuration parameters and their default settings are:
+smtpd_per_record_deadline (normal: no, overload: yes),
+smtp_per_record_deadline (no), and lmtp_per_record_deadline (no).
+
+Note: when per-record deadlines are enabled, a short time limit may
+cause problems with TLS over very slow network connections. The
+reason is that a TLS protocol message can be up to 16 kbytes long
+(with TLSv1), and that an entire TLS protocol message must be sent
+or received within the per-record deadline.
+
+Per-record deadlines were introduced with postscreen(8) in Postfix
+2.8. This program does not receive mail, and therefore it has no
+problems with TLS over slow connections.
+
+Major changes - postscreen
+--------------------------
+
+[Feature 20111211] The proxymap(8) server can now be used to share
+postscreen(8) or verify(8) caches between Postfix instances. Support
+for proxymap-over-TCP, to share a Postfix database between hosts,
+is expected to be completed in the Postfix 2.10 development cycle.
+
+[Feature 20111209] memcache lookup and update support. This provides
+a way to share postscreen(8) or verify(8) caches between Postfix
+instances.
+
+[Feature 20110228] postscreen(8) support to force remote SMTP clients
+to implement proper MX lookup policy. By listening on both primary
+and backup MX addresses, postscreen(8) can deny the temporary
+whitelist status to clients that connect only to backup MX hosts,
+and prevent them from talking to a Postfix SMTP server process.
+
+Example: when 1.2.3.4 is a local backup IP address, specify
+"postscreen_whitelist_interfaces = !1.2.3.4 static:all".
+
+Major changes - tls
+-------------------
+
+[Incompat 20111205] Postfix now logs the result of successful TLS
+negotiation with TLS logging levels of 0. See the smtp_tls_loglevel
+and smtpd_tls_loglevel descriptions in the postconf(5) manpage for
+other minor differences.
+
+[Feature 20111205] Support for TLS public key fingerprint matching
+in the Postfix SMTP client (in smtp_tls_policy_maps) and server (in
+check_ccert access maps). Public key fingerprints are inherently
+more specific than fingerprints over the entire certificate.
+
+[Feature 20111205] Revision of Postfix TLS logging. The main
+difference is that Postfix now logs the result of successful TLS
+negotiation with TLS logging levels of 0. See the smtp_tls_loglevel
+and smtpd_tls_loglevel descriptions in the postconf(5) manpage for
+other minor differences.
+
+Major changes - sasl authentication
+-----------------------------------
+
+[Incompat 20111218] To support external SASL authentication, e.g.,
+in an NGINX proxy daemon, the Postfix SMTP server now always checks
+the smtpd_sender_login_maps table, even without having
+"smtpd_sasl_auth_enable = yes" in main.cf.
+
+[Feature 20111218] Support for external SASL authentication via the
+XCLIENT command. This is used to accept SASL authentication from
+an SMTP proxy such as NGINX. This support works even without having
+to specify "smtpd_sasl_auth_enable = yes" in main.cf.
+
+[Incompat 20111106] To work around broken remote SMTP servers, the
+Postfix SMTP client by default no longer appends the "AUTH=<>"
+option to the MAIL FROM command. Specify "smtp_send_dummy_mail_auth
+= yes" to restore the old behavior.
+
+Major changes - large file support
+----------------------------------
+
+[Feature 20110219] Postfix now uses long integers for message_size_limit,
+mailbox_size_limit and virtual_mailbox_limit. On LP64 systems (64-bit
+long and pointer, but 32-bit integer), these limits can now exceed
+2GB.
+
+Major changes - ipv6
+--------------------
+
+[Incompat 20110918] The following changes were made in default
+settings, in preparation for general availability of IPv6:
+
+- The default inet_protocols value is now "all" instead of "ipv4",
+ meaning use both IPv4 and IPv6.
+
+ To avoid an unexpected loss of performance for sites without
+ global IPv6 connectivity, the commands "make upgrade" and "postfix
+ upgrade-configuration" now append "inet_protocols = ipv4" to
+ main.cf when no explicit inet_protocols setting is already present.
+ This workaround will be removed in a future release.
+
+- The default smtp_address_preference value is now "any" instead
+ of "ipv6", meaning choose randomly between IPv6 and IPv4. With
+ this the Postfix SMTP client will have more success delivering
+ mail to sites that have problematic IPv6 configurations.
+
+Major changes - address verification
+------------------------------------
+
+[Feature 20111211] The proxymap(8) server can now be used to share
+postscreen(8) or verify(8) caches between Postfix instances. Support
+for proxymap-over-TCP, to share a Postfix database between hosts,
+is expected to be completed in the Postfix 2.10 development cycle.
+
+[Feature 20111209] memcache lookup and update support. This provides
+a way to share postscreen(8) or verify(8) caches between Postfix
+instances.
+
+[Feature 20111203] Support for time-dependent sender addresses
+of address verification probes. The default address, double-bounce,
+may end up on spammer blacklists. Although Postfix discards mail
+for this address, such mail still uses up network bandwidth and
+server resources. Specify an address_verify_sender_ttl value of
+several hours or more to frustrate address harvesting.
+
+Major changes - session transcript notification
+-----------------------------------------------
+
+[Incompat 20120114] By default the Postfix SMTP server no longer
+reports transcripts of sessions where a client command is rejected
+because a lookup table is unavailable. Postfix now implements gradual
+degradation, for example, the SMTP server keeps running instead of
+terminating with a fatal error. This change in error handling would
+result in a very large number of "transcript of session" email
+notifications when an LDAP or *SQL server goes down).
+
+To receive such reports, add the new "data" class to the notify_classes
+parameter value. The reports will be sent to the error_notice_recipient
+address as before. This class is also used by the Postfix SMTP
+client to report about sessions that fail because a table is
+unavailable.
+
+Major changes - logging
+----------------------------------------
+
+[Incompat 20120114] Logfile-based alerting systems may need to be
+updated to look for "error" messages in addition to "fatal" messages.
+Specify "daemon_table_open_error_is_fatal = yes" to get the historical
+behavior (immediate termination with "fatal" message).
+
+[Incompat 20111214] Logfile-based analysis tools may need to be
+updated. The submission and smtps examples in the sample master.cf
+file were updated to make their logging easier to distinguish.
+
+See the source file pflogsumm_quickfix.txt for a "quick fix".
+
+[Incompat 20111205] Postfix now logs the result of successful TLS
+negotiation with TLS logging levels of 0. See the smtp_tls_loglevel
+and smtpd_tls_loglevel descriptions in the postconf(5) manpage for
+other minor differences.
+
+[Incompat 20110219] The Postfix SMTP and QMQP servers now log
+"hostname X does not resolve to address Y", when a "reverse hostname"
+lookup result does not resolve to the client IP address. Until now
+these servers logged "Y: hostname X verification failed" or "Y:
+address not listed for hostname X" which people found confusing.
diff --git a/RELEASE_NOTES-3.0 b/RELEASE_NOTES-3.0
new file mode 100644
index 0000000..62ee5e3
--- /dev/null
+++ b/RELEASE_NOTES-3.0
@@ -0,0 +1,628 @@
+The stable Postfix release is called postfix-3.0.x where 3=major
+release number, 0=minor release number, x=patchlevel. The stable
+release never changes except for patches that address bugs or
+emergencies. Patches change the patchlevel and the release date.
+
+New features are developed in snapshot releases. These are called
+postfix-3.1-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+mm=month, dd=day). Patches are never issued for snapshot releases;
+instead, a new snapshot is released.
+
+The mail_release_date configuration parameter (format: yyyymmdd)
+specifies the release date of a stable release or snapshot release.
+
+If you upgrade from Postfix 2.10 or earlier, read RELEASE_NOTES-2.11
+before proceeding.
+
+Notes for distribution maintainers
+----------------------------------
+
+* New backwards-compatibility safety net.
+
+With NEW Postfix installs, you MUST install a main.cf file with
+the setting "compatibility_level = 2". See conf/main.cf for an
+example.
+
+With UPGRADES of existing Postfix systems, you MUST NOT change the
+main.cf compatibility_level setting, nor add this setting if it
+does not exist.
+
+Several Postfix default settings have changed with Postfix 3.0. To
+avoid massive frustration with existing Postfix installations,
+Postfix 3.0 comes with a safety net that forces Postfix to keep
+running with backwards-compatible main.cf and master.cf default
+settings. This safety net depends on the main.cf compatibility_level
+setting (default: 0). Details are in COMPATIBILITY_README.
+
+* New Postfix build system.
+
+The Postfix build/install procedure has changed to support Postfix
+dynamically-linked libraries and database plugins. These must not
+be "shared" with non-Postfix programs, and therefore must not be
+installed in a public directory.
+
+To avoid massive frustration due to broken patches, PLEASE BUILD
+POSTFIX FIRST WITHOUT APPLYING ANY PATCHES. Follow the INSTALL
+instructions (see "Building with Postfix dynamically-linked libraries
+and database plugins"), and see how things work and what the
+dynamically-linked libraries, database plugin, and configuration
+files look like. Then, go ahead and perform your platform-specific
+customizations. The INSTALL section "Tips for distribution maintainers"
+has further suggestions.
+
+Major changes - critical
+------------------------
+
+[Incompat 20140714] After upgrading Postfix, "postfix reload" (or
+start/stop) is required. Several Postfix-internal protocols have
+been extended to support SMTPUTF8. Failure to reload or restart
+will result in mail staying queued, while Postfix daemons log
+warning messages about unexpected attributes.
+
+Major changes - default settings
+--------------------------------
+
+[Incompat 20141009] The default settings have changed for relay_domains
+(new: empty, old: $mydestination) and mynetworks_style (new: host,
+old: subnet). However the backwards-compatibility safety net will
+prevent these changes from taking effect, giving the system
+administrator the option to make an old default setting permanent
+in main.cf or to adopt the new default setting, before turning off
+backwards compatibility. See COMPATIBILITY_README for details.
+
+[Incompat 20141001] A new backwards-compatibility safety net forces
+Postfix to run with backwards-compatible main.cf and master.cf
+default settings after an upgrade to a newer but incompatible Postfix
+version. See COMPATIBILITY_README for details.
+
+While the backwards-compatible default settings are in effect,
+Postfix logs what services or what email would be affected by the
+incompatible change. Based on this the administrator can make some
+backwards-compatibility settings permanent in main.cf or master.cf,
+before turning off backwards compatibility.
+
+See postconf.5.html#compatibility_level for details.
+
+[Incompat 20141001] The default settings
+have changed for append_dot_mydomain (new: no. old: yes), master.cf
+chroot (new: n, old: y), and smtputf8 (new: yes, old: no).
+
+Major changes - access control
+------------------------------
+
+[Feature 20141119] Support for BCC actions in header/body_checks
+and milter_header_checks. There is no limit on the number of BCC
+actions that may be specified, other than the implicit limit due
+to finite storage. BCC support will not be implemented in Postfix
+delivery agent header/body_checks.
+
+It works in the same way as always_bcc and sender/recipient_bcc_maps:
+there can be only one address per action, recipients are added with
+the NOTIFY=NONE delivery status notification option, and duplicate
+recipients are ignored (with the same delivery status notification
+options).
+
+[Incompat 20141009] The default settings have changed for relay_domains
+(new: empty, old: $mydestination) and mynetworks_style (new: host,
+old: subnet). However the backwards-compatibility safety net will
+prevent these changes from taking effect, giving the system
+administrator the option to make an old default setting permanent
+in main.cf or to adopt the new default setting, before turning off
+backwards compatibility. See COMPATIBILITY_README for details.
+
+[Feature 20140618] New INFO action in access(5) tables, for consistency
+with header/body_checks.
+
+[Feature 20140620] New check_xxx_a_access (for xxx in client,
+reverse_client, helo, sender, recipient) implements access control
+on all A and AAAA IP addresses for respectively the client hostname,
+helo parameter, sender domain or recipient domain. This complements
+the existing check_xxx_mx_access and check_xxx_ns_access features.
+
+Major changes - address rewriting
+---------------------------------
+
+[Incompat 20141001] The default settings have changed for
+append_dot_mydomain (new: no. old: yes), master.cf chroot (new:
+n, old: y), and smtputf8 (new: yes, old: no).
+
+Major changes - address verification
+------------------------------------
+
+[Feature 20141227] The new smtp_address_verify_target parameter
+(default: rcpt) specifies what protocol stage decides if a recipient
+is valid. Specify "data" for servers that reject invalid recipients
+in response to the DATA command.
+
+Major changes - database support
+--------------------------------
+
+[Feature 20140512] Support for Berkeley DB version 6.
+
+[Feature 20140618] The "randmap" lookup table performs random
+selection. This may be used to implement load balancing, for example:
+
+/etc/postfix/transport:
+ # Deliver my own domain as usual.
+ example.com :
+ .example.com :
+
+/etc/postfix/main.cf:
+ transport_maps =
+ # Deliver my own domain as usual.
+ hash:/etc/postfix/transport
+ # Deliver other domains via randomly-selected relayhosts
+ randmap:{smtp:smtp0.example.com, smtp:smtp1.example.com}
+
+A variant of this can randomly select SMTP clients with different
+smtp_bind_address settings.
+
+To implement different weights, specify lookup results multiple
+times. For example, to choose smtp:smtp1.example.com twice as often
+as smtp:smtp0.example.com, specify smtp:smtp1.example.com twice.
+
+A future version may support randmap:/path/to/file to load a list
+of results from file.
+
+[Feature 20140618] As the name suggests, the "pipemap" table
+implements a pipeline of lookup tables. The name of the table
+specifies the pipeline as a sequence of tables. For example, the
+following prevents SMTP mail to system accounts that have "nologin"
+as their login shell:
+
+ /etc/postfix/main.cf:
+ local_recipient_maps =
+ pipemap:{unix:passwd.byname, pcre:/etc/postfix/no-nologin.pcre}
+ alias_maps
+
+ /etc/postfix/no-nologin.pcre:
+ !/nologin/ whatever
+
+Each "pipemap:" query is given to the first table. Each table
+lookup result becomes the query for the next table in the pipeline,
+and the last table produces the final result. When any table lookup
+produces no result, the entire pipeline produces no result.
+
+A future version may support pipemap:/path/to/file to load a list
+of lookup tables from file.
+
+[Feature 20140924] Support for unionmap, with the same syntax as
+pipemap. This sends a query to all tables, and concatenates non-empty
+results, separated by comma.
+
+[Feature 20131121] The "static" lookup table now supports whitespace
+when invoked as "static:{ text with whitespace }", so that it can
+be used, for example, at the end of smtpd_mumble_restrictions as
+"check_mumble_access static:{reject text...}".
+
+[Feature 20141126] "inline:{key=value, { key = text with comma/space}}"
+avoids the need to create a database for just a few entries.
+
+Major changes - delivery status notifications
+---------------------------------------------
+
+[Feature 20140321] Delivery status filter support, to replace the
+delivery status codes and explanatory text of successful or
+unsuccessful deliveries by Postfix mail delivery agents.
+
+This was originally implemented for sites that want to turn certain
+soft delivery errors into hard delivery errors, but it can also be
+used to censor out information from delivery confirmation reports.
+
+This feature is implemented as a filter that replaces the three-number
+enhanced status code and descriptive text in Postfix delivery agent
+success, bounce, or defer messages. Note: this will not override
+"soft_bounce=yes", and this will not change a successful delivery
+status into an unsuccessful status or vice versa.
+
+The first example turns specific soft TLS errors into hard
+errors, by overriding the first number in the enhanced status code.
+
+/etc/postfix/main.cf:
+ smtp_delivery_status_filter = pcre:/etc/postfix/smtp_dsn_filter
+
+/etc/postfix/smtp_dsn_filter:
+ /^4(\.\d+\.\d+ TLS is required, but host \S+ refused to start TLS: .+)/ 5$1
+ /^4(\.\d+\.\d+ TLS is required, but was not offered by host .+)/ 5$1
+
+The second example removes the destination command name and file
+name from local(8) successful delivery reports, so that they will
+not be reported when a sender requests confirmation of delivery.
+
+/etc/postfix/main.cf:
+ local_delivery_status_filter = pcre:/etc/postfix/local_dsn_filter
+
+/etc/postfix/local_dsn_filter:
+ /^(2\S+ delivered to file).+/ $1
+ /^(2\S+ delivered to command).+/ $1
+
+This feature is supported in the lmtp(8), local(8), pipe(8), smtp(8)
+and virtual(8) delivery agents. That is, all delivery agents that
+actually deliver mail. It will not be implemented in the error and
+retry pseudo-delivery agents.
+
+The new main.cf parameters and default values are:
+
+ default_delivery_status_filter =
+ lmtp_delivery_status_filter = $default_delivery_status_filter
+ local_delivery_status_filter = $default_delivery_status_filter
+ pipe_delivery_status_filter = $default_delivery_status_filter
+ smtp_delivery_status_filter = $default_delivery_status_filter
+ virtual_delivery_status_filter = $default_delivery_status_filter
+
+See the postconf(5) manpage for more details.
+
+[Incompat 20140618] The pipe(8) delivery agent will now log a limited
+amount of command output upon successful delivery, and will report
+that output in "SUCCESS" delivery status reports. This is another
+good reason to disable inbound DSN requests at the Internet perimeter.
+
+[Feature 20140907] With "confirm_delay_cleared = yes", Postfix
+informs the sender when delayed mail leaves the queue (this is in
+addition to the delay_warning_time feature that warns when mail is
+still queued). This feature is disabled by default, because it can
+result in a sudden burst of notifications when the queue drains at
+the end of a prolonged network outage.
+
+Major changes - dns
+-------------------
+
+[Feature 20141128] Support for DNS server reply filters in the
+Postfix SMTP/LMTP client and SMTP server. This helps to work around
+mail delivery problems with sites that have incorrect DNS information.
+Note: this has no effect on the implicit DNS lookups that are made
+by nsswitch.conf or equivalent mechanisms.
+
+This feature renders each lookup result as one line of text in
+standard zone-file format as shown below. The class field is always
+"IN", the preference field exists only for MX records, the names
+of hosts, domains, etc. end in ".", and those names are in ASCII
+form (xn--mumble form for internationalized domain names).
+
+ name ttl class type preference value
+ ---------------------------------------------------------
+ postfix.org. 86400 IN MX 10 mail.cloud9.net.
+
+Typically, one would match this text with a regexp: or pcre: table.
+When a match is found, the table lookup result specifies an action.
+By default, the table query and the action name are case-insensitive.
+Currently, only the IGNORE action is implemented.
+
+For safety reasons, Postfix logs a warning or defers mail delivery
+when a DNS reply filter removes all lookup results from a successful
+query.
+
+The Postfix SMTP/LMTP client uses the smtp_dns_reply_filter and
+lmtp_dns_reply_filter features only for Postfix SMTP client lookups
+of MX, A, and AAAAA records to locate a remote SMTP or LMTP server,
+including lookups that implement the features reject_unverified_sender
+and reject_unverified_recipient. The filters are not used for lookups
+made through nsswitch.conf and similar mechanisms.
+
+The Postfix SMTP server uses the smtpd_dns_reply_filter feature
+only for Postfix SMTP server lookups of MX, A, AAAAA, and TXT records
+to implement the features reject_unknown_helo_hostname,
+reject_unknown_sender_domain, reject_unknown_recipient_domain,
+reject_rbl_*, and reject_rhsbl_*. The filter is not used for lookups
+made through nsswitch.conf and similar mechanisms, such as lookups
+of the remote SMTP client name.
+
+[Feature 20141126] Nullmx support (MX records with a null hostname).
+This change affects error messages only. The Postfix SMTP client
+already bounced mail for such domains, and the Postfix SMTP server
+already rejected such domains with reject_unknown_sender/recipient_domain.
+This feature introduces a new SMTP server configuration parameter
+nullmx_reject_code (default: 556).
+
+Major changes - dynamic linking
+-------------------------------
+
+[Feature 20140530] Support to build Postfix with Postfix
+dynamically-linked libraries, and with dynamically-loadable database
+clients. These MUST NOT be used by non-Postfix programs. Postfix
+dynamically-linked libraries introduce minor runtime overhead and
+result in smaller Postfix executable files. Dynamically-loadable
+database clients are useful when you distribute or install pre-compiled
+packages. Postfix 3.0 supports dynamic loading for CDB, LDAP, LMDB,
+MYSQL, PCRE, PGSQL, SDBM, and SQLITE database clients.
+
+This implementation is based on Debian code by LaMont Jones, initially
+ported by Viktor Dukhovni. Currently, support exists for recent
+versions of Linux, FreeBSD, MacOS X, and for the ancient Solaris 9.
+
+To support Postfix dynamically-linked libraries and dynamically-loadable
+database clients, the Postfix build procedure had to be changed
+(specifically, the files makedefs and Makefile.in, and the files
+postfix-install and post-install that install or update Postfix).
+
+[Incompat 20140530] The Postfix 3.0 build procedure expects that
+you specify database library dependencies with variables named
+AUXLIBS_CDB, AUXLIBS_LDAP, etc. With Postfix 3.0 and later, the
+old AUXLIBS variable still supports building a statically-loaded
+CDB etc. database client, but only the new AUXLIBS_CDB etc. variables
+support building a dynamically-loaded or statically-loaded CDB etc.
+database client. See CDB_README, LDAP_README, etc. for details.
+
+Failure to follow this advice will defeat the purpose of dynamic
+database client loading. Every Postfix executable file will have
+database library dependencies. And that was exactly what dynamic
+database client loading was meant to avoid.
+
+Major changes - future proofing
+-------------------------------
+
+[Cleanup 20141224] The changes described here have no visible effect
+on Postfix behavior, but they make Postfix code easier to maintain,
+and therefore make new functionality easier to add.
+
+* Compile-time argument typechecks of non-printf/scanf-like variadic
+ function argument lists.
+
+* Deprecating the use of "char *" for non-text purposes such as
+ memory allocation and pointers to application context for call-back
+ functions. This dates from long-past days before void * became
+ universally available.
+
+* Replace integer types for counters and sizes with size_t or ssize_t
+ equivalents. This eliminates some wasteful 64<->32bit conversions
+ on 64-bit systems.
+
+Major changes - installation pathnames
+--------------------------------------
+
+[Incompat 20140625] For compliance with file system policies, some
+non-executable files have been moved from $daemon_directory to the
+directory specified with the new meta_directory configuration
+parameter which has the same default value as the config_directory
+parameter. This change affects non-executable files that are shared
+between multiple Postfix instances such as postfix-files, dynamicmaps.cf,
+and multi-instance template files.
+
+For backwards compatibility with Postfix 2.6 .. 2.11, specify
+"meta_directory = $daemon_directory" in main.cf before installing
+or upgrading Postfix, or specify "meta_directory = /path/name" on
+the "make makefiles", "make install" or "make upgrade" command line.
+
+Major changes - milter
+----------------------
+
+[Feature 20140928] Support for per-Milter settings that override
+main.cf parameters. For details see the section "Advanced policy
+client configuration" in the SMTPD_POLICY_README document.
+
+Here is an example that uses both old and new syntax:
+
+ smtpd_milters = { inet:127.0.0.1:port1, default_action=accept, ... },
+ inet:127.0.0.1:port2, ...
+
+The supported attribute names are: command_timeout, connect_timeout,
+content_timeout, default_action, and protocol. These have the same
+names as the corresponding main.cf parameters, without the "milter_"
+prefix.
+
+The per-milter settings are specified as attribute=value pairs
+separated by comma or space; specify { name = value } to allow
+spaces around the "=" or within an attribute value.
+
+[Feature 20141018] DMARC compatibility: when a Milter inserts a
+header ABOVE Postfix's own Received: header, Postfix no longer
+exposes its own Received: header to Milters (violating protocol)
+and Postfix no longer hides the Milter-inserted header from Milters
+(wtf).
+
+Major changes - parameter syntax
+--------------------------------
+
+[Feature 20140921] In preparation for configurable mail headers and
+logging, new main.cf support for if-then-else expressions:
+
+ ${name?{text1}:{text2}}
+
+and for logical expressions:
+
+ ${{text1}=={text2}?{text3}:{text4}}
+ ${{text1}!={text2}?{text3}:{text4}}
+
+Whitespace before and after {text} is ignored. This can help to
+make complex expressions more readable. See the postconf(5) manpage
+for further details.
+
+[Feature 20140928] Support for whitespace in daemon command-line
+arguments. For details, see the "Command name + arguments" section
+in the master(5) manpage. Example:
+
+ smtpd -o { parameter = value containing whitespace } ...
+
+The { ... } form is also available for non-option command-line
+arguments in master.cf, for example:
+
+ pipe ... argv=command { argument containing whitespace } ...
+
+In both cases, whitespace immediately after "{" and before "}"
+is ignored.
+
+[Feature 20141005] Postfix import_environment and export_environment
+now allow "{ name=value }" to protect whitespace in attribute values.
+
+[Feature 20141006] The new message_drop_header parameter replaces
+a hard-coded table that specifies what message headers the cleanup
+daemon will remove. The list of supported header names covers RFC
+5321, 5322, MIME RFCs, and some historical names.
+
+Major changes - pipe daemon
+---------------------------
+
+[Incompat 20140618] The pipe(8) delivery agent will now log a limited
+amount of command output upon successful delivery, and will report
+that output in "SUCCESS" delivery status reports. This is another
+good reason to disable inbound DSN requests at the Internet perimeter.
+
+Major changes - policy client
+-----------------------------
+
+[Feature 20140703] This release introduces three new configuration
+parameters that control error recovery for failed SMTPD policy
+requests.
+
+ * smtpd_policy_service_default_action (default: 451 4.3.5 Server
+ configuration problem): The default action when an SMTPD policy
+ service request fails.
+
+ * smtpd_policy_service_try_limit (default: 2): The maximal number
+ of attempts to send an SMTPD policy service request before
+ giving up. This must be a number greater than zero.
+
+ * smtpd_policy_service_retry_delay (default: 1s): The delay between
+ attempts to resend a failed SMTPD policy service request. This
+ must be a number greater than zero.
+
+See postconf(5) for details and limitations.
+
+[Feature 20140928] Support for per-policy service settings that
+override main.cf parameters. For details see the section "Different
+settings for different Milter applications" in the MILTER_README
+document.
+
+Here is an example that uses both old and new syntax:
+
+smtpd_recipient_restrictions = ...
+ check_policy_service { inet:127.0.0.1:port3, default_action=DUNNO }
+ check_policy_service inet:127.0.0.1:port4
+ ...
+
+The per-policy service settings are specified as attribute=value pairs
+separated by comma or space; specify { name = value } to allow
+spaces around the "=" or within an attribute value.
+
+The supported attribute names are: default_action, max_idle, max_ttl,
+request_limit, retry_delay, timeout, try_limit. These have the same
+names as the corresponding main.cf parameters, without the
+"smtpd_policy_service_" prefix.
+
+[Feature 20140505] A client port attribute was added to the policy
+delegation protocol.
+
+[Feature 20140630] New smtpd_policy_service_request_limit feature to
+limit the number of requests per Postfix SMTP server policy connection.
+This is a workaround to avoid error-recovery delays with policy
+servers that cannot maintain a persistent connection.
+
+Major changes - position-independent executables
+------------------------------------------------
+
+[Feature 20150205] Preliminary support for building position-independent
+executables (PIE), tested on Fedora Core 20, Ubuntu 14.04, FreeBSD
+9 and 10, and NetBSD 6. Specify:
+
+$ make makefiles pie=yes ...other arguments...
+
+On some systems, PIE is used by the ASLR exploit mitigation technique
+(ASLR = Address-Space Layout Randomization). Whether specifying
+"pie=yes" has any effect at all depends on the compiler. Reportedly,
+some compilers always produce PIE executables.
+
+Major changes - postscreen
+--------------------------
+
+[Feature 20140501] Configurable time limit (postscreen_dnsbl_timeout)
+for DNSBL or DNSWL lookups. This is separate from the timeouts in
+the dnsblog(8) daemon which are controlled by system resolver(3)
+routines.
+
+Major changes - session fingerprint
+-----------------------------------
+
+[Feature 20140801] The Postfix SMTP server now logs at the end of
+a session how many times an SMTP command was successfully invoked,
+followed by the total number of invocations if some invocations
+were unsuccessful.
+
+This logging will enough to diagnose many problems without using
+verbose logging or network sniffer.
+
+ Normal session, no TLS:
+ disconnect from name[addr] ehlo=1 mail=1 rcpt=1 data=1 quit=1
+
+ Normal session. with TLS:
+ disconnect from name[addr] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1
+
+ All recipients rejected, no ESMTP command pipelining:
+ disconnect from name[addr] ehlo=1 mail=1 rcpt=0/1 quit=1
+
+ All recipients rejected, with ESMTP command pipelining:
+ disconnect from name[addr] ehlo=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1
+
+ Password guessing bot, hangs up without QUIT:
+ disconnect from name[addr] ehlo=1 auth=0/1
+
+ Mis-configured client trying to use TLS wrappermode on port 587:
+ disconnect from name[addr] unknown=0/1
+
+Logfile analyzers can trigger on the presence of "/". It indicates
+that Postfix rejected at least one command.
+
+[Feature 20150118] As a late addition, the SMTP server now also
+logs the total number of commands (as "commands=x/y") even when the
+client did not send any commands. This helps logfile analyzers to
+recognize sessions without commands.
+
+Major changes - smtp client
+---------------------------
+
+[Feature 20141227] The new smtp_address_verify_target parameter
+(default: rcpt) determines what protocol stage decides if a recipient
+is valid. Specify "data" for servers that reject recipients after
+the DATA command.
+
+Major changes - smtputf8
+------------------------
+
+[Incompat 20141001] The default settings have changed for
+append_dot_mydomain (new: no, old: yes), master.cf chroot (new:
+n, old: y), and smtputf8 (new: yes, old: no).
+
+[Incompat 20140714] After upgrading Postfix, "postfix reload" (or
+start/stop) is required. Several Postfix-internal protocols have
+been extended to support SMTPUTF8. Failure to reload or restart
+will result in mail staying queued, while Postfix daemons log
+warning messages about unexpected attributes.
+
+[Feature 20140715] Support for Email Address Internationalization
+(EAI) as defined in RFC 6531..6533. This supports UTF-8 in SMTP/LMTP
+sender addresses, recipient addresses, and message header values.
+The implementation is based on initial work by Arnt Gulbrandsen
+that was funded by CNNIC.
+
+See SMTPUTF8_README for a description of Postfix SMTPUTF8 support.
+
+[Feature 20150112] UTF-8 Casefolding support for Postfix lookup
+tables and matchlists (mydestination, relay_domains, etc.). This
+is enabled only with "smtpuf8 = yes".
+
+[Feature 20150112] With smtputf8_enable=yes, SMTP commands with
+UTF-8 syntax errors are rejected, table lookup results with invalid
+UTF-8 syntax are handled as configuration errors, and UTF-8 syntax
+errors in policy server replies result in execution of the policy
+server's default action.
+
+Major changes - tls support
+---------------------------
+
+(see "Major changes - delivery status notifications" above for
+turning 4XX soft errors into 5XX bounces when a remote SMTP server
+does not offer STARTTLS support).
+
+[Feature 20140209] the Postfix SMTP client now also falls back to
+plaintext when TLS fails AFTER the TLS protocol handshake.
+
+[Feature 20140218] The Postfix SMTP client now requires that a queue
+file is older than $minimal_backoff_time, before falling back from
+failed TLS to plaintext (both during or after the TLS handshake).
+
+[Feature 20141021] Per IETF TLS WG consensus, the tls_session_ticket_cipher
+default setting was changed from aes-128-cbc to aes-256-cbc.
+
+[Feature 20150116] TLS wrappermode support in the Postfix smtp(8)
+client (new smtp_tls_wrappermode parameter) and in posttls-finger(1)
+(new -w option). There still is life in that deprecated protocol,
+and people should not have to jump hoops with stunnel.
diff --git a/TLS_ACKNOWLEDGEMENTS b/TLS_ACKNOWLEDGEMENTS
new file mode 100644
index 0000000..93c93d5
--- /dev/null
+++ b/TLS_ACKNOWLEDGEMENTS
@@ -0,0 +1,56 @@
+- Walcir Fontanini
+ * tested on Solaris 2.5 and and reported missing "snprintf()"
+ -> was fixed in pfixtls-0.1.2
+ * contributed the script to add fingerprints
+ contributed/fp.csh
+
+- Matti Aarnio (www.zmailer.org)
+ * updated pfixtls_dump to need fewer strcat and strcpy calls.
+
+- Cerebus
+ * Missing variable initialization in client mode enable STARTTLS
+ negotiation even when not wanted.
+ -> fixed in pfixtls-0.2.8
+
+- Bodo Moeller
+ * The SSL connection was not shut down at the end of the session, because
+ SSL_CTX_set_quiet_shutdown() was set. This however did not mean "do a
+ quiet shutdown" but "do not shutdown SSL".
+ -> fixed in pfixtls-0.3.3
+
+- Jeff Johnson
+ * noted that the patch code will not compile with SSL disabled anymore,
+ because a ´#ifdef HAS_SSL #endif´ encapsulation was missing in
+ smtp/smtp_connect.c. This must have been in since the very beginning
+ of client mode support (0.2.x).
+ -> fixed in 0.3.6
+
+- Craig Sanders
+ * noted that the Received: header does not contain sufficient information
+ whether a client certificate was not requested or not presented.
+ He also reminded me that the session cache must be cleared when
+ experimenting with the setup and certificates, what is not explained
+ in the documenation.
+ -> fixed in 0.4.4
+
+- Claus Assmann
+ * pointed out that the Received: header logging about the TLS state violated
+ RFC822. The TLS information must be in comment form "(info)".
+ -> fixed in 0.6.3
+
+- Wietse Venema
+ * uncounted important suggestions to start the integration into the Postfix
+ mainstream code.
+ * code adjustments in the dict_*() database code to allow easier inclusion
+ and use for session caching, and this is only the beginning :-)
+ -> started reprogramming Postfix/TLS to fit both Wietse's and my
+ requirements as of 0.6.0
+
+- Damien Miller
+ * Found mismatch between documentation and code with regard to logging.
+ -> fixed in 0.6.6
+
+- Deti Fliegl
+ * Provided an initial patch to support SubjectAlternativeName/dNSName
+ checks.
+ -> added in 0.8.14
diff --git a/TLS_CHANGES b/TLS_CHANGES
new file mode 100644
index 0000000..62a529e
--- /dev/null
+++ b/TLS_CHANGES
@@ -0,0 +1,2418 @@
+2004/09/12 == Released 0.8.19 ==
+
+2004/09/01
+ - Finished updating the code by adjusting to postfix-2.2-20040829
+ and started using it at my own site.
+
+2004/08/01
+ - Started adjusting the patch to postfix-2.2-20040729.
+
+2004/06/21 == Re-released 0.8.18 ==
+
+2004/06/21
+ - Postfix 2.1.3 has been released. Shortlived 2.1.2 did bring an
+ incompatibel change (patch conflict) which has been resolved.
+ - Fixed some typos in the tlsmgr.8 manual page (Chris Pepper
+ ).
+
+2004/04/27 == Re-released 0.8.18 ==
+
+2004/04/27
+ - Postfix 2.1.0 has been released. Some minor patch conflicts with respect
+ to the actual code and build environment.
+ - Due to the restructuring of the documentation the old sample-*.cf
+ files are no longer available.
+ Took documentation already adopted by Wietse for the 2.1-RC2-IPV6+TLS
+ snapshot.
+
+2004/02/09 == Re-released 0.8.18 ==
+
+2004/02/09
+ - Postfix 2.0.18-20040205 is available, patchkit applies without
+ problems.
+
+2004/02/02 == Release 0.8.18 ==
+
+2004/02/02
+ - Incorporated Luca Berra's information into the patchkit and ran tests
+ with my own versions.
+
+2004/02/01
+ - Reports about server side SMTP failure with Carsten's patch can be
+ found on postfix-users.
+ 'Luca Berra' informs, that he discoverd another
+ failure of the GNU patch program with a misplaced patch hunk in
+ smtpd.c
+
+2004/01/30
+ - Edited in additional #ifdef USE_TLS conditionals. If the TLS patch
+ is applied but not activated (USE_TLS is not defined), a warning is
+ printed as soon as TLS shall be used.
+
+2004/01/23
+ - Postfix 2.0.18-20040122 is now available. Several patch conflicts occur.
+ Even more: one hunk of the patch (which is provided in unified diff)
+ fails in smtp.c and causes a segmentation violation.
+ Carsten Hoeger provides an adapted patch kit.
+
+2004/01/02 == Released 0.8.17 ==
+
+2004/01/02
+ - Postfix-2.0.16-20031231 is released. No patch conflicts.
+ - Changed autoresponder for TLS tests to "The Postfix Book" echo
+ responder (provided by Patrick Koetter and Ralf Hildebrandt).
+
+2003/12/30
+ - Postfix-2.0.16-20031226 is released. No patch conflicts.
+
+2003/12/26
+ - Postfix-2.0.16-20031224 is released. Resolved patch conflicts.
+
+2003/12/16
+ - Postfix-2.0.16-20031215 is released. Resolved patch conflicts.
+ - src/global/pfixtls.c: changed occurance of "ssize_t" to "size_t"
+ as some quite old operating systems do no have ssize_t
+ (Reported by Klaus Jaehne for SunOS 4.1.4).
+ - src/global/pfixtls.c: both the client and the server engine did
+ print out messages even when tls_loglevel was set to 0 (reported
+ by Florian Effenberger ): evaluate loglevel
+ before printing any message.
+
+2003/11/17 == Re-released 0.8.16 ==
+
+2003/11/17
+ - Postfix 2.0.16-20031113 is released. Some minor patch conflicts.
+
+2003/10/27 == Re-released 0.8.16 ==
+
+2003/10/24
+ - Postfix 2.0.16-20031022 is released. Some minor patch conflicts.
+
+2003/09/23 == Re-released 0.8.16 ==
+
+2003/09/23
+ - Postfix 2.0.16 and 2.0.16-20030921 are now available.
+ Resolved some minor patch conflicts.
+
+2003/09/10 == Released 0.8.16 ==
+
+2003/09/09
+ - Postfix 2.0.15 has been released including another workaround for
+ select() on Solaris problems. It contains additional code to catch
+ EAGAIN on read() in the timed_read() routine (and the respective
+ precautions in timed_write()
+ - Note: this fix is not yet part of Postfix 2.0.14-20030812.
+ - Added corresponding code to pfixtls_timed_read()/_write().
+ - Changed SSL wrappermode behaviour: use smtpd_sasl_tls_security_options
+ instead of smtpd_sasl_security_options as is to be expected because TLS
+ is active. (Bug reported by Bob Snyder .)
+
+2003/08/29 == Re-released 0.8.15 ==
+
+2003/08/29
+ - Adapted patchkit to Postfix 2.0.14. No patch conflicts.
+
+2003/07/17 == Re-released 0.8.15a (-20030715 only) ==
+
+2003/07/16
+ - Experimental version Postfix 2.0.14-20030715 is released, including
+ the SASL changes. Resolved some minor patch conflicts.
+
+2003/07/11 == Released 0.8.15a (-20030706 only) ==
+
+2003/07/11
+ - Received error report about about TLS failing with the new smtpd_proxy
+ feature including instructions on how to reproduce.
+ (Did receive an earlier report on 2003/07/09, that however indicated other
+ setup problems, so that the actual problem was not visible.)
+ - Analysis: when introducing the new smtpd_proxy feature, different mechnisms
+ where introduced to either write to the cleanup daemon (as before) or to
+ the smtpd_proxy connection. Functions and streams are now expressed in
+ out_fprintf() function pointers etc. being assigned accordingly.
+ When updating to 0.8.15/2.0.13-20030706 this change was missed and the
+ routine adding the TLS information to the Received: headers did use the
+ older rec_fprintf() functions etc. This did work fine for the traditional
+ connection to the cleanup service, but naturally failed for smtpd_proxy
+ (with a segmentation violation).
+ Solution: access out_stream via the according pointers.
+ - The 2.0.13 stable version is not affected.
+
+2003/07/08 == Released 0.8.15 ==
+
+2003/07/07
+ - Postfix 2.0.13 and 2.0.13-20030706 are released.
+ Patchkit for 2.0.13 applies cleanly.
+ Patchkit for 2.0.13-20030607 requires several adaptations (patch conflicts,
+ no functional changes).
+ - Slightly modified SASL interface code (smpt[d]_sasl_glue layer) to
+ allow setting the security policy during session setup instead of
+ process start. This allows to actually choose SASL mechanisms available
+ depending on the availability of TLS encryption and authentication.
+ New parameters: smtpd_sasl_tls_security_options,
+ smtp_sasl_tls_security_options, smtp_sasl_tls_verified_security_options
+ - Submitted change to SASL interface to Wietse, who accepted the change
+ as part of the Snapshot line.
+
+2003/06/19 == Released 0.8.14 ==
+
+2003/06/19
+ - Add support for SubjectAlternativeName "dNSName" entries in certificate
+ checking (applies for client mode only).
+ If the client connects to the server, it does check the list of dNSName
+ entries against the expected hostname (therefore allowing the server to
+ have multiple identities). As described in RFC2818 (HTTP over TLS),
+ CommonName (CN) entries are only checked, if no dNSName entries are found
+ at all.
+ Initial patch proposed by Deti Fliegl , reworked to
+ follow the RFC2818 rules and some cleanup.
+
+2003/06/18
+ - Checked out similar settings, found another missing entry:
+ var_smtp_scert_vd was missing src/smtp/smtp.c.
+ - Renamed HAS_SSL to USE_TLS for compilation (have to use -DUSE_SSL
+ in the future). Currently pfixtls.h will take care of setting
+ USE_TLS, when HAS_SSL has been defined.
+
+2003/06/17
+ - Received bug reports about Postfix/TLS failing (connection closing)
+ after having finished the "STARTTLS"/"220 Ready to start TLS"
+ dialogue. (Actually the first report came in via private mail on
+ 2003/06/12, but the information was too diffuse to track down).
+ Tracking down became possible after it became clear, that only Solaris
+ systems are affected.
+ Analysis:
+ * As of 2003/06/09 postfix uses non-blocking socket I/O for the SMTP
+ connection on Solaris platforms. This requires using "select()" style
+ waiting before read() or write() access (which are not prepared EAGAIN
+ or EWOULDBLOCK in the Postfix case and therefore indicate error).
+ * As the var_smtpd_starttls_tmout variable is not correctly initialized
+ (value is 0), the select() style function is not called, therefore
+ read() fails with EAGAIN and the connection is closed due to a
+ presumed error condition.
+ * The initialization of the variable should be done in the time_table[]
+ list during main().
+ The entry however was lost during the patch adaptation from 0.7.13e
+ to 0.7.14-snap20020107 on 2002/01/07.
+ Impact:
+ * On Solaris systems, STARTTLS fails during handshake (server only).
+ * On other systems, the TLS negotiation phase is not protected by the
+ smtpd_starttls_tmout (default 300s) value and may hang until the
+ watchdog kills smtpd, if the client does not continue the handshake.
+ Restored var_smtpd_starttls_tmout variable initialization.
+
+2003/06/12 == Re-released 0.8.13 ==
+
+2003/06/11
+ - Adapted to snapshot 2.0.12-20030611. No patch conflicts.
+
+2003/06/11
+ - Adapted to snapshot 2.0.11-20030609. One minor patch conflict.
+
+2003/05/23 == Re-released 0.8.13 ==
+
+2003/05/23
+ - First release against snapshot 2.0.10-20030523.
+
+2003/04/26 == Re-released 0.8.13 ==
+
+2003/04/26
+ - Updated patchkit to apply to Postfix 2.0.9.
+ - Updated patchkit-name to reflect the release of OpenSSL 0.9.7b.
+
+2003/03/06 == Re-released 0.8.13 ==
+
+2003/03/06
+ - Postfix 2.0.6 has been released. No patch conflicts.
+
+2003/03/02 == Re-released 0.8.13 ==
+
+2003/03/02
+ - Postfix 2.0.4 has been released. "patch" should work with some warnings
+ about moved line numbers.
+ - OpenSSL 0.9.7a has been released. No visible changes with respect to
+ Postfix/TLS.
+
+2003/01/26 == Re-released 0.8.13 ==
+
+2003/01/26
+ - Postfix 2.0.3 has been released. One minor patch-conflict.
+
+2003/01/13 == Released 0.8.13 ==
+
+2003/01/13
+ - Postfix 2.0.1 has been released. Some minor patch conflicts resolved.
+ - Added HOWTO documents contributed by Justin Davies
+ to the contribution area.
+ - Added RFC3207 (SMTP Service Extension for Secure SMTP over Transport Layer
+ Security) to the documentation. RFC3207 is the successor of RFC2487.
+ - Updated TODO list to reflect release ideas up to the release of
+ Postfix/TLS 0.9.0. (Or will it finally be 1.0.0? :-)
+
+2002/12/30
+ - OpenSSL 0.9.7 has been released. Postfix/TLS works best with the new
+ 0.9.7 release.
+
+2002/12/24 == Re-released 0.8.12 ==
+
+2002/12/24
+ - Postfix 2.0.0.1 has been released. Resolved one minor patch conflict.
+
+2002/12/20 == Re-released 0.8.12 ==
+
+2002/12/20
+ - Postfix snapshot 1.1.12-20021214 has been released. Resolved minor
+ patch conflicts.
+
+2002/12/15 == Re-released 0.8.12 ==
+
+2002/12/15
+ - Postfix snapshot 1.1.12-20021214 has been released. Two minor patch
+ conflicts.
+
+2002/12/06 == Released 0.8.12 ==
+
+2002/12/06
+ - OpenSSL 0.9.6h has been released. Update documentation and filenames
+ to reflect this new release.
+ - Minor bug fix: when calling "sendmail -bs", smtpd is not run with
+ superuser permissions, therefore the loading of the private key fails.
+ STARTTLS is not used anyway, so the key is not needed anyway, but the
+ failure to load creates a misleading warning.
+ Do not initialize TLS engine at all when not started with superuser
+ permissions.
+
+2002/12/03
+ - Postfix snapshot 1.1.12-20021203 has been released. Resolved one patch
+ conflict.
+
+2002/11/01 == Re-released 0.8.11a ==
+
+2002/11/01
+ - Postfix snapshot 1.1.11-20021031 has been released. No patch conflicts.
+
+2002/10/30 == Re-released 0.8.11a ==
+
+2002/10/30
+ - Postfix snapshot 1.1.11-20021029 has been released. No patch conflicts.
+
+2002/09/30 == Re-released 0.8.11a ==
+
+2002/09/30
+ - Postfix snapshot 1.1.11-20020928 has been released. No patch conflices.
+
+2002/09/24
+ - Postfix snapshot 1.1.11-20020923 has been released. Adapt patchkit.
+
+2002/09/19 == Re-released 0.8.11a ==
+
+2002/09/18
+ - Postfix snapshot 1.1.11-20020917 has been released. Adapt patchkit.
+
+2002/08/23 == Re-released 0.8.11a ==
+
+2002/08/23
+ - Postfix snapshot 1.1.11-20020822 has been released. Adapt patchkit.
+
+2002/08/20
+ - Postfix snapshot 1.1.11-20020819 has been released with several
+ enhancements and changes. Adapt patchkit (minor issues).
+
+2002/08/12
+ - OpenSSL has experienced several (security critical) updates.
+
+2002/07/26 == Re-released 0.8.11a ==
+
+2002/07/26
+ - On popular demand, a new diff for the snapshot version of Postfix
+ is created: postfix-1.1.11-20020719.
+
+2002/06/18 == Re-released 0.8.11a ==
+
+2002/06/18
+ - On popular demand, a new diff for the snapshot versions of Postfix
+ is created: postfix-1.1.11-20020613.
+
+2002/06/03 == Released 0.8.11a ==
+
+2002/06/03
+ - When compiling with SSL but without SASL, compilation fails due to
+ the modification of state->sasl_mechanism_list that is not part of the
+ "state" structure when SASL is not compiled in.
+ This bug was introduced in version 0.8.11.
+ Bug reported and patch supplied by Bernd Matthes
+ .
+
+2002/05/29 == Released 0.8.11 ==
+
+2002/05/29
+ - Postfix 1.1.11 is released.
+
+2002/05/25
+ - Fix processing of options after STARTTLS handshaking: AUTH= was not
+ handled, as the "=" was not recognized as for the extension list for
+ the case without TLS. (The TLS case was a copy of an older version
+ of the code not yet containing the "=" and the change in the main
+ code slipped through without noting the difference, hence the option
+ as not added to the TLS part.
+ Found by "Christoph Vogel" .
+
+2002/05/24
+ - Bug reported by "Christoph Vogel" :
+ Client side AUTH does not work, if STARTTLS is used: if a server
+ announces AUTH and STARTTLS, AUTH is being used if TLS is disabled.
+ Once TLS is enabled, AUTH is still offered by the server, but the
+ client does not use it any longer.
+ Reason: when AUTH is offered, not only the SMTP_REATURE_AUTH flag
+ is set in state->features, but also the available mechanisms are
+ remembered in state->sasl_mechanism_list. As AUTH may be offered
+ twice by some hosts (in the correct "AUTH mech" form and the older
+ and deprecated "AUTH=mech" form), a check against processing the
+ line twice is included in smtp_sasl_helo_auth(). This check now
+ prevented the correct processing in the second evaluation of the
+ ESMTP extensions offered after the STARTTLS activation.
+ Solution: reset state->sasl_mechanism_list before processing the
+ extension list just like state->features.
+
+2002/05/15 == Released 0.8.10 ==
+
+2002/05/15
+ - Postfix 1.1.10 has been released. No changes.
+
+2002/05/14 == Released 0.8.9 ==
+
+2002/05/14
+ - Postfix 1.1.9 has been released. Patchkit requires a small adjustment
+ (supplied by Tuomo Soini ).
+
+2002/05/10 == Released 0.8.8 ==
+
+2002/05/10
+ - OpenSSL 0.9.6d has been released. Release the unchanged patchkit
+ with a new version number and under a new filename to indicate
+ that it should be built against 0.9.6d (it has the session caching
+ failure of 0.9.6c fixed). Update documentation accordingly.
+
+2002/05/05
+ - Postfix 1.1.8 has been released, the patchkit applies cleanly.
+
+2002/04/03 == Re-released 0.8.7 ==
+
+2002/04/03
+ - Postfix 1.1.7 has been released, the patchkit applies cleanly.
+ Re-released the patchkit.
+
+2002/03/29 == Released 0.8.7 ==
+
+2002/03/29
+ - Postfix/TLS did not honor the per-recipient-switching-off in SMTP
+ client mode via tls_per_site (per-host-switching off was honored).
+ Patch by Will Day .
+
+2002/03/27 == Released 0.8.6 ==
+
+2002/03/27
+ - Postfix 1.1.6 has been released. Adapted patchkit to resolve minor
+ patch conflict. (Template provided by Simon Matter
+ )
+
+2002/03/13 == Released 0.8.5 ==
+
+2002/03/13
+ - Postfix 1.1.5 has been released. The patchkit would apply cleanly, but
+ obviously the "lock_fd" change that applies to dict_dbm.c (Wietse)
+ also has to be applied to dict_sdbm.c. Tuomo Soini
+ kindly provided this change.
+
+2002/02/25 == Released 0.8.4 ==
+
+2002/02/25
+ - Postfix 1.1.4 became visible. One patch conflict in a Makefile
+ (Carsten Hoeger ).
+
+2002/02/21
+ - Dates in this CHANGES document were showing 2001 even though 2002 already
+ began :-). Fixed. (Marvin Solomon )
+
+2002/02/07
+ - Bug in the documentation (setup.html): the main.cf variables for the
+ SMTP server process have to be named smtpd_* instead of smtp_*.
+ Found by Andreas Piesk .
+
+2002/02/03 == Released 0.8.3 ==
+
+2002/02/03
+ - Patch from Andreas Piesk : remove some compiler warnings
+ by using explicit type casts in hexdump print statements.
+ - Re-released otherwise unchanged patchkit against Postfix-1.1.3.
+
+2002/01/30 == Released 0.8.2 ==
+
+2002/01/30
+ - Re-released unchanged patchkit against Postfix-1.1.2.
+
+2002/01/24 == Released 0.8.1 ==
+
+2002/01/24
+ - Postfix-1.1.1 has been released. The patchkit needed some small adjustment.
+ - Both Tuomo Soini and Carsten Hoeger
+ helped out with this small adjustment. As a side effect of Carsten's
+ complete pfixtls.diff, which I compared after applying Tuomo's adjustment,
+ I found that pfixtls.c contained several wrong "'" characters: on the
+ german keyboard there is an accent looking like the apostroph but producing
+ a different binary code. Obviously on Carsten's machine the code was
+ changed which became obvious during the comparison.
+ (Conclusion: I wrote the comments affected on my SuSE-Linux PC at home with
+ german keyboard. In my university-office I do have HP-UX workstations
+ with US keyboards.)
+
+2002/01/22 == Released 0.8.0 ==
+
+2002/01/22
+ - Received a comment from Wietse on the mailing list, that it is better
+ to resolve the "standalone" issue by using the already available
+ SMTPD_STAND_ALONE() macro in smtpd. Undid 0.7.16 change and made
+ new change in smtpd.c.
+ - Updated links in the References section of the documentation.
+
+2002/01/21 == Released 0.7.16 ==
+
+2002/01/21
+ - When calling "sendmail -bs" and STARTTLS is enabled, smtpd tries to
+ read the private key and fails due to insufficient permissions (smtpd
+ is run with the privileges of the user). This case is caught since
+ version 0.6.18 of the Postfix/TLS patchkit: STARTTLS is still being
+ offered but a "465 temporary failure" message is issued. Some mailers
+ (read this: PINE) will then refuse to continue. (And an irritating
+ error message indicating the failure to read the key will be logged.)
+ Experienced by "Lucky Green" .
+ - Solution: Disable STARTTLS when running "sendmail -bs" by adding
+ "-o smtpd_use_tls=no -o smtpd_enforce_tls=no" to smtpd's arguments
+ upon startup. Using STARTTLS does not make sense in simulated
+ SMTP mode.
+
+2002/01/18 == Released 0.7.15 ==
+
+2002/01/18
+ - Postfix 1.1.0 has been released. The patchkit for the former snapshot
+ version applied cleanly and now becomes the patchkit for the stable
+ version.
+
+2002/01/16 == Released 0.7.14a ==
+
+2002/01/16
+ - Snapshot-20020115 is released. Adapted patchkit.
+ - Add Postfix/TLS entries into the new conf/postfix-files
+ (Tuomo Soini , Carsten Hoeger ).
+
+2002/01/14
+ - OpenSSL: a user reported that session caching stopped working for him
+ with OpenSSL 0.9.6c. I found that this is also true for my own
+ Postfix/TLS installation.
+ Solution: server side session caching is broken in OpenSSL 0.9.6c when
+ using non-blocking semantics (Postfix/TLS is affected as it uses
+ BIO-pairs); sessions are simply not added to the cache. This bug
+ is not security relevant. A fix has been applied to the OpenSSL source
+ tree for the next release.
+
+2002/01/08 == Released 0.7.14 ==
+
+2002/01/07
+ - New snapshots released as release candidates. Adapted the patchkit
+ to snapshot-20020107. Moved our production servers from 20010228-pl08
+ to snapshot-20020107 with the adapted patchkit.
+ - Fix documentation: tlsmgr can be run chrooted since a long time.
+
+2001/12/21
+ - OpenSSL 0.9.6c is released. Postfix/TLS is fully compatible.
+
+2001/12/19 == Released 0.7.13e ==
+
+2001/12/19
+ - Adapted patchkit to snapshot-20011217.
+
+2001/12/12 == Released 0.7.13d ==
+
+2001/12/12
+ - Adapted patchkit to snapshot-20011210. Adaption provided by
+ Tuomo Soini .
+
+2001/11/28 == Released 0.7.13c ==
+
+2001/11/28
+ - Adapted patchkit to snapshot-20011127.
+
+2001/11/26 == Released 0.7.13b ==
+
+2001/11/26
+ - Adapted patchkit to snapshot-20011125.
+
+2001/11/22 == Released 0.7.13a ==
+
+2001/11/22
+ - Adapted patchkit to snapshot-20011121.
+
+2001/11/15 == Released 0.7.13 ==
+
+2001/11/15
+ - Adapted patchkit to postfix-20010228-pl08 and snapshot-20011115.
+
+2001/11/06 == Re-released 0.7.12 ==
+
+2001/11/06
+ - Snapshot-20011105 released. No patch conflicts, but in order to have
+ the pfixtls-* filename and home page entry reflect the new version,
+ I'll re-release 0.7.12.
+
+2001/11/05 == Released 0.7.12 ==
+
+2001/11/05
+ - Release of Postfix-20010228-pl06 and snapshot-20011104. The snapshot
+ version had some minor patch conflicts to be resolved.
+
+2001/10/14 == Released 0.7.11 ==
+
+2001/10/14
+ - Bug fix (client mode): when the peername is checked against the CommonName
+ in the certificate, the comparison does not correclty ignore the case
+ (the peername as returned by DNS query or set in the transport map
+ is not transformed to lower case). This bug was introduced in 0.7.5.
+
+2001/10/09 == Released 0.7.10 ==
+
+2001/10/09
+ - Snapshot-20011008 is released. Some minor adaptions are required to
+ sort out patch conflicts.
+
+2001/09/28
+ - Received patch from Uwe Ohse : There is a bug in sdbm's
+ handling of the .dir file, that also applies to Postfix/TLS.
+ The problem only appears for large databases.
+ - The example entries in conf/master.cf for the submission and smtps services
+ use "chroot=y" flags, while the Postfix default is "chroot=n". This could
+ lead to hardly explainable problems when users did not note this fact
+ during setup.
+ Fixed example entries to also use "chroot=n" default.
+
+2001/09/18
+ - Wietse releases Postfix-20010228-pl05. The patch applies cleanly with
+ "patch -p1 ...", so it is not necessary to release a new patchkit.
+
+2001/09/04 == Released 0.7.9 ==
+
+2001/09/04
+ - Due to unititialized variable in smtpd_state.c, AUTH may not be offered
+ without TLS even though smtpd_tls_auth_only was not enabled.
+ (Patch from Nick Simicich .)
+
+2001/08/29
+ - In the snapshot-20010808 version of 0.7.9, the "tlsmgr" line in the sample
+ conf/master.cf is missing (reported by Will Day ). Fixed.
+
+2001/08/27 == Released 0.7.8 ==
+
+2001/08/27
+ - Received bugreport about issuer_CN imprints consisting of long strings
+ of nonsense. This only appeard with certificates issued from a certain
+ CA (RSA Data Security Inc., Secure Server Certification Authority).
+ (Will Day )
+ - The problem: the issuer data of this certificate is:
+ Issuer
+ C=US
+ O=RSA Data Security, Inc.
+ OU=Secure Server Certification Authority
+ It does not contain a CN (CommonName) field. OpenSSL's
+ X509_NAME_get_text_by_NID() function does not catch this condition
+ (no error flag set), but it also does not set the name in the memory
+ location specified.
+ - Solution:
+ 1. Preset the memory for the string to '\0', so that a string of length
+ 0 is obtained on the failure described above.
+ 2. When no CN data is available, use the O (Organization) field
+ instead. The data are used for logging only (it is the issuer, not
+ the subject name), so this change does not affect functionality.
+
+2001/08/22 == Released 0.7.7 ==
+
+2001/08/22
+ - Found one more bug: erronously called SSL_get_ex_new_index() instead
+ of SSL_SESSION_get_ex_new_index() (note the _SESSION missing). This
+ could be responsible for the failure at the locations found during
+ debugging. Works fine on HP-UX (did also before), must cross check
+ at home...
+
+2001/08/21
+ - Received report, that smtp (client) fails with signal 11 (platform:
+ linux redhat). Cannot reproduce any problem on HP-UX (did run 1
+ week in production before release). But malloc() and stack strategies
+ are different between platforms.
+ - Can reproduce the failure on my Linux PC at home :-(.
+ - Found one bug in new_session_cb(): on successfull external caching,
+ success is reported by a return value of 1. This however must be another
+ bug, as it has nothing to do with the locations of the failure, when
+ analyzing the core dumps/running under debugger.
+ Still getting SIGSEGV...
+
+2001/08/20 == Released 0.7.6 ==
+
+2001/08/20
+ - Following "popular demand" implemented new feature and configuration option
+ "smtpd_tls_auth_only": Only allow authentication using the AUTH protocol,
+ when the TLS encryption layer is active. Default is "no" in order to
+ keep compatiblity to postfix without TLS patch.
+ This option does not distinguish between different AUTH mechanisms.
+
+2001/08/16 == Released 0.7.5 ==
+
+2001/08/15
+ - The new session cache handling is working now at my site for quite some
+ time.
+ - Client side: modified peername matching code, such that wildcard
+ certificates can be used. Matching is done as in HTTP/TLS: only the
+ leftmost part of the hostname may be replaced by a '*'.
+
+2001/08/09
+ - Further debugged the CRYPTO_set_ex_data() functionality.
+ - Unified "external cache write" and "external cache remove" callbacks
+ for client and server side. The "external cache read" functions are not
+ that easy to combine, as the lookup keys are quite different and do not
+ match the fixed interface to the callback function.
+ - Change shutdown behaviour according to SSL_shutdown(). When SSL_shutdown()
+ returns, the shutdown handshake may not be complete, if we were the first
+ party to send the shutdown alert. We must call SSL_shutdown() again,
+ to wait for the peer's alert.
+
+2001/08/08
+ - Postfix snapshot 20010808 is being released.
+
+2001/08/08
+ - Rewrite server side to remove externally cached sessions via callback.
+ - Rewrite client side to remove externally cached sessions via callback.
+ This turns out to be more difficult as expected, as the client side
+ session cache is sorted by hostnames, but the callbacks are called
+ with the SSL_SESSION objects. The information must be stored into the
+ SSL_SESSION objects by using the CRYPTO_set_ex_data() functionality,
+ the documentation of which, ahem, ...
+ - Reloading sessions stays separate, as the functionality is different.
+
+2001/08/07
+ - Started reworking the session cache code.
+ * On the server side the retrieval from the external cache and the writing
+ to the cache are handled by callback functions. The removal is handled
+ directly.
+ * On the client side, all session cache operations are performed explicitly.
+ * The explicit handling is on the client side is bad, as it requires a
+ quite complicated logic to detect session reuse and the appropriate
+ handling.
+ * The explicit handling of session removal on both sides is bad, as
+ the OpenSSL library will remove sessions (on session failure) according
+ to the TLS specifications automatically, so we want to take advantage
+ of this feature and have the externally cached sessions removed as
+ required via callback.
+ - First step: on the client side, also use the new_session_cb(), so that
+ new sessions are automatically saved to the external cache on creation.
+
+2001/08/01
+ - Postfix-20010228-pl04 is being released.
+
+2001/07/11 == Released 0.7.4 ==
+
+2001/07/10
+ - Postfix snapshot 20010709 was released. Resolved some minor patch
+ conflicts.
+
+2001/07/10
+ - OpenSSL 0.9.6b has been released including a security fix for the
+ libraries internal pseudo random number generator.
+ * Note: to exploit the weakness, an attacker must be able to retrieve
+ single random bytes. As in Postfix/TLS random bytes are only used
+ indirectly during the SSL handshake, an attacker could never access
+ the PRNG in the way required to exploit the weakness.
+ * Postfix/TLS is therefore not vulnerable (as are most (all?) applications
+ utilizing the SSL layer).
+ * The OpenSSL team however recommends to upgrade or install the bugfix
+ included in the announcement in any case.
+ * Details can be found at http://www.openssl.org/
+
+2001/05/31 == Released 0.7.3a ==
+
+2001/05/30
+ - Report from : TLS logging does not work.
+ Reason: parameters are not evaluated in mail_params.c, as the corresponding
+ lines for other_int_defaults[] were missing from the patch. This
+ only affected the 0.7.3-snapshot version, the version for "stable"
+ is correct.
+ I will release 0.7.3a with this fix only for the snapshot version to keep
+ version numbering consistent with the "stable" version.
+
+2001/05/28 == Released 0.7.3 ==
+
+2001/05/28
+ - Upgraded to snapshot-20010425: resolved some minor patch conflicts.
+ No functional changes.
+
+2001/05/16
+ - Received french documentation (doc_french/) contributed by
+ Etienne Roulland .
+
+2001/05/03 == Released 0.7.2 ==
+
+2001/05/03
+ - Postfix-Snapshot 20010502 is released. Bernhard Rosenkraenzer
+ supplies an adapted patch for Postfix/TLS, as the
+ normal patch has several rejections because of code changes;
+ functionality has not changed.
+
+2001/05/01
+ - Patchlevel 02 of Postfix 20010228 is being released. The Postfix/TLS
+ patchkit applies cleanly when using the "-p1" switch to patch.
+
+2001/04/09 == Released 0.7.1 ==
+
+2001/04/06
+ - OpenSSL 0.9.6a is released. It contains several bugfixes and will become
+ the recommended version to be used with Postfix/TLS.
+ I will run some more test and then re-release Postfix/TLS (without
+ additional changes to the source) as 0.7.1 to make people aware of the
+ new versions of Postfix and OpenSSL.
+
+2001/04/05
+ - Hint from Bodo Moeller :
+ the "Known Bugs" section in doc/test.html actually contains bugs
+ of clients and/or interoperatbility problems. Better name it
+ "Known interoperability problems" and rename the entries
+ "Postfix/TLS server" and "Postfix/TLS client" to improve clarity.
+
+2001/03/29
+ - Patchlevel 01 of Postfix 20010228 is being released. The Postfix/TLS
+ patchkit applies cleanly when using the "-p1" switch to patch.
+ OpenSSL 0.9.6a will be out within the next handful of days, so I will
+ delay the release of a new patchlevel until then.
+
+2001/03/01 == Released 0.7.0 ==
+ - IMPORTANT: If you are upgrading from a much older version, you will find
+ that some configuration options have changed over time (fingerprints are
+ now handled with ':'. check_relay_ccerts is now permit_tls_clientcerts.
+ Session caching has been reworked.)
+ It is recommended to re-read the sample-tls.cf file or the html version
+ in the documentation.
+
+2001/03/01
+ - Wietse has announced the _release_ version (non-beta) or postfix:
+ 20010228!
+ - Applied the Patchkit to the _release_ version (not the snapshot version).
+ Resolved one minor patch conflict.
+ - So, it's time to call this Postfix/TLS 0.7.0.
+
+2001/02/26 == Released 0.6.38 ==
+
+2001/02/26
+ - Snapshot-20010225 has been released. Resolved one minor patch conflict.
+
+2001/02/23 == Released 0.6.37 ==
+
+2001/02/23
+ - Snapshot-20010222 has been announced as RELEASE CANDIDAT. Resolved one
+ minor patch conflict.
+ - Removed "check_relay_ccerts" restriction which has been replaced
+ by "permit_tls_clientcerts" in 0.6.24. (Was left in until now for
+ transition.)
+ - Do not try to save session data > 8kB, since this cannot be handled
+ by SDBM. (This is more or less academical, since I have never met a
+ session even half that large.)
+
+2001/02/19 == Released 0.6.36 ==
+
+2001/02/05
+ - Snapshot-20010204 has been released. Resolved one minor patch conflict.
+
+2001/02/03 == Released 0.6.35 ==
+
+2001/02/03
+ - Snapshot-20010202 has been released. Resolved one minor patch conflict.
+
+2001/01/29 == Released 0.6.34 ==
+
+2001/01/29
+ - Snapshot-20010128 has been released. Resolved some minor patch conflicts.
+
+2001/01/11 == Released 0.6.33 ==
+
+2001/01/10
+ - Discussion in Thread "When to get peer certificate?" continues and it
+ comes out, that cross references between datastructures are well maintained
+ inside OpenSSL. A fact not well known due to lack of documentation
+ (seems I am facing some more work on the OpenSSL manpages :-).
+ - Moved around data needed for the certificate verification: a lot of
+ "static" entries globally needed inside pfixtls.c could now be moved
+ into the connection specific TLScontext.
+
+2001/01/07 == Released 0.6.32 ==
+
+2001/01/07
+ - Since now the checks at handshake stage (in pfixtls.c) are more strict,
+ some of the checks in smptd.c and smtp_proto.c could be removed.
+ At a later point I can probably move even more checks into pfixtls.c...
+
+2001/01/05
+ - Had a discussion with Ari Pirinen on openssl-users
+ (Thread: When to get peer certificate?) about the earliest possible
+ place to check the CommonName of the peer against the expected name.
+ (This is what smtp does when enforcing the peername of the server it
+ is connecting to.)
+ The final result was, that the check can already been done inside the
+ verifiy_callback() routine even before the handshake is completed.
+ The positive side effect is, that since the session is never completly
+ established, it is also not cached on either client or server.
+ - Since this is a good idea, I have extended the verify_callback in
+ src/global/pfixtls.c to check the CommonName of the peer (if applicable)
+ and have the handshake shut down immediatly on failure. I have also
+ changed the behaviour so that whenever a positive certificate verification
+ is required, the handshake is shut down immediatly.
+ (The versions up to now did delay these checks until the session was
+ established and then shut down the connection. I had established this
+ practice while working on BIO-pairs and running into a bug in
+ OpenSSL 0.9.5 (fixed now) and with the verify depth.)
+
+2000/12/23 == Released 0.6.31 ==
+
+2000/12/23
+ - Bug: When only enabling smtpd_tls_wrappermode and not additionally setting
+ smtpd_use_tls or smtpd_enforce_tls, the TLS engine was not fired up on
+ startup of smtpd
+ Fixed: also start TLS engine when only smtpd_tls_wrappermode is enabled.
+ (Experienced by "Fiamingo, Frank" )
+
+2000/12/18 == Released 0.6.30 ==
+
+2000/12/18
+ - New snapshot 20001217 has been released. Due to the change of "timeout"
+ parameters now being its own class and table, the old patchkit does not
+ apply cleanly!
+ - Checked out Postfix/TLS parameters being timeout values and put them into
+ the new style time parameter table. This allows to specify time values
+ like 3600s or 1h. Updated sample configuration to reflect this new style.
+ - "Fiamingo, Frank" pointed out to me, that there are
+ three parameters in src/global/mail_params.h (namely DEF_TLS_RAND_EXCH_NAME,
+ DEF_SMTPD_TLS_CERT_FILE, DEF_SMTPD_TLS_CA_FILE) that are hardcoded as
+ "/etc/postfix/something".
+ This does not match the usual style of postfix, where no paths are
+ hardcoded this way. I have removed the defaults for CERT_FILE and CA_FILE.
+ The RAND_EXCH is needed for good PRNG seeding on systems without
+ /dev/urandom, I however don't know yet, how to rearrange this requirement.
+ I could use the Postfix internal mechanisms to enforce a parameter, but
+ this would annoy people having compiled in TLS but not activated.
+
+2000/12/13 == Released 0.6.29 ==
+
+2000/12/13
+ - Snapshot-20001212 has been released.
+ - Undid bugfixes for 20001210 which now are included in the new snapshot.
+
+2000/12/12 == Released 0.6.28 ==
+
+2000/12/12
+ - Added bugfix provided by Wietse on postfix-users@postfix.org for
+ "postconf -m" behaviour.
+
+2000/12/11
+ - New snapshot-20001210 released. Some patch conflicts occur. Additionally
+ * adjusted calls to myflock() to changed interface,
+ * fixed bug in smtpd_sasl_glue(), where a change to the name_mask()
+ call was not applied in the original snapshot.
+
+2000/12/05 == Released 0.6.27 ==
+
+2000/12/04
+ - Print informational message "SSL session removed" only when
+ var_smtp[d]_loglevel >= 2. (Proposed by Craig Sanders .)
+ - Extend logging of "setting up TLS connection from/to" and corresponding
+ success/failure messages so that they include the hostname/ip address.
+ This way it is much easier to automatically analyze errors by simply
+ grepping for e.g. "SSL_accept error" and immediately get the peer
+ causing the problem without further logfile processing.
+ (Proposed by Craig Sanders .)
+ - When experiencing a TLS failure due to TLS-enforced failure in client mode
+ (no certificate or hostname/certificate mismatch etc), immediately shut
+ down the TLS mode with "failure" indication, so that the SSL session is
+ removed immediately. This way a new session is always enforced in the
+ case the peer has fixed the problem; no need to wait for the timeout.
+
+2000/11/29 == Released 0.6.26 ==
+
+2000/11/29
+ - Found security relevant bug in the OpenSSL library: the verify_result
+ stating whether or not the certificate verification succeeded is not
+ stored in the session data to be cached and reused.
+ - This bug was found during the development of Postfix/TLS around one
+ year ago, the bug in the library was however only fixed for the server
+ side. At that time I also tested the server side behaviour but ommitted
+ to check the client side, too.
+ - Versions before Postfix/TLS 0.4.4 experienced this problem for both
+ server and client side. Before 0.6.0 a workaround was active for both
+ sides, which has been removed at 0.6.0 in the believe that the bug
+ was gone (I only tested the server side, which was fixed).
+ - Fixed that bug in OpenSSL also for the client side (I can do this myelf
+ now that I have been invited to join the OpenSSL developers team :-).
+ The fix is availabe as of today and will be part of the 0.9.7 release
+ of OpenSSL (or 0.9.6a, if this release will be published).
+ - Included a workaround inside Postfix/TLS for OpenSSL library versions
+ before 0.9.6a or 0.9.7, respectively.
+
+********************** Begin Description
+
+ - By not caching the verify_result for the client side, the following
+ behaviour could appear:
+ * The problem can only appear when smtp_tls_session_cache_database
+ is activated.
+ * smtp_use_tls = yes
+ X On the first connection, the certificate fails verification, failure
+ is logged:
+ smtp[*]: Unverified: subject_CN=serv01.aet.tu-cottbus.de, issuer_CN=BTU-CA
+ For any following connections until the session times out (default 1 hour),
+ the peer certificate seems to pass verification:
+ smtp[*]: Verified: subject_CN=serv01.aet.tu-cottbus.de, issuer_CN=BTU-CA
+ X Security Impact:
+ Unverified certificates are logged as if verification had succeeded.
+ * smtp_enforce_tls = yes
+ X After the verification failure, the session is never correctly established
+ and hence not reused.
+ X Security impact:
+ None, as the session is never reused.
+ * smtp_enforce_tls = yes after smtp_tls_enforce_tls = yes for a server.
+ X If the session has been recorded with use_tls and then for this server
+ enforce_tls is set, the wrong verify_result could be used within the
+ session cache timeout (default = 1 hour).
+ X Security impact:
+ If TLS shall be enforced for a recipient, there is a window of approx.
+ one hour from setting the "enforce_tls" switch until a verification
+ failure is noted. For this to happen, a TLS session to that server must
+ have been used with use_tls set and the not-verifiable certificate must
+ have been recorded in that session.
+ - Evaluation:
+ Even though this _is_ a security problem, I consider risk to be *low*,
+ given the conditions under which the problem might occur.
+
+********************** End Description
+
+2000/11/27 == Released 0.6.25 ==
+
+2000/11/26
+ - Added "permit_tls_all_clientcerts" for smtpd_recipient_restrictions.
+ When this option is enabled, any valid client certificate allows relaying.
+ This can be practical, if e.g. a company has a special CA to create
+ these certificates and only this CA is "trusted". It however does not
+ allow finer control, so if e.g. an employee leaves, he could still
+ relay. Postfix/TLS does not (yet) allow CRL (certificate revocation lists).
+ (Added on popular demand.)
+ - Make the client behaviour more configurabe: when enforcing TLS connections,
+ the peer's name is checked against the CommonName in its certificate.
+ New configuration variable "smtp_tls_enforce_peername" (default=yes)
+ can now be used to accept peername!=CommonName. The server's certificate
+ must still pass the verifcation process against a trusted CA!
+ In tls_per_site, the according key is MUST_NOPEERMATCH.
+ (Added on demand.)
+
+2000/11/24
+ - If the server requires a client certificate and no certificate is presented
+ or the certificate fails verification, the connection is shut down but
+ no information is logged.
+ -> add according msg_info() in smtpd/smtpd.c:startls_cmd().
+ - If TLS is not enforced, it does not make sense for a server to require a
+ client certificate. If no STARTTLS is issued, the SMTP would continue
+ anyway, so why shut down when TLS is activated without verifyable client
+ certificate?
+ -> ignore smtpd_tls_req_ccert=yes, if TLS is not enforced and only treat
+ like smtpd_tls_ask_ccert = yes with an according information logged.
+
+2000/11/22 == Released 0.6.24 ==
+
+2000/11/22
+ - Installed on my own servers and changed configuration to use the new
+ "permit_tls_clientcerts" option name. Patchkit will be released after
+ some hours of successfull operation.
+
+2000/11/21
+ - New snapshot-20001121 is being released. The patch applies without any
+ conflict when applied with "patch -p1", so no need to rush out an updated
+ patchkit.
+ - Rename the smtpd_recipient_restrictions option from "check_relay_ccerts"
+ to "permit_tls_clientcerts" to better match the naming scheme.
+ Leave in the old option for now to not break existing configurations.
+ The final incompatible removing is scheduled of release 0.7.0 of the
+ patchkit which will be matching the next "stable" release of postfix.
+ - There is no manual page for tlsmgr.8 (pointed out by Terje Elde
+ ).
+ Fix the comments at the beginning of tlsmgr.c and create tlsmgr.8.
+ - In the session cache code an additional 20 bytes were allocated when
+ converting SSL_SESSION data to binary using i2d_SSL_SESSION().
+ In adding these 20 bytes to the size listed by i2d_SSL_SESSION() I followed
+ the example in the OpenSSL source (PEM_ASN1_write()). These 20 bytes are
+ only added since when writing the PEM, a 20 byte checksum is added, so
+ we don't need it in our case -> removed.
+ (Researched after Carlos Vicente asked what these
+ 20 bytes are good for :-)
+
+2000/10/30 == Re-Released 0.6.23 ==
+
+2000/10/30
+ - Postfix snapshot-20001030 with an important bug fix is made available.
+ The patchkit applies without any problem (patch -p1).
+ Hence, I re-release the 0.66.23 release for the new snapshot.
+
+2000/10/30 == Released 0.6.23 ==
+
+2000/10/30
+ - New Postfix snapshot 20001029 available with some important bug fix.
+ Adjusted patchkit (only minor conflicts).
+
+2000/10/27
+ - The CN_sanitize function (src/smtpd/smtpd.c) that shall make sure that
+ no illegal sign is included into the Received: header does not work
+ on systems were "char" is unsigned by default.
+ (Linux on s390, found by Carsten Hoeger )
+ -> Worked out a more precise (even though not looking elegant) solution
+ that checks out all acceptable characters.
+ - Sent new smptd.c to Carsten Hoeger for testing, will wait with new
+ Postfix/TLS release.
+
+2000/10/06 == Released 0.6.22 ==
+
+2000/10/06
+ - snapshot-20001005 has been released, featuring fast ETRN. Only some minor
+ patch conflicts needed to be resolved.
+
+2000/09/28 == Released 0.6.21 ==
+
+2000/09/28
+ - snapshot-20000924 seems to be somewhat longer lasting. I have been asked
+ for a new Postfix/TLS release against snapshot-20000924, hence I will
+ create one.
+ - Running OpenSSL 0.9.6 for a week now to my full satisfaction. I will bump
+ bump up the Postfix/TLS version counting to include "0.9.6", even though
+ it will still run fine with 0.9.5a.
+
+2000/09/25/
+ - snapshot-20000924 is available; only small adjustments.
+ - Wietse seems to release new snaphots on a daily basis, it doesn't make
+ sense to follow with a new Postfix/TLS release every day.
+
+2000/09/23 == Released 0.6.20 ==
+
+2000/09/23
+ - Recompile OpenSSL-0.9.6-beta3 with the change and reinstall old pfixtls.c:
+ works again. Hence, all versions of Postfix/TLS working against 0.9.5a
+ will also work again 0.9.6-final, which shall be released on 2000/09/24!
+ - Wietse releases snapshot-20000923, patchkit adapted.
+ - Went through the "install.html" document to add a remark about
+ OpenSSL-0.9.6. This document is of historic quality but did not fit
+ actual versions of Postfix/TLS, we are far beyond OpenSSL 0.9.2: Updated.
+
+2000/09/22
+ - Wietse releases snapshot-20000922. The source directory hierarchie has
+ changed, so the patch needs to be adjusted at several places.
+ - Run tests against OpenSSL 0.9.6-beta3: problems occur!
+ * Certificates are no longer verified, since an informationa flag about the
+ CA certificate search process is written into the error storage and
+ thus misinterpreted as verification failure.
+ * Changed Postfix/TLS source to maintain its own error storage based on
+ the verify_callback, send out according warning to Postfix/TLS mailing
+ list.
+ * Unfortunately, this will break all older versions of Postfix/TLS.
+ Sent out analysis to OpenSSL-bugs@openssl.org.
+ * Additional change is made to OpenSSL: the new behaviour is only activated
+ when a special flag is set, so compatibility is restored!
+
+2000/09/21
+ - Wietse releases snapshot-20000921. Some minor patch conflicts resolved.
+
+2000/09/14 == Released 0.6.19 ==
+
+2000/09/14
+ - Received a bug report: Postfix/TLS will accept a mail even though
+ smtpd_req_ccert=yes (require use of client certificate) and no
+ client certificate is presented.
+ Reason: when no client certificate is presented SSL_get_verify_result()
+ will return X509_V_OK, since this is the default value.
+ Solution: only set "peer_verified" internal information, if the
+ verify_result is X509_V_OK _and_ a peer certificate is available.
+ Remark: This default value does not make too much sense. I will file
+ a bug report/patch before the next release of OpenSSL...
+
+2000/09/03 == Released 0.6.18 ==
+
+2000/09/03
+ - When calling "sendmail -bs", smtpd is started without root privileges,
+ hence it cannot open the private key file and the session cache database.
+ Since the database routines do not offer a graceful return (only fatal
+ and abort), this leads to a failure when TLS and session caching is
+ activated.
+ This affects PINE users (noted by Craig Sanders ).
+ Solution: Try to read the private key first; if that fails, we can
+ gracefully recover and won't touch the session cache database at all.
+ - When STARTTLS is configured for smtpd but does not work (e.g. because of
+ unaccessible keys), smtpd answers with "465 TLS not available due to
+ temporary reasons". After that the connection was closed, this is however
+ not necessary, as the client may decide to continue without TLS activated.
+ - Craig Sanders contributes a script to automatically
+ generate the keys and certificates for Postfix/TLS usage. Added
+ "make-postfix-cert.sh" to the contributed/ directory.
+
+2000/09/02 == Released 0.6.17 ==
+
+2000/09/02
+ - Craig Sanders reports that he has connection problems
+ with a site; the message in the log is:
+ SSL_connect error 0
+ 8847:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message:s3_pkt.c:956:SSL alert number 10:
+ * This is the error caused by the faulty TLS implementation with
+ CommunigatePro. The bug is fixed in later versions of CommunigatePro,
+ The site shall be contacted, they should update.
+ - More important, he reports a segmentation fault immediately after this
+ problem.
+ - Bug: when not using session caching and an error occurs during the TLS
+ handshake, pfixtls_start_clienttls() tried to remove the erronous
+ session from a non-existant session cache.
+ Fix: check the existence of the session cache before trying to access it.
+ Comment: at all other places in the code this condition was already
+ caught.
+ - Remark: actually session caching was configured, but the configuration
+ variable was mistyped because...
+ it was wrong in conf/sample-tls.cf and doc/conf.html.
+ The correct values are "smtp[d]_tls_session_cache_database" instead of
+ "smtp[d]_tls_use_session_cache_database".
+ Unfortunately this is not flagged by Postfix...
+
+2000/08/25 == Released 0.6.16 ==
+
+2000/08/25
+ - Make sure, that the smtp[d] processes will try to access the "daemon"
+ entropy sources, but will only print an info when not available. Using
+ the PRNG-exchange file, they can happily run without.
+ - Moved HAS_SSL checks, such that the package compiles also when configured
+ without -DHAS_SSL.
+
+2000/08/24
+ - Changed the handling of the PRNG-exchange file. Until now it was written
+ by tlsmgr and read by the smtp[d] daemons. This had the disadvantage, that
+ until tlsmgr rewrote new bytes to the file, all starting daemons read the
+ same seed (to which some more bits, but not too much were added).
+ - Now the file is handled in read->stir into pool->write back mode, so that
+ every daemon will add its own entropy bits.
+ - The smtp[d] processes will do so when starting, when opening a TLS
+ connection and when closing.
+ - The tlsmgr will also read back the file and add it to its pool, so that
+ no entropy is lost.
+ - This change significantly increases the "self seeding" capability of
+ the TLS service.
+
+2000/08/09
+ - Cleaned up the new PRNG-seeding.
+ - When tlsmgr looses connection to an EGD-source (because it was restarted),
+ tlsmgr performes an exit(0), so that a newly started tlsmgr can reconnect.
+ [chroot/dropped privileges].
+
+2000/08/04
+ - Introduced new entropy sources for single daemons:
+ * tls_daemon_random_source
+ Using this source (same style as for tlsmgr), each starting daemon can
+ obtain additional entropy (32 bytes by default). The PRNG-exchange file
+ is still read.
+ - I am not sure about the policy for this feature. If such a source is
+ given, should a failure be considered fatal?
+
+2000/07/23
+ - Started reworking the PRNG seeding:
+ * tlsmgr now recognizes tls_random_source as
+ dev:/dev/urandom /* Direct read from device file */
+ egd:/path/to/socket /* Connection via EGD-socket */
+ /path/of/plain-file
+ * If a dev: or egd: is given, tlsmgr will connect and keep the connection
+ open, so that it now can run in chroot-mode with dropped privileges.
+ - Since EGD can be drained, but the connection is permanently open, only
+ suck a small number of bytes (default 32) at a time, but do it more
+ often.
+
+2000/08/09 == Released 0.6.15 ==
+
+2000/08/09
+ - Traced through OpenSSL to learn more about the verify_callback-feature.
+ The callback is called several times. When it returns "1", the handshake
+ will continue, when it calls "0", the handshake will immediately fail
+ (and Postfix/TLS will also close the TCP connection).
+ - Following the sample in the OpenSSL-apps, the verification chain depth
+ was the only property triggering this effect, so this stood hidden until
+ now. Obviously, users having longer chains did set the verifcation
+ depth accordingly or they gave up, since this was never reported...
+ - Changed the behaviour of verify_callback() to never return "0", such that
+ we can deal with the verification result later in a more consistent manner.
+ If we only enable and not enforce, we simply want to ignore problems with
+ the certificate.
+ - verify_callback() did not print out all information, since the wrong
+ state variables (pfixtls_*active instead of pfixtls_*engine) were
+ checked. The *active state variables are only set later.
+ As the verify process now became rather narrative, the normal logging
+ is only done in loglevel 2!
+ - Arrrghhh. The conf/sample-tls.cf _and_ the html-docu (which is actually
+ copied from conf/sample-tls.cf) has wrong names for the verification-
+ depth parameters. *_vd instead of *_verifydepth and ccert<->scert.
+ [Wondering, why this never popped up before...]
+ - Changed the default-verifydepth to "5" which should suffice for most
+ cases. Maybe the limit could also be completely removed, but we should
+ at least receive a warning hint when something goes wild.
+ Since OpenSSL>=0.9.5 is required for Postfix/TLS anyway, certificate chain
+ verification can now be used, so the caution applied before is no longer
+ necessary.
+
+2000/08/08
+ - Tracked down the double-free() call in smtp with Efence. SSL_free()
+ does call SSL_SESSION_free() on the negotiated session. Hence, I must
+ not call SSL_SESSION_free() on the session in question, it will be
+ removed anyway.
+ - Also tracked down the certificate chain feature. Reason is the
+ verify_callback() in global/pfixtls.c. It flags a chain depth that
+ is too long as fatal, hence the connection is immediately closed.
+
+2000/08/04
+ - Received information from Alain Thivillon :
+ FreeBSD-CURRENT offers malloc() with additional checks enabled.
+ After successfully delivering, smtp dumps core with free() called
+ twice in TLS mode.
+ - I noted, that there is a communication problem with his site an my new
+ certificate issued by the universities computer center (which has a chain
+ depth of 2). Step back to the old self certificate for the time being.
+
+2000/07/27 == Released 0.6.14 ==
+
+2000/07/27
+ - Introduced new configuration parameter "smtpd_tls_wrappermode" that
+ enables the (deprecated) old style SSL-wrapping around SMTP. It could
+ be run on a different port (once smtps=465) was recommended for this
+ services.
+ This method is used by old versions of Outlook (Express), the Mac versions
+ and even actual versions, when not run on port 25.
+ [Actually it was only a handful of lines, so it doesn't hurt too much,
+ even though it does not follow any RFC.]
+ - I recommend using this option only from master.cf. Example lines added
+ to conf/master.cf and description added to Postfix/TLS-doc/conf.html.
+ - When having SASL enabled and TLS-enforce mode in "smtpd", only offer
+ AUTH, when TLS has been activated. Otherwise the client might simply
+ send the unencrypted credentials before it receives
+ 530 Must issue a STARTTLS command first
+ and an eavesdropper already has what he was looking for.
+
+2000/07/19 == Released 0.6.13 ==
+
+2000/07/19
+ - Changed the library-initializaton call to new naming scheme
+ (SSLeay_add_ssl_algorithms() to OpenSSL_add_ssl_algorithms() :-).
+ - Updated documentation to reflect the use of chain certificates with
+ CAfile and smtp[d]_tls_cert_file (see 2000/07/06).
+ - Documentation: the interoperability problem with CommunigatePro has been
+ solved: CommunigatePro violated the TLS-RFC and has been fixed.
+ - Typo: It is "to stir" not "to stirl" :-)
+
+2000/07/06
+ - Received certificate for our site from our computer center. It's a chain
+ certificate. Now load the cert with SSL_CTX_use_certificate_chain_file(),
+ in order to better load the chain CA certificates.
+
+2000/07/04
+ - Reported Wietse about a possible problem in the SASL code, a relay check
+ may also be performed if sasl was not enabled and might lead to unwanted
+ relay.
+ As the fix is in my own codebase, I will leave it Postfix/TLS until a
+ new snapshot (or final release) is available.
+
+2000/06/02 == Released 0.6.12 ==
+
+2000/06/02
+ - Adapted to Snapshot-20000531 (minor patch conflict).
+ - Cleaned up some old header file dependencies in global/pfixtls.c and
+ global/Makefile.in that are no longer needed due to the interface changes
+ (timed_read()/write()) in 0.6.7.
+
+2000/05/29 == Released 0.6.11 ==
+
+2000/05/29
+ - Following Bodo Moeller's analysis, the error is due to a mismatch between
+ the CA certificate accessible in the smtp[d]_tls_CAfile and the one used
+ in the actual certificate (smtp[d]_tls_cert_file).
+ Daniel Miller fixed his setup and the problem is gone.
+ - Introduced a workaround into Postfix/TLS: if the padding error is found,
+ it is removed from the error-queue by Postfix/TLS, in order to protect
+ more sites from experiencing this problem.
+ - Added a warning to conf/sample-tls.cf
+ - Updated to the latest snapshot-20000528.
+
+2000/05/27
+ - After some fiddling around working through the binary certificate data to
+ see where it is modified at 0.6.10, I actually note, that both 0.6.9 and
+ 0.6.10 choke on the data. Now going back up through the functions very
+ fast reveals the problem:
+ * The certificate supplied triggers the "RSA-padding" error in any case.
+ Since the certificate authencity is not enforced on OpenSSL-library level
+ but inside postfix later, the error is not enforced.
+ The error messages generated stay however in the error queue.
+ - For blocking sockets, the SSL_accept()/connect() calls return
+ "success", so the error-queue is never checked.
+ - With BIO-pairs, the error queue is checked to find out, whether the
+ function has just to be called again to continue the handshake, so
+ the error messages are found and the connection is shut down due to
+ the error condition.
+ - Submitted bug report to Bodo Moeller. Bug fix is checked into the OpenSSL
+ CVS archive: if the error is ignored during the handshake, clear the
+ error-queue.
+ * The next release of OpenSSL will behave consistently.
+ - This leaves open the question, why the RSA-padding error is issued in the
+ first place. Sent a query to the OpenSSL-* mailing lists.
+
+2000/05/26
+ - A second site experiencing this problem pops up.
+ -> Issued a warning to the postfix_tls mailing list.
+
+2000/05/24
+ - Contacted Damien Miller . He did not change his TLS setup
+ in the last time. He is running Postfix/TLS-0.6.6.
+ - Contacted Bodo Moeller , the author
+ of the BIO-pair part of OpenSSL for some debugging hints. Received several
+ worthful remarks on what to look for.
+ - Checked byte-for-byte the data fed into the OpenSSL-library. It does not
+ differ between 0.6.9 and 0.6.10, so my handling seems to be actually
+ correct.
+
+2000/05/23
+ - A communication error occurs when talking to mail.mindrot.org:
+ SSL_accept error -1
+ 10264:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100:
+ 10264:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:396:
+ 10264:error:0D079006:asn1 encoding routines:ASN1_verify:bad get asn1 object call:a_verify.c:109:
+ - The error occurs both in client and server mode. 0.6.9 does not show
+ this problem.
+ - Tried to connect with several other sites, all connections are fine,
+ this includes sendmail and qmail peers; hence decided to not recall 0.6.10.
+
+2000/05/23 == Released 0.6.10 ==
+
+2000/05/23
+ - Sent a note to openssl-dev@openssl.org about the behaviour of SSL_free()
+ and BIO_free(), hoping for some clarification whether my way of doing
+ it is the recommended way.
+ - Run the software in production mode on my own servers...
+ - Finished writing the in-source documentation.
+ - Updated sample-tls.cf and sample-smtp[d].cf to reflect the new timeout
+ parameters.
+
+2000/05/21
+ - Removed error messages produced by the now non-blocking behaviour of the
+ TLS layer [apps_ssl_info_callback()].
+
+2000/05/20
+ - Took results home and tried to run it on my Linux-box: SEGV after
+ successfully handling the SMTP session!!
+ * It seems that the SSL_free() and BIO_free() functions interact.
+ SSL_free() releases the underlying BIO and it will bomb out when
+ it is then explicitely BIO_free()'ed again and vice versa.
+ * It did not bomb out on HP-UX, but such things happen. I however want to
+ know, why the example program does not fail...
+ * With respect to the bevaviour as is, SSL_free(TLScontext->con);
+ BIO_free(TLScontext->network_bio) and not touching
+ TLScontext->internal_bio works.
+ - Introduced special timeout values for the TLS negotiation stage, as the
+ timeout values may change with protocol state (suggested by Wietse).
+ - Started writing a full description of the BIO-pair concept and its
+ special treatment into the pfixtls.c sourcecode.
+
+2000/05/19
+ - Systematicly implemented a generalized layer handling:
+ * do_tls_operation() is the generic handler for all SSL_*() input/output
+ functions. It deals with the non-blocking behaviour of this functions,
+ requiring appropriate retrys.
+ * network_biopair_interop() handles the interaction between the socket/fd
+ and the buffering BIO-pair.
+
+2000/05/18
+ - Based on the example in openssl-0.9.5a/ssl/ssltest.c realized the first
+ usage of BIO-pairs. (Can do server handshaking.)
+ - Learned, that the BIO-pair has its own buffering that needs its own
+ flushing. It is not enough to relay on the SSL_ERROR_WANT_READ/WRITE
+ state information.
+
+2000/05/17 == Released 0.6.9 ==
+ - Important: the seperator in the relay-fingerprints is now ':'!!!
+ Don't forget to change your relay_clientcerts databases.
+
+2000/05/16
+ - Changed pfixtls.c to only use the interface described in util/vstream.c
+ for handling the VSTREAM.
+ * Added vstream_context() macro to the VSTREAM-interface.
+ - Introduce TLScontext to identify the connection instead of the file
+ descriptor. Move all static data (SSL structure and information gathered
+ about the connection) into the context.
+ The TLScontext is allocated on TLS-start for a connection and saved with
+ the VSTREAM, so several streams can be used at the same time.
+ - Removed "pfixtls_setfd()" as it is no longer needed.
+ - Changed the relay_clientcerts list from string_list_* to maps_* interface
+ to allow usage of ":" in the list.
+ THIS IS AN INCOMPATIBLE CHANGE!!!!
+ - Updated documentation accordingly.
+
+2000/05/12 == Re-released 0.6.8 ==
+
+2000/05/12
+ - Wietse announces snapshot-20000511 with an important bugfix.
+ - Since upgrading from 20000507 to 20000511 is highly recommended,
+ Postfix/TLS 0.6.8 is re-released for this snapshot (the patch applied
+ cleanly, just the name of the toplevel directory has changed).
+
+2000/05/11 == Released 0.6.8 ==
+
+2000/05/11
+ - Unlike expected I found some time to install the latest cyrus-sasl-1.5.21
+ and test some parts the integration. It does, well, work as advertised
+ (and the advertisement in SASL_README is not too optimistic).
+ - When checking all of the rejected patch-snippets for 0.6.6->0.6.7
+ I missed the parameter "smtpd_enforce_tls" (noted since I wanted to
+ enforce TLS encryption while playing around with plaintext passwords)
+ in the static CONFIG_BOOL_TABLE bool_table[] = {..} in smtpd/smtpd.c
+ -> I will immediately release a corrected version 0.6.8.
+
+2000/05/11 == Released 0.6.7 ==
+
+2000/05/11
+ - The latest sendmail.8.11.0.Beta1 includes STARTTLS support; it is available
+ in source code and also uses OpenSSL.
+
+2000/05/10
+ - After having it running at home (Linux) I also install it at work for
+ the field test.
+ - No time to install the SASL kit, so this part stays untested as of now.
+
+2000/05/09
+ - Downloaded snaphot and apply the patchkit.
+ - Straightened out the rejected parts of the patch.
+ - Due to the new layering with timed_read() and timed_write() functions
+ the integration of the TLS layer needed special adjustment.
+ * When TLS is active, the timed_read() and timed_write() functions are
+ replaced by the corresponding pfixtls_timed_read() and
+ pfixtls_timed_write() functions. When the TLS functionality is stopped,
+ the old functions are restored.
+ * The names of the pfixtls_timed_*() functions are looking into the future,
+ because they are working as before, the timeout functionality is not
+ in, yet.
+
+2000/05/08
+ - Wietse announces snapshot-20000507 with a lot of changes. Especially
+ important: the I/O handling of the smtp-stream has been changed to
+ a more layered technique that allows easier integration of the TLS layer.
+
+2000/04/27 == Released 0.6.6 ==
+
+2000/04/27
+ - Fixed inconsistency between documentation and actual behaviour: peer
+ certificate information was not logged at level 1 (found by
+ Damien Miller ).
+ * While at it: the logged information did not say whether the certificate
+ data logged passed verification or not: fixed. (The information logged
+ in the Received: header already contained that information.)
+ - Backported dict_dbm.c from snapshot-20000309 with the updated
+ dict_delete() behaviour (key not found is not considered fatal).
+ Maintained dict_sdbm.c accordingly.
+
+2000/04/18 == Released 0.6.5 ==
+ - Important:
+ * New session cache mechanism SDBM. Please adapt your main.cf and delete
+ any old ".db" session cache files manually.
+
+2000/04/18
+ - I am using the SDBM session cache for a week right now and did not have
+ any trouble, so I think its worth pushing it out.
+ - I am not completely happy with the dict_del() behaviour of considering
+ a not-found key fatal. It might happen when the smtp[d] processes would
+ be allowed to delete themselves. They are not as of now, so I accept it
+ for now but will reconsider it.
+ - Updated documentation accordingly.
+
+2000/04/17
+ - Received corrections for the HTML-docs from Ralf Hildebrandt
+ .
+
+2000/04/11
+ - Transfered SDBM from home (Linux-testbed :-) to work [found and fixed some
+ small items when compiling on HP-UX]. Started running it under
+ "real life" conditions.
+
+2000/04/07
+ - Implemented "SDBM" Simple Database Management routines as also utilized in
+ ModSSL. Of course, it requires reopening of the databases, so the
+ routines are changed, that the _file_descriptors_ are left open, but
+ the _in_memory_ database stuff (especially the cached data) is closed
+ and reopened on access. This is what is really needed. The pagesize
+ is increased from standard DBM compatibility to hold the session
+ information.
+ Additionally, this software is in the public domain, so no additional
+ license problems arise.
+ - The access goes through the dict_* interface, hence the locking is
+ performed by myflock().
+
+2000/04/01 == Released 0.6.4 ==
+
+2000/04/01
+ - Updated to the new patchlevel of Postfix (19991231-pl06), some parts of
+ the patch were rejected due to changes in smtpd.
+ - Changed patch name with respect of today's release of OpenSSL-0.9.5a.
+ The code remained unchanged.
+
+2000/03/25-31
+ - The cached informations are not deleted by "tlsmgr" even though stored
+ and retrieved by the smtp[d] processess. Strange.
+ - Spend some large amount of time digging through the Berkeley DB
+ documentation and code.
+ * It claims that Berkeley DB is multi-process capable. Caveat: it takes
+ the very complicated "transaction model", that I did not use until now.
+ Hence the session cache does not work as is.
+ * Even with transaction model, Berkeley DB requires re-opening of the
+ databases to get rid of cached information. F*ck.
+ - Finally, I give up on Berkeley DB for session caching. It will never
+ work for us. Even if it would, it requires a large amount of helper files
+ and it seems, that the transaction environment is somewhat fragile when it
+ comes to some problem. I won't rely on it.
+
+2000/03/28 == Released 0.6.3 ==
+
+2000/03/28
+ - As has been pointed out to me, the TLS information in the Received:
+ header is not conform to RFC822.
+ - The TLS protocol and peer CN information is now included in '()', so
+ that it is a comment.
+
+2000/03/21 == Released 0.6.2 ==
+
+2000/03/21
+ - I have been running DB based session caching with the changes for some
+ more time now without problems. Am I really confident? No, not really.
+ I remember the trouble I had with Berkeley DB and sendmail on HP-UX.
+ I don't think I really trust it.
+ - Realized single "smtp_tls_per_site" lookup. I cannot use the more or
+ less comfortable "domain_list" lookups as before, since these do not
+ return the value, just found or not :-(.
+ Hence the lookup is realized with maps and exact lookup. I never tried
+ regexp. But if I understand the docs correctly, it should be possible to
+ use it here to realize wildcard lookups, if it would not have been
+ disabled :-(.
+ - Summary:
+ * Session Cache will be cleaned at "postfix reload" or "postfix start"
+ * New table "smtp_tls_per_site"
+ * Gone: "smtp_tls_[use/enforce]_[recipients/sites]"
+
+
+2000/03/16
+ - Changed pfixtls.c, so that it will only open Session Cache databases,
+ that are already available. tlsmgr is responsible for creation.
+ - Change tlsmgr.c, such that session cache databases will be removed before
+ opening, so that fresh databases are used whenever postfix is restarted.
+ This means, that session information is not kept over a postfix stop/start
+ or reload sequence, but it also means, that issuing a postfix reload will
+ clean the session cache.
+ I don't use simple dict_open with O_TRUNC, because this would not help
+ against database files, that are locked by hanging smtp[d] processes.
+ If you think it will also solve the "hang" problem described for
+ 2000/03/15: in a certain sense it can, since tlsmgr will be killed by
+ the watchdog and new, fresh cache files are installed, but that is not
+ more than an ugly hack. It must be solved in a clean manner.
+
+2000/03/15
+ - Experienced some strange problem with Berkeley DB based session cache.
+ The DB routines hang while trying to delete an entry. I did save the
+ corresponding "hash:" file and could reproduce it (and walk through
+ the endless loop with a debugger), but I didn't find the reason why.
+ Since during "db->del" the database is exclusively locked all other
+ processes hang however, so this is really bad!!!!!!!!
+
+2000/03/12 == Released 0.6.1 ==
+
+2000/03/12
+ - Created tls_info_t structure to hold all information about the active
+ TLS connection. Remove all global variables except those for the
+ running client/server engines (those might be replaced with global
+ variables in smtpd/smtp, though).
+ - Added field "dNSName" to the structure (still unused). This will be
+ used with X503v3 extensions.
+ - Cleaned up TODO, since some items are now done...
+
+2000/03/11
+ - Added missing #include to tlsmgr.c. (Worked without on HP-UX,
+ showed up on Linux.)
+ - Bug: removal of server side sessions from the cache in case of trouble
+ failed, because uppercase hex was used instead of lowercase for the key.
+ This does not affect removal of expired sessions by tlsmgr.
+ - Stepped up to postfix-19991231-pl05.
+
+2000/03/09 == Released 0.6.0 ==
+ - Important:
+ * This release features an additional daemon, the "tlsmgr", please update
+ your master.cf accordingly.
+ * This release does not use the /var/spool/postfix/TLS* directories
+ anymore. Remove them and re-install the original postfix-script.
+ * Check the new/changed configuration parameters tls_random* and
+ smtp[d]_tls_session_cache*.
+ * This release will only work with OpenSSL >= 0.9.5!!!!!
+
+2000/03/09
+ - Testcompilation of Postfix/TLS without -DSSL and the OpenSSL includes and
+ libraries passed.
+ - Worked through tlsmgr.c to remove unneeded header files.
+ - Wrote documentation for tlsmgr.c.
+ - Updated documentation on top of pfixtls.c.
+ - Put (char *) casts into the myfree() calls, where necessary, to make the
+ HP compiler happy.
+ - Updated html PRNG documentation in Postfix/TLS.
+
+2000/03/08
+ - Finished first version of "tlsmgr". Does run through session cache
+ databases and detects and deletes (*) old sessions.
+ * Had to realize SYNC_UPDATES for the dict_db_delete() function and patch
+ the flag handling within the function. Changes sent to Wietse.
+ - Restored qmgr to its original state.
+ - Extended pfixtls.c to need an additional "needs_095_or_later()" function
+ when compiled with an older version of postfix.
+ - The session cache is now enabled, when a database filename is given.
+ smtp[d]_tls_use_session_cache configuration parameters removed,
+ updated documenation accordingly.
+ - Moved the PRNG handling to tlsmgr, applying the new model. tlsmgr will
+ query external sources at startup and will then feed a PRNG exchange
+ file with random data in intervals of configurable (but random driven)
+ length.
+ If running outside chroot, tlsmgr can query the entropy source (e.g.
+ EGD or /dev/urandom) again and so increase entropy with time. If the
+ entropy sources don't limit access, the tlsmgr can run with "postfix"
+ privileges. Mine does.
+ -> master.cf became a new entry.
+ - tlsmgr is realized as a trigger server and has the "fifo" entry. Actually,
+ it does not take any input. One could utilize it to feed back some entropy
+ from running smtp[d] processes, but I think this would overload the
+ issue.
+ - I will release a 0.6.0 pre-version as is. tlsmgr still lacks the detailed
+ information in the header and the interface description in pfixtls.c
+ probably is also not longer up do date.
+
+2000/03/07
+ - Since defective session data can cause SEGFAULTs, it is now armored
+ by a leading structure that does contain a session cache version and
+ the postfix library version before the timestamp. If a session does
+ not match exactly the version numbers, it is immediately discarded
+ and deleted to avoid harm.
+ - Removed the seperate storage of the peer's certificate verify_result,
+ so starting from this moment, Postfix/TLS will only work safely with
+ OpenSSL >= 0.9.5!!!
+ - Ported server side session cache routines to the client side; works.
+ - Analyzed structure of "qmgr" to understand consequences for the planned
+ "tlsmgr" daemon. Transferred the sceleton.
+ - Received word from sendmail, a (at least preliminary) TLS enabled test
+ address is "bounce@esmtp.org".
+
+2000/03/06
+ - Wietse supplied a change to the dict/dict_db mechanism to allow for
+ synchronous updates.
+ Session cache updates for the server side seem to work now, removal of
+ old sessions (when called from the client) integrated.
+
+2000/03/05
+ - Got the database style session cache to run for the server side (at least
+ partial). The removal of old sessions is not yet realized.
+ [There are several man pages for OpenSSL as of 0.9.5, but the i2d etc
+ interfaces are not belong them, so I had to study the source code instead.]
+ * What is not working by now is the synchronization of the memory database
+ to disk. It only is synchronized automatically upon close. It would be
+ necessary to sync after each update or delete, but this is not implemented
+ in Wietse's dict library. I will post an according proposal.
+
+2000/03/04
+ - Wietse posts a patch to select "EHLO" negotiation even if ESMTP is
+ not recognized from the 220 greeting. Activating this flag will however
+ break compatibility with mailers, that simply close the connection
+ upon EHLO. I don't know how the large the number of these broken mailers
+ is, but activating "smtp_always_send_ehlo" is a tradeoff.
+ - Integrated Wietse's patch into Postfix/TLS.
+
+2000/03/03
+ - Received update from Matti Aarnio (Zmailer) is now for some time able
+ to do server _and_ client side TLS. Updated documenation accordingly.
+ When testing, Postfix client to Zmailer server failed, because
+ Zmailer announces with "ESMTP+IDENT" and Postfix does not recognize
+ the ESMTP token (must be seperate), so only HELO is used and STARTTLS
+ is not offered by the Zmailer server. Informed Matti accordingly,
+ will wait until the problem is resolved before actually publishing
+ the update.
+ - Enhanced the documentation by listing automatic reply services at which
+ interoperability can be tested.
+
+2000/03/02
+ - Went through the Postfix source to check out the database routines.
+ It should be possible to move session caching from directory/file-
+ based to database. Since DBM only allows blocks (key+contents) of
+ 1024 bytes and a session is larger, only Berkeley DB can be used.
+ Put some first bits into Postfix/TLS.
+
+2000/02/29 == Released 0.5.5 ==
+
+2000/02/29
+ - OpenSSL 0.9.5 has been released. Since I want to promote 0.9.5, as it
+ contains several bugfixes and enhancements, I release a new version
+ of Postfix/TLS. My personal highlights:
+ * The bug with Win32 Netscape not commencing after certificate storage
+ unlocking should be fixed. (I will leave the not in however, as long
+ as I have not positively checked it myself. Reproducibility...)
+ * The bug, that the certificate verifiation result is not stored in the
+ session cache (discovered for Postfix/TLS 0.4.4) is fixed. I will leave
+ the Postfix/TLS workaround in as long as it will run with older versions
+ of OpenSSL.
+ * The OpenSSL commandline tools like "openssl gendh" now support EGD, so
+ that the examples for generating the DH parameters now will really work
+ with high quality random data :-)
+ * The support of 56bit ciphers has lost its importance since 128bit
+ versions of Netscape etc are now easily available...
+ - This version does not feature source code changes but updated documenation
+ when compared with 0.5.4:
+ * List examples on how to generate good entropy for the PRNG seed in
+ /etc/postfix/random_file.
+ - Update the TODO document with respect to the discussion about session
+ caching and other security items. This document is a very short summary,
+ for the full discussion check the mail archive at
+ http://www.aet.tu-cottbus.de/mailman/listinfo/postfix_tls/
+
+2000/02/26-28
+ - Wietse considers including Postfix/TLS into the main release. A discussion
+ about security relevant features, especially the session cache inside
+ the chroot jail takes place.
+ The discussion will definetely lead to some changes; I have however not
+ decided on the first step, yet :-)
+
+2000/02/21 == RELEASED 0.5.4 ==
+ - Important: Another directoy is created in /var/spool/postfix, so don't
+ forget to install the new versions of conf/postfix-script-*sgid.
+
+2000/02/21
+ - Finished the seed-exchange architecture by saving the random seed at exit
+ of smtp and smtpd.
+ - Wrote documentation for the PRNG handling to the documentation.
+ - Tested on HP-UX (with a current OpenSSL-pre-0.9.5 snapshot and 0.9.4)
+ and on SuSE-Linux (with 0.9.4).
+ * THIS VERSION WILL STILL RUN WITH OPENSSL-0.9.4, but it will also run
+ with OpenSSL-0.9.5. Older versions of Postfix/TLS will not, because the
+ PRNG is not seeded!
+
+2000/02/19
+ - Start to implement my own model of collecting entropy. All smtp and smtpd
+ processes will record some items (mainly the time of actions) to add
+ some entropy into the PRNG. The state is saved and used to re-seed by the
+ smtp and smtpd processes, so that entropy adds up into the pool.
+ The seeding by external file is additionally kept in order to be able
+ to inject additional entropy.
+
+2000/02/18
+ - Included routines to add random seed from a configurable file
+ "rand_file_name". I don't want to retrieve the entropy from a real
+ random system source, because the amount of entropy that can be collected
+ is limited. We might hence stall. Let's think about this problem.
+ - The SSL_CTX_load_verify_locations() has been fixed in the latest
+ OpenSSL snapshot.
+
+2000/02/17
+ - Tracked down the SSL_CTX_load_verify_locations() problem in the OpenSSL
+ library. If more than one CA-certificate is loaded, a bogus return value 0
+ is created, because the count of certs is checked to be "1" instead of
+ allowing ">=1". Reported to openssl-dev.
+
+2000/02/16
+ - Downloaded the latest openssl-SNAPSHOT-20000215 and installed it on
+ my development machine, then recompiled Postfix/TLS and try to run it.
+ * Failure: SSL_CTX_load_verify_locations() fails on reading the CAfile with
+ return value 0, but no actual error is displayed.
+ If the return value is not checked, the CA-certificates work, so that
+ they are loaded and the error indicator seems to be bogus.
+ Reported to openssl-dev mailing list.
+ * Failure: OpenSSL has become picky about correct seeding of the PRNG
+ Pseudo Random Number Generator. Installed some "testseed" that is
+ actually not random, but then Postfix/TLS starts to work again. We
+ will need some good random seed setup, probably reading from either
+ /dev/random (if available) or from EGD.
+ Found out during the experiments, that EGD is not that simple to use
+ as described in some of my Postfix/TLS docs. Must be upgraded.
+ Asked in the openssl-dev mailing list about the recommended amount
+ of random data needed for seeding the PRNG. Ulf Moeller recommends
+ a minimum of 128bit.
+
+2000/02/14 == Released 0.5.3 ==
+
+2000/02/14
+ - OpenSSL 0.9.5 is to be released within the next hours/days. Since I intend
+ to use some of its new features soon, I will re-release 0.5.2 as the last
+ version that will run with 0.9.4 but for the latest postfix patchlevel.
+ - No functional changes.
+ - Updated patch for postfix-19991231-pl04.
+
+2000/01/28 == Released 0.5.2 ==
+
+2000/01/28
+ - Stepped up the next postfix patchlevel postfix-19991231-pl03.
+ No functional changes.
+
+2000/01/03 == Released 0.5.1 ==
+
+2000/01/03
+ - Bug fixed: Don't specify a default value for "smtpd_tls_dcert_file",
+ assuming that typically a DSA certificate is not used.
+ Otherwise smtpd will try to read it on startup and the TLS engine won't
+ start since it is not found.
+ I didn't note this bug before today, because I could not install this
+ release in a larger scale on my own servers due to a network failure
+ of our campus backbone lastring from Dec 31 until today.
+ - Stepped up to the just released postfix-19991231-pl01.
+
+2000/01/01 == Released 0.5.0 ==
+
+2000/01/01
+ - Upgraded to the new postfix release 19991231.
+
+1999/12/30
+ - Enabled support for DSA certificate and key for the server side. One
+ can have both at the same time, the selected cipher decides which one
+ is used. OpenSSL clients (like Postfix/TLS) will prefer the RSA cipher
+ suites, if not especially changed in the cipher selection list.
+ Netscape will only use the RSA cert.
+ - The client side can only have one certificate. There is a way out by using
+ a callback function, that will receive the list of acceptable CAs and
+ then do some clever selection: SSL_CTX_set_client_cert_cb().
+ I will however have to figure out, how it has to be prepared, it seems,
+ that there is no example available.
+ - I have been able to successfully generate a DSA CA and certificates for
+ some Postfix hosts and to do authentication and relaying as expected.
+ So now I have to document how it is done in a practical manner...
+ - Moved up prerelease 0.5.0pre02 to the download site.
+
+1999/12/28
+ - Moved up to SNAPSHOT-19991227.
+ - Don't forget to check the return value when calling
+ SSL_CTX_set_cipherlist().
+ - Add code to load DH-parameters from disk.
+ - Add configuration information for the new functionality: DH paramter
+ support, possibility to influence the cipherlist.
+ - Moved up prerelease 0.5.0pre01 to the download site.
+
+1999/12/25
+ - Found some minutes to relax from the christmas business.
+ - Applied the 0.4.7 patch to SNAPSHOT-19991223 and included the new changes
+ of 1999/12/19.
+ Once the new stable release of postfix is out, this minimum state will be
+ the new Postfix/TLS patch: the new functionality will not influence
+ stability, so it can stay in even if still unfinished.
+
+1999/12/23
+ - Wietse announces SNAPSHOT-19991223: if no severe bugs are found, it will
+ be promoted as next stable release soon. Good to have kept everything
+ from yesterday.
+
+1999/12/22
+ - Got a query from a Postfix/TLS user: the patch does not apply cleanly to
+ SNAPSHOT-19991216 and he somehow messed up to integrate the rejected
+ parts (it later turned out he just forgot on reject).
+ Applied the patch myself and generated a diff, sent it to the user
+ and of course kept a copy for myself, since I will have to apply it
+ myself eventually once the next "stable" release of postfix is out.
+
+1999/12/19
+ - Began modifications for 0.5.x:
+ * Added configuration variables for specifying the cipherlist to be used
+ smtpd_tls_cipherlist and smtp_tls_cipherlist. For the format, there
+ is some (however sparse) documentation in the openssl package.
+ * Call SSL_CTX_set_cipherlist() with these data.
+ * Added default temporary DH parameters to pfixtls.c (only server side is
+ necessary) and configuration variables to specify user generated
+ parameters; they are however not used, yet.
+ The default parameters were generated using the presumably good
+ /dev/random source.
+
+1999/12/13 == Released 0.4.7 ==
+
+1999/12/13
+ - Addendum to the last change: do also remove sessions, that could _not_
+ be reused.
+ - 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
+ depth of 1.
+ Work is in progress for 0.9.5.
+ - Stepped up to the just released new patchlevel postfix-19990906-pl09.
+
+1999/12/10 == Released 0.4.6 ==
+
+1999/12/10
+ - Realized changes implied below: Removed SSL_CTX_add_session() in the
+ client startup; remove session on stop with SSL_SESSION_free().
+ - In the morning there is a mail on the list, that Postfix might be
+ crashed with a single "\" on the "CC:" line. Hence, we should expect
+ a new patchlevel soon. Release the actual change anyway.
+
+1999/12/09
+ - Read in the "openssl-users" mailing list, that SSL_CTX_add_session()
+ is only intended for servers. On the client side, SSL_set_session()
+ is sufficient.
+ Additionally, the session should be explicitely freed, since
+ SSL_set_session() will increment the usage count for the session.
+ Explained by Bodo Moeller.
+
+1999/12/xx
+ - Had a discussion (by email) with Bodo Moeller about DH/DSS. It seems
+ I understand better now (after the discussion) how it works :-).
+ Implementing it should not be too difficult but might take some more
+ hours. Mentally scheduled it for Version "0.5.0" whenever this might
+ be (rough guess: christmas vacation).
+ Decided to hence not discuss this topic in the docs, since it might
+ change in the near future anyway.
+
+1999/11/23
+ - Discussion with rch@writeme.com (Richard) about implementing DH ciphers
+ and DSA keys and certificates on the Postfix/TLS list: It does not work
+ as of now.
+
+1999/11/15 == Released 0.4.5 ==
+
+1999/11/15
+ - Applied patch to postfix-19990906-pl07 without problems. Well, let's
+ release new version of Postfix/TLS, so that we look up to date.
+ - Add the "DO NOT EDIT THIS FILE" to conf/sample-tls.cf.
+
+1999/11/08
+ - Applied patch to the fresh release of postfix-19990906-pl06 without
+ problems. Nothing else, so no new release of Postfix/TLS.
+
+1999/11/07 == Released 0.4.4 ==
+
+1999/11/07
+ - Played around some more with the X509_verify_cert() function: when saving
+ a session, neither the verify_result is saved nor the certificate chain
+ necessary to re-verify. So there were two possibilities left: do a full
+ renegotiation negating the benefit of session caching or
+ - save the verify_result into to the session cache file and set the value
+ when rereading from disk. This way the positive result of session caching
+ is kept.
+ - Make sure, the verify_result value is propagated as pfixtls_peer_verified
+ and used where needed.
+ - After experiencing some failures at TLS connection setup, the SSL_sessions
+ are now freed again when closing. It seems, something is left over in the
+ session structures, even though SSL_clear() is called.
+
+1999/11/06
+ - When not asking for a client certificate, the "Received:" header will show
+ the protocol and cipher, but silently omit the client CN (because they
+ where not supplied). Noted by Craig Sanders .
+ The same holds, if a certificate is asked for, but none supplied.
+ Now, in any case an appropriate information is added in the "Received:"
+ header.
+ - Added a hint to remove sessions from the cache during testing, since
+ old information may still be in the cache. Also proposed by Craig
+ Sanders .
+ - While at it: client CN and issuer CN are printed, but the verification
+ state is not, so that the trust value of this data is not known.
+ * Added (verify OK/not verified) to the Received: header.
+ * Obtained information using the SSL_get_verify_result(SSL *con) call.
+ * Learned, that the state is not saved in the session information, so
+ that a recalled old session will always return "OK" even if the
+ certificate failed the verification! Call it a bug in OpenSSL.
+ Still investigating on a good way to work around this problem.
+ - Fixed a bug in the syslog entries: The client CN is logged, but the
+ issuer CN is not, because of a missing "%s" in the format string.
+
+1999/11/03 == Released 0.4.3 ==
+
+1999/11/03
+ - Added some hints about security to the html documentation.
+ - Tested the changes made two weeks ago at home in the large university
+ setup. I was to a conference in between and didn't want to release
+ the new version without having done some more tests.
+
+1999/10/17
+ - Added another half a ton of comments (this time for the client side),
+ yielding one ton alltogether...
+
+1999/10/16
+ - Rearranged some of the TLS-engine initialization to improve readability.
+ - Do not "free" the SSL connection, when it is not really necessary. Do only
+ reset information about the TLS connection, when there was one. This is
+ the better way instead of the quick fix applied for 0.4.2.
+ - Added half a ton of comments to the TLS code (server side) to document
+ what is done when and why, since there is no real documentation about
+ the OpenSSL library.
+
+1999/10/11 == Released 0.4.2 ==
+
+1999/10/11
+ - Fixed a severe bug introduced in 0.4.0: smtpd and smtp tried to flush
+ old session from the session cache even when TLS was not enabled. Since
+ no SSL-context was allocated, smtp would segfault on connection close.
+
+1999/10/10 == Released 0.4.1 ==
+
+1999/10/10
+ - Added a long description of the session cache handling to the top of
+ global/pfixtls.c.
+ - There is a race condition when cleaning up the session cache in qmgr, that
+ might lead to lost sessions in client mode. The worst consequence is an
+ additional session negotiation, so we can live with it as of now.
+ Bug described in qmgr/qmgr_tls.c.
+ - Implemented immediate removal of session cache files with expired sessions
+ when these are called. No need to first load and then discard them.
+ - Implemented the requirement from RFC2246 to remove sessions, when
+ connection failures occure (well actually, when TLS layer failures
+ occur, but I cannot seperate this from another) for the server side.
+ the client side is under work.
+
+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
+ when somebody sometimes will run into a longer session id.
+
+1999/10/05 == Released 0.4.0 ==
+ - The new disk based session cache is a major step, so the minor release
+ number is pushed to 0.4.
+ - By now I think all necessary bells and whistles are in the code. What
+ is left is a big code cleanup and some more testing before calling this
+ patchkit "1.0.0".
+ - Initiated Mailing List at
+ http://www.aet.tu-cottbus.de/mailman/listinfo/postfix_tls
+
+1999/10/05
+ - Some code cleanup.
+ - Added new options to the documentation and the hint to update
+ "postfix-script", because otherwise qmgr might fail!
+
+1999/10/03
+ - Realized disc based session caching also for the Postfix/TLS client.
+ Must go to real world testing now between hosts.
+ And, of course, tune up the documentation, because users will have to
+ install a new postfix-script, too.
+
+1999/10/02
+ - The old sessions must be removed once they have timed out, so a process
+ is needed that will scan through the list of old sessions and remove
+ once they have expired.
+ Lucky me: this is what qmgr usually does with deferred messages, so
+ qmgr is extended only a little bit and will now also clean up the
+ old sessions from the cache directory.
+ And hey: it is good to see how easily this thing can be extended and
+ functions can easily be reused. Postfix is an excellent peace of
+ software engineering and there is no line of C++ or other "object
+ oriented modern junk" in it. It should be recommended as an example
+ 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
+ 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
+ routines. It does hold for 32byte session ideas.
+ Status: can save sessions to disk and recall them (server side).
+
+1999/09/26
+ - 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
+ session caching is far more complicated.
+
+1999/09/23 == Released 0.3.10 ==
+
+1999/09/23
+ - Debugging for 0.3.8/0.3.9 would have been so much easier, if the error
+ messages put onto the error message stack from the OpenSSL library would
+ have been printed out. The error was clearly stated from the library, I
+ just didn't print it. Added pfixtls_print_errors() calls where missing
+ after calls to the OpenSSL library.
+ Sometimes I feel so old...
+ - Used opportunity to upgrade to the latest postfix patchlevel 05:
+ postfix-19990906-pl05.
+
+1999/09/19 == Released 0.3.9 ==
+
+1999/09/19
+ - Added a "smtp_no_tls_sites" table to allow people to enable TLS negotiation
+ globally and only omit it on a per site basis.
+
+1999/09/18
+ - Finally found the bug described for 0.3.8: In the server setup, the
+ 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...
+ - This bug was hidden during the first developing stages, as the shutdown
+ sequence was not working correct, so the session was not cached.
+
+1999/09/17 == Released 0.3.8 ==
+
+1999/09/17
+ - Something is strange with the session caching in smtpd server mode
+ with Netscape 4.61 client. The first connection is fine, the next
+ one hangs after the server fails with errors while reading the
+ SSLv3 client hello C. (Found by Michael Stroeder )
+ Reproducable with OpenSSL 0.9.3a, 0.9.4 and SNAPSHOT 19990915, so
+ the problem seems to be persistent. I will try to figure out the
+ problem myself before reporting it to the developers. If I don't find
+ it, maybe they do :-)
+ Workaround: the cached session is removed after connection is closed.
+ This will impose some time penalty on the negotiation. As the caching
+ is local in the smtp processes and they time out anyway, the penalty
+ should not be significant.
+ The problem does not occure with Postfix/TLS clients.
+
+1999/09/13 == Released 0.3.7 ==
+
+1999/09/13
+ - Ran tests, seems no further conflicts between Wietse's changes and my
+ extensions.
+
+1999/09/09
+ - Applied the patchkit 0.3.6 to postfix-19990906-pl02 and worked out
+ the rejected part of the patch. From this point of view the patch
+ is included. Now everything has to be retested.
+
+1999/09/09 == Released 0.3.6 ==
+
+1999/09/09
+ - 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.
+ Future Postfix/TLS enhancements will be against this new version 19990906.
+
+1999/08/25 == Released 0.3.5 ==
+
+1999/08/25
+ - Added Wietse's patch for postfix-19990601 to prevent crashing smtpd when
+ VRFY is called without setting the sender with "MAIL FROM:" first.
+
+1999/08/13
+ - Small changes to global/pfixtls.[ch]: Since we also support client STARTLS,
+ we check the peers certificate, which may also be a "server" certificate
+ (not just client). Hence I renamed "*ccert*" to "*peer*".
+ - global/pfixtls.c: add some "const" to "char *" for OpenSSL library calls,
+ to make gcc happy.
+ - Extended comments in pfixtls.[ch] to better match Wietse's style.
+
+1999/08/12 == Released 0.3.4 ==
+
+1999/08/12
+ - Enabled workarounds for known bugs in SSL-engines.
+ - Tested with OpenSSL 0.9.4.
+ - Windows95/NT: Problem with Netscape hanging on first connection when
+ the client certificate database has to be unlocked cannot be reproduced
+ anymore.
+ I am happy, but I am also not sure what caused the problem to go away
+ and I cannot figure out the security settings manually from the files...
+
+1999/08/11
+ - Corrected loglevel handling: At some points smtpd_tls_loglevel was used
+ instead of smtp_tls_loglevel (only noted at loglevels >= 2).
+
+1999/08/09 == Released 0.3.3 ==
+
+1999/08/09
+ - Removed SSL_CTX_set_quiet_shutdown() as it does prevent the shutdown
+ from actually being performed. In order to remove the annoying
+ "SSL3 alert write:warning:close notify" it is now explicitly handled
+ in apps_ssl_info_callback().
+ Bug found by Bodo Moeller .
+
+1999/08/06 == Released 0.3.2 ==
+
+1999/08/06
+ - Add option "smtp_tls_note_starttls_offer" to collect information about
+ hosts, that offered the STARTTLS feature without using it.
+ - Shut up smtpd. Only print information about relaying based on certs
+ when msg_verbose is true.
+
+1999/07/20
+ - Added missing "const" in pfixtls.h (found by Juergen Scheiderer
+ ). HP-UX ANSI-C didn't complain.
+
+1999/07/08 == Released 0.3.1 ==
+
+1999/07/08
+ - New config variable "smtpd_tls_received_header". When "true", the protocol
+ and cipher data as well as subject and issuer CN of the client certificate
+ are included into the "Received:" header.
+
+1999/07/07
+ - "starting TLS engine" message will only be printed when loglevel >=2
+ to reduce unnecessary noise in the log files.
+ - Added code to fetch the protocol (e.g. TLSv1) and the cipher used (by name
+ and bits). Information is printed to the logfile.
+
+1999/07/01 == Released 0.3.0 ==
+
+1999/07/01
+ - (Client mode) Bug fix: Don't try to use STARTTLS if it is not offered. The
+ server we are connected to might not understand it and respond with a
+ "500 command not understood", causing the email to bounce back, even
+ when the lack of STARTTLS is just a temporary problem.
+ - Updated documentation for the new per recipient/site TLS decisions.
+
+1999/06/30
+ - Client mode: Added variables and routines to decide "per recipient" or
+ "per host/site" whether to use/enforce TLS or not.
+
+1999/06/18 == Released 0.2.8 ==
+
+1999/06/18
+ - In client mode the "use_tls" and "enforce_tls" internal variables were
+ not initialized correctly, such that the client could try to use the
+ STARTTLS negotiation even if not wanted. This error was introduced
+ in 0.2.7.
+ Noted by "Cerebus" .
+
+1999/06/08 == Released 0.2.7 ==
+
+1999/06/08
+ - Studied discussions in the IETF-apps-TLS mailing list: MS Exchange
+ seems to offer STARTTLS even if not configured. Added this info to the
+ documentation.
+ - Updated Documentation regarding the changes made.
+
+1999/06/03
+ - The subject-CommonName (CN) of the server certificate is extracted when
+ connecting to a TLS server.
+ - In "smtp_*_tls" mode, this subject-CommonName is matched against the
+ hostname of the server. In "enforce" mode, the connection is droppend
+ when the certified server name and the real hostname differ.
+ - Added missing dependencies in smtp/Makefile.in (missing pfixtls.h since
+ 0.2.0).
+
+1999/06/02 == Released 0.2.6 ==
+
+1999/06/02
+ - Adapted patchkit to postfix-19990601.
+
+1999/06/01 == Released 0.2.5 ==
+
+1999/06/01
+ - Updated OpenSSL API to 0.9.3a -> position of include files has changed
+ from to . No functional changes.
+ - pkcs12 utility is now part of OpenSSL -> changed documentation
+ accordingly.
+
+1999/05/20 == Released 0.2.4 ==
+
+1999/05/20
+ - Updated postfix base 19990317 from pl04 to pl05.
+
+1999/05/14 == Released 0.2.3 ==
+
+1999/05/14
+ - Fixed a bug in pfixtls_stop_*(): there was a ";" to much directly
+ after "if (con);". This check is only done as a safety measure:
+ When SSL is not started you should not stop it. This case could however
+ only happen when the code in smtp[d] would be wrong, so it should never
+ be necessary. (Bug found by Uwe Ohse )
+
+1999/05/11 == Released 0.2.2 ==
+
+1999/05/11
+ - Matti Aarnio: Reworked pfixtls_dump() to use fewer strcpy and strcat calls.
+ - Added information about Matti Aarnio (author/maintainer of ZMailer)
+ working on RFC2487 for ZMailer.
+
+1999/05/04 == Released 0.2.1 ==
+
+1999/05/04
+ - Stuffed up the documenation to reflect the actual status. No change
+ in functionality.
+
+1999/04/30 == Released 0.2.0 ==
+
+1999/04/30
+ - Adjusted the changes in smtp*.c to Wietse's indentation style.
+ - Sorry, the documentation about the client side has by now to be
+ taken from sample-tls.conf. The documenation has to be rearranged
+ in a larger scale.
+
+1999/04/29
+ - Finished client support for STARTTLS in smtp; some testing done.
+ - Fixed a race condition in smtpd: When in PIPELINE mode, the connection
+ was switched back from SSL to normal mode before the buffers were
+ flashed.
+ - Adjusted the code in pfixtls.[ch] and additions in smtpd*.c to
+ Wietse's indentation style.
+
+1999/04/28
+ - Incorporated skeleton of STARTTLS support into smtp.
+ - Introduced variables to control client STARTTLS to configuration.
+
+1999/04/15 == Released 0.1.5 ==
+
+1999/04/15
+ - Adjusted pfixtls.diff to postfix-19990317-pl04.
+
+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.
+ - Call SSL_free() to get rid of the SSL connection structure not used
+ anymore.
+
+1999/04/13 == Released 0.1.4 ==
+
+1999/04/13
+ - Based on a hint in the openssl-users list added an SSL_set_accept_state()
+ before the actual SSL_accept(). I don't really understand why, but the
+ documentation of SSL is a bit short anyway.
+
+1999/04/11
+ - Some more comments on certificates in the documentation.
+
+1999/04/10
+ - Moved initialization of the pfixtls_server_engine to the pre_jail_init()
+ section of smtpd, so that it is called with root privileges to read the
+ key and cert information. The secret key of the server can now be protected
+ by "chown root secretkey.pem; chmod 400 secretkey.pem".
+ Additionally, this makes it possible to run smtpd in chroot jail, even
+ though I didn't test that, yet. All information is read at smtpd startup
+ time except the CAcerts in tls_CApath, which are checked at runtime.
+ I have to look into that.
+ - Updated documentation accordingly.
+ - Rewrote the documentation with regard to the certificate setup and
+ explaining the different types of certificates.
+
+1999/04/09
+ - Introduced pfixtls_print_errors() which imitates BIO_print_errors()
+ (the typical way to print error information in OpenSSL) but writes
+ to syslog instead of a file handle.
+ Hence we can get more informative error information.
+
+1999/04/08 == Released 0.1.3 ==
+
+1999/04/08
+ - Stuffed up the documentation by reworking the references.
+ - Added contributed script for automatic addition of fingerprints.
+ - Added ACKNOWLEDGEMENTS file
+
+1999/04/06 == Released 0.1.2 ==
+
+1999/04/06
+ - Portability: removed call of "snprintf()", as it is not available on
+ some (older) UNIX versions (in this case Solaris 2.5).
+ - Removed calls to "select()" when in TLS mode: Even though no new bytes
+ arrive, there might be bytes left in the SSL buffer -> possible hang.
+
+1999/03/30 == Released 0.1.1 ==
+
+1999/03/30
+ - Added disclaimer about export restrictions.
+ - Fixed a bug in util/match_ops.c:
+ When using dictionary lookup the compare was case sensitive by accident.
+ Effect: Fingerprint matching did not work with databases, only for plain
+ file.
+ Bug report submitted to postfix author.
+
+1999/03/29 == Released first version 0.1.0 ==
diff --git a/TLS_LICENSE b/TLS_LICENSE
new file mode 100644
index 0000000..c588674
--- /dev/null
+++ b/TLS_LICENSE
@@ -0,0 +1,36 @@
+Author:
+=======
+- Postfix/TLS support was originally developed by Lutz Jaenicke of
+ Brandenburg University of Technology, Cottbus, Germany.
+
+License:
+========
+- This software is free. You can do with it whatever you want.
+ I would however kindly ask you to acknowledge the use of this
+ package, if you are going use it in your software, which you might
+ be going to distribute. I would also like to receive a note if
+ you are a satisfied user :-)
+
+Acknowledgements:
+=================
+- This package is based on the OpenSSL package as provided by the
+ ``OpenSSL Project''.
+
+Disclaimer:
+===========
+- This software is provided ``as is''. You are using it at your own risk.
+ I will take no liability in any case.
+- This software package uses strong cryptography, so even if it is created,
+ maintained and distributed from liberal countries in Europe (where it is
+ legal to do this), it falls under certain export/import and/or use
+ restrictions in some other parts of the world.
+- PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG
+ CRYPTOGRAPHY SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST
+ COMMUNICATING TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS
+ ILLEGAL IN SOME PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS PACKAGE
+ TO YOUR COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL
+ TECHNICAL SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR
+ OTHER PEOPLE YOU ARE STRONGLY ADVICED TO PAY CLOSE ATTENTION TO ANY
+ EXPORT/IMPORT AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHOR OF
+ PFIXTLS IS NOT LIABLE FOR ANY VIOLATIONS YOU MAKE HERE. SO BE
+ CAREFULLY YOURSELF, IT IS YOUR RESPONSIBILITY.
diff --git a/TLS_TODO b/TLS_TODO
new file mode 100644
index 0000000..0559010
--- /dev/null
+++ b/TLS_TODO
@@ -0,0 +1,39 @@
+This list does not really follow priority.
+
+* Code cleanup: split smtp_session.c into generic SMTP, legacy TLS,
+ and current TLS. The amount of TLS code now dominates the file.
+ Do this after all other code revisions stabilize, to avoid
+ complicating code reviews.
+
+* Code cleanup: TLS_LEV_NOTFOUND no longer belongs in the TLS
+ library. It is an SMTP-client only feature. To fix, change the
+ policy lookup API and use a different method to indicate if a
+ policy was found. At the same time, fix policy lookup to initialize
+ session->tls_level.
+
+* Code cleanup: see if multiple consecutive switches can be aggregated
+ (set_cipher_grade() and session_tls_init()).
+
+* Implement support of CRL checking. OpenSSL 0.9.7 finally supports CRLs,
+ so Postfix/TLS should support loading CRLs.
+
+* Cleanup the "pfixtls" special logging, so that it fits Wietses original
+ "per site" decision to make debugging easier.
+
+* Move TLS based information from separate lines into Postfix's smtpd
+ logging lines to make logfile analysis easier.
+
+* Check the "info_callback" for sensitive use. I already had to remove the
+ "warning alert" issued on normal shutdown. Why is a warning issued for
+ a normal shutdown??
+
+* Introduce new tls_per_client table to achieve the same selective behaviour
+ for incoming connections.
+
+* Introduce better support for "opportunistic" encryption: collect information
+ about peers connecting; log warnings when the key changed etc.
+ [I am not sure that I already have the best answers available.]
+
+* Find a way to use the certificates themselves instead of the fingerprints
+ to allow certificate based relaying. The maintenance of the fingerprints
+ is a nightmare.
diff --git a/US_PATENT_6321267 b/US_PATENT_6321267
new file mode 100644
index 0000000..4972090
--- /dev/null
+++ b/US_PATENT_6321267
@@ -0,0 +1,124 @@
+1. Disclaimer: This text is not an authoritative statement. If
+you are concerned about the implications of US patent 6,321,267,
+then you should give this text to your own lawyer and get their
+advice.
+
+1.1 Postfix is an MTA that aims to be an alternative to the widely
+ used Sendmail MTA. Postfix is available as open source code
+ from http://www.postfix.org/. One of the features implemented
+ by Postfix is called "sender address verification".
+
+1.2 US patent 6,321,267 (reference 4.1) describes a number of means
+ to stop junk email. One of the elements described in this
+ patent is called "active user testing".
+
+1.3 Postfix "sender address verification" and US patent 6,321,267
+ "active user testing" are implemented by connecting to an MTA
+ that is responsible for the sender address. Specifically, both
+ use the SMTP RCPT command, and both infer the validity of the
+ address from the MTA's response. Reference 4.3 defines SMTP.
+
+=====================================================================
+
+2. It is my understanding that the Postfix MTA's "sender address
+verification" does not infringe on US patent 6,321,267 for the
+following reasons:
+
+2.1 There is prior art for US patent 6,321,267 "active user testing"
+ within the context of the Sendmail MTA. See item (3.1) below.
+
+2.2 US patent 6,321,267 covers "active user testing" only in
+ combination with functions that the Postfix MTA does not
+ implement. See items (3.2) through (3.5) below.
+
+=====================================================================
+
+3. Discussion of specific details of US patent 6,321,267, and their
+relevance with respect to the Postfix MTA.
+
+3.1 Prior art. The "active user testing" method is described in
+ the paper "Selectively Rejecting SPAM Using Sendmail" by Robert
+ Harker (reference 4.2). The paper is cited as the first
+ reference in US patent 6,321,267, and was presented in October
+ 1997. The patent was filed more than two years later, in November
+ 1999. The paper says:
+
+ Bogus User Address
+
+ A desirable criterion for rejecting mail is to filter on
+ bogus user address. However, testing for a bad user address
+ is much harder because, short of sending a message to that
+ user address, there is no reliable way to check the validity
+ of the address. A simplistic test for a bad user address
+ might be to connect to the sender's SMTP server and use
+ either the SMTP VRFY or RCPT command to check the address.
+ If the server does local delivery of the message then this
+ would work well.
+
+ The prior art is about stopping junk mail with the Sendmail
+ MTA. It is my understanding that this prior art is equally
+ applicable to other MTAs, including the Postfix MTA (see items
+ 1.1 and 2.2 above).
+
+3.2 Combination of elements not implemented by the Postfix MTA.
+ Claim 1 of US patent 6,321,267 involves a combination of A)
+ determining whether the sending system is a dialup host, B)
+ determining whether the sending system is an open mail relay,
+ and C) active user testing.
+
+ Postfix does not implement elements A) and B) of claim 1.
+ Therefore, it is my understanding that the Postfix MTA does
+ not infringe on US patent 6,321,267 claim 1.
+
+3.3 Combination of elements not implemented by the Postfix MTA.
+ Claim 52 of US patent 6,321,267 involves the combination of A)
+ a proxy filter and B) active user testing.
+
+ Postfix is an MTA, not a proxy, and does not implement element
+ A) of claim 52. Therefore, it is my understanding that the
+ Postfix MTA does not infringe on US patent 6,321,267 claim 52.
+
+ US patent 6,321,267 makes a clear distinction between proxies
+ and MTAs.
+
+ Figure 13 in US patent 6,321,267 shows how a proxy interacts
+ with a sending system and a local MTA. In the case of (sending
+ system, proxy, local MTA), the proxy assumes no responsibility
+ for delivery of the email message. The responsibility remains
+ with the sending system or passes directly to the local MTA.
+
+ Figure 4 in US patent 6,321,267 shows how a sending system
+ interacts with an intermediate MTA. In the case of (sending
+ system, intermediate MTA, local MTA), the intermediate MTA
+ assumes full responsibility for delivery of the email message.
+
+ Figure 2 in US patent 6,321,267 shows how a sending system
+ interacts with a local MTA. In the case of (sending system,
+ local MTA), the local MTA assumes full responsibility for
+ delivery of the email message.
+
+3.4 The other independent claims in US patent 6,321,267 involve
+ elements that the Postfix MTA does not implement, and do not
+ involve sender address verification. Therefore, it is my
+ understanding that the Postfix MTA does not infringe on these
+ claims in US patent 6,321,267.
+
+3.5 All dependent claims in US patent 6,321,267 depend on claims
+ that involve elements that the Postfix MTA does not implement.
+ Therefore, it is my understanding that the Postfix MTA does
+ not infringe on these claims in US patent 6,321,267.
+
+4.References:
+
+4.1 Albert L. Donaldson, "Method and apparatus for filtering junk
+ email", US patent 6,321,267. Filing date: November 23, 1999.
+ http://www.uspto.gov/
+
+4.2 Robert Harker, "Selectively Rejecting SPAM Using Sendmail",
+ Proceedings of the Eleventh Systems Administration Conference
+ (LISA '97), San Diego, California, Oct. 1997, pp. 205-220.
+ http://www.usenix.org/publications/library/proceedings/lisa97/
+ full_papers/22.harker/22.pdf
+
+4.3 Jonathan B. Postel, "Simple Mail Transfer Protocol", August
+ 1982. http://www.ietf.org/rfc.html
diff --git a/WISHLIST b/WISHLIST
new file mode 100644
index 0000000..4f2ec86
--- /dev/null
+++ b/WISHLIST
@@ -0,0 +1,958 @@
+Wish list:
+
+ Things to do before the stable release:
+
+ Spell-check, double-word check, and HTML validator check.
+
+ Disable -DSNAPSHOT and -DNONPROD in makedefs.
+
+ Remove this file from the stable release.
+
+ Things to do after the stable release:
+
+ Specify WARN_UNUSED_RESULT for all library functions that
+ pass, deliver, bounce or defer a delivery request.
+
+ Specify WARN_UNUSED_RESULT for mac_expand(), after making
+ smtp_reply_footer() undoable.
+
+ Type-checking wrappers for htable(3), ctable(3) and other
+ modules that take and return a void* pointer.
+
+ TLS certificate provenance: indicate whether a subject
+ name/issuer are verified or not (for example, change the
+ attribute name to unverified_ccert_subject etc.). This is
+ relevant only for fingerprint-based authentication including
+ DANE, and affects logging, SMTPD policy, and Milters.
+
+ Generalize the daemon '-S' stand-alone mode, so that it can
+ be used with custom configuration settings for request/reply
+ regression testing. This would use the existing "-o name=value"
+ support to override parameters. For example, queue_directory
+ would point to a directory with sockets for fake versions of
+ Postfix-internal services.
+
+ Update the list of Sendmail macros that Postfix can send
+ to Milters (auth_ssf and TLS-related).
+
+ Update smtpd command count when rejecting or skipping input
+ before command-table lookup. But then we need to count
+ commands that are rejected (malformed UTF-8, tokenizer
+ error, forbidden command), or skipped (noop).
+
+ What is the best place to detect spaces in pathnames during
+ installation/upgrade/packaging? postfix-install for early
+ warning, and post-install as a safety net?
+
+ When the service basename differs from the program file
+ basename, either prepend the service name to the syslogname (as
+ if syslog_name=postfix/service/program), or prepend the service
+ name to the process name (perhaps too confusing). The service
+ indication is desirable for mail delivery transports (smtp
+ versus relay) as it identifies what scheduler parameters are
+ in effect, but it is also desirable for mail receiving services
+ (smtp versus submission verus smtps as configured in the stock
+ master.cf file). This requires exceptions for some program names
+ (exclude smtpd to avoid logging postfix/smtp/smtpd which could
+ result in more confusion, and maybe other program names).
+
+ UTF8 DNS[BW]L domain name.
+
+ Consolidate maps flags in mail_params.h instead of having
+ multiple copies scattered across programs.
+
+ Try to allow UTF-8 myhostname/mydomain, at least in bounce
+ template expansion.
+
+ In the SMTP server, do not issue an enhanced status code when
+ rejecting a connection before the HELO handshake is completed.
+
+ Maybe don't whitelist a client that has maxed out its
+ per-MTA connection count limit.
+
+ Inline support for pcre:{/pattern/=action, ...} and ditto
+ support for regexp: and cidr: tables. Factor out and reuse
+ code that already exists in inline: and other tables.
+
+ Log command=good/bad statistics in postscreen?
+
+ Implement smtpd_client_auth_rate limit?
+
+ Make the access map BCC action consistent with header_checks.
+
+ smtpd_checks tests either must use a DNS dummy resolver
+ (override the res_search API) or all names must be under
+ porcupine.org (but that does not work for address->name
+ lookups, and cannot simulate some errors).
+
+ Reporting the original Message-ID in a bounce message
+ In-Reply-To: or References: header. In the cleanup daemon,
+ grab a copy of the Message-ID and export it along with other
+ header-extracted information at the top of the "extracted"
+ queue file segment. In the queue manager, extract this
+ along with other header-extracted information, and forward
+ the Message-ID in the bounce server notification request.
+
+ Find a way to show non-default OPT, DEBUG etc. settings at
+ the top of the makedefs.out file.
+
+ Update smtputf8_enable in postconf(5)
+
+ Clobber ORCPT when sender is owner-mumble?
+
+ Add milter_mumble_macros to the list of per-macro features.
+
+ The pickup daemon logs warnings only when the cleanup daemon
+ dit not provide a "reason" attribute. Is this logic right?
+
+ up-convert myhostname to UTF-8 in MIME boundary strings?
+
+ Eliminate code duplication between pcf_print_master_field()
+ and pcf_print_master_entry().
+
+ Error reporting: see if pcf_check_master_entry() and children
+ can return error descriptions instead of terminating with
+ a fatal error.
+
+ Make sure that proxy: can handle random:, pipe:, and other
+ multimaps.
+
+ Add a switch to consider postscreen deep protocol tests as
+ "completed" when receiving "RSET" after "RCPT TO" and the
+ session has passed all tests up to that point. RSET becomes
+ like QUIT except perhaps that it does not hang up.
+
+ apipe: map, splits results into address lists and performs
+ lookups for the invidual addresses, converting back and
+ forth between external and internal forms.
+
+ Clarify that receive_override_options have no effect with
+ smtpd_proxy_filter.
+
+ Document the relative order of header_checks, address
+ rewriting, milters.
+
+ NOT: Table-driven case folding and case-insensitive string
+ comparison specifically for UTF-8. Use libicu functions
+ instead.
+
+ When downgrading message/global to 7bit, is quoted-printable
+ the appropriate encoding? Should it be base64?
+
+ Should we encode headers with RFC 2047, when that is the
+ only reason that Postfix cannot deliver to a non-UTF8SMTP
+ server? Probably not in the general case. What about
+ Postfix as a gateway server that converts UTF8SMTP
+ for delivery to non-UTF8SMTP environments?
+
+ Document and test restriction_classes example for
+ smtpd_policy_service_default_action.
+
+ Don't accept AUTH or other features that are not announced
+ in the EHLO response.
+
+ Suggested at Mailserver conference: Postscreen RDNS-based
+ reputation (but this makes postscreen performance highly
+ unpredicable because it introduces a dependency on random
+ DNS servers).
+
+ Suggested at Mailserver conference: a way to select a
+ specific field in a table, presumably as the result value.
+ This may be done with a filtermap{i,j,...}: table that propagates
+ only the specified field(s).
+
+ Discourage the use of "after 220" tests in POSTSCREEN_README
+ and the documentation of individual parameter settings.
+
+ To un-break "make tests" under src/smtpd, make tests
+ independent from the DNS and native routines for host
+ name/address lookup.
+
+ Make been_here flag BH_FLAG_FOLD configurable for masochists.
+
+ Replace some redundant TLS_README sections with pointers
+ to FORWARD_SECRECY_README.
+
+ Move html/index.html source to proto/.
+
+ How hard is it to follow canonical or virtual mapping
+ for the purpose of address validation? We must never
+ reject a valid address.
+
+ Preserve case in smtpd_resolve_addr() and add a structure
+ member for the case-folded address. IIRC some Milter macro
+ needs to show the unfolded address.
+
+ Per SASL account rate limits. This requires new infrastructure
+ that maintains stats by SASL account instead of client IP
+ address.
+
+ Watchdog timer in postmap/postalias.
+
+ Begin code revision, after DANE support stabilizes. This
+ should be one pass that changes only names and no code.
+
+ recipient_delimiters = $recipient_delimiter for BC
+
+ All source code must specify its original author and
+ license statement. Some code modules specify Lutz Jaenicke
+ as the original author and fall under his liberal license.
+ Code that is added to such a module has the same license
+ (or at least something that is not more restrictive). Code
+ modules without input from Lutz Jaenicke must state its
+ original author and license (preferably no more restrictive
+ than Postfix's own license). Currently, too many files list
+ Wietse as the original author, and Lutz Jaenicke's license,
+ which is wrong.
+
+ We have smtp_host_lookup, smtp_dns_resolver_options, and
+ now smtp_dns_support_level. Of these, smtp_dns_resolver_options
+ is orthogonal but the rest has overlap.
+
+ There needs to be support for automatic migration from the
+ deprecated disable_dns_lookups feature to the preferred
+ smtp_dns_support_level feature. This support needs to exist
+ for several releases before the deprecated feature can be
+ removed.
+
+ End code revision, after DANE support stabilizes.
+
+ It would be nice if "bare username" lookup is not hard-coded
+ for domains in the local address class.
+
+ Don't forget Apple's code donation for fetching mail from
+ IMAP server.
+
+ Should postconf -o refuse to work without the -x option?
+
+ Make 30s caching (feature 20070414) configurable, such that
+ 0 means no caching.
+
+ Make errno white/blacklist for getpwnam_r etc. and mailbox
+ write errors.
+
+ smtpd_muble_restrictions rule names are case-insensitive.
+ restriction_classes values are case-sensitive but should
+ be case-insensitive for consistency with smtpd_muble_restrictions.
+
+ Make "rename" the default when postmapping a DB file
+ (later: use copy+rename for postmap -i, postmap -d).
+
+ Service-name parameters aren't documented in daemon manpages.
+
+ When faking up the DSN ORCPT, don't send bare usernames
+ from local command-line submission.
+
+ lmtp_assume_final is broken. A 2XX response does not imply
+ final delivery. The Sieve language implements accept-then-bounce.
+
+ postscreen event-driven plug-in interface to send out a
+ query in parallel with the Pregreet and DNSBL tests, using
+ a simplified version of the policy delegation protocol.
+
+ Parallelized queue preprocessing: rip out the queue manager
+ code to read queue files and resolve recipients, and run
+ it in parallel processes. The queue manager then processes
+ their results as they become available. This would eliminate
+ the qmgr<->trivial-rewrite bottleneck. This can also eliminate
+ much of the scheduling disadvantage of a single queue manager
+ compared to hundreds of mail receiving or sending processes
+ (especially if there is a way to scan the queue in parallel).
+
+ Memory pools for same-type memory objects. This can be
+ used to either increase memory locality for frequently-allocated
+ objects (MRU allocation) or to make use-after-free bugs
+ more detectable (use LRU allocation and wipe the object
+ immediately after free(). Finally, same-type memory pools
+ prevent object type errors with use-after-free bugs.
+
+ "no-cache" option for selected postscreen tests?
+
+ Need a new DICT flag to indicate that a map handle supports
+ locking. If it doesn't (as with memcache or proxymap
+ handles), then postscreen etc. don't need to close a cache
+ file after "postfix reload". After a fork() it is OK to
+ keep using a memcache or proxymap handle, because the parent
+ exits immediately. For this to work, the memcache client
+ needs to propagate the flag from a persistent backup map,
+ but the proxymap protocol should not propagate this to the
+ client.
+
+ Different TTL values for different DNSBL sources?
+
+ Replace master(8) SIGHUP by very simple socket protocol to
+ allow reload of a specific service.
+
+ postscreen: in the dummy SMTP engine, log the protocol state
+ at time of violation (like smtpd, set state->where initially
+ to CONNECT, then update it with the name of the last "known"
+ command, or set it to "unimplemented").
+
+ The discussion of postscreen cache configuration is in the
+ wrong place (how whitelisting works). Move it to the section
+ about configuring postscreen.
+
+ Before proxymap can be exposed to the network (primarily
+ to share postscreen or verify caches), need to enforce
+ limits on attribute string name and value length in IPC
+ protocols. 10-20KB seems OK. We need to enforce content
+ sanity checks (for example, no control characters; Postfix
+ does not pass around multi-line data in table lookups). The
+ VSTREAM library already supports read/write deadlines. We
+ need to use attack-resistant code for numeric conversion.
+
+ move flush_init() etc. from defer service clients to the
+ bounce daemon? Postfix works best when work can be spread
+ out over many clients, instead of over a few servers.
+
+ multi_connect() function that takes a list of inet:host:port
+ and/or unix:pathname specs, with an explicit "inet" prefix
+ argument to handle applications that use host:port only.
+ This will simplify multi-host implementation for memcache
+ client, dovecot client, and other.
+
+ dict_memcache: treat "bad" key as cache miss, i.e. read/write
+ the backup database as if the cache did not exist. This
+ does not help because most Postfix maps (virtual, canonical,
+ access, transport, ...) also don't support spaces in keys.
+
+ postscreen: keep the cache open after "postfix reload" when
+ it is remote (type memcache: or proxy:). This does not work
+ because memcache can use a non-proxied file as backup).
+
+ What is the feasibility of adding an mta_name (personality)
+ attribute that is propagated via queue files and delivery
+ agent requests? It would default to myhostname.
+
+ Major performance improvement opportunity (that is until
+ everyone runs Postfix queues on SSDs). Investigate the
+ viability of a daemon that produces incoming and postdrop
+ queue files on request (in reality it would maintain a
+ limited queue of "spare" files). Central queue file allocation
+ reduces the I/O performance disadvantage that qmgr has when
+ 100 smtpd processes are receiving mail, or when lots of
+ mail is submitted with the sendmail command line. When an
+ smtpd process accepts MAIL FROM, a cleanup daemon requests
+ a queue file and receives a queue ID + file handle from the
+ queue file daemon. If the queue file daemon is down, the
+ cleanup daemon creates the file itself like it does now;
+ this can be hidden in the mail_stream library module. If
+ the mail transaction is aborted, then the cleanup daemon
+ gives the queue file back to the queue file daemon's "spare"
+ file pool, saving most of the overhead of creating and
+ deleting a queue file (the file would still need to be
+ renamed at the start of the next mail transaction). If the
+ cleanup daemon is unable to give a file back, then it can
+ delete the file like it does now; this can be hidden in the
+ mail_stream library module. The whole thing can be
+ transparently added to Postfix by adding calls to a
+ queue-file-service client to the mail_queue_enter() and
+ mail_queue_remove() library routines. Other advantages:
+ 1) negligible performance hit when queue file allocation
+ happens earlier, so that logging and milters have a queue
+ ID for the whole transaction not just the first valid
+ recipient; 2) by not removing every queue files we get most
+ of the performance gain of a queue based on append/truncate
+ instead of the much more expensive create/delete.
+
+ Investigate viability of Sendmail dns maps.
+
+ Make the rules for how to use close-on-exec more explicit.
+
+ Provide separate timeout control for dict_proxy client,
+ rewrite client, resolve client, cleanup client, and so on.
+ Perhaps a timeout argument to the mail_connect() routines.
+
+ Trick from amavisd: save listen socket/fifo/etc state, clear
+ their close-on-exec flags, exec the same program file to
+ re-initialize (with saved socket state on command line or
+ in environment), then restore the listen socket/fifo/etc
+ close-on-exec flags. This could be a way to mitigate the
+ impact of memory/file leaks, and to implement "postfix
+ reload" support for master(8) features that currently don't
+ support this.
+
+ Sub-second time resolution. The first benefit is to make
+ per-destination rate delays more usable. Other applications
+ will come up once the support exists. The straightforward
+ approach is to represent all time intervals in milliseconds,
+ and to update all code that makes system calls with a time
+ argument (as well as the compiled-in upper and lower time
+ parameter bounds, which are currently in seconds).
+ Unfortunately, that limits he maximum time interval to less
+ than 25 days on 32-bit systems, and is likely to break
+ compatibility (for starters, it cannot even deal with the
+ compiled-in 100d upper bound on the queue file lifetime).
+ A second option is to have a "compatibility" time base
+ switch between milliseconds and seconds; this means extra
+ changes to all code that makes system calls with a time
+ argument, and the way that the compiled-in upper and lower
+ bounds are specified. Some of this can be encapsulated in
+ macros like time_to_sec(t), time_to_msec(t) and sec_to_time(t).
+ Finally, it is relatively easy to replace the events(3)
+ interface to use "double" for the time delay arguments, but
+ it is a major pain to convert all main.cf time parameters
+ into doubles (converting only some leads to a documentation
+ nightmare).
+
+ Address verify cache: allow a negative cache "refresh"
+ result to purge a "positive" cache entry in some safe manner.
+ Currently, the negative cache "refresh" result is discarded,
+ address verify cache lookup returns OK, and each lookup
+ forces a "refresh" probe until the entry expires.
+
+ Some Sendmail configurations trigger sub-optimal behavior
+ when the postscreen_whitelist_interfaces parameter lists
+ primary MX addresses only. When postscreen's "deep protocol
+ tests" are successful on the primary MX address (i.e. they
+ result in 4XX responses to RCPT TO), some Sendmail
+ configurations keep the primary MX connection open until
+ AFTER they finish talking to the backup MX address. The
+ problem is that the backup connection runs into a WHITELIST
+ VETO condition because the whitelisting database has not
+ yet been updated with the PASS NEW result for the primary
+ MX connection. Unfortunately postscreen can't update the
+ whitelisting database before the primary MX connection is
+ closed, because a client may still make a mistake.
+
+ In the SMTP server, check if the connection is closed before
+ replying to ".", and discard the message if the reply can't
+ be sent. This reduces the time window for RFC 1047 message
+ duplication, and may even prevent the delivery of some spam.
+ http://www.exim.org/lurker/message/20070416.103159.9d5ff0ce.en.html
+ This requires splitting the SMTP server's commit operation
+ into two operations: first, a tentative commit operation
+ that performs most of the I/O and processing in milters and
+ in the cleanup server; second, a final commit operation
+ that is executed only if the remote SMTP client hasn't hung
+ up in the mean time. Unfortunately, SMTP-based before-queue
+ content filters don't support a tentative commit operation.
+
+ Find out how to reproduce Berkeley DB bogus ENOENT errors.
+ postscreen does not log this with Berkeley DB 1 (FreeBSD
+ 4..8), 4.7.25 (Ubuntu 9.04) and 4.8.24 (Ubuntu 10.04).
+
+ postconf command-line option to show the compile-time
+ settings (CCARGS, AUXLIBS) in case binary packages
+ don't install the makedefs.out file.
+
+ events.c: cache the side effects of file descriptor event
+ enable/disable operations in user space, and do bulk kernel
+ updates at event_loop() time. This can eliminate costly
+ system calls with successive event disable/enable operations
+ on the same file descriptor. This can also eliminate the
+ need for tricky code that tries to avoid the expense of
+ successive disable/enable operations. Such code is likely
+ to introduce bugs.
+
+ When does it pay off to send domains in the active queue
+ to a DNS prefetch daemon? Could this generalize to a dynamic
+ transport map that piggy-backs domains with the same MX
+ host into the same mail delivery transaction?
+
+ tlsproxy(8) should receive TLS preferences from postscreen(8)
+ and smtpd(8), instead of reading them from main.cf. This
+ means that many tlsproxy_ parameters become postscreen_
+ parameters, and that tls_server_init() parameters move to
+ to tls_server_start(). That is a significant API change.
+ It also means tlsproxy can't open all files before chroot().
+
+ anvil rate limit for sasl_username.
+
+ Encapsulate nbbio buffer access and update by tlsproxy.
+
+ Full-duplex support for tlsproxy(8). This requires updating
+ events(3) and nbbio(3).
+
+ Register automagic destructor for object attached to VSTREAM.
+
+ Use different ipc time limits for email message transactions
+ (smtpd, pickup)->cleanup and for quick query/reply transactions
+ such as address rewriting/resolution. Beware of large time
+ limits for local or virtual alias expansion.
+
+ permit_tempfail_action (default: defer_if_reject) to be
+ used as the default value for dnswl_tempfail_action and
+ rhswl_tempfail_action. Steal liberally from the code that
+ implements unverified_recipient_tempfail_action etc.
+
+ Support filtering of messages that are generated by Postfix:
+ This would apply to postmaster notices and bounce messages
+ (DKIM), and address verification (BATV).
+
+ Consistency: in postconf.proto make .. tags bold.
+
+ Would it help if there were different cleanup_service
+ parameter names for different message paths? smtpd(8) uses
+ the same cleanup_service value for receiving remote mail
+ and for submitting postmaster problem reports. Do we need
+ separate mumble_cleanup_service_name parameters for "inject",
+ "notify" and "forward" (with backwards compatible defaults)?
+
+ IF/ENDIF support for CIDR tables.
+
+ Need a regular expression table to translate address
+ verification responses into hard/soft/accept reply codes.
+
+ Is there a way to make sendmail -V work after local alias
+ expansion? Majordomo-like mailing lists would benefit from
+ this; the example in VERP_README does not work in the general
+ case.
+
+ When an alias is a member of an :include: list with owner-
+ alias, local(8) needs an option to deliver alias or alias->user
+ indirectly. What happens when an :include: list with owner-
+ alias includes another list?
+
+ Don't allow empty result values in pcre and regexp maps.
+ Postfix doesn't allow them anywhere else (check this).
+
+ Make PCRE_MAX_CAPTURE configurable.
+
+ Add some checks for tokens starting with #. A challenge
+ is to report sensible context from the guts of some low-level
+ parser, without introducing a great deal of clumsiness.
+
+ Add sendmail macros for {verify} and maybe other TLS info.
+
+ Find out if we are doing the correct thing by looking at
+ state->milter_reject_text when expanding {rcpt_addr} or
+ {rcpt_host}.
+
+ Find out why post_mail() etc. block when the qmgr fifo is
+ full (answer: trigger_timeout). How can this cause delays
+ in the queue manager? When a recipient bounces during
+ (transport, nexthop, address) resolution, it is redirected
+ to the error or retry mailer; and bounce-after-delivery is
+ asynchrounous so it can't block the queue manager, either.
+
+ How to ensure that proxy_read_maps is processed after all
+ its dependencies are initialized, or just bite the bullet
+ and rewrite the parameter initialization code.
+
+ The cleanup virtual alias expansion limit does not really
+ deliver on its promises. 1) It promises to truncate the
+ result without aborting delivery, which would be undesirable
+ anyway, but that is not what it does, so that is good. 2)
+ It keeps all the recipients from multi-recipient database
+ lookup, then terminates further recursion when the result
+ exceeds the expansion limit. This behavior achieves the
+ original goal that all things shall have a finite size (even
+ though but we don'really care how large they are) but may
+ result in surprises when recipients are listed in virtual
+ alias domains or need expansion for other reasons. In a
+ phone call with Victor, a reasonable way out is to set the
+ limit to some large number (100000) and abort delivery when
+ the result exceeds the limit.
+
+ Should the postscreen save permanent white/black list lookup
+ results to the temporary cache, and query the temporary
+ cache first? Skipping white/black list lookups will speed
+ up the handling of "good" clients without a permanent
+ whitelist entry. Of course, this means that updates to the
+ white/black lists do not immediately take effect. Workarounds:
+ 1) use a shorter temporary cache TTL for clients on the
+ permanent black/white lists; 2) ignore cached white/black
+ list lookup results after "postfix reload"; 2) adjust the
+ logging, for example "WHITELISTED address (cached)" and
+ "BLACKLISTED address (cached)" to eliminate surprises.
+ Comparing the cache entry time with the white/blacklist
+ file modification time is not foolproof: for example, pcre
+ or CIDR tables are read only once.
+
+ It would be nice if the generic dict_cache(3) cache manager
+ could postpone process suicide until cache cleanup is
+ completed (but that is not possible when postscreen forks
+ into the background to finish already-accepted connections,
+ and it is not desirable when a host is being shut down).
+
+ When postscreen drops a connection, a 521 "greeting" should
+ be of the form "521 servername..." and not have an enhanced
+ status code. The "521 5.7.1" form can be used after EHLO.
+ Of course no spammer is going to complain about Postfix
+ SMTP compliance.
+
+ Find a place to document all the mail routing mechanisms
+ in one place so people can figure out how Postfix works.
+
+ The access map BCC action is marked "not stable", perhaps
+ because people would also expect BCC actions in header/body_checks.
+ How much would it take to make the queue file editing code
+ generally usable?
+
+ Move smtpd_command_filter into smtpd_chat_query() and update
+ the session transcript (see smtp_chat_reply() for an example).
+
+ SMTP connection caching without storing connections, to
+ improve TLS mail delivery performance.
+
+ Should not milter8_mail_event() unset the "hold" default
+ reply? Better, the default reply should not be used for
+ this purpose.
+
+ Don't send MASTER_STAT_TAKEN/MASTER_STAT_AVAIL when a server
+ runs with process limit of 1. But this means the master
+ never learns that the process is successful and will always
+ pause $service_throttle_time before restarting a failed service.
+
+ Don't bother maintaining a per-service lockfile when a
+ server runs with process limit of 1. The purpose of the
+ lockfile is to avoid thundering herd problems when the kernel
+ wakes up multiple processes for each new client connection.
+
+ Implement PREPEND action for milter_header_checks. Save the
+ to-be-prepended text to buffer, then emit it along with the
+ new header.
+
+ Fix the header_body_checks API, so that the name of the map
+ class (e.g. milter_header_checks) is available for logging.
+
+ Fix the mime_state and header_body_checks APIs, so that
+ they use VSTRINGs. This simplifies REPLACE actions.
+
+ Update FILTER_README for multi-instance support, and rename
+ the old document to FILTER_LEGACY_README.
+
+ Need to sign delivery status notifications, to avoid surprises
+ when eventually people start enforcing DKIM etc. signatures.
+
+ Either document or remove the internal_mail_filter_classes
+ feature (it's disabled by default).
+
+ Make the "unknown recipient" test configurable as
+ first|last|never, with "yes"=="last" for backwards
+ compatibility. The "first" setting is good for performance
+ (stress=yes) when all users are defined in local files; but
+ it may perform worse when users are in networked tables.
+
+ Cleanup: make DNSBL query format configurable beyond the
+ client's reversed IP address.
+
+ With 'final delivery' in the LMTP client, need an option
+ to also add delivered-to and other pipe(8) features. This
+ requires making mail_copy() functionality available in
+ non-mailbox context.
+
+ Cleanup: modernize the "add missing From: header" code, to
+ ``phrase '' form. Most likely, quote the entire phrase
+ if it contains any text that is special, then rfc822_externalize
+ the whole thing.
+
+ SMTP server: make the server_addr and server_port available
+ to policy server, Dovecot, and perhaps Milters.
+
+ Med: local and remote source port and IP address for smtpd
+ policy hook.
+
+ Maybe change maps_rbl_reject_code default to 521, and
+ update wording in STRESS_README.
+
+ Encapsulate time_t comparisons so that they can be made
+ system dependent (use difftime() where available).
+
+ Encapsulate time_t conversions (e.g. REC_TYPE_TIME) so that
+ they can be made system dependent.
+
+ Plan for time_t larger than long, or wait for LP64 to
+ dominate the world?
+
+ Make "AUTH=<>" appendage to MAIL FROM configurable, enabled
+ by default.
+
+ To support ternary operator without a huge parsing effort,
+ consider ${value?{xxx}:{yyy}} where ${name} is existing
+ syntax, and where ?{text} and :{text} are new syntax that
+ is unlikely to break existing configurations. Or perhaps
+ it's just too ugly.
+
+ Write delivery rate delay example (which _README?) and auth
+ failure cache example (SASL_README). Then include them in
+ SOHO_README.
+
+ Look for alternatives for the use of non_smtpd_milters.
+ This involves some way to force local submissions to go
+ through a local SMTP client and server, without triggering
+ "mail loops back to myself" false alarms. The advantage is
+ that it makes smtpd_mumble_restrictions available for local
+ and remote mail; the disadvantage is that it makes local
+ submissions more dependent on networking. One possibility
+ is to use "pickup -o content_filter=smtp:127.0.0.1:10025",
+ or a dedicated SMTP client/server on UNIX-domain sockets;
+ we could also decide to always suppress "mail loop" detection
+ for loopback connections. Another option is to have the
+ pickup or cleanup server drive an SMTP client directly;
+ this would require extension of the mail_stream() interface,
+ plus a way to handle bounced/deferred recipients intelligently,
+ but it would be at odds with Postfix design where delivery
+ agents access queue files directly; exposing delivery agents
+ to raw queue files violates another Postfix design principle.
+
+ Consolidate duplicated code in *_server_accept_{pass,inet}().
+
+ Consolidate duplicated code in {inet,unix,upass}_trigger.c.
+
+ In the SMTP client, handle 421 replies in smtp_loop() by
+ having the input function raise a flag after detecting 421
+ (kill connection caching and be sure to do the right thing
+ with RSET probes), leave the smtp_loop() per-command reply
+ handlers unchanged, and have the smtp_loop() reader loop
+ bail out with smtp_site_fail("server disconnected after
+ %s", where), but only in the case that it isn't already in
+ the final state. But first we need to clean up the handling
+ of do/don't cache, expired, bad and dead sessions.
+
+ Combine smtpd_peer.c and qmqpd_peer.c into a single function
+ that produces a client context object, and provide attribute
+ print/scan routines that pass these client context objects
+ around. With this, we no longer have to update multiple
+ pieces of code when a client attribute is added. Ditto for
+ SASL and TLS context.
+
+ Don't log "warning: XXXXX: undeliverable postmaster
+ notification discarded" for spam from outside.
+
+ Really need a cleanup driver that allows testing against
+ Milter applications instead of synthetic events. This would
+ have to provide stubs for clients that talk to Postfix
+ daemon processes. See if this approach can also be used for
+ other daemons.
+
+ smtpd(8) exempts $address_verify_sender from access controls,
+ but it doesn't know whether cleanup(8) or delivery agents
+ modify the sender. Would it be possible to "calibrate" this
+ exemption, perhaps by having delivery agents pass the probe
+ sender to the verify server, keeping in mind that the probe
+ sender may differ per delivery agent due to output rewriting.
+
+ Update attr_print/scan() so they can send/receive file
+ descriptors. This simplifies kludgy code in many daemons.
+
+ Would there be a problem adding $smtpd_mumble_restrictions
+ and $smtpd_sender_login_maps to the default proxy_read_maps
+ settings?
+
+ Remove defer(8) and trace(8) references and man pages. These
+ are services not program names. On the other hand we have
+ man pages for lmtp(8) and smtp(8), but not for relay(8).
+ Likewise, retry(8) does not have a man page.
+
+ Bind all deliveries to the same local delivery process,
+ making Postfix perform as poorly as monolithic mailers, but
+ giving a possibility to eliminate duplicate deliveries.
+
+ Maybe declare loop when resolve_local(mxhost) is true?
+
+ Update message content length when adding/removing headers.
+
+ Need scache size limit.
+
+ REDIRECT should override original recipient info, and
+ probably override DSN as well.
+
+ Update FILTER_README with mailing list suggestions to tag
+ with a badness indicator and then filter down-stream.
+
+ Make null local-part handling configurable: either expand
+ into mailer-daemon (current bahavior) or disallow (strict
+ behavior, currently implemented only in the SMTP server).
+
+ Add M flag (enable multi-recipient delivery) to pipe daemon.
+
+ The usage of TLScontext->cache_type is unclear. It specifies
+ a TLS session cache type (smtpd, smtp, or lmtp), but it is
+ sometimes used as an indicator that TLS session caching is
+ unavailable. In reality, that decision is made by not
+ registering call-back functions for cache maintenance.
+
+ Postfix TLS library code should copy any strings that it
+ receives from the application, instead of passing them
+ around as pointers. TLScontext->cache_type is a case in
+ point.
+
+ Are transport:nexthop null fields the same as in the case
+ of default_transport etc. parameters?
+
+ Don't lose bits when converting st_dev into maildir file
+ name. It's 64 bits on Linux. Found with the BEAM source
+ code analyzer. Is this really a problem, or are they just
+ using 64 bits for upwards compatibility with LP64 systems?
+
+ Do or don't introduce unknown_reverse_client_reject_code.
+
+ Check that "UINT32 == unsigned int" choice is ok (i.e. LP64
+ UNIX).
+
+ Tempfail when a Milter application tries to negotiate content
+ access, while it is configured in an SMTP server that runs
+ before the smtpd_proxy filter.
+
+ Log DSN original recipient when rejecting mail.
+
+ Keep whitespace between label and ":"?
+
+ Make the map case folding/locking options configurable, if
+ not at run-time then at least at compile time so we get
+ consistent behavior across applications.
+
+ Investigate what it would take to eliminate oqmgr, and to
+ make the old behavior configurable in a unified queue
+ manager. This would shave another 2.7 KLOC from the source
+ footprint.
+
+ Document the case folding strategy for match_list like
+ features.
+
+ Eliminate the (incoming,deferred)->active rename operation.
+ This requires an in-memory hash of queue file names to avoid
+ duplicate open() operations.
+
+ Softbounce fallback-to-ISP for SOHO users. This heuristic
+ assumes that when direct-to-MX delivery fails with 5XX,
+ delivery via the ISP may still succeed. This could be
+ implemented by enabling soft bounces for destinations other
+ than the smtp_fallback_relay. So the only benefit of this
+ over the existing soft_bounce feature is that it has no
+ effect on smtp_fallback_relay deliveries.
+
+ Centralize main.cf parameter input so that defaults work
+ consistently. What about parameter names that are prefixed
+ with mail delivery transport names?
+
+ Fix default time unit handling so that we can have a default
+ bounce lifetime of $maximal_queue_lifetime, without causing
+ panics when a non-default maximal_queue_lifetime setting
+ includes no time unit.
+
+ After the 20051222 ISASCII paranoia, lowercase() lowercases
+ ASCII text only.
+
+ Privacy: remove local command/pathname details from remote
+ delivery status reports, and log them via local msg_warn().
+
+ Is it safe to cache a connection after it has been used for
+ more than some number of address verification probes?
+
+ Try to recognize that Resent- headers appear in blocks,
+ newest block first. But don't break on incorrect header
+ block organization.
+
+ Hard limits on cache sizes (anvil, specifically).
+
+ Laptop friendliness: make the qmgr remember when the next
+ deferred queue scan needs to be done, and have the pickup
+ server stat() the maildrop directory before searching it.
+
+ Low: replace_sender/replace_recipient actions in access
+ maps, so they can be used in policy servers?
+
+ Low: configurable order of local(8) delivery methods.
+
+ Med: smtp_connect_timeout_budget (default: 3x smtp_connect_timeout)
+ to limit the total time spent trying to connect.
+
+ Med: transform IPv4-in-IPv6 address literals to IPv4 form
+ when comparing against local IP addresses?
+
+ Med: transform IPv4-in-IPv6 address literals to IPv4 form
+ when eliminating MX mailer loops?
+
+ Med: Postfix requires [] around IPv6 address information
+ in match lists such as mynetworks, debug_peer_list etc.,
+ but the [] must not be specified in access(5) maps. Other
+ places don't care. For now, this gotcha is documented in
+ IPV6_README and in postconf(5) with each feature that may
+ use IPv6 address information. The general recommendation
+ is not to use [] unless absolutely necessary.
+
+ Med: the partial address matching of IPv6 addresses in
+ access(5) maps is a bit lame: it repeatedly truncates the
+ last ":octetpair" from the printable address representation
+ until a match is found or until truncation is no longer
+ possible. Since one or more ":" are usually omitted from
+ the printable IPv6 address representation, this does not
+ really try all the possibilities that one might expect to
+ be tried. For now, this gotcha is documented in access(5).
+
+ Low: reject HELO with any domain name or IP address that
+ this MTA is the final destination for.
+
+ Low: should the Delivered-To: test in local(8) be configurable?
+
+ Low: make mail_addr_find() lookup configurable.
+
+ Low: update events.c so that 1-second timer requests do not
+ suffer from rounding errors. This is needed for 1-second
+ SMTP session caching time limits. A 1-second interval would
+ become arbitrarily short when an event is scheduled just
+ before the current second rolls over.
+
+ Low: configurable internal/system locking method.
+
+ Low: add INSTALL section for pre-existing Postfix systems.
+
+ Low: add INSTALL section for pre-existing RPM Postfixes.
+
+ Low: disallow smtpd_recipient_limit < 100 (the RFC minimum).
+
+ Low: noise filter: allow smtp(8) to retry immediately if
+ all MXes return a quick ECONNRESET or 4xx reply during the
+ initial handshake. Retry once? How many times?
+
+ Low: make post-install a "postfix-only script" so it can
+ take data from the environment instead of main.cf.
+
+ Low: randomize deferred mail backoff.
+
+ Med: separate ulimit for delivery to command?
+
+ Med: postsuper -r should do something with recipients in
+ bounce logfiles, to make sure the sender will be notified.
+ To be perfectly safe, no process other than the queue manager
+ should move a queue file away from the active queue.
+
+ This could involve tagging a queue file, and use up another
+ permission bit (postsuper tags a "hot" file, qmgr requeues it).
+
+ Low: postsuper re-run after renaming files, but only a
+ limited number of times.
+
+ Low: smtp-source may block when sending large test messages.
+
+ Med: find a way to log the sender address when MAIL FROM
+ is rejected due to lack of disk space.
+
+ Low: revise other local delivery agent duplicate filters.
+
+ Low: all table lookups should consistently use internalized
+ (unquoted) or externalized (quoted) forms as lookup keys.
+ smtpd, qmgr, local, etc. use unquoted address forms as keys.
+ cleanup uses quoted forms.
+
+ Low: have a configurable list of errno values for mailbox
+ or maildir delivery that result in deferral rather than
+ bouncing mail. What about "killed by signal" exits?
+
+ Low: after reorganizing configuration parameters, add flags
+ to all parameters whose value can be read from file.
+
+ Medium: need in-process caching for map lookups. LDAP servers
+ seem to need this in particular. Need a way to expire cached
+ results that are too old.
+
+ Low: generic showq protocol, to allow for more intelligent
+ processing than just mailq. Maybe marry this with postsuper.
+
+ Low: default domain for appending to unqualified recipients,
+ so that unqualified names can be delivered locally.
+
+ Low: The $process_id_directory setting is not used anywhere
+ in Postfix. Problem reported by Michael Smith, texas.net.
+ This should be documented, or better, the code should warn
+ about attempts to set read-only parameters.
+
+ Low: while converting 8bit text to quoted-printable, perhaps
+ use =46rom to avoid having to produce >From when delivering
+ to mailbox.
+
+ virtual_mailbox_path expression like forward_path, so that
+ people can specify prefix and suffix.
diff --git a/auxiliary/name-addr-test/getaddrinfo.c b/auxiliary/name-addr-test/getaddrinfo.c
new file mode 100644
index 0000000..275bf59
--- /dev/null
+++ b/auxiliary/name-addr-test/getaddrinfo.c
@@ -0,0 +1,64 @@
+ /*
+ * getaddrinfo(3) (name->address lookup) tester.
+ *
+ * Compile with:
+ *
+ * cc -o getaddrinfo getaddrinfo.c (BSD, Linux)
+ *
+ * cc -o getaddrinfo getaddrinfo.c -lsocket -lnsl (SunOS 5.x)
+ *
+ * Run as: getaddrinfo hostname
+ *
+ * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
+ *
+ * Author: Wietse Venema, IBM T.J. Watson Research, USA.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+int main(int argc, char **argv)
+{
+ char hostbuf[NI_MAXHOST]; /* XXX */
+ struct addrinfo hints;
+ struct addrinfo *res0;
+ struct addrinfo *res;
+ const char *addr;
+ int err;
+
+#define NO_SERVICE ((char *) 0)
+
+ if (argc != 2) {
+ fprintf(stderr, "usage: %s hostname\n", argv[0]);
+ exit(1);
+ }
+ memset((char *) &hints, 0, sizeof(hints));
+ hints.ai_family = PF_UNSPEC;
+ hints.ai_flags = AI_CANONNAME;
+ hints.ai_socktype = SOCK_STREAM;
+ if ((err = getaddrinfo(argv[1], NO_SERVICE, &hints, &res0)) != 0) {
+ fprintf(stderr, "host %s not found: %s\n", argv[1], gai_strerror(err));
+ exit(1);
+ }
+ printf("Hostname:\t%s\n", res0->ai_canonname);
+ printf("Addresses:\t");
+ for (res = res0; res != 0; res = res->ai_next) {
+ addr = (res->ai_family == AF_INET ?
+ (char *) &((struct sockaddr_in *) res->ai_addr)->sin_addr :
+ (char *) &((struct sockaddr_in6 *) res->ai_addr)->sin6_addr);
+ if (inet_ntop(res->ai_family, addr, hostbuf, sizeof(hostbuf)) == 0) {
+ perror("inet_ntop:");
+ exit(1);
+ }
+ printf("%s ", hostbuf);
+ }
+ printf("\n");
+ freeaddrinfo(res0);
+ exit(0);
+}
diff --git a/auxiliary/name-addr-test/gethostbyaddr.c b/auxiliary/name-addr-test/gethostbyaddr.c
new file mode 100644
index 0000000..e58db9e
--- /dev/null
+++ b/auxiliary/name-addr-test/gethostbyaddr.c
@@ -0,0 +1,46 @@
+ /*
+ * gethostbyaddr tester. compile with:
+ *
+ * cc -o gethostbyaddr gethostbyaddr.c (SunOS 4.x)
+ *
+ * cc -o gethostbyaddr gethostbyaddr.c -lnsl (SunOS 5.x)
+ *
+ * run as: gethostbyaddr address
+ *
+ * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
+ */
+
+#include
+#include
+#include
+#include