Glenn Anderson wrote:
With the 550 DATA server response,
Q1 - How will your MTA behave here?
A) continue to try USER1?
B) continue to try USER1 and USER2?
C) not continue to try any?
D) Other scheme?
D, continue to try USER2, as that transaction was delayed.
But why not user1?
Did you assume USER1 is getting the message?
Where is there any concept of "DELAY" defined for 250/550 results?
Thats a major fundamental change, do you agree?
How about if it was just 1 RCPT to user1
RCPT: USER ---> 250
DATA: ---> 550
Do you continue trying USER1? or do not?
Finally, I have to ask, did you design your MTA prior to 2000 around
821 or after 2000 based on the 2821 message in 4.2.5?
[2821 - 4.2.5]
When an SMTP server returns a permanent error status (5yz) code
after the DATA command is completed with <CRLF>.<CRLF>, it MUST
NOT make any subsequent attempt to deliver that message. The
SMTP client retains responsibility for delivery of that message
and may either return it to the user or requeue it for a
subsequent attempt (see section 4.5.4.1).
Do you acknowledge that this was corrected in 2821bis where it now
says? Do you agree with it?
[2821bis - 4.2.5]
When an SMTP server returns a temporary error status (4yz) code
after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT
make a subsequent attempt to deliver that message. The SMTP
client retains responsibility for delivery of that message and
may either return it to the user or requeue it for a
subsequent attempt (see Section 4.5.4.1).
IMO, I believe you have it incorrect Glenn.
Your retry logic has to be based on a 250 or 4xy response DATA
response. If you want that same robustness that is found with
multiple single RCPT transactions, then it begins with honoring
250/4yz for the multiple RCPT transactions + Tony Finch Retry comments.
But if you see 5yz, you need to stop, just like it said in 2821 and
2821bis:
[2821/2821bis - 4.2.5]
When an SMTP server returns a permanent error status (5yz) code
after the DATA command is completed with <CRLF>.<CRLF>, it MUST
NOT make any subsequent attempt to deliver the message. As
with temporary error status codes, the SMTP client retains
responsibility for the message, but SHOULD not again attempt
delivery to the same server without user review of the message
and response and appropriate intervention.
Sure, you can keep trying, but thats on you only. Its not the specs.
Expecting different results with nothing is going to changed usually
doesn't work very well. In fact, it can get you black listed.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com