search

foxcpp / maddy

✉️ Composable all-in-one mail server.
https://maddy.email
GNU General Public License v3.0
5.07k stars 244 forks source link

ARC support #46

Open emersion opened 5 years ago

emersion commented 5 years ago

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

emersion commented 5 years ago

https://github.com/emersion/go-msgauth/issues/7

foxcpp commented 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.

foxcpp commented 4 years ago

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.

Avamander commented 1 year ago

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.