On 2021-08-06 11:25, Marcin Mirosław wrote:
The other thing I did on my masscheck box was to configure my DNS
resolver with a minimum TTL of some hours. Since we are checking mail
that is relatively ancient anyway, who cares if a particular DNS request
is 5 minutes or 3 hours old? This reduced the number of DNS queries
hitting "the world" considerably and was probably sufficient to stay
under limits. Be sure to increase the negative TTL cache as well.
But long TTL doesn't help when masscheck will be checking 2 month old
emails.
In practice, it helps a lot.
Each masscheck run will still need to query each sender IP on each
DNSBL, but now only once (per IP, per DNSBL, per masscheck run).
My masscheck took over an hour to finish, so I asked myself what value
is there in asking if each of Google's outbound IPs are listed a hundred
times in a row when I could just ask once and trust that answer for the
duration. Turns out it got the masscheck process running a decent amount
faster too, narrowing the gap between the daily and weekly net run
significantly. The cache rate was a lot higher than I expected too.
Henrik mentioned to use "--reuse" but I don't use header X-Spam-Status :/
Anyway, where is a problem, why masscheck have to query all uribl/dnsbl?
It needs a lot of time for devs?
There is value when DNSBLs are being evaluated. I used it in this
fashion, but I'm unclear if anyone writing rules does (or can).
The older the corpus, and the more dynamic a DNSBL, the less value there
will be. But conversely if I see a DNSBL's ham hitrate go up, it likely
doesn't matter how old the corpus is, there is likely a problem with the
DNSBL. Or an ESP playing games switching their spammy and non-spammy
ranges around.
I'm not sure if the data would be useful as collected from masscheckers,
I certainly looked closer at the specifics before making any decisions,
but there was value to me, at the time. Whether this extends to having
all masscheckers do this weekly or not is unclear to me.
