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
|
Nov
|
Dec
|
|
From: Matthias A. <mat...@gm...> - 2021-10-31 11:45:07
|
Am 16.10.21 um 17:18 schrieb hput: > Running ubuntu-21.04 > Running fetchmail -V: > ,---- > | This is fetchmail release 6.4.16+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. > | Compiled with SSL library 0x101010af "OpenSSL 1.1.1j 16 Feb 2021" > | Run-time uses SSL library 0x101010af "OpenSSL 1.1.1j 16 Feb 2021" > | OpenSSL: OPENSSLDIR: "/usr/lib/ssl" > | Engines: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" > `---- > > > If I run `fetchmail -vvvc', the tail of output shows: > > 1324764631.3974 = SEEN > 1324764631.3975 = SEEN > [...] snipped 17 more similar line > > 1324764631.4032 = SEEN > > Even if I've just run `fetchmail -vvva' making sure fetchmail pulls > down any `seen' messages. > > Looks like fetchmail is reporting 20 seen but not retrieved messages. > hput, Please provide full log information of a recent fetchmail per <https://www.fetchmail.info/fetchmail-FAQ.html#G3>. If you need support with the obsolete Ubuntu version, please contact Ubuntu instead (but I'm not giving you much hope for receiving anything but defensive e-mail). |
|
From: hput <hp...@fa...> - 2021-10-16 15:18:38
|
Running ubuntu-21.04
Running fetchmail -V:
,----
| This is fetchmail release 6.4.16+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5.
| Compiled with SSL library 0x101010af "OpenSSL 1.1.1j 16 Feb 2021"
| Run-time uses SSL library 0x101010af "OpenSSL 1.1.1j 16 Feb 2021"
| OpenSSL: OPENSSLDIR: "/usr/lib/ssl"
| Engines: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
`----
If I run `fetchmail -vvvc', the tail of output shows:
1324764631.3974 = SEEN
1324764631.3975 = SEEN
[...] snipped 17 more similar line
1324764631.4032 = SEEN
Even if I've just run `fetchmail -vvva' making sure fetchmail pulls
down any `seen' messages.
Looks like fetchmail is reporting 20 seen but not retrieved messages.
Is that right?
Also have `fetchall' in ~/fetchmailrc uid and passwd MUNGWED:
# set timeout 40
# set daemon 600
# set logfile /home/reader/t/var/log/fetchmail.log
poll pop.fastmail.com proto POP3 user MUNGED password MUNGED
ssl
## sslproto ''
fetchall
no keep
no rewrite
mda "/usr/bin/procmail -f %F -d %T";
|
|
From: hput <hp...@fa...> - 2021-10-16 14:48:05
|
Running ubuntu-21.04
Running fetchmail -V:
,----
| This is fetchmail release 6.4.16+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5.
| Compiled with SSL library 0x101010af "OpenSSL 1.1.1j 16 Feb 2021"
| Run-time uses SSL library 0x101010af "OpenSSL 1.1.1j 16 Feb 2021"
| OpenSSL: OPENSSLDIR: "/usr/lib/ssl"
| Engines: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
`----
If I run `fetchmail -vvvc', the tail of output shows:
1324764631.3974 = SEEN
1324764631.3975 = SEEN
[...] snipped 17 more similar line
1324764631.4032 = SEEN
Even if I've just run `fetchmail -vvva' making sure fetchmail knows
to retrieve all seen or not.
At a glance it seems to be reporting mail on the server that has been
viewed.
But, even in ~/.fetchmailrc I've told fetchmail `fetchall'
Maybe those `SEEN' lines mean something else?
my server is fastmail.com
~/.fetchmailrc (email addr and passwd munged):
# set timeout 40
# set daemon 600
# set logfile /home/reader/t/var/log/fetchmail.log
poll pop.fastmail.com proto POP3 user MUNGED password MUNGED.
ssl
## sslproto ''
fetchall
no keep
no rewrite
mda "/usr/bin/procmail -f %F -d %T";
------- ------- ---=--- ------- -------
|
|
From: Matthias A. <mat...@gm...> - 2021-09-13 21:18:24
|
Note that I had to re-roll the tarballs after missing a few documentation updates. The original tarballs were only available for a few minutes. The updated checksums are these: SHA256(fetchmail-6.4.22.tar.lz)= c704b2af5d083550a0b0f1d9af7284afe85247cba08f4e268f429db4b3d0c42a SHA256(fetchmail-6.4.22.tar.xz)= cc6818bd59435602169fa292d6d163d56b21c7f53112829470a3aceabe612c84 |
|
From: Matthias A. <mat...@gm...> - 2021-09-13 21:17:53
|
Note that I had to re-roll the tarballs after missing a few documentation updates. The original tarballs were only available for a few minutes. The updated checksums are these: SHA256(fetchmail-6.4.22.tar.lz)= c704b2af5d083550a0b0f1d9af7284afe85247cba08f4e268f429db4b3d0c42a SHA256(fetchmail-6.4.22.tar.xz)= cc6818bd59435602169fa292d6d163d56b21c7f53112829470a3aceabe612c84 |
|
From: Matthias A. <mat...@gm...> - 2021-09-13 21:06:18
|
Greetings, The 6.4.22 release of fetchmail is now available at <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. It contains the security fix for CVE-2021-39272 of 6.4.21 and earlier, fixes some crashes that can be triggered by local configurations, and makes some fixes to authentication and other changes, details below. DISTRIBUTORS please note OpenSSL's licensing change for OpenSSL 3, and you may want to review COPYING. The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.tar.xz/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.tar.lz/download> Detached GnuPG signatures for the respective tarballs are at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.tar.xz.asc/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.tar.lz.asc/download> SHA256 hash values for the tarballs: SHA256(fetchmail-6.4.22.tar.lz)= 5e596136660cca9b71f73c0f6fe79cc76db7db2b2dc33c08ad25241ed0cba368 SHA256(fetchmail-6.4.22.tar.xz)= 104379499a1346330a6799f1e20c790211dd07835cb1af5668dfd25de71357f4 Here are the release notes: --------------------------------------------------------------------------------- fetchmail-6.4.22 (released 2021-09-13, 30201 LoC): # OPENSSL AND LICENSING NOTE: * fetchmail 6.4.22 is compatible with OpenSSL 1.1.1 and 3.0.0. OpenSSL's licensing changed between these releases from dual OpenSSL/SSLeay license to Apache License v2.0, which is considered incompatible with GPL v2 by the FSF. For implications and details, see the file COPYING. # SECURITY FIXES: * CVE-2021-39272: fetchmail-SA-2021-02: On IMAP connections, without --ssl and with nonempty --sslproto, meaning that fetchmail is to enforce TLS, and when the server or an attacker sends a PREAUTH greeting, fetchmail used to continue an unencrypted connection. Now, log the error and abort the connection. --Recommendation for servers that support SSL/TLS-wrapped or "implicit" mode on a dedicated port (default 993): use --ssl, or the ssl user option in an rcfile. --Reported by: Andrew C. Aitchison, based on the USENIX Security 21 paper "Why TLS is better without STARTTLS - A Security Analysis of STARTTLS in the Email Context" by Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian Schinzel. The paper did not mention fetchmail. * On IMAP and POP3 connections, --auth ssh no longer prevents STARTTLS negotiation. * On IMAP connections, fetchmail does not permit overriding a server-side LOGINDISABLED with --auth password any more. * On POP3 connections, the possibility for RPA authentication (by probing with an AUTH command without arguments) no longer prevents STARTTLS negotiation. * For POP3 connections, only attempt RPA if the authentication type is "any". # BUG FIXES: * On IMAP connections, when AUTHENTICATE EXTERNAL fails and we have received the tagged (= final) response, do not send "*". * On IMAP connections, AUTHENTICATE EXTERNAL without username will properly send a "=" for protocol compliance. * On IMAP connections, AUTHENTICATE EXTERNAL will now check if the server advertised SASL-IR (RFC-4959) support and otherwise refuse (fetchmail <= 6.4 has not supported and does not support the separate challenge/response with command continuation) * On IMAP connections, when --auth external is requested but not advertised by the server, log a proper error message. * Fetchmail no longer crashes when attempting a connection with --plugin "" or --plugout "". * Fetchmail no longer leaks memory when processing the arguments of --plugin or --plugout on connections. * On POP3 connections, the CAPAbilities parser is now caseblind. * Fix segfault on configurations with "defaults ... no envelope". Reported by Bjørn Mork. Fixes Debian Bug#992400. This is a regression in fetchmail 6.4.3 and happened when plugging memory leaks, which did not account for that the envelope parameter is special when set as "no envelope". The segfault happens in a constant strlen(-1), triggered by trusted local input => no vulnerability. * Fix program abort (SIGABRT) with "internal error" when invalid sslproto is given with OpenSSL 1.1.0 API compatible SSL implementations. # CHANGES: * IMAP: When fetchmail is in not-authenticated state and the server volunteers CAPABILITY information, use it and do not re-probe. (After STARTTLS, fetchmail must and will re-probe explicitly.) * For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option do not match, emit a warning and continue. Closes Gitlab #31. (cherry-picked from 6.5 beta branch "legacy_6x") * fetchmail.man and README.SSL were updated in line with RFC-8314/8996/8997 recommendations to prefer Implicit TLS (--ssl/ssl) and TLS v1.2 or newer, placing --sslproto tls1.2+ more prominently. The defaults shall not change between 6.4.X releases for compatibility. # TRANSLATIONS: language translations were updated by these fine people: * sq: Besnik Bleta [Albanian] * cs: Petr Pisar [Czech] * eo: Keith Bowes [Esperanto] * fr: Frédéric Marchal [French] * pl: Jakub Bogusz [Polish] * sv: Göran Uddeborg [Swedish] # CREDITS: * Thanks for testing the release candidates and bug reports to: Corey Halpin, Stefan Eßer. -------------------------------------------------------------------------------- Happy fetches, Matthias |
|
From: Matthias A. <mat...@gm...> - 2021-08-29 15:37:42
|
Greetings, The 6.4.22 release CANDIDATE #3 of fetchmail is now available at <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. It contains security fixes for CVE-2021-39272 and fixes up several protocol violations along the way, fixes some configuration-based crashes (SIGSEGV) and updates the documentation. This version has quite extensive changes for a patchlevel release. rc2 fixes an IMAP protocol regression of rc1 that made it unable to download e-mail via IMAP in many circumstances. Reported by Corey Halpin. rc3 fixes an IMAP protocol regression that struck when a server was not the very first server in a run. Reported by Stefan Esser. Note that security recommendations in README.SSL were changed to achieve higher security from the configuration. Built-in defaults do not change. Please test this thoroughly and report your findings so we can be sure that 6.4.22 will be a good release. It has been mailed out to the translation project to solicit translation updates. The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.rc3.tar.xz/download> Detached GnuPG signatures for the respective tarballs are at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.rc3.tar.xz.asc/download> SHA256 hash values for the tarballs: SHA256(fetchmail-6.4.22.rc3.tar.xz)= 1087a1c8ef8053f2deb97c17e2ab1a91fd3dd40fe275c7d6da0693bb1218fe13 Here are the release notes: --------------------------------------------------------------------------------- fetchmail-6.4.22 (not yet released): # SECURITY FIXES: * On IMAP connections, without --ssl and with nonempty --sslproto, meaning that fetchmail is to enforce TLS, and when the server or an attacker sends a PREAUTH greeting, fetchmail used to continue an unencrypted connection. Now, log the error and abort the connection. Recommendation for servers that support SSL/TLS-wrapped or "implicit" mode on a dedicated port (default 993): use --ssl, or the ssl user option in an rcfile. Reported by: Andrew C. Aitchison, based on the USENIX Security 21 paper "Why TLS is better without STARTTLS - A Security Analysis of STARTTLS in the Email Context" by Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian Schinzel. The paper did not mention fetchmail. * On IMAP and POP3 connections, --auth ssh no longer prevents STARTTLS negotiation. * On IMAP connections, fetchmail does not permit overriding a server-side LOGINDISABLED with --auth password any more. * On POP3 connections, the possibility for RPA authentication (by probing with an AUTH command without arguments) no longer prevents STARTTLS negotiation. * For POP3 connections, only attempt RPA if the authentication type is "any". # BUG FIXES: * On IMAP connections, when AUTHENTICATE EXTERNAL fails and we have received the tagged (= final) response, do not send "*". * On IMAP connections, AUTHENTICATE EXTERNAL without username will properly send a "=" for protocol compliance. * On IMAP connections, AUTHENTICATE EXTERNAL will now check if the server advertised SASL-IR (RFC-4959) support and otherwise refuse (fetchmail <= 6.4 has not supported and does not support the separate challenge/response with command continuation) * On IMAP connections, when --auth external is requested but not advertised by the server, log a proper error message. * Fetchmail no longer crashes when attempting a connection with --plugin "" or --plugout "". * Fetchmail no longer leaks memory when processing the arguments of --plugin or --plugout on connections. * On POP3 connections, the CAPAbilities parser is now caseblind. * Fix segfault on configurations with "defaults ... no envelope". Reported by Bjørn Mork. Fixes Debian Bug#992400. This is a regression in fetchmail 6.4.3 and happened when plugging memory leaks, which did not account for that the envelope parameter is special when set as "no envelope". The segfault happens in a constant strlen(-1), triggered by trusted local input => no vulnerability. * Fix program abort (SIGABRT) with "internal error" when invalid sslproto is given with OpenSSL 1.1.0 API compatible SSL implementations. # CHANGES: * IMAP: When fetchmail is in not-authenticated state and the server volunteers CAPABILITY information, use it and do not re-probe. (After STARTTLS, fetchmail must and will re-probe explicitly.) * For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option do not match, emit a warning and continue. Closes Gitlab #31. (cherry-picked from 6.5 beta branch "legacy_6x") * fetchmail.man and README.SSL were updated in line with RFC-8314/8996/8997 recommendations to prefer Implicit TLS (--ssl/ssl) and TLS v1.2 or newer, placing --sslproto tls1.2+ more prominently. The defaults shall not change between 6.4.X releases for compatibility. # TRANSLATIONS: language translations were updated by these fine people: * sq: Besnik Bleta [Albanian] * eo: Keith Bowes [Esperanto] * fr: Frédéric Marchal [French] * pl: Jakub Bogusz [Polish] * sv: Göran Uddeborg [Swedish] # CREDITS: * Thanks for testing the release candidates and bug reports to: Corey Halpin, Stefan Esser. -------------------------------------------------------------------------------- Happy fetches, Matthias |
|
From: Matthias A. <mat...@gm...> - 2021-08-27 18:02:36
|
Greetings, The 6.4.22 release CANDIDATE #2 of fetchmail is now available at <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. It contains security fixes for CVE-2021-39272 and fixes up several protocol violations along the way, fixes some configuration-based crashes (SIGSEGV) and updates the documentation. This version has quite extensive changes for a patchlevel release. rc2 fixes an IMAP protocol regression of rc1 that made it unable to download e-mail via IMAP in many circumstances. Note that security recommendations in README.SSL were changed to achieve higher security from the configuration. Built-in defaults do not change. Please test this thoroughly and report your findings so we can be sure that 6.4.22 will be a good release. It has been mailed out to the translation project to solicit translation updates. The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.rc2.tar.xz/download> Detached GnuPG signatures for the respective tarballs are at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.rc2.tar.xz.asc/download> SHA256 hash values for the tarballs: SHA256(fetchmail-6.4.22.rc2.tar.xz)= 1bd3f25e221ea01de4ba57447b7464f8c5f07f0f107701583b9cdd85740da276 Here are the release notes: --------------------------------------------------------------------------------- fetchmail-6.4.22 (not yet released): # SECURITY FIXES: * On IMAP connections, without --ssl and with nonempty --sslproto, meaning that fetchmail is to enforce TLS, and when the server or an attacker sends a PREAUTH greeting, fetchmail used to continue an unencrypted connection. Now, log the error and abort the connection. Recommendation for servers that support SSL/TLS-wrapped or "implicit" mode on a dedicated port (default 993): use --ssl, or the ssl user option in an rcfile. Reported by: Andrew C. Aitchison, based on the USENIX Security 21 paper "Why TLS is better without STARTTLS - A Security Analysis of STARTTLS in the Email Context" by Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian Schinzel. The paper did not mention fetchmail. * On IMAP and POP3 connections, --auth ssh no longer prevents STARTTLS negotiation. * On IMAP connections, fetchmail does not permit overriding a server-side LOGINDISABLED with --auth password any more. * On POP3 connections, the possibility for RPA authentication (by probing with an AUTH command without arguments) no longer prevents STARTTLS negotiation. * For POP3 connections, only attempt RPA if the authentication type is "any". # BUG FIXES: * On IMAP connections, when AUTHENTICATE EXTERNAL fails and we have received the tagged (= final) response, do not send "*". * On IMAP connections, AUTHENTICATE EXTERNAL without username will properly send a "=" for protocol compliance. * On IMAP connections, AUTHENTICATE EXTERNAL will now check if the server advertised SASL-IR (RFC-4959) support and otherwise refuse (fetchmail <= 6.4 has not supported and does not support the separate challenge/response with command continuation) * On IMAP connections, when --auth external is requested but not advertised by the server, log a proper error message. * Fetchmail no longer crashes when attempting a connection with --plugin "" or --plugout "". * Fetchmail no longer leaks memory when processing the arguments of --plugin or --plugout on connections. * On POP3 connections, the CAPAbilities parser is now caseblind. * Fix segfault on configurations with "defaults ... no envelope". Reported by Bjørn Mork. Fixes Debian Bug#992400. This is a regression in fetchmail 6.4.3 and happened when plugging memory leaks, which did not account for that the envelope parameter is special when set as "no envelope". The segfault happens in a constant strlen(-1), triggered by trusted local input => no vulnerability. # CHANGES: * IMAP: When fetchmail is in not-authenticated state and the server volunteers CAPABILITY information, use it and do not re-probe. (After STARTTLS, fetchmail must and will re-probe explicitly.) * For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option do not match, emit a warning and continue. Closes Gitlab #31. (cherry-picked from 6.5 beta branch "legacy_6x") * fetchmail.man and README.SSL were updated in line with RFC-8314/8996/8997 recommendations to prefer Implicit TLS (--ssl/ssl) and TLS v1.2 or newer, placing --sslproto tls1.2+ more prominently. The defaults shall not change between 6.4.X releases for compatibility. # TRANSLATIONS: These language translations were updated by these fine people: * fr: Frédéric Marchal [French] * eo: Keith Bowes [Esperanto] -------------------------------------------------------------------------------- Happy fetches, Matthias |
|
From: Matthias A. <mat...@gm...> - 2021-08-27 16:33:42
|
Greetings, I am withdrawing 6.4.22.rc1 and ask that nobody installs it anew if IMAP fetches are desired. Setups that purely use POP3 seem fine for now, and if your setup can fetch mail from all your configurations, you need not downgrade. Sorry about this, but that is why there are release candidates, some turn out to be unworthy of promotion to a release. I am moving 6.4.22.rc1 around on sourceforge from branch_6.4/ to OldFiles/ so that people missing this announcement don't find it at the place announced earlier. Withdrawal reason: I received and confirmed a regression report against fetchmail's IMAP client, and 6.4.22.rc1 misidentifies IMAP protocol versions and in many situations tries IMAP4 commands on IMAP2 and IMAP4rev1 servers, which leads to poll errors without any mail downloaded. This is a side effect from the "reset session data", not covered in my testing scenarios. -ma |
|
From: Matthias A. <mat...@gm...> - 2021-08-26 22:32:00
|
fetchmail-SA-2021-02: STARTTLS session encryption bypassing Topics: fetchmail fails to enforce an encrypted connection Author: Matthias Andree Version: 0.9 Announced: 2021-08-26 Type: failure to enforce configured security policy Impact: fetchmail continues an unencrypted connection, thus reading unauthenticated input and sending information unencrypted over its transport Danger: medium Acknowledgment: Andrew C. Aitchison for reporting this against fetchmail Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian Schinzel for their Usenix Security 21 paper NO STARTTLS CVE Name: CVE-2021-39272 URL: https://www.fetchmail.info/fetchmail-SA-2021-02.txt Project URL: https://www.fetchmail.info/ Affects: - fetchmail releases up to and including 6.4.21 Not affected: - fetchmail releases 6.4.22 and newer Corrected in: 2021-08-26 fetchmail 6.4.22.rc1 release candidate TBD fetchmail 6.4.22 release tarball 0. History of this announcement =============================== 2021-08-10 Andrew C. Aitchison contacts fetchmail maintainer with pointer to Usenix Security 21 paper by Damian Poddebniak et al. 2021-08-16 a simplified recommendation to configure --ssl where possible (see section 3b. below) to mitigate impact was sent to the fetchmail mailing lists 2021-08-26 0.9 initial release along with fetchmail 6.4.22.rc1 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 supports SSL and TLS security layers through the OpenSSL library, if enabled at compile time and if also enabled at run time, in both SSL/TLS-wrapped mode on dedicated ports as well as in-band-negotiated "STARTTLS" and "STLS" modes through the regular protocol ports. 2. Problem description and Impact ================================= fetchmail permits requiring that an IMAP or POP3 protocol exchange uses a TLS-encrypted transport, in 6.4 by way of an --sslproto auto or similar configuration. This TLS encryption can be established either as Implicit TLS connection, which negotiates TLS first, or as a STARTTLS which starts as cleartext protocol exchange that gets upgraded in the same TCP stream to TLS. Without special configuration, fetchmail would opportunistically try to upgrade cleartext connections to TLS by STARTTLS, but allow cleartext protocol exchange, which is documented. IMAP also supports sessions that start in "authenticated state" (PREAUTH). In this latter case, IMAP (RFC-3501) does not permit sending STARTTLS negotiations, which are only permissible in not-authenticated state. In such a combination of circumstances (1. IMAP protocol in use, 2. the server greets with PREAUTH, announcing authenticated state, 3. the user configured TLS mandatory, 4. the user did not configure "ssl" mode that uses separate ports for Implicit SSL/TLS), fetchmail 6.4.21 and older would not encrypt the session. There was a similar situation for POP3: if the remote name contained @compuserve.com, and if the server supported a non-standard "AUTH" command without mechanism argument and if it responded with a list that contained "RPA" (also in mixed or lower case), then fetchmail would not attempt STARTTLS. While the password itself is then protected by the RPA scheme (which employs MD5 however), fetchmail 6.4.21 and older would not encrypt the session. Also, a configuration containing --auth ssh (meaning that fetchmail should not authenticate, on the assumption that the session will be pre-authenticated for instance through SSH running a mail server with --plugin, or TLS client certificates), would also defeat STARTTLS as result of an implementation defect. This affected both POP3 and IMAP. 3. Solutions ============ PREFACE: distributors backporting fixes to old versions are asked to diff the manual page and review the changes, and the NEWS file, because the manual page has been updated with newer recommendations. The same backport recommendations hold for the README.SSL file. 3a. Install fetchmail 6.4.22 or newer. The fetchmail source code is available from <https://sourceforge.net/projects/fetchmail/files/>. The Git-based source code repository is currently published via https://gitlab.com/fetchmail/fetchmail/-/tree/legacy_64 (primary) https://sourceforge.net/p/fetchmail/git/ci/legacy_64/tree/ (copy) 3b. Where the IMAP or POP3 server supports this form of access, fetchmail can be configured to use Implicit TLS, called "ssl" mode, meaning it will connect to a dedicated port (default: 993 for IMAP, 995 for POP3) and negotiate TLS without prior clear-text protocol exchange. Also, --ssl can be given on the command line, which switches all configured server statements to this Implicit TLS mode. A. Copyright, License and Non-Warranty ====================================== (C) Copyright 2021 by Matthias Andree, <mat...@gm...>. Some rights reserved. © Copyright 2021 by Matthias Andree. 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-2021-02 |
|
From: Matthias A. <mat...@gm...> - 2021-08-26 22:29:55
|
Greetings, The 6.4.22 release CANDIDATE of fetchmail is now available at <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. It contains security fixes for CVE-2021-39272 and fixes up several protocol violations along the way, fixes some configuration-based crashes (SIGSEGV) and updates the documentation. This version has quite extensive changes for a patchlevel release. Note that security recommendations in README.SSL were changed to achieve higher security from the configuration. Built-in defaults do not change. Please test this thoroughly and report your findings so we can be sure that 6.4.22 will be a good release. It has been mailed out to the translation project to solicit translation updates. The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.rc1.tar.xz/download> Detached GnuPG signatures for the respective tarballs are at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.rc1.tar.xz.asc/download> SHA256 hash values for the tarballs: SHA256(fetchmail-6.4.22.rc1.tar.xz)= 96634167a0c21673abaa8c76e669fb5799266c19f784c03a760c2048681cd3b3 Here are the release notes: --------------------------------------------------------------------------------- fetchmail-6.4.22 (not yet released): # SECURITY FIXES: * On IMAP connections, without --ssl and with nonempty --sslproto, meaning that fetchmail is to enforce TLS, and when the server or an attacker sends a PREAUTH greeting, fetchmail used to continue an unencrypted connection. Now, log the error and abort the connection. Recommendation for servers that support SSL/TLS-wrapped or "implicit" mode on a dedicated port (default 993): use --ssl, or the ssl user option in an rcfile. Reported by: Andrew C. Aitchison, based on the USENIX Security 21 paper "Why TLS is better without STARTTLS - A Security Analysis of STARTTLS in the Email Context" by Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian Schinzel. The paper did not mention fetchmail. * On IMAP and POP3 connections, --auth ssh no longer prevents STARTTLS negotiation. * On IMAP connections, fetchmail does not permit overriding a server-side LOGINDISABLED with --auth password any more. * On POP3 connections, the possibility for RPA authentication (by probing with an AUTH command without arguments) no longer prevents STARTTLS negotiation. * For POP3 connections, only attempt RPA if the authentication type is "any". # BUG FIXES: * On IMAP connections, when AUTHENTICATE EXTERNAL fails and we have received the tagged (= final) response, do not send "*". * On IMAP connections, AUTHENTICATE EXTERNAL without username will properly send a "=" for protocol compliance. * On IMAP connections, AUTHENTICATE EXTERNAL will now check if the server advertised SASL-IR (RFC-4959) support and otherwise refuse (fetchmail <= 6.4 has not supported and does not support the separate challenge/response with command continuation) * On IMAP connections, When --auth external is requested but not advertised by the server, log a proper error message. * Fetchmail no longer crashes when attempting a connection with --plugin "" or --plugout "". * Fetchmail no longer leaks memory when processing the arguments of --plugin or --plugout on connections. * On POP3 connections, the CAPAbilities parser is now caseblind. * Fix segfault on configurations with "defaults ... no envelope". Reported by Bjørn Mork. Fixes Debian Bug#992400. This is a regression in fetchmail 6.4.3 and happened when plugging memory leaks, which did not account for that the envelope parameter is special when set as "no envelope". The segfault happens in a constant strlen(-1), triggered by trusted local input => no vulnerability. # CHANGES: * IMAP: When fetchmail is in not-authenticated state and the server volunteers CAPABILITY information, use it and do not re-probe. (After STARTTLS, fetchmail must and will re-probe explicitly.) * For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option do not match, emit a warning and continue. Closes Gitlab #31. (cherry-picked from 6.5 beta branch "legacy_6x") * fetchmail.man and README.SSL were updated in line with RFC-8314/8996/8997 recommendations to prefer Implicit TLS (--ssl/ssl) and TLS v1.2 or newer, placing --sslproto tls1.2+ more prominently. The defaults shall not change between 6.4.X releases for compatibility. --------------------------------------------------------------------------------- Happy fetches, Matthias |
|
From: Joe Acquisto-j. <jo...@j4...> - 2021-08-16 17:06:26
|
> Am 16.08.21 um 01:45 schrieb Joe Acquisto-j4: >> >>>> Version 6.4.2-rc3+SSL-SSLv2-SSLv3+NLS >>>> >>>> Recent ping about SSL issue cause me to look at config and logs. Surprise. >>>> Been going on for months. My bad for not noticing earlier. >>>> >>>> from /var/log/fetchmail.log >>>> >>>> fetchmail: Loaded OpenSSL library 0x1010104f newer than headers 0x1010009f, >>>> trying to continue. >>>> fetchmail: OpenSSL reported: error:1408F10B:SSL >>>> routines:ssl3_get_record:wrong version number >>>> >>>> I'll search a bit while awaiting the lifeguards . . . >>>> >>> Updating to absolute latest on sourceforge resolved the issue. >>> >>> Pardon the noise. >>> >> Actually . . . I lied. Secure connections do appear to work, if I leave > config options at default, >> but when I add "ssl" to my config file the particular user I add that for > shows this error on attempted fetch: >> >> "fetchmail: OpenSSL reported: error:1408F10B:SSL > routines:ssl3_get_record:wrong version number" >> >> Sorry if this is an added burden, or, horrors, if I misread earlier emails > on the subject. > > Joe, > > this is a typical situation when OpenSSL tries to negotiate SSL on a > port that talks plaintext. > > If you configured the port explicitly, then you need to change it, too, > to the SSL-wrapped version (POP3 --ssl will use 995, IMAP --ssl will use > 993) or just remove the --port or --service parameter and go with the > defaults (if your ISP serves on the usual port, that will be sufficient). > - else see https://www.fetchmail.info/fetchmail-FAQ.html#G3 for what > information we need to help you. > > Also, your fetchmail was compiled with OpenSSL 1.1.0i headers and uses a > run-time library 1.1.1d. This is a strange situation. If you built > fetchmail yourself, make sure your system is fully updated and then > clean and rebuild fetchmail. > > Regards, > Matthias > Thank you. Removing the port parameter eliminated the error. Sorry for the bother. I will look into the OpenSSL mismatch you noticed. joe a. |
|
From: Matthias A. <mat...@gm...> - 2021-08-16 16:54:54
|
Am 15.08.21 um 22:08 schrieb Peter Pentchev: > On Sun, Aug 15, 2021 at 11:58:34AM -0700, Peter Scott via Fetchmail-users wrote: >> Dear Matthias, >> >> Fedora 34 just upgraded fetchmail for us. >> >> Now fetchmail --version shows >> >> This is fetchmail release 6.4.20+GSS+RPA+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. >> Compiled with SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" >> Run-time uses SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" >> OpenSSL: OPENSSLDIR: "/etc/pki/tls" >> Engines: ENGINESDIR: "/usr/lib64/engines-1.1" >> >> Since this upgrade my fetchmail logfile is showing the >> "run-together-lines" behavior, lacking the usual newline chars. > I think this bug was fixed in 6.4.21, was it not? So when the Fedora > maintainer updates fetchmail to 6.4.21, you will get the fix. Peter, correct, the --syslog and --logfile I broke in 6.4.20 were fixed in 6.4.21. The Fedora package maintainer wrote me this morning that he updated things earlier today, but the builds will take a few days to propagate. My addition is that the daring may check <https://koji.fedoraproject.org/koji/packageinfo?packageID=1046> and grab their RPM individually and test, but I am not affiliated with Fedora and cannot help or support this - but feel free to share your findings on Fedora's Bodhi if it works for you (it did not for me), or here, if you try. Regards, Matthias |
|
From: Matthias A. <mat...@gm...> - 2021-08-16 16:46:21
|
Am 16.08.21 um 01:45 schrieb Joe Acquisto-j4: > >>> Version 6.4.2-rc3+SSL-SSLv2-SSLv3+NLS >>> >>> Recent ping about SSL issue cause me to look at config and logs. Surprise. >>> Been going on for months. My bad for not noticing earlier. >>> >>> from /var/log/fetchmail.log >>> >>> fetchmail: Loaded OpenSSL library 0x1010104f newer than headers 0x1010009f, >>> trying to continue. >>> fetchmail: OpenSSL reported: error:1408F10B:SSL >>> routines:ssl3_get_record:wrong version number >>> >>> I'll search a bit while awaiting the lifeguards . . . >>> >> Updating to absolute latest on sourceforge resolved the issue. >> >> Pardon the noise. >> > Actually . . . I lied. Secure connections do appear to work, if I leave config options at default, > but when I add "ssl" to my config file the particular user I add that for shows this error on attempted fetch: > > "fetchmail: OpenSSL reported: error:1408F10B:SSL routines:ssl3_get_record:wrong version number" > > Sorry if this is an added burden, or, horrors, if I misread earlier emails on the subject. Joe, this is a typical situation when OpenSSL tries to negotiate SSL on a port that talks plaintext. If you configured the port explicitly, then you need to change it, too, to the SSL-wrapped version (POP3 --ssl will use 995, IMAP --ssl will use 993) or just remove the --port or --service parameter and go with the defaults (if your ISP serves on the usual port, that will be sufficient). - else see https://www.fetchmail.info/fetchmail-FAQ.html#G3 for what information we need to help you. Also, your fetchmail was compiled with OpenSSL 1.1.0i headers and uses a run-time library 1.1.1d. This is a strange situation. If you built fetchmail yourself, make sure your system is fully updated and then clean and rebuild fetchmail. Regards, Matthias |
|
From: Joe Acquisto-j. <jo...@j4...> - 2021-08-15 23:46:11
|
>> Version 6.4.2-rc3+SSL-SSLv2-SSLv3+NLS >> >> Recent ping about SSL issue cause me to look at config and logs. Surprise. > >> Been going on for months. My bad for not noticing earlier. >> >> from /var/log/fetchmail.log >> >> fetchmail: Loaded OpenSSL library 0x1010104f newer than headers 0x1010009f, >> trying to continue. >> fetchmail: OpenSSL reported: error:1408F10B:SSL >> routines:ssl3_get_record:wrong version number >> >> I'll search a bit while awaiting the lifeguards . . . >> > > Updating to absolute latest on sourceforge resolved the issue. > > Pardon the noise. > Actually . . . I lied. Secure connections do appear to work, if I leave config options at default, but when I add "ssl" to my config file the particular user I add that for shows this error on attempted fetch: "fetchmail: OpenSSL reported: error:1408F10B:SSL routines:ssl3_get_record:wrong version number" Sorry if this is an added burden, or, horrors, if I misread earlier emails on the subject. |
|
From: Joe Acquisto-j. <jo...@j4...> - 2021-08-15 22:27:14
|
> Version 6.4.2-rc3+SSL-SSLv2-SSLv3+NLS > > Recent ping about SSL issue cause me to look at config and logs. Surprise. > Been going on for months. My bad for not noticing earlier. > > from /var/log/fetchmail.log > > fetchmail: Loaded OpenSSL library 0x1010104f newer than headers 0x1010009f, > trying to continue. > fetchmail: OpenSSL reported: error:1408F10B:SSL > routines:ssl3_get_record:wrong version number > > I'll search a bit while awaiting the lifeguards . . . > Updating to absolute latest on sourceforge resolved the issue. Pardon the noise. |
|
From: Matthias A. <mat...@gm...> - 2021-08-15 22:14:09
|
Am 15.08.21 um 20:58 schrieb Peter Scott via Fetchmail-users: > Dear Matthias, > > Fedora 34 just upgraded fetchmail for us. > > Now fetchmail --version shows > > This is fetchmail release 6.4.20+GSS+RPA+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. > Compiled with SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" > Run-time uses SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" > OpenSSL: OPENSSLDIR: "/etc/pki/tls" > Engines: ENGINESDIR: "/usr/lib64/engines-1.1" > > Since this upgrade my fetchmail logfile is showing the > "run-together-lines" behavior, lacking the usual newline chars. > > This is not a big deal of course, but if there's a way to fix it, > let me know. Dear Peter, yes they did, same for Fedora 33. Unfortunately, the --logfile option and also --syslog are broken in 6.4.20, truncating log messages. While syslog does not run the lines together, it still misses log message pieces. The workaround for 6.4.20 would be to disable or remove the logfile option, add -N for "nodetach" (meaning fetchmail will stick to the console, and nodetach has a side effect of making log output unbuffered, sidestepping the issue if and only if the output goes to console directly) and then redirect its output to the log file, for instance with: fetchmail --nodetach >>mylogfile.txt (add your other options, if any) or, if you want a copy of the log printed to console: fetchmail --nodetach (your other options here) | tee -a mylogfile.txt > It looks as if you're struggling a bit, so I wish you the best of > luck. I really appreciate your depth of knowledge and years and > years of dealing with this stuff. fetchmail is so useful. Oh, I am not struggling, but thanks for your wishes - it's just a somewhat unlucky timing. First the security issue, then the logging bug in fixing it and then I receive word of the STARTTLS issue... I figured this requires lots of code review, and some rewriting, and some more review. Ideally, all this would have been part of one perfect release, but alas that's not how things worked out. Kind regards, Matthias |
|
From: Peter P. <ro...@ri...> - 2021-08-15 20:25:08
|
On Sun, Aug 15, 2021 at 11:58:34AM -0700, Peter Scott via Fetchmail-users wrote: > Dear Matthias, > > Fedora 34 just upgraded fetchmail for us. > > Now fetchmail --version shows > > This is fetchmail release 6.4.20+GSS+RPA+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. > Compiled with SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" > Run-time uses SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" > OpenSSL: OPENSSLDIR: "/etc/pki/tls" > Engines: ENGINESDIR: "/usr/lib64/engines-1.1" > > Since this upgrade my fetchmail logfile is showing the > "run-together-lines" behavior, lacking the usual newline chars. I think this bug was fixed in 6.4.21, was it not? So when the Fedora maintainer updates fetchmail to 6.4.21, you will get the fix. G'luck, Peter -- Peter Pentchev ro...@ri... ro...@de... pp...@st... PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 |
|
From: Peter S. <dr...@uc...> - 2021-08-15 19:23:29
|
Dear Matthias,
Fedora 34 just upgraded fetchmail for us.
Now fetchmail --version shows
This is fetchmail release 6.4.20+GSS+RPA+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5.
Compiled with SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021"
Run-time uses SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021"
OpenSSL: OPENSSLDIR: "/etc/pki/tls"
Engines: ENGINESDIR: "/usr/lib64/engines-1.1"
Since this upgrade my fetchmail logfile is showing the
"run-together-lines" behavior, lacking the usual newline chars.
This is not a big deal of course, but if there's a way to fix it,
let me know.
It looks as if you're struggling a bit, so I wish you the best of
luck. I really appreciate your depth of knowledge and years and
years of dealing with this stuff. fetchmail is so useful.
-- Peter
=================================================================
On Aug 15, 2021 at 4:40 pm, Matthias Andree <mat...@gm...> wrote:
| Greetings,
|
| all released fetchmail versions to date (up to and including 6.4.21)
| were found susceptible to some sorts of attacks against STARTTLS (IMAP)
| or STLS (POP3), which can lead to a session that remains unencrypted
| even though --sslproto tls1.2+ or similar configurations require
| encryption, and worst case exposing the user's login credentials and
| also e-mail when the configuration tells otherwise.
|
| The solution in fetchmail code requires thorough reviews and
| changes that will take more time. Remember that fetchmail is
| a volunteer spare-time project.
|
| The details of the implementation and concept flaws shall be disclosed
| later in the formal fetchmail security announcement 2021-02 (not yet
| published).
|
| MITIGATING THE IMPACT:
|
| Proper configuration for Implicit TLS can mitigate the impact for many
| users. I am already announcing such configuration changes below:
|
| ------------------------------------------------------------------------
| Everyone whose server supports "Implicit TLS", meaning TLS on
| a dedicated imaps port (TCP port 993) or pop3s port (TCP port 995),
| should reconfigure fetchmail to enable this option (ssl or --ssl)
| permanently.
| This can be achieved in two ways, either of which alone is sufficient:
|
| - on the command line, add --ssl), which will affect all servers
| included in the poll (= all poll statements from the rcfile, or all
| servers mentioned on the same command line).
|
| - in the rcfile, by adding the word "ssl" without quotes after each
| configuration stanza for a user description.
|
| After making the change, test your new configuration before enabling
| unattended operation.
|
|
| Future directions: 1. The Internet Engineering Task Force (IETF) has
| proposed standards that consider both STARTTLS obsolete (RFC-8314) and
| deprecate TLS 1.1 and earlier (including all SSL versions) (RFC-8997).
|
| 2. I may make Implicit TLS the default in future fetchmail releases,
| and promise to at least bump the minor version to >= 6.5.0 in that case.
| ------------------------------------------------------------------------
|
| I will also add an *unrelated* recommendation while we are at it and
| users are suggested to edit their configurations anyways:
|
| I suggest that everyone configures fetchmail to negotiate at least TLS
| v1.2 if supported by the server, or at least TLS v1.2, which can happen
| on the command line through --sslproto TLS1.2+ or in the rcfile by
| adding sslproto TLS1.2+ in each stanza after each user statement.
|
| Where possible, meaning server-side support and support by the local
| OpenSSL library version (for instance, 1.1.1 is good enough), fetchmail
| can also be configured to require TLS v1.3 or newer instead, in that
| case, use --sslproto TLS1.3+ on the command line or sslproto TLS1.3+ in
| the rcfile.
|
|
| future direction: fetchmail 6.5 and newer (not yet released and several
| weeks to months out) will make TLS 1.2 the minimum required version, and
| will also require an OpenSSL library that supports TLS 1.3.
| ------------------------------------------------------------------------
|
|
| Note that the changes proposed above, when successfully deployed, can
| remain in place when fetchmail 6.4.22 will be released, so there is no
| need to wait.
| _______________________________________________
| Fetchmail-users mailing list
| Fet...@li...
| https://lists.sourceforge.net/lists/listinfo/fetchmail-users
|
|
From: Joe Acquisto-j. <jo...@j4...> - 2021-08-15 17:28:08
|
Version 6.4.2-rc3+SSL-SSLv2-SSLv3+NLS Recent ping about SSL issue cause me to look at config and logs. Surprise. Been going on for months. My bad for not noticing earlier. from /var/log/fetchmail.log fetchmail: Loaded OpenSSL library 0x1010104f newer than headers 0x1010009f, trying to continue. fetchmail: OpenSSL reported: error:1408F10B:SSL routines:ssl3_get_record:wrong version number I'll search a bit while awaiting the lifeguards . . . |
|
From: Matthias A. <mat...@gm...> - 2021-08-15 14:41:02
|
Greetings, all released fetchmail versions to date (up to and including 6.4.21) were found susceptible to some sorts of attacks against STARTTLS (IMAP) or STLS (POP3), which can lead to a session that remains unencrypted even though --sslproto tls1.2+ or similar configurations require encryption, and worst case exposing the user's login credentials and also e-mail when the configuration tells otherwise. The solution in fetchmail code requires thorough reviews and changes that will take more time. Remember that fetchmail is a volunteer spare-time project. The details of the implementation and concept flaws shall be disclosed later in the formal fetchmail security announcement 2021-02 (not yet published). MITIGATING THE IMPACT: Proper configuration for Implicit TLS can mitigate the impact for many users. I am already announcing such configuration changes below: ------------------------------------------------------------------------ Everyone whose server supports "Implicit TLS", meaning TLS on a dedicated imaps port (TCP port 993) or pop3s port (TCP port 995), should reconfigure fetchmail to enable this option (ssl or --ssl) permanently. This can be achieved in two ways, either of which alone is sufficient: - on the command line, add --ssl), which will affect all servers included in the poll (= all poll statements from the rcfile, or all servers mentioned on the same command line). - in the rcfile, by adding the word "ssl" without quotes after each configuration stanza for a user description. After making the change, test your new configuration before enabling unattended operation. Future directions: 1. The Internet Engineering Task Force (IETF) has proposed standards that consider both STARTTLS obsolete (RFC-8314) and deprecate TLS 1.1 and earlier (including all SSL versions) (RFC-8997). 2. I may make Implicit TLS the default in future fetchmail releases, and promise to at least bump the minor version to >= 6.5.0 in that case. ------------------------------------------------------------------------ I will also add an *unrelated* recommendation while we are at it and users are suggested to edit their configurations anyways: I suggest that everyone configures fetchmail to negotiate at least TLS v1.2 if supported by the server, or at least TLS v1.2, which can happen on the command line through --sslproto TLS1.2+ or in the rcfile by adding sslproto TLS1.2+ in each stanza after each user statement. Where possible, meaning server-side support and support by the local OpenSSL library version (for instance, 1.1.1 is good enough), fetchmail can also be configured to require TLS v1.3 or newer instead, in that case, use --sslproto TLS1.3+ on the command line or sslproto TLS1.3+ in the rcfile. future direction: fetchmail 6.5 and newer (not yet released and several weeks to months out) will make TLS 1.2 the minimum required version, and will also require an OpenSSL library that supports TLS 1.3. ------------------------------------------------------------------------ Note that the changes proposed above, when successfully deployed, can remain in place when fetchmail 6.4.22 will be released, so there is no need to wait. |
|
From: Matthias A. <mat...@gm...> - 2021-08-09 18:25:23
|
Am 09.08.21 um 17:48 schrieb Matthias Andree:
> Am 08.08.21 um 21:54 schrieb Matthias Andree:
>> Am 08.08.21 um 20:07 schrieb J.Edner:
>>> Hi,
>>> I've just compiled and installed Fetchmail 6.4.20 on my server and found
>>> out, that some log lines are missing a new-line at the end, so that they
>>> are concatenated as follows:
>>>
>>> fetchmail: 16 messages for XYZ at SERVERfetchmail: reading message
>>> XYZ@SERVER:1 of 16fetchmail: reading message XYZ@SERVER:2 of
>>> 16fetchmail: reading message XYZ@SERVER:3 of 16fetchmail: reading
>>> message ...
>>>
>>> I checked the source code and saw that a new-line seems to be missing.
>>> After I've applied this small patch all messages are correctly written
>>> to the log file again:
>>>
>>> ----------
>>> --- a/driver.c. 2021-08-08 17:06:53.756148421 +0200
>>> +++ b/driver.c 2021-08-08 17:09:20.231666827 +0200
>>> @@ -629,7 +629,7 @@ static int fetch_messages(int mailserver
>>>
>>> if (outlevel > O_SILENT)
>>> {
>>> - report_build(stdout, GT_("reading message %s@%s:%d of %d"),
>>> + report_build(stdout, GT_("reading message %s@%s:%d of %d\n"),
>>> ctl->remotename, ctl->server.truename,
>>> num, count);
>>> ----------
>>>
>>> The result looks as follows now again:
>>>
>>> fetchmail: 16 messages for XYZ at SERVER
>>> fetchmail: reading message XYZ@SERVER:1 of 16
>>> fetchmail: reading message XYZ@SERVER:2 of 16
>>> fetchmail: reading message XYZ@SERVER:3 of 16
>>> ...
> Got it.
And as an example to illustrate what 6.4.20 misses from its --logfiles:
the log messages should have looked somewhat similar to (POP3 does not
distinguish header/body sizes and just logs (12345 octets)):
fetchmail: 2 messages for mandree at courier (folder INBOX.fmtest).
fetchmail: reading message mandree@localhost:1 of 2 (4982 header octets)
(32 body octets) not flushed
fetchmail: reading message mandree@localhost:2 of 2 (4263 header octets)
(41 body octets) not flushed
so the NNN octets stuff, and what ultimately happened to the messages
("not flushed") is missing, and your patch isn't bringing this
information back.
(I was using "--keep", so "not flushed" was in order).
|
|
From: Matthias A. <mat...@gm...> - 2021-08-09 17:04:11
|
Greetings, The 6.5.0.beta5 release of fetchmail is now available at the usual locations, including <https://sourceforge.net/projects/fetchmail/files/branch_6.5/> The source archive has been uploaded and will shortly be available from: <https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta5.tar.xz/download> This is a deep link to the GnuPG signature: <https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta5.tar.xz.asc/download> This fixes a regression introduced with the security fix for CVE-2021-36386 that broke --logfile and generally could cause log message truncation, and merges Eric Durand's --idletimeout configuration feature. This is the change history from Git: ================================================================================ * 0664b370 2021-08-09 | Merge branch 'legacy_64' into legacy_6x, bumping... |\ | * 06aee72e 2021-08-09 | Bump version to 6.4.21. (tag: RELEASE_6-4-21) | * 65d9dde0 2021-08-09 | Update fetchmail-SA-2021-01.txt with info on regression fix. v1.3. | * 54c3e4a1 2021-08-09 | NEWS/6.4.20: Fix typo in CVE number. | * d3db2da1 2021-08-09 | Fix --logfile and message truncation issue. | * f6ebe48b 2021-08-03 | fetchmail-SA-2021-01.txt: Replace copy by symlink | * a8f8447d 2021-08-03 | update fetchmail-SA-2021-01 | * fa027fe6 2021-08-03 | website: ext. link updates for openssh, getmail6 | * 13d816ba 2021-08-03 | Update website for 6.5.0.beta4 release. * db1cff0d 2021-08-05 | Merge branch 'rand0mdud3/fetchmail-legacy_6x_idle_timeout' into legacy_6x |\ | * 3d71de2f 2021-08-05 | Complete integration of --idletimeout feature. | * 0dc17130 2021-07-22 | Make the idle timeout configurable [Eric Durand] |/ * adcd49a1 2021-08-05 | fetchmailconf: fixup merge indentation error from ed4903efad * 77a1e3fc 2021-08-04 | fetchmail.man: Minor tweaks to sslproto doc. * 38f73ff5 2021-08-04 | fetchmail.man: update sslproto to reflect defaults * b3dd1527 2021-08-04 | socket.c: try harder not to redefine TLS_MAX_VERSION * b3eb6a48 2021-08-04 | driver.c: Fix misreporting SMTP errors as MDA. * 8e435aff 2021-08-04 | get_sink_type: return gettextized string of sink type. * 6124abb3 2021-08-04 | socket.c: refactor SSL shutdown/context getter code ================================================================================ |
|
From: Matthias A. <mat...@gm...> - 2021-08-09 16:51:07
|
TL;DR Summary: While fetchmail 6.4.20 fixed CVE-2021-36386, it introduced a bug WRT buffered logging that got fixed in 6.4.21. Packagers should either upgrade all the way to 6.4.21, or pick the near-trivial regression fix from section #3 below or Git commit d3db2da1 can be cherry-picked from the GitLab or SourceForge repos. Updated security announcement follows: -------------------------------------------------------------------- fetchmail-SA-2021-01: DoS or information disclosure logging long messages Topics: fetchmail denial of service or information disclosure when logging long messages Author: Matthias Andree Version: 1.3 Announced: 2021-07-28 (original), 2021-08-09 (last update) Type: missing variable initialization can cause read from bad memory locations Impact: fetchmail logs random information, or segfaults and aborts, stalling inbound mail Danger: low Acknowledgment: Christian Herdtweck, Intra2net AG, Tübingen, Germany for analysis and report and a patch suggestion CVE Name: CVE-2021-36386 and CVE-2008-2711 URL: https://www.fetchmail.info/fetchmail-SA-2021-01.txt URL: https://www.fetchmail.info/fetchmail-SA-2008-01.txt Project URL: https://www.fetchmail.info/ Affects: - fetchmail releases up to and including 6.3.8 - fetchmail releases 6.3.17 up to incl. 6.4.19 (but note 6.4.20 regresses for buffered output, f.i. with --logfile) Not affected: - fetchmail releases 6.4.21 and newer (fetchmail 6.4.20 fixes the immediate bug but regresses and causes message truncation on buffered output) - fetchmail releases 6.3.9 to 6.3.16 Corrected in: c546c829 + d3db2da1 Git commit hash (both needed) 2021-08-09 fetchmail 6.4.21 release tarball 0. Release history ================== 2021-07-07 initial report to maintainer 2021-07-28 1.0 release 2021-07-28 1.1 update Git commit hash with correction 2021-08-03 1.2 add references to CVE-2008-2711/fetchmail-SA-2008-01 2021-08-09 1.3 mention buffered logging regression (--logfile) 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 supports SSL and TLS security layers through the OpenSSL library, if enabled at compile time and if also enabled at run time, in both SSL/TLS-wrapped mode on dedicated ports as well as in-band-negotiated "STARTTLS" and "STLS" modes through the regular protocol ports. 2. Problem description and Impact ================================= Fetchmail has long had support to assemble log/error messages that are generated piecemeal, and takes care to reallocate the output buffer as needed. In the reallocation case, i. e. when long log messages are assembled that can stem from very long headers, and on systems that have a varargs.h/stdarg.h interface (all modern systems), fetchmail's code would fail to reinitialize the va_list argument to vsnprintf. The exact effects depend on the verbose mode (how many -v are given) of fetchmail, computer architecture, compiler, operating system and configuration. On some systems, the code just works without ill effects, some systems log a garbage message (potentially disclosing sensitive information), some systems log literally "(null)", some systems trigger SIGSEGV (signal #11), which crashes fetchmail, causing a denial of service on fetchmail's end. The same bug then named CVE-2008-2711 had already been fixed in fetchmail 6.3.9, but a code refactoring in fetchmail 6.3.17 (commit 414a3809 in 2010) reintroduced the bug. Fetchmail versions 6.4.19 and older are no longer supported, however. The bugfix used in 6.4.20 uses a different, more thorough, approach. 3. Solution =========== Install fetchmail 6.4.21 or newer. The fetchmail source code is available from <https://sourceforge.net/projects/fetchmail/files/>. Distributors are encouraged to review the NEWS file and move forward to 6.4.21, rather than backport individual security fixes, because doing so routinely misses other fixes crucial to fetchmail's proper operation, for which no security announcements are issued, or documentation, or translation updates. The regression fix for the new non-security bug in 6.4.20 that causes log message truncation simply consists of editing report.c to rotate lines 289 through 291, such that the /corrected/ report.c then looks like this: 286 n = snprintf (partial_message + partial_message_size_used, 287 partial_message_size - partial_message_size_used, 288 message, a1, a2, a3, a4, a5, a6, a7, a8); 289 290 if (n > 0) partial_message_size_used += n; 291 #endif 292 293 if (unbuffered && partial_message_size_used != 0) Fetchmail 6.4.X releases have been made with a focus on unchanged user and program interfaces so as to avoid disruptions when upgrading from 6.3.Z or 6.4.X to 6.4.Y with Y > X. Care was taken to not change the interface incompatibly. A. Copyright, License and Non-Warranty ====================================== (C) Copyright 2021 by Matthias Andree, <mat...@gm...>. Some rights reserved. fetchmail-SA-2021-01 © 2021 by Matthias Andree 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-2021-01 |
|
From: Matthias A. <mat...@gm...> - 2021-08-09 16:47:20
|
Greetings, The 6.4.21 release of fetchmail is now available at the usual locations, including <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. It contains the security fix for CVE-2021-36386 of 6.4.20, and fixes a regression/a bug that causes log message truncation/run-together prominently visible with --logfile that was introduced into 6.4.20. The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.21.tar.xz/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.21.tar.lz/download> Detached GnuPG signatures for the respective tarballs are at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.21.tar.xz.asc/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.21.tar.lz.asc/download> SHA256 hash values for the tarballs: SHA256(fetchmail-6.4.21.tar.lz)= 3abbe5f7bb003bdf3b8b71a2edd896fba55cbd3d19d59fe2ff8925fca4983af7 SHA256(fetchmail-6.4.21.tar.xz)= 6a459c1cafd7a1daa5cd137140da60c18c84b5699cd8e7249a79c33342c99d1d Here are the release notes: --------------------------------------------------------------------------------- fetchmail-6.4.21 (released 2021-08-09, 30042 LoC): # REGRESSION FIX: * The new security fix in 6.4.20 for CVE-2021-36386 caused truncation of messages logged to buffered outputs, predominantly --logfile. This also caused lines in the logfile to run into one another because the fragment containing the '\n' line-end character was usually lost. Reason is that on all modern systems (with <stdarg.h> header and vsnprintf() interface), the length of log message fragments was added up twice, so that these ended too deep into a freshly allocated buffer, after the '\0' byte. Unbuffered outputs flushed the fragments right away, which masked the bug. Reported by: Jürgen Edner, Erik Christiansen. -------------------------------------------------------------------------------- fetchmail-6.4.20 (released 2021-07-28, 30042 LoC): # SECURITY FIX: * When a log message exceeds c. 2 kByte in size, for instance, with very long header contents, and depending on verbosity option, fetchmail can crash or misreport each first log message that requires a buffer reallocation. fetchmail then reallocates memory and re-runs vsnprintf() without another call to va_start(), so it reads garbage. The exact impact depends on many factors around the compiler and operating system configurations used and the implementation details of the stdarg.h interfaces of the two functions mentioned before. To fix CVE-2021-38386. Reported by Christian Herdtweck of Intra2net AG, Tübingen, Germany. --------------------------------------------------------------------------------- Happy fetches, Matthias |
18 messages has been excluded from this view by a project administrator.
