Proceed to hit publish. I support this draft. Thank you all for taking the time to answer my questions and concerns!
Cheers, Al Iverson On Thu, Nov 6, 2025 at 9:22 PM Barry Leiba <[email protected]> wrote: > > 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] -- 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]
