fetchmail-6.4.0.rc3 release candidate - please translate to your language, and test!

Matthias Andree <[email protected]> Sat, 24 Aug 2019 12:51:35 +0200
Newsgroups gmane.mail.fetchmail.announce
Message-ID <[email protected]>
--===============4638323078329461066==
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT"
Content-Disposition: inline


--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

I have released fetchmail-6.4.0.rc3, it is available from sourceforge.net,
see: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>

Since rc2,
* several documentation fixes were made,=20
* fetchmailconf was fixed to be able to edit the first server, or user,
  from a list,
* and I figured that --help strings for --sslproto and --auth were way off,
  and three source files were not listed in POTFILES.in so their strings
  were never offered for translation, and would always be in English.
> We have translation string changes unfortunately.
* cs ja sv translations are at -rc2 level.

I have mailed the URL of the tarball to the translation project,=20
=3D=3D=3D PLEASE DO TRANSLATE =3D=3D=3D
(and if you need more than a few days, let me know)

Note that I have disabled installing translations for these languages
since they have < 500 translated strings out of 714:
Greek, Finnish, Galician, Brazilian Portuguese, Slovak, Turkish.

I solicit thorough testing, I plan to not hold off on the release much long=
er,
no matter what the TODO.txt says.  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 releas=
e on
the order of weeks.  I am hoping that I can got for a release in 2019Q3.

The changes below are taken from the NEWS file and are versus 6.3.26.
Changes since 6.4.0.rc1 are marked with a "+":

---------------------------------------------------------------------------=
-----
 # ADVANCE WARNING OF FEATURES TO BE REMOVED OR CHANGED IN FUTURE VERSIONS
 (this only lists additions since 6.4.0-rc1)
+* 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.
+* Fetchmailconf is deprecated and will be removed from a future release.
=20
 --------------------------------------------------------------------------=
------
=20
 fetchmail-6.4.0 (not yet released): (this lists changes since 6.3.26)
=20
 # NOTE THAT FETCHMAIL IS NO LONGER PUBLISHED THROUGH IBIBLIO.
 * They have stopped accepting submissions and consider themselves an archi=
ve.
=20
 ## SECURITY FIXES THAT AFFECT BEHAVIOUR AND MAY REQUIRE RECONFIGURATION
 * Fetchmail no longer supports SSLv2.
=20
 * 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 t=
hese
   versions, --sslproto ssl3 and --sslproto ssl3+ can be used to re-enable =
SSLv3.
   Doing so is discouraged because the SSLv3 protocol is broken.
=20
   Along the lines suggested - as patch - by Kurt Roeckx, Debian Bug #76884=
3.
=20
   While this change is supposed to be compatible with common configuration=
s,
   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.
=20
   The --sslproto option now understands the values auto, ssl3+, tls1+, tls=
1.1,
   tls1.1+, tls1.2, tls1.2+, tls1.3, tls1.3+ (case insensitively), see CHAN=
GES
   below for details.
=20
 * Fetchmail defaults to --sslcertck behaviour. A new option --nosslcertck =
to
   override this has been added, but may be removed in future fetchmail ver=
sions
   in favour of another configuration option that makes the insecurity in u=
sing
   this option clearer.
=20
 ## SECURITY FIXES
 * Fetchmail prevents buffer overruns in GSSAPI authentication with user na=
mes
   beyond c. 6000 characters in length. Reported by Greg Hudson.
=20
 ## 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 --sslproto auto and --sslproto tls1+ (same as ssl=
23).
 * --sslproto tls1.1+, tls1.2+, and tls1.3+ are now supported for
   auto-negotiation with a minimum specified TLS protocol version, and --ss=
lproto
   tls1.1, --sslproto tls1.2 and --sslproto tls1.3 to force the specified T=
LS
   protocol version. Note that tls1.3 requires OpenSSL v1.1.1 or newer.
 * Fetchmail now detects if the server hangs up prematurely during SSL_conn=
ect()
   and reports this condition as such, and not just as SSL connection failu=
