ietf-smtp
[Top] [All Lists]

per-recipient response twisters

2007-02-26 15:26:07


I have been working on rewriting the deferral draft to accommodate some of
our discussions and have gotten into some hairy corners.

Consider a scenario where the post-data response block looks like this:

  353 detailed responses follow
  250 lover(_at_)example(_dot_)com may accept the message
  550 fighter(_at_)example will not accept the message
  421 my disk disappeared... please try again later

The final response code determines whether or not the message is
accepted--if so (2xx) then the client releases the message from its queue
and generates whatever notifications are needed for failed recipient, but
if the final response indicates that transfer has failed entirely, the
client has to requeue the message according to traditional rules.

So, what does that mean for fighter(_at_)example(_dot_)com and the 550 
response? Does
the client requeue the message, and discard the recipient list? Or does it
go ahead and process the failed recipient, and then requeue the message
absent the failures?

This same problem also appears in regular SMTP somewhat, in that a RCPT TO
address may be rejected during envelope exchange, and the entire message
being rejected. Although it does not appear to be written in stone
anywhere, it seems that the correct course of action is to process the
failed recipients as soon as you know about them, and then requeue the
message absent the failed recipients.

Actually it seems that SMTP clients should generally treat the
per-recipient response codes as deferred RCPT TO responses, and to
essentially reuse the existing logic for failures in particular. This has
the benefit of simplifying implementation logic a bit and seems to cover
most of the corner cases. Does anyone disagree with this?

More generally, it also seems that this whole mechanism is a deferred RCPT
response mechanism, rather than a per-recipient data response mechanism. I
will likely change the extension acronym back to DRR accordingly.

It also seems that this is why I had the 352 response code in the original
RCPT handling--the model is deferring a response to RCPT, and 352 says
"wait for an answer" as appropriate. I'm not going to put it back in, but
this answers the question why it was in there in the first place.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

<Prev in Thread] Current Thread [Next in Thread>