Re: not really to do with Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

Douglas Otis <doug.mtview@gmail.com> Wed, 16 July 2014 01:29 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 0A9131B29E0 for <ietf@ietfa.amsl.com>; Tue, 15 Jul 2014 18:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 PaByPrnq_c1c for <ietf@ietfa.amsl.com>; Tue, 15 Jul 2014 18:29:19 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DA31B29D5 for <ietf@ietf.org>; Tue, 15 Jul 2014 18:29:19 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id kx10so305689pab.6 for <ietf@ietf.org>; Tue, 15 Jul 2014 18:29:19 -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 :content-transfer-encoding:message-id:references:to; bh=GFOodO3hU9ZJDqsHTfx99RuU49l2goBkemxsSiRRpus=; b=ShAbhhNKnAlQC13v/p7i63QKUs4GXJFD9B5Cw4HkfSNC1A7IdiM8AS92ee+AsGbCvm ou89zc1Fim5MQZYau4paxFOKZzIGujqyKMmRzFv2aOiQKIM3g/5kTbhKEiwdDqCk++hc JLiDFKxLIm9KKN3W49sQHQ3BncTS51tQgf3MctB0l8Yuhmqs+8hUZ/e8NymSQDvlcO0Y Q1x5BSH7/26EAb9AECtl4/q7ayAyxZwkY3SM8Tmfai4MxL+0zNIjnbrHYkn5m4OWKvt6 G0teyyKgh3lDHJp5bHZP/UIR/fmfOIQw1PKAu3LRFaQdrQu1zLqS5VnEAw1tr20C03UB CIfA==
X-Received: by 10.66.66.166 with SMTP id g6mr12720818pat.108.1405474158931; Tue, 15 Jul 2014 18:29:18 -0700 (PDT)
Received: from [192.168.2.234] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id z3sm64153166pas.15.2014.07.15.18.29.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 18:29:18 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: not really to do with Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <20140716002015.GV2595@mournblade.imrryr.org>
Date: Tue, 15 Jul 2014 18:29:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E870154-FACB-4E7A-BD3E-FDC784E391D9@gmail.com>
References: <4450964.7UmRiHm4KW@scott-latitude-e6320> <20140715001549.GG2595@mournblade.imrryr.org> <2270075.AYnCC6OxAQ@scott-latitude-e6320> <20140715033346.GL2595@mournblade.imrryr.org> <026301cfa01a$7ebdde40$4001a8c0@gateway.2wire.net> <20140715112023.GU2595@mournblade.imrryr.org> <01PA78TOWR4O007ZXF@mauve.mrochek.com> <53C55509.8050108@dcrocker.net> <01PA7DC3IFS0007ZXF@mauve.mrochek.com> <53C592C8.6050506@dcrocker.net> <20140716002015.GV2595@mournblade.imrryr.org>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/H44A6Pifn93v2xjV_v-fqUg4Lpg
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: Wed, 16 Jul 2014 01:29:21 -0000

On Jul 15, 2014, at 5:20 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

> On Tue, Jul 15, 2014 at 01:44:56PM -0700, Dave Crocker wrote:
> 
>> Incurring the considerable expense, in people and opportunity cost, by
>> pursuing a global standards effort that proves ineffective is a
>> particularly pernicious path, especially with respect to a
>> security-related topic like phishing.
> 
> Is there quantitative evidence that preventing spoofing of the
> "From" address reduces the efficacy of phishing?  My guess is that
> any such effect is rather marginal, and that phishers succeed or
> fail based on the content of the pitch, rather than "metadata".

Dear Viktor,

One of the major proponents for DMARC, in an industry closed meeting, made an impressive presentation showing their costs related to phishing.  The major component was customer attrition following each extensive phishing campaign.  DMARC started out as private agreements with large providers.  It was felt publishing these requests in DNS would provide better coverage and it has.

This was never about reducing losses due to fraud, it was about a pragmatic effort to protect their customer base.  People want to be able to trust the From header field, and would walk away from email related services when they couldn't.  The PRA algorithm promoted by Sender-ID never effectively mitigated phishing.  With DMARC and simply sorting messages based on trusted From header fields offered customers a tolerable solution.

DMARC is a good solution for domains only sending transactional messages by combining both SPF and DKIM into a scheme that offers reliable delivery while also ensuring rejection of invalid sources.  This scheme falls apart when applied against domains handling normal email.  Even so, some domains have seen their user accounts repeatedly compromised and were hoping to leverage DMARC's benefit of being relied upon to reject invalid sources. 

Unfortunately, such an effort must rely on feedback offered to DMARC domains otherwise its rejections become too disruptive to be relied on.  Only the DMARC domain is able to share this information with recipients.  In some cases, this involves third-party back-office services that offer source alignment with the Sender header field.  Even in this case, it is still the From header field the recipient will recognize and wish to trust.

The TPA-Label scheme is able to convey informally federated domains as determined by feedback given to the DMARC domain.   TPA-Label is also able to indicate alignment requirements for Sender and List-ID to give recipients trustworthy sorting options.

Regards,
Douglas Otis