On 8/18/2014 8:31 AM, Tim Draegen wrote: > If you have comments on the milestones, please provide them by August 25th. > Have fun,
Mostly small, suggested wording tweaks, to improve clarity and possibly avoid some unnecessary points of controversy. There's one (???) with a change I think is correct. If it isn't the reason needs to be made explicit. > [1] http://datatracker.ietf.org/wg/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 extend -> and extends DKIM and SPF don't do the extending. DMARC does. DKIM and SPF are merely underpinnings. > 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 internet -> Internet > email abuse, and has permitted simplifying some mail handling > processes. However, DMARC is problematic for mail that does not flow for mail that does not flow -> for indirect mail flows that are not > from operators having a relationship with the domain owner, directly directly -> and directl ('direct' vs. 'indirect' is an essential issue and the terminology needs to be established here, to make the late use clear.) > to receivers operating the destination mailbox (for example, mailing mailbox ( for mailing -> mailbox. Examples include mailing > lists, publish-to-friend functionality, mailbox forwarding via > ".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 specifications -> specifications > capabilities. It will also provide technical implementation guidance > and review possible enhancements elsewhere in the mail handling > sequence that could improve DMARC compatibility. > > The existing DMARC base specification has been submitted as an > Independent Submission to become an Informational RFC. > > Specifications produced by the working group will ensure preservation > of DMARC utility for detecting unauthorized use of domain names, hmmm. on reflection, this works better as a positve: utility for detecting authorized use of domain names Use for detecting unauthorized use is far more complicated and potentially controversial. Use for detecting authorized use is straightforward. > 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 delete [the] > 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 handling that -> handling, which (if only to reduce the number of 'that's in the sentence...) > 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 document authentication -> document additional authentication (???) > desirable. If they are 'desireable' they are not 'requirements'. If they are requirements they are not merely desirable. Perhaps: but can consider additional authentication-related issues 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 DMARC -> DMARC general Add: DMARC - https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ so there is an explicit reference to the specification. > SPF - RFC7208 > Authentication-Results Header Field - RFC7001 > DKIM - RFC6376 > Internet Message Format - RFC5322 > OAR / Original Authentication Results - > draft-kucherawy-original-authres > Using DMARC - draft-crocker-dmarc-bcp-03 > Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00 > DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03 > [2] https://www.ietf.org/mailman/listinfo/dmarc > [3] http://trac.tools.ietf.org/wg/dmarc/trac/wiki > [4] http://trac.tools.ietf.org/wg/dmarc/trac/roadmap -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
