|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: mouss (mouss
ml.netoyen.net)
Date: Mon Aug 03 2009 - 00:43:48 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Charles Sprickman a écrit :
> On Sun, 2 Aug 2009, Willy De la Court wrote:
>
>> On Sun, 02 Aug 2009 11:24:17 +0100, Clunk Werclick
>> <clunk.werclick
wibblywobblyteapot.co.uk> wrote:
> [snip]
>>> reject_rbl_client no-more-funn.moensted.dk
>>> reject_rbl_client bl.spamcop.net
>>> reject_rbl_client dnsbl-1.uceprotect.net
>>> reject_rbl_client dnsbl-2.uceprotect.net
>>> reject_rbl_client dnsbl-3.uceprotect.net
>>> reject_rbl_client dnsbl.sorbs.net
>>> reject_rbl_client bl.spamcannibal.org
>>> reject_rbl_client spam.dnsbl.sorbs.net
>>> reject_rbl_client zen.spamhaus.org
>>> reject_rbl_client b.barracudacentral.org
>>> permit
>> [SNIP]
>>
>> wow a lot of rbls. I used to use some of these but got a lot of
>> complaints
>> so i'm sticking with just spamcop and spamhaus.
>
> I'm still figuring things out, and have not really went very deep into
> spam prevention at this point. My question about the rbl rejects at the
> smtp level is whether it's possible to only apply this to certain
> domains/accounts without resorting ot using a policy daemon. I'm
> guessing no, but that may just be my old qmail pessimism. :)
>
if it depends on client, helo, sender or recipient, then you can use
restriction classes.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]