I’ve done lots of RBL testing, for years, and the only RBLs that I’m using are the ones that are effective and don’t have false positives: Barracuda RBL and Spamhaus Zen (paid). But I still do my best to keep my mail servers off the other lists; usually this just means I stop sending email from one of my gateways for a week. I also had to sign up for the AOL junk reporting service because their users are too stupid to know the difference between the “delete” button and the “report junk” button.
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Suresh Ramasubramanian Sent: Monday, August 29, 2016 8:46 AM To: Bryan Vest Cc: mailop@mailop.org Subject: Re: [mailop] How many more RBL's do we really need? Most of them have about the same reach as some random guy tweeting just how bad a movie sucks. Nobody other than his girlfriend, and maybe his family dog, are likely to read it. Now if nytimes, Rogerebert.com<http://Rogerebert.com> etc write reviews panning it, the movie will flop So - those are like Spamhaus and two or three other block lists that are widely used while the rest are more often than not some random guy with a bofh complex and maybe ten users on one vps. --srs On 29-Aug-2016, at 6:15 PM, Bryan Vest <murli...@gmail.com<mailto:murli...@gmail.com>> wrote: I have been lurking here for a couple years but have really not had any information worth jumping into a conversation. But the question in my subject is really burning me up these days. As far as my last general check there are at least 200 RBL's that could potentially be used by any mail admin anywhere in the world. They rarely have matching data sets and just becomes a real pain for a 2 person operation managing a system with 80k+ email accounts. We have built a very complex outbound mail verification system but we cant stop 100% of the spam 100% of the time so some does slip out. I have ran into some RBL's where you ask for removal and they either want payment (fairly rare at this point) or do not answer or give a really long explanation of why they are right and you are wrong. This may have been brought up before and if there is already a group please point me to it, but we need a study group/governing body/RFC to at least put out suggestions on RBL structure. Granted the RBL owners do not have to listen to anything that is said but maybe if it gained some traction admin's, at least the true admin's that know the internals of their mail system would start to listen. Hard set RBL's with no timeout's should be frowned upon. RBL's that give you the run around when you ask for a removal should be forgotten. RBL's that have no option for removal should be forgotten. RBL's that rely on 15 year old data sets should be forgotten. (I have ran into a few) We run our own internal RBL that slurp's IP's from a couple different reputable RBL's and through scripting/algorithm's that we have been perfecting for 10 years no IP stays in our RBL more than 12 hours, some are even less it all depends on hits over time. If they start spamming again they are added back to the RBL if spamming patterns are detected. We take care of most of this using rbldns and triggers from our Logstash system. Our internal RBL rarely contains more than 150k entries at one time since it is auto cleaning. It does swap in and out thousands of ip's per day but generally averages about 150k. We can always route around these what I will call at this point bogus RBL's but that should not be something we have to do. The RBL owners should properly maintain their lists. For instance it was not long ago that I had to jump though hoops to get one RBL to reassign a block of our ipaddresses as static in their system when we had reassigned them as static 5 years earlier. These RBL's are not doing anyone any favors, maybe to the admin's that can say "YAY we block all spam with this RBL." Acceptable, but how much legitimate mail are you blocking? I know there are some system vendors that have a set of RBL's built into their system's but what are the default RBL's, how many admin's would even know how to figure out? --Bryan Vest _______________________________________________ mailop mailing list mailop@mailop.org<mailto: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
