At 19:27 09-08-10, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
I have a somewhat different take on this. First of all, I have always thought
the admonition that you MUST minimize the amount of time spent before
responding to the trailing dot to the greatest extent possible was,
well, bunk.
(It's also an effectively unenforceable MUST - who can say you've done all you
can or not? - which is bad in its own right.) While it is important not to
spend too much time, the difference between a millisecond delay and a 2 second
delay is, in this situation, not worth worrying about.
Filter processing can sometimes take much more that two seconds. As
others mentioned, it is better not to rely on the 10 minute DATA
termination timeout. Some receivers set a much shorter
timeout. Some senders may timeout before that 10 minute period.
What *is* worth worrying about is deferring too much processing
until later. Do
From an operational perspective, I agree.
It can also lead, in a variety of ways, to generating excessive amounts of
blowback.
Yes.
One final point. This is a situation where it's useful to distinguish between
submission and relay. In the case of submission, there's usually a person
sitting there waiting for the message to be sent, so a shorter
timeout not only
makes sense, you're going to have very little luck convincing client
authors to
use a longer one. Relays, OTOH, tend to be much more tolerant of delayed
responses. There are of course all sorts of ways to make submit operations
responsive than relay operations.
The difference between submission and relay is that the user calls
you when they cannot send the message. Some MUAs may timeout well
before the 10 minute period.
At 19:52 09-08-10, Tony Hansen wrote:
A big timeout doesn't mean that one can takes lots of time, but it
might explain where someone got the idea that they *could* take lots of time.
Yes.
Regards,
-sm