I will not comment on the 85 messages in the thread. However, I would like to point out that STIR is working on a similar problem with similar goals but in a more constrained environment. I would offer coordination between WG’s, should DMARC be chartered, would be “a good thing.” On Jul 14, 2014, at 12:42 PM, The IESG <iesg-secretary@xxxxxxxx> wrote: > A new IETF working group has been proposed in the Applications Area. The > IESG has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-24. > > Domain-based Message Authentication, Reporting & Conformance (dmarc) > ------------------------------------------------ > Current Status: Proposed WG > > Assigned Area Director: > Pete Resnick <presnick@xxxxxxxxxxxxxxxx> > > Mailing list > Address: dmarc@xxxxxxxx > To Subscribe: https://www.ietf.org/mailman/listinfo/dmarc > Archive: http://www.ietf.org/mail-archive/web/dmarc/ > > Charter: > > Domain-based Message Authentication, Reporting & Conformance (DMARC) > uses existing mail authentication technologies (SPF and DKIM) to > extend validation to the RFC5322.From field. DMARC uses DNS records > to add policy-related requests for receivers and defines a feedback > mechanism from receivers back to domain owners. This allows a domain > owner to advertise that mail can safely receive differential > handling, such as rejection, when the use of the domain name in the > From field is not authenticated. Existing deployment of DMARC has > demonstrated utility at internet scale, in dealing with significant > email abuse, and has permitted simplifying some mail handling > processes. > > The existing base specification is being submitted as an Independent > Submission to become an Informational RFC. > > 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. > > Specifications produced by the working group will ensure preservation > of DMARC utility for detecting unauthorized use of domain names, > while improving the identification of legitimate sources that do not > currently conform to DMARC requirements. Issues based on operational > experience and/or data aggregated from multiple sources will be given > priority. > > The working group will seek to preserve interoperability with the > installed base of DMARC systems, and provide detailed justification > for any non-interoperability. As the working group develops solutions > to deal with indirect mail flows, it will seek to maintain the > end-to-end nature of existing identifier fields in mail, in > particular avoiding solutions that require rewriting of originator > fields. > > > Working group activities will pursue three tracks: > > 1. Addressing the issues with indirect mail flows > > The working group will specify mechanisms for reducing or eliminating > the DMARC's effects on indirect mail flows, including deployed > behaviors of many different intermediaries, such as mailing list > managers, automated mailbox forwarding services, and MTAs that > perform enhanced message handling that results in message > modification. Among the choices for addressing these issues are: > > - A form of DKIM signature that is better able to survive transit > through intermediaries. > > - Collaborative or passive transitive mechanisms that enable an > intermediary to participate in the trust sequence, propagating > authentication directly or reporting its results. > > - Message modification by an intermediary, to avoid authentication > failures, such as by using specified conventions for changing > the aligned identity. > > Consideration also will be given to survivable authentication through > sequences of multiple intermediaries. > > > 2. Reviewing and improving the base DMARC specification > > The working group will not develop additional mail authentication > technologies, but may document authentication requirements that are > desirable. > > 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 'base' name that is allocated from a > public registry; examples of registries include ".com" or ".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. > > Improvements in DMARC features (identifier alignment, reporting, > policy preferences) will be considered, such as: > > - Enumeration of data elements required in "Failure" reports > (specifically to address privacy issues) > - Handling potential reporting abuse > - Aggregate reporting to support additional reporting scenarios > - Alternate reporting channels > - Utility of arbitrary identifier alignment > - Utility of a formalized policy exception mechanism > > > 3. DMARC Usage > > The working group will document operational practices in terms of > configuration, installation, monitoring, diagnosis and reporting. It > will catalog currently prevailing guidelines as well as developing > advice on practices that are not yet well-established but which are > believed to be appropriate. > > The group will consider separating configuration and other deployment > information that needs to be in the base spec, from information that > should be in a separate guide. > > Among the topics anticipated to be included in the document are: > > - 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 options for the addresses to > which feedback reports are to be sent > - When and how to use local policy override options > > > Work Items > ---------- > > Phase I: > > Draft description of interoperability issues for indirect mail > flows and plausible methods for reducing them. > > Phase II: > > Specification of DMARC improvements to support indirect mail flows > > Draft Guide on DMARC Usage > > Phase III: > > Review and refinement of the DMARC specification > > 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 > > > Milestones: > > TBD >
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail