fetchmail-users — User questions and discussion

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

[Gene H. <ghe...@sh...>]

On Friday 27 September 2019 17:09:55 Christian Ebert wrote:

> * Matthias Andree on Friday, September 27, 2019 at 19:47:42 +0200:
> > -----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/>
>
> Hm, it expects defaut user rc file location at $HOME/fetchmailrc
> not $HOME/.fetchmailrc

Ooops, do I wait for a 6.4.1?  I think so.

> cheers,
>
> Christian
>
> --
> LAST SHIP HOME
> Die Weltumsegelung der Peter von Danzig
> Ein Film von Michael Weber und Christian Ebert
> --->> https://lastshiphome.de
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

[Christian E. <bla...@gm...>]

* Matthias Andree on Friday, September 27, 2019 at 19:47:42 +0200:
> -----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/>

Hm, it expects defaut user rc file location at $HOME/fetchmailrc
not $HOME/.fetchmailrc

cheers,

Christian

--
LAST SHIP HOME
Die Weltumsegelung der Peter von Danzig
Ein Film von Michael Weber und Christian Ebert
--->> https://lastshiphome.de

[Fetchmail-users] 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-----

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

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

Am September 16, 2019 12:15:31 PM UTC schrieb Jerry <je...@se...>:
>On Mon, 2 Sep 2019 19:27:45 +0200, Matthias Andree stated:
>>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
>>
>
>
>I assume that a version of Python newer than 2.3 (July 29, 2003) will
>work. Wouldn't it be better to at least require at least Python 3.0.0
>(Dec. 3, 2008)?
>
>-- 
>Jerry

Hi Jerry, 

That code is not Python 3 compatible and 2to3 is, err, well, let's do more important things. 
I plan to drop fetchmailconf. Its user experience is worse than that of your average text editor that sits in a window next to your manual, and it requires a lot of effort to keep in unison that I cannot afford given there are other important things to address about the code.

So, it will be Python 2 for now and unless someone is going to step up as new maintainer, I will remove fetchmailconf from a future release. I am aware that Python 2 is EOL soon and distributors are pulling the plug. 

Volunteers? 

Regards, 
Matthias

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

[Jerry <je...@se...>]

On Mon, 2 Sep 2019 19:27:45 +0200, Matthias Andree stated:
>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
>


I assume that a version of Python newer than 2.3 (July 29, 2003) will
work. Wouldn't it be better to at least require at least Python 3.0.0
(Dec. 3, 2008)?

-- 
Jerry

[Fetchmail-users] 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-users] 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-users] [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-users] 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-users] 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

Re: [Fetchmail-users] mail expunge mismatch (0 actual != 1 expected)

[Jerry <je...@se...>]

On Sat, 6 Jul 2019 17:43:25 +0200, Matthias Andree stated:
>Am 28.06.19 um 00:07 schrieb Matthias Andree:
>> Am 25.06.19 um 12:54 schrieb Jerry:  
>>> fetchmail release 6.3.26+RPA+SDPS+SSL-SSLv2-SSLv3+OPIE+NLS
>>> FreeBSD 12.0-RELEASE-p6 GENERIC  amd64
>>>
>>> The following entries have started appearing in my fetchmail log
>>> file:
>>>
>>> fetchmail: 1 message for XX...@ai... at imap.aim.com.
>>> fetchmail: reading message
>>> XX...@ai...@internal-aol.imap.mail.g03.yahoodns.net:1 of 1 (4137
>>> header octets) (54943 body octets) flushed fetchmail: mail expunge
>>> mismatch (0 actual != 1 expected) fetchmail: client/server
>>> synchronization error while fetching from XX...@ai...@imap.aim.com
>>> fetchmail: Query status=7 (ERROR)
>>>
>>> This appears every time fetchmail runs. It had worked correctly
>>> previously and there have been no changes to the system that I am
>>> aware of. I visited the site and deleted any files that were
>>> present. At that time, there were none.
>>>
>>> Can any one tell me what is causing this problem? It appears to be
>>> localized to AOL.
>>>
>>> Thanks!
>>>  
>> Jerry,
>>
>> as Ralph Corderoy asked, we need to see detailed logs, and for
>> instructions, please see
>> <http://www.fetchmail.info/fetchmail-FAQ.html#G3> to evaluate the
>> situation. Please provide them.
>>
>> Best regards,
>> Matthias  
>
>Jerry, any news?

