Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

Douglas Otis <doug.mtview@gmail.com> Sun, 13 April 2014 06:04 UTC

Return-Path: <doug.mtview@gmail.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 327981A026F for <ietf@ietfa.amsl.com>; Sat, 12 Apr 2014 23:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.5
X-Spam-Level:
X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] 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 unZqi9MX8Cx1 for <ietf@ietfa.amsl.com>; Sat, 12 Apr 2014 23:04:39 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B81E51A026D for <ietf@ietf.org>; Sat, 12 Apr 2014 23:04:39 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id kl14so7036217pab.32 for <ietf@ietf.org>; Sat, 12 Apr 2014 23:04:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=JSyTPQVyOLWQXSqQtuhgFmQfwbScbnw1gL890gpdaLY=; b=yISrA5cBhHmXZJY5hlr5/8Q8cIZGEP3WpS6GdYOH+AiQai7LyYSEpdt/HOs3g0Ooix qB7WkqkSNyWQHdRYlyElJ+4y4q+DRjUqry7lA4QzidWykMLEx5em/ODjza9AvzMZjLQ6 U+OKisIKdaokEaORgD4PDWG5WRvJE09bRO9k5/gF6TglWQ4tkFBpc+cyujTTNWLAaovT RqMq0c5gemWjuNLpxwfsLq9WEiufa7ZJdcWHswBgRHS6fbI1Z+s4HohdtyGcwJL8CTyf IX1EaL6mLUD5moAjdCSBLwNNxeAcmcA3BzSwcEmKlZoa35TFQ9Y4M5MOKAWSAvrvD2P1 7xog==
X-Received: by 10.68.202.8 with SMTP id ke8mr37303228pbc.86.1397369077345; Sat, 12 Apr 2014 23:04:37 -0700 (PDT)
Received: from [192.168.2.114] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id id10sm25700547pbc.35.2014.04.12.23.04.35 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Apr 2014 23:04:36 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_94D536FC-525C-4904-83F7-1F6560FF10D7"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <5349BCDA.7080701@gmail.com>
Date: Sat, 12 Apr 2014 23:04:33 -0700
Message-Id: <4B5E63AB-0331-4155-9317-141537B87F1D@gmail.com>
References: <53499A5E.9020805@meetinghouse.net> <5349A261.9040500@dcrocker.net> <5349AE35.2000908@meetinghouse.net> <5349BCDA.7080701@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/Yzru1cogywlJmqUQfdraQ96tj3I
Cc: ietf@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, 13 Apr 2014 06:04:42 -0000

On Apr 12, 2014, at 3:23 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> Hi,
> 
> In the DMARC draft, I noticed this:
> 
>> Descriptions of the PolicyOverrideTypes:
> ...
>>   mailing_list:  Local heuristics determined that the message arrived
>>      via a mailing list, and thus authentication of the original
>>      message was not expected to succeed.
> 
> Could somebody explain what that means and whether it can be used to
> mitigate the current issue? Or are substantial changes needed
> in the fundamentals of DMARC?
> 
> I assume the authors will be adding a discussion of this issue
> to the draft.
> 
> Regards
>   Brian

Dear Brian,

There was an extension that foresaw this problem by offering a safe policy override scheme for third-party services that might result in DKIM signature failure.  DMARC often fails with messages from third-party services such as mailing-list.  Such failures normally result in these messages being placed into junk folders.  Unfortunately, too many ignore cautions about rejecting as can be demanded by DMARC.  This work began as http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06 by Daniel Black and myself that eventually resulted in http://tools.ietf.org/html/rfc6541.  Murray considered TPA too complex.  The TPA scheme could have avoided the very problems caused by DMARC policies placed on wrong account types.  DMARC is often promoted without its limitation being clearly stated or seemingly understood.  Does Yahoo expect mailing lists to drop users of their service?  

This could have been avoided without any disruption to mailing lists by a community generated list of known good third-party service providers published as hash labels.  Although IESG did not think SPF records able to generate hundreds of DNS transactions against otherwise uninvolved domains a concern, IESG regarded a single ATPS query against the authoritative domain a major threat that MUST be addressed by use of a "special" DKIM signature.  This IESG mandated change defeated efforts aimed at avoiding such disruptions and also made virtually any policy exception scheme non-deployable. 

The IESG needs to explain their thinking.  I can't, nor have they allowed a means for a functional alternative.

Regards,
Douglas Otis


