Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)
Eric Burger <eburger@standardstrack.com> Sun, 20 July 2014 18:23 UTC
Return-Path: <eburger@standardstrack.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A6B1A0537; Sun, 20 Jul 2014 11:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.887
X-Spam-Level:
X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
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 Nu3tNuqgdyLb; Sun, 20 Jul 2014 11:23:45 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F7A1B292D; Sun, 20 Jul 2014 11:23:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=+xqsbPACfye4+xWeKujoxOT/+Ye+Aw3fyj5Cg34J6eQ=; b=Y8OKRsREz8Q2iOE8SB62Db4gQZQZsl9nPw14sMMAnkGRla3UrfpqjK7Zr20XCPEtxwLNMenVdKEXslM6HwHe2ifUAJs+ghCHBebD4epi6+nq+VXJc1ZN4S1paeCOG11HZ3U813bEnquhW0aAzcJ8i6/0c3ic8M5cfxrYWL+O4iU=;
Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:62143 helo=[192.168.15.115]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from <eburger@standardstrack.com>) id 1X8vlo-000650-8W; Sun, 20 Jul 2014 11:23:41 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_2F49F9D9-A5D2-4541-AB75-379E0A49E1AA"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <20140714164212.22974.20340.idtracker@ietfa.amsl.com>
Date: Sun, 20 Jul 2014 14:23:36 -0400
Message-Id: <D1E6E3BC-EC43-4FBA-894C-5A0C8EF1705D@standardstrack.com>
References: <20140714164212.22974.20340.idtracker@ietfa.amsl.com>
To: IETF <ietf@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/pZVmrOrw6cvJVZMLq2BRmeBfL-I
Cc: dmarc WG <dmarc@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Jul 2014 18:23:46 -0000
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@ietf.org> 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@qti.qualcomm.com> > > Mailing list > Address: dmarc@ietf.org > 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 >
- Re: WG Review: Domain-based Message Authenticatio… Dave Crocker
- Re: WG Review: Domain-based Message Authenticatio… Scott Kitterman
- Re: WG Review: Domain-based Message Authenticatio… Viktor Dukhovni
- Re: WG Review: Domain-based Message Authenticatio… Douglas Otis
- Re: WG Review: Domain-based Message Authenticatio… Viktor Dukhovni
- Re: WG Review: Domain-based Message Authenticatio… Scott Kitterman
- Re: WG Review: Domain-based Message Authenticatio… Viktor Dukhovni
- not really to do with Re: WG Review: Domain-based… t.p.
- Re: not really to do with Re: WG Review: Domain-b… Viktor Dukhovni
- Re: WG Review: Domain-based Message Authenticatio… John Levine
- Re: not really to do with Re: WG Review: Domain-b… ned+ietf
- Re: not really to do with Re: WG Review: Domain-b… Dave Crocker
- Re: WG Review: Domain-based Message Authenticatio… Scott Kitterman
- RE: not really to do with Re: WG Review: Domain-b… Christian Huitema
- Re: not really to do with Re: WG Review: Domain-b… ned+ietf
- Re: WG Review: Domain-based Message Authenticatio… Murray S. Kucherawy
- Re: WG Review: Domain-based Message Authenticatio… Murray S. Kucherawy
- Re: not really to do with Re: WG Review: Domain-b… John Levine
- Re: WG Review: Domain-based Message Authenticatio… Scott Kitterman
- Re: not really to do with Re: WG Review: Domain-b… Dave Crocker
- Re: not really to do with Re: WG Review: Domain-b… Viktor Dukhovni
- Re: not really to do with Re: WG Review: Domain-b… Douglas Otis
- Re: not really to do with Re: WG Review: Domain-b… John Levine
- Re: not really to do with Re: WG Review: Domain-b… Scott Kitterman
- Re: not really to do with Re: WG Review: Domain-b… Dave Crocker
- Re: not really to do with Re: WG Review: Domain-b… Viktor Dukhovni
- Re: not really to do with Re: WG Review: Domain-b… Niels Dettenbach (Syndicat IT&Internet)
- Re: really to do with Re: WG Review: Domain-based… Alessandro Vesely
- Re: not really to do with Re: WG Review: Domain-b… Scott Kitterman
- Re: not really to do with Re: WG Review: Domain-b… t.p.
- Re: WG Review: Domain-based Message Authenticatio… Dave Crocker
- Re: not really to do with Re: WG Review: Domain-b… Hector Santos
- Re: WG Review: Domain-based Message Authenticatio… Hector Santos
- Re: WG Review: Domain-based Message Authenticatio… Pete Resnick
- Re: WG Review: Domain-based Message Authenticatio… S Moonesamy
- Re: WG Review: Domain-based Message Authenticatio… Dave Crocker
- Re: WG Review: Domain-based Message Authenticatio… S Moonesamy
- Re: WG Review: Domain-based Message Authenticatio… Dave Crocker
- Re: WG Review: Domain-based Message Authenticatio… Martin Rex
- Re: WG Review: Domain-based Message Authenticatio… Dave Crocker
- Re: WG Review: Domain-based Message Authenticatio… Martin Rex
- Re: WG Review: Domain-based Message Authenticatio… Randy Bush
- Re: WG Review: Domain-based Message Authenticatio… John Levine
- Re: WG Review: Domain-based Message Authenticatio… S Moonesamy
- Re: WG Review: Domain-based Message Authenticatio… Barry Leiba
- Re: WG Review: Domain-based Message Authenticatio… John C Klensin
- Re: WG Review: Domain-based Message Authenticatio… Dave Crocker
- Re: WG Review: Domain-based Message Authenticatio… S Moonesamy
- Re: WG Review: Domain-based Message Authenticatio… John C Klensin
- Re: WG Review: Domain-based Message Authenticatio… John C Klensin
- Re: WG Review: Domain-based Message Authenticatio… Barry Leiba
- Re: WG Review: Domain-based Message Authenticatio… John R Levine
- Re: WG Review: Domain-based Message Authenticatio… Martin Rex
- Registration policies (was: WG Review: Domain-bas… S Moonesamy
- Re: Registration policies (was: WG Review: Domain… Barry Leiba
- Re: WG Review: Domain-based Message Authenticatio… Dave Crocker
- Re: WG Review: Domain-based Message Authenticatio… Pete Resnick
- Re: WG Review: Domain-based Message Authenticatio… Murray S. Kucherawy
- Re: WG Review: Domain-based Message Authenticatio… Pete Resnick
- Re: Registration policies (was: WG Review: Domain… S Moonesamy
- Re: Registration policies (was: WG Review: Domain… Barry Leiba
- Re: Registration policies (was: WG Review: Domain… Murray S. Kucherawy
- Re: Registration policies (was: WG Review: Domain… Barry Leiba
- Re: Registration policies (was: WG Review: Domain… Murray S. Kucherawy
- [***SPAM***] Re: Registration policies (was: WG R… S Moonesamy
- Re: WG Review: Domain-based Message Authenticatio… ned+ietf
- Re: WG Review: Domain-based Message Authenticatio… Hector Santos
- Re: WG Review: Domain-based Message Authenticatio… Martin Rex
- Re: WG Review: Domain-based Message Authenticatio… Murray S. Kucherawy
- Re: WG Review: Domain-based Message Authenticatio… Stuart Barkley
- Re: WG Review: Domain-based Message Authenticatio… Randy Bush
- Re: WG Review: Domain-based Message Authenticatio… John Levine
- DMARC and ietf.org Michael Richardson
- Re: WG Review: Domain-based Message Authenticatio… Douglas Otis
- Re: WG Review: Domain-based Message Authenticatio… S Moonesamy
- Re: DMARC and ietf.org Brian E Carpenter
- Re: [***SPAM***] Re: Registration policies (was: … Barry Leiba
- Re: DMARC and ietf.org John C Klensin
- Re: DMARC and ietf.org Brian E Carpenter
- Re: DMARC and ietf.org Hector Santos
- Re: DMARC and ietf.org Miles Fidelman
- Re: WG Review: Domain-based Message Authenticatio… Eric Burger
- Re: DMARC and ietf.org Brian E Carpenter
- Re: DMARC and ietf.org Miles Fidelman
- Re: DMARC and ietf.org Pete Resnick
- Re: DMARC and ietf.org Dave Crocker
- Re: [dmarc-ietf] WG Review: Domain-based Message … Hector Santos
- Re: WG Review: Domain-based Message Authenticatio… Martin Rex
- Re: DMARC and ietf.org Martin Rex
- Re: DMARC and ietf.org John Levine
- Re: DMARC and ietf.org Hector Santos
- RE: DMARC and ietf.org MH Michael Hammer (5304)
- Re: DMARC and ietf.org Hector Santos
- RE: DMARC and ietf.org MH Michael Hammer (5304)
- Re: DMARC and ietf.org Hector Santos
- Re: DMARC and ietf.org Viktor Dukhovni
- Re: DMARC and ietf.org Hector Santos
- Re: DMARC and ietf.org John Levine
- Re: DMARC and ietf.org John Levine
- Re: DMARC and ietf.org Rich Kulawiec
- Re: DMARC and ietf.org John Levine
- Re: DMARC and ietf.org Alessandro Vesely
- Re: DMARC and ietf.org Dave Crocker
- Re: DMARC and ietf.org Brian E Carpenter
- Re: DMARC and ietf.org ned+ietf
- Re: DMARC and ietf.org Russ Housley
- Re: DMARC and ietf.org ned+ietf
- Re: DMARC and ietf.org Dave Crocker
- Re: DMARC and ietf.org Brian E Carpenter
- Re: DMARC and ietf.org Dave Crocker
- Re: DMARC and ietf.org Michael Richardson
- Re: DMARC and ietf.org Michael Richardson
- Re: DMARC and ietf.org Michael Richardson
- Re: DMARC and ietf.org Andrew G. Malis
- Re: DMARC and ietf.org Russ Housley
- Re: DMARC and ietf.org Michael Richardson
- Re: DMARC and ietf.org Brian E Carpenter
- Re: DMARC and ietf.org Brian E Carpenter
- Re: DMARC and ietf.org Dave Crocker
- Re: DMARC and ietf.org Russ Housley
- Re: DMARC and ietf.org Michael Richardson
- Re: DMARC and ietf.org John Payne
- Re: DMARC and ietf.org John Levine