Re: [courier-users] Re: courier tmp directory - with some diagnostic

[Sam V. <mr...@st...>]

On Mon, 4 Sep 2000, Jason Haar wrote:

> On Sun, Sep 03, 2000 at 08:16:44PM -0400, Sam Varshavchik wrote:
> > You will find many fixed upper resource limits in Courier.  Overall, the
> > system design is oriented to limiting all sorts of potential sources of
> > denial of service attacks.  Allowing the system an unlimited period of
> > time to receive a single message is just asking for trouble.
> 
> Wow - that's come as a bit of a shock. What's wrong with setting up similar
> timeout options to sendmail and qmail, and setting some "sane" huge timeout
> for a connection - like 12hours? Even I could live with that :-)

Yes, I want to review all these settings, soon.  There is, actually,
several inactivity timeouts for ESMTP sessions:

[root@gwl root]# showconfig

...

esmtptimeout: 10 mins
   - Timeout for most outbound ESMTP commands
esmtptimeoutconnect: 1 min
   - Timeout for ESMTP connection attempt.
esmtptimeoutdata: 5 mins
   - Timeout for ESMTP data transfer.
esmtptimeouthelo: 5 mins
   - Timeout for the response to the initial EHLO/HELO command.
esmtptimeoutkeepalive: 1 min
   - How long to keep outbound ESMTP connections idle, before closing
esmtptimeoutkeepaliveping: 
   - How often outbound ESMTP connections are pinged
esmtptimeoutquit: 10 secs
   - Timeout for the response to the QUIT command.

These are the defaults, and they are tunable.

However there's also a hard timeout of 20 minutes in the submit process,
which accepts messages from all sources -- SMTP, or command line sendmail
process, or UUCP, or the delivery status notification injector, etc...

This one needs some thinking...

> FYI, in all the years I've run mail servers, I've never seen SMTP sessions
> under Qmail or Sendmail hang on for days on end because of such
> "troublesome" timeout settings...

But this approach is vulnerable to being teergrubed.  The hard timeout is
there to minimize the impact of being teergrubed.


-- 
Sam