https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #17 from AXB <[email protected]> --- (In reply to Henrik Krohns from comment #16) > Well it took a while to come up with an "optimal" solution. Hopefully you > will like this. > > Sending lib/Mail/SpamAssassin/AsyncLoop.pm > Sending lib/Mail/SpamAssassin/Conf.pm > Sending lib/Mail/SpamAssassin/PerMsgStatus.pm > Transmitting file data ...done > Committing transaction... > Committed revision 1842098. > > dns_block_rule RULE domain > If rule named RULE is hit, DNS queries to specified domain are > temporarily blocked. Intended to be used with rules that check RBL > return codes for specific blocked status. For example: > > urirhssub URIBL_BLOCKED multi.uribl.com. A 1 > dns_block_rule URIBL_BLOCKED multi.uribl.com > > Block status is maintained across all processes by empty statefile in > userstate directory (~/.spamassassin/dnsblock_multi.uribl.com). > > dns_block_time (default: 300) > dns_block_rule query blockage will last this many seconds. > > It's extremely simple, works also with spamd, and takes no resources at all, > one stat() call per dns_block_rule per message is not even worth mentioning > nor debating. > > I figured 5 minutes would be a better value than hour, in case something > goes wrong (bad dns response of such?), then it's not blocked for too long. > Imo, someone making max dozens of requests per 5 minutes or 1 hour makes > zero difference. Also there will be more warns in log this way. > > Must be enclosed with feature_dns_block_rule > > if can(Mail::SpamAssassin::Conf::feature_dns_block_rule) > dns_block_rule SURBL_BLOCKED multi.surbl.org > dns_block_rule URIBL_BLOCKED multi.uribl.com > dns_block_rule RCVD_IN_DNSWL_BLOCKED list.dnswl.org > endif > > Waiting for approval to commit that :-) I like it - you have my +1 -- You are receiving this mail because: You are the assignee for the bug.
