Menu
▾
▴
[Fetchmail-devel] fetchmail-6.4.0.rc1 release candidate - please test and translate
|
From: Matthias A. <mat...@gm...> - 2019-08-05 12:47:15
|
[resent with corrected Subject: and cross-mailed to fetchmail-users and -announce for higher exposure] Greetings, I have released fetchmail-6.4.0.rc1, it is available from sourceforge.net, see: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/> I have mailed the URL of the tarball to the translation project, and solicit thorough testing, I plan to not hold off on the release much longer, no matter what the TODO.txt says for 6.4.0. We need to get the SSL changes and other important fixes out the door, and as translations show up, I plan to release either another release candidate (if required) or else 6.4.0 release on the order of weeks. I have also pulled in the latest partial translations of -Andhika Padmawan - Indonesian <id> -Besnik Bleta - Albanian <sq> -Enrico Nicoletto - Brazilian Portuguese <pt_BR> -Ernest Adrogué Calveras - Catalan <ca> -Lauri Nurmi (1) - Finnish <fi> ### ^ note this is so incomplete I will not install it unless it's updated. The changes below are taken from the NEWS file and are versus 6.3.26. Changes since 6.4.0.beta5 are marked with a "+": -------------------------------------------------------------------------------- # NOTE THAT FETCHMAIL IS NO LONGER PUBLISHED THROUGH IBIBLIO. * They have stopped accepting submissions and consider themselves an archive. ## SECURITY FIXES THAT AFFECT BEHAVIOUR AND MAY REQUIRE RECONFIGURATION * Fetchmail no longer supports SSLv2. * Fetchmail no longer attempts to negotiate SSLv3 by default, even with --sslproto ssl23. Fetchmail can now use SSLv3, or TLSv1.1 or a newer TLS version, with STLS/STARTTLS (it would previously force TLSv1.0 with STARTTLS). If the OpenSSL version used at build and run-time supports these versions, --sslproto ssl3 and --sslproto ssl3+ can be used to re-enable SSLv3. Doing so is discouraged because the SSLv3 protocol is broken. Along the lines suggested - as patch - by Kurt Roeckx, Debian Bug #768843. While this change is supposed to be compatible with common configurations, users may have to and are advised to change all explicit --sslproto ssl2 (change to newer protocols required), --sslproto ssl3, --sslproto tls1 to --sslproto auto, so that they can benefit from TLSv1.1 and TLSv1.2 where supported by the server. The --sslproto option now understands the values auto, ssl3+, tls1+, tls1.1, tls1.1+, tls1.2, tls1.2+, tls1.3, tls1.3+ (case insensitively), see CHANGES below for details. * Fetchmail defaults to --sslcertck behaviour. A new option --nosslcertck to override this has been added, but may be removed in future fetchmail versions in favour of another configuration option that makes the insecurity in using this option clearer. ## SECURITY FIXES * Fetchmail prevents buffer overruns in GSSAPI authentication with user names beyond c. 6000 characters in length. Reported by Greg Hudson. ## CHANGES * fetchmail 6.3.X is unsupported. * fetchmail now configures OpenSSL support by default. * fetchmail now requires OpenSSL v1.0.2 or newer. * fetchmail now supports a pure OpenSSL v1.1.0 API with deprecated functions disabled. * Fetchmail now supports --sslproto auto and --sslproto tls1+ (same as ssl23). * --sslproto tls1.1+, tls1.2+, and tls1.3+ are now supported for auto-negotiation with a minimum specified TLS protocol version, and --sslproto tls1.1, --sslproto tls1.2 and --sslproto tls1.3 to force the specified TLS protocol version. Note that tls1.3 requires OpenSSL v1.1.1 or newer. * Fetchmail now detects if the server hangs up prematurely during SSL_connect() and reports this condition as such, and not just as SSL connection failure. (OpenSSL 1.0.2 reported incompatible with pop3.live.com by Jerry Seibert). * A foreground fetchmail can now accept a few more options while another copy is running in the background. * fetchmail now handles POP3 --keep UID lists more efficiently, by using Rainer Weikusat's P-Tree implementation. This reduces the complexity for handling a large UIDL from O(n^2) to O(n log n) and becomes noticably faster with thousands of kept messages. (IMAP does not track UIDs and is unaffected.) At the same time, the UIDL emulation code for deficient servers has been removed. It never worked really well. Servers that do not implement the optional UIDL command only work with --fetchall option set, which in itself is incompatible with the --keep option (it would cause message duplication). * fetchmail, when setting up TLS connections, now uses SSL_set_tlsext_host_name() to set up the SNI (Server Name Indication). Some servers (for instance googlemail) require SNI when using newer SSL protocols. * fetchmail will drop the connection when fetching with IMAP and receiving an unexpected untagged "* BYE" response, to work around certain faulty servers. * Fetchmail now sets the expected hostname through OpenSSL 1.0.2's new X509_VERIFY_PARAM_set1_host() function to enable OpenSSL's native certificate verification features. * The FETCHMAIL_POP3_FORCE_RETR environment variable is now documented, it forces fetchmail, when talking POP3, to always use the RETR command, even if it would otherwise use the TOP command. * Fetchmail's configure stage will try to query pkg-config or pkgconf for libssl and libcrypto, in case other system use .pc files to document specific library dependencies. (contributed by Fabrice Fontaine, GitLab merge request !14.) * The gethostbyname() API calls and compatibility functions have been removed. ## FIXES * Fix a typo in the FAQ. Submitted by David Lawyer, Debian Bug#706776. * Do not translate header tags such as "Subject:". Reported by Gonzalo Pérez de Olaguer Córdoba, Debian Bug#744907. * Convert most links from berlios.de to sourceforge.net. * Report error to stderr, and exit, if --idle is combined with multiple accounts. * Point to --idle from GENERAL OPERATION to clarify --idle and multiple mailboxes do not mix. In response to Jeremy Chadwick's trouble 2014-11-19, fetchmail-users mailing list. * Fix SSL-enabled build on systems that do not declare SSLv3_client_method(), or that #define OPENSSL_NO_SSL3 inside #include <openssl/ssl.h> Related to Debian Bug#775255. Fixes Debian Bug #804604. * Version report lists -SSLv3 on SSL-enabled no-ssl3 builds. * Fetchmail no longer adds a NUL byte to the username in GSSAPI authentication. This was reported to break Kerberos-based authentication with Microsoft Exchange 2013 by Greg Hudson. * Set umask properly before writing the .fetchids file, to avoid failing the security check on the next run. Reported by Fabian Raab, Debian Bug#831611. * When forwarding by LMTP, also check antispam response code when collecting the responses after the CR LF . CR LF sequence at the end of the DATA phase. (Contributed by Evil.2000, GitLab merge request !12.) * fetchmail will not try other protocols after a socket error. This avoids mismatches of how different prococols see messages as "seen" and re-fetches of known mail. (Fix contributed by Lauri Nurmi, GitLab Merge Request !10.) ## UPDATED TRANSLATIONS - THANKS TO: +* CS: Petr Pisar <pet...@at...> [Czech] +* EO: Felipe Castro <fe...@gm...> [Esperanto] +* FR: Frédéric Marchal <fma...@pe...> [French] +* JP: Takeshi Hamasaki <hm...@us...> [Japanese] +* PL: Jakub Bogusz <qb...@pl...> [Polish] +* SV: Göran Uddeborg <go...@ud...> [Swedish] # KNOWN BUGS AND WORKAROUNDS (This section floats upwards through the NEWS file so it stays with the current release information) * Fetchmail does not handle messages without Message-ID header well (See sourceforge.net bug #780933) * BSMTP is mostly untested and errors can cause corrupt output. * Sun Workshop 6 (SPARC) is known to miscompile the configuration file lexer in 64-bit mode. Either compile 32-bit code or use GCC to compile 64-bit fetchmail. Note that fetchmail doesn't take advantage of 64-bit code, so compiling 32-bit SPARC code should not cause any difficulties. * Fetchmail does not track pending deletes across crashes. * The command line interface is sometimes a bit stubborn, for instance, fetchmail -s doesn't work with a daemon running. * Linux systems may return duplicates of an IP address in some circumstances if no or no global IPv6 addresses are configured. (No workaround. Ubuntu Bug#582585, Novell Bug#606980.) * Kerberos 5 may be broken, particularly on Heimdal, and provide bogus error messages. This will not be fixed, because the maintainer has no Kerberos 5 server to test against. Use GSSAPI. -------------------------------------------------------------------------------- # ADVANCE WARNING OF FEATURES TO BE REMOVED OR CHANGED IN FUTURE VERSIONS (There are no plans to remove features from a 6.3.X release, but they may be removed from a 6.4.0 or newer release.) * The MX and host alias DNS lookups that fetchmail performs in multidrop mode are based on assumptions that are rarely met in practice, somewhat defective, deprecated and may be removed from a future fetchmail version. They have never supported IPv6 (including IPv6-mapped IPv4). Non-DNS based alias keywords such as "aka" will remain in fetchmail. * The monitor and interface options may be removed from a future fetchmail version as they are not reasonably portable across operating systems. * POP2 is obsolete, support will be removed from a future fetchmail version. * IMAP2 and IMAP4 (not IMAP4r1) are obsolete, support may be removed from a future fetchmail version. * RPOP is obsolete, support will be removed from a future fetchmail release. * --sslcertck will become a default setting in a future fetchmail version. * The multidrop To/Cc guessing code along with the fragile duplicate suppressor is deprecated and may be removed from a future release. * The "envelope Received" option may be removed from a future release, because the Received header was never meant to be machine-readable, the format varies widely, and various other differences in behavior make parsing Received an unreliable undertaking. The envelope option as such will remain though, in order to support Delivered-To, X-Envelope-To, X-Original-To and similar. See also <http://home.pages.de/~mandree/mail/multidrop>. * The --enable-fallback (fall back to MDA if MTA unavailable) will be removed from a future fetchmail release, because it makes fetchmail's behavior inconsistent and confusing. * The "protocol auto" default inside fetchmail may be removed from a future fetchmail release. Explicit configuration of the protocol is recommended. * Kerberos IV support may be removed from a future fetchmail release. * Kerberos 5 support may be removed from a future fetchmail release. * The --principal option may be removed from a future fetchmail release. * SIGHUP wakeup support may be removed from a future fetchmail release and cause fetchmail to terminate - it was broken for many years. * Support for operating systems that are not sufficiently POSIX compliant may be removed or operation on such systems may be suboptimal for future releases. This means that fetchmail may only continue to work on C99 and POSIX 2001 based systems. * The maintainer may migrate fetchmail to C++ with STL or C#, and impose further requirements (dependencies), such as Boost or other class libraries. * The softbounce option default will change to "false" in the next release. * The --bsmtp - mode of operation may be removed in a future release. * Given that OpenSSL is severely underdocumented, and needs license exceptions, fetchmail may switch to a different SSL library. * SSLv3 support may be removed from a future fetchmail release. It has been obsolete for many years and found insecure. Use TLS. -------------------------------------------------------------------------------- Happy fetches, Matthias |
