diff options
Diffstat (limited to '')
-rw-r--r-- | RELEASE_NOTES-2.8 | 383 |
1 files changed, 383 insertions, 0 deletions
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 <user@example> Recipient address rejected: User unknown + 550 5.5.1 For assistance, call 800-555-0101. + +This feature supports macro expansion ($client_address, $localtime, +etc.), as documented in the postconf(5) manpage. + +This feature is also supported as postscreen_reject_footer using +the same setting as smtpd_reject_footer by default. + +Major changes - rfc compliance +------------------------------ + +[Incompat 20101206] Postfix by default no longer adds a "To: +undisclosed-recipients:;" header when no recipient specified in the +message header. The Internet mail RFCs have supported messages +without recipient header for almost 10 years now. + +For backwards compatibility, specify: + +/etc/postfix/main.cf + undisclosed_recipients_header = To: undisclosed-recipients:; + +Note: both the ":" and ";" are required. + +Major changes - tls support +--------------------------- + +[Incompat 20110102] The Postfix SMTP server now always re-computes +the SASL mechanism list after successful completion of the STARTTLS +command. Earlier versions only re-computed the mechanism list when +the values of smtp_sasl_tls_security_options and smtp_sasl_security_options +differ. This could produce incorrect results, because the Dovecot +authentication server may change responses when the SMTP session +is encrypted. + +[Incompat 20110102] The smtpd_starttls_timeout default value is now +stress-dependent. By default, TLS negotiations must now complete +under overload in 10s instead of 300s. + +[Feature 20101223] The new tls_disable_workarounds parameter specifies +a list or bit-mask of OpenSSL bug work-arounds to disable. This may +be necessary if one of the work-arounds enabled by default in OpenSSL +proves to pose a security risk, or introduces an unexpected +interoperability issue. Some bug work-arounds known to be problematic +are disabled in the default value of the parameter when linked with +an OpenSSL library that could be vulnerable. See postconf(5) and +TLS_README for details. + +With "tls_preempt_cipherlist = yes" the Postfix SMTP server will +choose its most preferred cipher that is supported (offered) by the +client. This can lead to a more secure or performant cipher choice, +but may also introduce interoperability problems when a client +announces support for a cipher that does not work. See postconf(5) +and TLS_README for details. + +[Feature 20101217] The lower-level code in the TLS engine was +simplified by removing an unnecessary layer of data copying. OpenSSL +now writes directly to the network. The difference in performance +should be hardly noticeable. + +[Incompat 20100610] Postfix no longer appends the system-supplied +default CA certificates to the lists specified with *_tls_CAfile +or with *_tls_CApath. This prevents third-party certificates from +getting mail relay permission with the permit_tls_all_clientcerts +feature. + +Unfortunately this change may cause compatibility problems when +configurations rely on certificate verification for other purposes. +Specify "tls_append_default_CA = yes" for backwards compatibility. + +Major changes - postscreen +-------------------------- + +See html/POSTSCREEN_README.html for an introduction to postscreen +(or the text version, README_FILES/POSTSCREEN_README). The text +below summarizes milestones in reverse chronological order. + +[Incompat 20110111] The postscreen_access_list feature replaces the +postscreen_whitelist_networks and postscreen_blacklist_networks +features. Reason: CIDR-style access maps are some 100x faster than +the code that implemented the postscreen_white/blacklist_networks +support. CIDR maps can match about 100 million CIDR patterns/second +on a modern CPU, which is not blindingly fast but adequate for the +near future. + +[Feature 20110102] STARTTLS support for the postscreen(8) daemon. +This is implemented by a new tlsproxy(8) daemon that you will need +to enable in master.cf (see POSTSCREEN_README for instructions). +tlsproxy(8) implements its own tlsproxy_mumble versions of TLS-related +smtpd_mumble parameters. This leaves no confusion about which +parameters will affect tlsproxy(8) behavior, but it adds another +25 parameters to the documentation. + +[Incompat 20100912] If your DNSBL queries have a "secret" in the +domain name, you must now censor this information from the postscreen(8) +SMTP replies. For example: + + /etc/postfix/main.cf: + postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply + + /etc/postfix/dnsbl_reply: + # Secret DNSBL name Name in postscreen(8) replies + secret.zen.spamhaus.org zen.spamhaus.org + +The texthash: format is similar to hash: except that there is no need to +run postmap(1) before the file can be used, and that it does not detect +changes after the file is read. It is new with Postfix version 2.8. + +[Incompat 20100912] The postscreen "continue" action is now called +"ignore". The old name is still supported but no longer documented. + +[Incompat 20100912] The postscreen_hangup_action parameter was +removed. Postscreen now always behaves as if "postscreen_hangup_action += drop". + +[Incompat 20100912] The postscreen_cache_retention_time default was +increased from 1d to 7d, to avoid deleting results from expensive +deep SMTP protocol tests too quickly. + +[Feature 20100912] SMTP protocol engine for deep protocol tests, +and for logging the helo/sender/recipient information when postscreen +rejects an attempt to deliver mail. + +The postscreen SMTP protocol engine implements a number of deep +protocol tests and defers or rejects all attempts to deliver mail. +The first test detects unauthorized SMTP command pipelining (an +SMTP client sends multiple commands, instead of sending one command +and waiting for the server response); a second deep protocol test +implements the Postfix SMTP server's smtpd_forbidden_commands feature +(a client sends commands such as CONNECT, GET, POST); and a third +deep protocol test detects spambots that send SMTP commands that +end in newline instead of carriage-return/newline. Real spambots +rarely make this mistake, but poorly-written software often does. + +Deep protocol tests are disabled by default, because the built-in +SMTP engine cannot not hand off the "live" connection from a good +SMTP client to a Postfix SMTP server process. To work around this, +postscreen(8) defers attempts to deliver mail with a 4XX status, +and waits for the client to disconnect. The next time a good client +connects, it will be allowed to talk to a Postfix SMTP server process +to deliver mail. + +[Feature 20100830] Postscreen DNSBL support is extended with optional +fixed-string filters, with optional integral weight factors, and +with an adjustable threshold to block SMTP clients with DNSBL score +>= that threshold. Reply filters will be implemented later. + +The updated postscreen configuration syntax is: + + postscreen_dnsbl_sites = domain[=ipaddr][*weight] ... + postscreen_dnsbl_threshold = score + +Elements inside [] are optional, ipaddr is an IPv4 address, and +weight and score are integral numbers. The [] are not part of the +postscreen_dnsbl_sites input. By default, weight and score are +equal to 1, and entries without filter will match any non-error +DNSBL reply. Use a negative weight value for whitelisting. + +Examples: + +To use example.com as a high-confidence blocklist, and to block +mail with example.net and example.org only when both agree, use: + + postscreen_dnsbl_threshold = 2 + postscreen_dnsbl_sites = example.com*2, example.net, example.org + +To filter only DNSBL replies containing 127.0.0.4, use: + + postscreen_dnsbl_sites = example.com=127.0.0.4 + +See also postconf(5) for the fine details. + +[Incompat 20100101] When periodic cache cleanup is enabled (the +default), the postscreen(8) server now requires that the cache +database supports the "delete" and "sequence" operations. To disable +periodic cache cleanup specify a zero postscreen_cache_cleanup_interval +value. + +[Feature 20100101] Periodic cache cleanup for the postscreen(8) +cache database. The time between cache cleanup runs is controlled +with the postscreen_cache_cleanup_interval (default: 12h) parameter. +Cache cleanup increases the database access latency, so this should +not be run more often than necessary. + +In addition, the postscreen_cache_retention_time (default: 1d) +parameter specifies how long to keep an expired entry in the cache. +This prevents a client from being logged as "NEW" after its record +expired only a little while ago. + +[Feature 20091008] Prototype postscreen(8) server that runs a number +of time-consuming checks in parallel for all incoming SMTP connections, +before clients are allowed to talk to a real Postfix SMTP server. +It detects clients that start talking too soon, or clients that +appear on DNS blocklists, or clients that hang up without sending +any command. + +By doing these checks in a single postscreen(8) process, Postfix +can avoid wasting one SMTP server process per connection. A side +benefit of postscreen(8)'s DNSBL lookups is that DNS records are +already cached before the Postfix SMTP server looks them up later. + +postscreen(8) maintains a temporary whitelist of positive decisions. +Once an SMTP client is whitelisted, it is immediately forwarded to +a real Postfix SMTP server process without further checking. + +By default, the program logs only statistics, and it does not run +any checks on clients in mynetworks (primarily, to avoid problems +with buggy SMTP implementations in network appliances). The logging +function alone is already useful for research. + |