Re: [Asrg] Re: draft-hall-inline-dsn-01

On 2007-01-28 18:24:17 -0800, Claus Assmann wrote:
> Wrt section "6.4. The Final Response Code":
>
> Why do we need a final reply code? Isn't that code the same as the
> minimum over the RCPT reply codes (at least wrt the reply code
> severity)? Hence it is not need to send this reply code as it can
> be deduced from the existing reply codes.
As I understood it the final response code serves as a "commit"
indication. A final 2xx reply means that the server has accepted the
message and will try to deliver it to all the recipients which got a 2xx
reply individually. If the the server cannot accept the connection, for
example, because the queue is full, it can still return a 4xx or 5xx
code, although it has earlier returned 2xx codes for some or all
recipients. 

That should make implementing the server a bit easier, as the message
has to be queued only after all the recipients are known. Otherwise you
either need to queue the message for each recipient indivually or you
need to update the list of recipients after the message is already
queued.

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? It might be anything between
43 and 100, because you don't know how many reply codes got lost.
With the final reply code, the server only accepted the message after
sending *all* of the reply codes. The chance that 57 reply codes were
successfully sent from the server's perspective but never reached the
client aren't that big, so the client can assume that the server didn't
accept the message and resend it with all recipients.

(OTOH, especially with long recipient lists and lengthy and possibly
fragile content filters, maybe it is more robust to commit for each
recipient individually: If the client wants to send to 100 recipients,
and the server crashes after the 10th recipient every time, that way the
message will get through in 10 transactions. It will never get trough if
the server needs to scan the message for all recipients to queue it)


        hp


-- 
   _  | 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