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 <dotz...@gmail.com> 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 < > dougfoster.emailstanda...@gmail.com> 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 <ves...@tana.it> 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 >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
