Re: [dmarc-ietf] Charter improvements

[Mike Jones <[e-mail]>]

On Jul 16, 2013, at 8:39 AM, J. Trent Adams <[e-mail]> wrote:

> 
> Thanks, everyone, for their input on this thread (and to John for the
> pointer how to get back to land when I blundered into the wrong stream).
> Editing the proposed charter is a lot easier with this feedback.
> 
> From what I can tell, the most important question needing to be answered
> is whether or not revising the base DMARC specification is within scope
> of the proposed work group. Following Russ's guidance, it seems that we
> should start from the assumption that it's not in scope for now given
> the fact that it's being sponsored by an AD as an Individual Submission.
> 
> Regardless of whether that's the right path, or not, let's explore it as
> an option and see how the rest of the items identified in the proposed
> charter play out. Then we can leverage the outcome of the conversation
> to potentially revisit the fate of the base specification itself.
> 
> Given that guidance, here're the most obvious (and noncontroversial?)
> items needing to be done to shore up the proposed charter:
> 
> * Correct the text regarding the current path of the specification.
> * Tone down the "marketing puffery".
> * Clarify how to address "backward compatibility" with the installed base.
> 
> I've already updated the description of the current path of the base
> specification from "Independent Submission" to "Individual Submission",
> so that's one down. I'll pull out my red pen on the other two topics and
> see if I can make them more reasonable.

+1 

> 
> Skipping ahead. . . here're the items that have previously been proposed
> as worth exploring in the setting of an IETF work group:
> 
> -----
> * a mechanism for determining the organizational domain name based on an
> arbitrary fully-qualified hostname
> -----
> 
> If I'm not mistaken, the Apps Area WG has already expressed an interest
> in this work. In that case, I believe that this WG would only need to
> track that effort and ensure that its work addresses the use cases
> required to support DMARC.
> 
> QUESTION: Given that it's an important topic, and there's no guarantee
> that the other effort will result in an applicable solution, would it
> still be reasonable to include a mention of this as worth exploration?
> If so, it'd probably make sense to reference the other work as a
> starting point to clarify we're not planning to spin up a competing
> solution.

I think if it is expected to be addressed by another WG then only a reference to that work is appropriate.  I think even a mention of exploring it in this DMARC WG would be overreaching.

> 
> -----
> * a mechanism for detecting abuse involving the <display-name> portion
> of the RFC5322.From field
> -----
> 
> This is an interesting item in that there have been some proposals from
> contributors to the base DMARC specification to address this. The
> proposals, as you can see, didn't make it through to a consensus and it
> was suggested that they be brought to the broader community for
> consideration. It's highly likely that through the WG process we're able
> to identify a means by which this issue can be addressed.
> 
> QUESTION: Does it make sense for this proposed WG to explore how the
> base specification can be extended to apply the same level of
> "identifier alignment" to the <display-name> as is helping defend the
> <address-spec>?
> 

Yes, this would be a worthwhile discussion for a DMARC WG.  Maybe it is unlikely that a means to address this is identified as an extension to DMARC, but it's a real problem and worth the effort to discuss.


> -----
> * a mechanism for mitigating the effect of failures of DMARC policy when
> a message transits a mailing list
> -----
> 
> I recognize that there's definitely a counter-pressure against including
> this topic as it seems to be a potentially quixotic quest. That being
> said, even if we don't find the perfect solution, it does seem
> reasonable to believe there is a way to provide something more than
> nothing that does help in some meaningful way. I'm not presupposing a
> solution, just that there have been a few possible options discussed at
> the edges which are likely to be worth more rigorous exploration.
> 
> QUESTION: Is there value in a WG such as this exploring possible
> solutions to this issue and developing guidance that would potentially
> help improve the utility of the base DMARC specification?
> 

Yes, I believe so.


> -----
> * support for the notion of transitive trust (i.e., "host X trusted the
> sender of this message, and I trust X, so you should too")
> -----
> 
> I see this as similar to the above, but potentially more broadly
> applicable. One tweak I'd offer would be to replace ", so you should
> too" with something like ", so you could choose to as well".
> 
> QUESTION: Is there value in a WG such as this exploring possible
> solutions to this issue and developing guidance that would potentially
> help improve the utility of the base DMARC specification?

This one is a maybe for me.  I could see value in the discussion, but think it is far less likely a WG reaches any consensus on this than on the previous two items. 


> 
> -----
> * more robust transport of reports
> -----
> 
> After over a year of deployment, and the rise in support services
> handling reports, many folks have suggested that it would be worth
> exploring how to offer additional optional means of transport for
> reports. The base DMARC specification provides for this, but it is an
> area that was left to be extended by a group such as this.
> 
> QUESTION: Is this an area of exploration that is of enough interest to
> include in the charter for this proposed work group?

Yes. 


> 
> Beyond those, the topics in the proposed "Using DMARC" document have
> already proven useful in clarifying some options that aren't typically
> included in a base specification. For example, here a few items that may
> benefit from being specifically called out in the charter as worth
> exploring:
> 
> * 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 RUA reporting options
> * When and how to use local policy override options
> 
> QUESTION: Do any items on this list seem to be worth specifically adding
> to the proposed charter as examples of the type of work that would be
> useful?
> 

Yes to all of the items on the list from the "Using DMARC" document.


> Finally, this list of potential work items was developed a while ago,
> and it's likely additional possible areas of exploration have surfaced
> since then. Are there any other substantive items that would be worth
> adding to the list? Keeping in mind, of course, that our first cut will
> be to assume that the base specification isn't in scope for now.
> 
> Once the dust settles a bit around these items, I'll take another whack
> at the charter text to at least get it stable for now. Then we can
> bubble up the bigger question and see if we can tackle that given the
> input I've seen recently on other threads.
> 
> Thanks again,
> Trent
> 


Thanks, 

Mike Jones
Agari
[e-mail]