At 12:48 -0700 on 08/08/2008, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote about
Re: 2821bis/ter and procedures (was: Re: retry question):
> > 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.
A possible solution would be to define an EHLO 220 reply that says
"Single RCPT-TOs ONLY" and blow off the sender if they try sending a
second RCPT-TO (by at least 450'ing the extra RCPT-TOs).
Servers advertising the number of RCPT TOs they'll allow, and more generally
other limits, so that clients can act more intelligently, is something I've
been thinking about for a while. BUt while I think it may be worth pursuing, I
don't see it as a solution to this particular problem. Remember that the reason
the server wanted multiple copies was because different recipients have
different filtering policies. It is still possible, however, for a message to
have a hundred recipients all with the same policy. Or for there to only be two
policies for reciients to choose from. Such a limit isn't expressible as a
simple number.
I would nevertheless welcome a draft defining a LIMITS extension along the same
lines as the existing SIZE extension.
Ned