OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Postfix Archives: Re: Slow downstream site wedged my Postfix...

Re: Slow downstream site wedged my Postfix...

Subject: Re: Slow downstream site wedged my Postfix...
From: Gerard Lachac (lachacgsaturn.superlink.net)
Date: Tue Jan 25 2000 - 13:34:26 CST

On Tue, 25 Jan 2000, you wrote:
> In this case, the solution is for Postfix to not accept tons of
> mail for the downed site to begin with.
>
> This is a strategy that I thought up in off-list discussions with
> Patrick Rak. Although we disagreed initially on implementation
> details the general approach is that the master maintains a count
> that is incremented when mail is inserted into the incoming queue,
> and decremented when mail is delivered (or deferred, as the case
> may be).
>
> As the count exceeds some threshold, Postfix inserts delays into
> the the SMTP dialog, so it still accepts mail, just a bit slower.
> If lots of mail comes in over a few connections this strategy
> effectively slows down the sender and does not affect other inbound
> mail too much. If the mail flood comes from all over the network,
> eventually the connect() queue in the kernel will fill up and client
> connections will start to time out. That's still better than Postfix
> becoming clogged up.
>
> What do you people think of this solution?

I don't think I like it. I feel it the solution does not work well in
all situations.

Let's take the ISP for example. You are running a relay for your
customers with Postfix. Users are directed to point their
Netscape/Eudoda/Outlook clients at it. And all your web based mail readers
point to it as the outbound relay.

Your artificial delay proposal slows down the ISP user's mail client
response time in sending mail because the remote site is slow. Why punish
the user for something that isn't his fault? Even worse, with Webmail
readers that point at the Postfix relay, you will slow down the syncronous
send capability of the web interface because the remote site is slow,
increasing web user response time.

Customers like to complain, and it is especially bad when it isn't
their fault. I'm all for delays for stopping bad things (tarpit
controls etc.), but in this situation it doesn't seem the right thing to
do.

-lachacgsuperlink.net

This archive was generated by hypermail 2b27 : Tue Jan 25 2000 - 14:21:28 CST