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
(1) |
Nov
|
Dec
|
From: Matthias A. <mat...@gm...> - 2024-05-14 23:12:04
|
The 6.5.0.beta10 release of fetchmail is now available at the usual location, <https://downloads.sourceforge.net/project/fetchmail/branch_6.5/>. The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta10.tar.xz/download> The detached GnuPG signature is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.5/fetchmail-6.5.0.beta10.tar.xz.asc/download> The SHA256 hash for the tarball is: SHA2-256(fetchmail-6.5.0.beta10.tar.xz)= 1c818b87ccd6cde10b18e55bb30e2ce9dca9c4cc28be699fd436c4eab87ac636 ============================================================================ |
From: <rb...@al...> - 2024-05-14 17:14:37
|
FWIW I got an app password from Google years ago and had no trouble since. I still haven't figured out how to fetchmail from an Outlook server, which may be my incompetence. russell bell |
From: Matthias A. <mat...@gm...> - 2024-05-13 21:31:26
|
Am 11.05.24 um 15:40 schrieb Andrew C Aitchison: > > Executive Summary: > > Google Less Secure Apps (LSA) will be turned off in two stages: > Beginning June 15, 2024: > No new accounts > Beginning September 30, 2024: > Access to LSAs will be turned off for all Google Workspace > accounts. > > OAuth and App Password access to smtp/imap/pop etc. will continue. > > https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-le$ > > Yep. And all the while they are doing that, EC is considering if they want to ban calling apps "less secure" if whatever. I don't really care. Fetchmail isn't "less secure" because it doesn't bring the web browser that requires 100 security fixes every month, quite the contrary. We've had Kerberos/GSSAPI for ages. So then, app password access it will be. https://support.google.com/mail/answer/185833?hl=en&sjid=3175199933505007620-EU#app-passwords |
From: graeme v. <gra...@ve...> - 2024-05-12 21:23:48
|
>> >> It would be helpful in in verbose mode at least it indicated that the >> error was being ignored. Because I my case >> >> it failed right after that error and it was not immediately obvious >> that it had been ignored. Lost of time chasing the wrong error message. > > Sorry for that, yes, we can do that. Pushed to the Git branch that will > spawn a 6.5 release in the future in commit db0fd264, example output: > Thanks for that. Obviously I'm now "in the know" about that message but hopefully it will help the next guy in this situation. >>> If that persists with any version since and including 6.4.34, let me >>> know. The trace as posted looks as though the server had not replied to >>> UIDL at all (which I find strange because fetchmail should wait for a >>> reply before sending TOP 1 1 to get the header of the first message), >>> but I am not going to look into bugs of older versions. >>> >> OK, I was not seeing this as a "bug" ... I took it to mean "you need >> to use UIDL if you're using pop3+keep" > > > This is the standing recommendation and best current practice, yes, but > the log looks strange. Anyways, we're not going to dig this up. > > >> >> FYI Have a Trixie system which offers 6.4.38-1 ... the mailbox is >> one I'm using for testing ...so it has nothing sensitive (even the >> password) >> >> if you would like me to run a test? > > It's just that I lack time to dig up if that would be a bug in 6.4.16 > that I've fixed since. Or whoever compiled your version had compiler > bugs. My policy is to update. So if 6.4.38 shows similar client/server > synchronization errors, let me know, and please provide those logs with > -vv options to fetchmail. > > From memory I did not think there was a "bug" here, simply that e.g. the man page could point out if you have pop3+keep you MUST use uidl (or something like that). I believe what you are saying is, you may well see a bug, but this is an old version so you're , understandably, not willing to dig back that far. I was pointing out, that one of my systems runs 6.4.38-1 (which is new enough to be worth looking at?) . If it would be useful I can run a test on that ? 1: Would it be useful 2: what test would you like me to run? (is it pop3+keep and no uidl? ..with -vv , or something more specific) |
From: Andrew C A. <fet...@ai...> - 2024-05-11 14:00:19
|
On Sat, 11 May 2024, Andrew C Aitchison wrote: > Executive Summary: > > Google Less Secure Apps (LSA) will be turned off in two stages: > Beginning June 15, 2024: > No new accounts > Beginning September 30, 2024: > Access to LSAs will be turned off for all Google Workspace accounts. > > OAuth and App Password access to smtp/imap/pop etc. will continue. Oops. Cut and paste failure. The correct address is: https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-less-secure-apps-support.html?m=1 -- Andrew C. Aitchison Kendal, UK an...@ai... |
From: Andrew C A. <fet...@ai...> - 2024-05-11 13:53:04
|
Executive Summary: Google Less Secure Apps (LSA) will be turned off in two stages: Beginning June 15, 2024: No new accounts Beginning September 30, 2024: Access to LSAs will be turned off for all Google Workspace accounts. OAuth and App Password access to smtp/imap/pop etc. will continue. https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-le$ -- Andrew C. Aitchison Kendal, UK an...@ai... |
From: Matthias A. <mat...@gm...> - 2024-04-27 08:12:49
|
Am 23.04.24 um 22:30 schrieb Matthias Andree via Fetchmail-users: >> Apr 23 22:13:29 fetchmail: POP3< +OK send PASS >> Apr 23 22:13:29 fetchmail: POP3> PASS * >> Apr 23 22:13:29 fetchmail: POP3< +OK Welcome. >> Apr 23 22:13:29 fetchmail: POP3> STAT >> Apr 23 22:13:29 fetchmail: POP3< +OK 29 650667 >> Apr 23 22:13:29 fetchmail: POP3> LAST >> Apr 23 22:13:29 fetchmail: POP3< -ERR Not supported >> Apr 23 22:13:29 fetchmail: Not supported >> Apr 23 22:13:29 fetchmail: LAST is an obsolete command that many >> servers will not support. We will try modern means to find what >> messages are new. >> Apr 23 22:13:29 fetchmail: POP3> UIDL >> Apr 23 22:13:29 fetchmail: POP3< +OK >> Apr 23 22:13:29 fetchmail: POP3< 1 Id1516a57b9a0d4280 >> Apr 23 22:13:29 fetchmail: POP3< 2 Id1516a57ba7a71933 >> Apr 23 22:13:29 fetchmail: POP3< 3 Id1516a57bb8920733 > > I couldn't push this to sourceforge.net though (*), so only Gitlab > currently has it, see > https://gitlab.com/fetchmail/fetchmail/-/commit/db0fd264a85d11565b4abd20b0d7b6bbd4d77c23 I have now been able to push this to the Git repo on sourceforge.net, too. |
From: Matthias A. <mat...@gm...> - 2024-04-23 20:34:35
|
Am 09.04.24 um 16:18 schrieb Info: > Greeting all, > > How do I download Selected Remote Folder to Specific Local Folder > > For example: > Remote folder= INBOX.Sent > Local folder = INBOX/Sent > > > #========= fetchmail release =========# > > This is fetchmail release 6.4.37+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. > Compiled with SSL library 0x30000080 "OpenSSL 3.0.8 7 Feb 2023" > Run-time uses SSL library 0x300000b0 "OpenSSL 3.0.11 19 Sep 2023" > OpenSSL: OPENSSLDIR: "/usr/lib/ssl" > Engines: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3" > > > groups fetchmail > fetchmail : nogroup vmail postfix > > > cat /etc/default/fetchmail > START_DAEMON=yes > > > cat /etc/fetchmailrc > # /etc/fetchmailrc for system-wide daemon mode > # This file must be chmod 0600, owner fetchmail > # > set daemon 300 > set postmaster root > set no bouncemail > set no spambounce > set no syslog > set logfile "/var/log/fetchmail.log" > # > ########## mail.domain.com ########## > poll mail.domain.com protocol imap > user us...@do... there with password XXyyXXyy > is us...@do...n here This has set up fetchmail to forward via SMTP, totally ignoring LMTP servers. > keep ssl > norewrite > preconnect "date >> /var/log/fetchmail.log" > > > > #========= my lmtp sockets =========# > > In order do deliver emails from a selected remote folder to a specific > local folder one has to use the MDA parameter. > > How and which MDA? This is outside fetchmail's scope and a mail filtering thing on the receiving end. You may want to consult Dovecot's documentation, dovecot-lda in particular. |
From: Matthias A. <mat...@gm...> - 2024-04-23 20:30:56
|
Am 16.02.24 um 17:58 schrieb graeme vetterlein: > > On 14/02/2024 21:10, Matthias Andree via Fetchmail-users wrote: >> Am 13.02.24 um 22:34 schrieb graeme vetterlein: >>> The last "other person" email I saw was 29 Jan .. >>> >>> I saw my own mail come back to me on 7th feb ... but no response. >> >> >> That can happen without your dropping off the list. >> >> People get distracted, go on business trips, have week-end plans, >> whatever. Else show your support contract to claim service :-) >> >> > I wasn't complaining ...it just looked a little odd (and I have > dropped off other lists) ...I sent a email, I immediately > > got a response (an echo of my mail) what I expected next was it would > appear again in a "summary" (I don't' recall my "sign up" options, > but usually I opt to get a weekly summary email not "live" every email > as soon as it' sent) ... is this not how this mailing list works? There was a lot of churn in my mail logs quite a while ago and I have added a greylisting feature to it. I won't tell too much about the details, but the bottom line is if you haven't mailed the list in a long time (nobody has), the delivering mail server gets temporarily refused initially and has to come back for a retry, which all properly functioning mail relays do, but spammers sometimes do not, and there is some time for them to appear on real-time blacklist. This causes a delay of several minutes, which will not occur on subsequent messages using the same sender:destination relation in a certain time frame. Also, the list driver software is mailman 2, and it won't just boot you from the list, but only if your messages and certain subsequent probe messages keep causing undeliverable notices on several distinct days afterwards. > > It would be helpful in in verbose mode at least it indicated that the > error was being ignored. Because I my case > > it failed right after that error and it was not immediately obvious > that it had been ignored. Lost of time chasing the wrong error message. Sorry for that, yes, we can do that. Pushed to the Git branch that will spawn a 6.5 release in the future in commit db0fd264, example output: > Apr 23 22:13:29 fetchmail: POP3< +OK send PASS > Apr 23 22:13:29 fetchmail: POP3> PASS * > Apr 23 22:13:29 fetchmail: POP3< +OK Welcome. > Apr 23 22:13:29 fetchmail: POP3> STAT > Apr 23 22:13:29 fetchmail: POP3< +OK 29 650667 > Apr 23 22:13:29 fetchmail: POP3> LAST > Apr 23 22:13:29 fetchmail: POP3< -ERR Not supported > Apr 23 22:13:29 fetchmail: Not supported > Apr 23 22:13:29 fetchmail: LAST is an obsolete command that many > servers will not support. We will try modern means to find what > messages are new. > Apr 23 22:13:29 fetchmail: POP3> UIDL > Apr 23 22:13:29 fetchmail: POP3< +OK > Apr 23 22:13:29 fetchmail: POP3< 1 Id1516a57b9a0d4280 > Apr 23 22:13:29 fetchmail: POP3< 2 Id1516a57ba7a71933 > Apr 23 22:13:29 fetchmail: POP3< 3 Id1516a57bb8920733 I couldn't push this to sourceforge.net though (*), so only Gitlab currently has it, see https://gitlab.com/fetchmail/fetchmail/-/commit/db0fd264a85d11565b4abd20b0d7b6bbd4d77c23 > (*) ssh: connect to host git.code.sourceforge.net port 22: Connection > timed out >>> >>> The full set of messages I originally got: >>> >>> >>> fetchmail: POP3> STAT >>> fetchmail: POP3< +OK 2 12792 >>> fetchmail: POP3> LAST >>> fetchmail: POP3< -ERR bad command >>> fetchmail: bad command >>> fetchmail: POP3> UIDL >>> fetchmail: POP3> TOP 1 1 >>> fetchmail: protocol error while fetching UIDLs >>> fetchmail: POP3> QUIT >>> fetchmail: client/server synchronization error while fetching from >>> gr...@ma...@pop3.my.provider.net >>> fetchmail: 6.4.16 querying pop3.my.provider.net (protocol POP3) at Tue >>> 13 Feb 2024 16:59:19 GMT: poll completed >> >> If that persists with any version since and including 6.4.34, let me >> know. The trace as posted looks as though the server had not replied to >> UIDL at all (which I find strange because fetchmail should wait for a >> reply before sending TOP 1 1 to get the header of the first message), >> but I am not going to look into bugs of older versions. >> > OK, I was not seeing this as a "bug" ... I took it to mean "you need > to use UIDL if you're using pop3+keep" This is the standing recommendation and best current practice, yes, but the log looks strange. Anyways, we're not going to dig this up. > > FYI Have a Trixie system which offers 6.4.38-1 ... the mailbox is > one I'm using for testing ...so it has nothing sensitive (even the > password) > > if you would like me to run a test? It's just that I lack time to dig up if that would be a bug in 6.4.16 that I've fixed since. Or whoever compiled your version had compiler bugs. My policy is to update. So if 6.4.38 shows similar client/server synchronization errors, let me know, and please provide those logs with -vv options to fetchmail. |
From: Info <in...@wc...> - 2024-04-09 14:43:07
|
Greeting all, How do I download Selected Remote Folder to Specific Local Folder For example: Remote folder= INBOX.Sent Local folder = INBOX/Sent #========= fetchmail release =========# This is fetchmail release 6.4.37+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. Compiled with SSL library 0x30000080 "OpenSSL 3.0.8 7 Feb 2023" Run-time uses SSL library 0x300000b0 "OpenSSL 3.0.11 19 Sep 2023" OpenSSL: OPENSSLDIR: "/usr/lib/ssl" Engines: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3" groups fetchmail fetchmail : nogroup vmail postfix cat /etc/default/fetchmail START_DAEMON=yes cat /etc/fetchmailrc # /etc/fetchmailrc for system-wide daemon mode # This file must be chmod 0600, owner fetchmail # set daemon 300 set postmaster root set no bouncemail set no spambounce set no syslog set logfile "/var/log/fetchmail.log" # ########## mail.domain.com ########## poll mail.domain.com protocol imap user us...@do... there with password XXyyXXyy is us...@do...n here keep ssl norewrite preconnect "date >> /var/log/fetchmail.log" #========= my lmtp sockets =========# unix 2 [ ACC ] STREAM LISTENING 377089 private/lmtp unix 2 [ ACC ] STREAM LISTENING 377202 /var/spool/postfix/private/dovecot-lmtp unix 2 [ ACC ] STREAM LISTENING 377199 /run/dovecot/lmtp #========= my Dovecot lmtp service =========# service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } inet_listener lmtp { address = 127.0.0.1 port = 24 } #========= my ISP IMAP =========# A001 OK You are so in n namespace * NAMESPACE (("INBOX." ".")) NIL NIL n OK Namespace completed (0.001 + 0.000 secs). A002 list "INBOX." "*" * LIST (\HasNoChildren \Trash) "." INBOX.Trash * LIST (\HasNoChildren \Junk) "." INBOX.spambucket * LIST (\HasNoChildren \Sent) "." INBOX.Sent * LIST (\HasNoChildren \Drafts) "." INBOX.Drafts * LIST (\HasNoChildren) "." INBOX.Templates A002 OK List completed (0.001 + 0.000 secs). #========= my local IMAP =========# * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot (Debian) ready. a01 OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY PREVIEW STATUS=SIZE SAVEDATE LITERAL+ NOTIFY SPECIAL-USE ACL RIGHTS=texk] Logged in n namespace * NAMESPACE (("" "/")) NIL NIL n OK Namespace completed (0.001 + 0.000 secs). a02 LIST "" "*" * LIST (\HasNoChildren \Trash) "/" Trash * LIST (\HasNoChildren \Junk) "/" Junk * LIST (\HasNoChildren \Archive) "/" Archive * LIST (\HasNoChildren \Sent) "/" "Sent Messages" * LIST (\HasNoChildren \Sent) "/" Sent * LIST (\HasNoChildren \Drafts) "/" Drafts * LIST (\HasNoChildren) "/" INBOX a02 OK List completed (0.001 + 0.000 secs). a03 LIST "INBOX" "*" * LIST (\HasNoChildren) "/" INBOX a03 OK List completed (0.001 + 0.000 secs). A04 SELECT "INBOX" * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 0 EXISTS * 0 RECENT * OK [UIDVALIDITY 1712661597] UIDs valid * OK [UIDNEXT 1] Predicted next UID A04 OK [READ-WRITE] Select completed (0.001 + 0.000 secs). a05 LOGOUT * BYE Logging out a05 OK Logout completed (0.001 + 0.000 secs). In order do deliver emails from a selected remote folder to a specific local folder one has to use the MDA parameter. How and which MDA? Thanks very much in advance Jan |
From: graeme v. <gra...@ve...> - 2024-02-16 16:58:58
|
On 14/02/2024 21:10, Matthias Andree via Fetchmail-users wrote: > Am 13.02.24 um 22:34 schrieb graeme vetterlein: >> The last "other person" email I saw was 29 Jan .. >> >> I saw my own mail come back to me on 7th feb ... but no response. > > > That can happen without your dropping off the list. > > People get distracted, go on business trips, have week-end plans, > whatever. Else show your support contract to claim service :-) > > I wasn't complaining ...it just looked a little odd (and I have dropped off other lists) ...I sent a email, I immediately got a response (an echo of my mail) what I expected next was it would appear again in a "summary" (I don't' recall my "sign up" options, but usually I opt to get a weekly summary email not "live" every email as soon as it' sent) ... is this not how this mailing list works? >> fetchmail: POP3> LAST >> fetchmail: POP3< -ERR bad command >> fetchmail: bad command >> >> >> It seems this is "expected" ... it would be nice if the verbose log >> added that info "LAST is often not supported, it's OK" > > I am not sure if fetchmail should lecture people on defunct/superseded > versions of the standard (RFC-1460), this is a compatibility hack that > is quite assuming... and LAST was removed 30 years ago, for good > reasons. Arguably we should probably remove the remnants in the code. > For robustness, it's either UIDL or "take it all". It should be clear > from fetchmail's not reporting an error and continuing that it is up to > more useful protocol things. > Well I guess in the code there is some logic of the the form if (0 != ( rc=do_operation())) { if (condition(op, rc) == FATAL ...die else ..carry on } It would be helpful in in verbose mode at least it indicated that the error was being ignored. Because I my case it failed right after that error and it was not immediately obvious that it had been ignored. Lost of time chasing the wrong error message. >> >> The full set of messages I originally got: >> >> >> fetchmail: POP3> STAT >> fetchmail: POP3< +OK 2 12792 >> fetchmail: POP3> LAST >> fetchmail: POP3< -ERR bad command >> fetchmail: bad command >> fetchmail: POP3> UIDL >> fetchmail: POP3> TOP 1 1 >> fetchmail: protocol error while fetching UIDLs >> fetchmail: POP3> QUIT >> fetchmail: client/server synchronization error while fetching from >> gr...@ma...@pop3.my.provider.net >> fetchmail: 6.4.16 querying pop3.my.provider.net (protocol POP3) at Tue >> 13 Feb 2024 16:59:19 GMT: poll completed > > If that persists with any version since and including 6.4.34, let me > know. The trace as posted looks as though the server had not replied to > UIDL at all (which I find strange because fetchmail should wait for a > reply before sending TOP 1 1 to get the header of the first message), > but I am not going to look into bugs of older versions. > OK, I was not seeing this as a "bug" ... I took it to mean "you need to use UIDL if you're using pop3+keep" FYI Have a Trixie system which offers 6.4.38-1 ... the mailbox is one I'm using for testing ...so it has nothing sensitive (even the password) if you would like me to run a test? > > > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users |
From: Matthias A. <mat...@gm...> - 2024-02-14 21:10:21
|
Am 13.02.24 um 22:34 schrieb graeme vetterlein: > The last "other person" email I saw was 29 Jan .. > > I saw my own mail come back to me on 7th feb ... but no response. That can happen without your dropping off the list. People get distracted, go on business trips, have week-end plans, whatever. Else show your support contract to claim service :-) > There are a few interesting "gotchas" along the way which may be of > interest. > > > Using -vv : > > > fetchmail: POP3> LAST > fetchmail: POP3< -ERR bad command > fetchmail: bad command > > > It seems this is "expected" ... it would be nice if the verbose log > added that info "LAST is often not supported, it's OK" I am not sure if fetchmail should lecture people on defunct/superseded versions of the standard (RFC-1460), this is a compatibility hack that is quite assuming... and LAST was removed 30 years ago, for good reasons. Arguably we should probably remove the remnants in the code. For robustness, it's either UIDL or "take it all". It should be clear from fetchmail's not reporting an error and continuing that it is up to more useful protocol things. > > The full set of messages I originally got: > > > fetchmail: POP3> STAT > fetchmail: POP3< +OK 2 12792 > fetchmail: POP3> LAST > fetchmail: POP3< -ERR bad command > fetchmail: bad command > fetchmail: POP3> UIDL > fetchmail: POP3> TOP 1 1 > fetchmail: protocol error while fetching UIDLs > fetchmail: POP3> QUIT > fetchmail: client/server synchronization error while fetching from > gr...@ma...@pop3.my.provider.net > fetchmail: 6.4.16 querying pop3.my.provider.net (protocol POP3) at Tue > 13 Feb 2024 16:59:19 GMT: poll completed If that persists with any version since and including 6.4.34, let me know. The trace as posted looks as though the server had not replied to UIDL at all (which I find strange because fetchmail should wait for a reply before sending TOP 1 1 to get the header of the first message), but I am not going to look into bugs of older versions. |
From: graeme v. <gra...@ve...> - 2024-02-13 21:34:31
|
The last "other person" email I saw was 29 Jan .. I saw my own mail come back to me on 7th feb ... but no response. I've made a little progress . I tried using pop3 (instead of imap) and it's working much more as I would like. My most recent settings are: poll pop3.my.provider.net tracepolls with proto POP3 uidl user 'gr...@ma...' there with password 'XXXXX' is 'graeme' here options ssl sslproto "auto" keep fastuidl 24 mda "/usr/bin/maildrop -d graeme" There are a few interesting "gotchas" along the way which may be of interest. Using -vv : fetchmail: POP3> LAST fetchmail: POP3< -ERR bad command fetchmail: bad command It seems this is "expected" ... it would be nice if the verbose log added that info "LAST is often not supported, it's OK" The full set of messages I originally got: fetchmail: POP3> STAT fetchmail: POP3< +OK 2 12792 fetchmail: POP3> LAST fetchmail: POP3< -ERR bad command fetchmail: bad command fetchmail: POP3> UIDL fetchmail: POP3> TOP 1 1 fetchmail: protocol error while fetching UIDLs fetchmail: POP3> QUIT fetchmail: client/server synchronization error while fetching from gr...@ma...@pop3.my.provider.net fetchmail: 6.4.16 querying pop3.my.provider.net (protocol POP3) at Tue 13 Feb 2024 16:59:19 GMT: poll completed ...so you can see why the "bad command" looked like an issue, it immediately preceded the failure. This was "fixed" by adding the option uidl (and later fastuidl 24) as shown above. My understanding was without the uidl option, it would have possibly got the "wrong" mails ...ie ones that another client had read , I did not understand it would actually fail. -- Graeme |
From: graeme v. <gra...@ve...> - 2024-02-05 17:27:58
|
All, I'm trying to achieve something using fetchmail and I seem to rather "swimming against the tide". I wonder if a different approach is in order. I run an SMTP server @ home (actually called smtp.home [via CNAME] ) and I have recently rented use of smtp.remote (not it's real name) Stage1: I did fetchmail(imap) every 5 minutes of smtp.remote (using fetchall option) and delivered to smtp.home People then read email via Thunderbird via imap to imap.home (dovecot access to local files) All works well, but you can only send and receive email while you can "see" smtp.home (so on local LAN ... no holes in firewall) So Stage2: Do the fetchmail(imap) less frequently (e.g. daily) and use the keep option (and no fetchall) Users can now imap to both imap.home and imap.remote and see similar (but more or less up to date) views. They can also send mail from both locations. Stage3: Delete mail from imap.remote older than say 1 year Now "recent email" is on imap.remote while historic is held on imap.home, there is significant overlap. The idea being , when you're out "on the road" you lack access to history but you can deal with current day-to-day issues using a phone. ================ Problems ============= 1: Getting copies of "Sent" mail from imap.remote ... Solved using maildrop(1) ...needed to save by sender not recipient 2: Mail in inbox at imap.remote that had been "read" by "a phone" , was not downloaded by fetchmail(imap)....Looks like the rule for --keep and "no fetchall" is only download stuff not already "seen" by **somebody**. What I really want of course is "stuff not already seen by **me**". Now I note from uidl.c that pop3 does this differently...should I pop the mail to achieve the desired effect ... bear in mind I'd be skipping a years worth of mail to read one message? ...I guess I'm looking for a "cursor" to mark where "I" have downloaded to ... so e.g. multiple clients could "mark their place" and download ...anything after message No XXX. |
From: Matthias A. <mat...@gm...> - 2024-01-31 21:05:15
|
Note that the shipped NEWS file in the tarball and this release message claim fetchmail-6.4.38 were "not yet released", but I have released iti today intentionally, not by accident. That line should have read instead: "fetchmail-6.4.38 (released 2024-01-31, 31720 LoC)" and has been pushed with a GnuPG-signed tag to the Git repos, https://gitlab.com/fetchmail/fetchmail and https://sourceforge.net/p/fetchmail/git/ci/legacy_64/tree/ Am Wed, Jan 31, 2024 at 10:00:33PM +0100 schrieb Matthias Andree: > The 6.4.38 release of fetchmail is now available at the usual locations, > including <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. > > The source archive is available at: > <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.xz/download> > <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.lz/download> > > The detached GnuPG signature is available at: > <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.xz.asc/download> > <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.lz.asc/download> > > The SHA256 hashes for the tarballs are: > SHA2-256(fetchmail-6.4.38.tar.xz)= a6cb4ea863ac61d242ffb2db564a39123761578d3e40d71ce7b6f2905be609d9 > SHA2-256(fetchmail-6.4.38.tar.lz)= be82b520d9698c1378c3a9a4dbab4d392c8c90d457af11a97ce9b85a3fedc70a > > > Here are the release notes: > -------------------------------------------------------------------------------- > fetchmail-6.4.38 (not yet released): > > # BREAKING CHANGES: > * Tighten OpenSSL and wolfSSL version requirements again. See README.SSL. > Distributors providing older versions that they backport security fixes for > may want to patch socket.c but remember to redirect support to your > distribution's support channels. > The fetchmail maintainer only supports functionally unmodified builds with > publicly available SSL/TLS library versions. > fetchmail will refuse to build against OpenSSL 1.0.2 older than 1.0.2u, > or wolfSSL older than 5.6.2. It will warn about OpenSSL older than 3.0.9, > or between 3.1.0 and 3.1.4, or wolfSSL older than 5.6.6. > > # TRANSLATIONS: language translations were updated by these fine people: > (in reverse alphabetical order of language codes): > * ru: Kirill Isakov [Russian] > * eo: Keith Bowes [Esperanto] > > -------------------------------------------------------------------------------- |
From: Matthias A. <mat...@gm...> - 2024-01-31 21:00:50
|
The 6.4.38 release of fetchmail is now available at the usual locations, including <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. The source archive is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.xz/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.lz/download> The detached GnuPG signature is available at: <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.xz.asc/download> <https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.38.tar.lz.asc/download> The SHA256 hashes for the tarballs are: SHA2-256(fetchmail-6.4.38.tar.xz)= a6cb4ea863ac61d242ffb2db564a39123761578d3e40d71ce7b6f2905be609d9 SHA2-256(fetchmail-6.4.38.tar.lz)= be82b520d9698c1378c3a9a4dbab4d392c8c90d457af11a97ce9b85a3fedc70a Here are the release notes: -------------------------------------------------------------------------------- fetchmail-6.4.38 (not yet released): # BREAKING CHANGES: * Tighten OpenSSL and wolfSSL version requirements again. See README.SSL. Distributors providing older versions that they backport security fixes for may want to patch socket.c but remember to redirect support to your distribution's support channels. The fetchmail maintainer only supports functionally unmodified builds with publicly available SSL/TLS library versions. fetchmail will refuse to build against OpenSSL 1.0.2 older than 1.0.2u, or wolfSSL older than 5.6.2. It will warn about OpenSSL older than 3.0.9, or between 3.1.0 and 3.1.4, or wolfSSL older than 5.6.6. # TRANSLATIONS: language translations were updated by these fine people: (in reverse alphabetical order of language codes): * ru: Kirill Isakov [Russian] * eo: Keith Bowes [Esperanto] -------------------------------------------------------------------------------- |
From: Matthias A. <mat...@gm...> - 2024-01-31 18:48:46
|
Am 29.01.24 um 17:49 schrieb Michael Burgoon: > Thanks very much Lucio. I reran fetchmail with your debug args and got the following output. the IPA for my internal mail server is 192.168.1.111 and that this the address that my router port forwards to. I do not have anything located at 192.168.1.203, the spa that is causing the error, so I’m at a loss as to why fetchmail now, all of a sudden, has decided to use that address for my internal mail/smtp server. > Question: where does fetchmail get that address to query? Wherever it is, it’s getting the wrong ipa. > > Thanks for anyone’s additional assistance. > > Mike B > > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > mburgoon@mbdiskstation:/opt/etc/init.d$ sudo /opt/bin/fetchmail -vvv --nodetach --nosyslog -f /opt/etc/fetchmailrc > Password: > fetchmail: WARNING: Running as root is discouraged. > gethostbyname failed for mbdiskstation > Name or service not knownCannot find my own host in hosts database to qualify it! > Trying to continue with unqualified hostname. > DO NOT report broken Received: headers, HELO/EHLO lines or similar problems! > DO repair your /etc/hosts, DNS, NIS or LDAP instead. Mike, ^ these warnings you quoted above are relevant. The host running fetchmail needs fixing. Also, your fetchmail is nine years old. Who is maintaining the software and providing bug fixes? What software is it? Some NAS? > [...] > Trying to connect to 192.168.1.203/25...connection failed. > fetchmail: connection to localhost:smtp [192.168.1.203/25] failed: No route to host. Why does your mail server believe that "localhost" has address 192.168.1.203? You write you don't have something there (that's what you intend), but your host running fetchmail that localhost isn't 127.0.0.1 (or possibly 127.0.1.1 on some systems), but 192.168.1.203, which is non-standard and probably part of the problem you are posing. This is an issue on your operating system on the fetchmail host - and you need to find out where that address comes from. Check your /etc/hosts on the host running fetchmail, and local name servers if any (including on your router). You may find out with (as root): grep -r 192.168.1.203 /etc Also, you did not tell fetchmail to your internal mail server - there is no smtphost argument or similar which would mention that 192.168.1.111 that you intend to use. Where you did intend this to happen? > # Edit carefully, see the fetchmail(1) manual page, section "THE RUN CONTROL FILE". > > poll pop.earthlink.net proto pop3 localdomains mindspring.com user"mbu...@mi..." password “XXXXXXXX", is "mbu...@mb...” here |
From: Michael B. <mbu...@mi...> - 2024-01-29 16:49:35
|
Thanks very much Lucio. I reran fetchmail with your debug args and got the following output. the IPA for my internal mail server is 192.168.1.111 and that this the address that my router port forwards to. I do not have anything located at 192.168.1.203, the spa that is causing the error, so I’m at a loss as to why fetchmail now, all of a sudden, has decided to use that address for my internal mail/smtp server. Question: where does fetchmail get that address to query? Wherever it is, it’s getting the wrong ipa. Thanks for anyone’s additional assistance. Mike B ++++++++++++++++++++++++++++++++++++++++++++++++++++ mburgoon@mbdiskstation:/opt/etc/init.d$ sudo /opt/bin/fetchmail -vvv --nodetach --nosyslog -f /opt/etc/fetchmailrc Password: fetchmail: WARNING: Running as root is discouraged. gethostbyname failed for mbdiskstation Name or service not knownCannot find my own host in hosts database to qualify it! Trying to continue with unqualified hostname. DO NOT report broken Received: headers, HELO/EHLO lines or similar problems! DO repair your /etc/hosts, DNS, NIS or LDAP instead. Old UID list from pop.earthlink.net: <empty> Scratch list of UIDs: <empty> fetchmail: 6.3.26 querying pop.earthlink.net (protocol POP3) at Mon, 29 Jan 2024 16:34:57 +0000 (UTC): poll started Trying to connect to 24.41.66.181/110...connected. fetchmail: POP3< +OK NGPopper vEL_0_1_42_MP_1_P at earthlink.net ready <208...@mp...> fetchmail: POP3> CAPA fetchmail: POP3< +OK fetchmail: POP3< apop fetchmail: POP3< pass fetchmail: POP3< top fetchmail: POP3< uidl fetchmail: POP3< user fetchmail: POP3< . fetchmail: POP3> USER mbu...@mi... fetchmail: POP3< +OK Pass required for mbu...@mi... fetchmail: POP3> PASS * fetchmail: POP3< +OK mburgoon has 25 messages (35879814 octets). fetchmail: selecting or re-polling default folder fetchmail: POP3> STAT fetchmail: POP3< +OK 25 35879814 fetchmail: POP3> LAST fetchmail: POP3< +OK 0 25 messages for mbu...@mi... at pop.earthlink.net (35879814 octets). fetchmail: POP3> LIST 1 fetchmail: POP3< +OK 1 19510 fetchmail: POP3> TOP 1 99999999 fetchmail: POP3< +OK reading message mbu...@mi...@pop.earthlink.net:1 of 25 (19510 octets) About to rewrite Return-Path: <bounce+f5af3c.44e7ac-mburgoon=min...@mg...>... ...rewritten version is Return-Path: <bounce+f5af3c.44e7ac-mburgoon=min...@mg...>. About to rewrite Sender: reply=tvi...@mg...... ...rewritten version is Sender: reply=tvi...@mg.... About to rewrite From: Jerrys Leesburg Chevrolet <re...@tv...>... ...rewritten version is From: Jerrys Leesburg Chevrolet <re...@tv...>. About to rewrite To: mbu...@mi...... ...rewritten version is To: mbu...@mi.... Trying to connect to 192.168.1.203/25...connection failed. fetchmail: connection to localhost:smtp [192.168.1.203/25] failed: No route to host. fetchmail: Connection errors for this poll: name 0: connection to localhost:smtp [192.168.1.203/25] failed: No route to host. fetchmail: SMTP connect to localhost failed fetchmail: POP3> QUIT fetchmail: POP3< <!DOCTYPE html> fetchmail: SMTP transaction error while fetching from mbu...@mi...@pop.earthlink.net and delivering to SMTP host localhost fetchmail: 6.3.26 querying pop.earthlink.net (protocol POP3) at Mon, 29 Jan 2024 16:35:01 +0000 (UTC): poll completed Merged UID list from pop.earthlink.net: <empty> fetchmail: Query status=10 (SMTP) fetchmail: normal termination, status 10 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FETCHMAILRC # Edit carefully, see the fetchmail(1) manual page, section "THE RUN CONTROL FILE". poll pop.earthlink.net proto pop3 localdomains mindspring.com user "mbu...@mi..." password “XXXXXXXX", is "mbu...@mb...” here +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Jan 27, 2024, at 8:09 AM, Lucio Chiappetti <lu...@la...> wrote: On Fri, 26 Jan 2024, Michael Burgoon wrote: > explain where the following statements go: > > The output of env LC_ALL=C fetchmail -V called with whatever other command-line options you used. > The output of env LC_ALL=C fetchmail --nodetach -vvv --nosyslog with whatever other command-line options you use routinely. The statements shall be issued from a terminal emulator (xterm, console etc.). It depends how you call procmail (as a daemon, or via crontab, whether you use .fetchmailrc or a custom .fetchmailrc.SOMETHING (for instance I had two (now three) different .fetchmailrc.SOMETHING fopr different servers, and call by crontab at different frequencies. If I wanto to debug a particular .fetchmailrc.SOMETHING fetchmail -V -v --nodetach --nosyslog -f /path/to/.fetchmailrc.SOMETHING will analyse the .fetchmailrc.SOMETHING for syntax errors (and do nothing) fetchmail -vvv --nodetach --nosyslog -f /path/to/.fetchmailrc.SOMETHING will executw it and produce verbose diagnostic messages. It's all written in the man pages (where I found it recently when I needed to make checks for a new server) -- Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ A middle rank researcher at end career is not rich but is in the top 5% of the Italian income tax taxpayers. Does it not sound strange ? |
From: <gra...@ve...> - 2024-01-27 14:12:40
|
OK, part way there.... On 22/01/2024 12:41, Mihai Lazarescu wrote: > On Monday, January 22, 2024 at 10:54:07 +0000, graeme vetterlein: > >> I'd like to setup something for the whole household (Family) as I >> know for a >> fact they never organise their historic email :-) and I don't want >> their junk >> using my whole allocation > > I'm a mutt user :-) and I'm pretty sure that it allows creating a > script that automatically selects, deletes and purges messages older > than 1 year (~d >1y) for each account in sequence, which you can then > run periodically (interactively or cron). > So I think I plan to knock up a small python script that runs monthly and just deletes any mail older than 12 months. Working it though it however leaves another little "kink" ... 1: I download inbox say once a day (with --keep) 2: I run the delete python script once a month (leaves a year online) So now I have 12 months online and everything up to today on "local" (e.g. /var/mail/myuser) If I want to send *while I'm at home*, I use a *local SMTP* server and a copy of the outgoing mail gets saved in local-IMAPed-directory/Sent While I'm "on the road" I can view recent (year) mails via imap to "online provider". However if I send an email, while I'm out I'll need to use online_provider.SMTP a copy will need to be saved in online_provider-IMAPed-directory/Sent So my *outgoing mail is saved in 2 different places* depending on where I was when I sent it. The obvious solution would be to run fetchmail+imap on online_provider-IMAPed-directory/Sent ... However, this seems odd, for example, what would I do with it? If I pass it to local sendmail its going to send it to the original "TO:" header again ... when really it just needs to go into ~/mail/Sent (or similar) . If it's not going though sendmail, then I really should be doing some locking? (now I know "Sent" is a function of the MUA (Thunderbird) not the MTA ..but while I'm out of the house ~/mail/Sent is inaccessible . (while online_provider-IMAPed-directory/Sent is available) -- Graeme |
From: Lucio C. <lu...@la...> - 2024-01-27 13:09:33
|
On Fri, 26 Jan 2024, Michael Burgoon wrote: > explain where the following statements go: > > The output of env LC_ALL=C fetchmail -V called with whatever other command-line options you used. > The output of env LC_ALL=C fetchmail --nodetach -vvv --nosyslog with whatever other command-line options you use routinely. The statements shall be issued from a terminal emulator (xterm, console etc.). It depends how you call procmail (as a daemon, or via crontab, whether you use .fetchmailrc or a custom .fetchmailrc.SOMETHING (for instance I had two (now three) different .fetchmailrc.SOMETHING fopr different servers, and call by crontab at different frequencies. If I wanto to debug a particular .fetchmailrc.SOMETHING fetchmail -V -v --nodetach --nosyslog -f /path/to/.fetchmailrc.SOMETHING will analyse the .fetchmailrc.SOMETHING for syntax errors (and do nothing) fetchmail -vvv --nodetach --nosyslog -f /path/to/.fetchmailrc.SOMETHING will executw it and produce verbose diagnostic messages. It's all written in the man pages (where I found it recently when I needed to make checks for a new server) -- Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ A middle rank researcher at end career is not rich but is in the top 5% of the Italian income tax taxpayers. Does it not sound strange ? |
From: Michael B. <mbu...@mi...> - 2024-01-26 15:30:40
|
Greeting Matthias, I would like to provlde the info specified in the referenced document, please explain where the following statements go: The output of env LC_ALL=C fetchmail -V called with whatever other command-line options you used. The output of env LC_ALL=C fetchmail --nodetach -vvv --nosyslog with whatever other command-line options you use routinely. On Jan 25, 2024, at 7:48 PM, Matthias Andree via Fetchmail-users <fet...@li...> wrote: Am 25.01.24 um 19:43 schrieb Michael Burgoon: > Been using Fecthmail for years to pull mail down from EarthLink.net. It’s worked fine for years, now all of a sudden it just stopped working. Checked to make sure nothing changed on my end, so it’s something at the other end. Anyone know if Earthlink has adjusted anything that would affect this? > > fetchmailrc poll command: > > poll pop.earthlink.net proto pop3 localdomains mindspring.com user "mbu...@mi..." password “XXXXXXXXX", is "mbu...@mb...” here https://www.fetchmail.info/fetchmail-FAQ.html#G3 _______________________________________________ Fetchmail-users mailing list Fet...@li... https://lists.sourceforge.net/lists/listinfo/fetchmail-users |
From: Matthias A. <mat...@gm...> - 2024-01-26 00:48:21
|
Am 25.01.24 um 19:43 schrieb Michael Burgoon: > Been using Fecthmail for years to pull mail down from EarthLink.net. It’s worked fine for years, now all of a sudden it just stopped working. Checked to make sure nothing changed on my end, so it’s something at the other end. Anyone know if Earthlink has adjusted anything that would affect this? > > fetchmailrc poll command: > > poll pop.earthlink.net proto pop3 localdomains mindspring.com user "mbu...@mi..." password “XXXXXXXXX", is "mbu...@mb...” here https://www.fetchmail.info/fetchmail-FAQ.html#G3 |
From: Michael B. <mbu...@mi...> - 2024-01-25 18:59:02
|
Been using Fecthmail for years to pull mail down from EarthLink.net. It’s worked fine for years, now all of a sudden it just stopped working. Checked to make sure nothing changed on my end, so it’s something at the other end. Anyone know if Earthlink has adjusted anything that would affect this? fetchmailrc poll command: poll pop.earthlink.net proto pop3 localdomains mindspring.com user "mbu...@mi..." password “XXXXXXXXX", is "mbu...@mb...” here Thanks, Mike B |
From: Andrew C A. <fet...@ai...> - 2024-01-23 07:45:11
|
https://support.google.com/a/answer/6260879 suggests that less secure apps are still going away. On Mon, 22 Jan 2024, Lucio Chiappetti wrote: > I have recently received a message that I *SHALL* move to 2 > Factor Authentication in Gsuite, and, as I suspected, this broke > my arrangement (which exists sicne years and years) and I took > my counter-measures, and I wish to share. > > In a nutshell what I wanted to achieve and what I did is: > > (1) I want to have mail stored locally on my machine, and to > have > incoming mails processed by procmail (this is not just for > my fun, > I have a couple of cases where procmail post-processes mail > from > forms to update a local database for service reasons). > > (2) The simplest way to feed incoming mails into procmail is to > use > fetchmail, which I am happily using since 2018, when my > institution > moved from howgrown sendmail to Gsuite > > (3) The simplest way to have fetchmail working (after I > activated > 2FA on Gsuite fetchmail was not authenticateds) is to > "bypass" Gmail, > i.e. instruct Gsuite to forward all mail to another > provider which > provides *standard* IMAP. > > This solves 98% of my problems, because > > - Spam is not forwarded from Gmail to the alternate > provider > - messages forwrded *and deleted* are not actually deleted > but staged in Gmail's Bin for 30 days > > (4) The solution is ... "app passwords". Gmail with 2FA allows > to > define a 16-char password THEY generate to be used with > what in > the past were called provocatorily "less secure > applications" > > So I generated such an "app passwords" and I can use it > from my > preferred mail client (Alpine). And this solves my problem. > > (5) Actually the same app password can work also with > fetchmail, > so in theory I would not need the alternate provider of > point (3) and > could work "as previously", but I left it in. > > I had no need to move to OAUTH2, or learn it, or get an > OAUTH2-capable version of fetchmail (I use the OS-bundled one). > > I think I could be happy with the new arrangement. > > I hope the above is useful to somebody else. -- Andrew C. Aitchison Kendal, UK an...@ai... |
From: Mihai L. <mt...@gm...> - 2024-01-22 19:04:09
|
For pretty much the same setup (fetchmail, procmail, and mutt), I found that the Email OAuth 2.0 Proxy https://github.com/simonrob/email-oauth2-proxy was very easy to blend in. Best, Mihai On Monday, January 22, 2024 at 16:39:54 +0100, Lucio Chiappetti: > I have recently received a message that I *SHALL* move to 2 Factor > Authentication in Gsuite, and, as I suspected, this broke my > arrangement (which exists sicne years and years) and I took my > counter-measures, and I wish to share. > > In a nutshell what I wanted to achieve and what I did is: > > (1) I want to have mail stored locally on my machine, and to have > incoming mails processed by procmail (this is not just for my fun, > I have a couple of cases where procmail post-processes mail from > forms to update a local database for service reasons). > > (2) The simplest way to feed incoming mails into procmail is to use > fetchmail, which I am happily using since 2018, when my institution > moved from howgrown sendmail to Gsuite > > (3) The simplest way to have fetchmail working (after I activated > 2FA on Gsuite fetchmail was not authenticateds) is to "bypass" Gmail, > i.e. instruct Gsuite to forward all mail to another provider which > provides *standard* IMAP. > > This solves 98% of my problems, because > > - Spam is not forwarded from Gmail to the alternate provider > - messages forwrded *and deleted* are not actually deleted > but staged in Gmail's Bin for 30 days > > (4) The solution is ... "app passwords". Gmail with 2FA allows to > define a 16-char password THEY generate to be used with what in > the past were called provocatorily "less secure applications" > > So I generated such an "app passwords" and I can use it from my > preferred mail client (Alpine). And this solves my problem. > > (5) Actually the same app password can work also with fetchmail, > so in theory I would not need the alternate provider of point (3) and > could work "as previously", but I left it in. > > I had no need to move to OAUTH2, or learn it, or get an > OAUTH2-capable version of fetchmail (I use the OS-bundled one). > > I think I could be happy with the new arrangement. > > I hope the above is useful to somebody else. > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users |