[Mimedefang] Greylisting - Too many open connections

Michael Lang michi+mimedefang at relay3.jackal-net.at
Fri Nov 3 13:48:19 EST 2006


On Fri, 2006-11-03 at 13:38 +0000, Carlton Thomas wrote:
> Hi,
> 
> I have implemented greylisting in Mimedefang and all works
> well until the mail server gets very busy. When it gets
> busy there is a rapid increase in the number of Mimedefang,
> Sendmail and MySql processes. When the sendmail connections
> are examined, most of them are in the "RCPT TO" state, and
> they just hang around in that state for a long time. I am
> assuming that this is happening because sendmail has
> rejected the message  but the client is still holding the
> connection open, either to attempt immediate retries or
> because it does not understand the TEMPFAIL.
> 
> The call to the greylisting code is made in Filter_Recipient
> as per recommendations from various messages to this list.
> I have also searched the list archive to see whether others
> have had this problem but found only a couple of related
> posts but no solutions.
> 
> Has anybody else managed to get sendmail to terminate the
> connection when a message is tempfailed from within the
> filter_recipient routine? If that is not possible, what
> have others been doing to get rid of the connection in
> order to minimise the number of active sendmail processes?
> 
> I did see a message in which someone stated that tempfailing
> a message with the 421 code would cause sendmail to terminate
> the active connection. I have tried that but it does not seem
> to work for me and I have also seen others saying that it is
> not possible for a milter to force sendmail to terminate a
> connection.
> 
> Any help or guidance on this subject woul be most appreciated.

Hi Carlton,

it's not possible to terminate the connection in filter_recipient,
it has been on the list before (if you want to get in details), but try
using sendmails connection handling/throttle

in sendmail.mc
define(`confBAD_RCPT_THROTTLE', `2')dnl
define(`confCONNECTION_RATE_THROTTLE', `5')dnl
FEATURE(`ratecontrol', `nodelay')dnl

in access file 
# conns/timeunit
ClientRate:127.0.0.1            0
# internalClients
ClientRate:192.168.0.0		5
# default handling
ClientRate:                     2

# conns/total
ClientConn:127.0.0.1            0
# internalClients
ClientConn:192.168.0.0		5
# default handling
ClientConn:                     2

this settings can help you manage a large number of same/different
Client connections to your MTA but will not help you getting the
processes down, so maybe moving the SQL processes to another machine
might be helpful too.

Kind regards
Michael Lang

> 
> Regards !
> 
> --
> Carlton
> =============================
> GIFFORD INTERNET SERVICES
> Bristol, United Kingdom
> Tel: 0845 868 2245
> Fax: 0845 004 6843
> Email: admin at gifford.co.uk
> =============================
> _______________________________________________
> NOTE: If there is a disclaimer or other legal boilerplate in the above
> message, it is NULL AND VOID.  You may ignore it.
> 
> Visit http://www.mimedefang.org and http://www.roaringpenguin.com
> MIMEDefang mailing list MIMEDefang at lists.roaringpenguin.com
> http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
-- 
Michael Lang <michi+mimedefang at relay3.jackal-net.at>




More information about the MIMEDefang mailing list