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

[Douglas Foster <[e-mail]>]

Yes, it could have multiple causes.

  I was just trying to elucidate a reason why unaligned signatures are
needed.

Instead I conclude that one best aligned signature is all that is needed
for reporting.  Not 100, not 10, just 1.

Doug

On Sat, Oct 22, 2022, 7:43 AM Dotzero <[e-mail]> wrote:

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