Open emersion opened 5 years ago
The up-to-date spec is RFC 8617 (https://datatracker.ietf.org/doc/rfc861).
Also see https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-07 for usage recommendations.
Implementation considerations I see. Also plan for actions if somebody wants to get that into maddy.
Of course that first needs to have library support in go-msgauth. That likely involves abstracting away DKIM signature primitives that are reused in ARC.
Intact ARC chain literally means nothing to us unless we have some reputation system backing decisions whether to allow ARC to override failing DMARC. I do not see a good way to bring such decision factor into maddy so this is open for discussion.
For the sake of such discussion, I propose having a some trust threshold value sourced from somewhere. All intermediates need to have the trust threshold bigger than a configured value to have chain considered intact. The problem remains about the source of such thresholds and how to calculate them.
Intact ARC chain literally means nothing to us unless we have some reputation system backing decisions whether to allow ARC to override failing DMARC. I do not see a good way to bring such decision factor into maddy so this is open for discussion.
Other software like rspamd
has just adopted an allowlist-based approach. Signers that are to be trusted can be added to the list.
It wouldn't hurt to maintain a "default" list of sorts in maddy itself, those who do not trust say microsoft.com
are free to disable it. Most people would probably be fine with such a configuration though.
Thirdly, if there are any letters that fail DMARC, have an ARC signature (that would fix it) and also have a valid DKIM signature, it could be logged so that the mail operator could more easily add semi-trustworthy signers to their list. This could in theory be used to build a "reputation" of sorts as well, but that's very difficult and IMHO not in the scope of initial support.
In the end though, this is a human trust problem, not anything else. Approaches will always have their limitations.
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-23