Glenn Anderson wrote:
At 2:56 am -0400 10/8/2008, Hector Santos wrote:
Encourage? Efficiency? Urged? all code for optimization.
I'm all for the optimization, but nowhere in the specifications does it
say anything about things behaving differently when you make this
optimization.
And neither do I think that is the case here. But we do have a
different mind set in regards to POST SMTP vs DYNAMIC SMTP
acceptance/rejection concepts.
I believe they should be the same and believe what Tony Finch pointed
out applies to what we are talking about.
The difference is the DATA 55x handling and I believe I am correct to
suggest the documentation says that acceptance is only with a positive
response.
As I have already pointed out, if you consider the 5XX response to the
DATA command or message body to be applicable to a RCPT TO that got a
4XX response, you would get different behavior when this optimization is
used.
I don't think so. If you follow the original Tony Finch post, it is
all applicable for the optimized or non-optimization - the same
results will be achieved - but the client has to RETRY and the point
is, some might not i.e., a mailing list distribution.
Another example also just occurred to me, consider a case with
PIPELINING of:
MAIL FROM:<s>
RCPT TO:<d1>
RCPT TO:<d2>
DATA
250 ok
450 try later
450 try later
554 no valid recipients given
In this case the response to the DATA command definitely shouldn't apply
to the RCPT TOs.
PIPELINING is a ADD-ON concept and I belive that it has to fit into
basic model first. IOW, if we can't get the basic model to work,
then how do we expect PIPELINING to work?
Anyway, I guess we will just have to agree we see things a little
different but I think we have the same common end goal.
My goal is robust inter-operability. Even if this is considered to be
ambiguous, I think the most robust behavior is to consider the response
to a DATA command to not be applicable to a delayed RCPT TO. Worst case
the delayed RCPT TO is retried unnecessarily, no big deal.
I agree in principle, but that is not how the SMTP specs are written.
We can get the same results but you have to follow Finch's comments.
On the other hand, if the delayed RCPT TO isn't retried, and the
receiving server is doing some kind of per recipient filtering (eg: what
is being proposed in the thread on some sort of limits extension where
all but the first RCPT TO would get a 4XX response when the extension
isn't supported), mail could be lost.
Lets try to pin this down. I would like to ask this question since you
indicated your MTA behaves this way (correct me if I mis-read you).
Suppose your MTA was connecting to our server, and you were sending
mail to 3 accounts and the RCPT reply codes was:
RCPT TO: user1 ---> 250
RCPT TO: user2 ---> 450
RCPT TO: user3 ---> 550
because there was at least one 250, you were allowed to go to DATA
DATA
354 continue
... payload transfered ...
550 not accepted.
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?
Q2 - If A or B, is this based on the presumption DATA response will
change? Eventually?
Q3 - Do you believe that because USER1 was 250, the Server SHOULD not
issue a negative response? (To help with robust principle?)
These are serious questions because if you and the majority of
systems, are expecting my server to deliver for USER1 even with a DATA
554, then I had it all wrong.
Or maybe I had it all wrong and lucked out because if you tried 60
times, the same end results was provided and no one ever get the
messages - just like a 1 shot attempt would of provided.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com