In retrospect, yes it would have been a bit cleaner if the rbl list was sucked down, however it's a list that administrators often like to modify / tailor, and rbl's vanishing is relatively rare.
The next build does automatically ignore those two problem ones, and it also puts a very clear alert in the status if it detects a dead one that appears to be unresponsive.
ChrisP.
I believe Surgemail sucks down certain settings/info on a regular basis. What about having it suck down RBLs that have been deprecated, so they don’t become
a problem?
Sent: Tuesday, May 07, 2013 5:06 PM
Subject: re: [SurgeMail List] RBLs
1) Remove these two if you have them as they no longer exist and will cause smtp delays.
2) I recommend trying the setting g_sf_binary "true" which changes the spam scoring mechanism to be a bit more accurate.
rbl's won't protect servers from compromized email accounts on large public servers, which is where the bulk of spam comes from these days, and there have been
some large compromizes in recent months that may explain the increase you've observed.
It's been awhile since I've seen a discussion on this subject but I'm wondering if anyone is willing to share their RBL setup with Surgemail?
Here in the past 3 weeks to 2 months our SPAM has gone up and it appears our RBL hits have gone down. I'm wondering if I need to adjust our settings or servers
we have configured?
g_orbs_list name="list.dnswl.org" action="accept" stamp="3=dnswl_high~2=dnswl_medium~1=dnswl_low~0=dnswl_none" g_orbs_list name="dnsbl.sorbs.net" action="stamp"
stamp="1=1.sorbs~2=http.sorbs~3=socks.sorbs~4=misc.sorbs~5=smtp..sorbs~6=spam.sorbs~7=web.sorbs~8=block.sorbs~9=zombie.sorbs~10=dul.sorbs~11=badconf.sorbs~12=nomail.sorbs"
