Marc Haber wrote:
> On Fri, 10 Nov 2006 22:12:25 +0800, W B Hacker <[EMAIL PROTECTED]>
> wrote:
>> But specifically NOT allowing pipelining (and enforcing sync) tosses off a
>> whole
>> 'nuther class of spambots.
>
> I have always thought that these were caught before PIPELINING was
> advertised
Marc Haber wrote:
> On Fri, 10 Nov 2006 22:12:25 +0800, W B Hacker <[EMAIL PROTECTED]>
> wrote:
>> But specifically NOT allowing pipelining (and enforcing sync) tosses off a
>> whole
>> 'nuther class of spambots.
>
> I have always thought that these were caught before PIPELINING was
> advertised
On Fri, 10 Nov 2006 22:12:25 +0800, W B Hacker <[EMAIL PROTECTED]>
wrote:
>But specifically NOT allowing pipelining (and enforcing sync) tosses off a
>whole
>'nuther class of spambots.
I have always thought that these were caught before PIPELINING was
advertised? Is it adviseable to switch off P
Steffen Heil wrote:
> Hi
>
>> For some months now we have used a HELO ACL to delay by
>> 35 seconds all connections with suspicious looking HELOs.
>
> Looks a little long for me.
>
>> This is very effective at reducing the amount of spam that
>> our servers receive, while not preventing "real"
Hi
> For some months now we have used a HELO ACL to delay by
> 35 seconds all connections with suspicious looking HELOs.
Looks a little long for me.
> This is very effective at reducing the amount of spam that
> our servers receive, while not preventing "real"
> email getting through, because
Clive Goodhead wrote:
> For some months now we have used a HELO ACL to delay by
> 35 seconds all connections with suspicious looking HELOs.
I agree with other people that processes, at least on Unix
aren't all that expensive. However, if your processing
involves database lookups, the cost of an
quite enough.
>
>> Of course, the only resources you need to worry about are process
>> count (some systems have limits to the number of concurrent processes, so
>> you should find out what your limit is), and RAM. The waiting process
>> won't actually do any processing, disk access or network ac
On Fri, Nov 10, 2006 at 11:56:17AM -, Clive Goodhead wrote:
> Do you have any ideas, however, on how I can find out how much
> RAM a delayed process will use? We use Exim 4.63 and FreeBSD 4.11
> on our current production servers.
Rather than trying to predict it, measure it. Write a test
progr
>
>
> --On 10 November 2006 10:31:38 + Clive Goodhead
<[EMAIL PROTECTED]> wrote:
>
> > For some months now we have used a HELO ACL to delay by
> > 35 seconds all connections with suspicious looking HELOs.
> > This is very effective at reducing the amount of spam
> > that our servers receive, wh
> "Ian" == Ian Eiloart <[EMAIL PROTECTED]> writes:
>> For some months now we have used a HELO ACL to delay by 35 seconds
>> all connections with suspicious looking HELOs. This is very
>> effective at reducing the amount of spam that our servers receive,
>> while not preventing "real" emai
--On 10 November 2006 10:31:38 + Clive Goodhead <[EMAIL PROTECTED]> wrote:
> For some months now we have used a HELO ACL to delay by
> 35 seconds all connections with suspicious looking HELOs.
> This is very effective at reducing the amount of spam
> that our servers receive, while not preve
On Fri, Nov 10, 2006 at 10:31:38AM -, Clive Goodhead wrote:
> For some months now we have used a HELO ACL to delay by
> 35 seconds all connections with suspicious looking HELOs.
> This is very effective at reducing the amount of spam
> that our servers receive, while not preventing "real"
>
For some months now we have used a HELO ACL to delay by
35 seconds all connections with suspicious looking HELOs.
This is very effective at reducing the amount of spam
that our servers receive, while not preventing "real"
email getting through, because much of the current
spamming software see
13 matches
Mail list logo
