On 1/6/2010 6:47 AM, lstep wrote:
Hello,
I get spams that have an 'Envelope-From' (Sender, or equivalent attribute)
different from the 'From' header contained in the mail. The spam sets the
'From' in the header to an (existing) internal user.
If the spammer would have set the Envelope-From to an internal user as well,
he would have been blocked, not by Spamassassin, but by the MTA (Postfix),
where I set the list of IP allowed to send mail as an internal user.
Is there something implemented in Spamassassin to test and prevent mails
that come from 'outside' that have the header 'From' set to an internal
user?
It's very difficult... checking the MAIL FROM is rather straightforward
with SPF policy checks. We test during SMTP session time using
Postfix's policy service and deny if the SPF record is set to "-all" and
it doesn't validate. So nothing with a SPF_FAIL gets as far as SA.
The closest that I got for "From" forgery was to create a few rules and
then meta them together. And even then, I don't dare set the score much
higher then 2.5.
First a rule to see if if the "From" was purporting to be from our domain.
header __LOCAL_FROM_OURDOMAIN
From =~ /\@(domain1|domain2|domain3|domain4)\.com/i
A check to see if it's a mailing list (this needs to be converted into a
meta-rule that determines a few different ways whether it's a mailing
list). On the upside, most mailing lists are listed in one of the DNS
based whitelists and already come with a negative score when scored by SA.
header __LOCAL_ISMAILINGLIST
List-ID =~ /\<.+\>/
A really braindead test to see whether the Received-SPF line indicated
that it was from one of our servers.
header LOCAL_SPF_OURSERVER
Recieved-SPF =~ /(domain1|domain2|domain3|domain4)/i
score LOCAL_SPF_OURSERVER -1.0
And finally a meta rule that ties it all together and scores it.
meta LOCAL_FORGED_FROM
(__LOCAL_FROM_OURDOMAIN && !SPF_PASS &&
!LOCAL_SPF_OURSERVER && !__LOCAL_ISMAILINGLIST)
score LOCAL_FORGED_FROM 2.5
describe LOCAL_FORGED_FROM From address is forged as our domain
But I'm not totally convinced that this rule set works properly. There
are bound to be corner cases that I haven't considered. However, on our
system, we don't delete high-scoring messages - they merely get
quarantined (moved server-side with a Sieve script) into the user's IMAP
Junk folder. And we only quarantine for stuff over ~9.0. So the cost
of a high-scoring false-positive is low.
