Hi Rob, Isn't it time conclude that "separate IP blacklists" combined with "separate content filters" are not sufficient any more? Because you need one to interact with the other? You need the content filter to steer the IP blacklist (and other traffic limiting methods like throttling and greylisting).
In this sense, many IP blacklists have always been indicators of reputation instead of being used to block traffic "without questions". Adding to a spam score. I think that these more complicated spam filters need a lot of data to work (both the email and how people react to it). That is not easy to obtain for smaller domains. I guess there is a technical challenge in that... Yours, David On 7 June 2018 at 04:10, Rob McEwen <r...@invaluement.com> wrote: > On 6/6/2018 8:11 PM, Brandon Long wrote: > >> Isn't the simplest way to handle this is to treat IPv6 at the /64 or >> smaller level? >> > > Brandon, > > Everything I've stated in that article, and in my comments on this thread > - came with the foreknowledge that many of those who have discussed > implementing IPv6 DNSBLs - have concluded that it would be wise to make the > smallest block at the /64 level. I've already considered this. Your > suggestion doesn't change a thing I've stated. And it doesn't change the > "lack of scarcity" issues that will help IPv6 senders easily acquire new > IPv6 space, where their paid hosters are not as concerned as much about > soiled IP space, and start falling in love with spammers' money all over > again. It also doesn't change the magical listwashing opportunities for > sending spams on a one-IP (or /64) per recipient - then listwashing the > recipients when that sending IPv6 (or IPv6 /64) gets listed. It doesn't > change opportunities for them to do one-off sending where the resulting > DNSBL entries greatly bloat the size of the DNSBL with entries that are > absolutely worthless. There is just so much you glossed over or > overlooked... > > 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. >> > > I've seen spam filters which were serving several thousand mailboxes and > running on abundantly fast hardware - brought to their knees due to > sending-IP filtering temporarily breaking due to a glitch, where everything > then had to be fully content filtered. The problem here is that you're > greatly underestimating the VAST difference in resources used when a > majority of the spam is blocked by IPv4 RBLs at connection - vs - the > resources needed to accept the entire message and then doing content > filtering. This can really add up - to a point where it isn't "buying > another cheap VM"... instead... that becomes... "quadruple your hosting > budget", or worse. And this can also apply to large ISPs, too. I recall > chatting with an admin from a really large ISP (~30M mailboxes) some years > ago - and he told me - "we get 10s of thousand of messages per second, and > we couldn't even begin to handle that volume without rejecting a large > percentage of those at the connection based on the sending IP" - their > expenses would instantly grow by many millions of dollars if they suddenly > had to depend on much more content filtering. > > Also - large e-mail hosters who have teams of in-house software engineers > (such as Microsoft, Google, Proofpoint, etc) are at a distinct advantage > here because they have more options to do customized programming that > enables them to implement strategies that will work better for IPv6 (such > as filtering based on the DKIM domain, etc). In contrast, many smaller and > medium sized businesses that used "canned" software or hardware-appliance > solutions - are limited by the options presented in their software or > hardware. And, unlike Google and Microsoft, they don't have the option to > procure more hosting at essentially wholesale prices! So just because these > issues are no big deal to YOU (Google) - doesn't mean that they don't > present hardships to these other senders who might not have the flexibility > and options you handle (potentially) too-fast paradigm shifts like this. > > So I'm just trying to help these other types to have the information they > need to make "informed decisions" - which can be factored into their > particular situation. Certainly, they shouldn't be pressured into > publishing IPv6 records (and such pressure is already happening!), > especially without knowing the rest of these facts - and especially not by > others who have institutional advantages for handling IPv6 - who then might > not empathize with their situation. > > Ironically, (and sadly) we ALREADY have had a situation for many years > where the increasing complexity of managing a mail server had motivated > many to abandon it and move their email to the cloud. This is not all bad - > but I think the very large amount of that which occurred - was bad for the > industry. We're now dealing with spam coming from these large providers - > that would NEVER come from a smallish sender - because these larger > providers are "too big to blacklist", and the smaller hosts would have been > blacklisted. These larger providers have LESS motivation to control their > outbound spam - in comparison to an Internet where email hosting was more > distributed to more small and medium sized providers. > > Meanwhile, it is ironic that - to the extent that your arguments convince > these smaller senders to publish IPv6 records - and then to the extend that > they then get frustrated and more of them move to the cloud - Google stands > to be one of those mail cloud providers who stands to benefit financially > from this continued frustration with the continually-increasing complexity > of running a mail server. > > But, "let them eat cake", right? I know you don't mean it that way - I'm > sure you're very sincere and wanting the best for everyone impacted by IPv6 > MX records - but that is what your statements above sound like to me - when > I consider these small and medium-sized mail hosters' resources and options > - in comparison to Google, and Google's institutional advantages in many of > the areas you're talking about. > > -- > Rob McEwen > https://www.invaluement.com > > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- -- My opinion is mine.
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
