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.
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
