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

On 07-Jul/12 10:59 PM, "[email protected]"
<[email protected]> wrote:

>Michael (and FB crew),
>
>I acknowledge that due diligence was done for the proof of concept 6
>months ago, and a more open version of due diligence is being done now
>with the draft and an open internet community.
>
>I'm an outsider so I'll ask these simple questions:
>
> -  Are 3rd parties (aka those not privy to your backdoors white board
>sessions) aware of what you have "high confidence" in, and the areas you
>seek assistance? 
>
> - Are these needs made clear in a place other than "the archives"
>
> - Is it unexpected that a  ADMDs will go through the same fear,
>uncertainty, and doubt that (according to your message) took "months" to
>hash out?  
>
>Michael, what you see as an insult is just someone who is  frustrated by
>a lack of transparency, and needs more information.   If that information
>isn't in the draft, and isn't appropriate for such a document, perhaps a
>Wiki page should be created to address these historical concerns.
>
>What are your (FB.com et al) thoughts on creating a wiki page for
>historical and upcoming edits to the draft?
>
> (note I don't want to interfere with the ietf notes well process)
> 
>
>
>Sent via BlackBerry from T-Mobile
>
>-----Original Message-----
>From: Michael Adkins <[email protected]>
>Sender: [email protected]: Sun, 8 Jul 2012 01:55:18
>To: Alan Maitland<[email protected]>;
>[email protected]<[email protected]>
>Subject: Re: [dmarc-discuss] Clarification needed;
> Does p=none override -all and ADSP in all cases?
>
>>
>>
>>
>>"We are part of bigger infrastructures than you ever will be and have
>>also thought long and hard about all this over a Kirk burger" is just
>>probably not going to provide many folks with the warm fuzzies they want
>>to have in their justifying making a choice to move forward with DMARC.
>>
>
>I feel kind of insulted by this.  There's a big difference between the
>areas of the spec that we know need broader consensus and the areas of the
>spec that we feel like we flushed out thoroughly.  Identifying whether a
>given topic falls into one of those categories or the other goes a long
>way in terms of setting expectations around how open the working group
>will be to discussing it.  We involved several very large financial
>institutions and a technical financial industry organization in our work
>to make sure their concerns were addressed.  Speculating about concerns
>they may or may not have is not a constructive use of time as we already
>devoted several months to it.
>
>If you don't see the value of large scale data and experimentation, or the
>several years we devoted to it, or more than a year's experience running
>in it production at large scale, fine.  The reporting component exists so
>that you can collect the data and make an educated decision for yourself
>as to whether you should use it or not.  If you don't actually have a
>spoofing problem, and you don't see any value in the reports, then DMARC
>has nothing to offer you.  No one is interested in trying to convince
>anyone to use DMARC who doesn't actually have the problem it tries to
>solve.  Either you justify it yourself with the data provided, or you
>don't.
>
>>
>
>
>_______________________________________________
>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)
>
>_______________________________________________
>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)



_______________________________________________
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)

Reply via email to