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