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

[Douglas Foster <[e-mail]>]

I remain unconvinced.   Mail is nearly free to the sender, but expensive
and risky for the recipient and his organization.   Anything unwanted
message that gets through the spam filter consumes a person's time, which
is a non-trivial opportunity cost.   Asking me to accept extra cost to
provide "nice to have" data is too much.

Your first scenario is mostly about what an evaluator can do.  I think
there is an opportunity and need to discuss all the ways that an evaluator
can obtain acceptable authentication on a message that fails SPF or DKIM,
but the chairs have been clear that doing so is "not DMARC" and out of
scope.    I don't see is how the aggregate report contents facilitate or
hinder your un-munging algorithm.

I am not a mass mailer with a complicated identity structure, so I am
willing to be educated about the wonderful things that can be learned from
aggregate reports.   Based on my current knowledge, the use cases seem few,
and do not need unaligned results.

1) A server is sending legitimate mail and is correctly configured with
both SPF and DKIM.   The feedback from non-forwarded recipients confirms
this fact.

2) A server is sending legitimate mail on behalf of the domain owner, but
has a configuration error:  no signature, invalid signature, or using a
server not in SPF record.    SPF results from non-forwarded recipients will
identify the problem so that it can be corrected.

3) A signature has been compromised and an unauthorized source is sending
authenticated mail.  SPF FAIL with DMARC PASS provides the alarm trigger.

4) A server is using a delegated signature for an unauthorized purpose.
 Nothing in the reports is likely to indicate this problem.   If it is
detected from other sources, the correction involves revoking the public
key and terminating the offending organization.

5) Some mail is failing authentication after forwarding without MailFrom
rewrite or forwarding with changes.    The IP address and MailFrom address
help to identify the problem but the domain owner has no ability to correct
the problem.   He can use p=none to limit the consequences.

6) Some mail is failing authentication because it originates from an
illegitimate source.      The IP address and MailFrom address help to
identify the problem but the domain owner has no ability to correct the
problem.   He can use p=reject to limit the consequences.

Case 5 and Case 6 are distinguishable only by the reputation of the server
or MailFrom address.   Malicious senders are unlikely to add a signature to
prove their identity, so perhaps a signature suggests case 5 rather than
case 6.   But a competent forwarder will be doing MailFrom rewrite, so the
forwarder identity will be present whether a signature is added or not.

These use cases do not deal with authentication failures after multiple
forwards.   An abundance of signature data might allow the domain owner to
reconstruct the forwarding path, but is that something he needs to do,?   I
don't think so.

As for the duplicate signature issue, my rule would detect support for the
new signature algorithm if it appears first.

I would be happy to hear a case summary which indicates how a real problem
was solved, and was only solvable using non-aligned results.

Doug Foster



On Fri, Oct 21, 2022 at 4:11 AM Alessandro Vesely <[e-mail]> wrote:

> On Fri 21/Oct/2022 00:53:56 +0200 Douglas Foster wrote:
> >
> > Aligned DKIM PASS
> > When an aligned DKIM result is PASS, I don't see that the domain owner
> needs
> > any more data collection performed.   The verifiable DKIM scope ID
> should tell
> > him where the message originated, and the source IP and HELO name tell
> the last
> > place it landed before delivery.    I cannot see why a domain owner
> would spend
> > a lot of time trying to analyze success results, unless his interests
> have
> > transitioned from assuring identity to analyzing marketing impacts.   We
> are
> > not trying to provide marketing data, and any successful use of DMARC
> for that
> > purpose seems like an encroachment on the privacy concerns that we want
> to
> > minimize.
>
>
> Non-aligned signatures can be meaningful for various reasons.  In that
> case,
> the result of their evaluation is also meaningful.  For an example, the
> original author's domain signature, before From: was munged, is
> meaningful.  If
> it fails, it can be retried after undoing MLM transformation, possibly
> leading
> to secure recognition of the true author.  Is that worth its carbon
> footprint?
>
> And for scope, one may wonder whether the recognized, or failed to be
> securely
> recognized original author's domain deserves a copy of the report.  People
> prone to set p=quarantine; pct=0 in order to avoid receiving "errors"
> would
> clearly dislike a copy of the report.  Others may want it, in order to
> tune
> their DKIM signing configuration.
>
>
> > Duplicates:
> > If an aligned domain has multiple DKIM signatures and one passes, I
> suggest
> > that the PASS is the only one that needs to be reported.  If an aligned
> domain
> > has multiple DKIM signatures and none pass, I suggest that the first one
> found
> > (from the top) is the most important, because it is the last one
> applied.   If
> > duplicates are reported, disaggregation is increased, so why report data
> that
> > is not useful?
>
>
> Currently, putting 2 signatures, one rsa and one ed25519, is the way to
> monitor
> who supports the latter.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>