fetchmail-devel — Development related discussion

Re: [Fetchmail-devel] TLS fingerprints, and option --pinnedpublickey <sha256//b64hash>

[Matthias A. <mat...@gm...>]

Am 21.03.20 um 09:11 schrieb grarpamp:
> FYI Re: The former thread with this subject.
>
> One of the main links in it has moved and is now here...
>
> https://owasp.org/www-project-cheat-sheets/cheatsheets/Pinning_Cheat_Sheet
> https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md
>
>
> Added github for the other link...
> https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
> https://github.com/OWASP/www-community/blob/master/pages/controls/Certificate_and_Public_Key_Pinning.md
>
Thank you for keeping the link collection up to date, that's valuable!

[Fetchmail-devel] TLS fingerprints, and option --pinnedpublickey <sha256//b64hash>

[grarpamp <gra...@gm...>]

FYI Re: The former thread with this subject.

One of the main links in it has moved and is now here...

https://owasp.org/www-project-cheat-sheets/cheatsheets/Pinning_Cheat_Sheet
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md


Added github for the other link...
https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
https://github.com/OWASP/www-community/blob/master/pages/controls/Certificate_and_Public_Key_Pinning.md

[Fetchmail-devel] ANNOUNCE: fetchmail-6.4.2 has been released today, 2020-02-14 (fetchmailconf overhaul, bugfixes)

[Matthias A. <mat...@gm...>]

Greetings,

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

It is a RECOMMENDED update for all users, it fixes one SSL bug, updates
the manual page and Chinese translation,
and brings fetchmailconf into the 2020's, by making it compatible with Python 3
(but it requires the future package, see below).

The distribution is now in lzip (*) format, but xz format remains available.
(*) https://www.nongnu.org/lzip/

Older releases are herewith officially unsupported.

Where to get it - Deep link to tarball:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.2.tar.lz/download>
How to verify:
GnuPG detached signature:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.2.tar.lz.asc/download>

RIPEMD160(fetchmail-6.4.2.tar.lz)= 87b8b51bb8c781ce59e817a4189cd76783ac313b
SHA1(fetchmail-6.4.2.tar.lz)= 5e3b1cffcf80634d4a9ac2b16d10c4260285fb6b
SHA256(fetchmail-6.4.2.tar.lz)= 971361dca9bea227154c715ee88098b8ffc66fd4dbdb0dbbf1c77ace59e1461a
SHA512(fetchmail-6.4.2.tar.lz)= f8f7466f1891ffd0a72a042e4b942056acf1c0f153f44cb096e5e0aa5847400257e2880a78eaa682db94074205d9a311449e9743ed6cd254a8732d3afe3ef9a0

RIPEMD160(fetchmail-6.4.2.tar.xz)= 16faf2d06aa568f14f334b6c616d6ac1a34983d2
SHA1(fetchmail-6.4.2.tar.xz)= cdd6f0f4c8b99be3d3950763c53472c4ad764312
SHA256(fetchmail-6.4.2.tar.xz)= e21f6b3326f29fdb0c4786b5602aa4b9e668805424d0708eb42be6395c1ca630
SHA512(fetchmail-6.4.2.tar.xz)= 8ec62a5df81b9b8c5e5479d35a10aded22aca74f671cded339dc7ae1c78d8a8638dfe4f04be35334184b5b27f3fb857402dc5b587cca8ede3f5b9b268b37edc1

Status:

I plan to only do bug fixes to fetchmail-6.4.x so that upgrading
to newer 6.4.x releases should be acceptable under many "stable branch"
maintenance policies. More intrusive changes will happen to versions
that have higher numbers such as 6.5.y or 7.n.m (with m, n, y being numbers).


These are the release notes from NEWS:

--------------------------------------------------------------------------------
fetchmail-6.4.2 (released 2020-02-14, 27473 LoC):

## BREAKING CHANGES:
* fetchmailconf now supports Python 3 and currently requires the "future" 
  package, see https://pypi.org/project/future/.
* fetchmailconf: The minimum supported version is now Python 2.7.13, but it is 
  recommended to use at least 2.7.16 (due to its massive SSL updates).
  Older Python versions may check SSL certificates not strictly enough,
  which may cause fetchmail to complain later, if the certificate verify fails.
* fetchmailconf now autoprobes SSL-wrapped connections (ports 993 and 995 for 
  IMAP and POP3) as well and by preference.
* fetchmailconf now defaults newly created users to "ssl" if either of the
  existing users sets ssl, or if the server has freshly been probed and
  found supporting ssl.
  There is a caveat: adding a user to an existing server without probing it
  again may skip adding ssl. (This does not prevent STARTTLS.)

## BUG FIXES:
* Fix three bugs in fetchmail.man (one unterminated string to .IP macro, one
  line that ran into a .PP macro, .TH date format), and remove one .br request 
  from inside the table, which is unsupported by FreeBSD 12's mandoc(1) 
  formatter.  FreeBSD Bug#241032, reported by Helge Oldach.
* Further man page fixes and additions by Chris Mayo and Gregor Zattler.
* When evaluating the need for STARTTLS in non-default configurations (SSL 
  certificate validation turned off), fetchmail would only consider --sslproto 
  tls1 as requiring STARTTLS, now all non-empty protocol versions do.
