|Main Archive Page > Month Archives > spamassassin-dev archives|
--- Comment #5 from AXB <email@example.com> 2011-12-13 16:35:23 UTC ---
(In reply to comment #3)
> FYI, per URIBL:
> We block at the bind level with split horizon. So we return an NS record which
> resolves to 127.0.0.255. So a recursive NS would receive that NS record and
> have no where else to go. Effectively black holing it. Perhaps this should be
> changed to something other than 127.0.0.255 to avoid confusion... maybe
> 127.0.0.1 would be better, or 127.0.0.0.
> We do not respond with REFUSED at the bind level, as that just creates
> unnecessary added volume.
> The only reason we use acl.rbldnsd at the rbldnsd level is to :refuse queries
> that are made directly to the rbldnsd nodes. So if someone tries to bypass the
> split-horizon response upstream by hard-coding known good public mirrors IPs,
> they will still get a :refuse.
> So the policy differs from implementation and hopefully URIBL will follow suit
> with a BLOCKED rule as noted above.
till SA does some magic, one could add a ruleset like:
urirhssub URIBL_BLACK_BLOCKED multi.uribl.com. A 255
describe URIBL_BLACK_BLOCKED DNS IP blocked from querying URIBL.com
tflags URIBL_BLACK_BLOCKED net
score URIBL_BLACK_BLOCKED -1.8
urirhssub URIBL_GREY_BLOCKED multi.uribl.com. A 255
body URIBL_GREY_BLOCKED eval:check_uridnsbl('URIBL_GREY_BLOCK')
describe URIBL_GREY_BLOCKED DNS IP blocked from querying URIBL.com
tflags URIBL_GREY_BLOCKED net
score URIBL_GREY_BLOCKED -0,5
urirhssub URIBL_RED_BLOCK multi.uribl.com. A 255
body URIBL_RED_BLOCK eval:check_uridnsbl('URIBL_RED_BLOCK')
describe URIBL_RED_BLOCK DNS IP blocked from querying URIBL.com
tflags URIBL_RED_BLOCK net
score URIBL_RED_BLOCK 0.001
That would get the message thru, without hurting
-- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.