Re: [dmarc-ietf] Charter improvements

["MH Michael Hammer (5304)" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of J. Trent Adams
> Sent: Tuesday, July 16, 2013 11:39 AM
> To: [e-mail]
> Subject: Re: [dmarc-ietf] Charter improvements
> 
> 
> 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.
> 

+1

> 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.
> 
These items make sense to me. +1

> 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.
> 
> 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 personally think this is beyond the scope of the proposed working group even though the issue impacts DMARC. I suppose a mention might make sense but only in the sense of recognizing reality.

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

I think this is beyond the scope of the working group and probably stands on its own as a candidate for a separate working group. This is a much more intractable problem in that the display-name is free form.

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

I don't mind this topic being included but I'm not optimistic that a reasonable solution can be found other than "Dr., it hurts when I do that. Dr: Then don't do that!".

> -----
> * 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")
> -----
> 

Definitely have an issue with this approach. It would significantly and negatively impact DMARC and almost introduce opportunities for abuse.

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

Definitely worth exploring.

> 
> QUESTION: Is this an area of exploration that is of enough interest to include
> in the charter for this proposed work group?
> 
> 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 for 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
> 
> 

Mike