* fetchmailconf now properly writes "no sslcertck" if sslcertck is disabled.
* fetchmailconf now catches and reports OS errors (including DNS errors) when 
  autoprobing.  Reported as Gitlab issue #12 by Sergey Alirzaev.
* fetchmailconf received a host of other bugfixes, see the Git commit log.

## CHANGES:
* Make t.smoke more robust and use temporary directory as FETCHMAILHOME, to make
  sure that the home directory resolves for the user running the test suite
  even if the environment isn't perfect. Reported by Konstantin Belousov,
  analysed by Corey Halpin, FreeBSD Bug#240914.

## UPDATED TRANSLATION - THANKS TO:
* zh_CN: Boyuan Yang [Chinese (simplified)]

--------------------------------------------------------------------------------

Happy fetching,
Matthias

[Fetchmail-devel] The 6.4.2-rc3 release candidate #3 of fetchmail is available [fetchmailconf improvements]

[Matthias A. <mat...@gm...>]

[Re-sent announcement with fixed Subject: line.]

The 6.4.2-rc3 release of fetchmail is now available at the usual locations,
including <http://sourceforge.net/projects/fetchmail>.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.2-rc3.tar.lz>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.2-rc3.tar.xz>

Please test the revised fetchmailconf, it now also needs Python's "future"
package, supports Python 3, and learned how to autoprobe via SSL and/or IPv6.

These are the relevant changes from 6.4.2-rc2 to -rc3.
fetchmailconf.py is now at version 1.63.

NEWS: reword/reformat a bit.
fetchmailconf.py: hostname qualification fixup
fetchmailconf.py: Show hostname in configuration selector.
NEWS: mention fetchmailconf's improved error handling for OSErrors in get_greetline()
fetchmailconf: Catch errors from get_greetline()
fetchmailconf: Add missing line separator in RunWindow.
fetchmailconf: delete server entries properly.

[Fetchmail-devel] The 6.4.2-rc2 release candidate #2 of fetchmail is available [fetchmailconf improvements]

[Matthias A. <mat...@gm...>]

The 6.4.2-rc3 release of fetchmail is now available at the usual locations,
including <http://sourceforge.net/projects/fetchmail>.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.2-rc3.tar.lz>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.2-rc3.tar.xz>

Please test the revised fetchmailconf, it now also needs Python's "future"
package, supports Python 3, and learned how to autoprobe via SSL and/or IPv6.

These are the relevant changes from 6.4.2-rc2 to -rc3.
fetchmailconf.py is now at version 1.63.

NEWS: reword/reformat a bit.
fetchmailconf.py: hostname qualification fixup
fetchmailconf.py: Show hostname in configuration selector.
NEWS: mention fetchmailconf's improved error handling for OSErrors in get_greetline()
fetchmailconf: Catch errors from get_greetline()
fetchmailconf: Add missing line separator in RunWindow.
fetchmailconf: delete server entries properly.

[Fetchmail-devel] The 6.4.2-rc2 release candidate #2 of fetchmail is available [fetchmailconf improvements]

[Matthias A. <mat...@gm...>]

The 6.4.2-rc2 release of fetchmail is now available at the usual locations,
including <http://sourceforge.net/projects/fetchmail>.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.2-rc2.tar.lz>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.2-rc2.tar.xz>

Please test the revised fetchmailconf, it now also needs Python's "future"
package, supports Python 3, and learned how to autoprobe via SSL and/or IPv6.

These are the relevant changes from 6.4.2-rc1 to -rc2:

fetchmailconf: Bump version to 1.61.
fetchmailconf: Set window icon for window manager.
fetchmailconf: Add verbose/normal to run buttons of main window.
fetchmailconf: Check fetchmail's exit status from RunWindow()
fetchmailconf: Update RunWindow() line-wise.
fetchmailconf: Make RunWindow resizeable.
fetchmailconf: Omit unused 'parent' argument from RunWindow() constructor
fetchmailconf: Heed Exceptions in make_icon_window().
Fix missing 'from' in NEWS.

[Fetchmail-devel] The 6.4.2-rc1 release candidate #1 of fetchmail is available [with Python 3 compatible fetchmailconf!]

[Matthias A. <mat...@gm...>]

The 6.4.2-rc1 release of fetchmail is now available at the usual locations,
including <http://sourceforge.net/projects/fetchmail>.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.2-rc1.tar.lz>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.2-rc1.tar.xz>

Please test the revised fetchmailconf, it now also needs Python's "future"
package, supports Python 3, and learned how to autoprobe via SSL and/or IPv6.

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

Here are the release notes:

fetchmail 6.4.2 (not yet released):

## BREAKING CHANGES:
* fetchmailconf now supports Python 3 and currently requires the "future" 
  package, see https://pypi.org/project/future/.
* The minimum supported version is now Python 2.7.13, but it is recommended
  to use at least 2.7.16 (due to its massive SSL updates).
  Older Python versions may check SSL certificates not strictly
  enough which will may cause fetchmail to complain later when the
  certificate isn't compliant.
* fetchmailconf now autoprobes SSL-wrapped connections (ports 993 and 995 for 
  IMAP and POP3) as well and by preference.
* fetchmailconf now defaults newly created users to "ssl" if either of the
  existing users sets ssl, or if the server has freshly been probed and
  found supporting ssl.
  There is a caveat: adding a user to an existing server without probing it
  again may skip adding ssl. (This does not prevent STARTTLS.)

