Am 2014-04-30 13:15, schrieb Mark Martinec:
> >>> On 04/30/2014 10:10 AM, Michael Storz wrote:
> >>>> Are there any plans for a DMARC plugin for SpamAssassin?
Reacting to a
> >>>> DMARC policy of reject (AOL/Yahoo) seems only feasible with
> >>>> SpamAssassin because so many exceptions are needed for
software which
> >>>> destryes DKIM signatures:
I agree that a DMARC SpamAssassin plugin would be valuable.
How about implementing it in Amavisd-new in addition (I couldn't resist
to ask here too :-)
Currently the closest thing we have in SpamAssassin is ASDP
(Author Domain Signing Practices), implemented by the DKIM plugin.
Compared to DMARC it only cares for DKIM signatures and ignores SPF,
and offers no reporting.
If you want to implement a similar effect to the new yahoo and
aol DMARC policy by SpamAssassin, use rules similar to the
default rules in 60_adsp_override_dkim.cf:
adsp_override yahoo.com custom_med
adsp_override yahoo.com.ar custom_med
adsp_override yahoo.com.au custom_med
adsp_override yahoo.com.br custom_med
adsp_override yahoo.com.cn custom_med
adsp_override yahoo.com.hk custom_med
...
Either replace 'custom_med' with 'all' or 'discard',
and/or adjust/increase scores for:
score DKIM_ADSP_CUSTOM_LOW 0.001
score DKIM_ADSP_CUSTOM_MED 0.001
score DKIM_ADSP_CUSTOM_HIGH 0.001
score DKIM_ADSP_ALL 0 1.1 0 0.8
score DKIM_ADSP_DISCARD 0 1.8 0 1.8
score DKIM_ADSP_NXDOMAIN 0 0.8 0 0.9
I have looked at this too. For Paypal this would be ok. But for Payal a
pure DMARC rule is easy to write:
# _R = DMARC relaxed alignment mode, _S = DMARC strict alignment mode
header __LRZ_ENVFROM_PAYPAL_R EnvelopeFrom =~
/paypal\.[a-z]+$/i
header __LRZ_FROM_PAYPAL_R From:addr =~ /paypal\.[a-z]+$/i
meta LRZ_DMARC_PAYPAL_REJECT (__LRZ_FROM_PAYPAL_R && !
(DKIM_VALID_AU || (__LRZ_ENVFROM_PAYPAL_R && SPF_PASS)))
For AOL and Yahoo, there are too many false positives, if you just use
the rules without exceptions. Therefore my rules for AOL and Yahoo are
much more complicated, but they work without too many false positives in
my environment. For GMAIL (I know they did not publish a reject policy)
I am still getting a lot of false positives because of all the web
applications which use the address of the user as from. And in this case
you cannot use normal DMARC rules because of the mixture of the Google
organizational domains (gmail.com, googlemail.com, google.com and
googlegroups.com) and the different signing domains in the same message
:-( At the moment DMARC does not allow more than one organizational
domain for alignment.
> >>> How could a SA plugin help?
> >>> Isn't this something that should be handled at MTA level?
Not in my view. The SpamAssassin prides itself with collecting spam
scores based on various criteria, the DMARC or ASDP policy is just
one of such criteria. If one wants to block mail violating sender
policy one can bump up corresponding scores. More useful than hard
blacklisting is often the balanced resulting spam score.
Yup, that's right. At the moment I am using 5.1 as the score of my
reject rules. Bayes and DNSWL can lower it to ham, other firing rules
will increase the score to rejecting.
Btw, SpamAssassin (as well as amavisd) can be coupled with an MTA
as a before-queue filter (milter or proxy), so mail can be rejected
there too (not just bounced or tagged or quarantined).
Tom writes:
> I proposed a DMARC plugin for spamassassin on the dmarc mailing
list
> last year, to make it easier for people to give DMARC a spin.
They
> didn't really like the idea (I still do), because a simple
plugin
Jim P. writes:
> wouldn't do the report sending, which is an important part of
DMARC.
Sending reports can leak data (think: HIPAA). Know what you are
leaking to others.
Michael writes:
Right, therefore nearly no one is sending forensic reports, only
aggregate reports.
I wouldn't do the reporting at our site, even if offered by a DMARC
plugin. Remember SpamCop plugin? I think such feedback is not of high
value to a sending or to a policy site.
So in summary, I'm in favour of a DMARC SpamAssassin plugin, as
SA already has access to SPF and DKIM results. The configuration
approaches can mimic the existing ASDP in the DKIM plugin, concepts
are very similar (apart from reporting).
Mark
--
Michael
