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