## BUG FIXES:
* Fix three bugs in fetchmail.man (one unterminated string to .IP macro, one line
  that ran into a .PP macro, .TH date format), and remove one .br request from
  inside the table, which is unsupported by FreeBSD 12's mandoc(1) formatter.
  FreeBSD Bug#241032, reported by Helge Oldach.
* Further man page fixes and additions by Chris Mayo and Gregor Zattler.
* When evaluating the need for STARTTLS in non-default configurations (SSL 
  certificate validation turned off), fetchmail would only consider --sslproto 
  tls1 as requiring STARTTLS, now all non-empty protocol versions do.
* fetchmailconf now properly writes "no sslcertck" if sslcertck is disabled.

## CHANGES:
* Make t.smoke more robust and use temporary directory as FETCHMAILHOME, to make
  sure that the home directory resolves for the user running the test suite
  even if the environment isn't perfect. Reported by Konstantin Belousov,
  analysed by Corey Halpin, FreeBSD Bug#240914.

## UPDATED TRANSLATION - THANKS TO:
* zh_CN: Boyuan Yang [Chinese (simplified)]

--------------------------------------------------------------------------------

By popular demand, diffs from the previous release have been omitted.

Happy fetches,
Matthias

[Fetchmail-devel] ANNOUNCE: fetchmail-6.4.1 has been released today, 2019-09-28 (regression fixes)