Sorry, but I have been on vacation fr a week, I just checked the logs,
and that message sequence is still evident; however, no mail is being
lost, so I think it is just some sort of harmless error or warning
message.

If I get a chance in the next week or so, I will put fetchmail into
debug mode and see if I can isolate the problem.

I could probably set up another "dummy" account and see if it exhibits
the same problem. If it does, I could just give you access to it so you
could diagnose the problem yourself. That would probably be quicker.

-- 
Jerry

Re: [Fetchmail-users] mail expunge mismatch (0 actual != 1 expected)

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

Am 28.06.19 um 00:07 schrieb Matthias Andree:
> Am 25.06.19 um 12:54 schrieb Jerry:
>> fetchmail release 6.3.26+RPA+SDPS+SSL-SSLv2-SSLv3+OPIE+NLS
>> FreeBSD 12.0-RELEASE-p6 GENERIC  amd64
>>
>> The following entries have started appearing in my fetchmail log file:
>>
>> fetchmail: 1 message for XX...@ai... at imap.aim.com.
>> fetchmail: reading message XX...@ai...@internal-aol.imap.mail.g03.yahoodns.net:1 of 1 (4137 header octets) (54943 body octets) flushed
>> fetchmail: mail expunge mismatch (0 actual != 1 expected)
>> fetchmail: client/server synchronization error while fetching from XX...@ai...@imap.aim.com
>> fetchmail: Query status=7 (ERROR)
>>
>> This appears every time fetchmail runs. It had worked correctly
>> previously and there have been no changes to the system that I am aware
>> of. I visited the site and deleted any files that were present. At that
>> time, there were none.
>>
>> Can any one tell me what is causing this problem? It appears to be localized to AOL.
>>
>> Thanks!
>>
> Jerry,
>
> as Ralph Corderoy asked, we need to see detailed logs, and for
> instructions, please see
> <http://www.fetchmail.info/fetchmail-FAQ.html#G3> to evaluate the
> situation. Please provide them.
>
> Best regards,
> Matthias

Jerry, any news?

Re: [Fetchmail-users] mail expunge mismatch (0 actual != 1 expected)

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

Am 25.06.19 um 12:54 schrieb Jerry:
> fetchmail release 6.3.26+RPA+SDPS+SSL-SSLv2-SSLv3+OPIE+NLS
> FreeBSD 12.0-RELEASE-p6 GENERIC  amd64
>
> The following entries have started appearing in my fetchmail log file:
>
> fetchmail: 1 message for XX...@ai... at imap.aim.com.
> fetchmail: reading message XX...@ai...@internal-aol.imap.mail.g03.yahoodns.net:1 of 1 (4137 header octets) (54943 body octets) flushed
> fetchmail: mail expunge mismatch (0 actual != 1 expected)
> fetchmail: client/server synchronization error while fetching from XX...@ai...@imap.aim.com
> fetchmail: Query status=7 (ERROR)
>
> This appears every time fetchmail runs. It had worked correctly
> previously and there have been no changes to the system that I am aware
> of. I visited the site and deleted any files that were present. At that
> time, there were none.
>
> Can any one tell me what is causing this problem? It appears to be localized to AOL.
>
> Thanks!
>
Jerry,

as Ralph Corderoy asked, we need to see detailed logs, and for
instructions, please see
<http://www.fetchmail.info/fetchmail-FAQ.html#G3> to evaluate the
situation. Please provide them.

Best regards,
Matthias

Re: [Fetchmail-users] mail expunge mismatch (0 actual != 1 expected)

[Ralph C. <ra...@in...>]

Hi Jerry,

> I have logged in with a browser and cleaned out every thing I could
> find.

Have you read http://www.fetchmail.info/fetchmail-FAQ.html#G3 ?

-- 
Cheers, Ralph.

