Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARC support #46

Open
emersion opened this issue Apr 11, 2019 · 4 comments
Open

ARC support #46

emersion opened this issue Apr 11, 2019 · 4 comments
Labels
new feature New feature. rfc Request For Comments (ongoing discussion / research needed).

Comments

@emersion
Copy link
Collaborator

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-23

@emersion emersion added the new feature New feature. label Apr 11, 2019
@emersion
Copy link
Collaborator Author

emersion/go-msgauth#7

@foxcpp
Copy link
Owner

foxcpp commented Aug 15, 2019

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.

@foxcpp foxcpp added this to the X.Y - "Eventually" milestone Feb 10, 2020
@foxcpp
Copy link
Owner

foxcpp commented Jun 24, 2020

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.

@foxcpp foxcpp added the rfc Request For Comments (ongoing discussion / research needed). label Jun 24, 2020
@foxcpp foxcpp removed this from the X.Y - "Eventually" milestone Jul 16, 2020
@Avamander
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature New feature. rfc Request For Comments (ongoing discussion / research needed).
Projects
None yet
Development

No branches or pull requests

3 participants