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.

As a email administrator with 20 years of experience, I can safely say that having a report within SmarterMail is way outside the realm of reality.

At best, that would be something for log analysis.

I commonly use a website every quarter as well as my on long analysis to determine which RBLs are working for my circumstances. RBLs are indeed valuable when used in combination with other items. 

For full disclosure, I am a customer of SmarterMail and Mails Best Friend and have been involved with email filtering since about 2002. 

Just finished analyzing how effective a certain RBL was by manually going through daily log files to count the number of hits.  It would be really nice to have a report that shows which RBLs are tagging messages and which are not.

So I think this request still has merit. Evidently so do others with 18 votes. :)

Now here's a super-cool idea to measure RBL effectiveness. When a user marks a message as Spam, give all RBLs tagged in that message a star. Then at the end of the week we could assign more points to the RBLs that got a lot of stars!

And instead of blocking a sender, the option to block the domain should be added to the UX and then it should be forwarded to the admin console to be added to a centralised list of domains not allowed to connect.

That way spam would dissappear very quickly in all the users mailboxes.

To the last couple of responses: If the war on spam were that easy, it would be over by now.

It is completely outside of the scope of what an email server does and services it provides to ask it to also analyze logs and create reports. Log analysis is always an entirely different software/service regardless of what the server/service that is creating the logs is. 

John... SM already creates reports, SM also doesnt need to analyze the logs to generate said reports, SM tracks things like messages sent/received etc. with stat files, when you generate a report of mails sent etc. SM is not processing the log files to determine how many emails were sent, that would be insane. I'd assume their logic of using the stat files could also be used with RBLs as well in that a stat file is used to track how many emails were "acted on" per RBL, not really out of the realm of possibility. SM knows the RBL, it knows the action that is assigned to said RBL response code, there is no need to parse any logs.

@echoDreamz, thanks for the support.  Agree 100% – SM writes all the RBL hits to a log file, so just increment the counters in the stat file too. Easy. And has 18 votes!