Re: [Fetchmail-users] mail expunge mismatch (0 actual != 1 expected)

[Gene H. <ghe...@sh...>]

On Tuesday 25 June 2019 09:54:28 Jerry wrote:

> On Tue, 25 Jun 2019 09:39:49 -0400, Gene Heskett stated:
> >On Tuesday 25 June 2019 06:54:06 Jerry wrote:
> >> fetchmail release 6.3.26+RPA+SDPS+SSL-SSLv2-SSLv3+OPIE+NLS
> >> FreeBSD 12.0-RELEASE-p6 GENERIC  amd64
> >>
> >> The following entries have started appearing in my fetchmail log
> >> file:
> >>
> >> fetchmail: 1 message for XX...@ai... at imap.aim.com.
> >> fetchmail: reading message
> >> XX...@ai...@internal-aol.imap.mail.g03.yahoodns.net:1 of 1 (4137
> >> header octets) (54943 body octets) flushed fetchmail: mail expunge
> >> mismatch (0 actual != 1 expected)
> >> fetchmail: client/server synchronization error while fetching from
> >> XX...@ai...@imap.aim.com fetchmail: Query status=7 (ERROR)
> >>
> >> This appears every time fetchmail runs. It had worked correctly
> >> previously and there have been no changes to the system that I am
> >> aware of. I visited the site and deleted any files that were
> >> present. At that time, there were none.
> >>
> >> Can any one tell me what is causing this problem? It appears to be
> >> localized to AOL.
> >>
> >> Thanks!
> >
> >Some ISP's are serving their imap using customers from the same
> >filesystem that also serves up pop3 to fetchmail, and because the
> >customer may switch depending on the machine, they have disabled the
> >fetchmail issued DELE.  So I log in with a browser and use it to
> > clean house at the ISP.  Sounds like AOL has figured out yet another
> > way to annoy their pop3 customers with phony error msgs.
> >
> >I use fetchmail with kmail here, and kmail will occasionally get its
> >indices out of synch, so I had to use t-bird in imap mode for about a
> >day, and boy did I get an education on how NOT to do email. I suppose
> >one could learn to live with it, but imap=spit to me.
> >
> >Cheers, Gene Heskett
>
> I have logged in with a browser and cleaned out every thing I could
> find. Actually, there were no emails or Spam shown in any folders. I
> did the run twice to insure it was completely sanitized.
> Unfortunately, the problem still exists. My next move is to try and
> contact technical support at AOL and see what they have to say. I know
> it is a waste of time because either,
>
> 1) I will never get to actually speak to a rep

In that case, the magic words are "escalate to technical, please".

> 2) They will inevitably blame it on me.

Probably, but listen carefully for clues as to how to fix it.  The tech 
doesn't want 100k people calling him an idiot so he will generally 
relate a fix. Pay attention. The idiot is on occasion, looking back at 
one in the mirror.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: [Fetchmail-users] mail expunge mismatch (0 actual != 1 expected)

[Jerry <je...@se...>]

On Tue, 25 Jun 2019 09:39:49 -0400, Gene Heskett stated:
>On Tuesday 25 June 2019 06:54:06 Jerry wrote:
>
>> fetchmail release 6.3.26+RPA+SDPS+SSL-SSLv2-SSLv3+OPIE+NLS
>> FreeBSD 12.0-RELEASE-p6 GENERIC  amd64
>>
>> The following entries have started appearing in my fetchmail log
>> file:
>>
>> fetchmail: 1 message for XX...@ai... at imap.aim.com.
>> fetchmail: reading message
>> XX...@ai...@internal-aol.imap.mail.g03.yahoodns.net:1 of 1 (4137
>> header octets) (54943 body octets) flushed fetchmail: mail expunge
>> mismatch (0 actual != 1 expected)
>> fetchmail: client/server synchronization error while fetching from
>> XX...@ai...@imap.aim.com fetchmail: Query status=7 (ERROR)
>>
>> This appears every time fetchmail runs. It had worked correctly
>> previously and there have been no changes to the system that I am
>> aware of. I visited the site and deleted any files that were present.
>> At that time, there were none.
>>
>> Can any one tell me what is causing this problem? It appears to be
>> localized to AOL.
>>
>> Thanks!  
>
>Some ISP's are serving their imap using customers from the same 
>filesystem that also serves up pop3 to fetchmail, and because the 
>customer may switch depending on the machine, they have disabled the 
>fetchmail issued DELE.  So I log in with a browser and use it to clean 
>house at the ISP.  Sounds like AOL has figured out yet another way to 
>annoy their pop3 customers with phony error msgs.
>
>I use fetchmail with kmail here, and kmail will occasionally get its 
>indices out of synch, so I had to use t-bird in imap mode for about a 
>day, and boy did I get an education on how NOT to do email. I suppose 
>one could learn to live with it, but imap=spit to me.
>
>Cheers, Gene Heskett


