> On Fri, 8 Aug 2008, [EMAIL PROTECTED] wrote:
> >
> > I should also point out that if there are no valid recipients the
> > client probably sohuld not have bothered to send the message.
> The server should probably have rejected the DATA command.
Absolutely, if a rejection was possible at that point. OTOH, if the
554 was a result of content analysis, then that would not be possible.
> > > > My take FWIW, is that none should be retried because the data is
> > > > rejected (probably based on content analysis e.g. spam or
> > > > virus). If the data response were a 450, a+b+c should be retried.
> >
> > Yep, that's my (revised) assessment as well.
> John's example is actually a perfect illustration of the context for my
> original question. The server in question was using 450 replies to RCPT in
> order to get separate deliveries of the same message for recipients with
> different content filter settings.
OK, I have to admit, that's not a case I've heard of before, and it makes this
quite a bit trickier than I first thought: A server deliberately using
temporary failures in order to force the client to split the message up.
(Recipient limits in general can have this effect, but this is not normally the
intent of such settings.) As long the the number of possible content filter
settings is small (2) this actually works acceptably well, but the fact that N
separate policies among the recipients of a given message will require N-1
retries makes this impractical in situations with lots of possible filter
settings.
In any case, I don't think there's anything that prohibits this, and given how
quite a few popular filters are incapable of rendering multiple per-recipient
verdicts simultaneously, this is bound to be something that people are going to
do even if it does cause lots of retries. And that means it really does need to
be accomodated. And that in turn means that <c> really should be retried.
Thinking about it even further, I believe a similar case is also going to come
up in some situations where the new Sieve ereject construct is used and there
are other, over-quota, recipients getting temporary errors. (So much for
backscatter elimnation making life easier.)
These two use-cases seems likely enough to me to occur in practice that I
tested our client just now to make sure it does the right thing. And lo and
behold it retries <c> in this case. I no longer recall why it was done this
way, but I'm now glad it was.
> That is,
> MAIL FROM:<a>
> 250 ok
> RCPT TO:<b>
> 250 ok
> The server notes that user B has aggressive content filtering settings.
> RCPT TO:<c>
> 450 try later
> The server sees that user C has lenient content filtering settings and
> asks the client to try delivering the message to C later.
Because it wants an additional copy for separate evaluation. Yep, got it.
> RCPT TO:<d>
> 550 no such user
> DATA
> 354 go ahead
> blah blah
> .
> 554 ugh
> The message fails to pass B's filter settings, but it would have passed
> C's settings. The server expects the client to interpret the post-data
> rejection as a failure for recipient A only.
I believe you meant to say recipient <b>. <a> is the sender.
> I don't recommend this kind of setup because I get the heebie-jeebies when
> I contemplate the possible interoperability problems. Richard's and Ned's
> comments above confirm my fears.
Well, in this case at least my client code got it right even though I got it
wrong.
> There are other places in which retry logic is underspecified, e.g. should
> a client retry other MXs immediately or after a cooling-off period?
I agree it's underspecified, but at least in this case you're not talking about
legitimate server behavior causing unnecessary bounces. MX retry logic is
endlessly tunable and quite a lot of it ends up making one thing better
at the expense of another.
> Does
> the answer depend on whether there's one MX records with multiple A
> records, or multiple MX records at the same priority, or multiple MX
> records with differing priorities? Implementers have come up with
> different answers.
Indeed. And unfortunately with the ever-increasing prevalence of various
greylisting and limiting schemes, we're at a point where there probably is no
single "best" answer.
> So I think that it would be useful to pin this down more precisely, both
> for full clients and queueless clients. (Should message submission clients
> handle errors like queueless clients even when they have queues?) However
> I'm not very confident that we could get any useful consensus.
In the case of error returns in the protocol, I would hope that some amount of
consensus is possible. In the case of MX retry strategies, I share your doubts.
Ned
