On Tue, Mar 14, 2023 at 9:11 AM Scott Kitterman <[email protected]> wrote:
> 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. > Likely the issue is that the intermediary doesn't think of the specific message as being spam, yet is worried about the possibility of authenticating spam so drops ARC for some scenarios. The receiver still could benefit from seeing the Authentication-Results of the intermediary. In other scenarios, the ARC headers are intentionally broken by a spammer. Should non-malicious forwarders of those messages still generate ARC headers? Keep in mind, the forwarder again might not realize the message is spammy -Wei > > Scott K > > On March 14, 2023 2:49:30 PM UTC, Wei Chuang <weihaw= > [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
