[Top] [All Lists]

Re: Changing RFC 5322 guidance about crlf.crlf response delay

2010-08-11 14:47:04

Steve Atkins wrote:

For example, a delay time of up to 2 seconds is probably pretty safe.

Many of the things you're going to want to do in that time will take
longer than that. There's a long tail, but I'd expect to see some
processing take a minute or more in rare cases.

There is definitely a long tail here. The cases will depend on how these scripts are designed. If a script developer understands it could be applied at DATA, he/she will improve it for speed. That is what happen to us. An example script provided that illustrated word list scanner reading off a text file, grew with popularity and their word list file grew over time increasingly causing delays into the minutes when large payloads were transferred. Greater client timeouts drops and retransmits issues was a result. Improved updates of the scanner moved the processing time into seconds by using caching, memory map files, pre-compiling of words, etc.

No one wants long delays to causes problems.

What's the failure mode at that point in the transaction - are we
defending against a transport failure, or the client violating spec
with timeouts or...?

Two things IMV

  - most clients do not wait 10 mins. Its much shorter. We see around
    3-5 minutes.

- The realization DATA processing is the new and more desirable "thing"
    and we need standards "adjustments" in order to provide continued
    consideration for the "old things" (legacy software).

Implementators simply need to be reminded that data processing time should be as minimal as possible, but also not trust a SMTP recommendation of 10 minutes to be universally followed when they begin to implement more DATA processing work.

For us, to help enforce/control the issue, we added a sysop-definable GlobalTimeOut with a default of 5 minutes for processing all call-outs, hooks, shims, what have you.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>