Erik Espinoza wrote:
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.
Gotcha. I agree 100%. The basic toaster should have absolutely no false
positives. One size indeed does not fit all.
I can see it now, a wiki page devoted to BLs (and RBLs and SURBLs).
(and I see that Jamie already has started the ball rolling!)
On a side note, please do me a favor and try to avoid using the word
'conservative' wrt BLs. I think it can be interpreted as being loose or
tight (which I think are better descriptors), and thus is non-descriptive at
best, and misleading at worst. ;)
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.
Nicely put.
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.
Agree. I was thinking about the learning experience as well. I guess the
wiki will serve that purpose (once we get it shaped up).
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
Except for the skip_rbl_checks setting (according to O'Reilly's SA book). I
was thinking that this should indeed be "1" for the toaster, but after
considering Steve's post, I'm back to leaving it as default "0". While
rblsmtpd checks the MTA's address, SA checks the originator's address. This
might be a bit tight for the basic toaster, but we're only talking flagging
here (with SA), not outright rejections.
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.
I still fail to see the reason or benefit of having the "-L" option in the
basic toaster. Please enlighten me.
In any case, we will put in the wiki anything necessary to assist with post
installation setup and tuning. Some stuff rightfully belongs there. I just
don't think that these two items do (at this point, but I'm still learning!).
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.
Ok, we'll get the wiki whipped into shape first, and then (or while) someone
does some scripting for this.
Thanks for everything.
--
-Eric 'shubes'
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
