* Matt Kettler wrote (31/07/08 11:25):
Chris Lear wrote:
I'm trying to improve the effectiveness of a spamassassin
installation, and there's one user who gets a lot of spam that is
forwarded from another address, which effectively kills the network
tests and in some cases messes with the BAYES score as well. I want to
get rid of it.
My solution to the problem was originally to add the forwarding mtas
to trusted_networks (seems ironic, but I think this is appropriate).
Unfortunately, this doesn't work, because the headers look like this
(with apologies for the munging, but it's not my e-mail):
Received: from mta3.iomartmail.com ([62.128.193.153])
by smtp.DOMAIN.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
(Exim 4.69)
(envelope-from <[EMAIL PROTECTED]>)
id 1KOUZB-0001Xq-Eb
for [EMAIL PROTECTED]; Thu, 31 Jul 2008 10:35:29 +0100
Received: from mta3.iomartmail.com (localhost.localdomain [127.0.0.1])
by mta3.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id
m6V9ZOVc018574
for <[EMAIL PROTECTED]>; Thu, 31 Jul 2008 10:35:24 +0100
Received: from p548AAE80.dip0.t-ipconnect.de
(p548AB09B.dip0.t-ipconnect.de [84.138.176.155])
by mta3.iomartmail.com (8.12.11.20060308/8.12.11) with SMTP id
m6V9ZNUK018506
for <[EMAIL PROTECTED]>; Thu, 31 Jul 2008 10:35:24 +0100
[EMAIL PROTECTED] is the original address, which is handled by
mta[X].iomartmail.com, and it's forwarded to [EMAIL PROTECTED], which is
handled by smtp.DOMAIN.com.
I can put 62.128.193.153 into trusted_networks, which should make
spamassassin look at the next header back, but that's another
iomartmail.com machine (presumably a virus/spam checker), and I'm
fairly sure adding 127.0.0.1 to trusted_networks would be a mistake.
Why would adding 127.0.0.1 to trusted_networks be a mistake? Since trust
is a path this won't lead to spammers being able to forge trust, as
they'd have to first get to your system from a trusted IP address. (or
manage to do a TCP blind-spoofing attack and make it look like it came
from one)
OK, you've persuaded me. It seemed fishy, but I wasn't being logical.
I'll do that and keep an eye on it. Don't worry - I'm not going to
obsess about TCP spoofing.
Question one: Is there a way of getting the network tests working on
these forwarded e-mails?
My next idea is just to add a load of score to messages to
ORIGINALDOMAIN.com. Looking in the wiki at
http://wiki.apache.org/spamassassin/WritingRules#head-36104467608e64f77e1878ec3201073b8180c728
I see this:
===
Checking the From: line, or any other header, works much the same:
header LOCAL_DEMONSTRATION_FROM From =~ /test\.com/i
score LOCAL_DEMONSTRATION_FROM 0.1
Now, that rule is pretty silly, as it doesn't do much that a
blacklist_from can't.
===
What I want to do is blacklist_to [EMAIL PROTECTED], but with a
score of 3 (ie, it's not really a blacklisting). The quote above seems
to suggest I can do that, but I can't see it in the docs. Question
two: is it possible to set a score on a blacklisted address?
No, unless you reset the score for all blacklist_to's
score USER_IN_BLACKLIST_TO 3.0
When I said it "doesn't do much that a blacklist_from can't", I didn't
mean to say there's nothing it can do that a blacklist_from/to can't..
there's just not much. Custom per-address scoring, using a full regex
instead of a file-glob, and per-address combinations with other rules in
a meta are things blacklist_from/to can't do that a rule can.
Thanks. That all makes sense. I was reading too much into the remark. As
a side note, in my perusal of the documentation, I didn't stumble easily
on the link between the blacklist_to option and the USER_IN_BLACKLIST_TO
rule.
Finally, I can use header ToCC, and that'll probably do, but I wanted
to know if there's a better way.
That's the best way I know of. Also, be aware that unless your MTA drops
hints about the recipient in the Received: headers with a "for" clause,
SA won't know who the real recipient is when a message is BCC'ed. This
is important, as lots of spam is effectively BCC'ed (i.e.: actual
recipient is in the envelope, but not the To: or Cc:), so your ToCC may
not match spam.
Understood. That's part of the reason I didn't take to this solution
originally. I assumed that the blacklist_to option would fetch the real
recipient out of the received headers (which, as you can see above, do
contain the "for" clause).
Thanks for the help.
Chris
