[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 <[email protected]> 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 <[email protected]> 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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
