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
(1) |
Nov
|
Dec
|
|
From: Matthias A. <mat...@gm...> - 2019-10-19 19:35:36
|
Am 19.10.19 um 18:00 schrieb richardkimber--- via Fetchmail-users: > I have just upgraded from Ubuntu 19.04 to 19.10 and I find that > fetchmail is unable to retrieve emails from the POP3 server. The log > suggests it's an SSL problem, but I don't have the technical knowledge > to fix it. The log says: > > fetchmail: Query status=2 (SOCKET) > fetchmail: awakened by User defined signal 1 > fetchmail: starting fetchmail 6.4.0.rc4 daemon > fetchmail: mail.btinternet.com: upgrade to TLS failed. > fetchmail: Unknown login or authentication error on > <user>@bti...@ma... > fetchmail: socket error while fetching from > <user>@bti...@ma... > fetchmail: Query status=2 (SOCKET) > > I gather that my provider supports ssl but not startttls, but I have > no idea what that means. > > I'd really appreciate some guidance on what to do. Richard, A quick workaround seems to be that you add --ssl to the command line, or ssl to the rcfile - that way, fetchmail connects to the TLS-wrapped port, which seems to work for me. HTH for you too, Matthias |
|
From: <ric...@bt...> - 2019-10-19 16:20:57
|
I have just upgraded from Ubuntu 19.04 to 19.10 and I find that fetchmail is unable to retrieve emails from the POP3 server. The log suggests it's an SSL problem, but I don't have the technical knowledge to fix it. The log says: fetchmail: Query status=2 (SOCKET) fetchmail: awakened by User defined signal 1 fetchmail: starting fetchmail 6.4.0.rc4 daemon fetchmail: mail.btinternet.com: upgrade to TLS failed. fetchmail: Unknown login or authentication error on <user>@bti...@ma... fetchmail: socket error while fetching from <user>@bti...@ma... fetchmail: Query status=2 (SOCKET) I gather that my provider supports ssl but not startttls, but I have no idea what that means. I'd really appreciate some guidance on what to do. - Richard |
|
From: Matthias A. <mat...@gm...> - 2019-10-11 22:10:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Greetings, I have moved the fetchmail.info home page from sourceforge's VHOST service to my own web server, so as to enable https:// access. I cannot have https:// for sourceforge's VHOST service. https://www.fetchmail.info/ may see service interruptions within the next 24 hours while DNS and servers are out of synch. Purging your DNS caches may help if you have control over your resolvers. The sourceforge-hosted website has been residing under https://fetchmail.sourceforge.io/ for a few days already, http://fetchmail.sourceforge.net/ has redirected there since. After the change (i. e. on 2019-10-13 latest), the web addresses should be https://www.fetchmail.info/ https://fetchmail.sourceforge.io/ The project pages remain at https://sourceforge.net/projects/fetchmail/ https://gitlab.com/fetchmail/fetchmail/ Regards, Matthias -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAl2g+PYACgkQ5BKxVu/z hVpkfRAAhHMLfMMTZdzIo+AheCAGA2hEBHRizvq0Fm4RUNeRSXWgRn2kQu1BK9KX 1QbIPUTTCvtsTmXCEwDQtLutyRKh0sVpXV545LpNZ0h/42jVv5ARJdjK4ex3MqNk eCO3B+EgjmqZXJ0lcDVMF+sKzaCo8amrZMIXWt9irAR+bAWgEuyKEbD7hLY97FfH z+9qxnciGYrkYwmRfinm7jY76Zr7JtiZX7/2qvFdx708EqRrdCfhs0puJix+837a X2y4ihv0GErLrC+87QfX4/ZsNJRGaQhmWLDOL8xU1K568t2k23D66M3E+9rGmQi4 E+3mWmsoWoYHtS3+v2zP1rQAIoYcNBL5HaKqDoNhL861tQPyDryqOj2wHDC37Kut JmQ2fcI3N5DsRDQ4mF9K6Wg8SWG4rQiLaqjYMK9XaHhWFLrvooKp8ms+tOrg6ypC 0B2v8M3xEqWWlyCb80ZUN/UEKxEV2f11j9iGgIuhFqSKvlyDTId8NwRdPkQYAERa B8wToqmKjc2LfhY7zCA6k36KKztz+wFpF3KHBg41nXw/K5nnjsf52qR2EbjUocf0 rfDLimlrCl+pXmHTr+I04B4fjL6dkjSr9tbqATFPNHpmj0mmpbkmZ3u/d7hKvCiJ 3M6zYOxSIikaFlYXvvxsUPF6ksHCXFkGT9pDb7pU9PO+TXNC9wQ= =s/XO -----END PGP SIGNATURE----- |
|
From: <rus...@gm...> - 2019-10-03 22:26:48
|
'This looks like a successful connect. And now?' This was a successful connection. I cited it because I couldn't figure out what other cert was involved. Using strace revealed that. russell bell |
|
From: Matthias A. <mat...@gm...> - 2019-10-03 17:12:09
|
Am 02.10.19 um 13:30 schrieb rus...@gm...: > 'fetchmail -v or fetchmail -v -v should show the issuer and subject common names' > > Hmmm... I log only the cert gmail issues. It sez depth 2, but > both certs are in the gmail cert, which isn't hashed because there are > multiple certs in 1 file. I hash the certs in /etc/ssl/certs by hand. This looks like a successful connect. And now? > fetchmail: 6.4.1 querying pop.gmail.com (protocol POP3) at Tue 01 Oct 2019 07:54:03 PM MDT: poll started > fetchmail: Trying to connect to 123.45.67.890/995...connected. > fetchmail: SSL verify callback depth 2: preverify_ok == 1, err = 0, ok > fetchmail: Certificate chain, from root to peer, starting at depth 2: > fetchmail: Issuer Organization: GlobalSign > fetchmail: Issuer CommonName: GlobalSign > fetchmail: Subject CommonName: GlobalSign > fetchmail: SSL verify callback depth 1: preverify_ok == 1, err = 0, ok > fetchmail: Certificate at depth 1: > fetchmail: Issuer Organization: GlobalSign > fetchmail: Issuer CommonName: GlobalSign > fetchmail: Subject CommonName: GTS CA 1O1 > fetchmail: SSL verify callback depth 0: preverify_ok == 1, err = 0, ok > fetchmail: Server certificate: > fetchmail: Issuer Organization: Google Trust Services > fetchmail: Issuer CommonName: GTS CA 1O1 > fetchmail: Subject CommonName: pop.gmail.com > fetchmail: Subject Alternative Name: pop.gmail.com > fetchmail: pop.gmail.com key fingerprint: redacted > fetchmail: pop.gmail.com fingerprints match. > fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits > fetchmail: POP3< +OK Gpop ready for requests from 123.45.67.890 x19mb40915764ocd |
|
From: <rus...@gm...> - 2019-10-02 11:30:16
|
'fetchmail -v or fetchmail -v -v should show the issuer and subject common names' Hmmm... I log only the cert gmail issues. It sez depth 2, but both certs are in the gmail cert, which isn't hashed because there are multiple certs in 1 file. I hash the certs in /etc/ssl/certs by hand. fetchmail: 6.4.1 querying pop.gmail.com (protocol POP3) at Tue 01 Oct 2019 07:54:03 PM MDT: poll started fetchmail: Trying to connect to 123.45.67.890/995...connected. fetchmail: SSL verify callback depth 2: preverify_ok == 1, err = 0, ok fetchmail: Certificate chain, from root to peer, starting at depth 2: fetchmail: Issuer Organization: GlobalSign fetchmail: Issuer CommonName: GlobalSign fetchmail: Subject CommonName: GlobalSign fetchmail: SSL verify callback depth 1: preverify_ok == 1, err = 0, ok fetchmail: Certificate at depth 1: fetchmail: Issuer Organization: GlobalSign fetchmail: Issuer CommonName: GlobalSign fetchmail: Subject CommonName: GTS CA 1O1 fetchmail: SSL verify callback depth 0: preverify_ok == 1, err = 0, ok fetchmail: Server certificate: fetchmail: Issuer Organization: Google Trust Services fetchmail: Issuer CommonName: GTS CA 1O1 fetchmail: Subject CommonName: pop.gmail.com fetchmail: Subject Alternative Name: pop.gmail.com fetchmail: pop.gmail.com key fingerprint: redacted fetchmail: pop.gmail.com fingerprints match. fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits fetchmail: POP3< +OK Gpop ready for requests from 123.45.67.890 x19mb40915764ocd russell bell |
|
From: Matthias A. <mat...@gm...> - 2019-10-01 16:42:23
|
Am 01.10.19 um 13:19 schrieb rus...@gm...: > Thanks. A crontab job checks Slackware daily so my packages > are never more than a day out-of-date. It installs its certificates > in /usr/share/ca-certificates/mozilla/ ; I put mine in /etc/ssl/certs/ , > link the certs in /usr/share/ca-certificates/mozilla/ to there. I > deleted all those links, made a new set, which seems to make fetchmail > happy. Perhaps Slackware's package manager didn't delete old certs > because there were external links to them? > Good to know the cert checks out for fetchmail now. For all > this time I thought the only relevant cert was the one gmail issued. > How can I know which it uses? fetchmail -v or fetchmail -v -v should show the issuer and subject common names, or if you have broken-out certificate files (not one bundle file, but 100+ individual files), you can probably use strace -e trace=open or truss ... |& grep open to trace the files that OpenSSL opens. Note OpenSSL needs symlinks on broken-out directories that an OpenSSL-supplied script named c_rehash generates, it needs to be run on /etc/ssl/certs. OpenSSL will only attempt 12345678.0-like files, not the full .pem files. Not sure if Slackware has update-ca-certificates or similar scripts or post-install procedures that see to these. |
|
From: Ralph C. <ra...@in...> - 2019-10-01 11:58:00
|
Hi russell,
> For all this time I thought the only relevant cert was the one gmail
> issued. How can I know which it uses?
I think this formats the certificate handed over during TLS negogiation.
openssl s_client -connect pop.gmail.com:pop3s </dev/null |
openssl x509 -text
Its Issuer is visible, and can be seen in the middle of the chain listed
at the start.
--
Cheers, Ralph.
|
|
From: <rus...@gm...> - 2019-10-01 11:19:59
|
Thanks. A crontab job checks Slackware daily so my packages are never more than a day out-of-date. It installs its certificates in /usr/share/ca-certificates/mozilla/ ; I put mine in /etc/ssl/certs/ , link the certs in /usr/share/ca-certificates/mozilla/ to there. I deleted all those links, made a new set, which seems to make fetchmail happy. Perhaps Slackware's package manager didn't delete old certs because there were external links to them? Good to know the cert checks out for fetchmail now. For all this time I thought the only relevant cert was the one gmail issued. How can I know which it uses? russell bell |
|
From: Matthias A. <mat...@gm...> - 2019-09-30 18:57:10
|
Am 29.09.19 um 22:17 schrieb grarpamp: >> I added this: ssl sslproto auto >> I then changed it to this: ssl sslproto tlsv1.2 > For clarity, discrete parsing and easier line oriented > debug and error printing, try to recommend people not use > such multiple things all mashed into one single line > config syntax, and also avoid use of "noise", "english", > and "punctuation". > > Single line is also very hard for external constructors > and parsers to deal with. And seems more work to > maintain all this internally. > > Have seen local users trying to concoct, share, > teach, and cut / paste all sorts of random broken > configs because of "noise", "english", "punctuation" > and similar syntax and format "features", instead of > using some standard technical config file like any other > program on the net. > And having more than one format for configs does not help. Please file this as a Gitlab issue with a somewhat clearer wording (it appears this is very compact), I'll mark it feature request/milestone 7.0. Thanks. |
|
From: Matthias A. <mat...@gm...> - 2019-09-30 18:55:36
|
Am 30.09.19 um 04:35 schrieb rus...@gm...: > Beginning with 6.4.1, when I fetch mail from my gmail account, > I get: > > fetchmail: Server certificate verification error: unable to get local issuer certificate > fetchmail: Broken certification chain at: /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign > fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about. For details, please > see the README.SSL-SERVER document that ships with fetchmail. > fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. > fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed > fetchmail: pop.gmail.com: SSL connection failed. > fetchmail: socket error while fetching from Fak...@po... > fetchmail: Query status=2 (SOCKET) > > > I went back to 6.3.26, which works. Linux (kernel 5.3.1), > Slackware (updated daily), 64-bit, OpenSSL 1.1.1d 10 Sep 2019 > > Feel free to tell me it's all my fault. Russell, thanks for building that bridge. Let's be a bit more constructive so people will find this, and I've amended to the Subject line, too. The thing is that "the root CA's signing certificate is not in the trusted CA certificate location" as the error messages states, and you need to fix that. fetchmail 6.3.26 did not verify the certificate in your configuration, and I made fetchmail 6.4 do that by default (i. e. as if --sslcertck were added). I guess if you add --sslcertck to fetchmail 6.3.26's command line, it will fail, too - if it doesn't then the builds use differing OpenSSL libraries or configurations. Many "major" Linux distributions have packages of Mozilla's trusted certificates, and slackware's appears to be named "ca-certificates" if I interpret https://packages.slackware.com/ correctly. Install that (a _current_ version of it - certificates expire, and sometimes they get untrusted) - 20190826 from slackware-current should be OK, a 2016 version is certainly too, and see if that helps. Some info is also in the README.SSL file that ships with fetchmail, and I see that 6.4.2+ should add a reference to it. "Works for me" on Fedora 30: $ fetchmail --ssl -p pop3 pop.gmail.com -u testuser -v fetchmail: 6.4.1 querying pop.gmail.com (protocol POP3) at Mo 30 Sep 2019 20:49:34 CEST: poll started Trying to connect to 2a00:1450:400c:c00::6c/995...connected. fetchmail: Server certificate: fetchmail: Issuer Organization: Google Trust Services fetchmail: Issuer CommonName: GTS CA 1O1 fetchmail: Subject CommonName: pop.gmail.com fetchmail: Subject Alternative Name: pop.gmail.com fetchmail: pop.gmail.com key fingerprint: 97:15:E2:F8:6F:7E:88:E7:23:93:57:77:36:71:4C:3F fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits fetchmail: POP3< +OK Gpop ready for requests from 2003:d0:2719:f100:9d30:e07f:b412:af73 f18mb6117392wmf [...] HTH Matthias |
|
From: <rus...@gm...> - 2019-09-30 02:35:26
|
Beginning with 6.4.1, when I fetch mail from my gmail account, I get: fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: Broken certification chain at: /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about. For details, please see the README.SSL-SERVER document that ships with fetchmail. fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed fetchmail: pop.gmail.com: SSL connection failed. fetchmail: socket error while fetching from Fak...@po... fetchmail: Query status=2 (SOCKET) I went back to 6.3.26, which works. Linux (kernel 5.3.1), Slackware (updated daily), 64-bit, OpenSSL 1.1.1d 10 Sep 2019 Feel free to tell me it's all my fault. russell bell |
|
From: grarpamp <gra...@gm...> - 2019-09-29 20:17:39
|
> I added this: ssl sslproto auto > I then changed it to this: ssl sslproto tlsv1.2 For clarity, discrete parsing and easier line oriented debug and error printing, try to recommend people not use such multiple things all mashed into one single line config syntax, and also avoid use of "noise", "english", and "punctuation". Single line is also very hard for external constructors and parsers to deal with. And seems more work to maintain all this internally. Have seen local users trying to concoct, share, teach, and cut / paste all sorts of random broken configs because of "noise", "english", "punctuation" and similar syntax and format "features", instead of using some standard technical config file like any other program on the net. And having more than one format for configs does not help. $0.02 |
|
From: Matthias A. <mat...@gm...> - 2019-09-29 13:43:49
|
Am 29.09.19 um 14:53 schrieb Jerry: > The old version of Fetchmail would connect and collect mail from my TWC > mail account just fine. The new version is failing with this error > message: Jerry, "timeout" is suspicious and hints to network issues. The usual drills is: no logs, no support. http://www.fetchmail.info/fetchmail-FAQ.html#G3 And guess what, fetchmail 6.4.1 does work for me, without or with --sslproto auto, I can connect to mail.twc.com. This is on FreeBSD 12.0 RELEASE (OpenSSL 1.1.1a-freebsd 20 Nov 2018) and Fedora 30 (OpenSSL 1.1.1d FIPS 10 Sep 2019) > [mandree@hostA _build-asan]$ ./fetchmail mail.twc.com -u testuser -p > imap --ssl --auth external -vv > [...] > fetchmail: 6.4.1 querying mail.twc.com (protocol IMAP) at So 29 Sep > 2019 15:35:12 CEST: poll started > Trying to connect to 107.14.73.68/993...connected. > fetchmail: SSL verify callback depth 2: preverify_ok == 1, err = 0, ok > fetchmail: Certificate chain, from root to peer, starting at depth 2: > fetchmail: Issuer Organization: DigiCert Inc > fetchmail: Issuer CommonName: DigiCert Global Root CA > fetchmail: Subject CommonName: DigiCert Global Root CA > fetchmail: SSL verify callback depth 1: preverify_ok == 1, err = 0, ok > fetchmail: Certificate at depth 1: > fetchmail: Issuer Organization: DigiCert Inc > fetchmail: Issuer CommonName: DigiCert Global Root CA > fetchmail: Subject CommonName: DigiCert SHA2 Secure Server CA > fetchmail: SSL verify callback depth 0: preverify_ok == 1, err = 0, ok > fetchmail: Server certificate: > fetchmail: Issuer Organization: DigiCert Inc > fetchmail: Issuer CommonName: DigiCert SHA2 Secure Server CA > fetchmail: Subject CommonName: mail.twc.com > fetchmail: Subject Alternative Name: imap.mail.twc.com > [...] > fetchmail: Subject Alternative Name: mail.twc.com > fetchmail: mail.twc.com key fingerprint: > 35:BF:5D:5D:DB:40:B7:C8:30:96:9F:4C:46:9C:15:2B > fetchmail: SSL/TLS: using protocol TLSv1.2, cipher AES256-GCM-SHA384, > 256/256 secret/processed bits > fetchmail: IMAP< * OK IMAP4 server (InterMail vM.8.04.03.24.04 > 201-2389-100-175-1-20180501) ready Sun, 29 Sep 2019 13:35:12 +0000 (UTC) > fetchmail: IMAP> A0001 CAPABILITY > fetchmail: IMAP< * CAPABILITY IMAP4rev1 UIDPLUS NAMESPACE QUOTA > fetchmail: IMAP< A0001 OK CAPABILITY completed > fetchmail: Protocol identified as IMAP4 rev 1 > fetchmail: Authorization failure on tes...@dn... > fetchmail: IMAP> A0002 LOGOUT > fetchmail: IMAP< * BYE IMAP4 server terminating connection > fetchmail: IMAP< A0002 OK LOGOUT completed > fetchmail: 6.4.1 querying mail.twc.com (protocol IMAP) at So 29 Sep > 2019 15:35:13 CEST: poll completed > fetchmail: Query status=3 (AUTHFAIL) > fetchmail: normal termination, status 3 |
|
From: Jerry <je...@se...> - 2019-09-29 13:21:52
|
The old version of Fetchmail would connect and collect mail from my TWC mail account just fine. The new version is failing with this error message: fetchmail: timeout after 30 seconds waiting for server mail.twc.com. fetchmail: socket error while fetching from US...@nc...@mail.twc.com fetchmail: Query status=2 (SOCKET) I tried connecting using 'openssl' successfully. This is the start of the connection: ~ $ openssl s_client -crlf -connect mail.twc.com:993 -tls1_2 CONNECTED(00000003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA verify return:1 depth=0 C = US, ST = Missouri, L = Saint Louis, O = "Charter Communications Operating, LLC", CN = mail.twc.com verify return:1 --- Certificate chain 0 s:C = US, ST = Missouri, L = Saint Louis, O = "Charter Communications Operating, LLC", CN = mail.twc.com i:C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA 1 s:C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA 2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIILrjCCCpagAwIBAgIQBX5GbbeS0b4Jl8aBoPm6nzANBgkqhkiG9w0BAQsFADBN MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgxMDI5MDAwMDAwWhcN MTkxMDMwMTIwMDAwWjB9MQswCQYDVQQGEwJVUzERMA8GA1UECBMITWlzc291cmkx FDASBgNVBAcTC1NhaW50IExvdWlzMS4wLAYDVQQKEyVDaGFydGVyIENvbW11bmlj YXRpb25zIE9wZXJhdGluZywgTExDMRUwEwYDVQQDEwxtYWlsLnR3Yy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRwExBKr1OgSZm6fK8X1SUuVv4 oNWv1/87WJnVJ53buSM9Lf//SzY5AdozEweIw30lFJwppta6NiAWBeqejtfIyBbY bJObVVqqNQqb/XvnMZQBzmTaHsHQX+yQRoDuqEHc0SGef9YjL+hpPJtO1O6cCFv8 cHr/aK2ilek1coK7Xm7y9gc5yuulZvVeJssS9cFtlu6L+E+IqmG6MO+5b4pZAMjb 9sS0iIeL70iq7VdF87ac7kJ7rdX8eXdJeSRMgrZON9PKb80A8hGZO6fXLxnLYE++ a4hawgAINHCMDHNHC4cEz1sto2ufcJ5hjrXfl+rQ63PLVZ0o0Cx9nFgqYI+3AgMB AAGjgghYMIIIVDAfBgNVHSMEGDAWgBQPgGEcgjFh1S8o541GOLQs4cbZ4jAdBgNV HQ4EFgQU6ZyH6xz4IMfjZfODJfA0NKbFtv8wggWTBgNVHREEggWKMIIFhoIRaW1h cC5tYWlsLnR3Yy5jb22CF3BvcC1zZXJ2ZXIubWFpbC50d2MuY29tghV3ZWJtYWls LmF1c3Rpbi5yci5jb22CEndlYm1haWwuYmFrLnJyLmNvbYIYd2VibWFpbC5iZXJr c2hpcmUucnIuY29tghN3ZWJtYWlsLmJoYW0ucnIuY29tghF3ZWJtYWlsLmNhLnJy LmNvbYIXd2VibWFpbC5jYXJvbGluYS5yci5jb22CEndlYm1haWwuY2ZsLnJyLmNv bYIUd2VibWFpbC5jaW5jaS5yci5jb22CF3dlYm1haWwuY29sdW1idXMucnIuY29t ghF3ZWJtYWlsLmRjLnJyLmNvbYIRd2VibWFpbC5lYy5yci5jb22CFXdlYm1haWwu ZWxtb3JlLnJyLmNvbYISd2VibWFpbC5lbHAucnIuY29tghZ3ZWJtYWlsLmV1ZmF1 bGEucnIuY29tghF3ZWJtYWlsLmd0LnJyLmNvbYIVd2VibWFpbC5oYXdhaWkucnIu Y29tghJ3ZWJtYWlsLmhvdC5yci5jb22CEndlYm1haWwuaHZjLnJyLmNvbYITd2Vi bWFpbC5pbmR5LnJyLmNvbYIWd2VibWFpbC5pbnNpZ2h0LnJyLmNvbYIRd2VibWFp bC5rYy5yci5jb22CEXdlYm1haWwubWEucnIuY29tghN3ZWJtYWlsLm1haWwucnIu Y29tghR3ZWJtYWlsLm1haW5lLnJyLmNvbYITd2VibWFpbC5tYXNzLnJyLmNvbYIY d2VibWFpbC5tZXNzYWdpbmcucnIuY29tghF3ZWJtYWlsLm1pLnJyLmNvbYIRd2Vi bWFpbC5uYy5yci5jb22CEXdlYm1haWwubmUucnIuY29tghJ3ZWJtYWlsLm5lYi5y ci5jb22CEndlYm1haWwubmVvLnJyLmNvbYISd2VibWFpbC5uZXcucnIuY29tghF3 ZWJtYWlsLm5qLnJyLmNvbYISd2VibWFpbC5ueWMucnIuY29tghR3ZWJtYWlsLm55 Y2FwLnJyLmNvbYIRd2VibWFpbC5vaC5yci5jb22CEXdlYm1haWwucGEucnIuY29t ghh3ZWJtYWlsLnBhbmhhbmRsZS5yci5jb22CEndlYm1haWwucmd2LnJyLmNvbYIW d2VibWFpbC5yb2FkcnVubmVyLmNvbYIYd2VibWFpbC5yb2NoZXN0ZXIucnIuY29t ghJ3ZWJtYWlsLnNhbi5yci5jb22CE3dlYm1haWwuc2F0eC5yci5jb22CEXdlYm1h aWwuc2MucnIuY29tghV3ZWJtYWlsLnNoYWRvdy5yci5jb22CEXdlYm1haWwuc2ku cnIuY29tghR3ZWJtYWlsLnNvY2FsLnJyLmNvbYITd2VibWFpbC5zdG55LnJyLmNv bYISd2VibWFpbC5zdHgucnIuY29tghF3ZWJtYWlsLnN3LnJyLmNvbYIXd2VibWFp bC50YW1wYWJheS5yci5jb22CFHdlYm1haWwudHJpYWQucnIuY29tgg93ZWJtYWls LnR3Yy5jb22CF3dlYm1haWwuYnJpZ2h0aG91c2UuY29tghR3ZWJtYWlsLnR3Y255 LnJyLmNvbYITd2VibWFpbC50d21pLnJyLmNvbYIRd2VibWFpbC50eC5yci5jb22C EXdlYm1haWwud2UucnIuY29tghF3ZWJtYWlsLndpLnJyLmNvbYISd2VibWFpbC53 b2gucnIuY29tggh0d2NjLmNvbYIMd3d3LnR3Y2MuY29tggpiaG4ucnIuY29tgg9z ZWFyY2gudHdjYy5jb22CDXNlYXJjaC5yci5jb22CFG1haWwuYnJpZ2h0aG91c2Uu Y29tggxtYWlsLnR3Yy5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMBBggrBgEFBQcDAjBrBgNVHR8EZDBiMC+gLaArhilodHRwOi8vY3JsMy5k aWdpY2VydC5jb20vc3NjYS1zaGEyLWc2LmNybDAvoC2gK4YpaHR0cDovL2NybDQu ZGlnaWNlcnQuY29tL3NzY2Etc2hhMi1nNi5jcmwwTAYDVR0gBEUwQzA3BglghkgB hv1sAQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQ UzAIBgZngQwBAgIwfAYIKwYBBQUHAQEEcDBuMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wRgYIKwYBBQUHMAKGOmh0dHA6Ly9jYWNlcnRzLmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJTZWN1cmVTZXJ2ZXJDQS5jcnQwCQYDVR0T BAIwADCCAQYGCisGAQQB1nkCBAIEgfcEgfQA8gB3AKS5CZC0GFgUh7sTosxncAo8 NZgE+RvfuON3zQ7IDdwQAAABZr+xp/0AAAQDAEgwRgIhAMh91U6tmk+jJ/nq3p/6 p8855p2UpjMqPySXK8BxWwfqAiEAsTlfZiB4OPrK+6Unul0T2I3dr1UfFHjuNa0j 4TggA/sAdwCHdb/nWXz4jEOZX73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWa/sai9 AAAEAwBIMEYCIQCr4S0AIma5CsgDvIn5yqkKjRGu3OSJdo4f0KL3sCe1kAIhALGN 85NOr5y8vwir42dzEIQglVkS3T+MPVj//CNcLVH+MA0GCSqGSIb3DQEBCwUAA4IB AQBwW8iznCxFKOMx+cdH93F2U9k4YYhqbeBoXzu53VXSKrSdHh4ZSpWAHx/WIRR+ VcLb8U9H/rAuCHopbV90Ok0Ir/9itbU6uwsfFSfYN9Xmb7uEcjPUQ8clks9lfrk7 k6gx28Yv+l/QjCVaY/eYXKpGy41DMGPNnIrIPSSzJ7n5JxSbm3PZ22K9njsGCTsH 2M9TSSDNZXVcjIGEFrJY14mddNOBAxI+yhNKPJ8miZBe52TFbZcy5CULr2B7hkNe qNoVDn9dVtLx5/B0XZ48j2wucGVbxn1Cw3sE7HPB4wh2Dou0UL44/tA14xEd76QY oyKNkf7NqgEOKyC66VTxUFMX -----END CERTIFICATE----- subject=C = US, ST = Missouri, L = Saint Louis, O = "Charter Communications Operating, LLC", CN = mail.twc.com issuer=C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA --- No client certificate CA names sent --- SSL handshake has read 5447 bytes and written 533 bytes Verification: OK --- New, TLSv1.2, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : AES256-GCM-SHA384 Session-ID: 49970E5A87E7B161EFDC9723E2FCB7ACB1FA12D10C7C460BAA09E7FDCDB33A86 Session-ID-ctx: Master-Key: 2E67C0F1B6DD033D09DAE9C6E36C360C49CF7C42A62E52C762526ED7DD1A78DE88851795DA82A744496E18E70A5B6625 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 87 4e 5a e4 98 60 4f 78-38 38 75 08 3a ea 0e 70 .NZ..`Ox88u.:..p 0010 - 1d 04 69 98 08 65 33 9e-10 74 58 3a 42 74 e8 16 ..i..e3..tX:Bt.. 0020 - 18 e6 9c 88 2b 00 7e a2-e0 93 9d bf 82 a6 54 a6 ....+.~.......T. 0030 - 8a 6f 3e a7 19 68 bd 93-aa e7 0d 2a 61 6c 05 cb .o>..h.....*al.. 0040 - b6 65 0a e4 03 78 95 17-11 db dd 9a d6 b8 ea 73 .e...x.........s 0050 - 31 a5 63 14 d4 d4 0a 4f-28 4f 7c 76 35 e7 17 a9 1.c....O(O|v5... 0060 - 84 a8 2e 43 c2 bf f0 ff-85 79 a3 76 f8 5e c8 f3 ...C.....y.v.^.. 0070 - af e7 04 f5 b7 d4 1f b3-e4 46 4a 30 8d 72 6a 16 .........FJ0.rj. 0080 - db 7d 9b 45 87 db e3 8a-17 55 6d c1 35 70 b7 74 .}.E.....Um.5p.t 0090 - f7 35 a0 dc 9a 4d 90 77-50 e2 98 c5 61 75 bc 7a .5...M.wP...au.z 00a0 - d9 e8 89 c9 ad 42 f9 97-48 80 ff 28 c1 a1 15 44 .....B..H..(...D Start Time: 1569760454 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- * OK IMAP4 server (InterMail vM.8.04.03.24.04 201-2389-100-175-1-20180501) ready Sun, 29 Sep 2019 12:34:14 +0000 (UTC) I had no settings for SSL or sslproto in the older fetchmail config file. I added this: ssl sslproto auto I still cannot make a connection. I then changed it to this: ssl sslproto tlsv1.2 Apparently, the sslproto 'auto' setting is not working. Perhaps it is a bug or else I am doing something wrong. -- Jerry |
|
From: Gene H. <ghe...@sh...> - 2019-09-29 01:28:52
|
On Saturday 28 September 2019 17:33:33 Matthias Andree wrote: > Am 28.09.19 um 19:37 schrieb Gene Heskett: > > On Saturday 28 September 2019 11:26:31 Matthias Andree wrote: > >> Am 28.09.19 um 16:43 schrieb Peter Pentchev: > >> Yeah. Sorry for my bad English. I had to get 6.4.1 out in a rush > >> because 6.4.0 was so utterly broken, so I couldn't ponder the > >> wording for too long. > > > > Don't be sorry Matthias, after all, you did take the time to learn > > my language, but its been 65 years since I waded thru a telefunken > > radio schematic, absorbing just enough German to fix the radio. They > > made pretty good radios back in the day. Or at least this Iowa farm > > kid thought so. > > Thanks. The gist is that 6.4.1 had to happen quickly and the focus was > on testing the code, but not proof-reading the text. It might habe > been unintelligible to the uninitiated in German, too. > > I surmise that unless other important bugs want expedited fixing, I > should do a 6.4.2 in November or so with spelling and grammar fixes > and possibly clearer descriptions for non-programmers. I also hope > that 6.4.1 might entice translators to update/complete translations, > or possibly contribute new translations. > That does have a certain attraction for the super picky I'm sure. And I'm with many in that better docs are always welcomed, but that call is yours. I've been using it as a substitute for kmails mail fetcher for well over a decade. As long as I tell it to do sensible things, its just worked except with my present ISP, who serves its pop3 customers email from the same server as their imap using clients. So they've disabled fetchmails ability to delete, meaning I have to log in with firefox and delete old mail at approximately daily intervals. No biggie IMO. My thanks to you, and to any other maintainers its had over a rather lengthy piece of the internets history. Take care now. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene> |
|
From: Matthias A. <mat...@gm...> - 2019-09-28 21:33:48
|
Am 28.09.19 um 19:37 schrieb Gene Heskett: > On Saturday 28 September 2019 11:26:31 Matthias Andree wrote: > >> Am 28.09.19 um 16:43 schrieb Peter Pentchev: >> Yeah. Sorry for my bad English. I had to get 6.4.1 out in a rush >> because 6.4.0 was so utterly broken, so I couldn't ponder the wording >> for too long. >> > Don't be sorry Matthias, after all, you did take the time to learn my > language, but its been 65 years since I waded thru a telefunken radio > schematic, absorbing just enough German to fix the radio. They made > pretty good radios back in the day. Or at least this Iowa farm kid > thought so. Thanks. The gist is that 6.4.1 had to happen quickly and the focus was on testing the code, but not proof-reading the text. It might habe been unintelligible to the uninitiated in German, too. I surmise that unless other important bugs want expedited fixing, I should do a 6.4.2 in November or so with spelling and grammar fixes and possibly clearer descriptions for non-programmers. I also hope that 6.4.1 might entice translators to update/complete translations, or possibly contribute new translations. |
|
From: Gene H. <ghe...@sh...> - 2019-09-28 17:37:33
|
On Saturday 28 September 2019 11:26:31 Matthias Andree wrote: > Am 28.09.19 um 16:43 schrieb Peter Pentchev: > > On Sat, Sep 28, 2019 at 10:37:41AM -0400, Gene Heskett wrote: > >> Did I miss this correction in the 6.4.1 announcement? > > > > I believe this is the "regression in the default file locations" > > part. > > Yeah. Sorry for my bad English. I had to get 6.4.1 out in a rush > because 6.4.0 was so utterly broken, so I couldn't ponder the wording > for too long. > Don't be sorry Matthias, after all, you did take the time to learn my language, but its been 65 years since I waded thru a telefunken radio schematic, absorbing just enough German to fix the radio. They made pretty good radios back in the day. Or at least this Iowa farm kid thought so. > > > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene> |
|
From: Gene H. <ghe...@sh...> - 2019-09-28 17:30:16
|
On Saturday 28 September 2019 10:43:31 Peter Pentchev wrote: > On Sat, Sep 28, 2019 at 10:37:41AM -0400, Gene Heskett wrote: > > On Saturday 28 September 2019 07:32:02 Matthias Andree wrote: > > > Am 27.09.19 um 23:44 schrieb Gene Heskett: > > > > On Friday 27 September 2019 17:09:55 Christian Ebert wrote: > > > >> * Matthias Andree on Friday, September 27, 2019 at 19:47:42 +0200: > > > >>> -----BEGIN PGP SIGNED MESSAGE----- > > > >>> Hash: SHA256 > > > >>> > > > >>> Greetings, > > > >>> > > > >>> I have released fetchmail-6.4.0, it is available from > > > >>> sourceforge.net, see: > > > >>> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/> > > > >> > > > >> Hm, it expects defaut user rc file location at > > > >> $HOME/fetchmailrc not $HOME/.fetchmailrc > > > > > > > > Ooops, do I wait for a 6.4.1? I think so. > > > > > > Yes, the wait has ended. Sorry for the messup. > > > > Did I miss this correction in the 6.4.1 announcement? > > I believe this is the "regression in the default file locations" part. > I wondered if that meant that. ATM I'm up to my ears in alu cuttings for a pi4 heat sink, but might find time to put it in sometime in the next couple days. Been using it for almost 2 decades now. > G'luck, > Peter Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene> |
|
From: Matthias A. <mat...@gm...> - 2019-09-28 15:26:46
|
Am 28.09.19 um 16:43 schrieb Peter Pentchev: > On Sat, Sep 28, 2019 at 10:37:41AM -0400, Gene Heskett wrote: > >> Did I miss this correction in the 6.4.1 announcement? > I believe this is the "regression in the default file locations" part. Yeah. Sorry for my bad English. I had to get 6.4.1 out in a rush because 6.4.0 was so utterly broken, so I couldn't ponder the wording for too long. |
|
From: Peter P. <ro...@ri...> - 2019-09-28 15:08:27
|
On Sat, Sep 28, 2019 at 10:37:41AM -0400, Gene Heskett wrote: > On Saturday 28 September 2019 07:32:02 Matthias Andree wrote: > > > Am 27.09.19 um 23:44 schrieb Gene Heskett: > > > On Friday 27 September 2019 17:09:55 Christian Ebert wrote: > > >> * Matthias Andree on Friday, September 27, 2019 at 19:47:42 +0200: > > >>> -----BEGIN PGP SIGNED MESSAGE----- > > >>> Hash: SHA256 > > >>> > > >>> Greetings, > > >>> > > >>> I have released fetchmail-6.4.0, it is available from > > >>> sourceforge.net, see: > > >>> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/> > > >> > > >> Hm, it expects defaut user rc file location at $HOME/fetchmailrc > > >> not $HOME/.fetchmailrc > > > > > > Ooops, do I wait for a 6.4.1? I think so. > > > > Yes, the wait has ended. Sorry for the messup. > > > Did I miss this correction in the 6.4.1 announcement? I believe this is the "regression in the default file locations" part. G'luck, Peter -- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} 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: Matthias A. <mat...@gm...> - 2019-09-28 15:00:54
|
Am 28.09.19 um 16:37 schrieb Gene Heskett: > Did I miss this correction in the 6.4.1 announcement? > Cheers, Gene Heskett That's possible, it read: > fetchmail-6.4.1 (released 2019-09-28, 27473 LoC): > > ## REGRESSION FIXES: > * The bug fix Debian Bug#941129 was incomplete and caused > + a regression in the default file locations, so that fetchmail was no longer > able to find it configuration files in some situations. > Reported by Cy Schubert. > + a regression under _FORTIFY_SOURCE where PATH_MAX > minimal _POSIX_PATH_MAX. |
|
From: Gene H. <ghe...@sh...> - 2019-09-28 14:37:50
|
On Saturday 28 September 2019 07:32:02 Matthias Andree wrote: > Am 27.09.19 um 23:44 schrieb Gene Heskett: > > On Friday 27 September 2019 17:09:55 Christian Ebert wrote: > >> * Matthias Andree on Friday, September 27, 2019 at 19:47:42 +0200: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA256 > >>> > >>> Greetings, > >>> > >>> I have released fetchmail-6.4.0, it is available from > >>> sourceforge.net, see: > >>> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/> > >> > >> Hm, it expects defaut user rc file location at $HOME/fetchmailrc > >> not $HOME/.fetchmailrc > > > > Ooops, do I wait for a 6.4.1? I think so. > > Yes, the wait has ended. Sorry for the messup. > Did I miss this correction in the 6.4.1 announcement? Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene> |
|
From: Matthias A. <mat...@gm...> - 2019-09-28 11:32:22
|
Am 27.09.19 um 23:44 schrieb Gene Heskett: > On Friday 27 September 2019 17:09:55 Christian Ebert wrote: > >> * Matthias Andree on Friday, September 27, 2019 at 19:47:42 +0200: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> Greetings, >>> >>> I have released fetchmail-6.4.0, it is available from >>> sourceforge.net, see: >>> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/> >> Hm, it expects defaut user rc file location at $HOME/fetchmailrc >> not $HOME/.fetchmailrc > Ooops, do I wait for a 6.4.1? I think so. Yes, the wait has ended. Sorry for the messup. |
|
From: Matthias A. <mat...@gm...> - 2019-09-28 10:49:32
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Greetings, I have released fetchmail-6.4.1, it is available from sourceforge.net, see: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/> It is a RECOMMENDED update for all users, and fixes two regressions in fetchmail 6.4.0 since 6.4.0-rc4. fetchmail 6.4.0 has been withdrawn. Lesson learnt: do not change *anything* but the release name between release candidate and release. Older releases are herewith officially unsupported. Where to get it - Deep link to tarball: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.1.tar.xz/download> How to verify: GnuPG detached signature: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.1.tar.xz.asc/download> RIPEMD160(fetchmail-6.4.1.tar.xz)= 753d982f132cd5dcedb261631b5bee653410fef9 SHA1(fetchmail-6.4.1.tar.xz)= 1aadf078ed8fb1b6c93e9126cc0375b1f740301a SHA256(fetchmail-6.4.1.tar.xz)= 3f33f11dd08c3e8cc3e9d18eec686b1626d4818f4d5a72791507bbc4dce6a9a0 SHA512(fetchmail-6.4.1.tar.xz)= 940b8df52f963f71537962ebe2b2cb88298fd2b54ca79932e5c974abe850f0b59cdc4919d606ee4f210e82d1e0a6f090ea87f1d3bdea18b531d4fbb36f7f9ea0 Status: I plan to only do bug fixes to fetchmail-6.4.x so that upgrading to newer 6.4.x releases should be acceptable under many "stable branch" maintenance policies. More intrusive changes will happen to versions that have higher numbers such as 6.5.y or 7.n.m (with m, n, y being numbers). These are the release notes from NEWS: - -------------------------------------------------------------------------------- fetchmail-6.4.1 (released 2019-09-28, 27473 LoC): ## REGRESSION FIXES: * The bug fix Debian Bug#941129 was incomplete and caused + a regression in the default file locations, so that fetchmail was no longer able to find it configuration files in some situations. Reported by Cy Schubert. + a regression under _FORTIFY_SOURCE where PATH_MAX > minimal _POSIX_PATH_MAX. - -------------------------------------------------------------------------------- fetchmail-6.4.0 (released 2019-09-27, 27429 LoC): # NOTE THAT FETCHMAIL IS NO LONGER PUBLISHED THROUGH IBIBLIO. * They have stopped accepting submissions and consider themselves an archive. ## SECURITY FIXES THAT AFFECT BEHAVIOUR AND MAY REQUIRE RECONFIGURATION * Fetchmail no longer supports SSLv2. * Fetchmail no longer attempts to negotiate SSLv3 by default, even with --sslproto ssl23. Fetchmail can now use SSLv3, or TLSv1.1 or a newer TLS version, with STLS/STARTTLS (it would previously force TLSv1.0 with STARTTLS). If the OpenSSL version used at build and run-time supports these versions, --sslproto ssl3 and --sslproto ssl3+ can be used to re-enable SSLv3. Doing so is discouraged because the SSLv3 protocol is broken. Along the lines suggested - as patch - by Kurt Roeckx, Debian Bug #768843. While this change is supposed to be compatible with common configurations, users may have to and are advised to change all explicit --sslproto ssl2 (change to newer protocols required), --sslproto ssl3, --sslproto tls1 to --sslproto auto, so that they can benefit from TLSv1.1 and TLSv1.2 where supported by the server. The --sslproto option now understands the values auto, ssl3+, tls1+, tls1.1, tls1.1+, tls1.2, tls1.2+, tls1.3, tls1.3+ (case insensitively), see CHANGES below for details. * Fetchmail defaults to --sslcertck behaviour. A new option --nosslcertck to override this has been added, but may be removed in future fetchmail versions in favour of another configuration option that makes the insecurity in using this option clearer. ## SECURITY FIXES * Fetchmail prevents buffer overruns in GSSAPI authentication with user names beyond c. 6000 characters in length. Reported by Greg Hudson. ## CHANGED REQUIREMENTS * fetchmail 6.4.0 is written in C99 and requires a SUSv3 (Single Unix Specification v3, a superset of POSIX.1-2001 aka. IEEE Std 1003.1-2001 with XSI extension) compliant system. For now, a C89 compiler should also work if the system is SUSv3 compliant. In particular, older fetchmail versions had workaround for several functions standardized in the Single Unix Specification v3, these have been removed. The trio/ library has been removed from the distribution. ## CHANGES * fetchmail 6.3.X is unsupported. * fetchmail now configures OpenSSL support by default. * fetchmail now requires OpenSSL v1.0.2 or newer. * Fetchmail now supports --sslproto auto and --sslproto tls1+ (same as ssl23). * --sslproto tls1.1+, tls1.2+, and tls1.3+ are now supported for auto-negotiation with a minimum specified TLS protocol version, and --sslproto tls1.1, --sslproto tls1.2 and --sslproto tls1.3 to force the specified TLS protocol version. Note that tls1.3 requires OpenSSL v1.1.1 or newer. * Fetchmail now detects if the server hangs up prematurely during SSL_connect() and reports this condition as such, and not just as SSL connection failure. (OpenSSL 1.0.2 reported incompatible with pop3.live.com by Jerry Seibert). * A foreground fetchmail can now accept a few more options while another copy is running in the background. * fetchmail now handles POP3 --keep UID lists more efficiently, by using Rainer Weikusat's P-Tree implementation. This reduces the complexity for handling a large UIDL from O(n^2) to O(n log n) and becomes noticably faster with thousands of kept messages. (IMAP does not currently track UIDs and is unaffected.) At the same time, the UIDL emulation code for deficient servers has been removed. It never worked really well. Servers that do not implement the optional UIDL command only work with --fetchall option set, which in itself is incompatible with the --keep option (it would cause message duplication). * fetchmail, when setting up TLS connections, now uses SSL_set_tlsext_host_name() to set up the SNI (Server Name Indication). Some servers (for instance googlemail) require SNI when using newer SSL protocols. * Fetchmail now sets the expected hostname through OpenSSL 1.0.2's new X509_VERIFY_PARAM_set1_host() function to enable OpenSSL's native certificate verification features. * fetchmail will drop the connection when fetching with IMAP and receiving an unexpected untagged "* BYE" response, to work around certain faulty servers. * The FETCHMAIL_POP3_FORCE_RETR environment variable is now documented, it forces fetchmail, when talking POP3, to always use the RETR command, even if it would otherwise use the TOP command. * Fetchmail's configure stage will try to query pkg-config or pkgconf for libssl and libcrypto, in case other system use .pc files to document specific library dependencies. (contributed by Fabrice Fontaine, GitLab merge request !14.) * The gethostbyname() API calls and compatibility functions have been removed. * These translations are shipped but not installed by default because they have less than 500 translated messages out of 714: el fi gl pt_BR sk tr -> Greek, Finnish, Galician, Brazilian Portuguese, Slovak, Turkish. * Fetchmail now refuses delivery if the MDA option contains single-quoted expansions. ## FIXES * Fix a typo in the FAQ. Submitted by David Lawyer, Debian Bug#706776. * Do not translate header tags such as "Subject:". Reported by Gonzalo Pérez de Olaguer Córdoba, Debian Bug#744907. * Convert most links from berlios.de to sourceforge.net. * Report error to stderr, and exit, if --idle is combined with multiple accounts. * Point to --idle from GENERAL OPERATION to clarify --idle and multiple mailboxes do not mix. In response to Jeremy Chadwick's trouble 2014-11-19, fetchmail-users mailing list. * Fix SSL-enabled build on systems that do not declare SSLv3_client_method(), or that #define OPENSSL_NO_SSL3 inside #include <openssl/ssl.h> Related to Debian Bug#775255. Fixes Debian Bug #804604. * Version report lists -SSLv3 on SSL-enabled no-ssl3 builds. * Fetchmail no longer adds a NUL byte to the username in GSSAPI authentication. This was reported to break Kerberos-based authentication with Microsoft Exchange 2013 by Greg Hudson. * Set umask properly before writing the .fetchids file, to avoid failing the security check on the next run. Reported by Fabian Raab, Fixes Debian Bug#831611. * When forwarding by LMTP, also check antispam response code when collecting the responses after the CR LF . CR LF sequence at the end of the DATA phase. (Contributed by Evil.2000, GitLab merge request !12.) * fetchmail will not try other protocols after a socket error. This avoids mismatches of how different prococols see messages as "seen" and re-fetches of known mail. (Fix contributed by Lauri Nurmi, GitLab Merge Request !10.) * fetchmail no longer reports "System error during SSL_connect(): Success." Fixes Debian Bug#928916, reported by Paul Kimoto. * fetchmailconf would ignore Edit or Delete actions on the first (topmost) item in a list (no matter if server list, user list, ...). * The mimedecode feature now properly detects multipart/mixed-type matches, so that quoted-printable-encoded multipart messages can get decoded. (Regression in 5.0.0 on 1999-03-27, as a side effect of a PGP-mimedecode fix attributed to Henrik Storner.) * FETCHMAILHOME can now safely be a relative path, which will be qualified through realpath(). Previously, it had to be absolute in daemon mode. Reported by Alex Andreotti, Debian Bug#941129. ## UPDATED TRANSLATIONS - THANKS TO: * CS: Petr Pisar <pet...@at...> [Czech] * EO: Felipe Castro <fe...@gm...> [Esperanto] * FR: Frédéric Marchal <fma...@pe...> [French] * JP: Takeshi Hamasaki <hm...@us...> [Japanese] * PL: Jakub Bogusz <qb...@pl...> [Polish] * SV: Göran Uddeborg <go...@ud...> [Swedish] # KNOWN BUGS AND WORKAROUNDS (This section floats upwards through the NEWS file so it stays with the current release information) * Fetchmail does not handle messages without Message-ID header well (See sourceforge.net bug #780933) * Fetchmail currently uses 31-bit signed integers in several places where unsigned and/or wider types should have been used, for instance, for mailbox sizes, and misreports sizes of 2 GibiB and beyond. Fixing this requires C89 compatibility to be relinquished. * BSMTP is mostly untested and errors can cause corrupt output. * Sun Workshop 6 (SPARC) is known to miscompile the configuration file lexer in 64-bit mode. Either compile 32-bit code or use GCC to compile 64-bit fetchmail. * Fetchmail does not track pending deletes across crashes. * The command line interface is sometimes a bit stubborn, for instance, fetchmail -s doesn't work with a daemon running. * Linux systems may return duplicates of an IP address in some circumstances if no or no global IPv6 addresses are configured. (No workaround. Ubuntu Bug#582585, Novell Bug#606980.) * Kerberos 5 may be broken, particularly on Heimdal, and provide bogus error messages. This will not be fixed, because the maintainer has no Kerberos 5 server to test against. Use GSSAPI. - -------------------------------------------------------------------------------- Happy fetches, Matthias -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAl2POrYACgkQ5BKxVu/z hVp6MBAAvUGVyY68ze/U7ZVsXx401Tqs4bY0ozomAnvxS2gMI/6MCSjbo5isgz6f Q0wsLDBsMtufyUVsl0xg1jl++j9jSmrX9fkp+Ma9iX1d+FMRKSO3V19JDJ/Cunn0 DYw4sP8SIl8NaUcR95oNsCCxTsnMmqR7lo4/4ntpmiv/hT8k1Qy9KwX/rtb6zZTi Q/QWMP36PdTwLpClhmQpuYP4JZVHiIHxaVa6fKVQFI+CV5D0z1Uos4ifs9N4NF1F g0fOmCOTiNwm+pK/DV/GITyIQL8dGIe2gcWKPhMduYKpqPzNQeoj3mWYZKNzPK9m MaexHN90l9YOUnoIMri19QSRz8xJJspp1z2pGa9muDQMNYH2DV+7LXWrEd2tFV2S 2ExZT0s70VFLUvdz5NapqQ19Ab5Cu1TXVU4Yc4hKmwNWg8FBMcUxFtRcPS2lENPP CuJJEb2II5S98GjzLl152Vj0tKByYrihz3h6c+5tq5BovyN1ZlKgmTDmHCmnwrBT bB0cIsly6o8o3wL18wvuLgwg49I9BvV/XXOaQz8VLCoCbfvCCSuvDlJSqWvVuMm1 saq0Qe9h7Mo5KWa0txI3emCPj5wASMp9WEBtRNGVRl8rVY/h3cFJvDhqdjk5C/Ee Fb80jPJf743I8dQwMAuP/UXm5M9zB6ddmcrxwF4tfZ6rGgX32bI= =TDZF -----END PGP SIGNATURE----- |
18 messages has been excluded from this view by a project administrator.
