Tony Finch wrote:
> On Tue, 5 Aug 2008, SM wrote:
>> If you are going to temporary fail the transaction because the first
>> recipient got a 4yz reply, you may end up never being able to attempt a
>> delivery for the other recipients.
>
> I know that, but there's evidence that some implementers don't understand
> it.
Interesting, I have not seen it myself, but wouldn't be surprise.
Given we seem to have implementors from time to time that have difficulty at
the "see Spot run" level of comprehension, I'm not surprised either.
I guess, if given the chance, it should be made clearer.
IMV, it depends on the client, is it a MUA client? an backend server
list distribution?
Good point. This is one of those cases where submission is different than
relay. It is entirely reasonable for an MUA to abort the connection when such
an error pops up, although speaking as a user I'd prefer to have the option to
continue to send to the other recipients. And by the same token, a submit
server probably should be prepared to accept messages to such recipients
even though there's a problem preventin immediate delivery.
But IMO discussion of all this really belongs in the submit specification, not
2821bis.
Overall, the implementation where it attempts to satisfy all and keeps
trying in new sessions until the very last one is resolved, would be
more difficult, wasteful and prune to error - especially in a list
distribution. But of course, its not impossible to do.
The names we have for this three-state logic in our code are, with apologies to
Sergio Leone, "good" (2yx), "bad" (5yz), and "ugly" (4yz). There's a reason we
call it the ugly case.
In fact, I believe some MUAs will not even continue with the DATA
until all same session RCPT are positively resolved.
Yep, but as long as they report the problem to the user the user can take
corrective action. Of course that's not something a relay MTA has the option of
doing.
In either case, this MUA behavior would not be very acceptable for a
automated backend MTA.
Exactly.
Ned