Re: [dmarc-ietf] Question regarding RFC 8617

"Weist, Bill" <> Thu, 07 November 2019 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5CB5120113 for <>; Thu, 7 Nov 2019 08:45:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yGLY-ekqZBYW for <>; Thu, 7 Nov 2019 08:45:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6D55120858 for <>; Thu, 7 Nov 2019 08:45:41 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=fNA3fRGujb7X7YuRGtjn+TgeZ9U88/t7Ohw5NmH7oCk0LB4lWs3sTsV0ye7VEkNer2aKRshIAE+wws9wXP2jH9xVgAbmMEikLOs3n8GJqj99R2FE6vCSGm+ONYicYC5QMOLTojP/OyN/H8xj4awbgwL/fHh+GFIVgpBwFehxp8EwnsDCmSaL1E/Bt5cO+bS5uF+JWSRH07T+SIKPjxYEBjEBb4hkZ5jEWR337Ki/6dlwY1uBzloHD1z0EBjeyaNjdTWdz/cxyMasSI40jLxHbiH7Jg7FrmhgGxIm2sRg7zkUNk3EOREoLWQjR4qoOsNMfhwtSl7aovsMDUCuKg2dvQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n8oLzf9OSL+h4dCj3b9vsCWwAGz113OkbPINPXENWYc=; b=Z2v0oRlTn8hcUf3mnYWItJ6BGx4/dlxrLnhLYFySigpSMLY0a2UJ0+MLObhQ1soXI0iNzQIVDbrRv4Tw2TfGF1VZGTt9BgyLQLUJApTYwyjOOcrKBDa2h3vImwfNSw14bAjRFg2fK39J+UpkDVNllbEYfpffW+RDFqfUxE0AWZtWTz7h8xP6Evh/5OkSFql3/vBZYj+gXdYTrZc2HZYmkta0beCELb5coOGjWf1Nj2CIEXP6yhDls2OsUi3S3y4dwEqTejy92QqULIol0ZlFsXWC49vFV4gSlDRl+MQqCZ+CUextFlOxqfQxpJYGqb5rV7HfiqswpLFnQEaxHr6eFQ==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Thu, 7 Nov 2019 16:45:38 +0000
Received: from ([fe80::59e3:2661:ff12:f7be]) by ([fe80::59e3:2661:ff12:f7be%3]) with mapi id 15.20.2430.014; Thu, 7 Nov 2019 16:45:38 +0000
From: "Weist, Bill" <>
To: Brandon Long <>, "Kurt Andersen (b)" <>
CC: "" <>
Thread-Topic: [dmarc-ietf] Question regarding RFC 8617
Thread-Index: AdWTMguQWnkvj8CtSAGz9qIfZtaWOQBhe5aAAARtOwAAL3EZ4A==
Date: Thu, 7 Nov 2019 16:45:37 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
dlp-product: dlpe-windows
dlp-version: 11.0.700.9
dlp-reaction: no-action
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: d05a6e83-65a4-47cd-4680-08d763a1eb1a
x-ms-traffictypediagnostic: BYAPR05MB4855:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(39860400002)(396003)(376002)(346002)(136003)(51744003)(189003)(199004)(33656002)(76176011)(476003)(478600001)(11346002)(14454004)(2906002)(966005)(8676002)(45080400002)(81156014)(3846002)(102836004)(26005)(53546011)(7736002)(6116002)(6246003)(81166006)(8936002)(76116006)(66556008)(236005)(9686003)(790700001)(66946007)(486006)(66446008)(64756008)(66476007)(110136005)(7696005)(99286004)(316002)(446003)(186003)(4326008)(6506007)(5660300002)(25786009)(71200400001)(86362001)(54896002)(733005)(6306002)(55016002)(66616009)(6436002)(71190400001)(229853002)(5024004)(99936001)(256004)(606006)(5070765005)(66066001)(74316002)(52536014)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4855;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:3;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PLdv/v+rKfl5Sajx/aGG12BTZVTZth+vDfCG6QqYXd3M98BCDaKy5LIQ58IWe/fG8wjVPfuPmybpiv7HRqCknCwd8310k0SCP0rpb1wL8ONhqlzvipdxNtrBQGtPjGkVBpfJ8yz/8Cc0nSVynFhjsDrX8626pZOmaI1pjU3vMozilfjrmnt0zY0aS9sl1ptEKoo1T2IJ+GwaWL1zIVDl4RZudHz6fyTAsY2OgU+LEePeVYL025RAfPeK5OByKByCqFIP398lx4S1tNY6dHBA5w367qtQHR3Uxni6zvzpxg8O1slBYbTGzga4TjrX2Y/RXmSaoqJyp99lrpF81VLsMQCeBf+libWpPbGjq9/t/+ahMTjw0wK/GmXjRrMNh1mfhXIMwj3hepeZ/sjoRNbap9GqsD7tViIlCf4ldsZSelqoHoQQgF4tiq1l+m3oxaKASvVSLWtE+KCAvO7bvAOnQt6uIMlUfIzy/tyI8yBGil0=
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_004_BYAPR05MB4167E31DE0CC7377CEACF1A5FA780BYAPR05MB4167namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d05a6e83-65a4-47cd-4680-08d763a1eb1a
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 16:45:37.9797 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5989ece0-f90e-40bf-9c79-1a7beccdb861
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MqTNldtbEU5miZyCcA6t5ei0+P0PUv6Se0mXsVDDLTVNmJl5tZWvfuRlLi9qhhJLrV1ZTLjEhkb/UaFmFCUoWA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4855
Archived-At: <>
X-Mailman-Approved-At: Thu, 07 Nov 2019 11:11:18 -0800
Subject: Re: [dmarc-ietf] Question regarding RFC 8617
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Nov 2019 16:45:46 -0000

