On 13.5.2013 15:10, Wietse Venema wrote:
Instead of introducing a context-dependent overload resource budget,
I have a proposal that addresses the real problem (slow or
non-responding DNS and SMTP servers) and that requires no changes
to qmgr(8) or master(8), and minor changes to smtp(8).
If we want to address the real problem: slow or non-responding DNS
and SMTP servers, then we should not waste an entire SMTP client
process blocking on DNS lookup and TCP connection handshake in the
first place. Instead it is more efficient to interpose a prescreen(8)
process between the qmgr(8) and smtp(8) processes. This process
can look up DNS, create the initial TCP connection, peek() at the
remote server greeting, and keep the bogons away without wasting
any smtp(8) processes. Just like postscreen(8) can keep bogus SMTP
clients away without wasting smtpd(8) processes.
Hmm, this is definitely an interesting idea. Looks pretty cool. But
there are few problems as I see it:
First, it seems to work when the servers you talk to are slow, you can
talk to thousands of them at the same time easily. But what happens if
you initiate thousands of connections but then you find out that the
servers do not respond slowly, but are actually pretty fast? You still
have only hundred worth of smtp clients to deal with that. And the
message delivery can take considerable time. This spells trouble to me...
Second, it doesn't prevent the "blocked delivery agents" problem as
such. It merely scales the point when it happens - in this regard it
achieves the same thing as if the transport limit was increased, only
using much less resources. Even if such prescreen was able to handle few
thousand connections at a time, the deferred queue can easily grow much
larger than that.
Therefore I believe that trying to classify the mail as "hopefully fast"
and "perhaps slow" and capping the ratio of the resources we allocate to
the slow one is the best we can do, for both the active queue as well as
the delivery agent slots.
Patrik
