Re: DMARC and yahoo

Douglas Otis <doug.mtview@gmail.com> Tue, 22 April 2014 01:16 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 1AF431A010B for <ietf@ietfa.amsl.com>; Mon, 21 Apr 2014 18:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 r79b9DWOQEfb for <ietf@ietfa.amsl.com>; Mon, 21 Apr 2014 18:16:33 -0700 (PDT)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 954551A00C2 for <ietf@ietf.org>; Mon, 21 Apr 2014 18:16:33 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id p10so4235357pdj.17 for <ietf@ietf.org>; Mon, 21 Apr 2014 18:16:28 -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=8tqUU5r+8aow2LIQyyt1APcDPj93ZDY9v74l+xd2kaI=; b=DG3AEM3zo+Ds6JsU2v7EtEkEajdIVY3zYxsvvB8/cvRbDY7Qjg81zNlbCH9QAELe08 IOXrdKfOGIN8pfatzsXKnBOPhmIzzKsmqO4uR+wZH0bhUmrWYnNruPh/ObXMXV1uJRVG spmI9ccxcyj6nKH//2G+AdrAjDl+iwDHpHz9dGqFCFSR3/zvHtKDGQAR+8uIxNyPxN3E 9Bsq4b9JIExSpkRWWMdJAqd7G/ZlmttSgabnXj+/badkGwnOHW0NSV+stYOKrfi3mnfF fr21p/9998vUMyjlXb/pviDvIuI6Sn3XVa2CE/lhQk5uK0uIBBgXYpLEtfaTSlvdf1cb ZWeQ==
X-Received: by 10.68.181.165 with SMTP id dx5mr41593838pbc.38.1398129388442; Mon, 21 Apr 2014 18:16:28 -0700 (PDT)
Received: from [192.168.2.116] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id id10sm80874023pbc.35.2014.04.21.18.16.26 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 18:16:27 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_533A3416-3BAD-4CCC-9AC3-F8AEF8941B58"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: DMARC and yahoo
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <53558891.5080503@sonnection.nl>
Date: Mon, 21 Apr 2014 18:16:36 -0700
Message-Id: <34F5F7D7-9226-4D6F-9CF4-F8A84444E38A@gmail.com>
References: <20140421163621.29166.qmail@joyce.lan> <53554A7B.20006@dcrocker.net> <5A812333-040A-4EF0-946A-8996D2E4B7EB@gmail.com> <53558891.5080503@sonnection.nl>
To: R.E.Sonneveld@sonnection.nl
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/2HFR5u4-ch_SVrF59aNbZVRWwKA
Cc: John Levine <johnl@taugh.com>, dcrocker@bbiw.net, 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: Tue, 22 Apr 2014 01:16:38 -0000

On Apr 21, 2014, at 2:07 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:

> Hi, Doug,
> 
> On 04/21/2014 09:20 PM, Douglas Otis wrote:
>> 
>> On Apr 21, 2014, at 9:42 AM, Dave Crocker <dhc@dcrocker.net> wrote:
>> 
>>> On 4/21/2014 9:36 AM, John Levine wrote:
>>>> They could fix it if they
>>>> wanted, e.g., by arranging to whitelist mail sources that don't match
>>>> DMARC's authentication model but send mail people want.  This is not
>>>> just mailing lists, of course.
>>> 
>>> 
>>> Sorry, but I'm not quite understanding what additional mechanism you have in mind.
>>> 
>>> Exactly who does exactly what?
>>> 
>>> Who has to adopt it?
>>> 
>>> How will it scale?
>> 
>> Dear Dave,
>> 
>> Each domain can simply point to their desired white-list. This can be one published directly or simply referenced as described in:
>> 
>> http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06#page-8
>> 
>> This has elements from the moribund ADSP.  The sender wishing to protect a domain while also applying policy like that of ADSP or DMARC can offer receivers a rapid and scalable method to check third-party domain authorizations.  This means senders are always able to defend recipients who trust messages from their domain.  Please note, authorizations can also require presence of a List-ID.  
> 
> This doesn't answer Dave's questions: who has to adopt it and how will it scale.

Dear Rolf,

Sorry, I thought the scheme was easy to understand.

The basic white-list hash-label publication scheme is a single and small DNS query referenced at a _tpa subdomain within the sender's domain in much the same manner _dmarc  and other policy schemes operate.  RRs TTL can be set at levels that provide sustainable query burdens.  DNS can also scale using anycast and support very high query rates.  DMARC senders would need to publish their white-list indicating support of this protocol and of course it could also be signaled within DMARC.  Since this list offers a low overhead service for recipients there should be quick implementation at the other end of the exchange by recipient ESPs.  This also affords senders full control over all of their desired policy exceptions. If there is a problem, senders would only have themselves to blame.

Please note, MLM software or From header fields do not change at all.  The major portion of the effort would be by sending domains having a goal of offering better protection while preserving desired use.  The white-list can also be shared with other DMARC domains who trust the list's administration. Technically, this should be seen as a change to DKIM and SPF in a similar manner as ATSP did.  Of course, the change can be appended to existing processes.  There were necessary elements missing from ATPS which also required DKIM signatures to change that made deployment impractical.

> Adoption: of course the owner of the sending domain has to adopt it, but is there also a role for the owners of mailing lists, invite services etc.? How will the sending domain ever know whether a mailing list is open or closed for example? How will it know which invite services will need a TPA exemption?

At one time, we provided a reputation list that answered that very question, but there has not been a need for the MLM list for several years now.  If a sender receives any report of abuse, they can notify the list.  If there is not a timely response, the MLM can be de-authorized by the sender. Quick and painless.

> Scaling: how does the owner of the sending domain (potentially very large numbers of users) know to what mailing lists its users are subscribed, what invite services will potentially need this TPA authorization etc.?

Perhaps senders could ask their users which MLM they wish to use.  They could also monitor their DMARC feedback as well.

> Furthermore, will it scale if mailing lists can be members of mailing lists and how will the sending domain know about this hierarchy or chain of mailing lists? So the technical howto might be the easy part of the solution, while the organizational howto will definitely be the difficult part...

There is nothing wrong in having all the trusted MLMs listed to then permit list to list traffic.  It would not involve any complex changes to message signing or header field use either.   Use of TPA would have dramatically lower overhead than that caused by reverse DNS queries or that of chained SPF records. 

Regards,
Douglas Otis