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. |