Labsy wrote: I have numerous incidents on different domains (all properly setup SPF records with hard fail) being able to normally fake FROM e-mail and being normally received by Zimbra server. SPF score is set to add 10 points, but in maile header I see only 0.001 points are added for SPF filter.
Meaning, without quite a lot of hassle SPF is NOT engaged by default...at least in my situation.
I would agree with this... it isn't easy out of the box because while it seems SPF is easy to understand, it is overly simplistic and fails to solve spoofing in many instances.
IMO, if you want local SPF reject of your own domains and others too, than rspamd is perhaps a better solution given it can be deployed as a milter. This allows for the rejection of the envelope-from or helo during the SMTP dialog but before accepting the message. On the other hand, if you accept the email as Zimbra does by default than we preserve the envelope-from via a Return-Path header and pass it on to amavisd who will eventually pass it on to SA for checking. If we rejected the email now, we would then contribute to backscatter so scoring to spam or not deliver it are best options for following SPF policy. The real problem is that SPF breaks forwarding so real email gets bounced which decreases your users perception of the service you are offering. The best thing SPF does is in the reduction of backscatter on your domains provided the target follows your policy and as a component in DMARC "from" alignment. From a users perspective, the header-from can still be spoofed with SPF so what are you really accomplishing? To really prevent spoofing, digitally signing that header-from in addition to a few other headers in your email (DKIM) seems like the best solution currently.
Here are some ways to use SPF and DKIM to stop spoofing after you have already accepted email for your domains.
Code: Select all
header __FROM_FACEBOOK Return-Path:addr =~ /no-reply\@facebook\.com/i
meta __FORGED_SENDER (!SPF_PASS && !DKIM_VALID_AU)
meta FORGED_FACEBOOK_FROM (__FROM_FACEBOOK && __FORGED_SENDER)
score FORGED_FACEBOOK 5 5 5 5
The above is from /opt/zimbra/conf/sa/sa_local.cf ... On my own servers, I do it slightly different like this in my salocal.cf:
Code: Select all
#spoofed from
header __SPFSENDER_FROM From =~ /\@example\.com|\@example\.net/i
meta J_SPOOFED_FROM (__SPFSENDER_FROM && !DKIM_VALID_AU)
score J_SPOOFED_FROM 7
describe J_SPOOFED_FROM Not DKIM signed
meta J_WHITELISTUS (!J_SPOOFED_FROM && __SPFSENDER_FROM && DKIM_VALID_AU)
score J_WHITELISTUS -15
describe J_WHITELISTUS Kludge for mime parser FP
Note: I believe there is also a 10 lookup rule so if you have a few includes in your SPF records, double check you don't overshoot that if you have added outside vendors to that SPF record. It is becoming pretty rare to find
strict SPF policy "-all" for most big mail providers given the problems associated with SPF false positives. Just a few years ago, they all had
"-all" and told us we should too
- so things are changing.
Code: Select all
% dig +short _spf.google.com txt
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
% dig +short _spf.mail.yahoo.com txt
"v=spf1 ptr:yahoo.com ptr:yahoo.net ?all"
% dig +short aol.com txt
"'4a751cdeec084ee2bc9e2cb2e94ba8af'"
"v=spf1 ip4:204.29.186.0/23 include:spf.constantcontact.com include:aspmx.sailthru.com include:mail.zendesk.com include:_ipspf.yahoo.com ~all"
"spf2.0/pra ip4:204.29.186.0/23 include:spf.constantcontact.com include:aspmx.sailthru.com include:mail.zendesk.com ~all"
DMARC is a much better alternative to publish those stricter SPF/DKIM policies... And I just realized the OP was from Oct. Better get my first cup of coffee. You guys got me. LOL
HTH
Jim