Erik Espinoza wrote:
This was never a hard requirement, so much as a recommendation. This
is because we have a lot of checks happening now that require fast DNS
response, not one single thing. Here are the things (off the top of my
head) that require DNS:
1) SPF Checks (can be multiple lookups depending on the # of include
statements used)
2) DomainKeys (if published)
3) PTR Record lookup (ip to name of machine connecting)
4) DNS Black lists (# of requests == # of lists used)
I agree. It still isn't a *hard* requirement, but I think you'd agree that
it would be ill advised to run the toaster without one. I've been meaning to
add some code to the upgrade/install script to handle installing a caching
DNS (djbdns and/or bind). I'll also try to consolidate the DNS related
infomation on a single wiki page for DNS. This list of things will help -
thanks!
>> The second item needs some attention. Since many RBL checks are done
>> already upstream in SMTP (by rblsmtpd, I've seen rejections in the
>> log), doing them again in SA is a waste of resources. Perhaps this is
>> why rbl_checks is turned off in the toaster, I'm guessing. To
>> implement SURBL checking efficiently in the toaster, whichever BLs are
>> already checked in SMTP/rblsmtpd should be removed from the SA rules,
>> as these rules will never score any points since the offending email
>> has already been rejected before SA sees it.
>>
>> As a result, I'd like to suggest that someone go through and identify
>> every SA BL rule that's covered upstream by SMTP. These should be
>> commented out of the standard .cf rules. Put that together with a
>> short list of what changes need to be made to the toaster (from the
>> wiki would do), and perhaps Erik or Nick can include these changes in
>> the next release of spamassassin-toaster. Note, I think the install
>> scripts for perl modules will need a few additions as well.
I think all hard rejection lists should be put in
/var/qmail/control/blacklists. Anything that is going to count as
points in SpamAssassin should be put in SpamAssassin's configuration.
100% agree.
Our default is to leave that disabled, since people who want tougher
spam blocking will have to configure SpamAssassin, enabling dnsbl in
SpamAssassin is just one more thing to do.
One more thing they shouldn't have to do. Besides which, this is not the
default behavior of SA.
> The BL's that are checked by default are in your
> /var/qmail/control/blacklists file. I think these are default:
> -r sbl-xbl.spamhaus.org -r bl.spamcop.net -r relays.ordb.org
The only default list is "-r sbl.spamhaus.org"
This is correct. I was mistaken, as I had added a few in my blacklists file
at some point and didn't make an orig backup. My bad.
> And of course a lot of people add more (I have to run loose due to some
> of my clients), but here's what I run standard on my machines:
> -r sbl-xbl.spamhaus.org -r bl.spamcop.net -r relays.ordb.org -r
> dnsbl.antispam.or.id -r sbl.spamhaus.org -r opm.blitzed.org -r
> list.dsbl.org -r cbl.abuseat.org
Very nice list
As this list is very nice, is there a reason not to include it in the
default toaster?
Before we go down the road of turning on BL rules in the (default)
toaster,
perhaps we should come to a consensus as to which BLs would be
appropriate
for rblsmtpd to handle (up front, 100% rejection), and which would be
best
left for SA to handle. I think it'd be appropriate to leave it on the
loose
side, and let any customization be done to tighten it up (perhaps
that's the
way it is now).
I don't think the default should change. Users who want tighter spam
control should set up SpamAssassin. Those who want a basic
configuration can use the default.
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.
What say Erik/Nick? (I'm thinking Nick is very busy otherwise lately)
I think this should be left to post configuration. Certain things need
to be done after install, such as adding your ranges to tcp.smtp.
Tightening spamassassin should be one of those things. The nice guide
you wrote will assist users in doing that.
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?
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?
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.
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.
What do you say, EE?
(Anyone feel free to chime in)
--
-Eric 'shubes'
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
