Re: [apps-discuss] Start of DMARC WG + proposed milestones
Dave Crocker <dhc@dcrocker.net> Sun, 24 August 2014 22:40 UTC
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E0C1A8862; Sun, 24 Aug 2014 15:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8Uia8QzsZlh; Sun, 24 Aug 2014 15:40:19 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016611A885E; Sun, 24 Aug 2014 15:40:19 -0700 (PDT)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7OMeC0s031556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Aug 2014 15:40:16 -0700
Message-ID: <53FA692E.1040503@dcrocker.net>
Date: Sun, 24 Aug 2014 15:37:34 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Tim Draegen <tim@eudaemon.net>, Apps Discuss <apps-discuss@ietf.org>, dmarc@ietf.org
References: <AF8C9965-2351-496C-9A11-71B3B0C9B8A6@eudaemon.net>
In-Reply-To: <AF8C9965-2351-496C-9A11-71B3B0C9B8A6@eudaemon.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 24 Aug 2014 15:40:16 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qcgylcYggi9nEXXYoHpa5D_dBk4
Subject: Re: [apps-discuss] Start of DMARC WG + proposed milestones
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Aug 2014 22:40:21 -0000
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
- [apps-discuss] Start of DMARC WG + proposed miles… Tim Draegen
- Re: [apps-discuss] Start of DMARC WG + proposed m… Tim Draegen
- Re: [apps-discuss] Start of DMARC WG + proposed m… MH Michael Hammer (5304)
- Re: [apps-discuss] Start of DMARC WG + proposed m… Mike Jones
- Re: [apps-discuss] Start of DMARC WG + proposed m… Ned Freed
- Re: [apps-discuss] Start of DMARC WG + proposed m… Dave Crocker