I would like to see a better integrated, cross-area engineering effort. There is much to do in the integrated area of new domain authorization "permission-based" policy concepts. We have a tendency of repeating the similar concepts across proposed multiple protocols. In an evolved, modern SMTP receiver, it could perform 3-6 or more DNS redundant lookups for each transaction, and they are not flexible enough to be lumped together. -- Hector Santos http://www.santronics.com > On Jul 20, 2014, at 2:23 PM, Eric Burger <eburger@xxxxxxxxxxxxxxxxxx> wrote: > > 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 > > _______________________________________________ > dmarc mailing list > dmarc@xxxxxxxx > https://www.ietf.org/mailman/listinfo/dmarc