I think the other thing is that his smtp concurrency via tcpserver is serving
a dual purpose in that it's providing enough concurrency for his internal people
as well as for MX traffic. That means it has to be set fairly high so that his
internal people always get a connection.
I'd be inclined to put the MX on a separate (multi-homed) address running a separate
instance of tcpserver which has a *much* lower concurrency than 300 and have the
original
tcpserver concurrency set to something lower to match the internal requirements.
Other possibilities are to lower the concurrencylocal on an instance of qmail that
handles MX traffic so that even if a spammer gets thru the delivery is distributed
across greater time.
Regards.
On Mon, Mar 27, 2000 at 01:22:12PM -0500, [EMAIL PROTECTED] wrote:
> >> On Mon, 27 Mar 2000 10:53:27 -0600,
> >> Greg Moeller <[EMAIL PROTECTED]> said:
>
> G> Normally it keeps up pretty good, but when there's heavy spamming it can
> G> start to get behind with between 10,000 and 20,000 Email in the queue.
>
> If spamming is the main problem, have you looked into tarpitting?
>
> Date: Thu, 11 Feb 1999 10:32:36 -0500
> To: [EMAIL PROTECTED]
> Subject: Tarpitting
> Message-ID: <[EMAIL PROTECTED]>
> From: Chris Johnson <[EMAIL PROTECTED]>
>
> There was some discussion a while back about tarpitting. If you don't
> know what that is (I didn't when it first came up), it's the process
> of inserting a small sleep in an SMTP session for each RCPT TO after
> some set number of RCPT TOs. The idea is to thwart spammers who would
> hand your SMTP server a single message with a long list of RCPT TOs.
> [...]
>
> See http://www.palomine.net/qmail/tarpit.patch.
>
> --
> Karl Vogel
> ASC/YCOA, Wright-Patterson AFB, OH 45433, USA
> [EMAIL PROTECTED] or [EMAIL PROTECTED]
