Both of the cases you cited are entirely covered by ARC. If you are seeing failures, I would be pointing the finger toward said "intermediary SMTP system" which is modifying the message without properly affixing its own ARC set.
--Kurt On Thu, Nov 7, 2019 at 8:45 AM Weist, Bill <[email protected]> wrote: > 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: > [email protected] rewritten to [email protected]) > > > > 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. > > -Bill > > > > *From:* Brandon Long <[email protected]> > *Sent:* Wednesday, November 6, 2019 12:43 PM > *To:* Kurt Andersen (b) <[email protected]> > *Cc:* Weist, Bill <[email protected]>; [email protected] > *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. > > > > Brandon > > > > On Wed, Nov 6, 2019 at 7:37 AM Kurt Andersen (b) <[email protected]> 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 <[email protected]> > 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; d= > microsoft.com > <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmicrosoft.com&data=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191460908&sdata=KyZ7aC4X35IcojTOEbgeDFXnOPPSHvlt8RaqH8VtXpA%3D&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 > > *[image: IQVIA logo_96dpi_100pxheight]* > > Learn more > <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iqvia.com%2F&data=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191470898&sdata=w%2FI0jSRPXe2FRdp%2FgJ24EiKQO3OXBlB9ZOJjl4FVswE%3D&reserved=0> > about IQVIA™ > > > > 400 Campus Drive > > Collegeville, PA 19426 > > USA > > > > O: +1 610 244 2646 <(610)%20244-2646> | M: +1 484 904 8244 > <(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: https://www.iqvia.com/about-us/privacy/privacy-policy > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iqvia.com%2Fabout-us%2Fprivacy%2Fprivacy-policy&data=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191470898&sdata=HeMk%2BjRXLVJuYxWpQgL8g0DiHMOstcrEAjuppTXTHnc%3D&reserved=0>.. > Thank you. > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191470898&sdata=j1TU7PWjgxQGvmjfQ4RKZGQSzvQ7IrwTtcHMnW6ZAQE%3D&reserved=0> > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191480892&sdata=CvW1a5LuaUQBNVONP%2BZiX0zCRsJwvuCxb2%2FCcuQevhU%3D&reserved=0> > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
