Re: [dmarc-ietf] Charter improvements

["Murray S. Kucherawy" <[e-mail]>]

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

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

Yes, yes, and yes.


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

<hat type="dmarc-participant">
That sounds right to me.
</hat>

<hat type="appsawg-co-chair">
My recollection is that there have been arguments made that the right place
to develop a solution to this problem is APPSAWG, but not that a decision
has been made that that's going to be the venue.  I've no objection, but I
don't recall a decision.

There are two proposals available as I-Ds that we can discuss someplace:
draft-levine-orgboundary and draft-sullivan-domain-policy-authority.
There's time on the APPAREA agenda right now if John and Andrew (or their
delegates) would like to lead a discussion about it.
</hat>


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

The charter should say that the topic is out of scope, as we expect it will
be handled by another working group in parallel to our work.  If no working
group (extant or new) does pick it up, we can negotiate to recharter and
deal with it ourselves.


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

With the understanding that a working group can always decide not to tackle
an issue it's chartered to tackle because it decides the problem is
intractable, I think we should include it.  The ADs can encourage the
chairs to shut down a topic that it seems has no real solution sooner
rather than later.


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

Same answer as above.


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

Same answer as above.


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

Same answer as above.


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

Given the path for dmarc-base on the table, I suggest these be omitted and
saved for some future dmarc-bis effort, except where operational advice can
be developed and included in the "using" document.

-MSK