> On 13/04/2014 09:20, Miles Fidelman wrote:
>> Dave,
>> 
>> Dave Crocker wrote:
>>> On 4/12/2014 12:56 PM, Miles Fidelman wrote:
>>>> - DMARC.org defines the "DMARC Base Specification" with a link to
>>>> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF
>>>> document
>>> 
>>> While the Internet-Draft mechanism is operated by the IETF, it is an
>>> open mechanism and issuance through it carries no automatic status,
>>> particularly with respect to the IETF.
>>> 
>>> The DMARC specification is not 'an IETF document'.  The current plan
>>> is to publish it as an RFC, through the 'Independent' stream, which
>>> also is /not/ an IETF activity.
>>> 
>> 
>> My point is that the folks behind dmarc PRESENT it in a way that
>> implicitly makes it look like an IETF document, and that it's on the
>> standards track.  The reality, as you say, is different.  "Plan to" is
>> vaporware.
>>> 
>>>> - the referenced document is an informational  Internet draft, that
>>> 
>>> Drafts do not have status.  So the qualifier 'informational' here is
>>> not meaningful.
>>> 
>> As currently published, it carries the header
>> 
>> Intended status: Informational
>> 
>>> 
>>>> In essence, DMARC is being represented as a mature, standards-track IETF
>>>> specification - with the implication that it's been widely vetted, and
>>>> is marching through the traditional experimental -> optional ->
>>>> recommended -> mandatory steps that IETF standards go through.
>>>> 
>>>> In reality:
>>>> - DMARC was developed by a tiny number of people, all of whom work for
>>>> very large ISPs
>>> 
>>> Well, a few of us who participated don't...
>> 
>> fair enough - but again, just look at http://dmarc.org/about.html - I
>> don't see your name, or any other small individuals or ISPs - what I do
>> see are
>> "A group of leading organizations came together in the spring of 2011"
>> and
>> "The founding contributors include:
>> 
>> * *Receivers:* AOL, Comcast, GMail, Hotmail, Netease, Yahoo! Mail
>> * *Senders:* American Greetings, Bank of America, Facebook, Fidelity,
>>   JP Morgan Chase, LinkedIn, PayPal
>> * *Intermediaries & Vendors:* Agari, Cloudmark, ReturnPath, Trusted
>>   Domain Project"
>> 
>> This was very much an industry-based effort.
>> 
>>> 
>>>> - as far as I can tell, all input from the broader community - notably
>>>> mailing list developers and operators was roundly ignored or dismissed
>>>> (the transcript is really clear on this)
>>> 
>>> What transcript?  I'm not aware of its being 'ignored or dismissed'.
>> 
>> Funny, that's the impression I get when I read back through the archives
>> for dmarc-discuss@dmarc.org and dmarc@ietf.org
>> 
>> pretty much all discussion of aligning the From: field came down to -
>> "you change"
>> 
>>> 
>>>> - while DMARC is at least partially tested, deploying and honoring
>>>> "p=reject" messages is brand new, and has wreaked tremendous damage
>>>> across the net
>>> 
>>> It's not new at all, though of course Yahoo's use is distinctive.
>> 
>> Depends on your definition of "new" - and while DMARC builds on an older
>> base, DMARC itself was started in 2011, and I assume the first standards
>> and software are more recent then that.
>> 
>> As you say, Yahoo's use is "distinctive" - though I'd use a somewhat
>> stronger word.
>>> 
>>> 
>>>> - as far as I can tell, those who are behind DMARC are taking the
>>>> position "it's not our problem" (see discussions on
>>>> dmarc-discuss@dmarc.org and dmarc@ietf.org) - and there is nary a Yahoo
>>>> representative to be seen anywhere
>>> 
>>> I've no idea what specifics you are referring to.
>> 
>> I've been following the discussions, on lots of lists, and I've yet to
>> see someone say even "I'm from Yahoo and we feel your pain" - much less
>> "hmm... maybe this wasn't such a good idea, we're going to back off and
>> implement in a slightly gentler manner - and maybe provide some support
>> to help patch the major list management packages" - or even "our
>> implementation honors Original-Authentication-Results"
>> 
>> nope - as far as I can tell, the folks who turned on p=reject at Yahoo
>> don't seem to have even told their own security or customer care folks
>> about what's going on - at least when this first broke, and I contacted
>> Yahoo's postmaster (thinking I needed to get our servers back on the
>> whitelist) - they just pointed me at the whitelist request form
>> 
>>> 
>>> 
>>>> The situation strikes me as incredibly perverse and broken - the more so
>>>> that the perpetrators are presenting this as blessed by the IETF
>>>> standards process.
>>> 
>>> I haven't seen anyone present such a claim of blessing.  Please point
>>> to the specifics.
>>> 
>>> I fear you are confusing the difference between a desire for standards
>>> status with a claim of its having been granted.
>>> 
>> No... I'm quoting the way that dmarc.org is presenting the "DMARC Draft
>> Specification" - as marching through the IETF standards track, as it is
>> generally understood, and then hiding in the fine print that no such
>> thing has happened, or is currently happening
>> 
>> I'm not confused.  It is, and I think intentionally, being presented in
>> a way that is intended to confuse.  And I personally think that IETF
>> should be calling them on it.  Officially, loudly, and clearly.  (The
>> same way that Xerox and Kleenex jump down the throats of anybody who
>> tries to use their names generically.  )
>> 
>> Miles Fidelman
>> 
>