On 2007-01-30 18:13:07 +0000, Tony Finch wrote: > "Eric A. Hall" <ehall at ehsco.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.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.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall"
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Asrg mailing list Asrg at ietf.org https://www1.ietf.org/mailman/listinfo/asrg