August bump. 9 votes already!

RBL's are losing their value and in some cases causing more harm than good.  We are not spending much more time on RBL's moving forward.  It is very important for customers to understand the state of RBL's and our efforts moving forward.  If you're looking for a good free spam solution, Rspamd is the way to go and we have done allot to make that an extremely effective solution including training for Ham and Spam!

We are working with the new owners of Cyren to improve the overall effectiveness of their solution and the results are exciting. More information will be released shortly.

Getting good results from free solutions is becoming more and more difficult, as many of you already know.  

Let's not forget some RBLs are crooks through extortion!

Yea, some are. 

Tim, thanks for the reply. We're using RBLs and they are still quite effective.

I looked through the SMTP logs (since there are no reports :) and here are some stats from the last few days:

So that's over 20% of messages that are rejected due to Inbound SMTP Blocking. Nice!  And the remaining 80% were scored, so many end up in the Junk Email folder.

So maybe you could set this idea to Under Consideration and see if more people vote for it (12 Votes currently). Thanks!

BTW, you've done a really nice job in the way you implement RBLs. Assigning a unique spam weight to each RBL is better than other mail systems where it's all/nothing. It's very useful to give more weight to reliable RBLs and less weight to questionable ones.

And the (Apr 5, 2023) Build did a nice job of combining RBLs that use the same hostname and allow a unique weight per Required Lookup Value!

We also have great success with RBL filtering.  Our numbers (while overall smaller in general due to size of our footprint) are in matching proportion to kevind's.  The scoring implementation helps us as well, and with a little tuning puts us on the high-side of the spam-caught percentage by a couple points.

We will be implementing rspamd to manage the rest of the filtering - but we would be dealing with a real flood of spam without the RBLs.  MailEnable doesn't have the "scoring implementation" that SmarterMail uses, and since we've moved over, SM's implementation has proven to be much more robust.

Many people dislike RBL concept because it doesn't take much to land on one of those lists - but after almost 20 years in this game and only landing on a couple of them once before we locked things down, we've never had a problem since.

Hello Tim,

May I ask what makes you come to this conclusion. As far as I'm aware, RBLs / URIBLs are still the best first line of defense against SPAM.

Of course it's a pain that for most of them you have to subscribe to a commercial feed or you're getting blocked rather quickly if you have a lot of incoming mails.

But from experience, it's unfortunately still the most efficient way to block known sources of spam.

I love rspamd and we use it since a long time on incoming gateways. It has good result with its built-in rules and some additional you can add. But without the help of RBLs, a lot is getting through.

I mean the spammers know for sure, even more than we or legit mail senders do,  how to construct a mail so it won't trigger most of the rules.

SPF/DMARC is also one way to block crappy senders but now spammers mostly uses hacked accounts that have perfect legit SPF even signing as they use legit hacked accounts.

What is left then, except collaborative lists of known current source of spams, or compromised domains, etc. ?

I really would love to understand what brings you to your conclusion about RBLs.

Thanks a lot and kind regards.

1000000000% RBLs are worth it... At least with the filtering options SM has. I tested running just Cyren/Sniffer with zero RBLs (my personal domain only) in front to straight up shutdown SMTP connections from spammers and both solutions were beyond useless, I was getting 15+ spam emails a day that both solutions were saying "nope, let em thru boys, they are clean", checking the headers and running a multivali check on the IPs revealed that ~80% of the well-known RBLs would have immediately stopped these emails from even reaching the spool. (Should note that we did not test both solutions side-by-side, it was one-at-a-time).

The content filtering solutions that SM have just are not good enough on their own. VadeSecure on the other hand, with no RBLs running checks for 7 days (my personal domain only), I received a total of 3 spam emails. As they say though, "Nice things cost money, if you want them, be prepared to pay for them". Vade is significantly more expensive than Cyren and Sniffer combined. Though, having RBLs in front of Vade can help lessen the overall load put on the system by knocking down servers that are pumping out junk.

Bumping this thread with 14 votes and lots of comments. Looks like RBLs still play a significant role in spam identification.  A simple report that shows RBL hits would be great.

Here's another idea for gateway servers – populate the AntiSpam report. Currently it shows all zeros. It would be nice to see Inbound Spam passed on to the primary server. Maybe I'll create another thread for this.

Kind of surprised this idea with 15 votes was declined.  I've seen other ideas with <10 votes accepted and implemented.

What if we changed the request to populate the AntiSpam report on the gateway server? Instead of showing 100% of messages as not spam, show spam scoring. That would be useful. Would that request make it to Under Consideration?

Thanks!

Bump for October 3rd – National Techies Day! Thanks to all the programmers who transform complex code into user-friendly digital products.

Since his Majesty removed all reports in version 16 all requests for any kind of report have been declined. This was the reason I stayed with Version 15 and stopped paying yearly support/upgrades.