Den 31-01-2021 kl. 21:11 skrev Riccardo Alfieri: > > On 1/31/21 8:28 PM, Arne Jensen wrote: > >> Spamhaus (blacklist) will return 127.255.255.x responses, if you're >> over quota, using public resolvers or otherwise incorrect queries. >> >> > this is not completely true. As stated here: > https://www.spamhaus.org/news/article/788/spamhaus-dnsbl-return-codes-technical-update > we are giving 127.255.255.254 return codes if you are using public > resolver, but this is not completely enforced. > Not completely true, ... in which direction? The strict enforcement alone, where mentioning "will eventually return" would have been better?
As you are not documenting directly that it isn't a strict enforcement, I'd say the best assumption that one can take would be to believe that it is actually strict enforcement. However, documenting such things (e.g. in too specific details) can also cause other consequences, where it may indeed be better to leave such details as being mysterious. 127.255.255.x, 127.255.255.0/24 (as your site lists), or 127.255.255.* would all represent the same area, if you ask me, and looking at: https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 <https://www.spamhaus.org/faq/section/DNSBL%20Usage#200>: > 127.255.255.252 Any Typing error in DNSBL name > 127.255.255.254 Any Query via public/open resolver > 127.255.255.255 Any Excessive number of queries which was solely what I was referring to there. By doing so, I simply adhered the stuff mentioned on your own DNSBL Usage FAQ. > > This means that if you are using *very common* public resolvers (or if > your VM uses common VPS provider DNSs) you'll get a NXDOMAIN response, > that will dramatically lower spam detection, while not giving useful > response too. This had to be done because some (misconfigured) MTAs > interprets any response different than NXDOMAIN as "LISTED". > Just like the phrases mentioned on the link you mention: > [...], it is vitally important that software developers implement all > return codes correctly, and not treat these error codes as any sort of > reputation or "listed" values. and > Any software which does not distinguish response codes from Spamhaus > DNSBLs is, unfortunately, already out of date and may not be reliable > in these or other cases which are both very correct. People should care more for the software and servers they run, and they wouldn't run in to that many problems, which was the whole point. > > And we really don't want to cause unnecessary FPs. > Thumbs up for this, and I do not endorse (purposefully) causing FPs either. That being said, if the 127.255.255.0/24 one causes any FPs, Spamhaus wouldn't be the ones to blame. Even if Spamhaus were returning the querier IP for results over e.g. open resolvers, and that caused FPs, Spamhaus wouldn't really be the "bad party" here, as Spamhaus have always seemed to have listed the proper return codes, e.g. 127.0.0.0/24 for the IP zones. The other end would be the place to blame for carelessly doing their stuff, including, but not limited to such as e.g. deciding which software / implementation to use. If Spamhaus returned 127.0.0.2 (or other "negative codes") to all queries over public resolvers, or something similar, then yes, then Spamhaus would purposefully be making FPs. But otherwise, then the blame isn't to be put on Spamhaus. But as far as I have understood over the years, you had only previously been dropping queries (which could actually lead to potentially long timeouts, at some misconfigured systems, where the other end might give up..). > Sorry for vendor spam, but I felt this had to be outlined > Likewise, it wasn't my purpose to do any sort of spamming/advertising, even if it could be seen that way. Sometimes things just makes better sense with examples. -- Med venlig hilsen / Kind regards, Arne Jensen
