Scott Kitterman wrote: > On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss > <dmarc-discuss@dmarc.org> wrote: >>The question is not who you trust - ARC doesn't directly change that - >>but how you reliably automate determining whether the message was >>forwarded only by people that you trust. At present, you have to dig >>through Received: headers, infer per-forwarder internal structure and >>behaviour and, frequently, guess. ARC addresses that problem, not the >>one you're asking about. > > I don't see why the signing domain of the DKIM signature that could be > added by the most recent sender doesn't already give an identifier to use > to evaluate trust in the sender.
It does, but that only allows you to identify - and apply your trust assessment to - the most recent sender. ARC provides a means to automatically assess the chain *upstream* of the most recent sender. It might be worth pointing out that trust is this context is not absolute, and should not be transitive, because: - trusting the integrity (good intention) of the forwarder is not the same as trusting the competence of the forwarder, and - there are different competences that you may or may not be willing to trust (ability of a forwarder to ARC/DKIM sign correctly and maintain secrecy of keys is a *far* lower bar than ability of a forwarder to make exactly the same decisions about what abuse to exclude as those that you as receiver would make, particularly when you make local, secret decisions as part of doing so; this distinction gets increasingly acute as receivers get larger). > I can see that ARC gives a way to communicate information about > the upstream senders, but I don't see how that's related to DMARC. Many receivers implementing DMARC wish to be able to make decisions about when to ignore p=reject on a more fine-grained basis than all-or-nothing trust of the most recent sender. ARC is built to facilitate this and, therefore, is directly relevant to DMARC. > From a DMARC perspective, if you know the sender is trustworthy, you do a > local override. ARC doesn't seem to be needed for that. You keep talking about "the sender" as if there were only one. In your message to which I am replying, there are 7 Received: headers in various formats from 3, 4 or 5 ADMDs, interspersed with various information about authentication assessments. This is tough for me to assess as a human with considerable expertise in this area. For software to do it reliably would be both difficult and fragile. If you don't get why being able to perform this assessment automatically and reliably is valuable then ARC is never going to make sense to you, no matter how many detail questions you ask. I'd suggest that this may simply mean that ARC is not relevant to you and that, therefore, it may be the case that you can safely ignore it while those for whom the problem is relevant move forward to run the experiment. >>The amount of discussion to date about specific historical whitelist >>proposals is neither here nor there. The question is whether ARC's >>degree of support for reliable automatic chain-of-custody assessment >>provides a material improvement for a group of receivers interoperating >>with a group of forwarders. So long as the answer to that question is >>yes, then this is progress. I'd suggest that: >> >>* large receivers are generally keen to implement things that >>materially improve their ability to separate wheat from chaff (ARC does >>this if it's implemented by any significant subset of mailing-list >>operators), and >>* at least some of the mailing-list operators whose discomfort with >>DMARC interoperation is the need to disrupt long-traditional norms >>(leaving From: unchanged but tagging Subject:, stripping multiparts, >>adding footers, ...) will be willing to perform ARC processing on >>messages on the way in, in order to interoperate without giving up >>traditional mailing-list operations. >> >>If these are both true, then ARC is a clear benefit. > > Only if ARC processing materially affects if receivers are willing to > consider the mailing list as trusted. No, as with *ALL* protocol specifications, decisions about who to trust are out of scope. Operators will always make their own decisions about who to trust, protocol specifications can't usefully take over this function. > ARC appears to leverage knowledge of who are trusted senders > to make it easier to trace a message path. Yes. > If there's a way to know which senders are trusted, then > DMARC can already be overridden. No, for the reasons outlined above, it's not currently possible - in general - to work out whether the sender named in a particular Received: header actually handled the message. Your argument is a little like claiming that DKIM is not necessary because if you trust the domain named in the From: header and also the most recent sender then you don't need to perform your own signature validation. The need for DKIM arises specifically because this is not true, even for forwarding that does not modify messages. ARC addresses an analogous problem for forwarding which does modify messages. > Maybe I am just failing to understand, but this reads to me > like a solution to the DMARC mailing list problem that only > works if there already exists another solution to the DMARC > mailing list problem. That or it's completely unrelated to DMARC. > I'm not sure which. The fact that chain-of-custody doesn't immediately jump out at you as an extremely useful tool for receivers suggests that you've never needed to solve the problem in question. The issue then is simply that the problem is not relevant to you personally, in which case perhaps the solution isn't either. - Roland _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
