At 8:58 am -0400 10/8/2008, Hector Santos wrote:
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?
Because user1 was refused by the 550 response. Due to the 250
response to the RCPT TO command for user1 the transaction for user1
is still in progress, so the 550 is applicable.
Did you assume USER1 is getting the message?
Where is there any concept of "DELAY" defined for 250/550 results?
User2 was delayed by the 450 response.
Thats a major fundamental change, do you agree?
I think you don't understand what is going on.
How about if it was just 1 RCPT to user1
RCPT: USER ---> 250
DATA: ---> 550
Do you continue trying USER1? or do not?
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?
Prior to 2000, but I am unaware of any incompatibilities between it
and RFC 2821 and subsequent revisions.
[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).
I agree that it applies to a "message", singular. I do not consider
that it applies to messages that have already been delayed or refused
at RCPT TO time.
IMO, I believe you have it incorrect Glenn.
You still don't seem to understand that the smallest unit of work for
SMTP is a MAIL FROM plus a single RCPT TO plus a message body. While
multiple RCPT TO commands with a single message body can be used as
an optimization, the optimization is not required, and there is
nothing in the standards, including the above paragraphs, that
specifies that the optimized case should behave any differently from
the case where they are sent individually.
You seem to think that the optimized case should behave differently,
yet you aren't providing any reason for that.
Your retry logic has to be based on a 250 or 4xy response DATA response.
The retry logic for the delayed RCPT TO has to be based on the 450
response to the RCPT TO. To do otherwise would be inconsistent.
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
If you see a 4XX response to a RCPT TO, you need to stop for that
recipient and retry it later. Subsequent responses are not applicable.
Similarly, if you see a 5XX response to a RCPT TO, you stop
immediately, and report that 5XX to the sender. In your last example,
you wouldn't report the 550 response to the DATA command as the
reason why delivery failed to user3, the 550 response to the DATA
command is irrelevant to user3.
Glenn.