On Monday, June 02, 2014 13:10:04 Brandon Long wrote: > On Mon, Jun 2, 2014 at 1:00 PM, Scott Kitterman <[email protected]> > > wrote: > > 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? > > What does "trust" mean there? > > Here's an example we ran into. We had an open-posting (anyone can post) > mailing list on a "trusted" domain, but there was no way for gmail to know > the mailing list was open posting, and it didn't enforce DMARC. > > The "reputation" of the mailing list was stellar, 99%+.. but a spear > phishing attack was made through the mailing list. > > So, as I said, if "trust" means "enforces DMARC", then yes, OAR is > unnecessary. But, that is a level that I don't expect many MLM services to > do. If ietf.org doesn't enforce DMARC, then "trusting" its mailing lists > for DMARC enforcement makes no sense. OTOH, I can potentially imagine many > MLM services at least upgrading to doing spf/dkim auth and signing their > messages. I can then see from the receivers end, that this service signs > 99+% of its mail and adds an OAR header, then its easy for me to manage a > reputation for their service and whitelist that service or mailing list. > Even then, we would still be at the mercy if the service was compromised > or a hole was found where by a third party was able to send mail through > their servers and have it signed, but that issue is less likely or at > least, there's only so much that blanket protections can do against that > level of motivated attacker.
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. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