Thank you both for replying.  There are two instances where I have identified ARC signatures consistently failing:

Case 1:  An intermediary SMTP system receives an email on behalf of a recipient system whereby the “from” field is required to be changed for the email to reply as desired by the recipient system.  (example: rewritten to

Case 2: An Intermediary SMTP system receives an email on behalf of the recipient system whereby the “subject” field is required to by changed for the email to be categorized as desired by the recipient system. (example: “RE: [dmarc-ietf] Question regarding RFC 8617” modified to:  “RFC Correspondence: [dmarc-ietf] Question regarding RFC 8617”)

As Kurt pointed out below, the ARC signature is NOT intended to be validated by hops >1 step away.  However, I did not think this was the case and that ARC was specifically supposed to validate each custodian where DKIM would be broken by the cases listed above.

As differentiated from DKIM, the RFC reads as if ARC is designed to validate the “custodian” and NOT the “sender” therefore, “From” and “Subject” would not be as desirable as say “X-Received”, “X-Google-Smtp-Source”, and “X-Gm-Message-State” in the case of Brandon’s email to which I am replying.

It is my suggestion that for ARC to be a valuable addition to DKIM, it needs to focus on the “custodian” and not the “sender”.

Thank you both for your time and attention.

From: Brandon Long <>
Sent: Wednesday, November 6, 2019 12:43 PM
To: Kurt Andersen (b) <>
Cc: Weist, Bill <>om>;
Subject: Re: [dmarc-ietf] Question regarding RFC 8617

This email originated from outside of the organization.

What's more, the point of including Subject and other mutable headers is the same as it is for DKIM, those are the headers which are important to the receiver, so they should be validated.

As Kurt points out, the point of ARC is to acknowledge these changes hop to hop, and the Arc Seal proves who did the change, the question becomes do you believe
the person who changed it wasn't malicious.


On Wed, Nov 6, 2019 at 7:37 AM Kurt Andersen (b) <<>> wrote:
The choice of which headers are included in the signed set is strictly up to the domain administrators who implement the signing practices. Also, the AMS is only relevant for the next receiver, it is not intended to be validated by hops >1 step away from the domain which adds that instance so I don't see how mutability would matter.

--Kurt Andersen

On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill <<>> wrote:
DOI:  10.17487/RFC8617

The inclusion of the address headers in the signature, and possibly the Subject, is an issue:

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;<>amp;reserved=0>; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=;

If a downstream server needs to modify either of these two values, the signature check fails.

It is my understanding that the Authenticated Received Check signature is to validate the chain of possession.  As such, in my opinion, the signature should only include immutable references.

In my opinion, there is value in NOT requiring headers to be stripped by downstream servers, thus maintaining the custody chain from origination to destination.

Thank you for your time and attention,

William M. Weist
Enterprise Architect I – Global Messaging – Mobile and Presence
CIO Team – End User Computing
[IQVIA logo_96dpi_100pxheight]
Learn more<> about IQVIA™

400 Campus Drive
Collegeville, PA 19426

O: +1 610 244 2646<tel:(610)%20244-2646> | M: +1 484 904 8244<tel:(484)%20904-8244>

IMPORTANT - PLEASE READ: This electronic message, including its attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY PRIVILEGED or PROTECTED information and is intended for the authorized recipient of the sender. If you are not the intended recipient, you are hereby notified that any use, disclosure, copying, or distribution of this message or any of the information included in it is unauthorized and strictly prohibited. If you have received this message in error, please immediately notify the sender by reply e-mail and permanently delete this message and its attachments, along with any copies thereof, from all locations received (e.g., computer, mobile device, etc.). To the extent permitted by law, we may monitor electronic communications for the purposes of ensuring compliance with our legal and regulatory obligations and internal policies. We may also collect email traffic headers for analyzing patterns of network traffic and managing client relationships. For further information see:<>amp;reserved=0>.. Thank you.
dmarc mailing list<><>
dmarc mailing list<><>