| 1 | This document contains detailed information about incompatibilities that might |
| 2 | be encountered when upgrading from one release of Exim to another. The |
| 3 | information is in reverse order of release numbers. Mostly these are relatively |
| 4 | small points, and the configuration file is normally upwards compatible, but |
| 5 | there have been two big upheavals... |
| 6 | |
| 7 | |
| 8 | ************************************************************************** |
| 9 | * There was a big reworking of the way mail routing works for release * |
| 10 | * 4.00. Previously used "directors" were abolished, and all routing is * |
| 11 | * now done by routers. Policy controls for incoming mail are now done by * |
| 12 | * Access Control Lists instead of separate options. All this means that * |
| 13 | * pre-4.00 configuration files have to be massively converted. If you * |
| 14 | * are coming from a 3.xx release, please read the document in the file * |
| 15 | * doc/Exim4.upgrade, and allow some time to complete the upgrade. * |
| 16 | * * |
| 17 | * There was a big reworking of the way domain/host/net/address lists are * |
| 18 | * handled at release 3.00. If you are coming from a pre-3.00 release, it * |
| 19 | * might be easier to start again from a default configuration. Otherwise * |
| 20 | * you need to read doc/Exim3.upgrade and do a double conversion of your * |
| 21 | * configuration file. * |
| 22 | ************************************************************************** |
| 23 | |
| 24 | |
| 25 | The rest of this document contains information about changes in 4.xx releases |
| 26 | that might affect a running system. |
| 27 | |
| 28 | |
| 29 | Exim version 4.89 |
| 30 | ----------------- |
| 31 | |
| 32 | * SMTP CHUNKING in Exim 4.88 did not ensure that received mails had a final |
| 33 | newline; attempts to deliver such messages onwards to non-chunking hosts |
| 34 | would probably hang, as Exim does not insert the newline before a ".". |
| 35 | In 4.89, the newline is added upon receipt. For already-received messages |
| 36 | in your queue, try util/chunking_fixqueue_finalnewlines.pl |
| 37 | to walk the queue, fixing any affected messages. Note that because a |
| 38 | delivery attempt will be hanging, attempts to lock the messages for fixing |
| 39 | them will stall; stopping all queue-runners temporarily is recommended. |
| 40 | |
| 41 | * OpenSSL: oldest supported release series is now 1.0.2, which is the oldest |
| 42 | supported by the OpenSSL project. If you can build Exim with an older |
| 43 | release series, congratulations. If you can't, then upgrade. |
| 44 | The file doc/openssl.txt contains instructions for installing a current |
| 45 | OpenSSL outside the system library paths and building Exim to use it. |
| 46 | |
| 47 | * FreeBSD: we now always use the system iconv in libc, as all versions of |
| 48 | FreeBSD supported by the FreeBSD project provide this functionality. |
| 49 | |
| 50 | |
| 51 | Exim version 4.88 |
| 52 | ----------------- |
| 53 | |
| 54 | * The "demime" ACL condition, deprecated for the past 10 years, has |
| 55 | now been removed. |
| 56 | |
| 57 | * Old GnuTLS configuration options "gnutls_require_kx", "gnutls_require_mac", |
| 58 | and "gnutls_require_protocols" have now been removed. (Inoperative from |
| 59 | 4.80, per below; logging warnings since 4.83, again per below). |
| 60 | |
| 61 | |
| 62 | Exim version 4.83 |
| 63 | ----------------- |
| 64 | |
| 65 | * SPF condition results renamed "permerror" and "temperror". The old |
| 66 | names are still accepted for back-compatability, for this release. |
| 67 | |
| 68 | * TLS details are now logged on rejects, subject to log selectors. |
| 69 | |
| 70 | * Items in headers_remove lists must now have any embedded list-separators |
| 71 | doubled. |
| 72 | |
| 73 | * Attempted use of the deprecated options "gnutls_require_kx" et. al. |
| 74 | now result in logged warning. |
| 75 | |
| 76 | |
| 77 | Exim version 4.82 |
| 78 | ----------------- |
| 79 | |
| 80 | * New option gnutls_allow_auto_pkcs11 defaults false; if you have GnuTLS 2.12.0 |
| 81 | or later and do want PKCS11 modules to be autoloaded, then set this option. |
| 82 | |
| 83 | * A per-transport wait-<name> database is no longer updated if the transport |
| 84 | sets "connection_max_messages" to 1, as it can not be used and causes |
| 85 | unnecessary serialisation and load. External tools tracking the state of |
| 86 | Exim by the hints databases may need modification to take this into account. |
| 87 | |
| 88 | * The av_scanner option can now accept multiple clamd TCP targets, all other |
| 89 | setting limitations remain. |
| 90 | |
| 91 | |
| 92 | Exim version 4.80 |
| 93 | ----------------- |
| 94 | |
| 95 | * BEWARE backwards-incompatible changes in SSL libraries, thus the version |
| 96 | bump. See points below for details. |
| 97 | Also an LDAP data returned format change. |
| 98 | |
| 99 | * The value of $tls_peerdn is now print-escaped when written to the spool file |
| 100 | in a -tls_peerdn line, and unescaped when read back in. We received reports |
| 101 | of values with embedded newlines, which caused spool file corruption. |
| 102 | |
| 103 | If you have a corrupt spool file and you wish to recover the contents after |
| 104 | upgrading, then lock the message, replace the new-lines that should be part |
| 105 | of the -tls_peerdn line with the two-character sequence \n and then unlock |
| 106 | the message. No tool has been provided as we believe this is a rare |
| 107 | occurence. |
| 108 | |
| 109 | * For OpenSSL, SSLv2 is now disabled by default. (GnuTLS does not support |
| 110 | SSLv2). RFC 6176 prohibits SSLv2 and some informal surveys suggest no |
| 111 | actual usage. You can re-enable with the "openssl_options" Exim option, |
| 112 | in the main configuration section. Note that supporting SSLv2 exposes |
| 113 | you to ciphersuite downgrade attacks. |
| 114 | |
| 115 | * With OpenSSL 1.0.1+, Exim now supports TLS 1.1 and TLS 1.2. If built |
| 116 | against 1.0.1a then you will get a warning message and the |
| 117 | "openssl_options" value will not parse "no_tlsv1_1": the value changes |
| 118 | incompatibly between 1.0.1a and 1.0.1b, because the value chosen for 1.0.1a |
| 119 | is infelicitous. We advise avoiding 1.0.1a. |
| 120 | |
| 121 | "openssl_options" gains "no_tlsv1_1", "no_tlsv1_2" and "no_compression". |
| 122 | |
| 123 | COMPATIBILITY WARNING: The default value of "openssl_options" is no longer |
| 124 | "+dont_insert_empty_fragments". We default to "+no_sslv2". |
| 125 | That old default was grandfathered in from before openssl_options became a |
| 126 | configuration option. |
| 127 | Empty fragments are inserted by default through TLS1.0, to partially defend |
| 128 | against certain attacks; TLS1.1+ change the protocol so that this is not |
| 129 | needed. The DIEF SSL option was required for some old releases of mail |
| 130 | clients which did not gracefully handle the empty fragments, and was |
| 131 | initially set in Exim release 4.31 (see ChangeLog, item 37). |
| 132 | |
| 133 | If you still have affected mail-clients, and you see SSL protocol failures |
| 134 | with this release of Exim, set: |
| 135 | openssl_options = +dont_insert_empty_fragments |
| 136 | in the main section of your Exim configuration file. You're trading off |
| 137 | security for compatibility. Exim is now defaulting to higher security and |
| 138 | rewarding more modern clients. |
| 139 | |
| 140 | If the option tls_dhparams is set and the parameters loaded from the file |
| 141 | have a bit-count greater than the new option tls_dh_max_bits, then the file |
| 142 | will now be ignored. If this affects you, raise the tls_dh_max_bits limit. |
| 143 | We suspect that most folks are using dated defaults and will not be affected. |
| 144 | |
| 145 | * Ldap lookups returning multi-valued attributes now separate the attributes |
| 146 | with only a comma, not a comma-space sequence. Also, an actual comma within |
| 147 | a returned attribute is doubled. This makes it possible to parse the |
| 148 | attribute as a comma-separated list. Note the distinction from multiple |
| 149 | attributes being returned, where each one is a name=value pair. |
| 150 | |
| 151 | If you are currently splitting the results from LDAP upon a comma, then you |
| 152 | should check carefully to see if adjustments are needed. |
| 153 | |
| 154 | This change lets cautious folks distinguish "comma used as separator for |
| 155 | joining values" from "comma inside the data". |
| 156 | |
| 157 | * accept_8bitmime now defaults on, which is not RFC compliant but is better |
| 158 | suited to today's Internet. See http://cr.yp.to/smtp/8bitmime.html for a |
| 159 | sane rationale. Those who wish to be strictly RFC compliant, or know that |
| 160 | they need to talk to servers that are not 8-bit-clean, now need to take |
| 161 | explicit configuration action to default this option off. This is not a |
| 162 | new option, you can safely force it off before upgrading, to decouple |
| 163 | configuration changes from the binary upgrade while remaining RFC compliant. |
| 164 | |
| 165 | * The GnuTLS support has been mostly rewritten, to use APIs which don't cause |
| 166 | deprecation warnings in GnuTLS 2.12.x. As part of this, these three options |
| 167 | are no longer supported: |
| 168 | |
| 169 | gnutls_require_kx |
| 170 | gnutls_require_mac |
| 171 | gnutls_require_protocols |
| 172 | |
| 173 | Their functionality is entirely subsumed into tls_require_ciphers. In turn, |
| 174 | tls_require_ciphers is no longer an Exim list and is not parsed by Exim, but |
| 175 | is instead given to gnutls_priority_init(3), which expects a priority string; |
| 176 | this behaviour is much closer to the OpenSSL behaviour. See: |
| 177 | |
| 178 | http://www.gnutls.org/manual/html_node/Priority-Strings.html |
| 179 | |
| 180 | for fuller documentation of the strings parsed. The three gnutls_require_* |
| 181 | options are still parsed by Exim and, for this release, silently ignored. |
| 182 | A future release will add warnings, before a later still release removes |
| 183 | parsing entirely and the presence of the options will be a configuration |
| 184 | error. |
| 185 | |
| 186 | Note that by default, GnuTLS will not accept RSA-MD5 signatures in chains. |
| 187 | A tls_require_ciphers value of NORMAL:%VERIFY_ALLOW_SIGN_RSA_MD5 may |
| 188 | re-enable support, but this is not supported by the Exim maintainers. |
| 189 | Our test suite no longer includes MD5-based certificates. |
| 190 | |
| 191 | This rewrite means that Exim will continue to build against GnuTLS in the |
| 192 | future, brings Exim closer to other GnuTLS applications and lets us add |
| 193 | support for SNI and other features more readily. We regret that it wasn't |
| 194 | feasible to retain the three dropped options. |
| 195 | |
| 196 | * If built with TLS support, then Exim will now validate the value of |
| 197 | the main section tls_require_ciphers option at start-up. Before, this |
| 198 | would cause a STARTTLS 4xx failure, now it causes a failure to start. |
| 199 | Running with a broken configuration which causes failures that may only |
| 200 | be left in the logs has been traded off for something more visible. This |
| 201 | change makes an existing problem more prominent, but we do not believe |
| 202 | anyone would deliberately be running with an invalid tls_require_ciphers |
| 203 | option. |
| 204 | |
| 205 | This also means that library linkage issues caused by conflicts of some |
| 206 | kind might take out the main daemon, not just the delivery or receiving |
| 207 | process. Conceivably some folks might prefer to continue delivering |
| 208 | mail plaintext when their binary is broken in this way, if there is a |
| 209 | server that is a candidate to receive such mails that does not advertise |
| 210 | STARTTLS. Note that Exim is typically a setuid root binary and given |
| 211 | broken linkage problems that cause segfaults, we feel it is safer to |
| 212 | fail completely. (The check is not done as root, to ensure that problems |
| 213 | here are not made worse by the check). |
| 214 | |
| 215 | * The "tls_dhparam" option has been updated, so that it can now specify a |
| 216 | path or an identifier for a standard DH prime from one of a few RFCs. |
| 217 | The default for OpenSSL is no longer to not use DH but instead to use |
| 218 | one of these standard primes. The default for GnuTLS is no longer to use |
| 219 | a file in the spool directory, but to use that same standard prime. |
| 220 | The option is now used by GnuTLS too. If it points to a path, then |
| 221 | GnuTLS will use that path, instead of a file in the spool directory; |
| 222 | GnuTLS will attempt to create it if it does not exist. |
| 223 | |
| 224 | To preserve the previous behaviour of generating files in the spool |
| 225 | directory, set "tls_dhparam = historic". Since prior releases of Exim |
| 226 | ignored tls_dhparam when using GnuTLS, this can safely be done before |
| 227 | the upgrade. |
| 228 | |
| 229 | |
| 230 | |
| 231 | Exim version 4.77 |
| 232 | ----------------- |
| 233 | |
| 234 | * GnuTLS will now attempt to use TLS 1.2 and TLS 1.1 before TLS 1.0 and SSL3, |
| 235 | if supported by your GnuTLS library. Use the existing |
| 236 | "gnutls_require_protocols" option to downgrade this if that will be a |
| 237 | problem. Prior to this release, supported values were "TLS1" and "SSL3", |
| 238 | so you should be able to update configuration prior to update. |
| 239 | |
| 240 | [nb: gnutls_require_protocols removed in Exim 4.80, instead use |
| 241 | tls_require_ciphers to provide a priority string; see notes above] |
| 242 | |
| 243 | * The match_<type>{string1}{string2} expansion conditions no longer subject |
| 244 | string2 to string expansion, unless Exim was built with the new |
| 245 | "EXPAND_LISTMATCH_RHS" option. Too many people have inadvertently created |
| 246 | insecure configurations that way. If you need the functionality and turn on |
| 247 | that build option, please let the developers know, and know why, so we can |
| 248 | try to provide a safer mechanism for you. |
| 249 | |
| 250 | The match{}{} expansion condition (for regular expressions) is NOT affected. |
| 251 | For match_<type>{s1}{s2}, all list functionality is unchanged. The only |
| 252 | change is that a '$' appearing in s2 will not trigger expansion, but instead |
| 253 | will be treated as a literal $ sign; the effect is very similar to having |
| 254 | wrapped s2 with \N...\N. If s2 contains a named list and the list definition |
| 255 | uses $expansions then those _will_ be processed as normal. It is only the |
| 256 | point at which s2 is read where expansion is inhibited. |
| 257 | |
| 258 | If you are trying to test if two email addresses are equal, use eqi{s1}{s2}. |
| 259 | If you are testing if the address in s1 occurs in the list of items given |
| 260 | in s2, either use the new inlisti{s1}{s2} condition (added in 4.77) or use |
| 261 | the pre-existing forany{s2}{eqi{$item}{s1}} condition. |
| 262 | |
| 263 | |
| 264 | Exim version 4.74 |
| 265 | ----------------- |
| 266 | |
| 267 | * The integrated support for dynamically loadable lookup modules has an ABI |
| 268 | change from the modules supported by some OS vendors through an unofficial |
| 269 | patch. Don't try to mix & match. |
| 270 | |
| 271 | * Some parts of the build system are now beginning to assume that the host |
| 272 | environment is POSIX. If you're building on a system where POSIX tools are |
| 273 | not the default, you might have an easier time if you switch to the POSIX |
| 274 | tools. Feel free to report non-POSIX issues as a request for a feature |
| 275 | enhancement, but if the POSIX variants are available then the fix will |
| 276 | probably just involve some coercion. See the README instructions for |
| 277 | building on such hosts. |
| 278 | |
| 279 | |
| 280 | Exim version 4.73 |
| 281 | ----------------- |
| 282 | |
| 283 | * The Exim run-time user can no longer be root; this was always |
| 284 | strongly discouraged, but is now prohibited both at build and |
| 285 | run-time. If you need Exim to run routinely as root, you'll need to |
| 286 | patch the source and accept the risk. Here be dragons. |
| 287 | |
| 288 | * Exim will no longer accept a configuration file owned by the Exim |
| 289 | run-time user, unless that account is explicitly the value in |
| 290 | CONFIGURE_OWNER, which we discourage. Exim now checks to ensure that |
| 291 | files are not writeable by other accounts. |
| 292 | |
| 293 | * The ALT_CONFIG_ROOT_ONLY build option is no longer optional and is forced |
| 294 | on; the Exim user can, by default, no longer use -C/-D and retain privilege. |
| 295 | Two new build options mitigate this. |
| 296 | |
| 297 | * TRUSTED_CONFIG_LIST defines a file containing a whitelist of config |
| 298 | files that are trusted to be selected by the Exim user; one per line. |
| 299 | This is the recommended approach going forward. |
| 300 | |
| 301 | * WHITELIST_D_MACROS defines a colon-separated list of macro names which |
| 302 | the Exim run-time user may safely pass without dropping privileges. |
| 303 | Because changes to this involve a recompile, this is not the recommended |
| 304 | approach but may ease transition. The values of the macros, when |
| 305 | overridden, are constrained to match this regex: ^[A-Za-z0-9_/.-]*$ |
| 306 | |
| 307 | * The system_filter_user option now defaults to the Exim run-time user, |
| 308 | rather than root. You can still set it explicitly to root and this |
| 309 | can be done with prior versions too, letting you roll versions |
| 310 | without needing to change this configuration option. |
| 311 | |
| 312 | * ClamAV must be at least version 0.95 unless WITH_OLD_CLAMAV_STREAM is |
| 313 | defined at build time. |
| 314 | |
| 315 | |
| 316 | Exim version 4.70 |
| 317 | ----------------- |
| 318 | |
| 319 | 1. Experimental Yahoo! Domainkeys support has been dropped in this release. |
| 320 | It has been superceded by a native implementation of its successor DKIM. |
| 321 | |
| 322 | 2. Up to version 4.69, Exim came with an embedded version of the PCRE library. |
| 323 | As of 4.70, this is no longer the case. To compile Exim, you will need PCRE |
| 324 | installed. Most OS distributions have ready-made library and development |
| 325 | packages. |
| 326 | |
| 327 | |
| 328 | Exim version 4.68 |
| 329 | ----------------- |
| 330 | |
| 331 | 1. The internal implementation of the database keys that are used for ACL |
| 332 | ratelimiting has been tidied up. This means that an update to 4.68 might cause |
| 333 | Exim to "forget" previous rates that it had calculated, and reset them to zero. |
| 334 | |
| 335 | |
| 336 | Exim version 4.64 |
| 337 | ----------------- |
| 338 | |
| 339 | 1. Callouts were setting the name used for EHLO/HELO from $smtp_active_ |
| 340 | hostname. This is wrong, because it relates to the incoming message (and |
| 341 | probably the interface on which it is arriving) and not to the outgoing |
| 342 | callout (which could be using a different interface). This has been |
| 343 | changed to use the value of the helo_data option from the smtp transport |
| 344 | instead - this is what is used when a message is actually being sent. If |
| 345 | there is no remote transport (possible with a router that sets up host |
| 346 | addresses), $smtp_active_hostname is used. This change is mentioned here in |
| 347 | case somebody is relying on the use of $smtp_active_hostname. |
| 348 | |
| 349 | 2. A bug has been fixed that might just possibly be something that is relied on |
| 350 | in some configurations. In expansion items such as ${if >{xxx}{yyy}...} an |
| 351 | empty string (that is {}) was being interpreted as if it was {0} and therefore |
| 352 | treated as the number zero. From release 4.64, such strings cause an error |
| 353 | because a decimal number, possibly followed by K or M, is required (as has |
| 354 | always been documented). |
| 355 | |
| 356 | 3. There has been a change to the GnuTLS support (ChangeLog/PH/20) to improve |
| 357 | Exim's performance. Unfortunately, this has the side effect of being slightly |
| 358 | non-upwards compatible for versions 4.50 and earlier. If you are upgrading from |
| 359 | one of these earlier versions and you use GnuTLS, you must remove the file |
| 360 | called gnutls-params in Exim's spool directory. If you don't do this, you will |
| 361 | see this error: |
| 362 | |
| 363 | TLS error on connection from ... (DH params import): Base64 decoding error. |
| 364 | |
| 365 | Removing the file causes Exim to recompute the relevant encryption parameters |
| 366 | and cache them in the new format that was introduced for release 4.51 (May |
| 367 | 2005). If you are upgrading from release 4.51 or later, there should be no |
| 368 | problem. |
| 369 | |
| 370 | |
| 371 | Exim version 4.63 |
| 372 | ----------------- |
| 373 | |
| 374 | When an SMTP error message is specified in a "message" modifier in an ACL, or |
| 375 | in a :fail: or :defer: message in a redirect router, Exim now checks the start |
| 376 | of the message for an SMTP error code. This consists of three digits followed |
| 377 | by a space, optionally followed by an extended code of the form n.n.n, also |
| 378 | followed by a space. If this is the case and the very first digit is the same |
| 379 | as the default error code, the code from the message is used instead. If the |
| 380 | very first digit is incorrect, a panic error is logged, and the default code is |
| 381 | used. This is an incompatible change, but it is not expected to affect many (if |
| 382 | any) configurations. It is possible to suppress the use of the supplied code in |
| 383 | a redirect router by setting the smtp_error_code option false. In this case, |
| 384 | any SMTP code is quietly ignored. |
| 385 | |
| 386 | |
| 387 | Exim version 4.61 |
| 388 | ----------------- |
| 389 | |
| 390 | 1. The default number of ACL variables of each type has been increased to 20, |
| 391 | and it's possible to compile Exim with more. You can safely upgrade to this |
| 392 | release if you already have messages on the queue with saved ACL variable |
| 393 | values. However, if you downgrade from this release with messages on the queue, |
| 394 | any saved ACL values they may have will be lost. |
| 395 | |
| 396 | 2. The default value for rfc1413_query_timeout has been changed from 30s to 5s. |
| 397 | |
| 398 | |
| 399 | Exim version 4.54 |
| 400 | ----------------- |
| 401 | |
| 402 | There was a problem with 4.52/TF/02 in that a "name=" option on control= |
| 403 | submission terminated at the next slash, thereby not allowing for slashes in |
| 404 | the name. This has been changed so that "name=" takes the rest of the string as |
| 405 | its data. It must therefore be the last option. |
| 406 | |
| 407 | |
| 408 | Version 4.53 |
| 409 | ------------ |
| 410 | |
| 411 | If you are using the experimental Domain Keys support, you must upgrade to |
| 412 | at least libdomainkeys 0.67 in order to run this release of Exim. |
| 413 | |
| 414 | |
| 415 | Version 4.51 |
| 416 | ------------ |
| 417 | |
| 418 | 1. The format in which GnuTLS parameters are cached (in the file gnutls-params |
| 419 | in the spool directory) has been changed. The new format can also be generated |
| 420 | externally, so it is now possible to update the values from outside Exim. This |
| 421 | has been implemented in an upwards, BUT NOT downwards, compatible manner. |
| 422 | Upgrading should be seamless: when Exim finds that it cannot understand an |
| 423 | existing cache file, it generates new parameters and writes them to the cache |
| 424 | in the new format. If, however, you downgrade from 4.51 to a previous release, |
| 425 | you MUST delete the gnutls-params file in the spool directory, because the |
| 426 | older Exim will not recognize the new format. |
| 427 | |
| 428 | 2. When doing a callout as part of verifying an address, Exim was not paying |
| 429 | attention to any local part prefix or suffix that was matched by the router |
| 430 | that accepted the address. It now behaves in the same way as it does for |
| 431 | delivery: the affixes are removed from the local part unless |
| 432 | rcpt_include_affixes is set on the transport. If you have a configuration that |
| 433 | uses prefixes or suffixes on addresses that could be used for callouts, and you |
| 434 | want the affixes to be retained, you must make sure that rcpt_include_affixes |
| 435 | is set on the transport. |
| 436 | |
| 437 | 3. Bounce and delay warning messages no longer contain details of delivery |
| 438 | errors, except for explicit messages (e.g. generated by :fail:) and SMTP |
| 439 | responses from remote hosts. |
| 440 | |
| 441 | |
| 442 | Version 4.50 |
| 443 | ------------ |
| 444 | |
| 445 | The exicyclog script has been updated to use three-digit numbers in rotated log |
| 446 | files if the maximum number to keep is greater than 99. If you are already |
| 447 | keeping more than 99, there will be an incompatible change when you upgrade. |
| 448 | You will probably want to rename your old log files to the new form before |
| 449 | running the new exicyclog. |
| 450 | |
| 451 | |
| 452 | Version 4.42 |
| 453 | ------------ |
| 454 | |
| 455 | RFC 3848 specifies standard names for the "with" phrase in Received: header |
| 456 | lines when AUTH and/or TLS are in use. This is the "received protocol" |
| 457 | field. Exim used to use "asmtp" for authenticated SMTP, without any |
| 458 | indication (in the protocol name) for TLS use. Now it follows the RFC and |
| 459 | uses "esmtpa" if the connection is authenticated, "esmtps" if it is |
| 460 | encrypted, and "esmtpsa" if it is both encrypted and authenticated. These names |
| 461 | appear in log lines as well as in Received: header lines. |
| 462 | |
| 463 | |
| 464 | Version 4.34 |
| 465 | ------------ |
| 466 | |
| 467 | Change 4.31/2 gave problems to data ACLs and local_scan() functions that |
| 468 | expected to see a Received: header. I have changed to yet another scheme. The |
| 469 | Received: header is now generated after the body is received, but before the |
| 470 | ACL or local_scan() is called. After they have run, the timestamp in the |
| 471 | Received: header is updated. |
| 472 | |
| 473 | Thus, change (a) of 4.31/2 has been reversed, but change (b) is still true, |
| 474 | which is lucky, since I decided it was a bug fix. |
| 475 | |
| 476 | |
| 477 | Version 4.33 |
| 478 | ------------ |
| 479 | |
| 480 | If an expansion in a condition on a "warn" statement fails because a lookup |
| 481 | defers, the "warn" statement is abandoned, and the next ACL statement is |
| 482 | processed. Previously this caused the whole ACL to be aborted. |
| 483 | |
| 484 | |
| 485 | Version 4.32 |
| 486 | ------------ |
| 487 | |
| 488 | Change 4.31/2 has been reversed, as it proved contentious. Recipient callout |
| 489 | verification now uses <> in the MAIL command by default, as it did before. A |
| 490 | new callout option, "use_sender", has been added to request the other |
| 491 | behaviour. |
| 492 | |
| 493 | |
| 494 | Version 4.31 |
| 495 | ------------ |
| 496 | |
| 497 | 1. If you compile Exim to use GnuTLS, it now requires the use of release 1.0.0 |
| 498 | or greater. The interface to the obsolete 0.8.x releases is no longer |
| 499 | supported. There is one externally visible change: the format for the |
| 500 | display of Distinguished Names now uses commas as a separator rather than a |
| 501 | slash. This is to comply with RFC 2253. |
| 502 | |
| 503 | 2. When a message is received, the Received: header line is now generated when |
| 504 | reception is complete, instead of at the start of reception. For messages |
| 505 | that take a long time to come in, this changes the meaning of the timestamp. |
| 506 | There are several side-effects of this change: |
| 507 | |
| 508 | (a) If a message is rejected by a DATA or non-SMTP ACL, or by local_scan(), |
| 509 | the logged header lines no longer include the local Received: line, |
| 510 | because it has not yet been created. If the message is a non-SMTP one, |
| 511 | and the error is processed by sending a message to the sender, the copy |
| 512 | of the original message that is returned does not have an added |
| 513 | Received: line. |
| 514 | |
| 515 | (b) When a filter file is tested using -bf, no additional Received: header |
| 516 | is added to the test message. After some thought, I decided that this |
| 517 | is a bug fix. |
| 518 | |
| 519 | The contents of $received_for are not affected by this change. This |
| 520 | variable still contains the single recipient of a message, copied after |
| 521 | addresses have been rewritten, but before local_scan() is run. |
| 522 | |
| 523 | 2. Recipient callout verification, like sender verification, was using <> in |
| 524 | the MAIL FROM command. This isn't really the right thing, since the actual |
| 525 | sender may affect whether the remote host accepts the recipient or not. I |
| 526 | have changed it to use the actual sender in the callout; this means that |
| 527 | the cache record is now keyed on a recipient/sender pair, not just the |
| 528 | recipient address. There doesn't seem to be a real danger of callout loops, |
| 529 | since a callout by the remote host to check the sender would use <>. |
| 530 | |
| 531 | |
| 532 | Version 4.30 |
| 533 | ------------ |
| 534 | |
| 535 | 1. I have abolished timeout_DNS as an error that can be detected in retry |
| 536 | rules, because it has never worked. Despite the fact that it has been |
| 537 | documented since at least release 1.62, there was no code to support it. |
| 538 | If you have used it in your retry rules, you will now get a warning message |
| 539 | to the log and panic log. It is now treated as plain "timeout". |
| 540 | |
| 541 | 2. After discussion on the mailing list, Exim no longer adds From:, Date:, or |
| 542 | Message-Id: header lines to messages that do not originate locally, that is, |
| 543 | messages that have an associated sending host address. |
| 544 | |
| 545 | 3. When looking up a host name from an IP address, Exim now tries the DNS |
| 546 | first, and only if that fails does it use gethostbyaddr() (or equivalent). |
| 547 | This change was made because on some OS, not all the names are given for |
| 548 | addresses with multiple PTR records via the gethostbyaddr() interface. The |
| 549 | order of lookup can be changed by setting host_lookup_order. |
| 550 | |
| 551 | |
| 552 | Version 4.23 |
| 553 | ------------ |
| 554 | |
| 555 | 1. The new FIXED_NEVER_USERS build-time option creates a list of "never users" |
| 556 | that cannot be overridden. The default in the distributed EDITME is "root". |
| 557 | If for some reason you were (against advice) running deliveries as root, you |
| 558 | will have to ensure that FIXED_NEVER_USERS is not set in your |
| 559 | Local/Makefile. |
| 560 | |
| 561 | 2. The ${quote: operator now quotes an empty string, which it did not before. |
| 562 | |
| 563 | 3. Version 4.23 saves the contents of the ACL variables with the message, so |
| 564 | that they can be used later. If one of these variables contains a newline, |
| 565 | there will be a newline character in the spool that will not be interpreted |
| 566 | correctly by a previous version of Exim. (Exim ignores keyed spool file |
| 567 | items that it doesn't understand - precisely for this kind of problem - but |
| 568 | it expects them all to be on one line.) |
| 569 | |
| 570 | So the bottom line is: if you have newlines in your ACL variables, you |
| 571 | cannot retreat from 4.23. |
| 572 | |
| 573 | |
| 574 | Version 4.21 |
| 575 | ------------ |
| 576 | |
| 577 | 1. The idea of the "warn" ACL verb is that it adds a header or writes to the |
| 578 | log only when "message" or "log_message" are set. However, if one of the |
| 579 | conditions was an address verification, or a call to a nested ACL, the |
| 580 | messages generated by the underlying test were being passed through. This |
| 581 | no longer happens. The underlying message is available in $acl_verify_ |
| 582 | message for both "message" and "log_message" expansions, so it can be |
| 583 | passed through if needed. |
| 584 | |
| 585 | 2. The way that the $h_ (and $header_) expansions work has been changed by the |
| 586 | addition of RFC 2047 decoding. See the main documentation (the NewStuff file |
| 587 | until release 4.30, then the manual) for full details. Briefly, there are |
| 588 | now three forms: |
| 589 | |
| 590 | $rh_xxx: and $rheader_xxx: give the original content of the header |
| 591 | line(s), with no processing at all. |
| 592 | |
| 593 | $bh_xxx: and $bheader_xxx: remove leading and trailing white space, and |
| 594 | then decode base64 or quoted-printable "words" within the header text, |
| 595 | but do not do charset translation. |
| 596 | |
| 597 | $h_xxx: and $header_xxx: attempt to translate the $bh_ string to a |
| 598 | standard character set. |
| 599 | |
| 600 | If you have previously been using $h_ expansions to access the raw |
| 601 | characters, you should change to $rh_ instead. |
| 602 | |
| 603 | 3. When Exim creates an RFC 2047 encoded word in a header line, it labels it |
| 604 | with the default character set from the headers_charset option instead of |
| 605 | always using iso-8859-1. |
| 606 | |
| 607 | 4. If TMPDIR is defined in Local/Makefile (default in src/EDITME is |
| 608 | TMPDIR="/tmp"), Exim checks for the presence of an environment variable |
| 609 | called TMPDIR, and if it finds it is different, it changes its value. |
| 610 | |
| 611 | 5. Following a discussion on the list, the rules by which Exim recognises line |
| 612 | endings on incoming messages have been changed. The -dropcr and drop_cr |
| 613 | options are now no-ops, retained only for backwards compatibility. The |
| 614 | following line terminators are recognized: LF CRLF CR. However, special |
| 615 | processing applies to CR: |
| 616 | |
| 617 | (i) The sequence CR . CR does *not* terminate an incoming SMTP message, |
| 618 | nor a local message in the state where . is a terminator. |
| 619 | |
| 620 | (ii) If a bare CR is encountered in a header line, an extra space is added |
| 621 | after the line terminator so as not to end the header. The reasoning |
| 622 | behind this is that bare CRs in header lines are most likely either |
| 623 | to be mistakes, or people trying to play silly games. |
| 624 | |
| 625 | 6. The code for using daemon_smtp_port, local_interfaces, and the -oX options |
| 626 | has been reorganized. It is supposed to be backwards compatible, but it is |
| 627 | mentioned here just in case I've screwed up. |
| 628 | |
| 629 | |
| 630 | |
| 631 | Version 4.20 |
| 632 | ------------ |
| 633 | |
| 634 | 1. I have tidied and re-organized the code that uses alarm() for imposing time |
| 635 | limits on various things. It shouldn't affect anything, but if you notice |
| 636 | processes getting stuck, it may be that I've broken something. |
| 637 | |
| 638 | 2. The "arguments" log selector now also logs the current working directory |
| 639 | when Exim is called. |
| 640 | |
| 641 | 3. An incompatible change has been made to the appendfile transport. This |
| 642 | affects the case when it is used for file deliveries that are set up by |
| 643 | .forward and filter files. Previously, any settings of the "file" or |
| 644 | "directory" options were ignored. It is hoped that, like the address_file |
| 645 | transport in the default configuration, these options were never in fact set |
| 646 | on such transports, because they were of no use. |
| 647 | |
| 648 | Now, if either of these options is set, it is used. The path that is passed |
| 649 | by the router is in $address_file (this is not new), so it can be used as |
| 650 | part of a longer path, or modified in any other way that expansion permits. |
| 651 | |
| 652 | If neither "file" nor "directory" is set, the behaviour is unchanged. |
| 653 | |
| 654 | 4. Related to the above: in a filter, if a "save" command specifies a non- |
| 655 | absolute path, the value of $home/ is pre-pended. This no longer happens if |
| 656 | $home is unset or is set to an empty string. |
| 657 | |
| 658 | 5. Multiple file deliveries from a filter or .forward file can never be |
| 659 | batched; the value of batch_max on the transport is ignored for file |
| 660 | deliveries. I'm assuming that nobody ever actually set batch_max on the |
| 661 | address_file transport - it would have had odd effects previously. |
| 662 | |
| 663 | 6. DESTDIR is the more common variable that ROOT for use when installing |
| 664 | software under a different root filing system. The Exim install script now |
| 665 | recognizes DESTDIR first; if it is not set, ROOT is used. |
| 666 | |
| 667 | 7. If DESTDIR is set when installing Exim, it no longer prepends its value to |
| 668 | the path of the system aliases file that appears in the default |
| 669 | configuration (when a default configuration is installed). If an aliases |
| 670 | file is actually created, its name *does* use the prefix. |
| 671 | |
| 672 | |
| 673 | Version 4.14 |
| 674 | ------------ |
| 675 | |
| 676 | 1. The default for the maximum number of unknown SMTP commands that Exim will |
| 677 | accept before dropping a connection has been reduced from 5 to 3. However, you |
| 678 | can now change the value by setting smtp_max_unknown_commands. |
| 679 | |
| 680 | 2. The ${quote: operator has been changed so that it turns newline and carriage |
| 681 | return characters into \n and \r, respectively. |
| 682 | |
| 683 | 3. The file names used for maildir messages now include the microsecond time |
| 684 | fraction as well as the time in seconds, to cope with systems where the process |
| 685 | id can be re-used within the same second. The format is now |
| 686 | |
| 687 | <time>.H<microsec>P<pid>.<host> |
| 688 | |
| 689 | This should be a compatible change, but is noted here just in case. |
| 690 | |
| 691 | 4. The rules for creating message ids have changed, to cope with systems where |
| 692 | the process id can be re-used within the same second. The format, however, is |
| 693 | unchanged, so this should not cause any problems, except as noted in the next |
| 694 | item. |
| 695 | |
| 696 | 5. The maximum value for localhost_number has been reduced from 255 to 16, in |
| 697 | order to implement the new message id rules. For operating systems that have |
| 698 | case-insensitive file systems (Cygwin and Darwin), the limit is 10. |
| 699 | |
| 700 | 6. verify = header_syntax was allowing unqualified addresses in all cases. Now |
| 701 | it allows them only for locally generated messages and from hosts that match |
| 702 | sender_unqualified_hosts or recipient_unqualified_hosts, respectively. |
| 703 | |
| 704 | 7. For reasons lost in the mists of time, when a pipe transport was run, the |
| 705 | environment variable MESSAGE_ID was set to the message ID preceded by 'E' (the |
| 706 | form used in Message-ID: header lines). The 'E' has been removed. |
| 707 | |
| 708 | |
| 709 | Version 4.11 |
| 710 | ------------ |
| 711 | |
| 712 | 1. The handling of lines in the configuration file has changed. Previously, |
| 713 | macro expansion was applied to logical lines, after continuations had been |
| 714 | joined on. This meant that it could not be used in .include lines, which are |
| 715 | handled as physical rather than logical lines. Macro expansion is now done on |
| 716 | physical lines rather than logical lines. This means there are two |
| 717 | incompatibilities: |
| 718 | |
| 719 | (a) A macro that expands to # to turn a line into a comment now applies only |
| 720 | to the physical line where it appears. Previously, it would have caused |
| 721 | any following continuations also to be ignored. |
| 722 | |
| 723 | (b) A macro name can no longer be split over the boundary between a line and |
| 724 | its continuation. Actually, this is more of a bug fix. :-) |
| 725 | |
| 726 | 2. The -D command line option must now all be within one command line item. |
| 727 | This makes it possible to use -D to set a macro to the empty string by commands |
| 728 | such as |
| 729 | |
| 730 | exim -DABC ... |
| 731 | exim -DABC= ... |
| 732 | |
| 733 | Previously, these items would have moved on to the next item on the command |
| 734 | line. To include spaces in a macro definition item, quotes must be used, in |
| 735 | which case you can also have spaces after -D and surrounding the equals. For |
| 736 | example: |
| 737 | |
| 738 | exim '-D ABC = something' ... |
| 739 | |
| 740 | 3. The way that addresses that redirect to themselves are handled has been |
| 741 | changed, in order to fix an obscure bug. This should not cause any problems |
| 742 | except in the case of wanting to go back from a 4.11 (or later) release to an |
| 743 | earlier release. If there are undelivered messages on the spool that contain |
| 744 | addresses which redirect to themselves, and the redirected addresses have |
| 745 | already been delivered, you might get a duplicate delivery if you revert to an |
| 746 | earlier Exim. |
| 747 | |
| 748 | 4. The default way of looking up IP addresses for hosts in the manualroute and |
| 749 | queryprogram routers has been changed. If "byname" or "bydns" is explicitly |
| 750 | specified, there is no change, but if no method is specified, Exim now behaves |
| 751 | as follows: |
| 752 | |
| 753 | First, a DNS lookup is done. If this yields anything other than |
| 754 | HOST_NOT_FOUND, that result is used. Otherwise, Exim goes on to try a call to |
| 755 | getipnodebyname() (or gethostbyname() on older systems) and the result of the |
| 756 | lookup is the result of that call. |
| 757 | |
| 758 | This change has been made because it has been discovered that on some systems, |
| 759 | if a DNS lookup called via getipnodebyname() times out, HOST_NOT_FOUND is |
| 760 | returned instead of TRY_AGAIN. Thus, it is safest to try a DNS lookup directly |
| 761 | first, and only if that gives a definite "no such host" to try the local |
| 762 | function. |
| 763 | |
| 764 | 5. In fixing the minor security problem with pid_file_path, I have removed some |
| 765 | backwards-compatible (undocumented) code which was present to ease conversion |
| 766 | from Exim 3. In Exim 4, pid_file_path is a literal; in Exim 3 it was allowed to |
| 767 | contain "%s", which was replaced by the port number for daemons listening on |
| 768 | non-standard ports. In Exim 4, such daemons do not write a pid file. The |
| 769 | backwards compatibility feature was to replace "%s" by nothing if it occurred |
| 770 | in an Exim 4 setting of pid_file_path. The bug was in this code. I have solved |
| 771 | the problem by removing the backwards compatibility feature. Thus, if you still |
| 772 | have "%s" somewhere in a setting of pid_file_path, you should remove it. |
| 773 | |
| 774 | 6. There has been an extension to lsearch files. The keys in these files may |
| 775 | now be quoted in order to allow for whitespace and colons in them. This means |
| 776 | that if you were previously using keys that began with a doublequote, you will |
| 777 | now have to wrap them with extra quotes and escape the internal quotes. The |
| 778 | possibility that anybody is actually doing this seems extremely remote, but it |
| 779 | is documented just in case. |
| 780 | |
| 781 | |
| 782 | Version 4.10 |
| 783 | ------------ |
| 784 | |
| 785 | The build-time parameter EXIWHAT_KILL_ARG has been renamed EXIWHAT_KILL_SIGNAL |
| 786 | to better reflect its function. The OS-specific files have been updated. Only |
| 787 | if you have explicitly set this in your Makefile (highly unlikely) do you need |
| 788 | to change anything. |
| 789 | |
| 790 | **** |