Re: s41t storm

On 2007-02-02 13:47:01 -0700, Bryan Scott wrote:
> John Peacock wrote:
> >Peter J. Holzer wrote:
> >>Most of the time when forkserver maxes out the problem isn't CPU
> >>usage[0], it's clients which simply connect and hang around doing
> >>nothing until the timeout kills them. Greylisting doesn't help there, of
> >>course.
> >
> >That's exactly what I was seeing (strace yielded "read(0,"), so I 
> >reduced the timeout parameter from the default of 20 minutes. 
> 
> So what are people using for a timeout value?  If you figure the reason for 
> waiting that long is dialup users and none of my dialup users are 
> connecting to qpsmtpd (they use qmail-smtp on port 587), is 10 or 5 minutes 
> too short for a 20-25MB file (my cap)?

I don't think the size of the message makes much of a difference: The
timout is reset every time the server receives a packet, so the client
can send arbitrarily long emails as long as manages to send the next few
bytes before the timeout.

RFC 2821 recommends "a timeout of at least 5 minutes while it is
awaiting the next command from the sender", but doesn't make any
recommendations for timeouts during receiving data. One can probably
assume that the client doesn't have much processing to do while sending
out the email (unlike the server, which may do all kinds of DNS or LDAP
lookups, virus and spam scanning, etc.), so unless the "client" is
really a human typing commands into telnet, the largest delays will be
from lost packets on a congested line. A tcp connection can take a few
minutes to recover from packet loss, so the 5 minute recommendation is
probably reasonable.

	hp

--

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp <at> hjp.at         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"