[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The anti-abuse rDNS check that FTP gave up
On 10/5/11 11:47 AM, Carl S. Gutekunst wrote:
Some will decide not to accept IPv6 connection. The size of this space
(~56,000 x 2^32) prefixes growing exponentially inhibits effective
address management. It seems this number is likely to flatten out at
about 340,000 x 2^32 prefixes. IMHO, the only method that might scale
would use something like DANE. Use of reverse DNS is simply nonsensical
at these numbers. What is worse, Dual-Stack Lite is likely to expose
IPv4 only MTAs to IPv6 through Dual-Stack Lite NAPT or 6rd. In which
case, what would a reverse pointer offer within private address space?
Keith Moore wrote:
Just imagine how many wrongly rejected emails aren't reported.
Stupid spam filtering mechanisms are a DoS attack on email.
The problem is nearly all of our anti-spam measures are empirical. We
all know a lot of people who swear by this, that, or the other check,
even if the only supporting evidence is that using that particular
mechanism cut down the number of complaints. And what works on one
stream fails miserably on another.
FWIW, I last looked at this problem about three years ago. I
specifically wanted to know if some form of RDNS checks might be
useful in cutting down the load on the content-based spam filters. (I
was also checking effect and utilization of SPF and TLS.) Note that
the purpose here was not to improve the catch rate. This was on a
stream that was already filtered by a short-lived (60 minute) IP
reputation filter, so that would reduce the message count from some
known spam sources; and most of the recipients were business users.
As I recall, my sample size was something around 10 million E-mails
from a single MX server in a load balanced cluster over a 24-hour
period. There was a weak correlation between spam and a simple
existence check for the PTR record. There was no correlation at all
for a stronger check, e.g., A record matches; a message that failed
the strong check was as likely to be judged ham as spam by the content