Timo Sirainen schrieb:
Dovecot does support LAST optionally, but is it even then a problem? Looking at RFC1081 it still seems that LAST should return the highest RETRed message, regardless of whether the connection was QUIT or not.
Yes. The fundamental problem with LAST is that the server must assume that a message RETR'd is a message delivered, which is untrue and can cause message loss. I wish Dovecot wouldn't implement LAST at all.
And I'm certainly not bothering teaching fetchmail to do RETR, RSET and other tricks to keep LAST workable. We have UIDL, and we've had it for over a decade now, and it works well.
RSET command then.. Currently I'm rollbacking the transaction there.
Correct. Same for a broken connection. Only the UPDATE state (after a QUIT command) is allowed to update any state.
I'm not sure if it's wanted or not. If LAST is enabled it doesn't matter anyway, since all the \Seen flags are removed. So I guess I'll change the code so it doesn't rollback with LAST enabled since it only loses cache data.
Whatever cache data you're referring to...
In any case, I'd rather retrieve a message twice than only a corrupted copy if the connection breaks amidst the retrieval, so RSET, broken connections, whatever -> rollback, pretending the broken connection had never happened.
It *is* ugly, and I'd encourage you to remove "LAST" support altogether. It's foul debris from the past century.
Best, Matthias