ietf-smtp
[Top] [All Lists]

Re: retry question

2008-08-07 02:12:15

Tony Finch wrote:

Add:

   When the client issues more than one RCPT command, the server's replies
   can be a mixture of success and failure codes. If any of the RCPT
   commands are accepted, the client SHOULD proceed with the rest of the
   transaction. If any of the RCPT commands are rejected with a temporary
   failure code, the client SHOULD only queue those recipients for later
   retry. If any of the RCPT commands are rejected with a permanent
   failure code, the client SHOULD only generate delivery failure
   notifications for those recipients.

Sounds ok to me, but the 3rd sentence sounds like it can be better.

Don't you think there is a risk the implementer can get the silly idea that he 
has to oblige with even doing retries?

Possibly:

  If any of the RCPT commands are rejected with a temporary
failure code, the client MAY retry again under a different session and it SHOULD only consider these temporary rejected recipients for any future retry attempt to sent the same message. i.e. it should not send duplicates.
Overall, I think 2821bis is ok, but I think that what we really talking about 
is different client methods.  If that is not the case,  then there is 
presumption it is all understood - User's MTA vs domains' MTA - thus the naming 
calling continues.

Is this doc is only for backend MTAs and not a guideline for MUAs as well, then 
we should not be surprise of the variant behaviors that right now will 
contradict the statement above.


--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com