diff options
| -rw-r--r-- | NEWS | 29 | ||||
| -rw-r--r-- | README | 8 | ||||
| -rw-r--r-- | README.SSL | 34 | ||||
| -rw-r--r-- | README.SSL-SERVER | 9 | ||||
| -rw-r--r-- | fetchmail.man | 3 |
5 files changed, 54 insertions, 29 deletions
@@ -11,6 +11,13 @@ change. MA = Matthias Andree, ESR = Eric S. Raymond, RF = Rob Funk.) # 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.) +* Future fetchmail releases may require compilers and operating systems + that adhere to standards issued 2011 or later. + (Currently, C89 and Single Unix Specification V2 should suffice.) +* Future fetchmail releases may tighten up security and lean towards + it a bit more by, for instance, implementing recommendations from + RFC-7817 or RFC-8314. This may, for instance, require that TLS v1.1 + or newer be used. * 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. @@ -22,7 +29,6 @@ removed from a 6.4.0 or newer release.) * 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 @@ -96,8 +102,6 @@ fetchmail-6.4.0 (not yet released): * 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 @@ -111,7 +115,8 @@ fetchmail-6.4.0 (not yet released): * 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.) + thousands of kept messages. + (IMAP does not currently 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 @@ -119,11 +124,11 @@ fetchmail-6.4.0 (not yet released): * 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. +* fetchmail will drop the connection when fetching with IMAP and receiving an + unexpected untagged "* BYE" response, to work around certain faulty servers. * 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. @@ -150,14 +155,15 @@ fetchmail-6.4.0 (not yet released): 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. + security check on the next run. Reported by Fabian Raab, + Fixes 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.) -* fetchmail no longer reports System error during SSL_connect(): Success. +* fetchmail no longer reports "System error during SSL_connect(): Success." Fixes Debian Bug#928916, reported by Paul Kimoto. ## UPDATED TRANSLATIONS - THANKS TO: @@ -173,11 +179,14 @@ fetchmail-6.4.0 (not yet released): current release information) * Fetchmail does not handle messages without Message-ID header well (See sourceforge.net bug #780933) +* Fetchmail currently uses 31-bit signed integers in several places + where unsigned and/or wider types should have been used, for instance, + for mailbox sizes, and misreports sizes of 2 GibiB and beyond. + Fixing this requires C89 compatibility to be relinquished. * 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. * 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. @@ -38,6 +38,14 @@ the system is at least Single-Unix-Specification V2 compatible, yet will permit a C89 compiler. It currently ships with a copy of the trio library for systems that lack snprintf(). +Fetchmail should be able to be compiled with C89, C99, C11, C++98, C++03, +C++11, C++14 compilers, but not C++17 because the "register" keyword is +used in some parts of the code. + +Future fetchmail releases will require modern language features such as +"long long" and others, so this release is the last to support C89. + + Further reading --------------- @@ -11,10 +11,9 @@ specific to fetchmail. In case of troubles, mail the README.SSL-SERVER file to your ISP and have them check their server configuration against it. -Unfortunately, fetchmail confuses SSL/TLS protocol levels with whether a -service needs to use in-band negotiation (STLS/STARTTLS for POP3/IMAP4) -or is totally SSL-wrapped on a separate port. For compatibility -reasons, this cannot be fixed in a bugfix or minor release. +Note that fetchmail up to version 6.3.26 confused SSL/TLS protocol levels with +whether a service needs to use in-band negotiation (STLS/STARTTLS for +POP3/IMAP4) or is totally SSL-wrapped on a separate port. Also, fetchmail 6.4.0 and newer releases changed some of the semantics as the result of a bug-fix, and will auto-negotiate TLSv1 or newer only. @@ -22,15 +21,19 @@ If your server does not support this, you may have to specify --sslproto ssl3+. This is in order to prefer the newer TLS protocols, because SSLv2 and v3 are broken. - -- Matthias Andree, 2016-01-10 + -- Matthias Andree, 2019-08-18 Quickstart ---------- Use an up-to-date release of OpenSSL 1.0.2 or newer, so as to get -TLSv1.2 support. Older OpenSSL versions are unsupported upstream, and -fetchmail rejects them. +TLSv1.2 support. If possibly use a TLS1.3-enabled OpenSSL v1.1.1 or newer. +Older OpenSSL versions are unsupported upstream, and fetchmail rejects them. + +In all four examples below, the (--)sslcertck has become redunant +since fetchmail v6.4.0 but since fetchmail 6.3 releases will be in circulation +for a while, we'll leave it here to be safe. For use of SSL or TLS with in-band negotiation on the regular service's port, i. e. with STLS or STARTTLS, use these command line options @@ -56,9 +59,9 @@ or these options in the rcfile (after the respective "user"... options) Background and use (long version :-)) ------------------ -Using fetchmail's "ssl" option, you can have the data transferred between you -and the server in an encrypted form, so that eavesdropping should become -practically impossible. +Using fetchmail's "ssl" and since 6.4.0 "sslproto" options, +you can have the data transferred between you and the server in an encrypted +form, so that eavesdropping should become practically impossible. This works as follows: the server has a key pair (a secret and a public key), and it sends the client its public key. Messages encrypted with the public key @@ -86,10 +89,11 @@ document). This certificate contains the server's public key, some data about the server, and a digital signature and data about the signer. Digital signatures can also be made using a key pair as described earlier. -To check this certificate, you should use the new option "sslcertck". When it -is specified, the signature of the server certificate is checked against local -trusted certificates to see whether the owner of one of the certificates has -signed that server certificate, and if so, whether the signature is valid. +To check this certificate, you should use the new option "sslcertck" (fetchmail +6.4.0 and newer enable it by default). When it is specified, the signature of +the server certificate is checked against local trusted certificates to see +whether the owner of one of the certificates has signed that server +certificate, and if so, whether the signature is valid. So, if the server certificate is signed by a Certification Authority (CA), you put the CA's certificate into a directory where you keep trusted certificates, and point fetchmail to it. Fetchmail will then accept @@ -141,7 +145,5 @@ with a ":" separating two bytes (i.e. a ":" between every two hex "digits"). The match is case insensitive since release 6.3.10 (upper-case digits A to F were required up to and including release 6.3.9). -*CAVEAT*: OpenSSL must be at least version 0.9.7 to be able to check CRLs. - - Thomas Moestl <tmoestl@gmx.net> - Matthias Andree diff --git a/README.SSL-SERVER b/README.SSL-SERVER index ae833e60..60a7d332 100644 --- a/README.SSL-SERVER +++ b/README.SSL-SERVER @@ -25,8 +25,9 @@ are several requirements that need to be fulfilled. authority (CA). If your server certificate is not directly signed by the root certification - authority (root CA), then you are using intermediate CA. In this case, you - *MUST* (as per the TLS standard) provide *ALL* intermediate certificates. + authority (root CA), then you are using an intermediate CA. In this case, + you *MUST* (as per the TLS standard) provide *ALL* intermediate + certificates. If you fail to provide intermediate certificates, clients can only connect if the end user overrides/disables security warnings in his/her software, @@ -62,3 +63,7 @@ are several requirements that need to be fulfilled. readily available at least in MD5 and SHA1 formats and offer to clients and be ready to answer client questions as to the fingerprints (for verification) and installation in commonly used clients. + + Many systems will install the Mozilla root certificate bundle in an + easy to find place, so if you are signing your certificates by a CA + that Mozilla trusts, this helps many users. diff --git a/fetchmail.man b/fetchmail.man index 2855eacb..875bb016 100644 --- a/fetchmail.man +++ b/fetchmail.man @@ -1285,7 +1285,7 @@ different well known ports defined for the SSL encrypted services. The encrypted ports will be selected automatically when SSL is enabled and no explicit port is specified. Also, the \-\-sslcertck command line or sslcertck run control file option should be used to force strict -certificate checking - see below. +certificate checking with older fetchmail versions - see below. .PP If SSL is not configured, fetchmail will usually opportunistically try to use STARTTLS. STARTTLS can be enforced by using \-\-sslproto\~auto and @@ -1912,6 +1912,7 @@ Specify file for \fBclient side\fP public SSL certificate T} sslcertck \& \& T{ Enable strict certificate checking and abort connection on failure. +Default only since fetchmail v6.4.0. T} no sslcertck \& \& T{ Disable strict certificate checking and permit connections to continue |