1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
This is the Postfix 3.1 (stable) release.
The stable Postfix release is called postfix-3.1.x where 3=major
release number, 1=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.2-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.
Major changes - address verification safety
-------------------------------------------
[Feature 20151227] The new address_verify_pending_request_limit
parameter introduces a safety limit for the number of address
verification probes in the active queue. The default limit is 1/4
of the active queue maximum size. The queue manager enforces the
limit by tempfailing probe messages that exceed the limit. This
design avoids dependencies on global counters that get out of sync
after a process or system crash.
Tempfailing verify requests is not as bad as one might think. The
Postfix verify cache proactively updates active addresses weeks
before they expire. The address_verify_pending_request_limit affects
only unknown addresses, and inactive addresses that have expired
from the address verify cache (by default, after 31 days).
Major changes - json support
----------------------------
[Feature 20151129] Machine-readable, JSON-formatted queue listing
with "postqueue -j" (no "mailq" equivalent). The output is a stream
of JSON objects, one per queue file. To simplify parsing, each
JSON object is formatted as one text line followed by one newline
character. See the postqueue(1) manpage for a detailed description
of the output format.
Major changes - milter support
------------------------------
[Feature 20150523] The milter_macro_defaults feature provides an
optional list of macro name=value pairs. These specify default
values for Milter macros when no value is available from the SMTP
session context.
For example, with "milter_macro_defaults = auth_type=TLS", the
Postfix SMTP server will send an auth_type of "TLS" to a Milter,
unless the remote client authenticates with SASL.
This feature was originally implemented for a submission service
that may authenticate clients with a TLS certificate, without having
to make changes to the code that implements TLS support.
Major changes - output rate control
-----------------------------------
[Feature 20150710] Destination-independent delivery rate delay
Support to enforce a destination-independent delay between email
deliveries. The following example inserts 20 seconds of delay
between all 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.
Major changes - postscreen dnsbl
--------------------------------
[Feature 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
the default value for the new postscreen_dnsbl_max_ttl parameter.
Major changes - sasl auth safety
--------------------------------
[Feature 20151031] New "smtpd_client_auth_rate_limit" feature, to
enforce an optional rate limit on AUTH commands per SMTP client IP
address. Similar to other smtpd_client_*_rate_limit features, this
enforces a limit on the number of requests per $anvil_rate_time_unit.
Major changes - smtpd policy
----------------------------
[Feature 20150913] New SMTPD policy service attribute "policy_context",
with a corresponding "smtpd_policy_service_policy_context" configuration
parameter. Originally, this was implemented to share the same SMTPD
policy service endpoint among multiple check_policy_service clients.
Major changes - tls
-------------------
[Feature 20160207] A new "postfix tls" command to quickly enable
opportunistic TLS in the Postfix SMTP client or server, and to
manage SMTP server keys and certificates, including certificate
signing requests and TLSA DNS records for DANE. See the postfix-tls(1)
manpage for a detailed description.
[Feature 20160103] The Postfix SMTP client by default enables DANE
policies when an MX host has a (DNSSEC) secure TLSA DNS record,
even if the MX DNS record was obtained with insecure lookups. The
existence of a secure TLSA record implies that the host wants to
talk TLS and not plaintext. For details see the
smtp_tls_dane_insecure_mx_policy configuration parameter.
[Incompat 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.
[Incompat 20150719] The default Diffie-Hellman non-export prime was
updated from 1024 to 2048 bits, because SMTP clients are starting
to reject TLS handshakes with primes smaller than 2048 bits.
Historically, this prime size is not negotiable, and each site needs
to determine which prime size works best for the majority of its
clients. See FORWARD_SECRECY_README for some hints in the quick-start
section.
|