I have logged in with a browser and cleaned out every thing I could
find. Actually, there were no emails or Spam shown in any folders. I
did the run twice to insure it was completely sanitized. Unfortunately,
the problem still exists. My next move is to try and contact technical
support at AOL and see what they have to say. I know it is a waste of
time because either,

1) I will never get to actually speak to a rep
2) They will inevitably blame it on me.

-- 
Jerry

Re: [Fetchmail-users] mail expunge mismatch (0 actual != 1 expected)

[Gene H. <ghe...@sh...>]

On Tuesday 25 June 2019 06:54:06 Jerry wrote:

> fetchmail release 6.3.26+RPA+SDPS+SSL-SSLv2-SSLv3+OPIE+NLS
> FreeBSD 12.0-RELEASE-p6 GENERIC  amd64
>
> The following entries have started appearing in my fetchmail log file:
>
> fetchmail: 1 message for XX...@ai... at imap.aim.com.
> fetchmail: reading message
> XX...@ai...@internal-aol.imap.mail.g03.yahoodns.net:1 of 1 (4137
> header octets) (54943 body octets) flushed fetchmail: mail expunge
> mismatch (0 actual != 1 expected)
> fetchmail: client/server synchronization error while fetching from
> XX...@ai...@imap.aim.com fetchmail: Query status=7 (ERROR)
>
> This appears every time fetchmail runs. It had worked correctly
> previously and there have been no changes to the system that I am
> aware of. I visited the site and deleted any files that were present.
> At that time, there were none.
>
> Can any one tell me what is causing this problem? It appears to be
> localized to AOL.
>
> Thanks!

Some ISP's are serving their imap using customers from the same 
filesystem that also serves up pop3 to fetchmail, and because the 
customer may switch depending on the machine, they have disabled the 
fetchmail issued DELE.  So I log in with a browser and use it to clean 
house at the ISP.  Sounds like AOL has figured out yet another way to 
annoy their pop3 customers with phony error msgs.

I use fetchmail with kmail here, and kmail will occasionally get its 
indices out of synch, so I had to use t-bird in imap mode for about a 
day, and boy did I get an education on how NOT to do email. I suppose 
one could learn to live with it, but imap=spit to me.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Fetchmail-users] mail expunge mismatch (0 actual != 1 expected)

[Jerry <je...@se...>]

fetchmail release 6.3.26+RPA+SDPS+SSL-SSLv2-SSLv3+OPIE+NLS
FreeBSD 12.0-RELEASE-p6 GENERIC  amd64

The following entries have started appearing in my fetchmail log file:

fetchmail: 1 message for XX...@ai... at imap.aim.com.
fetchmail: reading message XX...@ai...@internal-aol.imap.mail.g03.yahoodns.net:1 of 1 (4137 header octets) (54943 body octets) flushed
fetchmail: mail expunge mismatch (0 actual != 1 expected)
fetchmail: client/server synchronization error while fetching from XX...@ai...@imap.aim.com
fetchmail: Query status=7 (ERROR)

This appears every time fetchmail runs. It had worked correctly
previously and there have been no changes to the system that I am aware
of. I visited the site and deleted any files that were present. At that
time, there were none.

Can any one tell me what is causing this problem? It appears to be localized to AOL.

Thanks!

-- 
Jerry

Re: [Fetchmail-users] Fetchmail reports "input in flex scanner failed"

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

