Re: [dmarc-ietf] dmarc and forwarding

Roland Turner <roland@rolandturner.com> Tue, 18 February 2014 11:24 UTC

Return-Path: <roland@rolandturner.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26E81A047F for <dmarc@ietfa.amsl.com>; Tue, 18 Feb 2014 03:24:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 LvzEdteW1x2P for <dmarc@ietfa.amsl.com>; Tue, 18 Feb 2014 03:24:22 -0800 (PST)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id BBD971A032F for <dmarc@ietf.org>; Tue, 18 Feb 2014 03:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=0Np8txCleWgQQJUhTj94FSJqeuujXtObpCsOaiwvLsk=; b=tJn1tUDWoa8CaYi/BIZiWjX3IOGuf3iEc13vM0eO3gF3lc3bxyCMivSWx2g60dfi+K40/grJ5AsswKHTMtOw4up/otalDB1ti2nG/BFZtTsrfJKcu1/XTQYJParTJO01B2RO2ssrUJJlezh0SVWZwxlP2bFT9667lDvIwaLVlWI=;
Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133
Received: from [116.12.149.133] (port=53125 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <roland@rolandturner.com>) id 1WFime-0002kB-VW for dmarc@ietf.org; Tue, 18 Feb 2014 11:24:17 +0000
Message-ID: <530342E0.8090309@rolandturner.com>
Date: Tue, 18 Feb 2014 19:24:16 +0800
From: Roland Turner <roland@rolandturner.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "dmarc@ietf.org" <dmarc@ietf.org>
References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be> <WM!6bb3f78a7feaec45cd6e16db08822359f618288053561e2a2c08e397644e063795fab5be7076e0d2e8163de4e710e3ff!@asav-2.01.com> <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> <20140130225152.GA27685@roeckx.be> <CAL0qLwbpy7R0gF9YPXJwFqrYr0F_ESxjLFS7ZSaxxTHpBF6KPA@mail.gmail.com> <20140131001732.GA29928@roeckx.be> <CAL0qLwaZfyTYkUcowWSOBtmC-UQFHC70CO+9cPfyyGRpRM3WLQ@mail.gmail.com> <CABDkrv2d=T9+bJTZr5Qq6dzANj7L5dLBnPb=V436ayh-6QX_mg@mail.gmail.com>
In-Reply-To: <CABDkrv2d=T9+bJTZr5Qq6dzANj7L5dLBnPb=V436ayh-6QX_mg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/J0y14pzTxufQqPUKNSWuXW5I--0
Subject: Re: [dmarc-ietf] dmarc and forwarding
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Feb 2014 11:24:23 -0000

I meant to respond to this earlier:

On 01/31/2014 02:38 PM, Mike Jones wrote:
> Roland gave an excellent explanation of the reason for the alignment 
> requirement the DMARC specifies.  One point in his reply I will 
> disagree on though is that domains without a current spoofing problem 
> should not implement a DMARC quarantine or reject policy.  This thing 
> about spoofing is that one never knows when one will become a victim.  
> We often see domains that go periods of time without a spoofing issue 
> and then are hit hard on one day.  If the your domain has excellent 
> SPF and DKIM with a high overall DMARC pass rate, you have fully 
> analyzed your DMARC reports to understand the risk of failures due to 
> mailing lists or forwarding, and everything looks good then why not 
> protect yourself from future attacks with a DMARC quarantine or reject?

I may have overstated slightly, but as a practical matter there really 
is a bound below which p=quarantine/reject does more harm than good to a 
Domain Owner, not because smaller organisations are immune from spoofing 
but because there is a non-zero cost in monitoring and interpreting 
authentication failures and responding when appropriate. Whether this 
cost is borne as a monetary subscription to an authentication 
specialist, as yet another demand on the time of an IT guy who's already 
spread far too thinly, or simply in disruption to business when neither 
of the above is in place and something breaks, the cost isn't zero. If 
the expected benefit of protection (the likely - not worst case - impact 
of an incident multiplied by the probability of an incident - a number 
which is vanishingly close to zero for most organisations) is less than 
the cost of monitoring, interpreting and responding then quarantine and 
reject are harmful choices.

The challenge, of course, is where to draw the line. F500s are clearly 
in the cross-hairs, Alexa's top thousand (and some distance beyond) 
likewise. Somewhere a little further along this continuum however, is a 
point beyond which the costs of monitoring, interpreting and responding 
(or of disruption) exceed the benefit. My guess, although I admit that I 
have no credible quantitative model, is that this applies to a 
substantial majority of all domains which are used in 5322.From headers.

- Roland