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