Subject: [dmarc-ietf] Start of DMARC WG + proposed milestones

From: Tim Draegen <[email-masked]>
Date: Mon, 18 Aug 2014 11:31:49 -0400

Hello world of email,

The DMARC WG is getting started [1].  This IETF working group's goal is to address interoperability issues with indirect email flows, to document operational practices, and to mature the existing DMARC base specification.  If you would like to join please visit the DMARC WG [2].

The WG's Wiki page [3] documents the approach the WG will take to produce its deliverables.  You can find the roadmap/milestones on the site [4].  For your convenience, the proposed milestones are:

    - 91st IETF: Document describing interoperability issues with DMARC and indirect mail flows.
    - EOY 2014: Deliverable #1 (above document + possible methods to address).
    - Feb 2015: draft DMARC Usage Guide
    - 92nd IETF: Deliverable #2 - Document describing DMARC improvements to better support indirect mail flows. 
    - May 2015: Deliverable #3 - base spec changes + DMARC Usage Guide

If you have comments on the milestones, please provide them by August 25th.  Have fun,

=- Tim

[1] http://datatracker.ietf.org/wg/dmarc/charter/
[2] https://www.ietf.org/mailman/listinfo/dmarc
[3] http://trac.tools.ietf.org/wg/dmarc/trac/wiki
[4] http://trac.tools.ietf.org/wg/dmarc/trac/roadmap

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 18 Aug 2014 15:50:50 +0000

Is the DMARC Usage Guide the same as the BCP or is it a different document? If it is a different document, is the BCP going to be one of the milestones for the WG or is it off the table?

Mike

> -----Original Message-----
> From: apps-discuss [mailto:[email-masked]] On Behalf Of Tim
> Draegen
> Sent: Monday, August 18, 2014 11:32 AM
> To: Apps Discuss; [email-masked]
> Subject: [apps-discuss] Start of DMARC WG + proposed milestones
> 
> Hello world of email,
> 
> The DMARC WG is getting started [1].  This IETF working group's goal is to
> address interoperability issues with indirect email flows, to document
> operational practices, and to mature the existing DMARC base specification.
> If you would like to join please visit the DMARC WG [2].
> 
> The WG's Wiki page [3] documents the approach the WG will take to produce
> its deliverables.  You can find the roadmap/milestones on the site [4].  For
> your convenience, the proposed milestones are:
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Tim Draegen <[email-masked]>
Date: Mon, 18 Aug 2014 12:09:21 -0400

> Is the DMARC Usage Guide the same as the BCP or is it a different document? If it is a different document, is the BCP going to be one of the milestones for the WG or is it off the table?

They are one and the same.

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Aug 2014 17:15:51 -0700

Hi Tim,

The list of milestones and deliverables looks good to me. Having not
participated in an IETF working group before, I have process oriented
questions.

Am I a part of the working group by being a member of the [email-masked]
list?
How do I contribute to the working group, will the chairs ask for input at
specific times or for volunteers to write specific pieces of documents?
How does the working group decide that any given suggestion warrants
inclusion in a deliverable or a base spec change or some other action?

Thanks,
Mike

On Mon, Aug 18, 2014 at 8:31 AM, Tim Draegen <[email-masked]> wrote:

> operational practices, and to mature the existing DMARC base
> specification.  If you would like to join please visit the DMARC WG [2].
>
> its deliverables.  You can find the roadmap/milestones on the site [4].
> For your convenience, the proposed milestones are:
>

-- 
*Mike Jones, Director of Product Management*
[email-masked] <[email-masked]> l M: 703.728.3978 l www.agari.com
<http://www.google.com/url?q=http%3A%2F%2Fwww.agari.com%2F&sa=D&sntz=1&usg=AFrqEzfeN6IEWk_XTZnvAI-p7poxyjlAkQ>Changing
Email Security For Good*
<http://www.google.com/url?q=http%3A%2F%2Fwww.agari.com&sa=D&sntz=1&usg=AFrqEzd4mZ00_sT0PTWz6Ol1KrgLNpsu8w>
 *l*
