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

[Dotzero <[e-mail]>]

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

This is incorrect. SPF FAIL with DMARC PASS can simply be an indirect mail
flow. It might also be an incorrectly configured SPF record.

Michael Hammer

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
>>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>