Den 13-05-2021 kl. 02:19 skrev Michael B Allen: > On Wed, May 12, 2021 at 6:10 PM Matthias Leisi <matth...@leisi.net> wrote: >>> That is unfortunate. It's not entirely crystal clear to me that >>> deliberately returning false positives that allow potentially >>> destructive SPAM to get through filters is a good way to enforce usage >>> policy. >> We use the „return hi“ in cases where long times of using other methods does >> not reduce the query load on the free nameservers. > I don't understand the technical details of all of this but what about > sending an error response just under the typical retry interval? If > you want to annoy someone, make it the one DNS server operator and not > the hundreds of SA endpoints using it. A lot of smaller companies like > me (I'm just me!) just use their hosting company DNS (linode for me) > and are completely oblivious as to what dnswl even is.
See: https://www.mail-archive.com/users@spamassassin.apache.org/msg107949.html <https://www.mail-archive.com/users@spamassassin.apache.org/msg107949.html> And then try to understand how DNS works: You're sending a query, for example to Quad 9 's resolver, on it's IP address 9.9.9.9, and in this example, from a location in Denmark. $ dig TXT o-o.myaddr.l.google.com @9.9.9.9 o-o.myaddr.l.google.com. 47 IN TXT "188.122.68.219" This reveals that Google sees the DNS request as coming from 188.122.68.219. 188.122.68.219 is owned/operated by i3d.net, and according to the public information, that IP address seems to be a part of their network/infrastructure in Germany. So here, you're technically hiding behind someone else's identity (IP address) to perform the query towards the final network, as they are literally your middleman here. No DNSBL/WL can see through your "middleman" and detect your personal(/organisational) quota independently, when you're all hiding behind the same "middleman". The only thing being seen here, is the IP address of that particular "middleman", and as such, all queries behind that middleman are all being aggregated together, towards the total limit of 100'000 queries/24h. Things such as e.g. trying to reach out to i3d.net's abuse desk, from the example shown above, where the originating IP belongs their organisation, doesn't work, at all. See: -> https://www.dnswl.org/?p=120 <https://www.dnswl.org/?p=120> -> https://www.dnswl.org/?p=118 <https://www.dnswl.org/?p=118> -> https://www.dnswl.org/?p=183 <https://www.dnswl.org/?p=183> > > Maybe you would prefer that SA disable dnswl lookups in the default > config? Folks who are fluent in such things and have their own DNS > server will know how to flip it on. May I ask if you are actually reading and following the documentation about the things you run? -> https://cwiki.apache.org/confluence/display/SPAMASSASSIN/CachingNameserver <https://cwiki.apache.org/confluence/display/SPAMASSASSIN/CachingNameserver> It is not only just the best practice with a local resolver, but is as close as it can be to "mandatory" with many block/welcome lists, such as e.g. URIBL, Spamhaus, and several others. At the link above, you want to make sure you catch the "NOTE:"-line. In the past, I saw Spamhaus being criticized, apparently for something that sounded like dropping queries with a firewall, which would lead to long timeouts, causing the originating mail server to give up before the responses were received, essentially leading to mails being deferred and (sometimes) lost. Such query dropping does (unfortunately) also means the queries often will be magnified, as e.g. Linode's resolver in your case, will just try another authoritative server for the zone. That "returnhi" option is only used for a minority, and only in the very extreme cases where other attempts have been tried, but with no positive success for a long while, - which is also being mentioned in the link from the top of this post. In the end, there is no perfect solution that simply works for everyone, and everything, at once. It would of course be nice, ... if there was... -- Med venlig hilsen / Kind regards, Arne Jensen