re.
   (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 c=
opy is
   running in the background.
 * fetchmail now handles POP3 --keep UID lists more efficiently, by using R=
ainer
   Weikusat's P-Tree implementation. This reduces the complexity for handli=
ng
   a large UIDL from O(n^2) to O(n log n) and becomes noticably faster with
   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 its=
elf 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 now sets the expected hostname through OpenSSL 1.0.2's new=20
   X509_VERIFY_PARAM_set1_host() function to enable OpenSSL's native certif=
icate
   verification features.
 * fetchmail will drop the connection when fetching with IMAP and receiving=
 an
   unexpected untagged "* BYE" response, to work around certain faulty serv=
ers.
 * 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 l=
ibrary
   dependencies. (contributed by Fabrice Fontaine, GitLab merge request !14=
=2E)
 * The gethostbyname() API calls and compatibility functions have been remo=
ved.
+* These translations are shipped but not installed by default because
+  they have less than 500 translated messages out of 714: el fi gl pt_BR s=
k tr
+  -> Greek, Finnish, Galician, Brazilian Portuguese, Slovak, Turkish.
=20
 ## 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=
=E9rez de
   Olaguer C=F3rdoba, 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 authentica=
tion.
   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 t=
he
   security check on the next run.  Reported by Fabian Raab,
   Fixes Debian Bug#831611.
 * When forwarding by LMTP, also check antispam response code when collecti=
ng
   the responses after the CR LF . CR LF sequence at the end of the DATA ph=
ase.
   (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-fetc=
hes
   of known mail.  (Fix contributed by Lauri Nurmi, GitLab Merge Request !1=
0.)
+* fetchmail no longer reports "System error during SSL_connect(): Success."
+  Fixes Debian Bug#928916, reported by Paul Kimoto.
=20
 ## UPDATED TRANSLATIONS - THANKS TO:
 * CS: Petr Pisar <[email protected]> [Czech]
 * EO: Felipe Castro <[email protected]> [Esperanto]
 * FR: Fr=E9d=E9ric Marchal <[email protected]> [French]
 * JP: Takeshi Hamasaki <[email protected]> [Japanese]
 * PL: Jakub Bogusz <[email protected]> [Polish]
 * SV: G=F6ran Uddeborg <[email protected]> [Swedish]
=20
 # 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)
+* 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.=20
+  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 lex=
er in
   64-bit mode.  Either compile 32-bit code or use GCC to compile 64-bit
   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.
---------------------------------------------------------------------------=
-----

Happy fetches,
Matthias

--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAl1hFrcACgkQ5BKxVu/z
hVrIag//Q3zvfeP2583uTYF0RIxeW9Wnq1Tn76jhDnjEIqNgPuhn5NSA/4vdhHtt
5wLB3QaYMlPsj9ScT44XoZMJVVJKrNQ85V4VhBFye1lCRvCCMhyFsYrijYYywApj
vLDasWl+HyqgzPk6cr6YAr76Hepbs2XInF3Hy8zeOBxl9NitheIGb0JLXsT9O1wl
irDfwFuU0qm8PRFGl13HV+zb8MG+xMK86hDf5XCbMdIVSid1tbKG4rYGavhc+8gr
Mba83honVedlB4vdr5ARB7u8mEgNErQ0Gh1WYx6fagT+yS19JnHr//A++oBTPYYB
YzKYmjkU8mzbVx5f1VBjzFg+CxanI81FfNhqfyKjokodDcFp1py3NG7DdOKUNXJs
u3Un5ecXIuhL07uC8+y3bxOFVgd6gzgrYIC+o+mPIvCAnEe4Fc0UGhXAJSJXZX7e
t/zGigBJYex0EqKv0j+rxEDwnJLN4APdVOVaR1ybOq1JES0nqTDZzw7moJvajZs8
UszK+PAG6HKjujs3YIkl3JFyFPdikHeMk7xSO1kRVqtOMoRldxAm3KpXncBKCzs1
QrKtXNy8pY8jsZDZtxtVQgw+jWty8sH95MtYVn/qC47zZGnotq0RbaSkZOH0279J
I9cx9xbc2tSIsRxTvJMGdirXxfoWjmLUp304v8398JPXfKXf+D4=
=u7c7
-----END PGP SIGNATURE-----

--X1bOJ3K7DJ5YkBrT--


--===============4638323078329461066==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============4638323078329461066==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Fetchmail-announce mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fetchmail-announce

--===============4638323078329461066==--