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 <[EMAIL PROTECTED]> 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/
>>


-- 
## 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/

Reply via email to