As this list is very nice, is there a reason not to include it in the
default toaster?
Some of those lists put false positives, prone to false positives. The
SBL is a very conservative list. Once upon a time, we included
bl.spamcop.net until they blocked hotmail and various other big
providers. It's best to leave tuning of blacklists and spam filtering
to the end user.
Excessive filtering can be done on a personal server, with just
friends and what not. On corporate servers, it's probably best to
handle it on the client instead of missing an important business
e-mail. This is the middle ground.
Shouldn't the basic (default) configuration be as 'nice' as possible? As a
new user, I would have liked to have had this list as the default, and I
can't think of any reason why it shouldn't be included. Figuring out which
BLs to use is a daunting and intimidating task.
A daunting, but one that will usually lead to a different list from
site to site. For example, if I have a bunch of users on dynamic ip
addresses that need to send from my server (because I have a tight spf
setup) then I probably don't want to have an rbl that blocks dialup
users. Running a mail server is a complicated case by case thing, and
the QmailToaster helps to make it easier, but there are certain things
that should be left to the administrator to tune, for they know more
about their environment than us.
Leaving a more restrictive blacklists will be a bigger burden on our
list when things get rejected as well. Where as if the Administrator
is aware (IE put them there), he/she will know where to look if there
is a problem. So it also serves as a learning experience.
I tend to agree with you here, that tuning SA should be a post installation
task. However, I also think that spamassassin-toaster should be as close to
the default spamassassin distribution as possible, which should make
building the toaster package easier. Don't you agree?
And it is
Since the only reason to limit SA-toaster to local tests (-L option) and
turn off rbl_checks (skip_rbl_checks 1) is for performance, and given that a
caching DNS is now 'included' in the toaster, doesn't it make sense to
ditch the "-L" option and turn rbl_checks back on? Especially since are many
more rbl checks in the default spamassassin distribution than are covered by
the rblsmtpd?
One a case by case scenario. If most users stick to the default config
(or put hard rejections in /var/qmail/control/blacklists) then this is
a non-issue. If they are adding rbl's to the SpamAssassin config, they
can do those two extra steps.
Granted, there will be inefficiency introduced by having rbl checking done
by both rblsmtpd and SA. That's where I believe post installation tuning
should be done. Besides, I wouldn't want to try to maintain the SA-toaster
package with altered (commented out) standard .cf rules. That would be a PITA.
Agreed
So here's a compromise I'd like to propose. In the default toaster, let's
use Jake's blacklist, ditch the "-L" option on SA, and put SA back to its
default configuration by turning on rbl_checks and adding the "loadplugin
Mail::SpamAssassin::Plugin::URIDNSBL" statement back into whichever .pre
file it belongs. That way, SA will function as it does by default, and we'll
have better BL coverage up front. As part of the post installation tuning,
I'll write up wiki documentation (or maybe eventually write a script) for
commenting out the redundant BL tests in SA.
Why not just create a post script that does those tasks with a default
to your liking and links to the wiki page with more info. I'd link to
that script from my page, but I'm also sure that Nick would probably
link to something like that from the master page. That way it stays
completely in the realm of post configuration, where it should be.
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
