Default to no RBL blocking or yes RBL blocking?

In the past the SpamBlocker Technology* exim.conf file offered to one of two choices for blocking mailservers known to send spam, by using RBLs (realtime block lists).

1) you could use a separate use_rbl_domains file and use realtime block lists to block mail only coming to certain domains hosted on your server.

2) you could make use_rbl_domains a link to the domains file, and use realtime block lists to block mail for coming to all domains hosted on your server.

Recently DirectAdmin administrators have expressed an interest in changing the default behavior of SpamBlocker Technology* to switch to an rbl_exceptions file. If we did that the options would be:

1) you could use a separate rbl_exceptions file and use realtime block lists to block mail coming in to all domains hosted on your server, except for the domains listed in the rbl_exceptions file.

2) you could use an rbl_exceptions file as a link to your domains file, and not use realtime blocklists at all, but continue to use the other features of the SpamBlocker Technology* exim.conf file.

That all said, making the change comes with its own set of issues:

The problem is that if I make the change, then everyone installing the new file need to rework their files. More work on install because the new file will simply not work unless you make the file change (exim won't run).

It's easy enough for me to make the change from the use_rbl_domains file to the rbl_exceptions file, but it's a lot of work to implement, especially if you still have separate domains and use_rbl_domains files, and even more so if you have a lot of servers.

It will make it a lot harder for DirectAdmin to use it as their new standard.

But it's probably much better moving into the future.

What do you think? Please answer the poll before posting.

Thanks!

Jeff

*SpamBlocker Technology is a trademark of NoBaloney Internet Services
for our exim.conf file for DirectAdmin. The exim.conf file itself is distributed
under the GNU GENERAL PUBLIC LICENSE, Version 2, June 1991.

First I would to remind everyone of this recent update that wreaked havoc on a lot of administrators http://www.directadmin.com/features.php?id=1050

No new feature should be a default if it has the potential to cause problems especially when those problems could cost a lot of time and effort to fix. The last thing I want is to have a new feature come out that I am forced to use until I can first figure that I have a problem, and then second figure out that the problem was due to a recent update, and then third have to spend a lot of time fixing it.

All the people who have 1 or 2 systems won't be affected too bad. But what about the ones who manage 10, 50, 100, and lot more servers? They may be suddenly forced to spend a lot of time fixing something they didn't want in the first place.

If a feature is new that means that it was not being used previously so that means nobody will be affected if it is turned off by default. But if people do want to use it then they can turn it on one server at a time at their leisure and not be in a mad rush to fix everything.

This change in how RBL is implemented will affect a lot of people with a lot of servers. Now it might be that this is what people want. If so then let them choose to implement it.

And the problem of course is I can do it one way or the other. I'd love it to be an opt-out system, but that, as you point out, makes the install quite a bit more complex for a lot of admins.

Maybe, just maybe, I'll do both.

Jeff

Another good idea would be to leave the SpamBlocker code as it is in the exim.conf file without making any changes to the file...

But instead, add the "rbl_exclusions" code into the exim.conf file but leave it commented out.

So in other words, the SpamBlocker exim.conf will remain as it currently is by default, and only the few people that want to enable the "rbl_exclusions" method will have to uncomment the code and, of course, delete the default code.

Am I making sense?

(Something similar to the 'clamav' scanner line - the administrator will pick the one that he/she wants to use).

It's not quite that simple but I'm looking into it.

Jeff

I've given this a lot of thought. I'm going to change it for the next RC, which is coming out tonight some time. I hope someone will try it.

The problem of course is that it's extra work to change to this version, but I think it's time it gets done.

Jeff