Am 27.05.19 um 00:59 schrieb Dmitry Katsubo via Fetchmail-users:
> I thought that if there is a possibility to improve the error
> reporting, it will certainly make fetchmail better, for example, it
> can additionally check ferrno() value.
> It is difficult to trace the problem if I/O error happens from time to time as the message "input in flex scanner failed" sounds for me that there is something wrong with ~/.fetchmailrc syntax.

Dmitry,

I'll concede it's not the best error message, but it states "input ...
failed", so to me it's pretty clear.

On POSIX-like systems it's mostly EIO or perhaps ENOMEM (which you'd
probably notice in different other ways, too). Syntax errors are
returned as such.

The default flex scanner will indeed report this "input in flex scanner
failed" when ferror(yyin) is set.

If you see enough repeated I/O errors that you care to report these, you
seem to have a special workload, a strange configuration, or failing
hardware. Care to shed some light?

If you can spend a few hours for writing, testing and debugging a macro
or function that I can use as YY_INPUT(buf,result,size_max), I'll
consider it - note it needs to be able to read from pipelines, for
instance, if some script generates ephemeral configuration files on the
fly and feeds it to stdin, through "--fetchmailrc -" (which is
documented). Check rcfile_l.c to see what either my flex stuffed into
the tarball, or what your flex generated, look for #define
YY_INPUT(buf,result,max_size).

Re: [Fetchmail-users] Fetchmail reports "input in flex scanner failed"

[Dmitry K. <dm...@ma...>]

On 2019-05-21 07:59, Matthias Andree wrote:
> Flex does not currently generate code to break down and relay the error
> in detail has been written yet.
> 
> With flex 2.6.4, the error gets reported if ferror() returns an error
> state and errno isn't EINTR.
> 
> Fetchmail isn't made to cope with files being intermittently
> unavailable. Make sure the file is readable at all times.
> For instance, if your $HOME is on NFS, you must use "hard" mounts (which
> block until the file server is available), so that you have reliable
> semantics for file I/O.

Thanks for the information, Matthias!

I thought that if there is a possibility to improve the error reporting, it will certainly make fetchmail better, for example, it can additionally check ferrno() value.

It is difficult to trace the problem if I/O error happens from time to time as the message "input in flex scanner failed" sounds for me that there is something wrong with ~/.fetchmailrc syntax.

-- 
With best regards,
Dmitry

Re: [Fetchmail-users] Fetchmail reports "input in flex scanner failed"

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

Am 21.05.19 um 00:40 schrieb Dmitry Katsubo via Fetchmail-users:
> Dear fetchamil users,
>
> I have noticed that sometimes fetchamil reports the following to the output:
>
>   input in flex scanner failed
>
> I think this happens because ~/.fetchmailrc becomes (temporary) unavailable (input/output error), however it's difficult for me to strace this situation. Can it be the reason of such error? If so, is
> it possible to rephrase this error message so that it is more verbose?

Dmitry,

Flex does not currently generate code to break down and relay the error
in detail has been written yet.

With flex 2.6.4, the error gets reported if ferror() returns an error
state and errno isn't EINTR.

Fetchmail isn't made to cope with files being intermittently
unavailable. Make sure the file is readable at all times.
For instance, if your $HOME is on NFS, you must use "hard" mounts (which
block until the file server is available), so that you have reliable
semantics for file I/O.

HTH
Matthias

[Fetchmail-users] Fetchmail reports "input in flex scanner failed"

[Dmitry K. <dm...@ma...>]

Dear fetchamil users,

I have noticed that sometimes fetchamil reports the following to the output:

  input in flex scanner failed

I think this happens because ~/.fetchmailrc becomes (temporary) unavailable (input/output error), however it's difficult for me to strace this situation. Can it be the reason of such error? If so, is
it possible to rephrase this error message so that it is more verbose?

Thanks for any help.

-- 
With best regards,
Dmitry

Re: [Fetchmail-users] 'fetchmail' daemon stuck

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

