http://blog.gmane.org/gmane.mail.exim.announce hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.mail.exim.announce/148 <pre>The machine hosting exim.org suffered some unexpected downtime on the afternoon of Friday 26 October between 14:51 and 17:12. The server failed to reboot because of some minor disk corruption and it took rather too long to fix this problem. The downtime was not related to the security patch release of Exim earlier in the day. Sorry for any inconvenience this may have caused. Tony. </pre> Tony Finch 2012-10-26T16:46:33 http://comments.gmane.org/gmane.mail.exim.announce/147 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Exim release 4.80.1 is now available from the primary ftp site: * ftp://ftp.exim.org/pub/exim/exim4/exim-4.80.1.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-4.80.1.tar.bz2 _________________________________________________________________ This is a SECURITY release, addressing a CRITICAL remote code execution flaw in versions of Exim between 4.70 and 4.80 inclusive, when built with DKIM support (the default). This release is identical to 4.80 except for the small changes needed to plug the security hole. The next release of Exim will, eventually, be 4.82, which will include the many improvements we've made since 4.80, but which will require the normal release candidate baking process before release. You are not vulnerable if you built Exim with DISABLE_DKIM or if you put this at the start of an ACL plumbed into acl_smtp_connect or acl_smtp_rcpt: warn control = dkim_disable_verify I apologise for the impact of releasing this on a Friday. I do not consider there to be an acceptable alternative. This issue, which is known by the CVE ID of CVE-2012-5671, was found during internal code review of an area of the Exim codebase relevant to another issue, DKIM signing and verification, which has been the subject of US-CERT VU#268267 and Common Weakness identifiers CWE-347 and CWE-326. As such, I expect that this area of code in various MTAs will be studied by many security conscious people around about now, so there is a significant risk that someone unfriendly has also discovered this, concurrently to our finding it. We discovered the issue on Wednesday, gave Thursday for the OS packagers to get emergency packages prepared, and are releasing on the next available work day. This is why we have made the smallest feasible changes to prevent exploit: we want this change to be as safe as possible to expedite into production. This security vulnerability can be exploited by anyone who can send email from a domain for which they control the DNS. The class of attack is known as a "heap-based buffer overflow"; your OS might be built with protections to mitigate against these attacks. To avoid confusion between "4.80.1" and "4.81", we will skip the "4.81" version number and the next release will be "4.82". I'd like to thank my employer, Apcera Inc, for supporting my commitment to the Exim community. _________________________________________________________________ The primary ftp server is in Cambridge, England. There is a list of mirrors in: * http://www.exim.org/mirmon/ftp_mirrors.html The master ftp server is ftp.exim.org. The distribution files are signed with Phil Pennock's PGP key 0x403043153903637F (uid pdp&lt; at &gt;exim.org; signed by Nigel Metheringham's PGP key 0x85AB833FDDC03262). This key should be available from all modern PGP keyservers. Please use your own discretion in assessing what trust paths you might have to this uid; the "Release verification" section of the Release Policy might be of assistance: * http://wiki.exim.org/EximReleasePolicy The detached ASCII signature files are in the same directory as the tarbundles. The SHA1 and SHA256 hashes for the distribution files are at the end of this email. This shall likely be the last release announcement to include SHA1 hashes. The distribution contains an ASCII copy of the 4.80.1 manual and other documents. Other formats of the documentation are also available:- * ftp://ftp.exim.org/pub/exim/exim4/exim-html-4.80.1.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-pdf-4.80.1.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-postscript-4.80.1.tar.gz The .bz2 versions of these tarbundles are also available. We know that the security details for verifying releases, in the documentation is out of date, and has been for the past few releases. This has been fixed for 4.82. The ChangeLog for this, and several previous releases, is included in the distribution. Individual change log files are also available on the ftp site, the current one being:- * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.80.1 * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.80.1.gz There are no new features, thus no NewStuff-4.80.1 file. _________________________________________________________________ Release Checksums SHA256: 9565b10f06be224fd03adafae2e07e6fdbb479f8873e3894ddb13f98eeebe78f exim-4.80.1.tar.bz2 2cac05ce27a5d5b409ce5657957047233d36f9396d0203d240a5b7aed2a969de exim-4.80.1.tar.gz 206ef4acc2641f10f3f23f8ee97cd1f7125486938ea1fc231ac2a1d5d6c9be09 exim-html-4.80.1.tar.bz2 0286d02f85e0a9a4a00d7bc74b6378c36181f5bb2500969039593d336cb142d7 exim-html-4.80.1.tar.gz d65cec38449432db60b090a82c688dd65d40c6b0c64953fbe4d3b765a2c74aee exim-pdf-4.80.1.tar.bz2 c2ed7d6ecce24631ac0a92894af09e1cdc90b7ba61f03a91a34d40f7dd762a1f exim-pdf-4.80.1.tar.gz 3c656be9196b94be96bcf1e775e7138bfcd49843acec0e0b16923f114ca26c2b exim-postscript-4.80.1.tar.bz2 1f0dc4daca46f59c7c52d90ff10cb635509be5f6f1bbb793ee05745e29fcbfa9 exim-postscript-4.80.1.tar.gz SHA1: 714e40d440641050a1d9946cd937aad0d1a6b746 exim-4.80.1.tar.bz2 eeb6d1e4c7c1dc0e4de55ba61316718e44d810b3 exim-4.80.1.tar.gz d23ec94c23228a1f540d8343c6c2c5f1833b0dd0 exim-html-4.80.1.tar.bz2 49b2f226f1355a11ba4d193a06a84f6a3dce3003 exim-html-4.80.1.tar.gz e24304f9f087faf79e22b8ca8b3e27154c7e4cc9 exim-pdf-4.80.1.tar.bz2 86594290072917649f165270ad61399aaf0c9c72 exim-pdf-4.80.1.tar.gz ffdc6a08093c4ec9f26bce24d3f16b5cf91f5454 exim-postscript-4.80.1.tar.bz2 d9c5951b7b415e09146d594fda864725096f596d exim-postscript-4.80.1.tar.gz - -Phil Pennock, pp The Exim Maintainers. -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlCKQ8gACgkQQDBDFTkDY3/rFACfW+aJvPe4hDYN6eIzzQielqC+ EbcAoIcWq5pfgPeZmsLE7Ikb7Zj+afm+ =NUm5 -----END PGP SIGNATURE----- </pre> Phil Pennock 2012-10-26T08:03:30 http://comments.gmane.org/gmane.mail.exim.announce/146 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Folks, For a narrative walk-through of what can go wrong when you don't use large enough keys in public cryptography, as applied in a real world attack against DKIM in email: http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-widespread/ There is a US-CERT announcement: http://www.kb.cert.org/vuls/id/268267 In particular, a number of tutorials on how to set up DKIM will have the administrator use the openssl command to create a 512 or 768 bit RSA key. This is unwise, and may permit others to fraudulently assert that their mail comes from you. If your mail and reputation are worth protecting, they're worth protecting right. “A 384-bit key I can factor on my laptop in 24 hours,” he says. “The 512-bit keys I can factor in about 72 hours using Amazon Web Services for $75. And I did do a number of those. Then there are the 768-bit keys. Those are not factorable by a normal person like me with my resources alone. But the government of Iran probably could, or a large group with sufficient computing resources could pull it off.” -- Zachary Harris, cited in the Wired article Public key cryptography on the Internet is in an awkward transitional phase: most folks are still using RSA and it's the "de facto supported" algorithm, but adequate key lengths today make processing very slow. In the USA, NSA Suite B cryptography uses ECC exclusively, which is fast and uses smaller keys, but support is not widespread. This leads to some uncomfortable choices for administrators. The Exim maintainers are not cryptanalysts, we can not state what should be used. We do not know what maximum sizes may be supported out there. We can say that DKIM specifies a minimum of 1024 bits; the site: http://www.keylength.com/en/ provides tables of key-lengths as recommended by various organisations. The European ECRYPT II standards cite 1248 bits (asymmetric) as the smallest general purpose level for protection in situations which most closely resemble DKIM for email on the Internet. We can say that DKIM has been designed to make it very easy to roll your keys! Create new keys, publish them in DNS. If you use a predictable naming scheme, you might wait for the zone minimum/negative TTL expiry duration to pass, so that non-existence can't have been abusively cached for your next key. Then switch the signing transport's `dkim_selector` and `dkim_private_key` values to point to the new selector and key. Wait a few days for mail in transit to all have been delivered, then remove the old keys from DNS (or sooner, if you've been attacked, as Google were). Those wanting a complete example, with Makefile, of Exim and DKIM integration might peruse "Unix and Linux System Administration Handbook", 4th Edition, by Nemeth et al; the Exim DKIM section has a complete example, contributed by myself. (I am not an author, I receive no money from sales of this excellent book.) Regards, - -Phil Pennock, mostly on behalf of The Exim Maintainers -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlCIVCYACgkQQDBDFTkDY3+FGQCaA7Tp8ImY2k0ujCKhVWoFI3hz Dd8An3MFQAlSxWDUzb8+AfNGy+VX9kuT =sCKz -----END PGP SIGNATURE----- </pre> Phil Pennock 2012-10-24T20:48:50 http://comments.gmane.org/gmane.mail.exim.announce/145 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Short version: if you take authentication data in Exim, or supply it, over TLS, with Exim built against OpenSSL, then you _might_ want to set: openssl_options = +no_compression in your Exim configuration file. This option value requires Exim 4.80 and a version of OpenSSL which defines SSL_OP_NO_COMPRESSION (1.0.0 or greater). We might fix this for Exim 4.81 to not be necessary. There's no adjustment possible with GnuTLS yet. Longer version: The "CRIME" attack uses TLS compression against itself: if someone can control part of the content of a TLS session, they can iterate across multiple sessions to try to make the packets smaller, by trying to repeat content they don't have access to: your SMTP authentication data. Any sort of attack would probably trip any ratelimits you might have configured, and would be visible as many mails, and requires the attacker to both be able to send mail from a client and witness the packet sizes on the wire, and send the mail to someone who won't be bothered by the sheer volume of such mails (eg, themselves). Whether this affects your setup is not something I can decide for you. Much of the analysis for the impact of BEAST applies here too: https://lists.exim.org/lurker/message/20110924.025611.322d31d8.en.html (Ignore the "CBC, OpenSSL &amp; GnuTLS" section). I do not intend to disable TLS compression by default in Exim. Most uses of TLS remain unauthenticated (and, at this time, unverified). The "openssl_options" option was added in Exim 4.73, using the list of SSL_OP_* values available at the time. As part of the TLS overhaul in Exim 4.80, the list of detected SSL_OP_* defines was updated to those available in OpenSSL 1.0.1c. Before Exim 4.80, SSL_OP_NO_COMPRESSION was not detected. The fix to add "no_compression" -&gt; SSL_OP_NO_COMPRESSION is a very easy backport to apply, if this functionality is wanted in an earlier version of Exim which is least version 4.73. It's three lines to add, then just recompile. In src/tls-openssl.c the exim_openssl_options[] array contains the list of options, in alphabetical order. It needs to gain: - ----------------------------8&lt; cut here &gt;8------------------------------ #ifdef SSL_OP_NO_COMPRESSION { US"no_compression", SSL_OP_NO_COMPRESSION }, #endif - ----------------------------8&lt; cut here &gt;8------------------------------ and this needs OpenSSL 1.0.0 or greater; the 0.9.&lt;...&gt; series of releases does not expose this option. (The change is safe to make to Exim regardless, because of the #ifdef guard.) For GnuTLS, there is no available control for Exim to adjust, so there is no defence available for Exim built against GnuTLS. Should this situation change, I expect to add support to Exim for using that control. I will examine the feasibility of avoiding this issue with Exim 4.81 on OpenSSL by forcing a BIO_flush() after SMTP AUTH. At present, although not guaranteed, this forces a compression block end in OpenSSL, which changes the compression dictionary and so makes this attack impossible. - -Phil -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlB0YBIACgkQQDBDFTkDY3/QawCgkoluI7JfTgXBpg03kKh45N9V rSoAmwYtHkfpDYubi652aXEk8jdtPCbq =He/S -----END PGP SIGNATURE----- </pre> Phil Pennock 2012-10-09T17:34:20 http://comments.gmane.org/gmane.mail.exim.announce/144 <pre>When will be available the debianized version ? I'd like to use the 4.80 in my Ubuntu Server 12.04. Please excuse me if this is not the correct mlist to discuss this item (if so what is the correct one ?). Best Regards luciano </pre> l.rinetti< at >movimatica.com 2012-08-06T10:08:15 http://comments.gmane.org/gmane.mail.exim.announce/143 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Exim release 4.80 is now available from the primary ftp site: * ftp://ftp.exim.org/pub/exim/exim4/exim-4.80.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-4.80.tar.bz2 _________________________________________________________________ This release contains backwards incompatible changes. PLEASE read the README.UPDATING file before upgrading. These changes affect OpenSSL, GnuTLS and LDAP. OpenSSL default options have changed to be more secure, including disabling of SSLv2 by default (and adding support for TLSv1.1 and TLSv1.2 if using OpenSSL 1.0.1 or newer); GnuTLS has been updated to use a new API and stop honouring some options starting gnutls_*; users of LDAP can now distinguish "comma in data" from "multi-valued attribute". There are more details, covering more changes, in README.UPDATING. We now enable accept_8bitmime by default, as the Exim maintainers agree with Dan Bernstein about the best way to deal with the 8BITMIME extension. Building Exim should now be easier, with pkg-config support. We now support use of the TLS Server Name Indication (SNI) extension, both as client and as server, so Exim can present different TLS identities to different clients on the same port. We have new authentication drivers, for gsasl and heimdal_gssapi. The ${eval...} expansion operator now supports 64-bit arithmetic (on 64-bit platforms). Exim can now be started with support for inetd "wait-mode", which should be a precursor to socket activation support for your OS's init system. _________________________________________________________________ The primary ftp server is in Cambridge, England. There is a list of mirrors in: * http://www.exim.org/mirmon/ftp_mirrors.html The master ftp server is ftp.exim.org. The distribution files are signed with Phil Pennock's PGP key 0x3903637F (uid pdp&lt; at &gt;exim.org; signed by Nigel Metheringham's PGP key DDC03262). This key should be available from all modern PGP keyservers. Please use your own discretion in assessing what trust paths you might have to this uid; the "Release verification" section of the Release Policy might be of assistance: * http://wiki.exim.org/EximReleasePolicy The detached ASCII signature files are in the same directory as the tarbundles. The SHA1 and SHA256 hashes for the distribution files are at the end of this email. This shall likely be the last release announcement to include SHA1 hashes. The distribution contains an ASCII copy of the 4.80 manual and other documents. Other formats of the documentation are also available:- * ftp://ftp.exim.org/pub/exim/exim4/exim-html-4.80.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-pdf-4.80.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-postscript-4.80.tar.gz The .bz2 versions of these tarbundles are also available. The ChangeLog for this, and several previous releases, is included in the distribution. Individual change log files are also available on the ftp site, the current one being:- * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.80 * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.80.gz Brief documentation for new features is available in the NewStuff file in the distribution. Individual NewStuff files are also available on the ftp site, the current one being:- * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.80 * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.80.gz _________________________________________________________________ Release Checksums SHA256: 787b6defd37fa75311737bcfc42e9e2b2cc62c5d027eed35bb7d800b2d9a0984 exim-4.80.tar.bz2 dba89de1e59e6d7b61aa03fcb6ce8946bce00bc966362b64c3758a6c557b921d exim-4.80.tar.gz 4d33239e787d4a509bdbf0bdb74a9da7c9ea2df8a953fe6dc5dd139b92301d7e exim-html-4.80.tar.bz2 9a5070e94df5b15c515028a779afee20114257dd127062345348f10f18cd0795 exim-html-4.80.tar.gz 3db123b18a504f9c72ccb815aff99be0dcbeb7b7c8e6bab74e80bbe3c96d1f64 exim-pdf-4.80.tar.bz2 dfd82b695522431fabd1636e6fbc5b9ea0402c9a1ea63d9a1d00f79ba51c3059 exim-pdf-4.80.tar.gz 711dd85219bd66a63a1343904127f028506349b45da3a0cd65df722a9988b114 exim-postscript-4.80.tar.bz2 43bf9c87968871dfc288171e89c0d61771a72bf575ea38c7e9dc2650644bf227 exim-postscript-4.80.tar.gz SHA1: ba9b78b9dfab48f45409ab7c1c94ad085347899d exim-4.80.tar.bz2 4ae4a8c66fad75a92c88b7ea1e4a46ef30a22995 exim-4.80.tar.gz 2e485cf4404d41909a3b79477702a765bcc50cb3 exim-html-4.80.tar.bz2 4674613c4e8d571e72583e5e820925637e3001b2 exim-html-4.80.tar.gz 51834b8d5a1d38453b411f07c5b70502f6afdc57 exim-pdf-4.80.tar.bz2 f202e471c515b0d0c8f3e1f6c31ae8b014ebed0c exim-pdf-4.80.tar.gz 0f3686bd3194a32e7bc5bb3c3142fc0416636e3d exim-postscript-4.80.tar.bz2 d89062f0dbb791f7aa1e0b03bb890cfc207195a8 exim-postscript-4.80.tar.gz - -Phil Pennock, pp The Exim Maintainers. -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk/HQa4ACgkQQDBDFTkDY39kJACggwyKRizLAYw2VobhZbXCtWKf VbIAn35r2OsnG1ojPQ6rEoNtkSOwHwzv =OlYc -----END PGP SIGNATURE----- </pre> Phil Pennock 2012-05-31T10:02:32 http://comments.gmane.org/gmane.mail.exim.announce/142 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Exim release 4.77 is now available from the primary ftp site: * ftp://ftp.exim.org/pub/exim/exim4/exim-4.77.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-4.77.tar.bz2 _________________________________________________________________ This release contains backwards incompatible changes. PLEASE read the README.UPDATING file before upgrading. Per the recent Exim-Announce notice, we have realised that the match_&lt;type&gt;{}{} expansion conditions were too powerful and sometimes misused, leading to configurations with security issues, such as SQL injection attacks. So we have restricted their functionality. The README.UPDATING file describes precisely what has changed and what the alternatives are, and how to restore the old functionality, should you need to. In brighter news: rate-limiting is now more powerful and users of GnuTLS can now use TLS 1.1 and 1.2 for connections. _________________________________________________________________ The primary ftp server is in Cambridge, England. There is a list of mirrors in: * http://www.exim.org/mirmon/ftp_mirrors.html The master ftp server is ftp.exim.org. The distribution files are signed with Phil Pennock's PGP key 0x3903637F (uid pdp&lt; at &gt;exim.org; signed by Nigel Metheringham's PGP key DDC03262). This key should be available from all modern PGP keyservers. Please use your own discretion in assessing what trust paths you might have to this uid; the "Release verification" section of the experimental Release Policy might be of assistance: * http://wiki.exim.org/EximReleasePolicyProposedDraft The detached ASCII signature files are in the same directory as the tarbundles. The SHA1 and SHA256 hashes for the distribution files are at the end of this email. The distribution contains an ASCII copy of the 4.77 manual and other documents. Other formats of the documentation are also available:- * ftp://ftp.exim.org/pub/exim/exim4/exim-html-4.77.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-pdf-4.77.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-postscript-4.77.tar.gz The .bz2 versions of these tarbundles are also available. The ChangeLog for this, and several previous releases, is included in the distribution. Individual change log files are also available on the ftp site, the current one being:- * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.77 * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.77.gz Brief documentation for new features is available in the NewStuff file in the distribution. Individual NewStuff files are also available on the ftp site, the current one being:- * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.77 * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.77.gz _________________________________________________________________ Release Checksums SHA256: 0ccc13cf2f052b1163fcdf71c55a3578765050848ba413a6473d3ab5d20b1475 exim-4.77.tar.bz2 16498072d82c74d29fe9e09cb46f9060de1bd0cb5721ccc071990af612ee9a3c exim-4.77.tar.gz 05823ebe0c0554215d928bee1a856bb2011e993f170edadbad57f0fb21dd9c76 exim-html-4.77.tar.bz2 4f36136cd14d64cb8e0709a4ac41f6d670f127fa313c7d196415f9eb04af043c exim-html-4.77.tar.gz 871eb94a2cdd27e151abd5629fad1319708bf7b2de37b002d586f8a06cc43605 exim-pdf-4.77.tar.bz2 511f0f6e369e6b8b0492d5bdef55fb451d73beab78d760a86e8fa13037592d4d exim-pdf-4.77.tar.gz b68d379366c1745c805f541de82878917bb7b544bf52cf34212ec887a5fbdfe2 exim-postscript-4.77.tar.bz2 443327a59e028b1399115ecaf1e78a814e6f6a658c05340a429f1d472d7f453d exim-postscript-4.77.tar.gz SHA1: 0aad2cf08d03ad9e809d86521eac8f3f31398a1d exim-4.77.tar.bz2 2c1ba6b8f627b71b3b58fc0cc56e394590dcd1dc exim-4.77.tar.gz bccf154854ed855aa031018a84f34c260fe00723 exim-html-4.77.tar.bz2 fa86474b675f99235e0ceb7cd8d202ae1d9710bf exim-html-4.77.tar.gz a4b6905e0d350e6fe2edeee510fedfa882a40d1b exim-pdf-4.77.tar.bz2 5e0d017c9d13a6830d90b6b7c37a8dc771bd2ef1 exim-pdf-4.77.tar.gz 68ae4edd34f3da73f9cea557a3aec46b7de3280d exim-postscript-4.77.tar.bz2 4c3f9ddc57fff05a51b1118891ac3dee99aeadbe exim-postscript-4.77.tar.gz - -Phil Pennock, pp The Exim Maintainers. -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk6SiP8ACgkQQDBDFTkDY3+6+gCbBdhXBRHF1HJkEFb9XQRkCXrS liAAn0UgsnzziVXRyJ/aCx622VTUDlwx =WQAj -----END PGP SIGNATURE----- </pre> Phil Pennock 2011-10-10T05:56:24 http://comments.gmane.org/gmane.mail.exim.announce/141 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Folks, The forthcoming Exim 4.77 release (now in Release Candidate state) will have a backwards-incompatible change by default, in configuration parsing of four expansion conditions: "match_address", "match_domain", "match_ip" &amp; "match_local_part". Exim's treatment of these options has matched the documentation, but does not appear to match the expectations of many administrators, who as a result may have created configurations which have a security flaw, leading to problems such as SQL injection. Exim's configuration language generally provides a lot of power, but also requires the administrator to use functions like ${quote_mysql:...} when constructing an SQL query. We let you shoot yourself in the foot. We also provide an ${expand:...} operator, to let you re-expand strings; hopefully it is obvious that re-expanding data extracted from an email's headers is a security problem. This is much like the "eval" functionality of many scripting languages. In the case of the match_* operators, the problem is more subtle and too many folks did not understand the documented behaviour and so inadvertently created similar situations, using expansion conditions more powerful than they realised. The four expansion conditions "match_address", "match_domain", "match_ip" &amp; "match_local_part" all take two arguments. The first is something to look for, the second is a list of data to match against. In common with Exim typed list handling, these lists can contain more than just literal string data. In particular, they can contain arbitrary database lookups with arbitrary SQL execution. At this point, it should be clear that using a value derived from an email header or an SMTP exchange as the specification of the list is somewhat unwise. And yet, experience has shown that, time and again, we are seeing people use conditions such as: match_address{$something}{$another_address} where $another_address is extracted from untrustworthy sources. Going forward, by default those four expansion conditions will be unusually different from other conditions, in that the contents of the second string WILL NOT BE SUBJECT TO STRING EXPANSION. Thus this works: ${if match_domain{example.org}{+local_domains}} but this does not, because the '$' is left as a literal '$': ${if match_domain{example.org}{$sender_domain}} Note that the named domainlist "local_domains" here can still contain arbitrary data lookups, as before. Those can still refer to variables derived from an email, as before. It's just that the specification of what the list is that Exim should compare against is no longer expanded and thus can not directly refer to data from an email. This may break some existing configurations, but if so then we believe that your current configuration may have unpleasant security implications. Because we recognise that there may be safe usage of variables _not_ derived directly from the email being handled there is a new build-time option to keep the old behaviour, "EXPAND_LISTMATCH_RHS". Please let us know if you need to use this built-time option, so that we can consider providing safer alternatives. If we do not hear of cases where this was needed, then we may remove the build-time option in a future release. Two new expansion conditions have been added to Exim to help with this change. They are "inlist" and "inlisti". The check: ${if inlist{needle}{foo:needle:bar}} is equivalent to the existing: ${if forany{foo:needle:bar}{eq{$item}{needle}}} but is a little easier to understand and matches the existing match_&lt;foo&gt; layout. The "inlisti" condition is similar, but uses "eqi" instead if "eq" for case-insensitive comparison. The second parameter here is subject to string expansion, but the contents are not subject to lookup expansion, including named list handling. So it's: ${if inlist{example.org}{${complicated_expansion_giving_list}}} ${if inlist{example.org}{&lt;, example.org, example.com}} ${if match_domain{example.org}{+my_domain_list}} It is likely that current incorrect usages of the match_&lt;foo&gt; conditions can be migrated to use of either "eqi" for direct string equality checks, or "inlisti" for looking in ${expanded_data}. Regards, - -Phil Pennock, pp The Exim Maintainers -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk6JqTQACgkQQDBDFTkDY3+r5wCfeh/WH5GhSwzvh9nS/uZxrZpf +NQAn0Lj+6ZRqscljdygVqF8kUHQCaaR =2mhA -----END PGP SIGNATURE----- </pre> Phil Pennock 2011-10-03T12:23:26 http://comments.gmane.org/gmane.mail.exim.announce/140 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Administrators may be worried about the current reports of the so-called "BEAST" attacks against SSL/TLS. This mail addresses the impact on Exim as I currently understand the issues. I will use "TLS" below to mean SSL and/or TLS, since most environments can be forced to degrade at least down to SSL3.0. Short version: not directly vulnerable to this threat model, but if you use plaintext passwords over TLS to authenticate to a remote web-server, or your clients authenticate to you in this way, then there are more general issues to be aware of. There are TLS compatibility vs security trade-offs that you might want to tune in this case. See the existing documentation for the "openssl_options" variable and the documented suggested alternate value; the option was added in Exim 4.73. Online documentation: http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html At this point, there are no plans to release a new version of Exim specifically to address this issue, and whether to change the default value of "openssl_options" is still open to debate. There are a couple of other adjustments that will be made, most notably to our GnuTLS configuration support. In practice, my non-cryptographic-expert summary is: don't worry too much right now. Longer version follows. Much Longer. I aimed for completeness. Beware that this was written in one sitting, so something may still be absent. BEAST - ----- The BEAST attack relies upon a "chosen plaintext", ie the attacker chooses what data will be encrypted and can then look at what's sent, to try to recover data. Now, it's fairly easy for an attacker to send email through a mail-server if it's set up as a relay, or if they have an account. Whether or not, in theory, the attacker can control matters with sufficient precision to recover text is doubtful, but human ingenuity is not to be underestimated. At the current time though, the attacks depend upon one existing connection being held open and authentication happening repeatedly on client-server messages, with the attacker influencing the boundaries. In HTTPS there is often a cookie, not exposed to JavaScript, which it can be valuable to extract; once you've figured out how to control the data being sent over HTTPS (via injecting script somehow), the attacker can slowly manage to recover the cookie, at which point they can directly access the web site as the signed-in user. This relies upon the cookie being sent with each HTTP request over the HTTPS connection, with persistent connections. In SMTP, the equivalent data to recover would be a session password used in SMTP AUTH. The ideal protection is to not treat TLS as sufficient justification to send cleartext passwords (PLAIN or LOGIN mechanisms) within the communication channel and instead to use CRAM-MD5, GSSAPI or some other mechanism which proves possession of a password or token, rather than disclosing it. Ultimately, because there will always be new breaks in cryptography, the very cautious folks will layer their defences and not use PLAIN or LOGIN even within TLS. In practice, this might be difficult to achieve; in balancing costs and benefits, it might not be worth mandating this protection in most environments. This is into the realms of risk management and policy-making. In SMTP, the authentication happens once, at the beginning of an SMTP connection. While 1 or more messages may be sent over an existing session, the credentials are not re-sent, so a new session needs to be opened to re-sent the credentials, so the current BEAST attack does not apply, per my current understanding. TLS &amp; SMTP - ---------- So, onwards to the more general issue of the security of TLS in email and Exim, what might be attacked, CBC and clients. In email, there are four modes to consider: (1) No SMTP-level encryption; the bulk of email today is sent like this, and so for security the sender should use an end-to-end system such as PGP or S/MIME. (2) Encryption from a mail-client to the mail-server, for mail submission, typically on port 587 (or 465); some degree of identity verification is performed here and there's an assumption of security. (3) Opportunistic encryption MX-&gt;MX, vulnerable to Man-in-the-middle attack because there is no defined idea of what the "identity" of a mail-server should be; that's a separate debate, but in short it's highly likely that if you're sending passwords in this mode, you're crazy. (4) Encryption MX-&gt;MX by out-of-band established policy on identity verification. In mode 1, there's nothing to discuss. Similarly for mode 3. In mode 2, the attack model is something on a client computer which can send email through an MUA but not recover the MUA's configured password. If this is malware, then it almost certainly can get the password anyway and the BEAST-style attack is unnecessary. If it's software which can be abused into sending email (automating mailto: submission?) then perhaps there's an issue. At this point, the evidence left behind is large (saved copies of sent mail). Nonetheless, those with particularly sensitive data might conceivably care about this vector as often the same password used to send email is used to access stored email, eg in an IMAP store. In mode 4, the attack model is someone trying to recover the server-to-server password so that they can fraudulently send email; it's unlikely that such as password will grant access to read existing mail. The attacker might have an easier time here, since they might be able to send email between two boxes they control. In neither case does a vulnerability in TLS permit an attacker to directly compromise data other than what they're sending; the issue is entirely about access to credentials sent over the same sessions. In mode 4, a reasonable approach to avoid these issues is to use TLS client certificates; Exim supports that now. With this done, there is no data within the session other than the attacker's own, and so nothing to worry about the disclosure of. In mode 2 (MUAs), client certificates are possible but client support becomes much more limited. Note that overly broad selection of Certification Authorities may turn mode 4 unexpectedly into mode 3. So: most mail, there's nothing to protect against the person sending the mail in the first place; there are ways to avoid having something to protect, or to protect that data against even a TLS break; some people are stuck using passwords via PLAIN or LOGIN SMTP AUTH mechanisms over TLS right now, the above analysis of this particular attack does not reassure them, and they want to make sure that the session encryption being used is as strong as possible. Onwards. CBC, OpenSSL &amp; GnuTLS - --------------------- Cryptographic discussion follows; warning, I am not a professional cryptographer. In sending data securely in blocks, there are various ways that an encryption key can be used to protect more than a small amount of data without generating repeated patterns. One mode, which has been shown for some time to have problems, is to use one "Initialisation Vector" (or IV) at the start, and then for all blocks except the first to use the previous _encrypted_ text as the IV for this block. When the encrypted data is sent over the wire first, this means that the IV is "known". That's how TLS is used -- the previous data is sent before the current data, and the encrypted data is directly exposed. This "implicit IV" can be avoided in three ways, but unfortunately two are not available to current implementations and the one available solution breaks some widely deployed software. One way is to not use Cipher-Block-Chaining (CBC) encryption. This is controlled in Exim with the "tls_require_ciphers" options; one in the main configuration, used for incoming connections, and also on SMTP Transports, used for outbound connections. More on this below. The second way: TLS 1.1 introduces explicit IVs to protect against just these attacks. This doesn't help us. Some releases of GnuTLS support TLS 1.1 (and TLS 1.2). OpenSSL does not. NSS, the third main TLS provider library, does not. So most clients in use will not. Thus this currently could only help with server-server communication where GnuTLS is used on both sides. (I welcome hearing of a widespread MUA which uses GnuTLS). The gnutls_require_protocols Exim option controls this, however current releases of Exim only support "TLS1" and "SSL3" as values of this option and by default constrain GnuTLS to these versions. This is regrettable. A bug has been filed and future releases of Exim should have support for configuring GnuTLS with support for higher protocol versions. So Exim can currently only support up to TLS 1.0, in part because our GnuTLS support could do with more loving care. We are a volunteer project and contributions are welcome. (For this one particular issue, it _looks_ simple enough to fix even without knowing GnuTLS well, so I'll give it a go). The third way: tinkering with the TLS 1.0 protocol, and disabling SSL3. OpenSSL introduced an adjustment to the protocol behaviour to defend against exactly this attack, by (ab)using the protocol, sending empty fragments and getting the IV to be non-predictable as a result of that. Unfortunately, the adjustment breaks some other implementations. Most notably, it is my understanding that it breaks the OS-provided TLS implementation of Microsoft Windows, at least through Windows XP. So OpenSSL included the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option to disable this protection. Because of the breakage, a long time ago Exim set this option by default. Exim Configuration - ------------------ As of Exim 4.73, the setting of the OpenSSL options was exposed to the Exim configuration file, via the "openssl_options" option. Note that because of an infelicity in how this option is managed, the default value is shown as blank but that means that +dont_insert_empty_fragments is set, as described in The Exim Specification. So: $ exim -bP openssl_options is misleading. If you read the documentation for "openssl_options", the example use of this option given is to set: openssl_options = -all Doing this will, loosely speaking, reset the options passed to OpenSSL to be empty and take the OpenSSL defaults. That will provide the CBC protection. Doing this may cause TLS breakage for some of your clients. The value of the "tls_require_ciphers" option is interpreted by either OpenSSL or GnuTLS, depending upon which TLS provider Exim was built with: * OpenSSL: http://www.openssl.org/docs/apps/ciphers.html * GnuTLS: http://www.gnu.org/s/gnutls/manual/html_node/Priority-Strings.html In addition, there are a number of gnutls_* options which may assist; as noted above, gnutls_require_protocols does not currently support values other than "TLS1" and "SSL3" (specified in a list in the usual Exim manner). Because the particular ciphers available vary depending upon the release of the TLS provider in use, the best way to tell is to ask the library what a given string means. I am not currently aware of a command-line tool to do this with GnuTLS. With OpenSSL, the "openssl ciphers -v $SPEC" command can be used to see which ciphers are enabled for a given specification. If you remove all the CBC cipher-based ciphersuites, you're left with some ECDH* ciphersuites, some Camellia, and about six others. The Exim maintainers are not qualified to give cryptographic advice as to the security properties of these suites, to which of these suites are suitable, nor to comment on how widely deployed they are and how this will affect the ability of your installation to find a mutually supported ciphersuite when talking to someone else. That butt-covering said, with the understanding that it's not expert advice, merely a pointer, note that one well known search provider and free mail provider tends to use "RC4-SHA" both for web traffic and SMTP/TLS. So as long as that remains in your list of available ciphersuites, you'll _probably_ be good. [More butt-covering: disclosure: said company is a former employer of mine and I still own stock; I really don't think I just pimped them, though]. If you're reading this sentence after reading _all_ of the above without skimming, congratulations. :) - -Phil -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk59RrkACgkQQDBDFTkDY396uQCfRnib6kFZMzcFk1Z8+KZ4cPC/ 1b8An0eQuhYW7UB2DPQnnRTyg29NLALX =aAPp -----END PGP SIGNATURE----- </pre> Phil Pennock 2011-09-24T02:56:11 http://comments.gmane.org/gmane.mail.exim.announce/139 <pre>I have just made 2 changes to the list configurations on exim.org:- 1. Monthly list reminders have been switched off. It has been a long time since these were considered best practice, and routinely sending out clear text passwords is not sensible. 2. VERP has been set on all the lists. This will make the handling of non-delivery notifications much more effective. If you filter lists based on the envelope sender address then this may break your filtering. The message headers should not change. VERP handling will increase the load on the exim.org machines, but the reduced throughput on the list in recent years makes this less of an issue. Nigel. -- [ Nigel Metheringham ------------------------------ nigel&lt; at &gt;dotdot.it ] [ Ellipsis Intangible Technologies ] </pre> Nigel Metheringham 2011-09-05T20:45:00 http://comments.gmane.org/gmane.mail.exim.announce/137 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Exim release 4.76 is now available from the primary ftp site: * ftp://ftp.exim.org/pub/exim/exim4/exim-4.76.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-4.76.tar.bz2 _________________________________________________________________ This is a SECURITY release: Exim versions 4.70 up to and including 4.75 contained a security hole (format string attack) permitting remote execution of arbitrary code as the Exim run-time user. This is CVE-2011-1764. There is also another, lesser security issue. Both lie in the DKIM code and mitigation techniques are described below. Note that as part of our work to improve Exim and protect against future security issues, some changes were made to the code to pass gcc with many more warnings enabled, and in some cases to compile with Clang. Although feedback so far has been positive, there remains a chance that these changes will cause compilation problems on lesser-tested platforms; please raise any issues encountered on the exim-users mailing-list. _________________________________________________________________ The primary ftp server is in Cambridge, England. There is a list of mirrors in: * http://www.exim.org/mirmon/ftp_mirrors.html The master ftp server is ftp.exim.org. The distribution files are signed with Phil Pennock's PGP key 0x3903637F (uid pdp&lt; at &gt;exim.org; signed by Nigel Metheringham's PGP key DDC03262). This key should be available from all modern PGP keyservers. Please use your own discretion in assessing what trust paths you might have to this uid; the "Release verification" section of the experimental Release Policy might be of assistance: * http://wiki.exim.org/EximReleasePolicyProposedDraft The detached ASCII signature files are in the same directory as the tarbundles. The SHA1 and SHA256 hashes for the distribution files are at the end of this email. The distribution contains an ASCII copy of the 4.76 manual and other documents. Other formats of the documentation are also available:- * ftp://ftp.exim.org/pub/exim/exim4/exim-html-4.76.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-pdf-4.76.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-postscript-4.76.tar.gz The .bz2 versions of these tarbundles are also available. The ChangeLog for this, and several previous releases, is included in the distribution. Individual change log files are also available on the ftp site, the current one being:- * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.76 * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.76.gz Brief documentation for new features is available in the NewStuff file in the distribution. Individual NewStuff files are also available on the ftp site, the current one being:- * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.76 * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.76.gz _________________________________________________________________ Security notes for 4.75: Disabling DKIM verification will avoid the security issues. This can be done without recompilation by adding to the start of your RCPT ACL the line: warn control = dkim_disable_verify In addition, not defining an ACL for acl_smtp_dkim will avoid the lesser security issue, which permits a crafted DKIM identity to cause matching to be performed against lookup items, not just strings. I believe that the results will not be included in an email or non-debug logs, so this results in attacker-controlled file-system access, tripping IDS systems but not offering an avenue of attack. Our quick fix for the latter issue does have the side-effect of falsely rejecting some (unusual) DKIM signatures, which we do not believe will have any material impact in the real world. We'll work on a more forgiving solution for a future release. _________________________________________________________________ Release Checksums SHA1: b0df27b0407eef2d79e130597916cde18f2bbe30 exim-4.76.tar.bz2 13121644a9dfd6c066f65db4ad6703a3dc432c8a exim-4.76.tar.gz a3ca9861f7d77188a38f251e5d1d5050b76332cd exim-html-4.76.tar.bz2 fd2ce339fc184463ce6766c5a70bb30306dcbbdb exim-html-4.76.tar.gz 80cafed859a78772b1c7ab6eae98c8ef44ad6c97 exim-pdf-4.76.tar.bz2 85572f9083e42368065e8d4791e2b435934da37f exim-pdf-4.76.tar.gz a63c9e6327447e13f9c4ad6a213c9da5e22019db exim-postscript-4.76.tar.bz2 7e46742a2700c4066d446e3bc0cb245470abdb03 exim-postscript-4.76.tar.gz SHA256: 4625b0fb916835ae60a73311a8956267fa1248e888f584c337a5b7df20174e95 exim-4.76.tar.bz2 9976c9efe6c304b1bf891a1695931aa5d18dc374f7d77e2fa082aac753b2272d exim-4.76.tar.gz 744ae2d523d937c133ae8877dc2262310a8ab2e4f6bbe38f494f7af52b3b9e88 exim-html-4.76.tar.bz2 77a445f12060c29de0b11055b9391c088660a7a14508b1000fb1e92750bbe156 exim-html-4.76.tar.gz 58ee11f0e0f518a39ee1b53d68e69aa44de5d9e8da8adcfe77dbe51a1b7a7a68 exim-pdf-4.76.tar.bz2 c1d2419f8bcce4c94bec70c0ad1c5359ea4d58223c5b17ea5dd38030c7b1b263 exim-pdf-4.76.tar.gz 1890533456cafe4f805298f363bad5cde297ca5535c4cf806c9bde60d16238e5 exim-postscript-4.76.tar.bz2 47874011ae0765b293189aab5fd5475fca7113453bc98abe7be72e889abff37b exim-postscript-4.76.tar.gz - -Phil Pennock, pp The Exim Maintainers. -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk3HsOYACgkQQDBDFTkDY3/iBwCfUM6bqRizoj/3x5iaBLyAv4I4 7HMAnA66ZJUUBN515RAoGIKLApR+Siwj =whAV -----END PGP SIGNATURE----- </pre> Phil Pennock 2011-05-09T09:16:32 http://comments.gmane.org/gmane.mail.exim.announce/136 <pre>Exim release 4.72 is now available from the primary ftp site: * ftp://ftp.exim.org/pub/exim/exim4/exim-4.72.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-4.72.tar.bz2 _________________________________________________________________ The changes involved are:- 1. TWO SECURITY FIXES: one relating to mail-spools which are globally writable, the other to locking of MBX folders (not mbox). These have CVE identifiers CVE-2010-2023 and CVE-2010-2024 2. MySQL stored procedures are now supported. 3. The dkim_domain transport option is now a list, not a single string, and messages will be signed for each element in the list (discarding duplicates). 4. The 4.70 release unexpectedly changed the behaviour of dnsdb TXT lookups in the presence of multiple character strings within the RR. Prior to 4.70, only the first string would be returned. The dnsdb lookup now, by default, preserves the pre-4.70 semantics, but also now takes an extended output separator specification. The separator can be followed by a semicolon, to concatenate the individual text strings together with no join character, or by a comma and a second separator character, in which case the text strings within a TXT record are joined on that second character. Administrators are reminded that DNS provides no ordering guarantees between multiple records in an RRset. For example: foo.example. IN TXT "a" "b" "c" foo.example. IN TXT "d" "e" "f" ${lookup dnsdb{&gt;/ txt=foo.example}} -&gt; "a/d" ${lookup dnsdb{&gt;/; txt=foo.example}} -&gt; "def/abc" ${lookup dnsdb{&gt;/,+ txt=foo.example}} -&gt; "a+b+c/d+e+f" Due to packaging build issues no texinfo documentation files have been produced - however they should be build-able from the documentation source should you have the correct toolchain available. _________________________________________________________________ The primary ftp server is in Cambridge, England. There is a list of mirrors in: * http://www.exim.org/mirmon/ftp_mirrors.html The master ftp server is now ftp.exim.org. The distribution files are signed with Nigel Metheringham's GPG key (address is nigel&lt; at &gt;exim.org, key id is DDC03262), which is available on the ftp site and on a number of keyservers. The ASCII signature files are in the same directory as the tarbundles. The SHA1 hashes for the distribution files are: 3aab453faaa076a6b5f02320d7f8ad8aba21b347 exim-4.72.tar.bz2 261c02c95b4d3aada73840b01f836e6874841c44 exim-4.72.tar.gz 3e8434b1a07bcb92235233db6a7f6dbda8802c75 exim-html-4.72.tar.bz2 6c5ee19c154ba12004b38dc74f7015cc668570c0 exim-html-4.72.tar.gz 9d1a5517d52ec5730d1e552740adf2beb37349ab exim-pdf-4.72.tar.bz2 3bd08fb77574a712944aff00a1add482b64a2b7d exim-pdf-4.72.tar.gz cf95726555dbc999aff3c2e884f4508933a6a875 exim-postscript-4.72.tar.bz2 3094cdc4a63308dd62f41d09079d6ae4c76c56cb exim-postscript-4.72.tar.gz The distribution contains an ASCII copy of the 4.72 manual and other documents. Other formats of the documentation are also available: * ftp://ftp.exim.org/pub/exim/exim4/exim-html-4.72.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-pdf-4.72.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-postscript-4.72.tar.gz The .bz2 versions of these tarbundles are also available. The ChangeLog for this, and several previous releases, is included in the distribution. Individual change log files are also available on the ftp site, the current one being: * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.72 * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.72.gz Brief documentation for new features is available in the NewStuff file in the distribution. Individual NewStuff files are also available on the ftp site, the current one being: * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.72 * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.72.gz _________________________________________________________________ Many thanks to all those involved in updating and testing this release. </pre> Nigel Metheringham 2010-06-03T12:48:41 http://comments.gmane.org/gmane.mail.exim.announce/135 <pre>I've been expecting this for a number of years, but its finally hit us... We have had 2 instances today of spam sent to these lists from subscribers, neither of which was picked up by the content scanning. So I've made 2 sets of changes to the list configurations:- 1. All lists now have new members set to be moderated. We will then take them off moderation when they post on-subject messages to the list. 2. All lists other than the exim-users lists have had all existing members set to be moderated. Again users will be taken off moderation as we approve messages from them. All of the affected lists are relatively low traffic. This will mean longer delays on postings until people get set non-moderated. Sorry for that, but I'd prefer to keep the lists relatively spam free, despite it being something like trying to keep back the sea. Nigel. -- [ Nigel Metheringham Nigel.Metheringham&lt; at &gt;InTechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] </pre> Nigel Metheringham 2010-05-18T13:35:43 http://comments.gmane.org/gmane.mail.exim.announce/134 <pre>Exim release 4.71 is now available from the primary ftp site: * ftp://ftp.exim.org/pub/exim/exim4/exim-4.71.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-4.71.tar.bz2 ===================================================================== This release is a pure bug fix release over version 4.70. The main changes are:- * Bugzilla 912: Fix DKIM segfault on empty headers/body * Bugzilla 913: Documentation fix for gnutls_* options. * Bugzilla 722: Documentation for randint. Better randomness defaults. * Bugzilla 847: Enable DNSDB lookup by default. * Bugzilla 915: Flag broken perl installation during build. There are a few other minor build and test suite changes. As usual, all changes are in the doc/ChangeLog file, which can also be seen at http://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.71 New features in 4.70 (and hence in 4.71) can be seen in http://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.71 ===================================================================== The primary ftp server is in Cambridge, England. There is a list of mirrors in: * http://www.exim.org/mirmon/ftp_mirrors.html The master ftp server is now ftp.exim.org. The distribution files are signed with Nigel Metheringham's GPG key (address is nigel&lt; at &gt;exim.org, key id is DDC03262), which is available on the ftp site and on a number of keyservers. The ASCII signature files are in the same directory as the tarbundles. The SHA1 hashes for the distribution files are: 4b8f853843edcfa4f3bfbb4bef45d8dcff2fc990 exim-4.71.tar.bz2 8198c70892ba8ce1a1c550b0d19bc7590814c535 exim-4.71.tar.gz f8975ea773b938f0aae92c94311202c2d79bb466 exim-html-4.71.tar.bz2 94f7a9daf6cc38cf1dfa1cd87a3796696730a8b0 exim-html-4.71.tar.gz 9c2da57f0b0996ab89a3ed304fa1816860f73ed1 exim-info-4.71.tar.bz2 ab6aa92ae8ed1223756ebce70db5e1a0e1a5edd7 exim-info-4.71.tar.gz c7f70e2d91fa50d61a02eff201dfcb066a6d72a8 exim-pdf-4.71.tar.bz2 24d8930cf058c1a723d1d40ca9c784a0e020d8a4 exim-pdf-4.71.tar.gz 7397161970369f3a6b2ef09b5b2a70391c03c1a3 exim-postscript-4.71.tar.bz2 76ab0a7129f1e64b168b7e23006c80100a020d6c exim-postscript-4.71.tar.gz 8b77d63b40436665bc1421ed106ed966cb385735 exim-texinfo-4.71.tar.bz2 809a7c7197b73f32bbe4250f5f56d90eeff3a42e exim-texinfo-4.71.tar.gz ===================================================================== The distribution contains an ASCII copy of the 4.71 manual and other documents. Other formats of the documentation are also available: * ftp://ftp.exim.org/pub/exim/exim4/exim-html-4.71.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-pdf-4.71.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-postscript-4.71.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-texinfo-4.71.tar.gz The .bz2 versions of these tarbundles are also available. The ChangeLog for this, and several previous releases, is included in the distribution. Individual change log files are also available on the ftp site, the current one being: * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.71 * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.71.gz Brief documentation for new features is available in the NewStuff file in the distribution (although this was not fully updated before release). Individual NewStuff files are also available on the ftp site, the current one being: * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.71 * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.71.gz ===================================================================== </pre> Nigel Metheringham 2009-11-24T12:39:20 http://comments.gmane.org/gmane.mail.exim.announce/133 <pre>Exim release 4.70 is now available from the primary ftp site: * ftp://ftp.exim.org/pub/exim/exim4/exim-4.70.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-4.70.tar.bz2 ===================================================================== This release is a combination feature and bug fix release. The major new features are:- * Native DKIM support without an external library. * Experimental DCC support via dccifd (contributed by Wolfgang Breyha). Other changes:- * PCRE is no longer included with the Exim distribution. You will need a separate PCRE library (and matching headers) to compile Exim. You will need to change your Local/Makefile to support this. Most modern systems have a packaged PCRE library, alternatively PCRE can be found at http://www.pcre.org/ * Experimental Yahoo! Domainkeys support dropped in favor of native DKIM support. * The documentation has been updated and regenerated. As usual, all changes are in the doc/ChangeLog file, which can also be seen at http://vcs.exim.org/viewvc/exim/exim-doc/doc-txt/ChangeLog?view=markup&amp;pathrev=exim_4_70 ===================================================================== The primary ftp server is in Cambridge, England. There is a list of mirrors in: * http://www.exim.org/mirmon/ftp_mirrors.html The master ftp server is now ftp.exim.org. The distribution files are signed with Nigel Metheringham's GPG key (address is nigel&lt; at &gt;exim.org, key id is DDC03262), which is available on the ftp site and on a number of keyservers. The ASCII signature files are in the same directory as the tarbundles. The SHA1 hashes for the distribution files are: 012d32acb63342f60d50f8905e20acb2f73f59b0 exim-4.70.tar.bz2 9483cf513f9b9b5a60e8228e88962c549b542f9d exim-4.70.tar.bz2.asc f758ad1d31fa4b1dec538a160668e6f2b676a8a2 exim-4.70.tar.gz 248804500e01569383d84ae9e886e53cc62e6877 exim-4.70.tar.gz.asc 45c7e09dc0fafa62c31da880b96a9acef8d28ff5 exim-html-4.70.tar.bz2 f6126e084bfa6128069a06e86fa07140f3a5bf43 exim-html-4.70.tar.gz ff80170aba79c25b773625c8e9f934690b714d7c exim-info-4.70.tar.bz2 716a3ffac67e33ba325549b1cfc250286b97f9c9 exim-info-4.70.tar.gz f429a6cc6c6e388f9ad0775a77fe6bedc56027bb exim-pdf-4.70.tar.bz2 8f6c604c766333b6f78655bea90fd82d6701c69d exim-pdf-4.70.tar.gz 20f5dbafaea4c6ea8c8833b54743c451d6ae1735 exim-postscript-4.70.tar.bz2 b11e3b688dd1a05a92621442452da73e92b9ee98 exim-postscript-4.70.tar.gz d7e2269330a437b92723795e3ff8577672480d12 exim-texinfo-4.70.tar.bz2 1396e1ed0b91a7ab4a0682ec15d52a4ee0c6f169 exim-texinfo-4.70.tar.gz ===================================================================== The distribution contains an ASCII copy of the 4.70 manual and other documents. Other formats of the documentation are also available: * ftp://ftp.exim.org/pub/exim/exim4/exim-html-4.70.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-pdf-4.70.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-postscript-4.70.tar.gz * ftp://ftp.exim.org/pub/exim/exim4/exim-texinfo-4.70.tar.gz The .bz2 versions of these tarbundles are also available. The ChangeLog for this, and several previous releases, is included in the distribution. Individual change log files are also available on the ftp site, the current one being: * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.70 * ftp://ftp.exim.org/pub/exim/ChangeLogs/ChangeLog-4.70.gz Brief documentation for new features is available in the NewStuff file in the distribution (although this was not fully updated before release). Individual NewStuff files are also available on the ftp site, the current one being: * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.70 * ftp://ftp.exim.org/pub/exim/ChangeLogs/NewStuff-4.70.gz ===================================================================== </pre> Nigel Metheringham 2009-11-14T09:14:51 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.mail.exim.announce