On Sun 23/Oct/2022 14:16:30 +0200 Dotzero wrote:
On Sun, Oct 23, 2022 at 6:29 AM Alessandro Vesely <[email protected]> wrote:
On Sat 22/Oct/2022 18:25:55 +0200 Dotzero wrote:
Unaligned signatures are orthogonal/irrelevant to DMARC. They may be useful in
other contexts. In the DKIM standard, signatures mean that the signer is
asserting some (unspecified) responsibility for the signed message. That may be
useful for some reputation systems.
Somewhat skewed w.r.t. orthogonality, actually. Indirect flows are
explicitly mentioned in the I-D as a reason to override DMARC dispositions:
DMARC only gives a pass if either SPF or DKIM passes. Unaligned DKIM
signatures will NEVER give a DMARC pass.
How about dmarc=redeemed?
There MAY be an element for reason, meant to include any notes the
reporter might want to include as to why the disposition policy does
not match the policy_published, such as a Local Policy override
(possible values listed in Appendix A).
Local Policy is just that. When a Receiver invokes Local Policy it is
saying "I don't care what DMARC says, I'm choosing to ignore DMARC Policy
and do something else".
It is a local decision to trust an ARC seal or an unaligned signature,
depending on the signing domains. Yet, the decision can be made by the same
filter which looked up the From: domain policy.
ARC too is a kind of unaligned signature, albeit with a bunch of
additions. The extra information it carries, designed to bestow enough
trust in the chain of custody to outweigh the self-referential reliance of
aligned From:, doesn't substantially change the semantic of DKIM
signatures. And we should say how to report it, sooner or later.
> ARC != DMARC. It is a separate RFC that gives participants an alternative
means of evaluating mail flows when DKIM signatures are broken. Nothing
more and nothing less.
Conflicting protocols? ARC was devised by the DMARC WG, during the phase of
"improving the identification of legitimate sources that do not currently
conform to DMARC requirements." So, yes, on the one hand, since unaligned
signatures don't conform to DMARC requirements, they're not DMARC. On the
other hand, as a fusion of deterministic authentication techniques and domain
policies, DMARC is intrinsically extensible. For aggregate reporting in
particular, we explicitly provide for extensions.
I'm not proposing to mandate the evaluation of any evaluable item.
However, I'd neither discourage it. Perhaps technology will provide us
with ecological sources of energy.
There is nothing wrong with using whatever data points you have available.
That doesn't necessarily mean that such evaluations and choices are DMARC.
If ARC were a separate thing, it'd make no sense to include its data in DMARC
aggregate reports.
I think what we could do is to identify some criteria that a report generator
may follow, such as doing everything, reporting up to X signatures, or doing
SPF only. Such meta data could be useful to report consumers, along with the
generator's software/version.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
