From: Joe Acquisto-j. <jo...@j4...> - 2020-02-05 02:40:25
|
Having entered the modern era, I seek guidance on the following problem: . . . fetchmail: 6.4.1 querying imap.gmail.com (protocol IMAP) at Tue 04 Feb 2020 09:05:20 PM EST: poll started fetchmail: Trying to connect to 173.194.175.108/143... (log message incomplete) fetchmail: timeout after 10 seconds waiting to connect to server imap.gmail.com. fetchmail: socket error while fetching from gue...@gm...@imap.gmail.com fetchmail: 6.4.1 querying imap.gmail.com (protocol IMAP) at Tue 04 Feb 2020 09:05:30 PM EST: poll completed fetchmail: Query status=2 (SOCKET) . . . A snippet of fetchmailrc is below: ----- set logfile "/var/log/fetchmail.log" set postmaster "admin@[mydomain]" set nobouncemail set no spambounce set properties "" set daemon 240 poll imap.gmail.com with proto IMAP timeout 10 envelope Delivered-to user 'gue...@gm...', with password 'someword', is 'xma...@an...' here folder 'Inbox' fetchlimit 10 sslfingerprint '11:22:33:53:84:9C:EF:6C:E2:BF:AA:A8:2A:DD:EE:FF' ------ This had been working during earlier testing, but stopped while. I updated to fetchmail 6.4.1, being the cautions fellow I am, yet, the problem persists. Checked that "less secure" apps was still enabled. Did find some "security warnings" about suspicious access attempts and approved them. That did not resolve the issue. Many indications on the web that gmail is particularly reluctant to play nice with others. FWIW there are several accounts defined in the same fetchmailrc file at another provider that work just fine in the same fetch cycle. Thanks in advance. joe a |
From: Joe Acquisto-j. <jo...@j4...> - 2020-02-05 03:26:40
|
>>> > Having entered the modern era, I seek guidance on the following problem: > . . . > fetchmail: 6.4.1 querying imap.gmail.com (protocol IMAP) at Tue 04 Feb 2020 > 09:05:20 PM EST: poll started > fetchmail: Trying to connect to 173.194.175.108/143... (log message > incomplete) > fetchmail: timeout after 10 seconds waiting to connect to server > imap.gmail.com. > fetchmail: socket error while fetching from > gue...@gm...@imap.gmail.com > fetchmail: 6.4.1 querying imap.gmail.com (protocol IMAP) at Tue 04 Feb 2020 > 09:05:30 PM EST: poll completed > fetchmail: Query status=2 (SOCKET) > . . . > > A snippet of fetchmailrc is below: > > ----- > set logfile "/var/log/fetchmail.log" > set postmaster "admin@[mydomain]" > set nobouncemail > set no spambounce > set properties "" > set daemon 240 > > poll imap.gmail.com with proto IMAP timeout 10 envelope Delivered-to > > user 'gue...@gm...', with password 'someword', is > 'xma...@an...' here folder 'Inbox' fetchlimit 10 > sslfingerprint '11:22:33:53:84:9C:EF:6C:E2:BF:AA:A8:2A:DD:EE:FF' > ------ > > This had been working during earlier testing, but stopped while. I updated > to fetchmail 6.4.1, being the cautions fellow I am, yet, the problem > persists. > > Checked that "less secure" apps was still enabled. Did find some "security > warnings" about suspicious access attempts and approved them. That did not > resolve the issue. > > Many indications on the web that gmail is particularly reluctant to play > nice with others. > > FWIW there are several accounts defined in the same fetchmailrc file at > another provider that work just fine in the same fetch cycle. > > Thanks in advance. > > joe a > BTW, the "timeout 10" was "timeout 120" in earlier testing, same result. joe a. |
From: Ralph C. <ra...@in...> - 2020-02-05 17:02:52
|
Hi Joe, > fetchmail: 6.4.1 querying imap.gmail.com (protocol IMAP) at Tue 04 Feb 2020 09:05:20 PM EST: poll started > fetchmail: Trying to connect to 173.194.175.108/143... (log message incomplete) ... > poll imap.gmail.com with proto IMAP timeout 10 envelope Delivered-to > user 'gue...@gm...', with password 'someword', is > 'xma...@an...' here folder 'Inbox' fetchlimit 10 > sslfingerprint '11:22:33:53:84:9C:EF:6C:E2:BF:AA:A8:2A:DD:EE:FF' Port 143, mentioned above, is IMAP. I don't know if Gmail every listen on that. You'll doing better using 993; see /etc/services for 993/tcp. That's achieved with fetchmail's keyword ssl; and it has friends. You've sslfingerprint above, so presumably you were down this path before. -- Cheers, Ralph. |
From: Matthias A. <mat...@gm...> - 2020-02-05 17:29:43
|
> Checked that "less secure" apps was still enabled. Did find some "security warnings" about suspicious access attempts and approved them. That did not resolve the issue. > > Many indications on the web that gmail is particularly reluctant to play nice with others. > > FWIW there are several accounts defined in the same fetchmailrc file at another provider that work just fine in the same fetch cycle. If Ralph's answer (try ssl) doesn't help, we're at the point where it boils down to the canned answer, please provide output per <https://www.fetchmail.info/fetchmail-FAQ.html#G3> and mask your passwords. Generally I'd say, however, that a timeout < 30 s might be fraught with problems. |
From: Joe Acquisto-j. <jo...@j4...> - 2020-02-05 19:10:08
|
>Checked that "less secure" apps was still enabled. Did find some "security > warnings" about suspicious access attempts and approved them. That did not > resolve the issue. >> >> Many indications on the web that gmail is particularly reluctant to play > nice with others. >> >> FWIW there are several accounts defined in the same fetchmailrc file at > another provider that work just fine in the same fetch cycle. > > If Ralph's answer (try ssl) doesn't help, we're at the point where it > boils down to the canned answer, please provide output per > <https://www.fetchmail.info/fetchmail-FAQ.html#G3> and mask your > passwords. Generally I'd say, however, that a timeout < 30 s might be > fraught with problems. > Well . . . oops? Don't know how I missed the port issue. At some point the "ssl" option was deleted from the user line. That resolved the connection failure. Working after a few fetch cycles and chasing a gmail issue. The ssl fingerprint seems to change, seemingly with what IP it happens to connect. While I do find almost immediate response when connecting (human eyeball time) I set the timeout to 30 for the moment. Thanks for the assistance, I'll look into improving the ssl business. joe a. |
From: Matthias A. <mat...@gm...> - 2020-02-05 20:08:50
|
Am 05.02.20 um 20:06 schrieb Joe Acquisto-j4: > Well . . . oops? Don't know how I missed the port issue. At some point the > "ssl" option was deleted from the user line. > > That resolved the connection failure. Working after a few fetch cycles and > chasing a gmail issue. The ssl fingerprint seems to change, seemingly with what > IP it happens to connect. SSL fingerprints are mostly non-workable for those of the big sites that use per-host certificates, and fetchmail won't let you list dozens, let a lone use a secure hash (it uses MD5). Be sure to install the Mozilla root certificates (most distributions have packages such as ca-certificates or nss_root_ca) that integrate with the default OpenSSL configuration such that the certificates can be verified automatically, do not use --sslfingerprint, do not use --nosslcertck (but do use --sslcertck on 6.3.x) and move on. > While I do find almost immediate response when connecting (human eyeball time) I suppose Google's non-SSL port (which would have had to use STARTTLS or possibly risked broken clients volunteering their password over unencrypted links) is firewalled and blackholes inbound traffic. And yes, Google isn't exactly following the IMAP RFCs (standards) to the letter, or even the traditional model of an IMAP server. |