Frank Ellermann <[EMAIL PROTECTED]> wrote: > Hector Santos wrote: > >> DATA >> +----------------------------------------------+ >> | | 250 | 45x | 55x | >> |--------+-----------+------------+------------| >> | 250 | DELIVER | MAY RETRY | NO RETRY | >> RCPT |--------+-----------+------------+------------| >> | 45x | MAY RETRY | MAY RETRY | NO RETRY | >> |--------+-----------+------------+------------| >> | 55x | NO RETRY | NO RETRY | NO RETRY | >> +----------------------------------------------+ > > If somebody writes a "retry clarification" draft *and* the > proposal goes in this direction, please copy Hector's ASCII > art.
I don't agree: Hector's table may be helpful to this discussion, but would be confusing for an RFC. (I also don't agree with Hector.) Let me try, reprising John Levine's original question: ] ] From: John Levine <[EMAIL PROTECTED]> ] ] Straw man: ] ] 220 server ] ] EHLO foo ] 250 whatever ] ] MAIL FROM:<a> ] 250 ok (I too have misread this to think of <a> as a recipient, so I may well still be misreading something.) ] RCPT TO:<b> ] 250 ok ] ] RCPT TO:<c> ] 450 try later ] ] RCPT TO:<d> ] 550 no such user At this point, there's one valid recipient, one indeterminate, and one invalid. Were the following DATA to respond 250 OK, it would have accepted responsibility to deliver to <b> only. There is, I suppose, some wiggle room for other responses to DATA to mean something about <c> and/or <d>; but this strikes me as weird: the obvious implementation is for both sides of the SMTP session to have forgotten about <c> and <d> at that point (for this session). (Titling the 554 response "no valid recipients" may confuse the issue; but IMHO we'd be stretching things beyond reason to interpret it to mean to disambiguate the indeterminate status of <c>.) ] DATA ] blah blah ] . ] 554 ugh I would certainly interpret this as a permanent rejection for <b> only. Thus, I would expect to retry <c> -- about which I can infer nothing by the DATA response. ] Which, if any, of b, c, and d get retried? Why or why not? What if ] the 554 were a 450? If the DATA response were 450, I would take that as a directive to retry <b> (orthogonal to the question of retrying <c>). IMHO, trying to infer anything beyond this is unwise -- and trying to rewrite what all this means in a 2821-ter is double-plus-unwise. 2821-bis isn't helpful on whether to try combined <b> and <c>. My guess is that separate is better; and that seems the obvious way to implement a MTA. We might state in a future Informational or BCP document that in cases like this it's best to retry <b> and <c> separately; but we can't hope to enforce such behavior. -- John Leslie <[EMAIL PROTECTED]>
