Vladimir Koshelenko wrote:
> Здравствуйте.
>
> В сообщении от 30 марта 2007 Ian Eiloart написал(a):
>
>> --On 29 March 2007 08:06:39 -0700 Marc Perkel <marc@???> wrote:
>>
>>> We know it's not useful but there are a lot of admins out there who
>>> don't know it and will end up blocking our servers because their
>>> blacklist is listed on places like DNSstuff along with all the
>>> legitimate lists.
>>>
>> And that's a pain in the butt, because it makes work for us. For example,
>> some of my users (university staff) were unable to contact the schools that
>> their children attend. It took work for me to persuade the remote admins to
>> stop using a particular RBL.
>>
>> It's also a frequently asked question here: "which RBLs should I use?"
>>
>> Is there a central, trusted resource for evaluating RBLs? Would a page on
>> the wiki be useful? I'd like something authoritative that I can point
>> remote admins to.
>>
>
> Personally, I use zen.spamhaus.org
> You can use *any* RBL - just do not block mail, if you do not want to lost
> mail. Try to impose delay 20s after every SMTP command if sender sits in RBL.
> Most spammers will not deal with such slow server.
>
> Example:
>
> acl_check_connect:
>
> warn
> dnslists = zen.spamhaus.org
> set acl_c_delay = true
> ...
> ...
> accept
> set acl_c_wait = ${if def:acl_c_delay {20}{0}}
> delay = ${acl_c_wait}s
>
>
> and in every ACL add this instead plain accept:
>
> accept
> set acl_c_wait = ${if def:acl_c_delay {20}{0}}
> delay = ${acl_c_wait}s
>
>
I have several levels of MX records. I bounce email listed with
Spamhause. But for other RBLs I do a defer on the lowest MX but accept
them on the next level up. If they retry then they get in.
