On March 19, 2023 7:30:55 AM UTC, Wei Chuang <[email protected]> wrote: >On Wed, Mar 15, 2023 at 5:05 AM Scott Kitterman <[email protected]> >wrote: > >> >> >> On March 15, 2023 6:55:15 AM UTC, Wei Chuang <weihaw= >> [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. >> >> >> >> 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?
I think this kind of work is better done in the open. I think M3WAAG does great work, but it's for a particular audience that isn't particularly inclusive. I suspect that anything that's developed in a private, pay to play environment will miss the mark with a significant fraction of the target audience (although maybe there's a way to get non-members involved sufficiently to work through this). Generically, I think a BCP is a good place to start. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
