Dear Brandon, See comments inline: On Jun 2, 2014, at 1:10 PM, Brandon Long <[email protected]> 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. More than a decade ago, we managed a zone dedicated to mailing-list subscription policy compliance to confirm the mailing-list's practices. Back then, the test was to ensure confirmed subscriptions. Of course, doing so remains important. Authorizing only validated domains still leaves a few things to still check regarding posts. 1) enforcing DMARC policy alignment request (not a problem when mailing-list friendly i.e. TPA-Label) 2) protect use of List-ID or Sender header and stipulate inclusion in authorization 3) use X-original-authentication-results and stipulate inclusion in authorization (missing but can be added) It would be easy to add any number of these stipulations for receivers to check before applying the authorization. Also consider the TPA-Label method can disable a domain in minutes following any detected or reported abuse. No one wants to see their services disrupted which helps ensure compliance. Allow others to use your lists, and this hammer gets much bigger. Unless email is only permitted to be exchanged peer-to-peer, there will always be some intermediate steps to be trusted. Take the Intuit example, where they make use of the Sender header. Regards, Douglas Otis
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
