Bug 7189

Summary: DMARC Plugin Specification / Discussion
Product: Spamassassin Reporter: Kevin A. McGrail <kmcgrail>
Component: PluginsAssignee: SpamAssassin Developer Mailing List <dev>
Status: RESOLVED FIXED    
Severity: normal CC: apache, davej, giovanni, kmcgrail, me, rwmaillists
Priority: P2    
Version: 3.4 SVN branch   
Target Milestone: 4.0.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Bug Depends on: 6918    
Bug Blocks:    

Description Kevin A. McGrail 2015-05-05 22:08:51 UTC 
SpamAssassin needs to support DMARC.  

My current ramble of thoughts is broken into two Stages.

First, for Stage 1 Proof of Concept there is an assumption that you have a milter.
- in a milter as the email comes in, strip any and all pre-existing Auth results headers
- then I would have the milter that does the DMARC tests and adds a new Auth results header
- finally, I would make SA be able to react based on a new Auth results header possibly with just a set of rules.

The requirement here is you have a milter that adds a header such as the opendmarc milter.

Stage 2 Enhancement to not require a milter

Then the next step would be to add a native plugin for SA for testing DMARC that doesn't require a milter so you can get the same results (and hopefully hook into the same rules above with an eval).  This gives the end-user of SA flexibility and makes the implementation/scoring consistent.

To me it does seem like the best way is to look at http://www.trusteddomain.org/opendmarc/ and use the libopendmarc with a perl wrapper.  i.e. download from http://sourceforge.net/projects/opendmarc/ and then use something like http://search.cpan.org/~shari/Mail-DMARC-opendmarc-0.11/lib/Mail/DMARC/opendmarc.pm to call the lib directly from a plugin in spamassassin to then.


Any input why not to use opendmarc for the basis of the plugin?

Regards,
KAM
Comment 1 Dave Jones 2017-06-14 22:14:51 UTC 
Anyone out there willing to take a stab at a DMARC plugin?  Even just a draft patch to get this ball rolling?  This is really important and should be included in SA like SPF and DKIM is.
Comment 2 RW 2017-06-20 20:51:11 UTC 
There's an intermediate possibility between 1 and 2 where all of the trusted authentication headers are examined and a pass from any one overrides any fail. 

IMO this is the optimum solution for almost everyone. Where forwarding or pop/imap retrieval is involved, upstream headers can be much more reliable. If you are running a mail server I would think you would want dmarc reports and rejects handled before the mail reaches SA, in which case a header might just as well be added.

The most significant case where it wont work is when a service provider adds the header out of order and it can't be trusted, but this need only break dmarc based whitelisting, a dmarc fail should be fine.
Comment 3 Dave Jones 2018-01-30 22:00:17 UTC 
GSoC 2018 project?
Comment 4 Kevin A. McGrail 2018-01-31 13:52:06 UTC 
(In reply to Dave Jones from comment #3)
> GSoC 2018 project?

Definitely.  I'm making a list as we speak.
Comment 6 Benny Pedersen 2018-01-31 14:36:48 UTC 
https://github.com/msimerson/mail-dmarc

imho this is the active repo for it, i like to make the AR header parsing another sa plugin if needed, this perl module here is more native to dmarc testing in sa
Comment 7 Giovanni Bechis 2021-05-18 10:16:58 UTC 
On https://github.com/bigio/spamassassin-dmarc there is a working Dmarc plugin,
atm it does queries and can be configured to store reports using Mail::Dmarc.
Arm it does not read authentication headers.
Comment 8 Henrik Krohns 2021-05-18 10:51:31 UTC 
(In reply to Giovanni Bechis from comment #7)
> On https://github.com/bigio/spamassassin-dmarc there is a working Dmarc
> plugin,
> atm it does queries and can be configured to store reports using Mail::Dmarc.
> Arm it does not read authentication headers.

Atleast it shouldn't use uri_to_domain. Mail::DMARC does it's own correct processing with Public Suffix List.
Comment 9 Benny Pedersen 2021-05-18 12:42:48 UTC 
dont forget ARC, thats why i say AuthRes needs more love, mail-dkim nearly have all that is needed for dkim, arc, and authres, and end in dmarc, dmarc must validate arc chains, just using spf, dkim, is a fail for dmarc
Comment 10 Giovanni Bechis 2021-05-18 15:32:24 UTC 
(In reply to Henrik Krohns from comment #8)
> (In reply to Giovanni Bechis from comment #7)
> > On https://github.com/bigio/spamassassin-dmarc there is a working Dmarc
> > plugin,
> > atm it does queries and can be configured to store reports using Mail::Dmarc.
> > Arm it does not read authentication headers.
> 
> Atleast it shouldn't use uri_to_domain. Mail::DMARC does it's own correct
> processing with Public Suffix List.

I have uncommitted code that get rid of uri_to_domain calls.
Comment 11 Henrik Krohns 2022-04-11 13:01:07 UTC 
It's already committed, dunno if there's anything to discuss here. My only gripe is that it's named "Dmarc" as the protocol is clearly "DMARC", but I guess it'll have to do..
Comment 12 Henrik Krohns 2022-04-22 17:16:04 UTC 
FYI.. sorry but the name irritated me, so I renamed Dmarc.pm -> DMARC.pm. Loadplugin has backwards compatibility for old name.

Cleaned up the code a lot.

Sending        trunk/MANIFEST
Sending        trunk/UPGRADE
Sending        trunk/lib/Mail/SpamAssassin/Conf.pm
Adding         trunk/lib/Mail/SpamAssassin/Plugin/DMARC.pm
Deleting       trunk/lib/Mail/SpamAssassin/Plugin/Dmarc.pm
Sending        trunk/lib/Mail/SpamAssassin/Util/DependencyInfo.pm
Sending        trunk/rules/v400.pre
Sending        trunk/t/all_modules.t
Sending        trunk/t/debug.t
Sending        trunk/t/dmarc.t
Transmitting file data .........done
Committing transaction...
Committed revision 1900161.
Comment 13 Henrik Krohns 2022-04-25 17:01:58 UTC 
Can someone please check if 25_dmarc.cf looks proper for stock rules. I have very little knowledge right now about DMARC and all the policies.

Sending        trunk/lib/Mail/SpamAssassin/Plugin/DMARC.pm
Adding         trunk/rules/25_dmarc.cf
Sending        trunk/t/dmarc.t
Transmitting file data ...done
Committing transaction...
Committed revision 1900272.