Subject: Re: [Emailcore] Ticket #16: G.7.12. Review Timeout Specifications

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Mar 2021 03:02:32 -0200

> On Feb 23, 2021, at 6:10 PM, Todd Herr <[email-masked]> wrote:
> 
> RFC 5321 (and its predecessors going back to 821) specify minimum periods
> for client and server to wait before timing out. Are those intervals still
> appropriate in a world of faster processors and faster networks? Should they
> be updated and revised? Or should more qualifying language be added?

Sadly, the more CPU horsepower we add, the more new work we expect them
to do.  Nothing gets faster, we just raise the complexity.  What this
means in the present context is that clients waiting for a response
to DATA must still wait the full 600s, because the various virus
scanning engines and callouts to remote services that return URL
reputation information, ... all take time.  Servers expect to be able
to still use the original timeout, and just squeeze more out of the
available time budget.

> On a related note (maybe another issue?), only a few mailers sit after
> an DATA transaction holding the socket until something else comes in
> to start a new transaction.

Here, I'm quite sympathetic to a less generous limit.  Postfix will
hog an idle connection for at most 2 seconds, and will only keep it
alive in the first place when there is a backlog for the destination
domain at the time the delivery starts, and so some likelihood that
the connection will be reused.  Wietse considered it rude to hog the
resources of remote servers for more than a brief time to piggy-back
an immediately ready message.

So, yes, even 5s would be more than sufficient, 300s is much too generous.
Again (the space I know), Postfix will generally wait the 300s, but is
somewhat adaptive and as the server's connection limit is saturated
that time drops to 10s.

-- 
	Viktor.