[Matthias A. <mat...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Greetings,

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

It is a RECOMMENDED update for all users, and fixes two regressions
in fetchmail 6.4.0 since 6.4.0-rc4.

fetchmail 6.4.0 has been withdrawn.

Lesson learnt: do not change *anything* but the release name between
release candidate and release.

Older releases are herewith officially unsupported.


Where to get it - Deep link to tarball:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.1.tar.xz/download>
How to verify:
GnuPG detached signature:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.1.tar.xz.asc/download>

RIPEMD160(fetchmail-6.4.1.tar.xz)= 753d982f132cd5dcedb261631b5bee653410fef9
SHA1(fetchmail-6.4.1.tar.xz)= 1aadf078ed8fb1b6c93e9126cc0375b1f740301a
SHA256(fetchmail-6.4.1.tar.xz)= 3f33f11dd08c3e8cc3e9d18eec686b1626d4818f4d5a72791507bbc4dce6a9a0
SHA512(fetchmail-6.4.1.tar.xz)= 940b8df52f963f71537962ebe2b2cb88298fd2b54ca79932e5c974abe850f0b59cdc4919d606ee4f210e82d1e0a6f090ea87f1d3bdea18b531d4fbb36f7f9ea0


Status:

I plan to only do bug fixes to fetchmail-6.4.x so that upgrading
to newer 6.4.x releases should be acceptable under many "stable branch"
maintenance policies. More intrusive changes will happen to versions
that have higher numbers such as 6.5.y or 7.n.m (with m, n, y being numbers).


These are the release notes from NEWS:

- --------------------------------------------------------------------------------

fetchmail-6.4.1 (released 2019-09-28, 27473 LoC):

## REGRESSION FIXES:
* The bug fix Debian Bug#941129 was incomplete and caused
  + a regression in the default file locations, so that fetchmail was no longer
    able to find it configuration files in some situations.
    Reported by Cy Schubert.
  + a regression under _FORTIFY_SOURCE where PATH_MAX > minimal _POSIX_PATH_MAX.

- --------------------------------------------------------------------------------

fetchmail-6.4.0 (released 2019-09-27, 27429 LoC):

# 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.

## CHANGED REQUIREMENTS
* fetchmail 6.4.0 is written in C99 and requires a SUSv3 (Single Unix
  Specification v3, a superset of POSIX.1-2001 aka. IEEE Std 1003.1-2001 with
  XSI extension) compliant system. For now, a C89 compiler should also work
  if the system is SUSv3 compliant.

  In particular, older fetchmail versions had workaround for several functions
  standardized in the Single Unix Specification v3, these have been removed.

  The trio/ library has been removed from the distribution.

## 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 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 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
  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
  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.
* 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.
* 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 sk tr
  -> Greek, Finnish, Galician, Brazilian Portuguese, Slovak, Turkish.
* Fetchmail now refuses delivery if the MDA option contains single-quoted
  expansions.

## 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,
  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."
  Fixes Debian Bug#928916, reported by Paul Kimoto.
* fetchmailconf would ignore Edit or Delete actions on the first (topmost)
  item in a list (no matter if server list, user list, ...).
* The mimedecode feature now properly detects multipart/mixed-type matches, so
  that quoted-printable-encoded multipart messages can get decoded.
  (Regression in 5.0.0 on 1999-03-27, as a side effect of a PGP-mimedecode fix
  attributed to Henrik Storner.)
* FETCHMAILHOME can now safely be a relative path, which will be qualified
  through realpath(). Previously, it had to be absolute in daemon mode.
  Reported by Alex Andreotti, Debian Bug#941129.

## 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)
* 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.
* 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.

- --------------------------------------------------------------------------------

Happy fetches,
Matthias
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAl2POrYACgkQ5BKxVu/z
hVp6MBAAvUGVyY68ze/U7ZVsXx401Tqs4bY0ozomAnvxS2gMI/6MCSjbo5isgz6f
Q0wsLDBsMtufyUVsl0xg1jl++j9jSmrX9fkp+Ma9iX1d+FMRKSO3V19JDJ/Cunn0
DYw4sP8SIl8NaUcR95oNsCCxTsnMmqR7lo4/4ntpmiv/hT8k1Qy9KwX/rtb6zZTi
Q/QWMP36PdTwLpClhmQpuYP4JZVHiIHxaVa6fKVQFI+CV5D0z1Uos4ifs9N4NF1F
g0fOmCOTiNwm+pK/DV/GITyIQL8dGIe2gcWKPhMduYKpqPzNQeoj3mWYZKNzPK9m
MaexHN90l9YOUnoIMri19QSRz8xJJspp1z2pGa9muDQMNYH2DV+7LXWrEd2tFV2S
2ExZT0s70VFLUvdz5NapqQ19Ab5Cu1TXVU4Yc4hKmwNWg8FBMcUxFtRcPS2lENPP
CuJJEb2II5S98GjzLl152Vj0tKByYrihz3h6c+5tq5BovyN1ZlKgmTDmHCmnwrBT
bB0cIsly6o8o3wL18wvuLgwg49I9BvV/XXOaQz8VLCoCbfvCCSuvDlJSqWvVuMm1
saq0Qe9h7Mo5KWa0txI3emCPj5wASMp9WEBtRNGVRl8rVY/h3cFJvDhqdjk5C/Ee
Fb80jPJf743I8dQwMAuP/UXm5M9zB6ddmcrxwF4tfZ6rGgX32bI=
=TDZF
-----END PGP SIGNATURE-----

[Fetchmail-devel] ANNOUNCE: fetchmail-6.4.0 has been released today, 2019-09-27

[Matthias A. <mat...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Greetings,

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

It is a RECOMMENDED update for all users.
Older releases are herewith officially unsupported.


Where to get it - Deep link to tarball:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.0.tar.xz/download>
How to verify:
GnuPG detached signature:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.0.tar.xz.asc/download>

RIPEMD160(fetchmail-6.4.0.tar.xz)= b119f17bfbb26a0487bd080e30ecb724e94882e5
SHA1(fetchmail-6.4.0.tar.xz)= 323d97096e3cbdf0699c923f973f0bb95c20bb29
SHA256(fetchmail-6.4.0.tar.xz)= 8b30e2e43744be3b7caa6490dc969630dae59dfcc65d508bddc43b1463193072
SHA512(fetchmail-6.4.0.tar.xz)= 45344d542b8312f4beb9fe7d99b3547f5a80447f7af6af3cd28c9d27ac104b505a25fc8e802b51ed6301df8b1ffd171ef92de19f0a83715b4dab6fc46f7cf1d5

Status:

I plan to only do bug fixes to fetchmail-6.4.x so that upgrading
to newer 6.4.x releases should be acceptable under many "stable branch"
maintenance policies. More intrusive changes will happen to versions
that have higher numbers such as 6.5.y or 7.n.m (with m, n, y being numbers).

Since 6.4.0.rc4, Debian Bug#941129 has been fixed.


These are the release notes from NEWS:

fetchmail-6.4.0 (released 2019-09-27, 27429 LoC):

# 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.

## CHANGED REQUIREMENTS
* fetchmail 6.4.0 is written in C99 and requires a SUSv3 (Single Unix
  Specification v3, a superset of POSIX.1-2001 aka. IEEE Std 1003.1-2001 with
  XSI extension) compliant system. For now, a C89 compiler should also work
  if the system is SUSv3 compliant.

  In particular, older fetchmail versions had workaround for several functions
  standardized in the Single Unix Specification v3, these have been removed.

  The trio/ library has been removed from the distribution.

## 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 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 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
  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
  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.
* 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.
* 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 sk tr
  -> Greek, Finnish, Galician, Brazilian Portuguese, Slovak, Turkish.
* Fetchmail now refuses delivery if the MDA option contains single-quoted
  expansions.

## 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,
  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."
  Fixes Debian Bug#928916, reported by Paul Kimoto.
* fetchmailconf would ignore Edit or Delete actions on the first (topmost)
  item in a list (no matter if server list, user list, ...).
* The mimedecode feature now properly detects multipart/mixed-type matches, so
  that quoted-printable-encoded multipart messages can get decoded.
  (Regression in 5.0.0 on 1999-03-27, as a side effect of a PGP-mimedecode fix
  attributed to Henrik Storner.)
* FETCHMAILHOME can now safely be a relative path, which will be qualified
  through realpath(). Previously, it had to be absolute in daemon mode.
  Reported by Alex Andreotti, Debian Bug#941129.

## 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)
* 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.
* 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.

- --------------------------------------------------------------------------------

Happy fetches,
Matthias
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAl2OSzsACgkQ5BKxVu/z
hVrtpw/+IKFQ5ZHqnIqBRl92Dh/8nWKuop6SORESZei2pD7ekn43w+obhLcZDMaf
ipgxVU+o3URHA1N7iA5VdANFzVD3JtyaHsPRPurFWrWINxCt9P7MAzCDSEtogFoD
Zr38BubS00/n6g5bBNMctxdJ7Pf5OIciOSrvTuk5BKp5tmSRwHAW2ij3Oy6JtsqK
1CEF0iWOnIxSIF11yWaAhmrxmCwAB07/1QZFA9uiOHfhyvVK7/T7B21DIwddc6UL
Y2m5FVF8L0QAOZhwEwkHjPqgExk+PhrWsQxnZjk+dM4nWJx99N32vLulaL69cW1i
XbocYPm/0ZV7ykWWIRZCIsWrzKK3+g4s7zgm8tOP7ZArYAvLsM587CooIbRWrswd
nqxYqBLK4aFoKxP86lvE+0P0Q9o5SXb8dFsEQkgamGsBoGhecqAmQxT0vrrSN4Lb
JIurnrXtZ95IvLndF6fieszZbfflM2C2bdfaQiu6mZwrbV6JqSzDEcwauBnleOLy
6K/B30gaMeiO1e8lXI8gGtNWH2BfDekO3iPLKRZSGglom4tE5xWqlr3NBNmaOkkI
LzECz0NIx0fC6JQvCc91//TtLzYd9cDzF4hjsoeyax96GGuMml4wbkI6XrrzPe/K
RCNsYrGJsYiozCjpxN9S1+j2zYc2TCnts34DPAw4Fn1rKoXCJrM=
=HYlj
-----END PGP SIGNATURE-----

[Fetchmail-devel] fetchmail-6.4.0 release candidate #4 - please translate to your language, and test!

[Matthias A. <mat...@gm...>]

Greetings,

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

Since rc3,
* several translation updates were merged,
* several consistency issues in documentation and configuration were fixed,
* comparing the 6.4.x branch with the 7.x.x branch, a few missed bug fixes and
  safety nets were backported. This is hidden under the "Align with legacy_6x"
  label.

These are non-translation updates since rc3:
* c83898bf 2019-08-25 | Mention MDA single-quote fix safety check. [Matthias Andree]
* e0e7a74b 2019-08-25 | Align with legacy_6x. [Matthias Andree]
* 5256f612 2011-06-16 | mimedecode: Fix multipart/mixed detection. [Matthias Andree]
* 525a4c43 2019-08-25 | Drop #ifdef HAVE_GETCWD, there never was a formal configure check. [Matthias Andree]
* 6928f65f 2019-08-25 | fetchmail.man: fix typo spotted by lintian [Nicolas Boulenguez]
* c8e26099 2019-08-25 | contrib/fetchmail-mode.el: run fetchmail-mode-hook after other settings [Kevin Ryde]
* 51ea9ddc 2019-08-24 | Do not reference m4/gethostbyname_r.m4, we don't ship it any more. [Matthias Andree]
* 7c7279e4 2019-08-24 | Remove crypt() check, we don't use it. [Matthias Andree]
* e4f511bb 2019-08-24 | Require Python 2.3 (2.0 is no longer sufficient). [Matthias Andree]

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

I solicit thorough testing, I plan to not hold off on the release much longer,
no matter what the TODO.txt says.  We need to get the SSL changes and
other important fixes out the door, and unless serious bugs are found, this
is slated to become v6.4.0 in September.

Happy fetches,
Matthias

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

[Matthias A. <mat...@gm...>]

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, 
* 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, 
=== PLEASE DO TRANSLATE ===
(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 longer,
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 release 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.
 
 --------------------------------------------------------------------------------
 
 fetchmail-6.4.0 (not yet released): (this lists changes since 6.3.26)
 
 # 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 --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 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
   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 
   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.
 * 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.
+* 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 sk tr
+  -> Greek, Finnish, Galician, Brazilian Portuguese, Slovak, Turkish.
 
 ## 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,
   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."
+  Fixes Debian Bug#928916, reported by Paul Kimoto.
 
 ## 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)
+* 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.
 * 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

Re: [Fetchmail-devel] fetchmail-6.4.0.rc2 final candidate - please translate to your language, and test!

[Matthias A. <mat...@gm...>]

Am 20.08.19 um 08:37 schrieb grarpamp:
> A note that these days no one should be configuring
> anything less than TLS 1.2, or building against less
> than openssl 1.1.1, unless they have no other choice.
> All lesser are either broken and insecure, or out of support.
> Continuing using them can put you at risk,
> and hamper development.

(Deliberately chose the -devel list...)

Jumping the gun while the big graphics MUAs such as Microsoft's,
Mozilla's and the big ones on Android and iOS were still permitting
older TLS levels, meaning that they don't exert major pressure on ISPs,
is no good. If users need to jump hoops because their provider only goes
up to TLS 1.1 while fetchmail demands TLS 1.2 they'll use whatever
insecure crap comes their way "but works".

See, the important first step is moving people away from fetchmail <=
6.3.26 to a version 6.4.0 that has a halfway decent TLS support - so
that a sufficiently underconfigured fetchmail 6.4.0 will OOTB

* pull in SSL at all,

* permit compilation against a recent and pure (no compatibility cruft
and possibly SSLv3 disabled) OpenSSL version,

* so that it can talk TLS v1.2 and possibly v1.3 in the first place,

* and getting *any* kind of reasonable server identity checking (X.509)
into place.

It isn't as strict as recent RFCs (numbers below to keep you excited)
recommend, but I can't destroy the user's forward path if their ISPs are
lazy.

> A release such as 6.4.0 is a good time to try
> updated software against your server. If your server
> does not support at least TLS 1.2, ask your provider
> to update per any easily found RFC or other deprecation
> notice, rationale, or howto on the net.

For users, that is true. The standing IETF RFC-based recommendation
(RFCs 7817, 8314 to mention just two starting points) however is TLS 1.1
or newer, or 1.3 if you use client certificates and a bit of user privacy.

Of course I'd endorse users lobbying their ISP if the latters' servers
aren't TLS-1.3-enabled yet, but if I want to really tighten up default
security I want to make the options users need to use in order to
relax/override security checks as scary, cumbersome to type and talking
as possible. Options such as --connect-insecurely-and-waive-cert-check
or something.

That is, however, a major user interface change that conventionally goes
only with a version bump to 7.0.0 - such that everyone halfway
acquainted with software *EXPECTS* something hard is flying right into
their faces with respect to compatibility.

I have already changed the --sslproto semantics and --sslcertck defaults
for 6.4.0 which is pretty hard for a minor release.

And the world really needs to upgrade fetchmail-on-Cygwin! 6.3.18,
6.3.21 or 6.3.22 have critical and security relevant bugs. I'll notify
cygwin@.

I'll also be pulling the plug on a lot of old systems soonish, but not
in 6.4.0. We really need that "no excuses" way forward, and that means I
can't give distros or users excuses for sticking to the SSL-wise moldy
6.3.x releases.

Re: [Fetchmail-devel] fetchmail-6.4.0.rc2 final candidate - please translate to your language, and test!

[grarpamp <gra...@gm...>]

A note that these days no one should be configuring
anything less than TLS 1.2, or building against less
than openssl 1.1.1, unless they have no other choice.
All lesser are either broken and insecure, or out of support.
Continuing using them can put you at risk,
and hamper development.

A release such as 6.4.0 is a good time to try
updated software against your server. If your server
does not support at least TLS 1.2, ask your provider
to update per any easily found RFC or other deprecation
notice, rationale, or howto on the net.

Here is one that is already over 4 years old...
https://tools.ietf.org/html/rfc7525

https://www.openssl.org/source/

openssl s_client -connect google.com:https < /dev/null

If the output matches this...
'^New, TLSv1\.3,'
then openssl is good and you can then test fetchmail :)

[Fetchmail-devel] fetchmail-6.4.0.rc2 final candidate - please translate to your language, and test!

[Matthias A. <mat...@gm...>]

[resent with corrected Subject:
and cross-mailed to fetchmail-users and -announce for higher exposure]

Greetings,

I have released fetchmail-6.4.0.rc2, 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, 
=== PLEASE DO TRANSLATE ===
(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 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 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.
 
 --------------------------------------------------------------------------------
 
 fetchmail-6.4.0 (not yet released): (this lists changes since 6.3.26)
 
 # 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 --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 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
   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 
   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.
 * 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.
+* 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 sk tr
+  -> Greek, Finnish, Galician, Brazilian Portuguese, Slovak, Turkish.
 
 ## 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,
   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."
+  Fixes Debian Bug#928916, reported by Paul Kimoto.
 
 ## 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)
+* 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.
 * 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

[Fetchmail-devel] fetchmail-6.4.0.rc1 release candidate - please test and translate

[Matthias A. <mat...@gm...>]

[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

[Fetchmail-devel] fetchmail-6.4.0.beta5 released - please test

[Matthias A. <mat...@gm...>]

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

[Fetchmail-devel] fetchmail-6.4.0.beta5 released - please test

[Matthias A. <mat...@gm...>]

[Final attempt at sending a signed message, now with mutt.]

Greetings,

I have released fetchmail-6.4.0.beta5, 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 a
candidate for a 6.4.0 release.

This is taken from the NEWS file. Changes since 6.4.0.beta4 are marked with a
"+" - some were older but undocumented so far:


 ## 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 requires OpenSSL v1.0.2 or newer.
 * fetchmail now configures OpenSSL support by default.
+* 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.)
 
 # 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.


Happy fetches,
Matthias

[Fetchmail-devel] fetchmail-6.4.0.beta5 released - please test

[Matthias A. <mat...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

[Resend - I am trying to see if a clearsigned message will keep an
intact signature]

Greetings,


I have released fetchmail-6.4.0.beta5, 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 a candidate for a 6.4.0 release.

This is taken from the NEWS file. Changes since 6.4.0.beta4 are marked
with a "+"
- - some were older but undocumented so far:

>  ## 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
requires OpenSSL v1.0.2 or newer. > * fetchmail now configures OpenSSL
support by default. > +* 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.) > > #
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.
Happy fetches,
Matthias



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

iQIzBAEBCAAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAlzbLCwACgkQ5BKxVu/z
hVo4MA/+LPq1R3gLXmYGLN4fSak/CDM7ZMghNyZ0X4g7ABFEj6fJx2QPoQNn07nh
7VB2N95e57gj61M4SHYY/3CZfQWYTi1MNu1pNtzp8ZXvqEtJaNSadL1TIYIEAwu8
XtH1cKGQ+bAd53YwazVUBmEwZ4s/XJw/8vs7P9KQN60Ug4tuodzejKxr+IAS3415
xm86JOpzv1hl0C0eBqkSOsM2Xbez3iTmXIuM7sTb6CJftOU8V4f4u1NKQxfTPDTd
nqDyebS3rp0m40nJ1uwGDalHDwS5TPRCMth3KTs9rdHdESOE7f8EwPdAgcW7ojzF
QycAUBnfpTuIvP00zNMDxBiWXsc4FlwqpB42XqlvdMFPyTKeROX3EfCzhPZNoE68
UwOgQgQWM4jKici4Sj9FpYTUUuo8Q4oGSINFcailxGaFFwu7ehZpmCeF3J/RSNXF
M38CG2lU/gzt7knsmr6UrMValDsnRI88M8kwNOkT0oCYRFzeosDoQNZOFsSHFvlY
jBiijkMpPEnJgzF6iUtO/B4BETujnsCkr849IFOXYdodXhs6fJUeuXSd5uwO7RMv
oGntML/LbqkfVu61T89X5tYaTLIHUU9pHqPzZNNtL76dNzHiMG2dB3d8KcJMz879
GJkYKIL6YnB6PC8U91W5qbXwN3jy2wdsxQcLYA7UhKzdhONTrKY=
=I897
-----END PGP SIGNATURE-----

[Fetchmail-devel] fetchmail-6.4.0.beta5 released - please test

[Matthias A. <mat...@gm...>]

Greetings,

I have released fetchmail-6.4.0.beta5, 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 a candidate for a 6.4.0 release.

This is taken from the NEWS file. Changes since 6.4.0.beta4 are marked
with a "+"
- some were older but undocumented so far:

>  ## 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 requires OpenSSL v1.0.2 or newer.
>  * fetchmail now configures OpenSSL support by default.
> +* 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.)
>  
>  # 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.

Happy fetches,
Matthias

Re: [Fetchmail-devel] [Fetchmail-users] some question and thoughts about imap and uids

[Matthias A. <mat...@gm...>]

> [...] I am Cc:'ing Sunil
> Shetye who contributed this code in early 2010 if he remembers. I hope
> his mail address works, haven't heard in a long time.

Update: Sunil's e-mail address that I know is no longer working.

Re: [Fetchmail-devel] [Fetchmail-users] some question and thoughts about imap and uids

[Matthias A. <mat...@gm...>]

NOTE: Followup-To set to a public mailing list (which requires
subscription for postings) - be sure to double-check where your mailer
is going to send your reply!


Am 09.10.18 um 18:44 schrieb Kamil Jońca:
> I have read imap.c code and (it is possible I have overlooked something)

Hello Kamil,

Thanks for looking into this. I think this should continue on
fetchmail-devel@, I am redirecting there and please do subscribe so you
can post.

The model that fetchmail followed so far is that it relied on the \Seen
flags to track which messages had been downloaded, and without --keep,
it would mark messages as deleted.

> 1. (imap_search)
>    sometimes fetchmail issues "SEARCH UNSEEN" and sometimes "SEARCH
>    UNSEEN UNDELETED" (it depends on "keep" flag )
>    What is use case to issue "SEARCH UNSEEN" (without undeleted?)

ad 1. What the original intention was, I don't know. Part of it was
compatibility with IMAP2 (see the revision log for dca4a906), and part
may be the assumption that without --keep, we mark messages for deletion
but possibly without an immediate EXPUNGE, so disconnects or crashes
could theoretically leave deleted messages somehow. I am Cc:'ing Sunil
Shetye who contributed this code in early 2010 if he remembers. I hope
his mail address works, haven't heard in a long time.

> commit dca4a906d60a197b09159bc8d8a16625b1790215
> Committer: Matthias Andree <mat...@gm...>
> Date:   Thu Feb 4 09:51:01 2010 +0000
>
>     IMAP SEARCH fixes & FETCH fallback by Sunil Shetye
>     
>     * The IMAP client now uses "SEARCH UNSEEN" rather than "SEARCH
> UNSEEN NOT
>       DELETED" again on IMAP2, to fix a regression in fetchmail 6.2.5
> reported by
>       Will Stringer in June 2004. (Sunil Shetye)
>     * The IMAP client now uses "SEARCH UNSEEN UNDELETED" on IMAP4 and
> IMAP4r1
>       servers (Sunil Shetye).
>     * Workaround: The IMAP client now falls back to "FETCH n:m FLAGS"
> if the server
>       does not support "SEARCH". (Sunil Shetye)
>     * The IMAP client now requests message numbers in batches of 1,000
> to avoid
>       problems if there are more than 1860 unseen messages. (Sunil Shetye)
>         Note that this wasn't security relevant because fetchmail
> would only read up
>       to the maximum buffer size and leave the remainder of the string
> unread, going
>       out of synch afterwards.
>     
>     svn path=/branches/BRANCH_6-3/; revision=5468

> 2. After fetchin we set "\Seen" flag. Will be this neccessary with uids
> tracking?

It will no longer be necessary. We might make it an option, or we might
forego it entirely.

> 3. my first idea is to keep "not seen" ranges attached to (host,folder)
> ie something like 5:6,1000:* this can easilly be mapped to
> SEARCH UNSEEN UNDELETED UID <ranges here>

Makes sense. If you find the current .fetchids format non-workable, we
can address that, too. We used to have a different layout for .fetchids
that was more efficient, and split up, however the patches were for
6.2.5, surely will no longer apply, and I haven't forward-ported them to
6.4.x beta, let alone 7.0.x alpha.  And if you find awkward things that
need fixing, but should not distract from your current work, feel free
to file issues on Gitlab even without patches.

Thanks again for looking into this!

Cheers,
Matthias

Re: [Fetchmail-devel] cannot fetch mail: Server CommonName mismatch

[Matthias A. <mat...@gm...>]

Am 13.09.18 um 10:39 schrieb Sergey Senozhatsky:
> Hello,
>
> As of today, fetchmail-6.3.26-6 cannot fetch from Gmail.
>
> fetchmail: Server certificate:
> fetchmail: Unknown Organization
> fetchmail: Issuer CommonName: invalid2.invalid
> fetchmail: Subject CommonName: invalid2.invalid
> fetchmail: Server CommonName mismatch: invalid2.invalid != imap.gmail.com
> fetchmail: imap.gmail.com key fingerprint: 90:4A:C8:D5:44:5A:D0:6A:8A:10:FF:CD:8B:11:BE:16
> fetchmail: Server certificate verification error: self signed certificate
> fetchmail: Missing trust anchor certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
>
> RedHat's bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=1611815
>
> This patch fixes the issue on my side:
> https://bugzilla.redhat.com/attachment.cgi?id=1472812&action=diff

The patch is inadequate, it lacks error checking, its use is
discouraged, and I have added a relevant comment.

My upstream Git repository for fetchmail has had a proper solution for a
year now,
https://gitlab.com/fetchmail/fetchmail/commit/9b8b634312f169fab872f3580c2febe5af031615

[Fetchmail-devel] cannot fetch mail: Server CommonName mismatch

[Sergey S. <ser...@gm...>]

Hello,

As of today, fetchmail-6.3.26-6 cannot fetch from Gmail.

fetchmail: Server certificate:
fetchmail: Unknown Organization
fetchmail: Issuer CommonName: invalid2.invalid
fetchmail: Subject CommonName: invalid2.invalid
fetchmail: Server CommonName mismatch: invalid2.invalid != imap.gmail.com
fetchmail: imap.gmail.com key fingerprint: 90:4A:C8:D5:44:5A:D0:6A:8A:10:FF:CD:8B:11:BE:16
fetchmail: Server certificate verification error: self signed certificate
fetchmail: Missing trust anchor certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid

RedHat's bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1611815

This patch fixes the issue on my side:
https://bugzilla.redhat.com/attachment.cgi?id=1472812&action=diff

	-ss

Re: [Fetchmail-devel] set sha1 fingerprint checking correctly on fetchmail

[grarpamp <gra...@gm...>]

>> My mail service provider gmx.com recently appears to have changed their fingerprint to SHA1 (I am guessing) as a result of which my fetchmail has stopped working.
>
> No. Fetchmail 6.3.26 will use MD5 fingerprints no matter what.

If under the same fetchmail config, gmx was working before, then
gmx quit working with fingerprint error, then gmx either swapped
their cert out for something else, or they're under attack, or you're
under attack. That's why certificate pinning exists... to help detect
that. You can usually verify a cert swap by manually consulting
an observatory or the service provider, or if CA is trusted. Attacks
are usually more transient such as via Tor, coffee shops, foreign lands,
and governments as with FinFisher and Skype / WhatsApp, etc.

Your updated config quit because fetchmail only supports the
broken MD5 hash function over the cert.

Openssl thus fetchmail's fingerprint is over the public cert
DER form itself, similar idea as making a hash of some file
on your disk.

> Given that you can only specify one
> fingerprint, for big sites such as GMX

If a service has two or more certs, yes that would be a pain.
We see it with web services like wikipedia. And gmail's global
rollout is known to not happen all at the same time.
I suspect a proper survey, or checking the observatories,
would probably find more instances of affected email services.

> it's /currently/ better to use --sslcertck and rely on certificate checking.

So long as you don't care about trusting the root CA's and MITM's,
both of which have occured in the past.
Probably also want to read up on DNSSEC to cover that part too.
At least if your mail is sensitive. Most people don't care.

Don't remember if you can pin down just google's intermediate
CA with a fetchmail fingerprint to let their service cert float,
but do think you can put it in a cert file on disk. It's one step
removed from pinning a cert to a specific server, but does
save hacking config on every cert change.

7.x should have both cert and modular config enhancements
on the roadmap somewhere. Feel free to pick them up from
the list and bugtracker and get them / 7.x moving.

Re: [Fetchmail-devel] set sha1 fingerprint checking correctly on fetchmail

[Matthias A. <mat...@gm...>]

Am 03.10.2017 um 15:42 schrieb Globe Trotter via Fetchmail-devel:
> Hi, 
>
> My mail service provider gmx.com recently appears to have changed their fingerprint to SHA1 (I am guessing) as a result of which my fetchmail has stopped working.

No. Fetchmail 6.3.26 will use MD5 fingerprints no matter what.

> Here is the fingerprint I get:
> $openssl s_client -connect pop.gmx.com:995 | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint
You're asking OpenSSL for the SHA1 fingerprint, but you need the MD5
fingerprint, as specified in fetchmail's manual page, and that's what
you get in the "mismatch" reporting. Given that you can only specify one
fingerprint, for big sites such as GMX it's /currently/  (in fetchmail
6.3.X) better to use --sslcertck and rely on certificate checking. You
need to install the root certificate though, most distributions have a
package such as ca-certificates, nss_root_ca, or similar, and it should
Just Work™.

Also see README.SSL as shipped with fetchmail.