Re: Proposal for Adjusted DATA Timeout

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
> > > (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.
> 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)
>
> where
>
>    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.