On Wed, Mar 15, 2023 at 5:05 AM Scott Kitterman <skl...@kitterman.com> wrote:
> > > On March 15, 2023 6:55:15 AM UTC, Wei Chuang <weihaw= > 40google....@dmarc.ietf.org> wrote: > >On Tue, Mar 14, 2023 at 9:11 AM Scott Kitterman <skl...@kitterman.com> > >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 > > I think this may get to the core of the issue. > > ARC doesn't provide any authentication itself, it's a mechanism for > forwarding the received authentication. If people are thinking of ARC as > providing authentication, I don't think they are looking at it correctly. > > Any receiver (either original or post-ARC) shouldn't assume that the ARC > results are in any way related to classification of a message as spam/not > spam. ARC from a trusted relay can yield an identity to use as an input > for domain reputation, which can aid in classification, but that's two > critical steps away from the ARC data in the message: > > 1. Knowing if the source of the ARC data is sufficiently trustworthy to > believe the data (since, as you say, the bad guys lie). > > 2. Having a useful set of domain reputation data. > > Neither of those items are ones that can be 100% accurate. ARC isn't a > protocol that produces a definitive result that can be used to mechanically > alter message delivery that people would like for it to be. > Agreed. > In contrast to DKIM, ARC signing a message doesn't imply taking > responsibility for the message. It implies accurately communicating the > DMARC status that was received. I don't know how to communicate that > effectively to the people making design decisions about mail systems. I > doubt they generally read IETF mailing lists (or RFCs). > While established forwarders that already generate ARC headers may or may not pay attention to the IETF mailing lists, forwarders that want to set up ARC will come visit and look up the RFCs. So I would argue there is value in creating a BCP. If the IETF effort bar is high due to the rigor involved, then perhaps something more light weight at M3AAWG to start with? -Wei > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
