Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Dotzero <[e-mail]>]

On Mon, Oct 24, 2022 at 5:47 AM Alessandro Vesely <[e-mail]> wrote:

> On Sun 23/Oct/2022 14:16:30 +0200 Dotzero wrote:
> > On Sun, Oct 23, 2022 at 6:29 AM Alessandro Vesely <[e-mail]>
> 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