~ubuntu-branches/ubuntu/vivid/postfix/vivid-proposed

« back to all changes in this revision

Viewing changes to RELEASE_NOTES-2.7

  • Committer: Bazaar Package Importer
  • Author(s): LaMont Jones
  • Date: 2011-02-22 05:26:41 UTC
  • mto: (33.1.4 natty) (39.1.4 oneiric)
  • mto: This revision was merged to the branch mainline in revision 36.
  • Revision ID: james.westby@ubuntu.com-20110222052641-9kcxe1gt157c31j9
Tags: upstream-2.8.0
ImportĀ upstreamĀ versionĀ 2.8.0

Show diffs side-by-side

added added

removed removed

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