Apologies for repeating myself here and creating noise. I'm just re-walking through the thread, trying to get to Scott's subsequent response, which I wanted to get to. -Wei
On Sun, Mar 19, 2023 at 12:19 AM Wei Chuang <[email protected]> wrote: > > > 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. >> > > Agreed. > > >> 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. >> > > Agreed. I'd like to encourage folks to generate ARC headers even if the > message is perceived to be somehow spammy. > > >> 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. >> > > Some of this is because the intermediary doesn't realize a particular > message is spammy. However the forwarder suspects that some forwarded mail > might contain spam, and doesn't want to help authenticate that at all, > hence doesn't generate ARC headers. This despite knowing it could help the > receiver better apply DMARC policy. > > -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
