On Monday, June 02, 2014 12:43:48 Brandon Long wrote: > On Fri, May 30, 2014 at 8:10 PM, John Levine <[email protected]> wrote: > > >1) Support Original-Authentication-Results. This requires the MLM to add > > >them in the first place, and for the DMARC enforcing domains to check > > > > them. > > > > > Has an open question of how best to "trust" the OAR header on a message. > > > Options there are explicit whitelists from the sending domains > > > > (tpa-labels > > > > >or whatever) or to leave it up to the individual receiving domain. > > > > This keeps reducing to the previous case. If you know what senders > > you trust, why do you need the OAR header? > > OAR and the signed mailing list means that I trust the mailing list to have > properly checked the original validation. > > The mailing list didn't reject the DMARC message because it was valid, but > its modifying the message, so no one downstream knows that it was fine. > Or, it may not enforce DMARC at all. > > OAR allows the MLM to tell everyone else what the auth state was prior to > munging. The MLM may choose to forward the message regardless of the auth > state, but receivers downstream can then enforce. > > The OAR isn't necessary for a DMARC "compliant" MLM which would know to > make sure the message passed DMARC as sent by following one of the > mitigation strategies (don't munge the message, munge the from, embed the > message as an attachment, etc). It seems necessary for any whitelisting > scheme, however, otherwise an "anyone can post" mailing list on a host > which doesn't enforce DMARC is a wide-open hole.
If I already know to trust the mailing list, what does OAR cause me to do differently? Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
