Sidney Markowitz <sid...@sidney.com> writes:
> The third is the correct return code to indicate blocking for
> overuse. When SpamAssassin sees that, it hits a rule whose description
> is supposed to inform whoever looks at the mail headers or spam report
> that the ISP has misconfigured their SpamAssassin server's DNS or is
> at a usage level that requires a paid subscription to dnswl. In
> addition, to reduce the excessive load on dnswl, when SpamAssassin
> sees that code it temporarily disables further queries to dnswl, I
> think for the life of the running process. So we do what we can to
> make the 127.0.0.255 code have a useful effect.
It looks to me like there may be a middle ground that works for both SA
and dnswl.
the primary method for overuse is to return 127.0.0.255 (not sure
that's true vs SERVFAIL, but seems it could be)
SA is coded to stop querying on receipt of blocked (already true)
dnswl will only return a fake hi response if
- persistent overquerying
- the overquerying is not consistent with SA's behavior of stopping
queries on receipt of 127.0.0.255
- at most 1 in N, for N somewhere between 2 and 10
This should result in
- any SA installations stopping querying
- send the spam-getting-through signal to abusers
- false signals to SA installations limited to situations where they
are sharing a nameserver with an abuser, and then only rarely, as
a process should stop on receipt of a single 127.0.0.255
Another thought is for SA to have way to send a dns query, perhaps to
ASF infrastructure, perhaps to someplace else, to figure out if it's
using shared DNS, and to refrain from dns queries entirely if so.
Then we can take "SA is sharing a resolver with abusers" off the table.
