--On Saturday, May 24, 2008 5:38 PM -0700
ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
>...
> Well, not only do we have an option to increase the client
> wait time based on message size
> (STATUS_DATA_RECV_PER_BLOCK_TIME), we also have an option to
> increase it based on number of recipients
> (STATUS_DATA_RECV_PER_ADDR_TIME) and on size*recipient
> (STATUS_DATA_RECV_PER_ADDR_PER_BLK_TIME).
>
> As for their utility, our experience has been that this is one
> of those things that's rarely needed, but when it is needed
> you REALLY need it, because without it you have to choose
> between crap client performance or large messages being
> duplicated. Accordingly, I think writing it down somewhere
> makes quite a bit of sense.
I agree. I also think an option to increase based on perceived
link performance (e.g., how long TCP ACKs take to arrive if that
information were available from the local stack, which, of
course, it almost never is) would be worthwhile.
RIght. As you're undoubtedly aware, the channel concept in our MTA gives us the
ability to adapt to link-specific conditions - all timeout settings can be
made per-channel.
However, since channels are widely used and well understood by our users, it
creates a situation where people are able to make link accomodations without
asking for help. As a result we really have no idea to what extent people are
doing this. These size and recipient accomodation settings, OTOH, are pretty
obscure so people using them tend to ask about them first. In fact if memory
serves we actually had a recent case where having the
STATUS_DATA_RECV_PER_ADDR_PER_BLK_TIME value set too high was causing a problem
for someone.
Ned
P.S. Of course the irony here is that in some ways the worse we do at defining
and/or documenting such capabilities the more we end up knowing about what
people are actually doing out there. It can really suck when you remove a
feature you thought nobody was using only to find that it was just that you
didn't know people were using it.