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.
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.
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.
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.
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.
Glenn.