On 05/12/2016 01:47 PM, Stephen J. Turnbull wrote:
I believe this thread has moved to "dmarc", so "arc-discuss" has been removed.
Thanks. It appears that I was not on dmarc (now corrected), so had missed quite a bit of the discussion.
Roland Turner writes: > > (as mentioned below under "authenticated identity"). The biggest > > problem with that, is whether anyone should trust such purported > > authentication claims. > > Sure, but that's _*exactly*_ the same problem as trusting ARC > forwarders' claims in the first place. In a particular formal sense, perhaps. But an ARC assertion is an assertion that certain data have been *validated*. An originator assertion is an assertion that certain data is *authentic*. The assertions are different in *kind*, and therefore the trust decision is a different problem (requires different data and balances different risks). ARC doesn't help with authenticity, as you yourself have been at pains to explain. Trying to stretch it to do so is a bad idea (at least from the point of view of mailing list owners).
Thanks for persisting on this. Per my earlier email to Murray, I now agree with you. The sensible thing to do would appear to be to register a new 7601.Method to describe situations where a 5598.Originator wishes to explicitly assert that they're acting on behalf of an Author from a different ADMD whom they've previously authenticated by some other means.
> Failure to support independent origination explicitly (I've > suggested cv=I to the same end previously) invites ad hoc > arrangements, That may be true, but IMO it's out of scope for ARC. It should be done in DKIM or DMARC. ARC currently is very easy to interpret: a third party asserts that it validated some data provided by an earlier party in the chain (possibly but not always the originator). Let's not muddy it with assertions that belong to an originator protocol.
I'd suggest that the areas of concern (webmail providing the ability for someone to send with the From: address of their work account that they've previously demonstrated control of, [typically] small customers of ESPs who haven't got their DKIM etc. sorted out) aren't well addressed by DKIM or DMARC, but that there's also a better option than AS[0].
- Roland _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
