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 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 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.
|