Am 02.05.19 um 21:25 schrieb min...@vf...:
> Hello
>
> Every now and then my 'fetchmail' daemon gets stuck. After some time
> (varies between 1/2 hour and a few days) it stops fetching e-mails. I
> did start it in verbose mode and got the below log. The initial 30 MB
> of the log I threw away as it shows only successful operation, the
> interesting part is here:
>
> fetchmail: 6.3.26 querying imap.yandex.com (protocol IMAP) at xxx xxx
> xx xx:xx:xx xxxx: poll started
> fetchmail: Trying to connect to 87.250.251.124/993...connected.
> fetchmail: Certificate chain, from root to peer, starting at depth 3:
> fetchmail: Issuer Organization: Unizeto Sp. z o.o.
> fetchmail: Issuer CommonName: Certum CA
> fetchmail: Subject CommonName: Certum CA
> fetchmail: Certificate at depth 2:
> fetchmail: Issuer Organization: Unizeto Sp. z o.o.
> fetchmail: Issuer CommonName: Certum CA
> fetchmail: Subject CommonName: Certum Trusted Network CA
> fetchmail: Certificate at depth 1:
> fetchmail: Issuer Organization: Unizeto Technologies S.A.
> fetchmail: Issuer CommonName: Certum Trusted Network CA
> fetchmail: Subject CommonName: Yandex CA
> fetchmail: Server certificate:
> fetchmail: Issuer Organization: Yandex LLC
> fetchmail: Issuer CommonName: Yandex CA
> fetchmail: Subject CommonName: imap.yandex.ru
> fetchmail: Subject Alternative Name: imap.yandex.ru
> fetchmail: Subject Alternative Name: imap.yandex.kz
> fetchmail: Subject Alternative Name: imap.yandex.ua
> fetchmail: Subject Alternative Name: imap.yandex.com.tr
> fetchmail: Subject Alternative Name: imap.yandex.by
> fetchmail: Subject Alternative Name: imap.ya.ru
> fetchmail: Subject Alternative Name: imap.yandex.com
> fetchmail: imap.yandex.com key fingerprint:
> 12:09:8E:B7:44:DE:6F:6B:04:2B:C3:8B:AA:ED:99:53
> fetchmail: IMAP< * OK Yandex IMAP4rev1 at imapxxj.mail.yandex.net:993
> ready to talk with ::xxxx:xxx.xxx.xxx.xxx:xxxxx, xxxx-xxx-xx xx:xx:xx,
> xxxxxxxxxxxx
> fetchmail: IMAP> A0001 CAPABILITY
> fetchmail: IMAP< * BYE Autologout; idle for too long
> fetchmail: Received BYE response from IMAP server:  AUTOLOGOUT; IDLE
> FOR TOO LONGfetchmail: IMAP< * BYE Autologout; idle for too long
> fetchmail: Received BYE response from IMAP server:  AUTOLOGOUT; IDLE
> FOR TOO LONGfetchmail: IMAP< * BYE Autologout; idle for too long
> fetchmail: Received BYE response from IMAP server:  AUTOLOGOUT; IDLE
> FOR TOO LONGfetchmail: IMAP< * BYE Autologout; idle for too long
> ...
>
> The last line repeats forever, blocking any further polling. Only
> restarting 'fetchmail' helps.
>
> What could be the issue? Possible to circumvent it through further
> configuring 'fetchmail'?


First of all, this appears to be a server malfunction, but
unfortunately, you elided the instance information - if you still have
it, check with Yandex's user support (if there is such a thing) and
report the issue.

The server isn't supposed to answer with an untagged * BYE in response
to a CAPABILITY command that happens first in the session, and in
particular, it shouldn't repeat that message, "* BYE Autologout; idle
for too long".

I don't know a good approach to attack this. A brute force workaround is
to edit imap.c, find the line

    report(stderr, GT_("Received BYE response from IMAP server: %s"),
buf + 5);

and add a new line immediately below

    return PS_SOCKET;

then recompile and reinstall. This will make fetchmail disconnect
immediately without any more protocol chatter, unless the * BYE happens
in logout stage.

HTH
Matthias

[Fetchmail-users] 'fetchmail' daemon stuck

[<min...@vf...>]

Hello

