Re: [dmarc-ietf] Charter improvements

[Greg Colburn <[e-mail]>]

Apologies for my tardiness to the conversation.  Comments below.

Greg Colburn


On 7/16/13 9: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.

While the work required for this task is out of scope, it could
significantly impact DMARC.  This WG should probably track the effort as
closely as possible.

>
>-----
>* 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>?

+1, we probably cannot solve it 100%, however, this WG seems like a
potential place to establish a wider effort.

>
>-----
>* 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?


+1, as we're heard through dmarc-discuss (and others) this is an issue
important to the community.  There is work to do here.


>
>-----
>* 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?

+1

>
>-----
>* 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?

+1, as a large report parser, I'd love to +10 this one.  Absolutely things
to discuss here.

>
>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?

+1.  Using DMARC laid out a number of items to discuss further.

>
>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
>
>--
>J. Trent Adams
>
>Profile: http://www.mediaslate.org/jtrentadams/
>LinkedIN: http://www.linkedin.com/in/jtrentadams
>Twitter: http://twitter.com/jtrentadams
>
>_______________________________________________
>dmarc mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dmarc