Bug 7189 - DMARC Plugin Specification / Discussion
Summary: DMARC Plugin Specification / Discussion
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 3.4 SVN branch
Hardware: PC Windows 7
: P2 normal
Target Milestone: 4.0.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on: 6918
Blocks:
  Show dependency tree
 
Reported: 2015-05-05 22:08 UTC by Kevin A. McGrail
Modified: 2019-10-02 10:17 UTC (History)
5 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
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