Glenn Anderson wrote:
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.
I don't know. That doesn't make sense.
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.
Well, I would be the first to admit it if it was true. What I need to
find out now is you are an isolated case or this is in fact the norm.
That USER1 is not getting the mail, and you only trying to retry User2
completely fly in the face of common sense.
Ok, lets suppose that on your 2nd try with USER2, that it now ACCEPTED.
Please explain why did user1 now lose out in getting the mail when it
was a more valid 250 case and user2 was not?
Continuing to retry on a DATA 550 will definitely get your red flagged
by continuing to ignore that the told you not to continue doing.
How about if it was just 1 RCPT to user1
RCPT: USER ---> 250
DATA: ---> 550
Do you continue trying USER1? or do not?
Not.
But you will continue to retry with a 450 RCPT reply? I don't know.
That doesn't sound right.
[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.
Nuts! <g>
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.
How can not anyone understand that 1 + 1 is smaller than 1 + MANY?
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.
I don't think anyone has said otherwise. But you are breaking the
rules even to make it work as you wish.
You seem to think that the optimized case should behave differently, yet
you aren't providing any reason for that.
I think I provided tons of reasons from different approaches - doesn't
see to catch. Not even what is written in stone means anything.
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.
-1. Your method will breed problems.
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.
Not TRUE. Not for the same payload. If DATA 55x, you SHOULD stop
retrying to sending that payload - per SPECIFICATION.
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.
Agree about USER3, but IMO you are not applying consistent logic. It
breaks down with an incorrect interpretation of the specs.
Probably the 2821 gaffe, but now corrected in 2821bis, is the cause of
this ill MTA behavior.
Even if DATA 55x said SHOULD retry, when it in fact says SHOULD NOT
retry, it doesn't make sense you should only try USER2 and not USER1.
USER1 will never get that mail with your logic.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com