1The stable Postfix release is called postfix-2.7.x where 2=major
2release number, 7=minor release number, x=patchlevel.  The stable
3release never changes except for patches that address bugs or
4emergencies. Patches change the patchlevel and the release date.
5
6New features are developed in snapshot releases. These are called
7postfix-2.8-yyyymmdd where yyyymmdd is the release date (yyyy=year,
8mm=month, dd=day).  Patches are never issued for snapshot releases;
9instead, a new snapshot is released.
10
11The mail_release_date configuration parameter (format: yyyymmdd)
12specifies the release date of a stable release or snapshot release.
13
14If you upgrade from Postfix 2.5 or earlier, read RELEASE_NOTES-2.6
15before proceeding.
16
17Major changes - performance
18---------------------------
19
20[Feature 20100101] Periodic cache cleanup for the verify(8) cache
21database. The time between cache cleanup runs is controlled with
22the address_verify_cache_cleanup_interval (default: 12h) parameter.
23Cache cleanup increases the database access latency, so this should
24not be run more often than necessary.
25
26[Feature 20091109] Improved before-queue filter performance.  With
27"smtpd_proxy_options = speed_adjust", the Postfix SMTP server
28receives the entire message before it connects to a before-queue
29content filter. This means you can run more SMTP server processes
30with the same number of running content filter processes, and thus,
31handle more mail. This feature is off by default until it is proven
32to create no new problems.
33
34This addresses a concern of people in Europe who want to reject all
35bad mail with a before-queue filter. The alternative, an after-queue
36filter, means they would have to discard bad mail (which is illegal)
37or bounce bad mail (which violates good network citizenship).
38
39NOTE 1: When this feature is turned on, a filter cannot selectively
40reject recipients of a multi-recipient message.  It is OK to reject
41all recipients of the same multi-recipient message, as is deferring
42or accepting all recipients of the same multi-recipient message.
43
44NOTE 2: This feature increases the minimum amount of free queue
45space by $message_size_limit. The extra space is needed to save the
46message to a temporary file.
47
48To keep the performance overhead low, the same temporary file is
49reused with successive mail transactions (the file is of course
50truncated before reuse, so there is no information leakage).
51
52Major changes - sender reputation
53---------------------------------
54
55[Feature 20100117] The FILTER action in access maps or header/body_checks
56now supports sender reputation schemes that dynamically choose the
57SMTP source IP address. Typically, mail is split into classes, and
58all mail in class X is sent out from an SMTP client IP address that
59is reserved for class X.
60
61This is implemented by specifying FILTER actions with empty next-hop
62destinations in access maps or header/body_checks, and by configuring
63in master.cf one Postfix SMTP client for each SMTP source IP address,
64where each client has its own "-o myhostname" and "-o smtp_bind_address"
65settings.
66
67[Feature 20091209] sender_dependent_default_transport_maps, a
68per-sender override for default_transport. The original motivation
69is to use different output channels (with different source IP
70addresses) for different sender addresses, in order to keep their
71IP-based reputations separate from each other.
72
73The result value syntax is that of default_transport, not transport_maps.
74Thus, sender_dependent_default_transport_maps does not support the
75special transport_maps result value syntax for null transport, null
76nexthop, or null email address.
77
78This feature makes sender_dependent_relayhost_maps pretty much
79redundant (though sender_dependent_relayhost_maps will often be
80easier to use because that is the only thing people want to override).
81
82Major changes - address verification
83------------------------------------
84
85[Incompat 20100101] The verify(8) service now uses a persistent
86cache by default (address_verify_map = btree:$data_directory/verify_cache).
87To disable, specify "address_verify_map =" in main.cf.
88
89When periodic cache cleanup is enabled (the default), the verify(8)
90server now requires that the cache database supports the "delete"
91and "sequence" operations.  To disable periodic cache cleanup specify
92a zero address_verify_cache_cleanup_interval value.
93
94[Feature 20100101] Periodic cache cleanup for the verify(8) cache
95database. The time between cache cleanup runs is controlled with
96the address_verify_cache_cleanup_interval (default: 12h) parameter.
97Cache cleanup increases the database access latency, so this should
98not be run more often than necessary.
99
100Major changes - content filter
101------------------------------
102
103[Incompat 20100117] The meaning of an empty filter next-hop destination
104has changed (for example, "content_filter = foo:" or "FILTER foo:").
105Postfix now uses the recipient domain, instead of using $myhostname
106as in Postfix 2.6 and earlier.  To restore the old behavior specify
107"default_filter_nexthop = $myhostname", or specify a non-empty
108next-hop content filter destination.
109
110This compatibility option is not needed with SMTP-based content
111filters, because these always have an explicit next-hop destination.
112
113With pipe-based filters that specify no next-hop destination, the
114compatibility option restores the FIFO order of deliveries. Without
115the compatibility option, the delivery order for filters without
116next-hop destination changes to round-robin domain selection.
117
118[Feature 20100117] The FILTER action in access maps or header/body_checks
119now supports sender reputation schemes that dynamically choose the
120SMTP source IP address. Typically, mail is split into classes, and
121all mail in class X is sent out from an SMTP client IP address that
122is reserved for class X.
123
124This is implemented by specifying FILTER actions with empty next-hop
125destinations in access maps or header/body_checks, and by configuring
126in master.cf one Postfix SMTP client for each SMTP source IP address,
127where each client has its own "-o myhostname" and "-o smtp_bind_address"
128settings.
129
130[Feature 20091109] Improved before-queue filter performance.  With
131"smtpd_proxy_options = speed_adjust", the Postfix SMTP server
132receives the entire message before it connects to a before-queue
133content filter. This means you can run more SMTP server processes
134with the same number of running content filter processes, and thus,
135handle more mail. This feature is off by default until it is proven
136to create no new problems.
137
138This addresses a concern of people in Europe who want to reject all
139bad mail with a before-queue filter. The alternative, an after-queue
140filter, means they would have to discard bad mail (which is illegal)
141or bounce bad mail (which violates good network citizenship).
142
143NOTE 1: When this feature is turned on, a filter cannot selectively
144reject recipients of a multi-recipient message.  It is OK to reject
145all recipients of the same multi-recipient message, as is deferring
146or accepting all recipients of the same multi-recipient message.
147
148NOTE 2: This feature increases the minimum amount of free queue
149space by $message_size_limit. The extra space is needed to save the
150message to a temporary file.
151
152To keep the performance overhead low, the same temporary file is
153reused with successive mail transactions (the file is of course
154truncated before reuse, so there is no information leakage).
155
156Major changes - milter
157----------------------
158
159[Feature 20090606] Support for header checks on Milter-generated
160message headers.  This can be used, for example, to control mail
161flow with Milter-generated headers that carry indicators for badness
162or goodness. For details, see the postconf(5) section for
163"milter_header_checks". Currently, all header_checks features are
164implemented except PREPEND.  
165
166Major changes - multi-instance support
167--------------------------------------
168
169[Incompat 20090606] The "postmulti -e destroy" command no longer
170attempts to remove files that are created AFTER "postmulti -e
171create".  It still works as expected immediately after creating an
172instance by mistake.  Trying to automatically remove other files
173is too risky because Postfix-owned directories are by design not
174trusted.
175
176