Re: I'm wondering if I've somehow dropped off the list?

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
>> [email protected]@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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users


_______________________________________________
Fetchmail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fetchmail-users