Let's recap what we know about the ARC experiment: We have two major players who have tried the ARC.
For Outlook.com, Microsoft is using ARC to document their role as originator or outbound gateway. ARC does not provide the appropriate authentication mechanisms for this, so Microsoft makes up results. I have seen both irrelevant FAILs and justified PASS results from them. Clearly ARC is not meeting their needs. ARC assumes that an A-R record is used to transmit results between inbound gateway and outbound gateway, which is one of its weakest design points and an obstacle to defining new authentication types. Google has ignored this problem by creating ARC sets on every incoming message. Now we have Wei from Google participating directly, and he is telling us that ARC does not meet Google's needs very well. Google also wants to see ARC sets created by originators, as Microsoft has been doing. More generally, they see a need for ARC sets to be created by both incoming gateways and outgoing gateways. But currently, ARC does not currently provide a way to report identifier states independently of authentication, so it needs changes to support standalone reporting by outbound gateways. Someone said awhile back that "implementation trumps specification". We don't need a BCP to tell people how to use ARC as-is more effectively We need to a revised ARC specification based on what its implementers want and need. Doug On Sun, Mar 19, 2023 at 11:39 AM Scott Kitterman <skl...@kitterman.com> wrote: > > > On March 19, 2023 7:30:55 AM UTC, Wei Chuang <wei...@google.com> wrote: > >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? > > 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
