Note I'm not saying that IP time blocking isn't useful. My issue is, are most RBL's good for IP time blocking?
An RBL is a statement that everything from that IP is bad, but the truth of that statement varies greatly based on the RBL in question. But, in the end, what everyone seems to have is that hammer, and so the little built-in software support is for RBLs and using them either at connection time or letting the mail through. If the industry had moved to a reputation model, it would be easier to discuss "how bad is it" and whether it's bad enough to block at IP time, or whether you mix it into your spam score. As for the large mailbox providers being too big to block, I think that's really more of a question of how many false positives are you willing to hit with your block, and the fact that you're arguing for something that's a blacklist. There are definitely large spammers out there which are pure blocks, and definitely being blocked helps push back on folks to clean up their act, and the RBLs are good for that part of the eco-system. But they will have a false positive aspect to them, and how much (by percentage and absolute volume) an RBL is willing to put up with varies greatly as well. What a large mailbox provider gives is the largest example of that fact, that the ban hammer has affects the innocent as well. And that's even before you get into the realm of grey mail, the mail that's spam depending on the eye of the beholder, did this opt-in list overstep it's bounds, is the content a little too much, did this sales women reach out to one too many potential new clients (manually!). Will SMTP be the last hold-out on IPv4? Brandon On Thu, Jun 7, 2018 at 8:41 AM Rob McEwen <r...@invaluement.com> wrote: > On 6/7/2018 9:45 AM, David Hofstee wrote: > > 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... > > > David, > > If I had tried to cover all such details in that article (and other > similar things that you could also have mentioned, too) I would have had > to write a book, not an article. In fact, my own filtering does such > things - but I can afford the extra processing, where I accept every > entire spam message and then combine all such processing as you > described - and even having them dynamically interact in the ways you've > described, and in other ways, too. > > For example, one of the 3rd party command-line anti-spam content filters > that I use in my spam filtering is good at blocking elusive spams, but > has just a few too many false positives. Therefore, I dynamically alter > its spam scoring in my system based on the sending IP's reputation, > increasing that score if the IP isn't in my whitelist, and then further > altering its score based on my systems' overall reputation score of the > sending-IP, which is similar to what you've described, correct? > > But I can afford to put much time and money into my filter per user - > even if that time and cost isn't justified by the overall spam filtering > revenue. I can afford this precicely because my anti-spam business > essentially subsidizes my small mail hosting and spam filtering > business, which mostly exists as a way to keep my finger on the pulse of > what my typical DNSBL subscriber experiences. HOWEVER - many businesses > don't have this flexibility and/or they are stuck with a "canned" > anti-spam solution from a software or hardware vendor that doesn't > provide such flexibility. (and not all email admins are > coders/programmers! nor should they have to be!) And, as I mentioned, > others have such massively high volumes of inbound mail that they DEPEND > on significantly reducing the volume of spam (with IPv4 blacklists) > before it hits any kind of content filtering. > > And these are the more common situations - those with situations like > your situation or mine (for example, most of my spam filter is > self-programmed!) ...are more rare. > > BTW - for anyone just joining this thread, here is the article being > discussed: > > https://www.linkedin.com/pulse/should-mail-servers-publish-ipv6-mx-records-rob-mcewen/ > > -- > Rob McEwen > https://www.invaluement.com > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
