Brian Candler <B(_dot_)Candler(_at_)pobox(_dot_)com> writes:
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.
POP3 lets you RSET, but the only thing that resets is the DELE state
(although that's the only thing you can actually change via POP3). I
don't think IMAP has any kind of rollback.
If it doesn't, the rest of the system must accomodate.
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.
I think any CAPA/CAPABILITY/EHLO tests can be hidden behind the module API.
If a module doesn't support FETCH then it returns an empty list to LIST;
"empty list" is different from "cannot fetch". Being explicit in
responses helps. Trying to fold "I cannot do that" into other special
cases doesn't work. I've seen Mailman, and I'm getting deferral notices
at the -owner account that one module in Mailman wants discarded that
another module interprets as "parse failure". Concepts such as "empty
list means cannot fetch" are prone to such errors.
Well, new primitives can be added if they're needed, and you could have a
flag to say whether primitive X is supported. If that's what you mean by
CAPABILITY then fine.
Indeed that is my intention.
PUT <-> MAIL FROM, RCPT TO, DATA
ABORT <-> nope, too late!
Not at all - slam the receiver on the hook, i. e. close(2) before
sending CRLF.CRLF. For sendmail, send SIGKILL instead of EOF. It's rude,
but it works.
COMMIT <-> null operation
It should fail if the previous PUT failed.
I guess if you are streaming from A to B, then abort can be 'drop
connection'. That means if a FETCH operation aborts, the corresponding PUT
can be aborted too. But I'd be inclined to spool to disk anyway.
This would need to be considered in context with multidrop, and it would
also mean that fetchmail became much slower, since the fetchmail spool
will consume additional time (fsync(2) will be needed!) and the regular
MTA spool or MDA delivery will still take place.
copynew:
from pop3 (host=serverA user=foo pass=bar)
to smtp (host=127.0.0.1)
to smtp (host=serverB user=baz pass=baz)
Then each message detected as 'new' on serverA could be delivered to two
places. It's probably easier to fetch the whole message then deliver twice,
than to try and stream to two places simultaneously.
Well, I'd personally insert a "fanout" or "copy" driver for such
purposes. Makes the core design easier.
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95