grpprod wrote:

> > The problem, if I understand correctly, is that the connections are
> > left open for a long time. The solution is to create a new
> > configuration file with at least the following features:
> >
> > FEATURE(`access_db')dnl
> > FEATURE(`ratecontrol', , `terminate')dnl
> > FEATURE(`conncontrol', , `terminate')dnl
> > define(`confCONNECTION_RATE_THROTTLE', `10')dnl
> > define(`confBAD_RCPT_THROTTLE', `2')dnl
> >
> > I would also recommend this one:
> >
> > FEATURE(`greet_pause', `5000')dnl
>
> Hi Rene and group,
> I have utilized all your suggestions, and I now totally understand
> their meaning (especially after reading the excellent article from
> Weldon Whipple (http://www.technoids.org/dossed.html). I am completely
> happy about them, they block a large number of connections. I still
> have the 'open connection' problem, though (I am not sure this has
> something to do with attacks), and it still consumes server resources.
> I explain:
>
> If some mesage manages to 'pass' the limits, but the server is perhaps
> a bogus one, our server tries to send back the usual bounce. Although
> my sendmail runs as '-bd -q1h' you can see below the connection remains
> and it constantly tries to send the response. I was wondering how to
> configure a 'max retry timeout' to overcome this problem.
>
> Sep 23 03:57:46 myserver sendmail[16283]: k8LMj0ci005712:
> to=<ekiehl@infozines.com>, delay=1+02:12:46, xdelay=00:03:09,
> mailer=esmtp, pri=32250000, relay=infozines.com. [204.251.15.174],
> dsn=4.0.0, stat=Deferred: Connection timed out with infozines.com.

Something is wrong here, sendmail doesn't retry that often (by
default).

First thing is that the connection is not left open, not from what is
shown in this log. This shows sendmail trying to deliver a message to
a server that doesn't respond (could be a firewall with no mail server
behind, for instance).

Second, it's probably not a bounce (unless you have a complex
configuration, i.e. sendmail doesn't accept messages it cannot deliver,
unless you told it to do it for some reason). You could see the
message that sendmail is trying to send by going into the mqueue
directory and looking at the 2 files that end with k8LMj0ci005712 (the
qf and df files) one has the description of the operation the other has
the message.

There's very little you can do if the other server doesn't respond.
Sendmail will keep trying for a default of 5 days
(Timeout.queuereturn).

Now the real problem, why is sendmail re-trying every 3 minutes?

You could just increase that time using MinQueueAge, which by defailt
is 0 (not set), but if you really had a queue run time of 1h this would
not be necessary. Somewhere you have the 3m queue run time setting,
probably in the parameters used to run sendmail. The MinQueueAge is
used for controlling fast queue run times in a way that new messages
get sent fast, but the ones that could not be sent are in a slower
frequency (so to speak).

HTH
--
René Berber