https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #11 from D. Stussy <[email protected]> 2011-12-16 01:51:18 UTC --- "So you want to trigger blocked for anything outside of 127.0.0/24 or 127/8?" Yes - to 127/8 (127.0.0.0/255.0.0.0). RFC 5782 permits anything in 127/8, so there is no reason to restrict it to the /24. Furthermore, there are some lists (e.g. hostkarma.junkemailfilter.com) which do return codes within the /8 but outside the /24 (for various experimental things like "does the server issue QUIT?" = 127.0.1.[0-2]). A am against the use of "127.0.0.255" to mean "query refused due to abuse and/or excessive traffic" because it is within the valid range of 127/8, yet yields no information as to actual information answering the query. It can be easily mistaken for a valid answer. "Not available/go away" is not the same as "listed" nor "unlisted." The fact that it is an answer in the valid range is the very reason why we have the FP/FN problem in the first place -- we considered it a valid answer. As "0.0.0.0" is outside the valid range for an informational answer AND also not a valid unicast address, that's why I suggested it for a "null answer." Another suitable value of all one's (255.255.255.255) as a refusal indicator was considered and rejected. A single-bit error in the MSB which gets past any application layer error detection could be confused with a valid answer. "0.0.0.0" triggering a block implies an explicit block from an active list, vs. a "random" unicast address triggering a block, implying a decommissioned list. The software could but need not distinguish between the cases. If it were to distinguish, then the non-all-zero address would permanently block (until manual intervention). Although I agree with an initial one-hour delay, the TTL amount on the record in question when one is returned could also, if higher (than 3600), be the initial count for the recheck timer (when the A-RR value is outside 127/8). -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
