[Dovecot] 1.0.rc22 released

[Matthias Andree]

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