Re: [exim] problem with spamd (connection time out)

トップ ページ
このメッセージを削除
このメッセージに返信
著者: W B Hacker
日付:  
To: exim users
題目: Re: [exim] problem with spamd (connection time out)
the sew wrote:

> Hi,
>
> I'm not much of a exim expert, even though it works for what I want to
> achieve, we also handle of alot of mail and my spamd was also taking heavy
> beating
>
> I've added a line that dont scan messages over 200k of size and works like a
> charm, I would also suggest greylisting, reduced our spam quite alot
>
> # Messages larger than 200k are accepted without spam scanning
> accept condition = ${if >{$message_size}{200k}{true}}
>
>
> Out of interest some greylisting stats
>
> Of 451253 items that were initially greylisted:
> - 56502 ( 12.5%) became whitelisted
> - 394751 ( 87.5%) expired from the greylist
>
> anyway, hope it helps
>
> Sew


But does not greylisting also mean that:

- every arrival, accepted OR rejected, required that a lookup be made against a
flat file or DB to see if the sender had 'passed' greylisting (been whitelisted)
and no longer needed to wait. Over half a million such, per above, and how many
(if any) of those lookups were, or could be, usefully 'cached'?

- for each new arrival that had NOT 'passed', some form of 'first time seen'
list or DB entry with a timestamp needed to be written. Is that not 451,253 writes?

- for each subsequent 'retry' attempt received before the timeout, the
'greylist' DB/file must again be checked, also with some timestamp calculating?.
Also not cacheable, AFAIK.

Better than calling up an SA perl script?
Probably much better - even if the greylisting was also done in perl.

But how many of those 394,751 'gone walkabout' had/would have either failed
forward/reverse DNS resolution, been found in a dynamic-IP BL, or found in some
other reasonably trustworthy RBL?

- all of which are DNS-like lookups that *are* cached, by the closest upstream
nameserver, if not by Exim itself, or, for heavy-hitters, by a purpose-built
local caching nameserver of your own.

IMNSHO, that's a lower load than greylisting any way you cut it.

Much lower.

And for those who believe that greylisting generates no false-positive
rejections, just have a look at the destination hosts marked as unreachable, and
how long it takes for them to expire from a cache or hints db unless you spot
that problem and nuke same.

Not saying the greylisting approach is useless.

But I can't see it as anything like optimal.

Bill



>
>
>
> On 9/29/06, Balzi Andrea <andrea.balzi@???> wrote:
>
>>Hi
>>
>>I've a new problem with spamassassin :(
>>In to my main.log i found the follow line:
>>
>>spam acl condition: error reading from spamd socket: Connection timed
>>out
>>
>>My server have 2 CPU Intel Xeon 3.00GHz with 4GB RAM.
>>
>>pamassassin start with the follow command:
>>
>>/usr/sbin/spamd --syslog=local4 --create-prefs --max-children 5
>>--helper-home-dir -d --pidfile=/var/run/spamd.pid
>>
>>There is some solution in order to delay the forward of the mails to
>>spamassassin to prevent the Time out?
>>
>>Andrea
>>
>>--
>>## List details at http://www.exim.org/mailman/listinfo/exim-users
>>## Exim details at http://www.exim.org/
>>## Please use the Wiki with this list - http://www.exim.org/eximwiki/
>>