Re: [exim] Anti SPAM Exim configuration

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] Anti SPAM Exim configuration
Marc Perkel wrote:
>
> W B Hacker wrote:
>> Matthias wrote:
>>
>>> Hello,
>>>
>>> Alexander Prohorenko Wrote:
>>>
>>>> Tony,
>>>>
>>>> What can you advise, except spending hours daily filtering mail from
>>>> SPAM manually?
>>>>
>>> DynaStop may well help in your filtering. It can stop all spam from
>>> dynamic IP addresses (dialup and DHCP residential).
>>>
>>> its at http://tanaya.net/DynaStop/
>>>
>>> There is also a new forum at exim-users under Add-Ons.
>>>
>>>
>>>
>> Looked at the code.
>>
>> We have been using a wildcarded regexp block list with <1,000 members in a
>> similar manner for more than a year. But far, far less clever substring matching.
>>
>> JM2CW, but possible pro and con:
>>
>> Pro:
>>
>> - Should work largely as advertised.
>>
>> Con:
>>
>> - Should be expected to return more false-positives AND misses than an actively
>> maintained RBL of dynamic-IP's, if only because of updating/NOT.
>>
>> - but the far bigger drawback is that there is no 'free lunch' w/r substring
>> matching.
>>
>> Whereas RBL hits are cached by Exim, the upstream, or a bespoke local DNS
>> implemented for the purpose, using a simple and efficient DNS lookup...
>>
>> ..by contrast, this critter requires, (SWAG), probably 3 or greater orders of
>> magnitude more CPU cycles than a DNS lookup uses.
>>
>> Ergo:
>>
>> IF {AND {CPU cycles to burn} {marginal DNS}{DOIT}{NOT}}
>>
>> Check your server load with/without the tool.
>>
>> YMMV,
>>
>> Bill
>>
>>
>>
>
> Bill, might be good as a greylist.


Meaning in terms of resource consumption? Or effectiveness?

For *our* arrivals, we cannot justify the greylisting concept. YMMV.

> Suppose you had your lowest MX do a
> DEFER based on this list and your next highest MX not do defer.


I cannot justify multiple MX against 'seamless' ways to handle failover. YOMD.

> Bots
> usually don't retry


Most of the ones that hit us DO retry, and at just the interval that would
defeat a typical greylist timeout. Their designers must read mailing lists.

> so if you get it wrong on this list you don't lose
> any mail.


We don't lose much - not unintentionally anyway.

> But for bots that use the lowest MX it could make a lot of
> spam go away.
>


They 'go away' just fine w/o that complexity.

> Or - you could just add a header and let Spamassassin score it as well.
>


Different thread. This is about things one can do *before* accepting
header-message DATA.

Bill