For the replay resistance part of the question, I think it would make sense to wait and see how the DKIM working group addresses the problem for DKIM generally and then assess how their solution impacts ARC and how it addresses the issue for ARC.
I think the question of spamminess is orthogonal to the authentication questions that ARC attempts to answer. It's subjective, so I don't think it can really play into ARC. Additionally, if the intermediary thinks a message is bad (spam), then the solution is to not send the message onward and try to make it someone else's problem. Scott K On March 14, 2023 2:49:30 PM UTC, Wei Chuang <weihaw=40google....@dmarc.ietf.org> wrote: >Hi all, >We've been making use of ARC to help with forwarded mail. One thing we've >noticed is differences for when some forwarders generate the ARC headers. >Another concern is that we've seen spammers attempt to manipulate ARC >headers. >1) ARC could benefit from more refinement of interop such as when to >generate ARC headers e.g. if the message appears spammy? and how should the >ARC-Authentication-Results be reported if there is a local policy >override? Would it be helpful to clarify this with a BCP? >2) Considerations on what to do about ARC header spoofing and replay. I >have an I-D >https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/ that >outlines some ideas on mitigating that (particularly the "SeRCi" idea) as >one starting point. (In case it matters I should point out the DARA idea >in the draft is more oriented towards DKIM). >-Wei _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