<http://www.google.com/url?q=http%3A%2F%2Fwww.facebook.com%2Fpages.agari&sa=D&sntz=1&usg=AFrqEzenk5sOQNv2kVpEwPOZa1rCMY7U1w>
<http://www.google.com/url?q=http%3A%2F%2Fwww.twitter.com%2Fagariinc&sa=D&sntz=1&usg=AFrqEzcauu14S4nXj_fNJqbceMWl8MuvfA>
<http://www.google.com/url?q=http%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fagari&sa=D&sntz=1&usg=AFrqEzfp5UPxXBRo5sHX9u4uEwTalrUpEw>
<https://plus.google.com/102166045743309741150/about>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Aug 2014 08:04:15 +0200

Hi Tim,

One suggestion...

>     - EOY 2014: Deliverable #1 (above document + possible methods to address).

That seems quite short a period between adoption and approval, and I
question whether you will get sufficient review at a time when in
America there is Thanksgiving, and then in December much of the world
takes two weeks off".  I'd suggest pushing back one month.

Eliot

---

From: Ned Freed <[email-masked]>
Date: Thu, 21 Aug 2014 13:25:03 -0700 (PDT)

> Am I a part of the working group by being a member of the [email-masked]

Yes. The IETF doesn't have a concept of membership; you either
participate or you don't.

> specific times or for volunteers to write specific pieces of documents?

Both of those things will probably happen, but that's in addition to general
list discussions on current topics relevant to the goals of the group.

> inclusion in a deliverable or a base spec change or some other action?

When there's a rough consensus among the participants to do so. Usually it's
pretty obvious whether something is supported or not, but it's up to the WG
chairs to make the close calls.

				Ned

P.S. You might want to take a look at "The Tao of IETF: A Novice's Guide to the
Internet Engineering Task Force", available here:

    http://www.ietf.org/tao.html

---

From: Tim Draegen <[email-masked]>
Date: Fri, 22 Aug 2014 13:30:37 -0400

> takes two weeks off".  I'd suggest pushing back one month.

Thanks Eliot.  The order of the work is the most important thing.  When the WG gets near a milestone and its clear the WG is in the thick of it, then the milestone will be pushed back.

=- Tim

---

From: Kurt Andersen <[email-masked]>
Date: Fri, 22 Aug 2014 11:15:42 -0700

On Mon, Aug 18, 2014 at 8:31 AM, Tim Draegen <[email-masked]> wrote:

> If you have comments on the milestones, please provide them by August
> 25th.
>

Is there a planned mechanism to draft these documents prior to submitting
them as IETF artifacts? There have been various pieces of work scattered
around either this list (previously) or the blogosphere to start to
characterize deliverable #1.  Is there anything stopping us from starting
toward #1 already?

I think that this is a reasonable working plan, but agree with Eliot's
concern that the timing may need to be flexed.

