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

[Douglas Foster <[e-mail]>]

My closing should have said:

"I would be happy to hear a case summary which indicates how a real problem
was solved by a domain owner, and was only solvable using non-aligned
results obtained from aggregate reports."

df

On Fri, Oct 21, 2022 at 5:57 PM Douglas Foster <
[e-mail]> wrote:

> 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
>>
>