[Top] [All Lists]

Re: Proposal for Adjusted DATA Timeout

2008-05-26 00:20:09

Hector Santos wrote:
John C Klensin wrote:
--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

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.

IMO, I don't think its a TCP or COM I/0 bandwidth issue.

However, it could be. SMTP is not interactive, it thus deserves a TOS based on minimal cost, where possible.

With more systems doing dynamic DATA processing (i.e, AVS processing, and soon more DKIM hash calculations of large files), the timeout is now directly proportional factor in the maximum email size allowed per receiver (worker thread/spawned process).

So we can equate this to:

  EMS = SPR x (DTT *60)


   DTT -> minimum expected data termination timeout (per min)
   SPR -> system data processing rate (bytes per sec)
   EMS -> email max size (bytes)

Yes, an MTA should take all the time it needs to validate DATA.

IMHO, an MTA can devise better strategies than maximizing throughput. In that respect, the last paragraph in section 6.1 is fine for authenticated/whitelisted clients only. For spammers, tarpitting makes sense; on my system, for one, that adds up to 128 seconds to each response.