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 |