On Monday, December 6, 2021 3:04:37 PM EST Dave Crocker wrote: > On 12/6/2021 11:56 AM, Scott Kitterman wrote: > > Somewhere we need to explain about how ARC related to DMARC. If it's > > going to be in the protocol specification, this is the place. Otherwise > > it would go in the appendix I keep mentioning that we need which explains > > options senders, intermediaries, and receivers can do to mitigate DMARC > > interoperability challenges. > > > > I think it's slightly better to do it in an appendix , as long as we > > remember to write it. > You want to comment on ARC in the DMARC specification? Don't do that. > > ARC currently has nothing to do with DMARC. And DMARC currently has > nothing to do with ARC. > > To change this will require writing a specification, presumably as an > enhancement to DMARC, to include consideration of ARC. > > In technical terms, the ARC specification must not know about or care > about DMARC, since ARC is attempting to augment DKIM, rather than an > upper-level function that uses DKIM, which is what DMARC is. > > If it helps, draw boxes with labels for different functions, like SPF, > DKIM, and DMARC. Draw arrows between them,to establish which provides > functionality and which uses it. > > A providing specification must not know or document anything about a > consumer. Otherwise it is, effectively, a layer violation. It also > invites messy complexity and out-of-date references, as specifications > change. > > To the extent that there is a strong benefit in having a document that > discussion an aggregation of components, then it's a separate operations > or architecture document.
That's fine. I was thinking something conceptually similar to RFC 7208 Appendix D, but I think there's nothing wrong with a separate document if that's what the group prefers. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
