Hi,
>>> smtpd_recipient_restrictions =
>>> reject_rbl_client bl.spamcop.net,
>>> reject_rbl_client list.dsbl.org,
>>> reject_rbl_client sbl-xbl.spamhaus.org,
>>> reject_rbl_client cbl.abuseat.org,
>>> reject_rbl_client dul.dnsbl.sorbs.net,
>>
>> Several of those are combined into ZEN. If you use Zen instead you'll
>> save some DNS queries. See the Spamhaus link I provided earlier for
>> details, I don't offhand remember which ones go into ZEN.
>
> Per Noel's advice, I have shortened the list (dsbl.org is defunct) and
> acted upon your mutual suggestion regarding ZEN:
>
> reject_rbl_client bl.spamcop.net,
> reject_rbl_client zen.spamhaus.org,
> reject_rbl_client dnsbl.sorbs.net,
I've also started using the following, but it could be specific to postfix v2.9:
reject_rhsbl_reverse_client zen.spamhaus.org,
reject_rhsbl_sender zen.spamhaus.org,
reject_rhsbl_helo zen.spamhaus.org,
Are you using rbl_reply_maps? Prior to postscreen, I was using it in this way:
rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps
I'm not sure it's necessary in your situation. You can find more about
this here:
http://www.postfix.org/STRESS_README.html
No doubt the guys on this list have been incredibly helpful in the
past. I'd like to thank them again as well.
> Okay, good. Bowie's response to this question differed (he suggested
> that Amavis would need to be restarted for Bayes to be updated), but I'm
> pretty sure that restarting Amavis is not necessary. It seems unlikely
> that Amavis would copy the entire Bayes DB (which is stored in MySQL on
> this server) into memory every time that the Amavis service is started.
> To do so seems self-defeating: more RAM usage, worse performance, etc.
I also don't believe it's necessary to restart amavisd when changes
are made to bayes. I'm also using mysql. I just wish replication was
faster, or it would use it across my multiple mail servers. Instead, I
have to have multiple separate mysql bayes databases, each with their
own tokens, corpus that's used for training, etc, despite it all being
for a single domain.
Regarding restarting amavisd, this is always frustrating to me. I'm
sometimes making changes very frequently, and amavisd doesn't always
restart reliably. Despite a "service amavisd stop" on fedora, it
doesn't completely stop, but instead just goes catatonic and requires
me to manually kill it.
I've asked on the amavisd list, but no one has been able to help. I've
tried just issuing a "reload" but that doesn't always work either.
Does anyone know if it's possible to send it a signal or a way to more
reliably signal amavisd?
Thanks,
Alex
