Hi Rob, > ... score of the sending-IP, which is similar to what you've described, correct? Correct.
So you have these mechanisms in place. But your customers, who get access to the invaluement RBL, do not. Am I correct? If I am, it still results in the conclusion that blacklists are not sufficient to have a resulting good spam filter. You would be ok, the list would not have false positives, but your customers would not be sufficiently covered once bad guys get smarter. I also think that there is space for a reputation provider which can: - Identify more than just IP addresses and domains from an email. - Is able to process feedback from domain owners and recipients in an automated, quick, effective and anonymous enough way (with the GDPR et al). Feedback is key. Yours, David On 7 June 2018 at 17:29, 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 > -- -- My opinion is mine.
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
