On Wed, Jun 6, 2018 at 4:48 PM Rob McEwen <r...@invaluement.com> wrote:
> On 6/6/2018 6:32 PM, Steve Atkins wrote: > > To answer the question in the title: "Probably, yes. Only if your spam > filtering is bad." As Rob mentions in his article in the case he's discussing > the spam would have been blocked if they'd had better spam filtering in place. > > > Steve, > > (1) in that particular example, the technology used (uri blacklists > checking domains in the body of the message) only applies to a subset of > all incoming IPv6 spams, and the portion it doesn't apply to is very > significant. > > (2) Also, had my subscriber (discussed in that article) not published IPv6 > MX records, those incoming IPv6 spams would have been sent via IPv4, and > MUCH of that spam would have been easily blocked by low-FP IPv4 blacklists > like Spamhaus' IPv4 blacklists and invaluement's IPv4 blacklists. In > contrast, IPv6 filtering cannot possibly scale as well as IPv4 since the > resulting increase in content filtering would be order of magnitudes more > resource-expensive (CPU and RAM) than blocking so many of those connections > via low-FP IPv4 blacklists at the perimeter. (especially when running the > IPv4 lists locally in rbldnsd) > > Therefore, because of (1), IPv6 spam filtering can't possibly be *as* > good (all else being equal) as spam filtering on a system that only accepts > IPv4 connections. Because of (2) the filtering can't be as fast/efficient > and doesn't scale nearly as well as IPv4 filtering - and the quality of > one's content spam filtering doesn't change that. In fact, filtering IPv6 > spam will cause an INCREASE in necessary investments in more types of > content filtering (to compensate for these not being blockable anymore via > IPv4 blacklists), and that only further exacerbates the resource problems, > which then only makes IPv6 filtering even LESS scalable. > > Steve - you have some valid points, but I think your "probably, yes" > answer to the question in the title of my article fails to factor in these > things. Due to these things I mentioned above, even someone with "good > filtering" (who publishes IPv6 MX records) is still going to need EVEN MORE > resource-expensive content filtering, which will require MORE hardware to > run this increased content filtering, and such increases in content > filtering does not scale very well (or at least don't scale > inexpensively!). Also, their content filtering is STILL going to have some > false positives in situations where the spam would have been easily blocked > by IP4v blacklists had those IPv6 MX records not been published, and the > content filtering missed. Also, the example of that spam being blockable > via ivmURI was somewhat anecdotal. While ivmURI can greatly help to block > IPv6-sent spams that otherwise would have been blocked by IPv4 IP > blacklists, ivmURI doesn't solve the entire problem, nor can ANY content > filtering be nearly as efficient as when an IPv4 DNSBL blocks the spam at > the perimeter! In fact, many medium and large systems heavily depend on > their content filters getting a reduced spam volume due to IPv4 blocking a > high percentage of such spams BEFORE the body of the message is accepted > (before DATA). > Isn't the simplest way to handle this is to treat IPv6 at the /64 or smaller level? More likely, because most people use IPv4, the RBL's just don't have the data sources they need to populate the data, not because of some inherent size problem with the data. I'm also not clear that content level scanning is really so much more expensive that it can't be invested in. "Here's a nickel kid, buy yourself another VM" or something. More likely, there's a trade-off in trusting RBLs completely vs how much mail you receive, and as you scale up, the more numerous the false positives from RBLs become (not as a fraction but as an absolute number) and the more effort you need to put into doing more complicated evaluations even as your traffic is higher. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
