I wanted to add for clarity sake, as I feel a lot of people got confused, the modifications I did on mailman to work with DMARC, is a personal project, not linked to the DMARC group. This is why I post on this topic using my personal email address.
I never intended to get the DMARC spec modified, nor this is a spec proposal. I'm just saying if you look at the FAQ, there are different ways to tackle the mailing list issues. This is a possibility in one way, which does not require any modification to the DMARC spec, but to the Mailing List spec (if there is such a thing). There has been prior analysis (before DMARC and even ADSP I think): http://wiki.list.org/display/DEV/DKIM but no one to code something and test. A bit of experimentation is good, and who knows this solution could be satisfactory for enough people. There are other solutions which are also viable (see FAQ and other previous suggestions). For this solution, you know where is the test list and test code.... Also in a way there is no need to write a lot of theoretical pages about it... :P But back to DMARC work as this group is, I think, focusing on providing a public tool to solve a very specific and very problematic phishing issue, not a mailing list issue ;) Also let's be patient, level headed, focused and contributing positively... ----- Original Message ----- From: "Paul Midgen" <[email protected]> To: [email protected], "Michael Adkins" <[email protected]>, [email protected], "Alan Maitland" <[email protected]>, [email protected] Sent: Sunday, July 8, 2012 12:04:38 AM Subject: Re: [dmarc-discuss] Clarification needed; Does p=none override -all and ADSP in all cases? Speaking as DMARC's co-chair and referencing my contributions to the spec as the person formerly responsible for inbound anti-spam and email delivery at Hotmail... We designed DMARC to solve a narrow problem: for a domain owner, reduce or eliminate fraudulent/unauthorized email-based use of their domain(s). We intended DMARC as a policy layer operating "above" SPF and DKIM, and we were emphatic about baking useful reporting and deployment options into the spec. In the course of developing and testing DMARC we conducted innumerable tests and modeled DMARC's effects on a very diverse set of email streams: social networks, large mailbox providers, ESP-monitored traffic, financial services companies, and so on. The spec you see now was derived from all of this analysis and the considerable experience of many of DMARC's member organizations, so please understand that if you don't see something in the spec, it is almost certainly a deliberate omission. It also means that what IS in the spec has withstood rigorous analysis and testing. That doesn¹t mean that we aren't open to feedback; on the contrary, we put DMARC in front of the entire world to get broader deployment, testing, and feedback and created dmarc-discuss as the discussion forum for that. So, to all the "new" folks - we've heard you and we get it. There are some pretty big questions and/or things you feel aren't adequately settled in the draft. We've assigned some folks to write up the history of why those things are the way they are to provide a starting point for moving forward with re-examining some of those things and possibly modifying the spec. What I respectfully ask in return, of those who want to help make DMARC better, don't present your personal opinions as facts, and don't start conversations by talking about solutions. Start with a very clear statement of the problem you perceive and present the real-world data and/or observations that back up your position. That was the bar each and every one of us held ourselves to when drafting the spec, and it is only fair to ask that of all of you. Now: we're heads-down planning the DMARC interop event, so it may take a week or so to pull the document I mentioned together, but it will at a minimum cover the following points: 1. Why a DMARC policy should override all other policy and the role of "local policy". 2. Background on why we elected not to try and "solve" mailing lists in DMARC. 3. Why DMARC does not contain support for policy matrices. If you would like to see other topics included in that initial write-up, or feel there are other documentation/site issues that need to be addressed please send them directly to me. I will summarize that back to the list when we send the write-up(s) out. By all means continue this thread, but beyond making it painfully clear that we have some explaining to do, it really hasn't done much else in 50+ messages except get a bunch of feathers ruffled. Thanks. -p _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
