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

[Douglas Foster <[e-mail]>]

I continue to object to the notion that unaligned domains are relevant to
DMARC reporting, even on a "conditionally useful" basis.

This has become a scope issue:  what does DMARC do for domain owners?   My
answer:

DMARC defines an approach to proxy verification of the FROM address, using
SPF-verified MailFrom and verified DKIM domains as the proxy agent.

DMARC Aggregate reports help domain owners inventory their legitimate
senders to ensure that all messages originate with dual authentication.
This requires reports to include the server identity, the MailFrom
identity, and the evaluation result.   Disposition results are not needed,
but having information about message rejection volumes will help a domain
owner prioritize his efforts.

DMARC policy allows a domain owner to announce to recipient evaluators that
all of his legitimate outbound mail originates with dual-authentication.
 This is expected to influence how recipient evaluators handle
unauthenticated messages.

DMARC Aggregate reports identify unauthenticated messages that are
delivered by servers outside the domain owner's control.  In some cases,
this may help identify servers and server organizations that are candidates
for takedown efforts by law enforcement.   This requires reports to include
the server identity, the MailFrom identity, and the evaluation result.
 Disposition results may be useful to help law enforcement prioritize their
efforts against the biggest offenders,

The domain owner cannot control message flow after it leaves his
organization, and the domain owner cannot fix a forwarding operation that
causes a message to arrive without verification.

It is the recipient evaluator's problem to determine whether an
unauthenticated message is an acceptable forward, an acceptable
impersonation, or an unacceptable malicious impersonation.   ARC is a way
for a forwarder to attempt validation with the recipient evaluator.   The
domain owner can neither trigger this process nor  influence its
results, so he is irrelevant.   An aggregate report can document that ARC
validation was accepted by the evaluator, to gauge the extent of ARC
support.  It can also identify a particular forwarder as non-malicious, and
therefore not a candidate for law enforcement, based on the judgement of a
particular evaluator.

Nothing in this list uses knowledge about unaligned signatures, and
therefore any craving for unaligned signature data must come from a
non-DMARC direction.

DMARC is complex.   Reporting unaligned signatures to domain owners is an
unnecessary complexity, and one that also seems inappropriate.

Doug


On Mon, Oct 24, 2022 at 5:48 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.
>
>
> >> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>