On Monday, June 02, 2014 15:31:36 Brandon Long wrote: > On Mon, Jun 2, 2014 at 1:36 PM, Scott Kitterman <[email protected]> > > wrote: > > Trust in this context means "trust not to lie on the OAR". Either you > > trust > > them not to lie (and the content can be used) or you don't and it can't be > > used. If you've evaluated them sufficiently to conclude they won't lie on > > the > > OAR, you already know enough to just whitelist them. > > I would argue they aren't the same. > > Trusting that they aren't lying on the OAR just means that I can implement > policy about the value of the OAR. > > That doesn't mean that we agree on what policy we should implement in > regards to authentication-results. > > An MLM could implement OAR but not enforce DMARC, for example. In that > case, a DMARC enforcing receiver could reject the message for DMARC if it > fails, but not reject messages that passed auth for the mailing list. > > One could imagine using it for other things as well, the spam filtering for > a mailing list may not be particularly strong, but with OAR, we could apply > different rules based on authentication. One could imagine trusting > "authenticated sender in address book" more than "unauthenticated sender in > address book", for example.
Even if I grant you that (and I'm not sure I do), I also don't know why OAR is better than AR. In order to ensure OAR was added by the ML (or whoever you trust to add it correctly) you're going to have to grovel through the received fields and see if the MTA you trust added the field. Once you've done that, you might as well just use AR. Calling it OAR adds nothing beyond forcing us to re-invent the wheel. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