(I've dropped appsdiscuss off of the distro for the reply)

--Kurt Andersen

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 23 Aug 2014 10:34:24 -0400

>>>     - EOY 2014: Deliverable #1 (above document + possible methods to address).

I did notice the absence of anything related to process.  How are we 
going to get to a "document (that) captures all known interoperability 
issue between DMARC and indirect email flows?"  If this were an RFC, 
there'd be an author or authors identified, maybe a draft to start from.

At a minimum, it seems like someone might want to generate an initial 
outline, and set it up as a wiki where folks can start providing input.

Just a thought.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 23 Aug 2014 08:28:05 -0700

On Sat, Aug 23, 2014 at 7:34 AM, Miles Fidelman <[email-masked]>
wrote:

> I did notice the absence of anything related to process.  How are we going
> to get to a "document (that) captures all known interoperability issue
> between DMARC and indirect email flows?"  If this were an RFC, there'd be
> an author or authors identified, maybe a draft to start from.
>

Since in essence we're only talking about milestones, I disagree.  I've
never seen a set of milestones on a WG charter or otherwise that name
specific people who will complete them.

For some of these there is indeed a draft to start from, named in the
charter.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 23 Aug 2014 09:30:16 -0700

On 8/23/2014 8:28 AM, Murray S. Kucherawy wrote:
> On Sat, Aug 23, 2014 at 7:34 AM, Miles Fidelman
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     going to get to a "document (that) captures all known
>     interoperability issue between DMARC and indirect email flows?"  If
>     this were an RFC, there'd be an author or authors identified, maybe
>     a draft to start from.
> 
> 

Assinging names to tasks in a charter? No, certainly not.

On the other hand, a common exercise in a wg organizing bof is to look
for a show of hands for interesting in specific topics and willingness
to work on them.

Perhaps an informal query like that, here, would be useful?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Tim Draegen <[email-masked]>
Date: Sun, 24 Aug 2014 20:36:06 -0400

> Perhaps an informal query like that, here, would be useful?

Yes, I'll post such a query once the milestone discussion is wrapped up.  Working backward from each milestone to identify topics and work items will surely reveal plenty of work to go around.

=- Tim

---

From: Tim Draegen <[email-masked]>
Date: Sun, 24 Aug 2014 20:48:21 -0400

On Aug 23, 2014, at 10:34 AM, Miles Fidelman <[email-masked]> wrote:
> I did notice the absence of anything related to process.  How are we going to get to a "document (that) captures all known interoperability issue between DMARC and indirect email flows?"  If this were an RFC, there'd be an author or authors identified, maybe a draft to start from.
> 
> At a minimum, it seems like someone might want to generate an initial outline, and set it up as a wiki where folks can start providing input.

Hi Miles, you're right.  There is very little around process today.  Once the milestones discussion has settled (as I probably too briefly mentioned to Dave Crocker in this thread), Ned and myself will create an outline of topics and work items that, when worked through, should have the WG arrive at its deliverables.

This outline should give everyone a clear picture and plenty of opportunity to volunteer.  !

=- Tim

---

From: Kurt Andersen <[email-masked]>
Date: Sun, 24 Aug 2014 19:35:58 -0700

On Aug 24, 2014 5:48 PM, "Tim Draegen" <[email-masked]> wrote:
>
>   Once the milestones discussion has settled..., Ned and myself will
create an outline of topics and work items that, when worked through,
should have the WG arrive at its deliverables.
> =- Tim

What about adopting a somewhat more agile, less waterfall strategy?

--Kurt

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 24 Aug 2014 22:30:02 -0400

> This outline should give everyone a clear picture and plenty of opportunity to volunteer.  !

Makes sense.  I always figure that milestones go hand in hand with 
approach to the work at hand.  With that caveat, milestones look good to 
me, modulo the comment about holidays.

Miles Fidelman

---

From: Dave Crocker <[email-masked]>
Date: Sun, 24 Aug 2014 19:49:57 -0700

> If you have comments on the milestones, please provide them by August 25th.  Have fun,

So, obviously I read the wrong text carefully.  Sorry.

Was so zoned into doing a series of reviews I forgot that the wg was
already chartered, and no it doesn't get changed for editing
improvements after that.

Oh boy.

d/

---

From: Jim Fenton <[email-masked]>
Date: Sun, 24 Aug 2014 21:09:19 -0700

[dropping apps-discuss from this reply]

>     - May 2015: Deliverable #3 - base spec changes + DMARC Usage Guide

With all the discussion about interoperability issues, DMARC issues,
etc. I have lost sight of what the status of the specification itself
is. Is there still intent to pursue it through the independent
submission path or is it to become a WG document? If so, I don't see it
(except possibly as "base spec changes" in Deliverable #3).

In any case, I don't see how you can write deliverable #1 without a
normative reference to the specification itself, and therefore I'm
unclear on how #1 would be published.

-Jim

---

From: Tim Draegen <[email-masked]>
Date: Mon, 25 Aug 2014 00:09:41 -0400

On Aug 24, 2014, at 10:35 PM, Kurt Andersen <[email-masked]> wrote:
> >   Once the milestones discussion has settled..., Ned and myself will create an outline of topics and work items that, when worked through, should have the WG arrive at its deliverables.
> >
> > =- Tim
> 

Kurt, although I don't see this WG as a product development exercise (where agile and its bugbear waterfall tend to live), I think you're touching on something that should be clarified.

There are a few challenges in play that will make this WG difficult: the email community is vast (because the deployment base is almost ubiquitous), email has been around for a long time (and there probably isn't an upgrade cycle), and the WG is focused on understanding and addressing DMARC's impact on indirect email flows (which means we're not likely to hear from people where impact is near zero).

Against this backdrop/problem-space, the order of the milestones is important.  Obviously, the latter milestones are informed by the earlier ones.. BUT, there's a nuance in play due to the enormity of the problem space.  The milestones will allow the WG to solicit participation from the email community for specific topics/work-items without requiring full-time participation for the next 9+ months.  This work has to remain accessible.

So, the WG will maintain an "official focus" that will track the milestones to allow for wider participation.  That said, work on items that are ahead of the official focus (or even behind if something is overlooked and important) is most definitely encouraged, because it doesn't make sense to nip constructive work in the bud just to follow process.  The only caveat I can think of is that topics/work-items will necessarily remain open until the WG officially focuses on them (again with the aim of inviting wide participation).

I hope the above is an acceptable compromise between remaining agile with respect to work items while keeping a schedule for those of that require an explicit time & place to be productive.

=- Tim

---

From: Dave Crocker <[email-masked]>
Date: Sun, 24 Aug 2014 15:37:34 -0700

> If you have comments on the milestones, please provide them by August 25th.  Have fun,

Mostly small, suggested wording tweaks, to improve clarity and possibly
avoid some unnecessary points of controversy.

There's one (???) with a change I think is correct.  If it isn't the
reason needs to be made explicit.

>  Domain-based Message Authentication, Reporting & Conformance (DMARC)
> uses existing mail authentication technologies (SPF and DKIM) to
> extend validation to the RFC5322.From field. DMARC uses DNS records

   to extend -> and extends

DKIM and SPF don't do the extending. DMARC does.  DKIM and SPF are
merely underpinnings.

> to add policy-related requests for receivers and defines a feedback
> mechanism from receivers back to domain owners. This allows a domain
> owner to advertise that mail can safely receive differential
> handling, such as rejection, when the use of the domain name in the
> From field is not authenticated. Existing deployment of DMARC has
> demonstrated utility at internet scale, in dealing with significant

   internet -> Internet

> email abuse, and has permitted simplifying some mail handling
> processes. However, DMARC is problematic for mail that does not flow

  for mail that does not flow -> for indirect mail flows that are not

> from operators having a relationship with the domain owner, directly

   directly -> and directl

('direct' vs. 'indirect' is an essential issue and the terminology needs
to be established here, to make the late use clear.)

> to receivers operating the destination mailbox (for example, mailing

   mailbox ( for mailing -> mailbox.  Examples include mailing

> lists, publish-to-friend functionality, mailbox forwarding via
> ".forward", and third-party services that send on behalf of clients).
> The working group will explore possible updates and extensions to the
> specifications in order to address limitations and/or add

   specifications -> specifications

> capabilities. It will also provide technical implementation guidance
> and review possible enhancements elsewhere in the mail handling
> sequence that could improve DMARC compatibility.
> 
> The existing DMARC base specification has been submitted as an
> Independent Submission to become an Informational RFC.
> 
> Specifications produced by the working group will ensure preservation
> of DMARC utility for detecting unauthorized use of domain names,

hmmm.  on reflection, this works better as a positve:

   utility for detecting authorized use of domain names

Use for detecting unauthorized use is far more complicated and
potentially controversial.  Use for detecting authorized use is
straightforward.

> while improving the identification of legitimate sources that do not
> currently conform to DMARC requirements. Issues based on operational
> experience and/or data aggregated from multiple sources will be given
> priority.
> 
> The working group will seek to preserve interoperability with the
> installed base of DMARC systems, and provide detailed justification
> for any non-interoperability. As the working group develops solutions
> to deal with indirect mail flows, it will seek to maintain the
> end-to-end nature of existing identifier fields in mail, in
> particular avoiding solutions that require rewriting of originator
> fields.
> 
> Working group activities will pursue three tracks:
> 
> 1. Addressing the issues with indirect mail flows
> 
> The working group will specify mechanisms for reducing or eliminating
> the DMARC's effects on indirect mail flows, including deployed

 delete [the]

> behaviors of many different intermediaries, such as mailing list
> managers, automated mailbox forwarding services, and MTAs that
> perform enhanced message handling that results in message

   handling that -> handling, which

(if only to reduce the number of 'that's in the sentence...)

> modification. Among the choices for addressing these issues are:
> 
> - A form of DKIM signature that is better able to survive transit
> through intermediaries.
> 
> - Collaborative or passive transitive mechanisms that enable an
> intermediary to participate in the trust sequence, propagating
> authentication directly or reporting its results.
> 
> - Message modification by an intermediary, to avoid authentication
> failures, such as by using specified conventions for changing
> the aligned identity.
> 
> Consideration also will be given to survivable authentication through
> sequences of multiple intermediaries.
> 
> 2. Reviewing and improving the base DMARC specification
> 
> The working group will not develop additional mail authentication
> technologies, but may document authentication requirements that are

   document authentication -> document additional authentication

(???)

> desirable.

If they are 'desireable' they are not 'requirements'.  If they are
requirements they are not merely desirable.

Perhaps:

   but can consider additional authentication-related issues that are
desirable.

> The base specification relies on the ability of an email receiver to
> determine the organizational domain responsible for sending mail. An
> organizational domain is the 'base' name that is allocated from a
> public registry; examples of registries include ".com" or ".co.uk".
> While the common practice is to use a "public suffix" list to
> determine organizational domain, it is widely recognized that this
> solution will not scale, and that the current list often is
> inaccurate. The task of defining a standard mechanism for identifying
> organizational domain is out of scope for this working group. However
> the working group can consider extending the base DMARC specification
> to accommodate such a standard, should it be developed during the
> life of this working group.
> 
> Improvements in DMARC features (identifier alignment, reporting,
> policy preferences) will be considered, such as:
> 
> - Enumeration of data elements required in "Failure" reports
> (specifically to address privacy issues)
> - Handling potential reporting abuse
> - Aggregate reporting to support additional reporting scenarios
> - Alternate reporting channels
> - Utility of arbitrary identifier alignment
> - Utility of a formalized policy exception mechanism
> 
> 3. DMARC Usage
> 
> The working group will document operational practices in terms of
> configuration, installation, monitoring, diagnosis and reporting. It
> will catalog currently prevailing guidelines as well as developing
> advice on practices that are not yet well-established but which are
> believed to be appropriate.
> 
> The group will consider separating configuration and other deployment
> information that needs to be in the base spec, from information that
> should be in a separate guide.
> 
> Among the topics anticipated to be included in the document are:
> 
> - Identifier alignment configuration options
> - Implementation decisions regarding "pct"
> - Determining effective RUA sending frequency
> - Leveraging policy caching
> - Various options for integrating within an existing flow
> - Defining a useful, common set of options for the addresses to
> which feedback reports are to be sent
> - When and how to use local policy override options
> 
> Work Items
> ----------
> 
> Phase I:
> 
> Draft description of interoperability issues for indirect mail
> flows and plausible methods for reducing them.
> 
> Phase II:
> 
> Specification of DMARC improvements to support indirect mail flows
> 
> Draft Guide on DMARC Usage
> 
> Phase III:
> 
> Review and refinement of the DMARC specification
> 
> Completion of Guide on DMARC Usage
> 
> References
> ----------
> 
> DMARC - http://dmarc.org

  DMARC ->  DMARC general

Add:

  DMARC - https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/

so there is an explicit reference to the specification.

> SPF - RFC7208
> Authentication-Results Header Field - RFC7001
> DKIM - RFC6376
> Internet Message Format - RFC5322
> OAR / Original Authentication Results -
> draft-kucherawy-original-authres
> Using DMARC - draft-crocker-dmarc-bcp-03
> Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00
> DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03

---

From: Steven M Jones <[email-masked]>
Date: Mon, 25 Aug 2014 03:18:47 -0700

I agree with most of the commentary I've seen in this thread. I just

>     - 92nd IETF: Deliverable #2 - Document describing DMARC improvements to better support indirect mail flows. 

So that's delivery of #2 during the last week of March, 2015, or about
eight months from now. And roughly three months after Deliverable #1,
including possible methods to address interop issues, is delivered.

How much "running code"[1] is Deliverable #2 supposed to reflect? Even
bearing in mind Tim's note about not being too limited by
"waterfalling," we'd want to have solidly identified the mechanisms to
be tested well before the holiday season - especially given lead times
for larger organizations/operators, where it might take three months
just to implement and package any changes.

I know this is all pretty flexible at this stage, so again I'm just
wondering if at this stage we have a notion of whether and/or how much
operational experience we expect to inform Deliverable #2?

Either way, I'm glad to see us moving forward.
--Steve.

[1]  Dr. Dave Clark, http://www.ietf.org/tao.html, etc. I always thought
it was "rough consensus and working code," glad I checked.

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 25 Aug 2014 07:52:21 -0700

On Sun, Aug 24, 2014 at 9:09 PM, Tim Draegen <[email-masked]> wrote:

> So, the WG will maintain an "official focus" that will track the
> milestones to allow for wider participation.  That said, work on items that
> are ahead of the official focus (or even behind if something is overlooked
> and important) is most definitely encouraged, because it doesn't make sense
> to nip constructive work in the bud just to follow process.  The only
> caveat I can think of is that topics/work-items will necessarily remain
> open until the WG officially focuses on them (again with the aim of
> inviting wide participation).
>
> I hope the above is an acceptable compromise between remaining agile with
> respect to work items while keeping a schedule for those of that require an
> explicit time & place to be productive.
>

That sounds reasonable to me. Thanks for the detail.

--Kurt

---

From: Pete Resnick <[email-masked]>
Date: Tue, 26 Aug 2014 17:09:18 -0700

On 8/24/14 9:09 PM, Tim Draegen wrote:

> milestones to allow for wider participation.  That said, work on items 
> that are ahead of the official focus (or even behind if something is 
> overlooked and important) is most definitely encouraged, because it 
> doesn't make sense to nip constructive work in the bud just to follow 
> process.  The only caveat I can think of is that topics/work-items 
> will necessarily remain open until the WG officially focuses on them 
> (again with the aim of inviting wide participation).

Sure, but....

When the IESG reviewed this charter, we agreed to the three different 
"phases" for a reason: Dealing with the Indirect Mail Flow issue is a 
pretty contained task. We were inclined not to have the WG start diving 
into ratholes right out of the gate. The Usage Guide is a bit more of an 
open-ended discussion than Indirect Mail Flow, and the Spec Review could 
be a *big* discussion. Having a huge thread trying to sort a really 
juicy issue for a later phase can really suck the energy out of work on 
a current topic. So we wanted to give the chairs the ability to say, 
"Thanks, that issue is definitely something we need to consider for the 
Spec Review, but let's toss that in the issue list for now and delay 
discussion of it until we're done with the current discussion." I 
definitely don't want work on future phase stuff ignored, but I also 
hope that we'll all be willing to hold off when the chairs say, "Not 
right now."

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478