On Wed, 16 Jan 2013, Ben Johnson wrote:
On 1/16/2013 11:00 AM, John Hardin wrote:
That's odd. That suggests you SA wasn't looking up those DNSBLs, or they
would have contributed to the score.
Check your trusted networks setting. One difference between SMTP-time
and SA-time DNSBL checks is that SMTP-time checks the IP address of the
client talking to the MTA, while SA-time can go back up the relay chain
if necessary (e.g. to check the client IP submitting to your ISP if your
ISP's MTA is between your MTA and the Internet, rather than always
checking your ISP's MTA IP address).
Are you referring to SA's "trusted_networks" directive?
Yes.
If so, it is commented-out (presumably by default). Does this need to be
set? I've read the info re: trusted_networks at
http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Conf.html
, but I'm struggling to understand it.
It means "which MTAs are trusted to not forge Received headers".
There is a related one: internal_networks, which lists networks that are
considered "internal" to your inbound mail topology. Sorry I missed that
one in my first message. This one you'd set if you were retrieving your
email from your ISP rather than directly exposing a MTA to the Internet.
If the info is helpful, I have a very simple setup here: a single server
with a single public IP address and a single MTA.
That's the assumed default environment. If you aren't explicitly setting
trusted_networks and internal_networks you should be okay.
That said, the Bayes scores seem to be much more accurate now, too. I
was hardly ever seeing BAYES_99 before, but now almost all spam messages
have BAYES_99.
Odd. SMTP-time hard rejects shouldn't change that.
That's what I figured. I wonder if feeding all of the messages that I
"auto-learned manually" -- messages that were tagged as spam (but for
reasons unrelated to Bayes) -- contributed significantly to this change.
Quite possibly.
That shouldn't be the case. SA and sa-learn both use a shared-access
database; if you're training the database that SA is learning, the
results of training should be effective immediately.
Okay, good. Bowie's response to this question differed (he suggested
that Amavis would need to be restarted for Bayes to be updated),
No, he didn't, he said that in a situation where you'd have to restart
spamd, you instead need to restart amavisd. One such situation is after
running sa-update and getting updated rules.
but I'm pretty sure that restarting Amavis is not necessary. It seems
unlikely that Amavis would copy the entire Bayes DB (which is stored in
MySQL on this server) into memory every time that the Amavis service is
started. To do so seems self-defeating: more RAM usage, worse
performance, etc.
Right.
So, I emptied the Bayes DB and re-trained ham and spam on my hand-sorted
corpus. The net result was to discard all previous end-user training, if
I understand correctly.
That is correct.
Everything still looks good; mostly BAYES_99 on the messages that are
and should be marked as spam, and no false-positives at all.
yay!
I've disabled the Antispam plug-in for now, for the reasons we've
already discussed. I have asked the Dovecot mailing list for suggestions
regarding how best to pre-screen end-user training submissions.
I think I'm in pretty good shape here, unless setting trusted_networks
is a must, in which case I could use some guidance.
No, sounds like you're good for that.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
It is criminal to teach a man not to defend himself when he is the
constant victim of brutal attacks. -- Malcolm X (1964)
-----------------------------------------------------------------------
Tomorrow: Benjamin Franklin's 307th Birthday
