Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers

John Levine <johnl@taugh.com> Fri, 03 April 2020 20:05 UTC

Return-Path: <johnl@iecc.com>
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 C41623A0935 for <dmarc@ietfa.amsl.com>; Fri, 3 Apr 2020 13:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level:
X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=k3OZQuLu; dkim=pass (1536-bit key) header.d=taugh.com header.b=kdQBqHEs
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 UaYsVOt75iNT for <dmarc@ietfa.amsl.com>; Fri, 3 Apr 2020 13:05:28 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 499323A092E for <dmarc@ietf.org>; Fri, 3 Apr 2020 13:05:28 -0700 (PDT)
Received: (qmail 74265 invoked from network); 3 Apr 2020 20:05:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12217.5e879707.k2004; bh=EH4rDwl7+tI6OLIKuajkELLu1nMujxj/ZsAJqkOj0AA=; b=k3OZQuLuXKVMGLg9Zymtmo/BHD+ddC5TjCouJp+t6qbGff2oOjV/RuHDKwWoHi2LdC5ZYfWZdNOzo1XmCIWeS3w0yCB8hGTej7XhkRUdl9I6QrbMkJbvIDjRBkBisBzjm5939ewgpmmKa9OLVCd2mDZ+xBmIBkCmW43d3xTquO06pL+Vs1AqPs/R6BwiteksIzphnFcD2KDdflnceUJk5vGn0aL6xSNXaV+W/aYweBr9nkMxnfNkSmh4fHjcCKYZ
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12217.5e879707.k2004; bh=EH4rDwl7+tI6OLIKuajkELLu1nMujxj/ZsAJqkOj0AA=; b=kdQBqHEsXpLGzaZQ5ZytY/5e6NGWbnXnQTp0bi0ouxU1YOt9NhcIX+O9YQ9iGueNcjMwivHE5mgTldOA5sHDEIgu4qNJpYymyzX22xBLuy3iunpmoqVVyuaEf6LTWn97dlgS9DlI561fd6vuE+nZurISpjhZ2rQgX7apgZiWl2GCgKeuLDJVQ/HK6llEDOSk+ywDZD3DHTpFEp7JsTH45aZiCmmWMUi23zw+hy+GluOLFDntbH1Ml3z32XpQgaaa
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Apr 2020 20:05:26 -0000
Received: by ary.qy (Postfix, from userid 501) id DDAD616FC9A3; Fri, 3 Apr 2020 16:05:26 -0400 (EDT)
Date: 3 Apr 2020 16:05:26 -0400
Message-Id: <20200403200526.DDAD616FC9A3@ary.qy>
From: "John Levine" <johnl@taugh.com>
To: dmarc@ietf.org
Cc: rfc@arcsin.de
In-Reply-To: <e2bd3117-2217-1206-0c0c-f06a35d49dca@arcsin.de>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/f32FGKquFmSr2IZkpDVw3sk8SZ0>
Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers
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, 03 Apr 2020 20:05:30 -0000

In article <e2bd3117-2217-1206-0c0c-f06a35d49dca@arcsin.de> you write:
>> this specification MUST delete any discovered instance of this header
>> field that claims, by virtue of its authentication service
>> identifier, to have been added within its trust boundary but that did
>> not come directly from another trusted MTA.
>
>In my opinion, a header that does not conform to the specified
>authres-header-field in the RFC, is not an Authentication-Results
>header, has no authentication service identifier, and as such cannot
>claim anything in the context of the RFC. ...

Honestly, it doesn't matter.  The only A-R headers you can trust are
the ones that your own system added, and the point of that text is
that you should delete ones that look like yours but that you didn't
add.

We leave other people's A-R headers in case they might be useful to
do forensics, and we have a slightly different version of them in
ARC chains which again are only trustworthy if you know who added
the ARC seals.

R's,
John