On 5 Mar 2019, at 11:37, Mayhem wrote:
The reason why I even suggested this is that I don't see a lot
different IP
addresses. I figured the Postfix system wouldn't need to cache that
many
"bad" IP addresses. You guys obviously see differently.
Random data point:
On my very tiny personal mail system, I've seen 105 different IPs
violate PREGREET in the past 24 hours. 51 of those had not been seen in
the past 30 days. I have seen 1509 unique IPs violating PREGREET in the
past 30 days, 1315 of which had not been seen for over 30 days prior to
their first offense of the period. None of these are from the vast
swaths of network space that I have permanently blocked from port 25 on
the system, including almost all of China, Viet Nam, AWS, and MS Azure.
I know that because I have an elaborate fail2ban-like rig that drops
PREGREET violators into firewall rules which live until they haven't
been hit for 30 days. I don't have stats handy for DNSBL hits at
postscreen time, but I can say that nearly all of the PREGREET violators
I see are on at least one DNSBL that I check in postscreen.
My mail logs rotate at 12AM every night, this is just one IP address
in 8.5
hours :
$ more /var/log/maillog | grep -c 'CONNECT from \[103\.129\.47\.19\]'
1004
That's just *one* IP address attempting to deliver spam 1000+ times.
Isn't
it a waste of the DNSBL resources telling me 1000 times in 8 hours
that this
IP address is up to no good?
Not so much, really.
If you're rejecting it due to Spamhaus Zen (where it is listed at the
moment in the "CSS" sub-list) and have a local caching recursive
resolver (which every mail system should have) you won't actually hit a
Spamhaus DNS server with a query for that IP more than 510 times in 8.5
hours, i.e. once per minute, because the record TTL is 60s. Spamhaus
sets its TTLs and caps on free service with a solid understanding of how
much its infrastructure can handle, how long various types of listing
are likely to persist, and how likely it is for a no longer valid
listing to have collateral damage. You can probably trust their judgment
on what is an acceptable query rate.
That's why it would be nice to blacklist the offending IP address for
24-48
hours and keep resources free for legitimate connections.
That's probably a bit long for CSS listings like this one. If you're
really concerned with pounding on DNSBL servers too hard, you might want
to consider making your own resolver enforce a minimum cache TTL around
5 minutes. This is not a universally available feature because it is
formally a violation of the DNS spec and is easy to mis-use, but there
are resolvers which will allow it. You should NOT do that on a resolver
that serves web browsers or push it much past 5 minutes for a MTA
client.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
