Re: [dmarc-ietf] Charter improvements
"J. Trent Adams" <jtrentadams@gmail.com> Tue, 16 July 2013 15:39 UTC
Return-Path: <jtrentadams@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9B111E80F0 for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2013 08:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G4b43FN2mYI for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2013 08:39:24 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E019F11E80D5 for <dmarc@ietf.org>; Tue, 16 Jul 2013 08:39:23 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id qd12so1915166ieb.2 for <dmarc@ietf.org>; Tue, 16 Jul 2013 08:39:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Gdxg/6wQUGj8Vvi1SflpEW71EZMYbiE05u13vQVqjZQ=; b=gRYrC6Cvp8QEQjvTehTYDK4vMe4CtKdr9pRsdftPOSyQKKBUJiEyqOwQ3DXMONrAU3 aSkGkeeO4cF7YnOmVoOXHKoQuV/uWlM9/GUuDFdIK4apVZY7JrxI8jk4K7wU3xYtANR7 GWH/457Rcl18qyKqTDudBi7BwNNre8WKsEpW3ewJu5yzxByLNXJuFfBh78K0TXfXjmfL ULJyaVD3X2IrOXPJABwZh9uc1tDfCj/cipIQ4AoDvhD6mgmzfIvtjW10Al4B36ztXgGV IkvseHQkc6PuL0x3TdAp+IJu9Q1/qJSI8JfzefQvj54mHQPLvEd7RnTIAEXlF05wYMLZ OkZQ==
X-Received: by 10.42.109.15 with SMTP id j15mr1302961icp.116.1373989161978; Tue, 16 Jul 2013 08:39:21 -0700 (PDT)
Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id y9sm25114028iga.9.2013.07.16.08.39.21 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 08:39:21 -0700 (PDT)
Message-ID: <51E56928.4020207@gmail.com>
Date: Tue, 16 Jul 2013 09:39:20 -0600
From: "J. Trent Adams" <jtrentadams@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "dmarc@ietf.org" <dmarc@ietf.org>
References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net>
In-Reply-To: <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [dmarc-ietf] Charter improvements
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmarc>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 15:39:28 -0000
Thanks, everyone, for their input on this thread (and to John for the pointer how to get back to land when I blundered into the wrong stream). Editing the proposed charter is a lot easier with this feedback. >From what I can tell, the most important question needing to be answered is whether or not revising the base DMARC specification is within scope of the proposed work group. Following Russ's guidance, it seems that we should start from the assumption that it's not in scope for now given the fact that it's being sponsored by an AD as an Individual Submission. Regardless of whether that's the right path, or not, let's explore it as an option and see how the rest of the items identified in the proposed charter play out. Then we can leverage the outcome of the conversation to potentially revisit the fate of the base specification itself. Given that guidance, here're the most obvious (and noncontroversial?) items needing to be done to shore up the proposed charter: * Correct the text regarding the current path of the specification. * Tone down the "marketing puffery". * Clarify how to address "backward compatibility" with the installed base. I've already updated the description of the current path of the base specification from "Independent Submission" to "Individual Submission", so that's one down. I'll pull out my red pen on the other two topics and see if I can make them more reasonable. Skipping ahead. . . here're the items that have previously been proposed as worth exploring in the setting of an IETF work group: ----- * a mechanism for determining the organizational domain name based on an arbitrary fully-qualified hostname ----- If I'm not mistaken, the Apps Area WG has already expressed an interest in this work. In that case, I believe that this WG would only need to track that effort and ensure that its work addresses the use cases required to support DMARC. QUESTION: Given that it's an important topic, and there's no guarantee that the other effort will result in an applicable solution, would it still be reasonable to include a mention of this as worth exploration? If so, it'd probably make sense to reference the other work as a starting point to clarify we're not planning to spin up a competing solution. ----- * a mechanism for detecting abuse involving the <display-name> portion of the RFC5322.From field ----- This is an interesting item in that there have been some proposals from contributors to the base DMARC specification to address this. The proposals, as you can see, didn't make it through to a consensus and it was suggested that they be brought to the broader community for consideration. It's highly likely that through the WG process we're able to identify a means by which this issue can be addressed. QUESTION: Does it make sense for this proposed WG to explore how the base specification can be extended to apply the same level of "identifier alignment" to the <display-name> as is helping defend the <address-spec>? ----- * a mechanism for mitigating the effect of failures of DMARC policy when a message transits a mailing list ----- I recognize that there's definitely a counter-pressure against including this topic as it seems to be a potentially quixotic quest. That being said, even if we don't find the perfect solution, it does seem reasonable to believe there is a way to provide something more than nothing that does help in some meaningful way. I'm not presupposing a solution, just that there have been a few possible options discussed at the edges which are likely to be worth more rigorous exploration. QUESTION: Is there value in a WG such as this exploring possible solutions to this issue and developing guidance that would potentially help improve the utility of the base DMARC specification? ----- * support for the notion of transitive trust (i.e., "host X trusted the sender of this message, and I trust X, so you should too") ----- I see this as similar to the above, but potentially more broadly applicable. One tweak I'd offer would be to replace ", so you should too" with something like ", so you could choose to as well". QUESTION: Is there value in a WG such as this exploring possible solutions to this issue and developing guidance that would potentially help improve the utility of the base DMARC specification? ----- * more robust transport of reports ----- After over a year of deployment, and the rise in support services handling reports, many folks have suggested that it would be worth exploring how to offer additional optional means of transport for reports. The base DMARC specification provides for this, but it is an area that was left to be extended by a group such as this. QUESTION: Is this an area of exploration that is of enough interest to include in the charter for this proposed work group? Beyond those, the topics in the proposed "Using DMARC" document have already proven useful in clarifying some options that aren't typically included in a base specification. For example, here a few items that may benefit from being specifically called out in the charter as worth exploring: * 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 RUA reporting options * When and how to use local policy override options QUESTION: Do any items on this list seem to be worth specifically adding to the proposed charter as examples of the type of work that would be useful? Finally, this list of potential work items was developed a while ago, and it's likely additional possible areas of exploration have surfaced since then. Are there any other substantive items that would be worth adding to the list? Keeping in mind, of course, that our first cut will be to assume that the base specification isn't in scope for now. Once the dust settles a bit around these items, I'll take another whack at the charter text to at least get it stable for now. Then we can bubble up the bigger question and see if we can tackle that given the input I've seen recently on other threads. Thanks again, Trent On 7/2/13 10:50 PM, Matt Simerson wrote: > On Jul 2, 2013, at 2:29 PM, "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl> wrote: > >>> In view of the large base of running DMARC >>> code, the group will avoid changes that would cause incompatible >>> changes to bits on the wire. >> -1 >> >> Granted, the installed base is large, but let's not ignore the other 40 percent of the Internet. IETF standards are standards for the _entire_ Internet community, not just ten or twenty of the largest companies in a specific area. The WG should not be bound by 'bits on the wire' in their review and possible comments on the standard. Otherwise the IETF is to a large extent degraded to the 'rubber stamp business' Scott mentioned. >> >> Don't get me wrong: the outcome of the discussions may well be that nothing will change on the wire and that'd be fine. But including this in the Charter as a precondition for the work to be done is wrong in my opinion. > +1 to Rolf's -1. > > I'm happy to see DMARC moving towards becoming a standard. Validation of incoming messages is a great feature. Reporting is more timely and structured than bounce messages. But for the vast majority of mail senders, DMARC is close to useless because of the forwarder / mailing list issue. > > "DMARC policies are not appropriate for domains with users who send mail through mailing lists" --John R Levine > > "SMTP refusal to an unmapped-but-reliable forwarder is likely to cause list unsubscription." --Roland Turner > > The mailing list issue is intractable and also a huge implementation barrier that is barely documented. For legit domain owners (ie, not abusers) that wish to use DMARC to curtail phishing from their domains, they will need to choose between losing legit mail (DMARC + mailing lists) or not losing legit mail (no DMARC). > > Most of the broader internet community does not have the resources to "map the exit IP addresses of well-behaved forwarders and ignore DMARC results for messages that come from those addresses." As such, many domain owners will deploy DMARC, lose valid mail, and then reject the technology. > > While it may be kinda sorta true that DMARC "protects 60% of global consumer mailboxes," it seems to be marketing puffery. While 60% of global mailboxes may have some form of DMARC validation, the number of legit domains that do and potentially *can* deploy DMARC records is absurdly low. > > Other minor Issues such as report loops (DMARC reporters reporting each others DMARC reports to each other ad infinitum) are minor and have simple (but not yet documented) workarounds but could also be addressed technically, rather than requiring workaround documentation. > > Matt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Dave Crocker
- [dmarc-ietf] DMARC BoF at IETF 87, Berlin Barry Leiba
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Russ Housley
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin J. Trent Adams
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin John Levine
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Dave Crocker
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Russ Housley
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Scott Kitterman
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Barry Leiba
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Franck Martin
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Scott Kitterman
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin John Levine
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Scott Kitterman
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Franck Martin
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin John Levine
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Franck Martin
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin John R Levine
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Dave Crocker
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin John Levine
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Dave Crocker
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin John R Levine
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Scott Kitterman
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Dave Crocker
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Dave Crocker
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin John R Levine
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Scott Kitterman
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Scott Kitterman
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Dave Crocker
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Scott Kitterman
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Dave Crocker
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Dave Crocker
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Scott Kitterman
- Re: [dmarc-ietf] Charter improvements John Levine
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Murray S. Kucherawy
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Scott Kitterman
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Dave Crocker
- Re: [dmarc-ietf] Charter improvements Dave Crocker
- Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Barry Leiba
- Re: [dmarc-ietf] Charter improvements John Levine
- Re: [dmarc-ietf] Charter improvements Dave Crocker
- Re: [dmarc-ietf] Charter improvements John Levine
- Re: [dmarc-ietf] Charter improvements Dave Crocker
- Re: [dmarc-ietf] Charter improvements Rolf E. Sonneveld
- Re: [dmarc-ietf] Charter improvements Dave Crocker
- Re: [dmarc-ietf] Charter improvements Matt Simerson
- Re: [dmarc-ietf] Charter improvements SM
- Re: [dmarc-ietf] Charter improvements J. Trent Adams
- Re: [dmarc-ietf] Charter improvements Dave Crocker
- Re: [dmarc-ietf] Charter improvements MH Michael Hammer (5304)
- Re: [dmarc-ietf] Charter improvements Scott Kitterman
- Re: [dmarc-ietf] Charter improvements Kurt Andersen
- Re: [dmarc-ietf] Charter improvements Kelley, John
- Re: [dmarc-ietf] Charter improvements Dave Crocker
- Re: [dmarc-ietf] Charter improvements Mike Jones
- Re: [dmarc-ietf] Charter improvements Franck Martin
- Re: [dmarc-ietf] Charter improvements Barry Leiba
- Re: [dmarc-ietf] Charter improvements Dave Crocker
- Re: [dmarc-ietf] Charter improvements Roland Turner
- Re: [dmarc-ietf] Charter improvements Dave Crocker
- Re: [dmarc-ietf] Charter improvements Murray S. Kucherawy
- Re: [dmarc-ietf] Charter improvements Murray S. Kucherawy
- Re: [dmarc-ietf] Charter improvements Dave Crocker
- Re: [dmarc-ietf] Charter improvements Murray S. Kucherawy
- Re: [dmarc-ietf] Charter improvements Greg Colburn