On Tue, May 25, 2004 at 10:40:54PM +0200, Matthias Andree wrote:
I think few if any mail protocols have useful COMMIT/ABORT semantics though.
SMTP, once you've done DATA and the final dot, is always commit.
Nope. Close the connection before the final dot -> abort.
Well, I think we're actually saying the same thing.
If the "PUT" operation means "MAIL FROM; RCPT TO; DATA; send mail; send
period" then there is no separate 'COMMIT'. If you want the ability to
abort, you'd need to separate this into other primitives:
PUTSTART - MAIL FROM; RCPT TO; DATA
PUTDATA - chunk of DATA (repeat as required)
PUTEND - send period (commit)
PUTABORT - drop connection
If it were me writing the core, I'd sequence the operations appropriately:
- FETCH message from A
- PUT message to B
- once B has confirmed successful PUT, then issue DELE to A
I am running "keep" all the time and delete manually, due to ESR's
refusal of an expire-after-N-days option.
That's fine too. You don't issue DELE, so there's no 'COMMIT' at all on
server A. You write to server B, and update our UID table for B. If the
write to B fails, then you'll try again next time.
Concepts such as "empty
list means cannot fetch" are prone to such errors.
In this case I think it's logical. An SMTP-accessed mailbox is a write-only
mailbox; having it as a mailbox which appears empty every time you try to
read it does work. But I'm not bothered if we have an explicit flag to say
"this is an append-only mailbox" either.
Regards,
Brian.