On 2007-01-30 18:13:07 +0000, Tony Finch wrote:
"Eric A. Hall" <ehall(_at_)ehsco(_dot_)com> wrote:
On 1/29/2007 4:49 AM, Peter J. Holzer wrote:
It also may reduce the risk of resending a message which was already
accepted because the connection broke down, but I'm not sure that really
works:
If you send a message to 100 recipients, and the connection breaks after
43 replies, how many will get the message?
Hopefully none of them, since the server was not able to fully accept the
message for delivery.
That's what I understood to be the intention of the final code. If the
client receives the final code, it knows the server has taken
responsibility for the message and can forget about it (except for
recipients with 4xx replies, of course). If it doesn't receive the final
code, it must assume that the server hasn't accepted it and must resend
it for all recipients. I'm just not sure whether that really reduces the
number of duplicate messages. It it conceivable that the server sends
the final code before it notices that the connection has been lost. In
that case the client will resend the message to all recpients, while
otherwise it would resend the message only for those recipients for
which it hasn't received a reply code. So the final reply code reduces
the probability of duplicated messages, but if they happen, they are sent
to more users. I have no idea whether that results in more or less
duplicated messages overall.
It might be worth putting a synchronization marker after the full list of
recipients has been acknowledged by the client in order to ensure that
both end points are at the same state when final code is issued.
Ugh, no, that's horrible for performance. The right solution is:
http://www.ietf.org/internet-drafts/draft-fanf-smtp-rfc1845bis-00.txt
That only lets you put checkpoints inside the data. It doesn't let the
client specify how many reply codes it received for data (there's no
need for that in unextended SMTP). Of course the server could save the
reply codes it has already sent and quickly replay those if the client
resumes at the end of data, so maybe that doesn't matter.
hp
PS: I just subscribed to ietf-smtp(_at_)imc(_dot_)org, so as far as I am
concerned
we can continue the discussion there.
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp(_at_)hjp(_dot_)at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
signature.asc
Description: Digital signature
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg