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