[dmarc-ietf] ***SPAM*** 7.348 (5) Re: Re: Draft DMARC working group charter

[Jim Fenton <[e-mail]>]

[removed the SPAM tag from subject]

On 06/22/2014 10:44 PM, Barry Leiba wrote:
> I'd like to steer the discussion on this list for now:
> Dave posted the following message to the list on Friday.
> Unfortunately, the list seems to have marked it as spam, and it's not
> in the archive.  I hope this copy will get into the archive, and to
> everyone's mailbox.
>
> And so:
> Let's please stop all the other discussions for now, and say that the
> purpose of the <[e-mail]> mailing list is, for now, to discuss
> the charter proposal and converge on a charter for a working group.
>
> Please have at it.  (And please remove me from the CC list when you
> reply to this; I subscribe to the list from another email address, and
> don't want a separate copy.)
>
> Barry, Applications AD
>
>
> On Fri, Jun 20, 2014 at 3:38 PM, Dave Crocker <[e-mail]> wrote:
> Folks,
>
> Here is some draft text to consider for a DMARC working group charter:
>
> Working group name: dmarc
> Chair(s):
> Area and Area Director(s):
> Responsible Area Director:
> Mailing list: https://www.ietf.org/mailman/listinfo/dmarc
>
> Description of working group
> ----------------------------
>
> Domain-based Message Authentication, Reporting & Conformance (DMARC)
> extends stable, domain-level validation to the RFC5322.From field. DMARC
> builds upon existing mail authentication technologies (SPF and DKIM),
> using DNS records to add policy-related requests for receivers and
> defining a feedback mechanism from receivers back to domain owners. This
> can allow a domain owner to advertise that mail, which does not
> authenticate use of the domain name in the From field, can safely
> receive differential handling, such as rejection. Existing deployment of
> DMARC has demonstrated utility at internet scale, in dealing with
> significant email abuse, and has permitted simplifying some mail
> handling processes. However, DMARC is problematic for mail that does not
> flow from operators having a relationship with the domain owner,
> directly to receivers operating the destination mailbox. Examples of
> such "indirect" flows are mailing lists, publish-to-friend
> functionality, mailbox forwarding (".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 capabilities. It will also provide technical
> implementation guidance and review possible enhancements elsewhere in
> the mail handling sequence that could improve could DMARC compatibility.
>
> The existing base specification is being submitted as an Independent
> Submission to become an Informational RFC.

I'm not sure if this belongs in the charter, but in any case I wonder if
it creates market confusion to pursue both an Informational Independent
Submission and a Standards-track working group RFC. Are there other
examples of where that has been done? As a counter-example, note that
the publication of DomainKeys (RFC 4870) was delayed until DKIM
published to avoid confusion, and there the names were somewhat different.

>
> 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 basic domain name obtained through a public
> registry, such as example.com or example.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.

I don't see how this can be considered out of scope without a viable
alternative. The identification of the Administrative Domain is a
normative requirement in DMARC, and if this problem is not solved, the
specification will be stuck. Having tried and failed to solve this
problem several years ago, I am convinced that this is a very difficult
problem.

>
> Goals and milestones
> --------------------
>
> Phase I:
>
>    Draft description of interoperability issues and plausible methods
> for eliminating or reducing them.  This will not include final choices.
>
>    Draft Guide on DMARC Usage
>
>
> Phase II:
>
>    Specification of DMARC improvements to support better
>    interoperability
>
>    Review and refinement of the DMARC specification

Does this include the publication of a standards-track specification?

>
> Phase III:
>
>    Completion of Guide on DMARC Usage
>
>
> References
> ----------
>    DMARC - http://dmarc.org
>    SPF - RFC7208
>    DKIM - RFC6376
>    Internet Message Format - RFC5322
>    OAR / Original Authentication Results - draft-kucherawy-original-authres
>    Using DMARC -  draft-crocker-dmarc-bcp-03

Overall, this seems like a very long and complex charter, although I'm
sure someone will find one even longer and more complex.

-Jim