Menu
▾
▴
fetchmail-users — User questions and discussion
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(2) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(21) |
Sep
(17) |
Oct
(35) |
Nov
(39) |
Dec
(55) |
| 2006 |
Jan
(70) |
Feb
(11) |
Mar
(55) |
Apr
(27) |
May
(73) |
Jun
(47) |
Jul
(63) |
Aug
(27) |
Sep
(52) |
Oct
(39) |
Nov
(87) |
Dec
(15) |
| 2007 |
Jan
(23) |
Feb
(46) |
Mar
(108) |
Apr
(63) |
May
(54) |
Jun
(34) |
Jul
(29) |
Aug
(103) |
Sep
(46) |
Oct
(69) |
Nov
(29) |
Dec
(17) |
| 2008 |
Jan
(45) |
Feb
(32) |
Mar
(25) |
Apr
(17) |
May
(39) |
Jun
(20) |
Jul
(64) |
Aug
(31) |
Sep
(38) |
Oct
(20) |
Nov
(42) |
Dec
(50) |
| 2009 |
Jan
(10) |
Feb
(38) |
Mar
(3) |
Apr
(29) |
May
(41) |
Jun
(31) |
Jul
(21) |
Aug
(53) |
Sep
(49) |
Oct
(26) |
Nov
(28) |
Dec
(15) |
| 2010 |
Jan
(83) |
Feb
(38) |
Mar
(33) |
Apr
(44) |
May
(9) |
Jun
(16) |
Jul
(35) |
Aug
(38) |
Sep
(11) |
Oct
(35) |
Nov
(68) |
Dec
(19) |
| 2011 |
Jan
(16) |
Feb
(69) |
Mar
(42) |
Apr
(54) |
May
(56) |
Jun
(29) |
Jul
|
Aug
(65) |
Sep
(3) |
Oct
(39) |
Nov
(33) |
Dec
(4) |
| 2012 |
Jan
(31) |
Feb
(21) |
Mar
(26) |
Apr
(13) |
May
(38) |
Jun
(39) |
Jul
(14) |
Aug
(31) |
Sep
(8) |
Oct
(32) |
Nov
(12) |
Dec
(16) |
| 2013 |
Jan
(40) |
Feb
(22) |
Mar
(21) |
Apr
(15) |
May
(13) |
Jun
(9) |
Jul
(34) |
Aug
(10) |
Sep
(10) |
Oct
|
Nov
(7) |
Dec
(1) |
| 2014 |
Jan
(25) |
Feb
(9) |
Mar
(8) |
Apr
(12) |
May
(7) |
Jun
|
Jul
(7) |
Aug
(4) |
Sep
(27) |
Oct
(25) |
Nov
(18) |
Dec
(3) |
| 2015 |
Jan
(18) |
Feb
(13) |
Mar
(4) |
Apr
(19) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(6) |
Oct
(4) |
Nov
(19) |
Dec
(6) |
| 2016 |
Jan
|
Feb
(8) |
Mar
(14) |
Apr
|
May
(11) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(11) |
Dec
(17) |
| 2017 |
Jan
(17) |
Feb
(35) |
Mar
|
Apr
(4) |
May
(8) |
Jun
(2) |
Jul
(16) |
Aug
|
Sep
(5) |
Oct
(11) |
Nov
(15) |
Dec
(10) |
| 2018 |
Jan
|
Feb
(3) |
Mar
|
Apr
(3) |
May
(2) |
Jun
(8) |
Jul
|
Aug
(10) |
Sep
(17) |
Oct
(15) |
Nov
(12) |
Dec
(10) |
| 2019 |
Jan
(4) |
Feb
(14) |
Mar
(33) |
Apr
(17) |
May
(7) |
Jun
(6) |
Jul
(2) |
Aug
(4) |
Sep
(22) |
Oct
(13) |
Nov
|
Dec
|
| 2020 |
Jan
(36) |
Feb
(19) |
Mar
(31) |
Apr
(2) |
May
(22) |
Jun
(7) |
Jul
(25) |
Aug
(9) |
Sep
(17) |
Oct
(52) |
Nov
(13) |
Dec
(9) |
| 2021 |
Jan
(23) |
Feb
(13) |
Mar
(9) |
Apr
(15) |
May
(3) |
Jun
(7) |
Jul
(4) |
Aug
(23) |
Sep
(3) |
Oct
(8) |
Nov
(28) |
Dec
(9) |
| 2022 |
Jan
(38) |
Feb
(2) |
Mar
(56) |
Apr
(24) |
May
(29) |
Jun
(22) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(2) |
Dec
|
| 2023 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(21) |
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2024 |
Jan
(15) |
Feb
(4) |
Mar
|
Apr
(4) |
May
(11) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(9) |
Oct
(9) |
Nov
(1) |
Dec
(1) |
| 2025 |
Jan
(7) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(10) |
Jul
|
Aug
(1) |
Sep
(12) |
Oct
(4) |
Nov
|
Dec
|
|
From: Matthias A. <mat...@gm...> - 2025-10-10 13:09:42
|
The 6.6.0.rc1 release of fetchmail is now available at the usual locations, including <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>. Please test this especially if + you want to try TLS or STARTTLS connection to your SMTP forwarder + you use SMTP AUTH (esmtppassword) + and/or want to store your SMTP passwords in .netrc and share feedback mentioning the 6.6.0.rc1 version via list, by e-mail or, if you find a bug, Gitlab issue (account required) at https://gitlab.com/fetchmail/fetchmail/-/issues - note for bug reports that AUTH PLAIN and AUTH LOGIN data must be redacted from your reports, these can be reversed to reveal your password! Reminder: only subscribers to the fetchmail mailing lists can send mail there. The source archive is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6.6.0.rc1.tar.xz/download> The detached GnuPG signature is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6.6.0.rc1.tar.xz.asc/download> The SHA256 hashes for the tarballs are: SHA2-256(fetchmail-6.6.0.rc1.tar.xz)= f1a2cec31f673fd3cdcdca50ff0608321f168e9513c355fedd061a9f76928f5f Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.6.0 (not yet released): ## FEATURE: * SMTP TLS and STARTTLS support. By default, this works opportunistically, attempting to set up a TLS connection to the smtphost if it understands EHLO and offers STARTTLS, but will not enforce peer certificate validity for compatibility, esp. because "localhost" (the default SMTP host) usually isn't listed in the X.509 certificates. Behavior can be tweaked by adding /notls (cleartext connection), /tls (TLS-wrapped connection, negotiating TLS before conversing otherwise), or /starttls (requiring EHLO to offer STARTTLS, requesting the latter and requiring the server certificate to validate) to the SMTP host's name. Also, you can add /tlsproto=... where ... accepts the same parameters as the --sslproto option, which see. Ports, if not specified, default to 25 for opportunistic and /notls modes, 465 for /tls and 587 for /starttls, but can be overridden either by giving, say /25 or /smtp for /starttls. ## TRANSLATIONS: These will be requested only after fetchmail 6.5.7 will have been released. ------------------------------------------------------------------------------- |
|
From: axreios <rp...@am...> - 2025-10-08 19:21:15
|
This RC is working well for me using ESMTP protocol to obtain emails from my ISP's mailhost for two separate accounts. Compiled without error on up-to-date Voidlinux and fetching mail without error. A tip of the hat to MA! ax On Wed, Oct 08, 2025 at 04:40:34PM +0200, Matthias Andree via Fetchmail-users wrote: >The 6.5.7.rc1 release of fetchmail is now available at the usual locations, >including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. > > >Please test this especially if >+ you use SMTP AUTH (esmtppassword) >+ and/or want to store your SMTP passwords in .netrc >and share feedback mentioning the 6.5.7.rc1 version via list, >by e-mail or, if you find a bug, Gitlab issue (account required) at >https://gitlab.com/fetchmail/fetchmail/-/issues - >note for bug reports that AUTH PLAIN and AUTH LOGIN data must be redacted >from your reports, these can be reversed to reveal your password! > >Reminder: only subscribers to the fetchmail mailing lists can send mail there. > > >Plan: > >I intend this to further clean up the SMTP AUTH code, which I saw necessary >when fixing the security bug in 6.5.6, and collect the translations, which >I could not wait for when making the security bugfix release. > >If we don't see regressions, I intend to release 6.5.7 in c. 10 days. > >Afterwards, I intend to quickly follow up with an unplanned but necessary >fetchmail 6.6.0 feature release that will add TLS and STARTTLS support for >SMTP because we don't have strong protection for SMTP passwords yet. > > >The source archive is available at: ><https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.7.rc1.tar.xz/download> > >The detached GnuPG signature is available at: ><https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.7.rc1.tar.xz.asc/download> > >The SHA256 hashes for the tarballs are: >SHA2-256(fetchmail-6.5.7.rc1.tar.xz)= 2aa57f8cfe117dcfaf0a481a8c607dc401c15603bcb641bc610ec794c398cb9a > > >Here are the release notes: >-------------------------------------------------------------------------------- >fetchmail-6.5.7 (not yet released): > >## BUGFIX: >* When authenticating to an SMTP server, the AUTH LOGIN method (which didn't > become a proposed standard, and is only the third method fetchmail would try, > if CRAM-MD5 and PLAIN weren't offered) required that the server returned > a 334 code followed by a blank and by a decodable base64 challenge we ignored > anyways. This is in line with RFC 4952. > However, to improve compatibility, fetchmail now accepts anything that > starts with "334 " and disregards the remainder of the line. > At the same time, AUTH LOGIN was deprecated. AUTH PLAIN should be available > everywhere AUTH LOGIN is, and is specified in IETF RFC 4616. >* When authenticating to an SMTP server, i. e. esmtpname/esmtppassword are > defined, check for errors, and skip servers that do not understand EHLO, > because we cannot negotiate supported authentication schemes with them. > This should avoid attempting to send a lot of messages and see them rejected. >* When authenticating to an SMTP server, do not send client abort "*" when > we receive any other server reply but 334. >* Extend 6.5.6's RFC-5321 address-literal fix to MAIL FROM:<>. This might > apply when we only have a server's IP address and need to quality > addresses without domain. Fixes Debian Bug#1080025. >* SMTP AUTH can now look up passwords from the .netrc file - for that, > fetchmail's esmtpname setting must match the login for the given host in > .netrc. Fixes Debian Bug#1056651 by Ticker Berkin. > >## TRANSLATION UPDATES were contributed by these fine people - thank you! >* cs: Petr Pisar [Czech] >* eo: Keith Bowes [Esperanto] >* es: Cristian Othón Martínez Vera [Spanish] >* fr: Frédéric Marchal [French] >* ja: Takeshi Hamasaki [Japanese] >* pl: Jakub Bogusz [Polish] >* ro: Remus-Gabriel Chelu [Romanian] >* sv: Göran Uddeborg [Swedish] > >------------------------------------------------------------------------------- >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA512 > >fetchmail-SA-2025-01: SMTP AUTH denial of service > >Topics: fetchmail SMTP client can crash when authenticating > >Author: Matthias Andree >Version: 1.0 >Announced: 2025-10-03 >Type: failure to validate network input in certain configurations >Impact: fetchmail tries to read from address 1 and can crash >Severity: moderate > >URL: https://www.fetchmail.info/fetchmail-SA-2025-01.txt >Project URL: https://www.fetchmail.info/ >CVE Name: pending, requested via MITRE as CNA-LR > >Affects: - fetchmail releases up to and including 6.5.5 > - fetchmail 7.0.0 pre-releases > >Not affected: - fetchmail 6.5 releases 6.5.6 and newer > >Introduced in: 2002-03-09 fetchmail release 5.9.9 added SMTP AUTH > >Corrected in: 2025-10-03 Git commit 4c3cebfa4e659fb778ca2cae0ccb3f69201609a8 > 2025-10-03 fetchmail release 6.5.6 > > >1. Background >============= > >fetchmail is a software package to retrieve mail from remote POP3, IMAP, >ETRN or ODMR servers and forward it to local SMTP, LMTP servers or >message delivery agents. > >fetchmail defaults to using the SMTP server on "localhost" >and to not attempting to authenticate, unless configured otherwise. > >fetchmail also supports a "daemon" mode, where it runs over extended time >and periodically polls the upstream servers. This can detach fetchmail >from the controlling terminal into the background, or - with a "nodetach" setting >- - keep attached to the controlling terminal, which also eases use by >service supervisors. > > >2. Problem description and Impact >================================= > >fetchmail's SMTP client, when configured to authenticate [1], is susceptible >to a protocol violation where, when a trusted but malicious or malfunctioning >SMTP server responds to an authentication request with a "334" code but without a >following blank on the line, it will attempt to start reading from memory >address 0x1 to parse the server's SASL challenge. This address is constant and not >under the attacker's control. This event will usually cause a crash of fetchmail. > If fetchmail in this situation was running in daemon mode, this mode is also >terminated by the crash. > >[1] This requires the esmtpname and esmtppassword options to be configured in >the configuration file and the plugout and mda options to be inactive. > >As a word of warning, this vulnerability has eluded several static code analyzers. > > >3. Solutions >============ > >General recommendation: if running fetchmail in the background or in daemon >mode, ensure that the daemon is supervised and crashes are reported so that >action can be taken about the malfunctioning SMTP server, or on fetchmail's end >to replace local delivery by different server or other means. > > >3a. Install fetchmail 6.5.6 or newer. > >The fetchmail source code is available from ><https://sourceforge.net/projects/fetchmail/files/> and ><https://gitlab.com/fetchmail/fetchmail/-/releases> > >The Git-based source code repository is currently published via >https://gitlab.com/fetchmail/fetchmail/-/tree/legacy_6x (primary) >https://sourceforge.net/p/fetchmail/git/ci/legacy_6x/tree/ (copy) > > >3b. Apply the smtp.c patch from the URL below and rebuild fetchmail: ><https://gitlab.com/fetchmail/fetchmail/-/commit/4c3cebfa4e659fb778ca2cae0ccb3f69201609a8> > > >A. Copyright, License and Non-Warranty >====================================== > >(C) Copyright 2025 by Matthias Andree, <mat...@gm...>. >Some rights reserved. > >This file is licensed under CC BY-ND 4.0. To view a copy of this license, >visit <http://creativecommons.org/licenses/by-nd/4.0/> > >THIS WORK IS PROVIDED FREE OF CHARGE AND WITHOUT ANY WARRANTIES. >Use the information herein at your own risk. > >END of fetchmail-SA-2025-01 >-----BEGIN PGP SIGNATURE----- > >iQIzBAEBCgAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAmjfuj8ACgkQ5BKxVu/z >hVoXfRAApBdTub7EDpczbGlHfuqM96xFFRXHahETtL3sPSTNf+EB5CpBH+t5wV2M >zeYcdbYLgf0X/nT8+ua2lyP8c5YW5OOntINa49HOwYhTnIf/Msju4NS9RExigOxM >xpUAFNO8Mci79q7NWxrNJkOZIy5OfM1cTxXfECbibWjg2MsbZj7BaJu3EdkEmpOp >bzKBbL87Fv3dfYYvrRgBeJo7jvl9PqqNgY+WtBSC4lkHKstA0QaEYvkZDzQW4pwC >ZUQASWpDHEQTU5VSaKNXEMy3g9nqmLtMBx66VH8Gzv/dh73x5rouiExKQIjKBMxD >LUkibZ2iQOQR2gETd/QwtY98W5KGCW5pjVdIV2SJsoPOte0OEaMI5aersREmI52O >R++3dmOeKbT/DW6SGCvY8xGKXqCfQfQy66XY3/ZXBpE7xJITGEzjiYqOv7Tt5L8E >3VKCRC/MVbkrPF8Hnh9It75OdxO6v1gG/GNBOStiHVU6cOhPQmwykhTug4UjfOzZ >0n6c5DNk7Lz3m1AjWHIGgO7v0rHWibH5rw3ksBQi0X3OSv4xqrSTHsQz0WV+l3KS >q98e0GtG5g/aKQL1EWp+/VNXjrhm3I+Wg+haR3zJ/PcTdxEfpaXW4RUTsK2MAxvm >1HPZuyhLFpgsptFGvPbJONUnah/OWttaPCfrM5neP9wZzPHLnjs= >=Su9H >-----END PGP SIGNATURE----- >_______________________________________________ >Fetchmail-users mailing list >Fet...@li... >https://lists.sourceforge.net/lists/listinfo/fetchmail-users |
|
From: Matthias A. <mat...@gm...> - 2025-10-08 14:40:47
|
The 6.5.7.rc1 release of fetchmail is now available at the usual locations, including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. Please test this especially if + you use SMTP AUTH (esmtppassword) + and/or want to store your SMTP passwords in .netrc and share feedback mentioning the 6.5.7.rc1 version via list, by e-mail or, if you find a bug, Gitlab issue (account required) at https://gitlab.com/fetchmail/fetchmail/-/issues - note for bug reports that AUTH PLAIN and AUTH LOGIN data must be redacted from your reports, these can be reversed to reveal your password! Reminder: only subscribers to the fetchmail mailing lists can send mail there. Plan: I intend this to further clean up the SMTP AUTH code, which I saw necessary when fixing the security bug in 6.5.6, and collect the translations, which I could not wait for when making the security bugfix release. If we don't see regressions, I intend to release 6.5.7 in c. 10 days. Afterwards, I intend to quickly follow up with an unplanned but necessary fetchmail 6.6.0 feature release that will add TLS and STARTTLS support for SMTP because we don't have strong protection for SMTP passwords yet. The source archive is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.7.rc1.tar.xz/download> The detached GnuPG signature is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.7.rc1.tar.xz.asc/download> The SHA256 hashes for the tarballs are: SHA2-256(fetchmail-6.5.7.rc1.tar.xz)= 2aa57f8cfe117dcfaf0a481a8c607dc401c15603bcb641bc610ec794c398cb9a Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.5.7 (not yet released): ## BUGFIX: * When authenticating to an SMTP server, the AUTH LOGIN method (which didn't become a proposed standard, and is only the third method fetchmail would try, if CRAM-MD5 and PLAIN weren't offered) required that the server returned a 334 code followed by a blank and by a decodable base64 challenge we ignored anyways. This is in line with RFC 4952. However, to improve compatibility, fetchmail now accepts anything that starts with "334 " and disregards the remainder of the line. At the same time, AUTH LOGIN was deprecated. AUTH PLAIN should be available everywhere AUTH LOGIN is, and is specified in IETF RFC 4616. * When authenticating to an SMTP server, i. e. esmtpname/esmtppassword are defined, check for errors, and skip servers that do not understand EHLO, because we cannot negotiate supported authentication schemes with them. This should avoid attempting to send a lot of messages and see them rejected. * When authenticating to an SMTP server, do not send client abort "*" when we receive any other server reply but 334. * Extend 6.5.6's RFC-5321 address-literal fix to MAIL FROM:<>. This might apply when we only have a server's IP address and need to quality addresses without domain. Fixes Debian Bug#1080025. * SMTP AUTH can now look up passwords from the .netrc file - for that, fetchmail's esmtpname setting must match the login for the given host in .netrc. Fixes Debian Bug#1056651 by Ticker Berkin. ## TRANSLATION UPDATES were contributed by these fine people - thank you! * cs: Petr Pisar [Czech] * eo: Keith Bowes [Esperanto] * es: Cristian Othón Martínez Vera [Spanish] * fr: Frédéric Marchal [French] * ja: Takeshi Hamasaki [Japanese] * pl: Jakub Bogusz [Polish] * ro: Remus-Gabriel Chelu [Romanian] * sv: Göran Uddeborg [Swedish] ------------------------------------------------------------------------------- |
|
From: Matthias A. <mat...@gm...> - 2025-10-03 13:40:29
|
The 6.5.6 release of fetchmail is now available at the usual locations, including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. The source archive is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.6.tar.xz/download> The detached GnuPG signature is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.6.tar.xz.asc/download> The SHA256 hashes for the tarballs are: SHA2-256(fetchmail-6.5.6.tar.xz)= ec10e0e0eaa417313559379ede76c74614766d838b39470b66474863aa690dab Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.5.6 (released 2025-10-03, 31795 LoC): ## SECURITY BUGFIX: * fetchmail-SA-2025-01.txt: CVE pending assignment by MITRE An SMTP server advertising EHLO and AUTH, and if fetchmail is configured to authenticate (esmtpname and esmtppassword given and non-empty), the server might crash fetchmail by sending a "334" response without further blank to fetchmail's AUTH request. This is in violation of applicable RFC-4952 though. Fetchmail now detects this situation and reports it separately as malformed server reply. Fetchmail 6.5.6 has been released without waiting for translation updates or CVE identifier, these will be provided in followup releases. ## BUGFIXES: * RFC-5321: When the --smtpaddress, --smtphost, --smtpname, -D or -S argument is an numeric address literal such as 192.0.2.2 or 2001:0DB8::4321, properly format that as such in the SMTP RCPT command as user@[192.0.2.2] or user@[IPv6:2001:0DB8::4321]. * When printing output on the console while fetching mail, do not intersperse another copy of our program name and date in the middle of a log line. Workaround for older versions: --logfile /dev/tty (might also use --logfile /dev/stderr) - but note this changes buffering behavior and may output to appear later and without ticker marks. * A few low-priority memory leaks in the command-line options parser were fixed. Since this parser runs only once, leaks are harmless. * Some minor code cleanups and robustness fixes were made, and we should see fewer compiler warnings as a result. ## CHANGES: * Given the slow update schedules of some distributions, already add code that checks if time_t() is good beyond the year 2038, meaning time_t is either unsigned (which would last until 2106) or 64 bits wide. If the system isn't safe, warn on every launch of fetchmail beginning 2028-01-01 at 00:00 GMT so users have 10 years to plan. Fetchmail will also print a warning if time(time_t *t) overflows. ------------------------------------------------------------------------------- |
|
From: Matthias A. <mat...@gm...> - 2025-09-24 19:03:57
|
The 6.5.5 release of fetchmail is now available at the usual locations, including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. Note this re-enables DNS-based features on ./configure-based builds with GCC 15 and other compilers that implement C23 by default. The source archive is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.5.tar.xz/download> The detached GnuPG signature is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.5.tar.xz.asc/download> The SHA256 hashes for the tarballs are: SHA2-256(fetchmail-6.5.5.tar.xz)= f989b62729c76afbcd65ec43b9c477f2d990f0913da141ff8166aa4e2bf56025 Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.5.5 (released 2025-09-24, 31528 LoC): ## LICENSING CHANGE OF WOLFSSL: * Note that wolfSSL 5.8.2 switched license from GPLv2 to GPLv3, so if a distribution links fetchmail against wolfSSL, this implies the use of the "or-any-later-version" clause of the GPLv2-or-later licensed material in fetchmail, and the combined work can also only ship as GPLv3. This may or may not apply to later versions of wolfSSL - be sure to check! ## BUGFIXES: ==-- note that these comprise C23 compatibility fixes (GCC 15) --== * Support t.operation when the running user is different from the one mentioned in the $USER variable. Fix courtesy of Corey Halpin. * The kerberos*_auth() functions for v4 and v5 have prototypes now, so they can be compiled by the most modern C compilers. * AC_TYPE_* type-checking macros seem unnecessary, strip them, also from config.h.meson which would not fill them from build.meson. We expect the operating system to provide us pid_t, size_t, uint32_t. * Our res_search() autoconf check was broken on compilers adhering to newer standards (C23), for instance GCC 15, disabling several DNS-based features in autotools-based builds, but not meson-based builds. Strip the bogus "extern int res_search();" declaration without prototype, we would need to have the prototype from the system either way. ## IMPORTANT CHANGE: * Fetchmail is now more careful to actually clear password and like buffers in memory, so that is less likely that other processes could access them should they happen to access similar memory regions after fetchmail's exit. Fetchmail now uses memset_explicit(), explicit_bzero(), or its own explicit_bzero() implementation to clear memory buffers that contain passwords or like secrets, or their base64 equivalents, and also buffers that it uses to visualize such strings, instead of just using memset(). The motivating reason is that a plain memset() that does not have /observable/ effects, i. e. when we do not read from the buffer or transfer it, can be removed by the compiler's optimizer in the so-called dead store elimination, voiding our attempt to clear the buffer contents before releasing it to the heap. The named alternative functions are not being optimized away. ## WORKAROUND: * IMAP: Recognize SASL_IR advertisement of Cyrus IMAP 3.10.0...3.12.? as synonymous to SASL-IR per RFC4959. Upstream bug reported at https://github.com/cyrusimap/cyrus-imapd/issues/5481 - and it was quickly fixed in all their supported branches by patch releases. ## CHANGES: * Several documentation tweaks. * As long as SOURCE_DATE_EPOCH is set, the source tarball build may be reproducible now. Tested on Fedora 42. * The Japanese translation [ja] has been updated by Takeshi Hamasaki. * The Makefile should be compatible across a wider set of make implementations, beyond GNU make. ------------------------------------------------------------------------------- |
|
From: Matthias A. <mat...@gm...> - 2025-09-23 19:32:57
|
Am 23.09.25 um 12:21 schrieb Christian Ebert: > > > * Matthias Andree via Fetchmail-users on Sunday, September 21, 2025 at > 15:03:17 +0200: >> Am 21.09.25 um 10:24 schrieb Christian Ebert: >>> Hi, >>> >>> * Matthias Andree via Fetchmail-users on Tuesday, September 16, 2025 >>> at 12:51:18 +0200: >>>> The 6.5.5.rc1 release candidate >>>> of fetchmail is now available at the usual locations, including >>>> <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. >>> >>> Thank you. >>> >>>> Please test soon in your usual configuration, please compile with >>>> -fsanitize=address,undefined added to CFLAGS if your compiler supports >>>> that, and let me know if it's OK or if new issues show up. >>> >>> It doesn't build on macos x: >>> >>> [...] >>> depbase=`echo explicit_bzero.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ >>> gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" -I. >>> -I/opt/local/libexec/openssl3/include -I/Users/chris/.local/include >>> -I/usr/local/include -I/opt/local/include -I/opt/local/include/X11 >>> -I/opt/local/lib/ImageMagick7/include -DBIND_8_COMPAT >>> -I/Users/chris/.local/include -I/usr/local/include >>> -I/opt/local/include -I/opt/local/include/X11 >>> -I/opt/local/lib/ImageMagick7/include -I/opt/local/include >>> -I/usr/kerberos/include -MT explicit_bzero.o -MD -MP -MF >>> $depbase.Tpo -c -o explicit_bzero.o explicit_bzero.c &&\ >>> mv -f $depbase.Tpo $depbase.Po >>> explicit_bzero.c:10:6: error: conflicting types for 'explicit_bzero' >>> 10 | void explicit_bzero(char *buf, size_t sz) >>> | ^ >>> ./fetchmail.h:713:6: note: previous declaration is here >>> 713 | void explicit_bzero(void *buffer, size_t size); >>> | ^ >>> 1 error generated. >>> make[2]: *** [explicit_bzero.o] Error 1 >>> make[1]: *** [all-recursive] Error 1 >>> make: *** [all] Error 2 >>> >> Thanks for the test and report. That's unintentional. This escaped my >> testing so far because all OSes I have tested so far do provide >> explicit_bzero. > > Kind of guessed it would be something like that. > >> Does it compile and work if you replace the "char *buf" by "void >> *buf" on line 10 in explicit_bzero.c? > > Compiles and works perfectly. Thanks a bunch. > > I was about to try the "void *buf", but better safe than sorry, so I > asked. > Hi Christian, thanks for the re-test, I had sort of expected my patch would work from the error messagtes, and had already pushed it, so it will become part of upcoming fetchmail 6.5.5. -> <https://gitlab.com/fetchmail/fetchmail/-/commit/8f2da41b80888f82b644eb638df3e44023ceec57> Cheers, Matthias |
|
From: Christian E. <bc...@ph...> - 2025-09-23 10:21:58
|
* Matthias Andree via Fetchmail-users on Sunday, September 21, 2025 at 15:03:17 +0200: > Am 21.09.25 um 10:24 schrieb Christian Ebert: >> Hi, >> >> * Matthias Andree via Fetchmail-users on Tuesday, September 16, 2025 >> at 12:51:18 +0200: >>> The 6.5.5.rc1 release candidate >>> of fetchmail is now available at the usual locations, including >>> <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. >> >> Thank you. >> >>> Please test soon in your usual configuration, please compile with >>> -fsanitize=address,undefined added to CFLAGS if your compiler supports >>> that, and let me know if it's OK or if new issues show up. >> >> It doesn't build on macos x: >> >> [...] >> depbase=`echo explicit_bzero.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ >> gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" >> -I. -I/opt/local/libexec/openssl3/include >> -I/Users/chris/.local/include -I/usr/local/include >> -I/opt/local/include -I/opt/local/include/X11 >> -I/opt/local/lib/ImageMagick7/include -DBIND_8_COMPAT >> -I/Users/chris/.local/include -I/usr/local/include >> -I/opt/local/include -I/opt/local/include/X11 >> -I/opt/local/lib/ImageMagick7/include -I/opt/local/include >> -I/usr/kerberos/include -MT explicit_bzero.o -MD -MP -MF >> $depbase.Tpo -c -o explicit_bzero.o explicit_bzero.c &&\ >> mv -f $depbase.Tpo $depbase.Po >> explicit_bzero.c:10:6: error: conflicting types for 'explicit_bzero' >> 10 | void explicit_bzero(char *buf, size_t sz) >> | ^ >> ./fetchmail.h:713:6: note: previous declaration is here >> 713 | void explicit_bzero(void *buffer, size_t size); >> | ^ >> 1 error generated. >> make[2]: *** [explicit_bzero.o] Error 1 >> make[1]: *** [all-recursive] Error 1 >> make: *** [all] Error 2 >> > Thanks for the test and report. That's unintentional. This escaped my > testing so far because all OSes I have tested so far do provide > explicit_bzero. Kind of guessed it would be something like that. > Does it compile and work if you replace the "char *buf" by "void *buf" > on line 10 in explicit_bzero.c? Compiles and works perfectly. Thanks a bunch. I was about to try the "void *buf", but better safe than sorry, so I asked. -- LAST SHIP HOME The circumnavigation of the world of the Peter von Danzig Winner of the German Ocean Film Award 2019 Watch the movie in full online: https://lastshiphome.de/en/movie |
|
From: Matthias A. <mat...@gm...> - 2025-09-21 20:56:34
|
Am 21.09.25 um 21:58 schrieb axreios: > I see I previously did not understand how to set the CFLAGS. Now that I > have thankfully been instructed, it seems to work. So also > --disable-POP3 works, though now I am running ArtixLinux, which has gcc > 15.2.1+r22+gc4e96a094636-1 and make 4.4.1-2. Sorry, I did not keep that > make error. Sorry for all the noise. OK, it might have been something else then. make does not understand a --disable-POP3 option, but configure would. Thanks for the re-test! |
|
From: axreios <rp...@am...> - 2025-09-21 19:59:53
|
I see I previously did not understand how to set the CFLAGS. Now that I have thankfully been instructed, it seems to work. So also --disable-POP3 works, though now I am running ArtixLinux, which has gcc 15.2.1+r22+gc4e96a094636-1 and make 4.4.1-2. Sorry, I did not keep that make error. Sorry for all the noise. ax. On Sun, Sep 21, 2025 at 03:10:22PM +0200, Matthias Andree via Fetchmail-users wrote: >Am 16.09.25 um 16:33 schrieb axreios: >>Greetings. When I did the simple 3-step (configure, make, make >>install), this RC1 compiled nicely and is working OK on my simple >>system. I had tried adding the -fsanitize=address,undefined but that >>seemed to be ignored. Separately, when I tried --disable-POP3, make >>erred; so I removed the disable POP3 and make ran without error. >> My system is Dell Optiplex 7020 SFF, Intel I5-4690 running an >> up-to-date VoidLinux with gcc 14.2.1-20250405_2 and make >> 4.4.1_1. > >Thanks for the test. The -fsanitize=address,undefined would go like this: > >make clean > >env 'CFLAGS=-fsanitize=address,undefined -fno-omit-frame-pointer -O >-ggdb3' ./configure > >make > > >and then test. > > >Did you happen to keep the exact errors you got from the ./configure >--disable-POP3 ; make? > >It does work for me on Fedora Linux. > > > >_______________________________________________ >Fetchmail-users mailing list >Fet...@li... >https://lists.sourceforge.net/lists/listinfo/fetchmail-users |
|
From: Matthias A. <mat...@gm...> - 2025-09-21 14:15:16
|
Am 21.09.25 um 15:10 schrieb Matthias Andree via Fetchmail-users: > Am 16.09.25 um 16:33 schrieb axreios: >> Greetings. When I did the simple 3-step (configure, make, make >> install), this RC1 compiled nicely and is working OK on my simple >> system. I had tried adding the -fsanitize=address,undefined but that >> seemed to be ignored. Separately, when I tried --disable-POP3, make >> erred; so I removed the disable POP3 and make ran without error. >> My system is Dell Optiplex 7020 SFF, Intel I5-4690 running an >> up-to-date VoidLinux with gcc 14.2.1-20250405_2 and make >> 4.4.1_1. > > Thanks for the test. The -fsanitize=address,undefined would go like this: > > make clean > > env 'CFLAGS=-fsanitize=address,undefined -fno-omit-frame-pointer -O > -ggdb3' ./configure > > make > > > and then test. > > > Did you happen to keep the exact errors you got from the ./configure > --disable-POP3 ; make? > > It does work for me on Fedora Linux. It also works for me on Void Linux, just installed in the musl variant. |
|
From: Matthias A. <mat...@gm...> - 2025-09-21 13:10:30
|
Am 16.09.25 um 16:33 schrieb axreios: > Greetings. When I did the simple 3-step (configure, make, make > install), this RC1 compiled nicely and is working OK on my simple > system. I had tried adding the -fsanitize=address,undefined but that > seemed to be ignored. Separately, when I tried --disable-POP3, make > erred; so I removed the disable POP3 and make ran without error. > My system is Dell Optiplex 7020 SFF, Intel I5-4690 running an > up-to-date VoidLinux with gcc 14.2.1-20250405_2 and make > 4.4.1_1. Thanks for the test. The -fsanitize=address,undefined would go like this: make clean env 'CFLAGS=-fsanitize=address,undefined -fno-omit-frame-pointer -O -ggdb3' ./configure make and then test. Did you happen to keep the exact errors you got from the ./configure --disable-POP3 ; make? It does work for me on Fedora Linux. |
|
From: Matthias A. <mat...@gm...> - 2025-09-21 13:03:31
|
Am 21.09.25 um 10:24 schrieb Christian Ebert: > Hi, > > * Matthias Andree via Fetchmail-users on Tuesday, September 16, 2025 > at 12:51:18 +0200: >> The 6.5.5.rc1 release candidate >> of fetchmail is now available at the usual locations, including >> <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. > > Thank you. > >> Please test soon in your usual configuration, please compile with >> -fsanitize=address,undefined added to CFLAGS if your compiler supports >> that, and let me know if it's OK or if new issues show up. > > It doesn't build on macos x: > > [...] > depbase=`echo explicit_bzero.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" -I. > -I/opt/local/libexec/openssl3/include -I/Users/chris/.local/include > -I/usr/local/include -I/opt/local/include -I/opt/local/include/X11 > -I/opt/local/lib/ImageMagick7/include -DBIND_8_COMPAT > -I/Users/chris/.local/include -I/usr/local/include > -I/opt/local/include -I/opt/local/include/X11 > -I/opt/local/lib/ImageMagick7/include -I/opt/local/include > -I/usr/kerberos/include -MT explicit_bzero.o -MD -MP -MF $depbase.Tpo > -c -o explicit_bzero.o explicit_bzero.c &&\ > mv -f $depbase.Tpo $depbase.Po > explicit_bzero.c:10:6: error: conflicting types for 'explicit_bzero' > 10 | void explicit_bzero(char *buf, size_t sz) > | ^ > ./fetchmail.h:713:6: note: previous declaration is here > 713 | void explicit_bzero(void *buffer, size_t size); > | ^ > 1 error generated. > make[2]: *** [explicit_bzero.o] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > Thanks for the test and report. That's unintentional. This escaped my testing so far because all OSes I have tested so far do provide explicit_bzero. Does it compile and work if you replace the "char *buf" by "void *buf" on line 10 in explicit_bzero.c? |
|
From: Christian E. <bc...@ph...> - 2025-09-21 08:45:20
|
Hi, * Matthias Andree via Fetchmail-users on Tuesday, September 16, 2025 at 12:51:18 +0200: > The 6.5.5.rc1 release candidate > of fetchmail is now available at the usual locations, including > <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. Thank you. > Please test soon in your usual configuration, please compile with > -fsanitize=address,undefined added to CFLAGS if your compiler supports > that, and let me know if it's OK or if new issues show up. It doesn't build on macos x: [...] depbase=`echo explicit_bzero.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" -I. -I/opt/local/libexec/openssl3/include -I/Users/chris/.local/include -I/usr/local/include -I/opt/local/include -I/opt/local/include/X11 -I/opt/local/lib/ImageMagick7/include -DBIND_8_COMPAT -I/Users/chris/.local/include -I/usr/local/include -I/opt/local/include -I/opt/local/include/X11 -I/opt/local/lib/ImageMagick7/include -I/opt/local/include -I/usr/kerberos/include -MT explicit_bzero.o -MD -MP -MF $depbase.Tpo -c -o explicit_bzero.o explicit_bzero.c &&\ mv -f $depbase.Tpo $depbase.Po explicit_bzero.c:10:6: error: conflicting types for 'explicit_bzero' 10 | void explicit_bzero(char *buf, size_t sz) | ^ ./fetchmail.h:713:6: note: previous declaration is here 713 | void explicit_bzero(void *buffer, size_t size); | ^ 1 error generated. make[2]: *** [explicit_bzero.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 $ sw_vers ProductName: macOS ProductVersion: 15.7 BuildVersion: 24G222 FWIW, the next branch builds fine. But then it doesn't feature the explicit_bzero stuff (yet). -- LAST SHIP HOME The circumnavigation of the world of the Peter von Danzig Winner of the German Ocean Film Award 2019 Watch the movie in full online: https://lastshiphome.de/en/movie |
|
From: Andrea V. <ml...@ne...> - 2025-09-17 07:54:39
|
On 6/23/25 18:53, Matthias Andree via Fetchmail-users wrote: > I would probably start by checking what actual error code is passed > through this code in driver.c (near line 1150) as return from the - > >getauth(...) method: Hello. I think I found the reason. In the logs I see: > sm-mta[13685]: 589NKPid013685: collect: relay=[127.0.2.1], from=<FET...@ma...>, info=Bare linefeed (LF) not allowed, where=body, status=tempfail > sm-mta[13685]: 589NKPid013685: from=<FET...@ma...xxxxxx..it>, size=337, class=0, nrcpts=1, proto=ESMTP, daemon=MTA, relay=[127.0.2.1] I'll try and change the code to use CRLF instead... bye av. |
|
From: axreios <rp...@am...> - 2025-09-16 14:59:08
|
Greetings. When I did the simple 3-step (configure, make, make install), this RC1 compiled nicely and is working OK on my simple system. I had tried adding the -fsanitize=address,undefined but that seemed to be ignored. Separately, when I tried --disable-POP3, make erred; so I removed the disable POP3 and make ran without error. My system is Dell Optiplex 7020 SFF, Intel I5-4690 running an up-to-date VoidLinux with gcc 14.2.1-20250405_2 and make 4.4.1_1. |
|
From: Matthias A. <mat...@gm...> - 2025-09-16 10:51:27
|
The 6.5.5.rc1 release candidate of fetchmail is now available at the usual locations, including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. Please test soon in your usual configuration, please compile with -fsanitize=address,undefined added to CFLAGS if your compiler supports that, and let me know if it's OK or if new issues show up. I intend to release 6.5.5 next week if things work out. The source archive is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.5.rc1.tar.xz/download> The detached GnuPG signature is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.5.rc1.tar.xz.asc/download> The SHA256 hashes for the tarballs are: SHA2-256(fetchmail-6.5.5.rc1.tar.xz)= c35eeece253a1bf4b0aa8f3467f8d0eb111d99c3caddbdf5f8fdbd2413ef9b63 Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.5.5 (not yet released): ## LICENSING CHANGE OF WOLFSSL: * Note that wolfSSL 5.8.2 switched license from GPLv2 to GPLv3, so if a distribution links fetchmail against wolfSSL, this implies the use of the "or-any-later-version" clause of the GPLv2-or-later licensed material in fetchmail, and the combined work can also only ship as GPLv3. wolfSSL has therefore lost its licensing advantage and has been marked for potential removal in fetchmail 7 above. (OpenSSL 3 is under the Apache License 2.0 and a combined work of fetchmail with OpenSSL 3 also requires the combined work to ship as GPLv3.) ## BUGFIXES: ==-- note that these comprise C23 compatibility fixes (GCC 15) --== * Support t.operation when the running user is different from the one mentioned in the $USER variable. Fix courtesy of Corey Halpin. * The kerberos*_auth() functions for v4 and v5 have prototypes now, so they can be compiled by the most modern C compilers. * AC_TYPE_* type-checking macros seem unnecessary, strip them, also from config.h.meson which would not fill them from build.meson. We expect the operating system to provide us pid_t, size_t, uint32_t. * Our res_search() autoconf check was broken on compilers adhering to newer standards (C23), for instance GCC 15, disabling several DNS-based features in autotools-based builds, but not meson-based builds. Strip the bogus "extern int res_search();" declaration without prototype, we would need to have the prototype from the system either way. ## IMPORTANT CHANGE: * Fetchmail is now more careful to actually clear password and like buffers in memory, so that is less likely that other processes could access them should they happen to access similar memory regions after fetchmail's exit. Fetchmail now uses memset_explicit(), explicit_bzero(), or its own explicit_bzero() implementation to clear memory buffers that contain passwords or like secrets, or their base64 equivalents, and also buffers that it uses to visualize such strings, instead of just using memset(). The motivating reason is that a plain memset() that does not have /observable/ effects, i. e. when we do not read from the buffer or transfer it, can be removed by the compiler's optimizer in the so-called dead store elimination, voiding our attempt to clear the buffer contents before releasing it to the heap. The named alternative functions are not being optimized away. ## WORKAROUND: * IMAP: Recognize SASL_IR advertisement of Cyrus IMAP 3.10.0...3.12.? as synonymous to SASL-IR per RFC4959. Upstream bug reported at https://github.com/cyrusimap/cyrus-imapd/issues/5481 - and it was quickly fixed in all their supported branches by patch releases. ## CHANGES: * Several documentation tweaks. * As long as SOURCE_DATE_EPOCH is set, the source tarball build may be reproducible now. Tested on Fedora 42. * The Japanese translation [ja] has been updated by Takeshi Hamasaki. * The Makefile should be compatible across a wider set of make implementations, beyond GNU make. ------------------------------------------------------------------------------- |
|
From: Matthias A. <mat...@gm...> - 2025-08-29 17:53:55
|
REMINDER: Use fetchmail 6.5.X versions. fetchmail 6.4.Y and older versions are at the end of life. Also, the older versions contained faulty configure checks that cause the build to fail with, among others, GCC 15, and also other compilers that comply with newer versions of the C language standard in their factory setting. Current fetchmail versions of the 6.5 series (6.5.4 is the current release) build fine with recent compilers in C23 in my spot checks. Regards, Matthias |
|
From: Matthias A. <mat...@gm...> - 2025-06-23 16:53:26
|
Am 21.06.25 um 14:45 schrieb Andrea Venturoli:
> On 6/21/25 12:48, Matthias Andree via Fetchmail-users wrote:
>
> Hello.
>
> Thanks for your answer.
>
>
>
>> these warnings work only in daemon mode
>
> That's my case.
>
>
>
>> fetchmail runs for a sufficiently long time
>
> It's usually weeks, if not months before I restart it.
>
>
>
>> fetchmail didn't authenticate successfully, it should send the
>> warning after 3 failed attempts;
>
> It did (in the past); only it doesn't anymore :(
>
>
>
>> If fetchmail is triggered purely by cron or systemd timer or similar,
>
> Not my case.
>
>
>
>> Changes to configuration files also trigger fetchmail to discard
>> state and re-execute itself.
>
> These are very rare.
>
>
>
>> Oh, one more thing, this only happens on authentication failures and
>> timeouts BUT NOT on other errors,
>
> That's fine; that's what I'm trying to get.
>
>
>
> I thought some option was added to enable/disable this, but if you
> confirm it hasn't, I guess I'll need to try and debug this.
I would probably start by checking what actual error code is passed
through this code in driver.c (near line 1150) as return from the
->getauth(...) method:
> /* accept greeting message from mail server */
> err =
> (ctl->server.base_protocol->parse_response)(mailserver_socket, buf);
> if(err != 0)
> gotocleanUp;
>
> /* try to get authorized to fetch mail */
> if(ctl->server.base_protocol->getauth)
> {
> set_timeout(mytimeout);
> err =
> (ctl->server.base_protocol->getauth)(mailserver_socket, ctl, buf);
> set_timeout(0);
>
> if(err != 0)
> {
> if(err == PS_LOCKBUSY)
> report(stderr, GT_("Lock-busy error on %s@%s\n"),
> ctl->remotename,
> ctl->server.truename);
> elseif(err == PS_SERVBUSY)
> report(stderr, GT_("Server busy error on %s@%s\n"),
> ctl->remotename,
> ctl->server.truename);
> elseif(err == PS_AUTHFAIL)
> {
> report(stderr, GT_("Authorization failure on
> %s@%s%s\n"),
> ctl->remotename,
> ctl->server.truename,
> (ctl->wehaveauthed ? GT_(" (previously
> authorized)") : "")
> );
> if(ctl->server.authenticate == A_ANY && !ctl->wehaveauthed) {
> report(stderr, GT_("For help, see
> http://www.fetchmail.info/fetchmail-FAQ.html#R15\n"));
> }
>
|
|
From: Andrea V. <ml...@ne...> - 2025-06-21 12:45:36
|
On 6/21/25 12:48, Matthias Andree via Fetchmail-users wrote: Hello. Thanks for your answer. > these warnings work only in daemon mode That's my case. > fetchmail runs for a sufficiently long time It's usually weeks, if not months before I restart it. > fetchmail didn't authenticate successfully, it should send the warning > after 3 failed attempts; It did (in the past); only it doesn't anymore :( > If fetchmail is triggered purely by cron or systemd timer or similar, Not my case. > Changes to configuration files also trigger fetchmail > to discard state and re-execute itself. These are very rare. > Oh, one more thing, this only happens on authentication failures and timeouts BUT NOT on other errors, That's fine; that's what I'm trying to get. I thought some option was added to enable/disable this, but if you confirm it hasn't, I guess I'll need to try and debug this. bye & Thanks av. |
|
From: Matthias A. <mat...@gm...> - 2025-06-21 10:52:41
|
Am 21.06.25 um 12:48 schrieb Matthias Andree via Fetchmail-users:
> Am 20.06.25 um 14:30 schrieb Andrea Venturoli:
>> Hello.
>>
>> Suppose you set up fetchmail to get messages fro a service (POP or
>> IMAP) and it works; then something happens (e.g. the password
>> expires) and it stops working.
>> While I (as the sysadmin) can see this in the logs, I wish the user
>> who reads the emails was informed.
>> In the past this worked: he received a mail from fetchmail itself
>> saying auth was failing and another mail when everything was solved.
>> However, this hasn't been working for me for some time (after some
>> upgrade, I think, but without any change to configuration).
>>
>> What are the requirements to have these informational messages?
>> Some setting? Some prerequisite?
>> Has anything purposedly changed? (I don't know since when, however...
>> possibly several months).
>
>
> Hi Andrea,
>
> these warnings work only in daemon mode (run.poll_interval) and if
> fetchmail runs for a sufficiently long time, counting in intervals. If
> fetchmail didn't authenticate successfully, it should send the warning
> after 3 failed attempts; if it did authenticate ever before, after 10
> (both hardcoded). See below. I quick test with fetchmail 6.5.4 and
> arguments
>
> --mda "cat >/dev/null ; exit 75" and --proto imap --auth external
> --user -d 1 --nodetach on one of my servers complained "MDA returned
> nonzero status 75" and when using --mda "cat >/tmp/debug.txt || exit
> 75" put the warning message into the file -- so it seems to be working
> still.
>
> If fetchmail is triggered purely by cron or systemd timer or similar,
> they won't work. Changes to configuration files also trigger fetchmail
> to discard state and re-execute itself.
>
>
> This is from the 6.5.X code (the "in background" comment is
> inaccurate, --nodetach won't impact this):
>
>> /*
>> * If we're running in background, try to mail the
>> * calling user a heads-up about the authentication
>> * failure once it looks like this isn't a fluke
>> * due to the server being temporarily inaccessible.
>> * When we get third succesive failure, we notify
>> the user
>> * but only if we haven't already managed to get
>> * authorization. After that, once we get
>> authorization
>> * we let the user know service is restored.
>> */
>> if(run.poll_interval
>> && !ctl->wehavesentauthnote
>> && ((ctl->wehaveauthed && ++ctl->authfailcount
>> >= 10)
>> || (!ctl->wehaveauthed &&
>> ++ctl->authfailcount >= 3))
>> && !open_warning_by_mail(ctl))
>> {
>>
> The thing is that fetchmail doesn't store these
> authfailcount/wehaveauthed/wehavesentauthnote variables to disk.
>
> HTH & feel free to ask further questions
Oh, one more thing, this only happens on authentication failures and
timeouts BUT NOT on other errors, for instance, server/client
synchronization errors, for instance, if the user deletes an IMAP folder
(mailbox) and it can no longer be selected when using the --folder option.
|
|
From: Matthias A. <mat...@gm...> - 2025-06-21 10:48:49
|
Am 20.06.25 um 14:30 schrieb Andrea Venturoli:
> Hello.
>
> Suppose you set up fetchmail to get messages fro a service (POP or
> IMAP) and it works; then something happens (e.g. the password expires)
> and it stops working.
> While I (as the sysadmin) can see this in the logs, I wish the user
> who reads the emails was informed.
> In the past this worked: he received a mail from fetchmail itself
> saying auth was failing and another mail when everything was solved.
> However, this hasn't been working for me for some time (after some
> upgrade, I think, but without any change to configuration).
>
> What are the requirements to have these informational messages?
> Some setting? Some prerequisite?
> Has anything purposedly changed? (I don't know since when, however...
> possibly several months).
Hi Andrea,
these warnings work only in daemon mode (run.poll_interval) and if
fetchmail runs for a sufficiently long time, counting in intervals. If
fetchmail didn't authenticate successfully, it should send the warning
after 3 failed attempts; if it did authenticate ever before, after 10
(both hardcoded). See below. I quick test with fetchmail 6.5.4 and arguments
--mda "cat >/dev/null ; exit 75" and --proto imap --auth external
--user -d 1 --nodetach on one of my servers complained "MDA returned
nonzero status 75" and when using --mda "cat >/tmp/debug.txt || exit 75"
put the warning message into the file -- so it seems to be working still.
If fetchmail is triggered purely by cron or systemd timer or similar,
they won't work. Changes to configuration files also trigger fetchmail
to discard state and re-execute itself.
This is from the 6.5.X code (the "in background" comment is inaccurate,
--nodetach won't impact this):
> /*
> * If we're running in background, try to mail the
> * calling user a heads-up about the authentication
> * failure once it looks like this isn't a fluke
> * due to the server being temporarily inaccessible.
> * When we get third succesive failure, we notify
> the user
> * but only if we haven't already managed to get
> * authorization. After that, once we get
> authorization
> * we let the user know service is restored.
> */
> if(run.poll_interval
> && !ctl->wehavesentauthnote
> && ((ctl->wehaveauthed && ++ctl->authfailcount
> >= 10)
> || (!ctl->wehaveauthed &&
> ++ctl->authfailcount >= 3))
> && !open_warning_by_mail(ctl))
> {
>
The thing is that fetchmail doesn't store these
authfailcount/wehaveauthed/wehavesentauthnote variables to disk.
HTH & feel free to ask further questions
Regards,
Matthias
|
|
From: Andrea V. <ml...@ne...> - 2025-06-20 12:30:29
|
Hello. Suppose you set up fetchmail to get messages fro a service (POP or IMAP) and it works; then something happens (e.g. the password expires) and it stops working. While I (as the sysadmin) can see this in the logs, I wish the user who reads the emails was informed. In the past this worked: he received a mail from fetchmail itself saying auth was failing and another mail when everything was solved. However, this hasn't been working for me for some time (after some upgrade, I think, but without any change to configuration). What are the requirements to have these informational messages? Some setting? Some prerequisite? Has anything purposedly changed? (I don't know since when, however... possibly several months). bye & Thanks av. |
|
From: Matthias A. <mat...@gm...> - 2025-06-17 22:21:41
|
The 6.5.4 release of fetchmail is now available at the usual locations, including <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. The source archive is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.4.tar.xz/download> The detached GnuPG signature is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.4.tar.xz.asc/download> The SHA256 hashes for the tarballs are: SHA2-256(fetchmail-6.5.4.tar.xz)= c859156e9bff841d4d984cb3fdcb8042b6b31789fc3387c2649baa95a88d698b Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.5.4 (released 2025-06-17, 31208 LoC): ## BUGFIXES: * socket: avoid crash when writing to a socket without SSL/TLS fails. Reported by Andrea Venturoli via mailing list, fixes #71. * wolfSSL support: avoid fetchmail.c compilation failure in certain configurations of wolfSSL (for instance, on FreeBSD's wolfssl-5.8.0_1 package), OpenSSL_version enables a newer 1.1.x compat API that passes its argument to a wolfSSL API, with OPENSSL_DIR and OPENSSL_ENGINES_DIR, causing related compiler failures. See <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287435>. ------------------------------------------------------------------------------- |
|
From: Andrea V. <ml...@ne...> - 2025-06-17 06:53:23
|
On 6/16/25 18:40, Matthias Andree via Fetchmail-users wrote: > mille grazie for the report and debugging. You are welcome. > Would you also know a quick way to reproduce it? Not really. An idea might be: _ set up fetchmail to retrieve from somewhere *without SSL*; _ put a huge message on the server (so to have time for the next steps); _ start fetchmail; _ while it's fetching, unplug the network cable/drop the connection somehow/introduce a firewall block/... However I didn]'t try this. bye & Thanks av. |
|
From: Matthias A. <mat...@gm...> - 2025-06-16 16:40:16
|
Am 16.06.25 um 17:45 schrieb Andrea Venturoli: > Hello. > > Recently fetchmail has started crashing on a couple of servers of mine. Hi Andrea, mille grazie for the report and debugging. I've put this up as issue #71 <https://gitlab.com/fetchmail/fetchmail/-/issues/71>. Would you also know a quick way to reproduce it? > > The problem seems to be in socket.c: > >> int SockWrite(int sock, const char *buf, int len) >> { >> /* WARNING: This is messy - we use an int pointer, so does >> SSL_write, but fm_write/write would use ssize_t instead. >> Assume that write() won't ever return something that wouldn't >> fit an int. */ >> int n; >> int wrlen = 0; >> #ifdef SSL_ENABLE >> SSL *ssl = SSLGetContext(sock); >> #endif >> >> while (len) >> { >> #ifdef SSL_ENABLE >> if (ssl) { >> ERR_clear_error(); >> n = SSL_write(ssl, buf, len); >> } else >> #endif /* SSL_ENABLE */ >> n = fm_write(sock, buf, len); >> #ifdef SSL_ENABLE >> if (n <= 0) { >> int ssle = SSL_get_error(ssl, n); // do this before >> flushing the error queue! >> // map error code to n = 0 -> retryable or n = -1 -> true >> error >> switch(ssle) { >> case SSL_ERROR_ZERO_RETURN: >> case SSL_ERROR_SYSCALL: >> case SSL_ERROR_SSL: >> n = -1; break; >> default: >> /* assume retryable */ >> n = 0; break; >> } >> if (n) >> ERR_print_errors_fp(stderr); // do this after >> SSL_get_error - and only on fatal errors >> } >> #endif >> if (n < 0) >> return -1; >> len -= n; >> wrlen += n; >> buf += n; >> } >> return wrlen; >> } > > Here ssl is first checked in order to decide if SSL_write or fm_write > should be called. > Then, regardless of the choice, in case of error, SSL_get_error is > called (even when ssl is NULL) and that's where the program crashes. Plausible. I could issue 6.5.4 once I understand or reproduce this with a fix. > > > > Maybe I'm wrong, but I think the lines: >>> if (n <= 0) { >>> int ssle = SSL_get_error(ssl, n); // do this before >>> flushing the error queue! > > should be changed to: > >>> if (ssl && n <= 0) { >>> int ssle = SSL_get_error(ssl, n); // do this before >>> flushing the error queue! > > > (Or the whole "if {...}" could be moved inside the first "if (ssl)"). > > > > > In any case, thanks a lot for providing this software! Thanks a lot for your report! Cheers, Matthias |
18 messages has been excluded from this view by a project administrator.
