Re: [dmarc-ietf] Question regarding RFC 8617

Yes, its for checking whether a custodian made changes, but the changes its
checking for are the core of the message (to use the DKIM wording), the
same as DKIM.

If the core of the message was unchanged, then ARC is unnecessary.  The
utility of ARC is to pinpoint where the core was changed, so the receiver
can make a
judgement as to how to handle the message.

Brandon

On Thu, Nov 7, 2019 at 8:45 AM Weist, Bill <William.Weist@iqvia.com> 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:
> William.Weist@gmail.com rewritten to William.Weist@iqvia.com)
>
>
>
> 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 <blong@google.com>
> *Sent:* Wednesday, November 6, 2019 12:43 PM
> *To:* Kurt Andersen (b) <kboth@drkurt.com>
> *Cc:* Weist, Bill <William.Weist@iqvia.com>; dmarc@ietf.org
> *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) <kboth@drkurt.com> 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 <William.Weist@iqvia.com>
> 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
> dmarc@ietf.org
> 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
> dmarc@ietf.org
> 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>
>
>

Re: [dmarc-ietf] Question regarding RFC 8617

Attachment: image001.jpg