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

graeme vetterlein <[email protected]> Tue, 13 Feb 2024 21:34:14 +0000
Newsgroups gmane.mail.fetchmail.user
Message-ID <[email protected]>
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 '[email protected]' 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 
[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


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







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