Aaron,
There are distributed transaction managers. Moot point in this context.
Let's consider a simple example. Let's say that James accepts a message and
the sender's connection is pulled at just the wrong point. James has
spooled the message, but the sender can't get the notification.
RFC 1123 states that 'When the receiver-SMTP accepts a piece of mail (by
sending a "250 OK" message in response to DATA), it is accepting
responsibility for delivering or relaying the message. It must take this
responsibility seriously, i.e., it MUST NOT lose the message for frivolous
reasons, e.g., because the host later crashes or because of a predictable
resource shortage.' Therefore, James may see that the sender's connection
has gone bye-bye, but that doesn't mean James should not send the message.
Meanwhile, the sender doesn't know if the message was sucessfully sent. RFC
1123 (amongst others) states that the sender "MUST be able to [retry] until
a delivery attempt succeeds."
Sending e-mail is not a database transaction. James tries to be as reliable
as possible. James should not send the "250" until after the message is in
the spool. To do otherwise would be a defect requiring a fix. Once the
message is in the spool, it stays there until after a sucessful transfer
elsewhere.
If you need guaranteed delivery over SMTP, you could have the destination
send an ACK after it has successfully processed the message. The sender
continues to periodically resend the message until receiving the ACK. The
receiver must discard duplicates.
> It may be possible to track the progress of a mail through the processor
As you noted, this would require making a database update for each
transition between mailets. There is a different solution, available today.
Configure a separate processor element for each non-idempotent operation.
That way there will be a spooler transition recording the change where it is
necessary.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
