Re: (DMARC) We've been here before, was Why mailing lists

Douglas Otis <doug.mtview@gmail.com> Fri, 18 April 2014 15:48 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 0CAE91A0388 for <ietf@ietfa.amsl.com>; Fri, 18 Apr 2014 08:48:33 -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 H4aL4wo7A3ED for <ietf@ietfa.amsl.com>; Fri, 18 Apr 2014 08:48:29 -0700 (PDT)
Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 77F8B1A0417 for <ietf@ietf.org>; Fri, 18 Apr 2014 08:48:28 -0700 (PDT)
Received: by mail-pd0-f174.google.com with SMTP id y13so1535734pdi.5 for <ietf@ietf.org>; Fri, 18 Apr 2014 08:48:24 -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=0cxYkysFTFGaChUuD2X47S8reOvfuYA5bheGUvdL7yA=; b=Qdpp1Qsx4UQhu+MFs45FpTUSQjBMfOkKR7URz77bmNkGouYy3/6xpslnmHwINXcm8K 04cdYkNrtS+obpooDERy9FxFVYutj98vU42i2ZDIGFI7ZlfpkriHOzI0QR5+HFQ0MYfj zfyoHyMcy6swFDHYHRXRMZU3OdjzPfVsHTaW4YsGG8oePdyOyAImhAqSfZ9x7gRSBY0t l0cPxIKeRyt/69j5qmR0kpxLUi+Y64vIAwzbyEkFYcpgRxOUqMkEhkyxHLJt1WCCUeyW +guShWEwOFD7nzwNWPxnIFAi4e16ToissfU6Soo61SDsHho8pId3buo3XSzewWbW+FmM Kjvg==
X-Received: by 10.68.240.99 with SMTP id vz3mr22629484pbc.93.1397836104604; Fri, 18 Apr 2014 08:48:24 -0700 (PDT)
Received: from dhcp150.priv.bungi.com (c-24-4-159-60.hsd1.ca.comcast.net. [24.4.159.60]) by mx.google.com with ESMTPSA id ha2sm60673627pbb.8.2014.04.18.08.48.22 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 08:48:23 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1BC6D4A8-3F90-47BD-A754-B74ABAC3F9AC"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: (DMARC) We've been here before, was Why mailing lists
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <CAL0qLwa0a4nDAdCHkkMJdeemsj+cezcmH3+59CvhF8q7B72ryg@mail.gmail.com>
Date: Fri, 18 Apr 2014 08:48:22 -0700
Message-Id: <865517EA-29BD-4A6A-B1A2-F4C7653745A6@gmail.com>
References: <20140417181815.8A5871ACD1@ld9781.wdf.sap.corp> <9451.1397772992@sandelman.ca> <CAL0qLwa0a4nDAdCHkkMJdeemsj+cezcmH3+59CvhF8q7B72ryg@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/HRnwyLmyAmdQIhlyqiQgDkWz20g
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Pete Resnick <presnick@qti.qualcomm.com>, John R Levine <johnl@taugh.com>, "ietf@ietf.org" <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: Fri, 18 Apr 2014 15:48:33 -0000

On Apr 18, 2014, at 8:20 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

> On Thu, Apr 17, 2014 at 3:16 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> So, the bug is that Yahoo/DMARC/ are authenticating the From:, when it should
> really be authenticating the Sender:. DMARC should key it's policy from
> Sender: rather than From, and if it did that then:
>   1) we could leave the From: intact, which is what's good for the end
>      users.
>   2) the list would change the Sender:, which is what we would establish
>      the reputation of the list, not the From:
>   3) MUAs would compare the From: and Sender:, and if they differed,
>      could say useful things like:
> 
>      "From: Mrex@sap.com via ietf@ietf.org".
> 
> (I was also wondering this morning on my commute if a layer of message/rfc822
> added by the mailing list might be a useful interim hack)
> 
> http://tools.ietf.org/html/draft-kucherawy-dmarc-base-04#section-15.1
> 
> One of the key points about DMARC's design is that it's concerned specifically with From:.  The reason is that the content of From: is what's typically shown to the recipient by MUAs.  If DMARC keyed off Sender: instead, then this would work:
> 
> MAIL FROM: haha@badguy.example.com
> 
> From: security@paypal.com
> Sender: haha@badguy.example.com
> DKIM-Signature: v=1; d=badguy.example.com; ...
> 
> If DMARC pays attention to Sender: in favor of From:, then this passes, but what the user is shown that the message is from security@paypal.com with a DMARC pass.  Not good.
> 
> Using Sender: as the authentication key was suggested and ultimately abandoned during both DomainKeys (RFC 4870, the predecessor to DKIM) and Sender-ID (RFC 4406, pretty much never implemented) for this sort of reason.
> 
>     > MUAs which are not implementing the rfc822/2822/5322 "on behalf of"
>     > semantics of a message that carries both From: and Sender: header
>     > fields ought to be FIXED.  Standards that build on rfc822/2822/5322
>     > and do not respect "on behalf of" semantics of messages with
>     > both "Sender:" and "From:" also need to be FIXED.
> 
> I don't believe that's standardized.  I'm also not sure we (the IETF) want to enter into user space like MUAs, an area we have historically avoided because we don't really have such expertise.

Dear Murray,

Agreed.  The intent behind DMARC is to protect recipients wanting to trust specific From header fields.   Not protecting them will cause customer loss for high value transactional domains.  Most just don't want the flood of spoofing reaching their inbox these high value domains attract. 

Yahoo has had other problems where many of their accounts have become compromised.  Perhaps DMARC is also seen as a method to curb complaints caused by spoofed addresses so they can better address accounts actually compromised by leveraging DMARC feedback.  This would be a poor choice in my view.

Regards,
Douglas Otis

 

> 
> -MSK