On Mon, Oct 24, 2022 at 5:47 AM Alessandro Vesely <[email protected]> wrote:
> 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. > > It may or may not be performed by the same filter which looked up the From: domain policy. So what? That same filter may also consider reputation while the SMTP session is held open. That doesn't make reputation part of DMARC. > > > >> 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. > ARC is a different signature not an "unaligned signature". > > > 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. > Splitting out reporting is a good thing. Perhaps it should be renamed so that it is not DMARC centric. I would suggest the fact that something (ARC) which is not DMARC is included in the reporting that was developed as an integral part of DMARC is a matter of convenience more than anything else. > > > >> 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. > As I wrote above, it is more a matter of convenience than anything else. Generating separate ARC reports is duplicative effort from both a report generating perspective as well as consumption of those 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 > -- > Michael Hammer
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
