https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6724
D. Stussy <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |software+spamassassin@kd6lv | |w.ampr.org --- Comment #16 from D. Stussy <[email protected]> 2011-12-13 20:53:44 UTC --- RE - Comment #14: We don't have to rely on a draft but can rely on the most current published RFC (5782) on the topic which says the same thing. Presumedly, the cited draft would update or obsolete that RFC. The issue then becomes: Should we drop any use of a DNS-based-list which does not follow follow RFC 5782 (and its successors), especially when they return codes in the 127/8 range which are not meant to be actual determinations of the data they contain? I say yes. From RFC 1035, refusal to answer should be signalled with a "REFUSED" query RC, but if data were returned, it should indicate an A record with an address OUTSIDE of 127/8. I would personally suggest to these DNS-list maintainers returning "0.0.0.0" to indicate a non-response. All-zeros makes sense for a "null answer." Defining a "non-response due to abuse" code within 127/8 is irresponsible considering the BCP of the RFC. In a prior post (in a related issue), I did consider (and rejected the decision) that SA test for validity all DNS-lists upon startup by querying for "127.0.0.1" (NXDOMAIN or 0 answers expected) and "127.0.0.2" (1+ answer(s) expected). I rejected that position because if the entire world (or a significant portion) rebooted at once, we would effectively be executing a denial of service attack (by flooding) on the DNS-lists. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