Every now and then my 'fetchmail' daemon gets stuck. After some time 
(varies between 1/2 hour and a few days) it stops fetching e-mails. I 
did start it in verbose mode and got the below log. The initial 30 MB of 
the log I threw away as it shows only successful operation, the 
interesting part is here:

fetchmail: 6.3.26 querying imap.yandex.com (protocol IMAP) at xxx xxx xx 
xx:xx:xx xxxx: poll started
fetchmail: Trying to connect to 87.250.251.124/993...connected.
fetchmail: Certificate chain, from root to peer, starting at depth 3:
fetchmail: Issuer Organization: Unizeto Sp. z o.o.
fetchmail: Issuer CommonName: Certum CA
fetchmail: Subject CommonName: Certum CA
fetchmail: Certificate at depth 2:
fetchmail: Issuer Organization: Unizeto Sp. z o.o.
fetchmail: Issuer CommonName: Certum CA
fetchmail: Subject CommonName: Certum Trusted Network CA
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: Unizeto Technologies S.A.
fetchmail: Issuer CommonName: Certum Trusted Network CA
fetchmail: Subject CommonName: Yandex CA
fetchmail: Server certificate:
fetchmail: Issuer Organization: Yandex LLC
fetchmail: Issuer CommonName: Yandex CA
fetchmail: Subject CommonName: imap.yandex.ru
fetchmail: Subject Alternative Name: imap.yandex.ru
fetchmail: Subject Alternative Name: imap.yandex.kz
fetchmail: Subject Alternative Name: imap.yandex.ua
fetchmail: Subject Alternative Name: imap.yandex.com.tr
fetchmail: Subject Alternative Name: imap.yandex.by
fetchmail: Subject Alternative Name: imap.ya.ru
fetchmail: Subject Alternative Name: imap.yandex.com
fetchmail: imap.yandex.com key fingerprint: 
12:09:8E:B7:44:DE:6F:6B:04:2B:C3:8B:AA:ED:99:53
fetchmail: IMAP< * OK Yandex IMAP4rev1 at imapxxj.mail.yandex.net:993 
ready to talk with ::xxxx:xxx.xxx.xxx.xxx:xxxxx, xxxx-xxx-xx xx:xx:xx, 
xxxxxxxxxxxx
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * BYE Autologout; idle for too long
fetchmail: Received BYE response from IMAP server:  AUTOLOGOUT; IDLE FOR 
TOO LONGfetchmail: IMAP< * BYE Autologout; idle for too long
fetchmail: Received BYE response from IMAP server:  AUTOLOGOUT; IDLE FOR 
TOO LONGfetchmail: IMAP< * BYE Autologout; idle for too long
fetchmail: Received BYE response from IMAP server:  AUTOLOGOUT; IDLE FOR 
TOO LONGfetchmail: IMAP< * BYE Autologout; idle for too long
...

The last line repeats forever, blocking any further polling. Only 
restarting 'fetchmail' helps.

What could be the issue? Possible to circumvent it through further 
configuring 'fetchmail'?


Thanks!

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

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: [Fetchmail-users] ssl with dslextreme.com attempts to send a spurious email

[Ralph C. <ra...@in...>]

Hi Matthias,

> > starting fetchmail 6.3.24 daemon
> > 1 message for jd...@ea... at pop.earthlink.net (4706 octets).
> > reading message jd...@ea...@pop.earthlink.net:1 of 1 (4706
> >     octets) (log message incomplete)
> > SMTP error: 501 5.1.7 Bad sender address syntax
> > not flushed
>
> The log message incomplete stems from the log "reading message" that
> gets interrupted by the 501 5.1.7 error, logging makes this excursion,
> and finally the "not flushed" concludes the original log message.

It's quite subtle that the incomplete log message is resumed later.
And that the message in `log message' is a different kind to `reading
message', i.e. the read message wasn't incomplete.

Could it instead be something like

    reading message jd...@ea...@pop.earthlink.net:1 of 1 (4706
        octets) (log-message to be continued)
    SMTP error: 501 5.1.7 Bad sender address syntax
    (log-message continued) not flushed

-- 
Cheers, Ralph.