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 |