Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

Dave Crocker <dhc@dcrocker.net> Fri, 31 May 2019 13:44 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13961200F3 for <dmarc@ietfa.amsl.com>; Fri, 31 May 2019 06:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 OeoQjYgvky10 for <dmarc@ietfa.amsl.com>; Fri, 31 May 2019 06:44:13 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3D9120276 for <dmarc@ietf.org>; Fri, 31 May 2019 06:44:13 -0700 (PDT)
Received: from [192.168.0.125] (178-164-174-220.pool.digikabel.hu [178.164.174.220]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x4VDkDCP016847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2019 06:46:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559310375; bh=QHSXPwPCRWbYS/5OZ1QTaGZ9D3PWfACLXOkh0EnnoyY=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=SNKWeE5y1WcrhACRvh39+wDOCGKkQtciDSVECqmYhwL1W4tOwpodqjjXnAcoXastF 0EQxaqUKZy5Qco52iAKngJwPRtB7DNYd1cJSOZ1/h1ogpUCxXUYjB0BtzNXCjlTm5w eOBlymHwAqidZxJQThfZBaBzzz7hVpImBKARM4og=
To: Dotzero <dotzero@gmail.com>, fosterd@bayviewphysicians.com
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <54FB29A0-517A-430E-AF5B-CB079CC3D7F6@aegee.org> <20190526144848.08A772014A0BF4@ary.qy> <CAL0qLwbxwLTpgYJN9qBTzi2oN1EMvAYuNoDbw5Rx5W46-WNyLA@mail.gmail.com> <alpine.OSX.2.21.9999.1905301712140.76792@ary.qy> <c559a331d90b49eba5b5f6e35ff4774a@bayviewphysicians.com> <1931a4e4-7112-56ae-24e6-b138466392b4@dcrocker.net> <f5106924930f41c5bd83a709e4307f8b@bayviewphysicians.com> <CAJ4XoYd5F6Fte_ibUwWG82vPhiixTWYezCuL3nzahFRc5SJSTg@mail.gmail.com>
Reply-To: dcrocker@bbiw.net
From: Dave Crocker <dhc@dcrocker.net>
Message-ID: <1af46ba0-e9c6-5185-e910-4a8937cbd1aa@dcrocker.net>
Date: Fri, 31 May 2019 15:44:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CAJ4XoYd5F6Fte_ibUwWG82vPhiixTWYezCuL3nzahFRc5SJSTg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/DtdwBC2rR2MMmFpYNBIx9AhpX0g>
Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 31 May 2019 13:44:18 -0000

On 5/31/2019 4:47 AM, Dotzero wrote:
> Non-repudiation is not the purpose of DKIM signing. The purpose was (and 
> is) to provide a mechanism for mailbox providers to evaluate whether an 
> email message was authorized by a particular domain.


Nit-picking time.  I'd apologize for indulging, but I'm not really sorry:

Even "authorized" is too strong a label for what DKIM officially does.

"Touched" is more in line with what the spec defines, although "took 
some responsibility for" is a more ponderous way of saying that.

Specific sites have DKIM usage policies based on much stronger 
semantics, but that's outside the DKIM specification.  Hence, no one 
down the handling sequence can rely on just the specification and know 
of that stricter semantic.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net