I think this seems like diminishing returns, and I'm inclined to push the "publish" button tomorrow after the IETF meeting ends. If you really want to pursue this we can handle it as an IETF Last Call issue. But, really, think about whether it's worth the trouble for the benefit.
Barry On Thu, Nov 6, 2025 at 6:03 PM Al Iverson <[email protected]> wrote: > > On Wed, Nov 5, 2025 at 12:04 PM Alessandro Vesely <[email protected]> wrote: > > > > On Wed 05/Nov/2025 17:57:33 +0100 Al Iverson wrote: > > > > > > I think it was overkill to remove (sometimes referred to as "forensic > > > reports") from section 7. I don't know enough to know if there's an > > > IETF terminology reason to remove that, but assuming not, my > > > recommendation is to restore it, just because it helps drive > > > understanding -- driving the connection that regardless of which term > > > is used, that's what we're ultimately referring to. Meaning, it > > > bridges an understanding gap, and that's generally a positive thing. > > > > Todd asked for it to be removed, because the word "forensic" doesn't appear > > in > > either DMARCbis or the Aggregate Reporting document. > > > > If we want to restore it, it should be after the first occurrence of the > > term > > "Failure reports", in the Introduction. > > Thank you for this. Not sure that I have much of a strong opinion on > this after all, the more I think about it. I think I'll let that go > unless others pipe up with a strong opinion. > > > > Also in section 7, I don't understand this statement: "On the other > > > hand, a Domain Owner publishing an internal Report Consumer, can put a > > > dot-forward at that mailbox." Could somebody ELI5? I mean, I know what > > > email forwarding is, and I understand most of these words, but I think > > > there's context missing. (I'd also suggest rewording it to not use the > > > inside baseball term "dot-forward," but I'm not able to offer a > > > rewrite because I'm missing something about the broader context of the > > > statement.) > > > > Section 7.2 speculates on the recipient type indicated in the ruf=tag. It > > prompts report generator to consider the recipient type they are sending > > reports to. Invoking dot-forward warns that, in any case, the information a > > report generator reads from the DMARC Policy record may not include all end > > recipients. > > Thank you for explaining! My suggestion would be a reword like: "On > the other hand, a Domain Owner publishing an Internal Report Consumer > could be publishing a destination address that is actually some time > of forwarding address, meaning that a report's final destination may > not be guaranteed." Or something like that. Though I grant how saying > "dot forward" is a concise way of explaining that to an email nerd, I > am not totally sure that's how you'd want to write a technical > document about it. Anybody agree/disagree? > > Cheers, > Al Iverson > > -- > > Al Iverson // 312-725-0130 // Chicago > http://www.spamresource.com // Deliverability > http://www.aliverson.com // All about me > https://xnnd.com/calendar // Book my calendar > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
