From nobody Wed Dec 2 07:40:46 2015 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 287901B3544; Mon, 30 Nov 2015 17:12:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151201011224.857.46547.idtracker@ietfa.amsl.com> Date: Mon, 30 Nov 2015 17:12:24 -0800 Archived-At: X-Mailman-Approved-At: Wed, 02 Dec 2015 07:40:40 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-12.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 01:12:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF. Title : Interoperability Issues Between DMARC and Indirect Email Flows Authors : Franck Martin Eliot Lear Tim Draegen Elizabeth Zwicky Kurt Andersen Filename : draft-ietf-dmarc-interoperability-12.txt Pages : 22 Date : 2015-11-30 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 7 07:23:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086591A8702 for ; Mon, 7 Dec 2015 07:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no 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 lzz7QEPcyIoi for ; Mon, 7 Dec 2015 07:23:54 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD04C1A86E3 for ; Mon, 7 Dec 2015 07:23:53 -0800 (PST) Received: by qkdb5 with SMTP id b5so32178972qkd.0 for ; Mon, 07 Dec 2015 07:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=XIVRtVbTJL8DPxpAZyVgvIDDlsAAvs/RSMIpFk7HbFM=; b=Z5MEt+dncAxEcDypuyWmlpDodkI8ySv0Yx8PCwUTDLgFW+AhWCMNHdQLlrzKUT+WBQ +MO2biPDJcVD8ZkZW4sWeutBMjdAoZCoY3R041fM94BgqNBmTatcG5uG2H10o9LdN8N3 snlro7XkTvqqlsQJRFomgdJdB6XceaM05V6RA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=XIVRtVbTJL8DPxpAZyVgvIDDlsAAvs/RSMIpFk7HbFM=; b=Up3aWcgW1tzp8eqGC/V8rhFccKQfzElnU/kE3muJUPfx+TcpWX1LyFJHMOavGxfpBR ZbddMsEP4pJzEPV/HfyhrW2bKjSr89RW2ivbrT9KJr0iAiOXvXS10e06KZbM2Zb9HuLr VV6ehpppWSSHZ5fem9qVV0wnSs8y2MrvPWY4/ZUkloGjST4UtifVTKUiY9iiZn2sZQLp EOTPaZnrSC5nM+3VBQkPfCw+uBQljtjn1OdQ1az8DgJtj5m2fBza0td+06A1VZIPHJWv 4s7tXe7of832Je1S56/G6whN7GhPnLCfTvjbfbsc52MbvSH1ckuj65Whi+OOmSKxktyZ gerw== X-Gm-Message-State: ALoCoQksQ7o7QKFv+XCFPoknW+Uz1V2oWmOHrjoBL5jQm8ekgi67RrIJteWXt6mL78DVCYHWkxtn MIME-Version: 1.0 X-Received: by 10.55.79.141 with SMTP id d135mr36737244qkb.41.1449501833051; Mon, 07 Dec 2015 07:23:53 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.198.219 with HTTP; Mon, 7 Dec 2015 07:23:52 -0800 (PST) Date: Mon, 7 Dec 2015 07:23:52 -0800 X-Google-Sender-Auth: BAmmDsI7utNM8uvqywXixrQoj9I Message-ID: From: "Kurt Andersen (b)" To: "dmarc@ietf.org" , Eliot Lear Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 07 Dec 2015 15:23:56 -0000 Rather than submit this directly as a draft update, I wanted to circulate my proposed change for "pre"comment to see if it addresses the concern with undue textual density in section 2.1, particularly the last paragraph about SPF identifiers. My proposed rework for section 2.1 follows below. I have split the section into subsections dealing each with the DKIM and SPF identifiers and expanded the discussion around the SPF identifiers. Comments welcome. --Kurt Andersen Currently, section 2.1 reads: 2.1. Identifier Alignment DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message source validation. The DMARC [RFC7489] mechanism refers to source domains that are validated by DKIM or SPF as Authenticated Identifiers. DMARC requires an Authenticated Identifier to be related to the domain found in the message's RFC5322.from header field [RFC5322]. This relationship is referred to as Identifier Alignment. DMARC allows for Identifier Alignment to be achieved in two different modes: strict and relaxed. Strict mode requires an exact match of either of the Authenticated Identifiers to the message's RFC5322.from header field [RFC5322]. Relaxed mode allows for Identifier Alignment if Authenticated Identifiers and the message's RFC5322.from header field [RFC5322] share the same Organizational Domain. In general, interoperability issues between strict and relaxed modes are the same, with strict mode constraining the application of possible solutions. The mitigations described in this document generally require a relaxed mode of Identifier Alignment. DKIM provides a cryptographic means for a domain identifier to be associated with a particular message. As a standalone technology DKIM identifiers are not required to be relevant to the content of a message. However, for a DKIM identifier to align in DMARC, the signing domain of a valid signature must be part of the same Organizational Domain as the domain in the RFC5322.from header field [RFC5322]. In addition, DKIM allows for the possibility of multiple valid signatures. The DMARC mechanism will process Authenticated Identifiers that are based on DKIM signatures until an aligned Authenticated Identifier is found (if any). However, operational experience has shown that some implementations have difficulty processing multiple signatures. The impact on DMARC processing is clear: implementations that cannot process multiple DKIM signatures may incorrectly flag messages as "failing DMARC" and erroneously apply DMARC based policy to otherwise conforming messages. SPF can provide two Authenticated Identifiers. The DMARC relevant Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM [RFC7208] based on the RFC5321.mailfrom [RFC5321] domain, or, if the RFC5321.mailfrom address is absent (as in the case of "bounce" messages), on the RFC5321.HELO/EHLO SMTP domain. The SPF validated domain in RFC7208.MAILFROM must be part of the same Organizational Domain as the domain in the RFC5322.from header field to be aligned. It is important to note that even when an SPF record exists for the domain in RFC5322.from [RFC5322], SPF will not authenticate it unless it is also the domain checked by SPF. Also note that the RFC7208.MAILFROM definition is different from the RFC5321.mailfrom [RFC5321] definition. ----------------------- Proposed rework: 2.1. Identifier Alignment DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message source validation. The DMARC [RFC7489] mechanism refers to source domains that are validated by DKIM or SPF as Authenticated Identifiers. DMARC requires an Authenticated Identifier to be related to the domain found in the message's RFC5322.from header field [RFC5322]. This relationship is referred to as Identifier Alignment. DMARC allows for Identifier Alignment to be achieved in two different modes: strict and relaxed. Strict mode requires an exact match of either of the Authenticated Identifiers to the message's RFC5322.from header field [RFC5322]. Relaxed mode allows for Identifier Alignment if Authenticated Identifiers and the message's RFC5322.from header field [RFC5322] share the same Organizational Domain. In general, interoperability issues between strict and relaxed modes are the same, with strict mode constraining the application of possible solutions. The mitigations described in this document generally require a relaxed mode of Identifier Alignment. 2.1.1. DKIM Identifier(s) DKIM provides a cryptographic means for one or more domain identifier to be associated with a particular message. As a standalone technology DKIM identifiers are not required to be relevant to the content of a message. However, for a DKIM identifier to align in DMARC, the signing domain of a valid signature must be part of the same Organizational Domain as the domain in the RFC5322.from header field [RFC5322]. In addition, DKIM allows for the possibility of multiple valid signatures. The DMARC mechanism will process Authenticated Identifiers that are based on DKIM signatures until an aligned Authenticated Identifier is found (if any). However, operational experience has shown that some implementations have difficulty processing multiple signatures. The impact on DMARC processing is clear: implementations that cannot process multiple DKIM signatures may incorrectly flag messages as "failing DMARC" and erroneously apply DMARC based policy to otherwise conforming messages. 2.1.2. SPF Identifier(s) The SPF specification [RFC7208] defines two Authenticated Identifiers for each message. These identifiers derive from: a. the RFC5321.mailfrom [RFC5321] domain, and b. the RFC5321.HELO/EHLO SMTP domain. In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is defined to be based on RFC5321.mailfrom unless that value is absent (as in the case of "bounce" messages) in which case, the second (RFC5321.HELO/EHLO) identifier value is used. This "fallback" definition has occasionally been misunderstood by senders since "bounce" messages are often an "automatic" feature of MTA software. For the purposes of DMARC validation/alignment, the hybrid RFC7208.MAILFROM [RFC7208] identifier's domain is used if, and only if, it is aligned with the RFC5322.from [RFC5322] domain. The alignment of the validated domain is determined based on the DMARC record's "strict" or "relaxed" designation as described above for the DKIM identifiers and in [RFC7489]. From nobody Tue Dec 8 10:26:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB86E1A1A5A for ; Tue, 8 Dec 2015 10:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 2pSxq0_mEsBr for ; Tue, 8 Dec 2015 10:26:06 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CFA1A1A90 for ; Tue, 8 Dec 2015 10:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8170; q=dns/txt; s=iport; t=1449599166; x=1450808766; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=e0gmjfZJd+w70yTav81JGz1iFCcvam35F/f81loRQlM=; b=EpdG94dA+eL1x83tSG8nX1AS4uivjH9EOh5iZbcPwXQjp3USCemDdHrc 4f+qM4eqNDBcdwfHRz12HXUJezuY+j7BgGM7psZAbPvyPQp/KYUg2kxxq rZEqMnEsOoDD+MxO7ql14l4xDBASI4NdVairyvKtI2yCFXul9nKmPwHUf w=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBABoH2dW/xbLJq1exDeCXoMwAoILA?= =?us-ascii?q?QEBAQEBgQuENQEBBCNPBhELGAkWCwICCQMCAQIBRQYBDAgBAReIFK9QkHABAQE?= =?us-ascii?q?BAQEBAwEBAQEBAQETCYtRh3eBRAEEh0+PEoJhgWKDF4VigVuHRopwiFxjgkSBQ?= =?us-ascii?q?T2EWyWBIwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,400,1444694400"; d="asc'?scan'208";a="607080529" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2015 18:26:04 +0000 Received: from [10.61.173.38] ([10.61.173.38]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tB8IQ3b7028783; Tue, 8 Dec 2015 18:26:03 GMT To: "Kurt Andersen (b)" , "dmarc@ietf.org" References: From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <566720BA.5080601@cisco.com> Date: Tue, 8 Dec 2015 19:26:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NRFvmrtLbkGtHwEPxMG3q9qgdOpWSjEnR" Archived-At: Subject: Re: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 08 Dec 2015 18:26:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NRFvmrtLbkGtHwEPxMG3q9qgdOpWSjEnR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kurt, I need a bit more time to review this text, but I want to point out that one of my main issues was that an example or two that highlights the fields or the SMTP exchange would be helpful. I am willing to toss something together for the group's consideration if you want me to pass the token. Depending on their length I would drop these inline or in an appendix. Eliot On 12/7/15 4:23 PM, Kurt Andersen (b) wrote: > Rather than submit this directly as a draft update, I wanted to > circulate my proposed change for "pre"comment to see if it addresses > the concern with undue textual density in section 2.1, particularly > the last paragraph about SPF identifiers. My proposed rework for > section 2.1 follows below. I have split the section into subsections > dealing each with the DKIM and SPF identifiers and expanded the > discussion around the SPF identifiers. > > Comments welcome. > > --Kurt Andersen > > Currently, section 2.1 reads: > > 2.1. Identifier Alignment > > DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message > source validation. The DMARC [RFC7489] mechanism refers to source > domains that are validated by DKIM or SPF as Authenticated > Identifiers. DMARC requires an Authenticated Identifier to be related > to the domain found in the message's RFC5322.from header field > [RFC5322]. This relationship is referred to as Identifier Alignment. > > DMARC allows for Identifier Alignment to be achieved in two different > modes: strict and relaxed. Strict mode requires an exact match of > either of the Authenticated Identifiers to the message's RFC5322.from > header field [RFC5322]. Relaxed mode allows for Identifier Alignment > if Authenticated Identifiers and the message's RFC5322.from header > field [RFC5322] share the same Organizational Domain. In general, > interoperability issues between strict and relaxed modes are the same, > with strict mode constraining the application of possible solutions. > The mitigations described in this document generally require a relaxed > mode of Identifier Alignment. > > DKIM provides a cryptographic means for a domain identifier to be > associated with a particular message. As a standalone technology DKIM > identifiers are not required to be relevant to the content of a > message. However, for a DKIM identifier to align in DMARC, the signing > domain of a valid signature must be part of the same Organizational > Domain as the domain in the RFC5322.from header field [RFC5322]. > > In addition, DKIM allows for the possibility of multiple valid > signatures. The DMARC mechanism will process Authenticated Identifiers > that are based on DKIM signatures until an aligned Authenticated > Identifier is found (if any). However, operational experience has > shown that some implementations have difficulty processing multiple > signatures. The impact on DMARC processing is clear: implementations > that cannot process multiple DKIM signatures may incorrectly flag > messages as "failing DMARC" and erroneously apply DMARC based policy > to otherwise conforming messages. > > SPF can provide two Authenticated Identifiers. The DMARC relevant > Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM > [RFC7208] based on the RFC5321.mailfrom [RFC5321] domain, or, if the > RFC5321.mailfrom address is absent (as in the case of "bounce" > messages), on the RFC5321.HELO/EHLO SMTP domain. The SPF validated > domain in RFC7208.MAILFROM must be part of the same Organizational > Domain as the domain in the RFC5322.from header field to be aligned. > It is important to note that even when an SPF record exists for the > domain in RFC5322.from [RFC5322], SPF will not authenticate it unless > it is also the domain checked by SPF. Also note that the > RFC7208.MAILFROM definition is different from the RFC5321.mailfrom > [RFC5321] definition. > > ----------------------- > Proposed rework: > > 2.1. Identifier Alignment > > DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message > source validation. The DMARC [RFC7489] mechanism refers to source > domains that are validated by DKIM or SPF as Authenticated > Identifiers. DMARC requires an Authenticated Identifier to be related > to the domain found in the message's RFC5322.from header field > [RFC5322]. This relationship is referred to as Identifier Alignment. > > DMARC allows for Identifier Alignment to be achieved in two different > modes: strict and relaxed. Strict mode requires an exact match of > either of the Authenticated Identifiers to the message's RFC5322.from > header field [RFC5322]. Relaxed mode allows for Identifier Alignment > if Authenticated Identifiers and the message's RFC5322.from header > field [RFC5322] share the same Organizational Domain. In general, > interoperability issues between strict and relaxed modes are the same, > with strict mode constraining the application of possible solutions. > The mitigations described in this document generally require a relaxed > mode of Identifier Alignment. > > 2.1.1. DKIM Identifier(s) > > DKIM provides a cryptographic means for one or more domain identifier > to be associated with a particular message. As a standalone technology > DKIM identifiers are not required to be relevant to the content of a > message. However, for a DKIM identifier to align in DMARC, the signing > domain of a valid signature must be part of the same Organizational > Domain as the domain in the RFC5322.from header field [RFC5322]. > > In addition, DKIM allows for the possibility of multiple valid > signatures. The DMARC mechanism will process Authenticated Identifiers > that are based on DKIM signatures until an aligned Authenticated > Identifier is found (if any). However, operational experience has > shown that some implementations have difficulty processing multiple > signatures. The impact on DMARC processing is clear: implementations > that cannot process multiple DKIM signatures may incorrectly flag > messages as "failing DMARC" and erroneously apply DMARC based policy > to otherwise conforming messages. > > 2.1.2. SPF Identifier(s) > > The SPF specification [RFC7208] defines two Authenticated Identifiers > for each message. These identifiers derive from: > > a. the RFC5321.mailfrom [RFC5321] domain, and > b. the RFC5321.HELO/EHLO SMTP domain. > > In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is > defined to be based on RFC5321.mailfrom unless that value is absent > (as in the case of "bounce" messages) in which case, the second > (RFC5321.HELO/EHLO) identifier value is used. This "fallback" > definition has occasionally been misunderstood by senders since > "bounce" messages are often an "automatic" feature of MTA software. > > For the purposes of DMARC validation/alignment, the hybrid > RFC7208.MAILFROM [RFC7208] identifier's domain is used if, and only > if, it is aligned with the RFC5322.from [RFC5322] domain. The > alignment of the validated domain is determined based on the DMARC > record's "strict" or "relaxed" designation as described above for the > DKIM identifiers and in [RFC7489]. > --NRFvmrtLbkGtHwEPxMG3q9qgdOpWSjEnR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWZyC6AAoJEIe2a0bZ0nozOLIIAIONpD5Od8d1mxSXYTsVa0X5 ekSy8d870poT/KduSeBrahpp1BElw/66EtuiR8Vfj5jGfa7pjh31LuxYcK+S+RmK I8uJsg4OY9E+4xLO2l/9td1fVRlV+Ux0ru2Ijw9fiXR28KuzuuMjy0D7UvDXTRnx v1Pgi/VpOEWWXP+ImV1K9dsXKmd7GrwTLJdqwiYBtM68Rc7emmYn64DLr2id7SN4 DPq1djIQcNR38vBUR6OABFujlS/QOv9M9Sv1GuIaOtf9ybJl8gZRDA9WRN9NvMJF +w7NwkHQnjJbPz3VDlJyUgY8RSgJZJBob8goQHvfMU1NOfwxpk7ydtsRYbWNWnI= =UWsU -----END PGP SIGNATURE----- --NRFvmrtLbkGtHwEPxMG3q9qgdOpWSjEnR-- From nobody Tue Dec 8 12:20:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10171A6EF4 for ; Tue, 8 Dec 2015 12:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.276 X-Spam-Level: X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no 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 9SDRvt8IFZuA for ; Tue, 8 Dec 2015 12:20:21 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BCA1A6EE1 for ; Tue, 8 Dec 2015 12:20:21 -0800 (PST) Received: by qgea14 with SMTP id a14so35135835qge.0 for ; Tue, 08 Dec 2015 12:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9wUiTHZc/xmBRRhQRVLQIuOjcZrDzNKFqyJPb5MQ4nc=; b=YncZ8UnopVGvwladVke3JZkau4ZZzDIKSCPQfSHdoo7sDbVCQexJ1Lp28XhEj0Zr+o Gn3d2tJtSjecsPen34IG6ZmpiG1TGo6ZtTYqOT6IlCIUAVcznC7haY0Nam4shqS8b7m5 r/LIz8x+I8t2HGArf6zfLdzCpQiDVc2JJ2w0o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9wUiTHZc/xmBRRhQRVLQIuOjcZrDzNKFqyJPb5MQ4nc=; b=ZIsWzKf5k2HDkPsB1R1lZj/ZAny5dMRoJKC6e64uw/6qF2UZI/mvQmyZS/EB8H3uC8 g5qD0wexrAB+5RIhfuc3e53bXcAuN+a3oMlOU4b/SHlhfyRNwzh/782ncEB/Lk78XS3n ovRE3eNYz3XWOr7JV9dkfvRmGD23ceY1JB2c3Rqc6/u3qJ3TuHx/yKYyId+Dw3BpkIGd 5LC3WCiFtQr6vGWw1nqw17mCod1D4DGy1EaJoGo7Norq90fmCsrPmz2j6cB8J4e48jvt LPFagESWB3BGGLEKl3vscm6Gpt4LBU2w6W1u6DbLAHIUsq5eDV33slgS5z/3vSxHLuaF tsGQ== X-Gm-Message-State: ALoCoQn1PypTKHK0cqaq5vR9x3J8FnXqOUQx5c6EPQV33s2r1JPPLK9LN7dCzs1sOQFWMDUbL0Es2UVoKX32et+Jyn7hsXGbDg== MIME-Version: 1.0 X-Received: by 10.55.82.193 with SMTP id g184mr2156963qkb.65.1449606019664; Tue, 08 Dec 2015 12:20:19 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.198.219 with HTTP; Tue, 8 Dec 2015 12:20:19 -0800 (PST) In-Reply-To: <566720BA.5080601@cisco.com> References: <566720BA.5080601@cisco.com> Date: Tue, 8 Dec 2015 12:20:19 -0800 X-Google-Sender-Auth: 04n0k20JFoc7yENLOYrx8kHPMJU Message-ID: From: "Kurt Andersen (b)" To: Eliot Lear Content-Type: multipart/alternative; boundary=001a114a6fccddeb7d052668b3d5 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 08 Dec 2015 20:20:23 -0000 --001a114a6fccddeb7d052668b3d5 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 8, 2015 at 10:26 AM, Eliot Lear wrote: > > I need a bit more time to review this text, but I want to point out that > one of my main issues was that an example or two that highlights the > fields or the SMTP exchange would be helpful. I am willing to toss > something together for the group's consideration if you want me to pass > the token. Depending on their length I would drop these inline or in an > appendix. > > > Eliot I can put together an appendix with some examples. I was thinking that having a better explanation would provide more value so I guess I got your suggestion backwards :-) --Kurt --001a114a6fccddeb7d052668b3d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 8, 2015 at 10:26 AM, Eliot Lear <lear@cisco.com> = wrote:

I need a bit more time to review this text, but I want to point out that one of my main issues was that an example or two that highlights the
fields or the SMTP exchange would be helpful.=C2=A0 I am willing to toss something together for the group's consideration if you want me to pass=
the token.=C2=A0 Depending on their length I would drop these inline or in = an
appendix.
=


Eliot

I can put together an appendix with some= examples. I was thinking that having a better explanation would provide mo= re value so I guess I got your suggestion backwards :-)

--Kurt
--001a114a6fccddeb7d052668b3d5-- From nobody Tue Dec 8 13:00:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C871A8025 for ; Tue, 8 Dec 2015 13:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 l1zbl6jckZ7T for ; Tue, 8 Dec 2015 13:00:54 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C16F1A6FA6 for ; Tue, 8 Dec 2015 13:00:54 -0800 (PST) Received: (qmail 65124 invoked from network); 8 Dec 2015 21:00:53 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Dec 2015 21:00:53 -0000 Date: 8 Dec 2015 21:00:31 -0000 Message-ID: <20151208210031.62812.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: kboth@drkurt.com Subject: Re: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 08 Dec 2015 21:00:55 -0000 >I can put together an appendix with some examples. I was thinking that >having a better explanation would provide more value so I guess I got your >suggestion backwards :-) I'd prefer that you post the current version of the draft so we can see what the context is. Draft revisions are cheap, posting three in a week if there are changes is not unreasonable. R's, John From nobody Tue Dec 8 15:57:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B971AD213 for ; Tue, 8 Dec 2015 15:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 E_HhcaiuUHHu for ; Tue, 8 Dec 2015 15:57:33 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEB21AD151 for ; Tue, 8 Dec 2015 15:57:25 -0800 (PST) Received: by qgeb1 with SMTP id b1so45474715qge.1 for ; Tue, 08 Dec 2015 15:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=SbhYp4jbU49wgGqS4YNz9WkcWptP8Q8mumoEzj44L7g=; b=SBBrvsXKoe4eq/chX0iPpqT9KVS5kI5jHrNA4obxasoWGNF2rRLg/iiYdRSUzV1bMR oPxAXE9DnYxK6ftXVTq1CILaBpw7+rtLOxGrNTmkq9DE6OkEe0L9lZLCPcx1R7QhJXCt 4nFshV7MfgT0tSpoRohZNn/d9V33vZeZVevcE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SbhYp4jbU49wgGqS4YNz9WkcWptP8Q8mumoEzj44L7g=; b=ioydlFM1FAHJYZn36sFxZLxhE2n8Ircxs0CiOQaZWYO8Wo5Aj19w2mA9hW2s7+M8fv WLZAEL7L89qqPJjSUGPbmoYJTEkkXd5v29AbrYE5KlVdUjO/U2LhvkoHuEfFnDEA7714 6mKEiFljzhI51QWTg57JOvhs0dUgv8fldDyVyYjnqLdX573E/9UFOms8ZGdViFYFA8ZB oLVAapBjq97pdVlzZc4FHIxFo5sSRv0+lonFzobuJmo8xn4puxTjsmZ3R03mMdqeQUmG H08IRJ41I+i2JLI9FU84MHlcKlEBmnPzFILEkTVOtD1iOz1cFt8N42+Sq1vLvbW8YVa/ DnNA== X-Gm-Message-State: ALoCoQl+JYKsnS1W0yBubfQNRFPwSU5CvcvDX8yDBGDHh931+wx6adUmn9/2fa4FbbR62IqItGEFRpnzy4iOUl5EeapV25QjFQ== MIME-Version: 1.0 X-Received: by 10.140.142.206 with SMTP id 197mr8916466qho.77.1449619044209; Tue, 08 Dec 2015 15:57:24 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.198.219 with HTTP; Tue, 8 Dec 2015 15:57:24 -0800 (PST) In-Reply-To: <20151208210031.62812.qmail@ary.lan> References: <20151208210031.62812.qmail@ary.lan> Date: Tue, 8 Dec 2015 15:57:24 -0800 X-Google-Sender-Auth: SXNq6PW5A3-XtaMhjV_1mUikWkI Message-ID: From: "Kurt Andersen (b)" To: John Levine Content-Type: multipart/alternative; boundary=001a11373a7a30acd805266bbc4f Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 08 Dec 2015 23:57:35 -0000 --001a11373a7a30acd805266bbc4f Content-Type: text/plain; charset=UTF-8 On Tue, Dec 8, 2015 at 1:00 PM, John Levine wrote: > >I can put together an appendix with some examples. I was thinking that > >having a better explanation would provide more value so I guess I got your > >suggestion backwards :-) > > I'd prefer that you post the current version of the draft so we can > see what the context is. Draft revisions are cheap, posting three in > a week if there are changes is not unreasonable. > > R's, > John > -13 has now been posted with these changes in full context. --Kurt --001a11373a7a30acd805266bbc4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 8, 2015 at 1:00 PM, John Levine <johnl@taugh.com> wrot= e:
>I can put togethe= r an appendix with some examples. I was thinking that
>having a better explanation would provide more value so I guess I got y= our
>suggestion backwards :-)

I'd prefer that you post the current version of the draft so we = can
see what the context is.=C2=A0 Draft revisions are cheap, posting three in<= br> a week if there are changes is not unreasonable.

R's,
John

-13 has now been po= sted with these changes in full context.
--Kurt
--001a11373a7a30acd805266bbc4f-- From nobody Wed Dec 9 08:03:48 2015 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 672061AD0B4; Tue, 8 Dec 2015 15:56:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151208235650.16949.5186.idtracker@ietfa.amsl.com> Date: Tue, 08 Dec 2015 15:56:50 -0800 Archived-At: X-Mailman-Approved-At: Wed, 09 Dec 2015 08:03:47 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-13.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 23:56:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF. Title : Interoperability Issues Between DMARC and Indirect Email Flows Authors : Franck Martin Eliot Lear Tim Draegen Elizabeth Zwicky Kurt Andersen Filename : draft-ietf-dmarc-interoperability-13.txt Pages : 23 Date : 2015-12-08 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 9 09:19:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BC01A00E0 for ; Wed, 9 Dec 2015 09:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.599 X-Spam-Level: ** X-Spam-Status: No, score=2.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 xCEeJYzkWD8T for ; Wed, 9 Dec 2015 09:19:19 -0800 (PST) Received: from turnbull.sk.tsukuba.ac.jp (turnbull.sk.tsukuba.ac.jp [130.158.96.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC301A00DA for ; Wed, 9 Dec 2015 09:19:18 -0800 (PST) Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1a6iOZ-0003IC-E5; Thu, 10 Dec 2015 02:19:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22120.25235.362274.401994@turnbull.sk.tsukuba.ac.jp> Date: Thu, 10 Dec 2015 02:19:15 +0900 From: "Stephen J. Turnbull" To: "Kurt Andersen (b)" In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" 698a9aa86de4 XEmacs Lucid (x86_64-apple-darwin14.5.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false Archived-At: Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 09 Dec 2015 17:19:22 -0000 Kurt Andersen (b) writes: > Proposed rework: I'll look at -13 later. Right now work is scrambling my brain so want to write this while I'm thinking of it. Basically, I find the wording too technology-oriented, making it difficult for me to see the actual problem domain. As I see it, unlike the specifications it discusses which address implementers, this draft addresses less technical admins as well as the implementer/admins who hang out on this list. (Eg, I'd like to be able to quote chapter and verse on Mailman-Users.) Disclaimer: All suggestions are written in my dialect and style in the hope that they will be useful in some part. I don't expect them to be adopted verbatim (and they might look weird in context anyway). > 2.1. Identifier Alignment > > DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message > source validation. The DMARC [RFC7489] mechanism refers to source > domains that are validated by DKIM or SPF as Authenticated > Identifiers. I would add The Authenticated Identifiers defined by these specifications need bear no relationship whatsoever to the content provided by the author of the message or even to the system which injected the message, though they usually do. > DMARC requires an Authenticated Identifier to be related to the > domain found in the message's RFC5322.from header field > [RFC5322]. This relationship is referred to as Identifier > Alignment. I would substitute DMARC adopts these definitions, and further requires a relationship called "Identifier Alignment" between at least one of the Authenticated Identifiers and the domain found in the message's RFC5322.from header field[RFC5322]. > DMARC allows for Identifier Alignment to be achieved in two different > modes: strict and relaxed. Strict mode requires an exact match of > either of the Authenticated Identifiers to the message's RFC5322.from > header field [RFC5322]. Relaxed mode allows for Identifier Alignment > if Authenticated Identifiers and the message's RFC5322.from header > field [RFC5322] share the same Organizational Domain. In general, > interoperability issues between strict and relaxed modes are the same, > with >From the Picky-Picky Department: There are no interoperability issues between strict and relaxed modes, except that the receiver must implement and select the correct mode as chosen by the sender. Better strict and relaxed modes exhibit very similar interoperability issues, but > strict mode constraining the application of possible solutions. constraining -> constrains. I prefer "applicability" to "application" slightly. Also, DMARC p=reject used for non-transactional mail is a problem without real solutions at present. The best we can do is mitigate. > The mitigations described in this document generally require a relaxed > mode of Identifier Alignment. "the relaxed mode". Mention "multiple RFC5322.from domains" issue here? E.g., RFC 5322 permits only one From header field, but it may contain multiple addresses [mailboxes?]. Since DKIM requires only one valid signature, if the domains differ, an attacker could add their domain to the RFC5322.from field, provide arbitrary new content, and sign the message. Therefore, DMARC chooses to require that there be only one domain in the RFC5322.from field, and in practice, since multiple addresses that field are extremely rare, implementations may require a single address. I forget how that last came down. Maybe DMARC itself now requires a single address. > 2.1.1. DKIM Identifier(s) > > DKIM provides a cryptographic means for one or more domain identifier > to be associated with a particular message. As a standalone technology > DKIM identifiers are not required to be relevant to the content of a >From the Picky-Picky Department: At least in my dialect of English, the DKIM identifiers are never "relevant to" the content. How about "consistent with"? > message. However, for a DKIM identifier to align in DMARC, the signing > domain of a valid signature must be part of the same Organizational > Domain as the domain in the RFC5322.from header field [RFC5322]. > > In addition, DKIM allows for the possibility of multiple valid > signatures. The DMARC mechanism will process Authenticated Identifiers > that are based on DKIM signatures until an aligned Authenticated > Identifier is found (if any). However, operational experience has > shown that some implementations have difficulty processing multiple > signatures. The impact on DMARC processing is clear: implementations > that cannot process multiple DKIM signatures may incorrectly flag > messages as "failing DMARC" and erroneously apply DMARC based policy > to otherwise conforming messages. Picky-Picky Department: Isn't the DMARC terminology "failing Identifier Alignment" for the case where no Authenticated Indentifier is found as well as when there's a mismatch? > > 2.1.2. SPF Identifier(s) > > The SPF specification [RFC7208] defines two Authenticated Identifiers > for each message. These identifiers derive from: > > a. the RFC5321.mailfrom [RFC5321] domain, and > b. the RFC5321.HELO/EHLO SMTP domain. > > In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is > defined to be based on RFC5321.mailfrom unless that value is absent > (as in the case of "bounce" messages) in which case, the second > (RFC5321.HELO/EHLO) identifier value is used. This "fallback" > definition has occasionally been misunderstood by senders since > "bounce" messages are often an "automatic" feature of MTA software. I don't understand the last sentence, specifically why automated bounces would lead to a misunderstanding of SPF identifiers, and who the "sender" is (author? RFC5322.sender?) Regards, Steve From nobody Thu Dec 10 23:05:49 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DAC1A6F2E for ; Thu, 10 Dec 2015 23:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 4eUkXDJhSpVS for ; Thu, 10 Dec 2015 23:05:45 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44DC1A1AB5 for ; Thu, 10 Dec 2015 23:05:44 -0800 (PST) Received: by vkha189 with SMTP id a189so110290489vkh.2 for ; Thu, 10 Dec 2015 23:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n0Plnrxjxwwyb+dlWGT6tUOhSfXN+gpGqUccFO1dSOE=; b=RQm9VozOGbdumHhJDAjoZA5a6pCkaQKWpmmnnoF5lGbZHLF2HcKBcS3skzmHJnKIcB gwoio1cPN7WqKQilAmfi3crQt1V499RlhtiFpuQKNubALIkDjWYL4ar0QL4UsciPjJwu CZlbEaULU7XurY/lg/3Lhz5nr2zoa1xPa/wTzWrDOEo8+w+AW9GQprz46IKVNkMdmIGW X6MrZdGzjPCNFWcNPBlfTW9KI4RxccXK4Jpvt4XNH5t9HN8t84hy2cbS/B0oLckNArWz nxfy+aGOvklFfcZvgJFtrpTlIFZnjSE2SSax8SI1YRwlVUAzLM9SttAnYQsShN7Tg3l1 43dw== MIME-Version: 1.0 X-Received: by 10.31.7.11 with SMTP id 11mr14119632vkh.155.1449817543974; Thu, 10 Dec 2015 23:05:43 -0800 (PST) Received: by 10.103.83.73 with HTTP; Thu, 10 Dec 2015 23:05:43 -0800 (PST) In-Reply-To: <22120.25235.362274.401994@turnbull.sk.tsukuba.ac.jp> References: <22120.25235.362274.401994@turnbull.sk.tsukuba.ac.jp> Date: Thu, 10 Dec 2015 23:05:43 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=001a1143d96eb2aae7052699f32a Archived-At: Cc: "dmarc@ietf.org" , "Kurt Andersen \(b\)" Subject: Re: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Dec 2015 07:05:48 -0000 --001a1143d96eb2aae7052699f32a Content-Type: text/plain; charset=UTF-8 On Wed, Dec 9, 2015 at 9:19 AM, Stephen J. Turnbull wrote: > > > 2.1. Identifier Alignment > > > > DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message > > source validation. The DMARC [RFC7489] mechanism refers to source > > domains that are validated by DKIM or SPF as Authenticated > > Identifiers. > > I would add > > The Authenticated Identifiers defined by these specifications need > bear no relationship whatsoever to the content provided by the > author of the message or even to the system which injected the > message, though they usually do. > Do we think that's necessary here, or is that same advice which is (I'm fairly sure) present in RFC6376 and RFC7208 sufficient? I guess another way to word that is: How independent is this work from full understanding of those? I suppose in the end it can't hurt to be sure and repeat this caveat here. > > 2.1.2. SPF Identifier(s) > > > > The SPF specification [RFC7208] defines two Authenticated Identifiers > > for each message. These identifiers derive from: > > > > a. the RFC5321.mailfrom [RFC5321] domain, and > > b. the RFC5321.HELO/EHLO SMTP domain. > > > > In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is > > defined to be based on RFC5321.mailfrom unless that value is absent > > (as in the case of "bounce" messages) in which case, the second > > (RFC5321.HELO/EHLO) identifier value is used. This "fallback" > > definition has occasionally been misunderstood by senders since > > "bounce" messages are often an "automatic" feature of MTA software. > > I don't understand the last sentence, specifically why automated > bounces would lead to a misunderstanding of SPF identifiers, and who > the "sender" is (author? RFC5322.sender?) > I would also change "In the SPF" to "In that", since the context is established in the first sentence. I agree, I'm not sure what that second sentence says at all. -MSK --001a1143d96eb2aae7052699f32a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 9, 2015 at 9:19 AM, Stephen J. Turnbull <ste= phen@xemacs.org> wrote:

=C2=A0> 2.1. Identifier Alignment
=C2=A0>
=C2=A0> DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform mess= age
=C2=A0> source validation. The DMARC [RFC7489] mechanism refers to sourc= e
=C2=A0> domains that are validated by DKIM or SPF as Authenticated
=C2=A0> Identifiers.

I would add

=C2=A0 =C2=A0 The Authenticated Identifiers defined by these specifications= need
=C2=A0 =C2=A0 bear no relationship whatsoever to the content provided by th= e
=C2=A0 =C2=A0 author of the message or even to the system which injected th= e
=C2=A0 =C2=A0 message, though they usually do.

Do we think that's necessary here, or is that same advice which= is (I'm fairly sure) present in RFC6376 and RFC7208 sufficient?=C2=A0 = I guess another way to word that is: How independent is this work from full= understanding of those?

I suppose in the end it can'= t hurt to be sure and repeat this caveat here.
=C2=A0
=C2=A0 > 2.1.2. SPF Identifier(s)
=C2=A0>
=C2=A0> The SPF specification [RFC7208] defines two Authenticated Identi= fiers
=C2=A0> for each message. These identifiers derive from:
=C2=A0>
=C2=A0>=C2=A0 =C2=A0 =C2=A0a. the RFC5321.mailfrom [RFC5321] domain, and=
=C2=A0>=C2=A0 =C2=A0 =C2=A0b. the RFC5321.HELO/EHLO SMTP domain.
=C2=A0>
=C2=A0> In the SPF specification, the RFC7208.MAILFROM [RFC7208] value i= s
=C2=A0> defined to be based on RFC5321.mailfrom unless that value is abs= ent
=C2=A0> (as in the case of "bounce" messages) in which case, t= he second
=C2=A0> (RFC5321.HELO/EHLO) identifier value is used. This "fallbac= k"
=C2=A0> definition has occasionally been misunderstood by senders since<= br> =C2=A0> "bounce" messages are often an "automatic" f= eature of MTA software.

I don't understand the last sentence, specifically why automated=
bounces would lead to a misunderstanding of SPF identifiers, and who
the "sender" is (author? RFC5322.sender?)
I would also change "In the SPF" to "In that&qu= ot;, since the context is established in the first sentence.

<= div>I agree, I'm not sure what that second sentence says at all.
-MSK
--001a1143d96eb2aae7052699f32a-- From nobody Sat Dec 12 00:19:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEB01A1BD1 for ; Sat, 12 Dec 2015 00:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 OO0OVlBEoBcg for ; Sat, 12 Dec 2015 00:19:06 -0800 (PST) Received: from turnbull.sk.tsukuba.ac.jp (turnbull.sk.tsukuba.ac.jp [130.158.96.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9281A1BCD for ; Sat, 12 Dec 2015 00:19:05 -0800 (PST) Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1a7fOP-0001TA-Ey; Sat, 12 Dec 2015 17:19:01 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22123.55413.422699.900910@turnbull.sk.tsukuba.ac.jp> Date: Sat, 12 Dec 2015 17:19:01 +0900 From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <22120.25235.362274.401994@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 698a9aa86de4 XEmacs Lucid (x86_64-apple-darwin14.5.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false Archived-At: Cc: "Kurt Andersen \(b\)" , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 12 Dec 2015 08:19:09 -0000 Murray S. Kucherawy writes: > On Wed, Dec 9, 2015 at 9:19 AM, Stephen J. Turnbull wrote: >> I would add >> >> The Authenticated Identifiers defined by these specifications need >> bear no relationship ... > Do we think that's necessary here, or is that same advice which is > (I'm fairly sure) present in RFC6376 and RFC7208 sufficient? I > guess another way to word that is: How independent is this work > from full understanding of those? I've already expressed my opinion, but I hope I'll be forgiven a gloss on my previous words. In Mailman we have three levels of "ownership": *list*, (virtual) *domain*, and *site* (host system). Mailman list and domain owners can choose their mitigation policies, and they need a guide. I hope this BCP can be written in a way that allows them to identify their own use case, and choose an appropriate mitigation. Needless to say, almost all of them would find RFCs 6376 and 7208 useless, and many site owners are in the same boat -- they don't really understand MTAs, MIME, HTML (sorry, but yeah that's necessary), or digital signatures, and most are kinda fuzzy on the roles of MUAs and the email header. Mailman has already pretty much decided what mitigations we can and will implement; I haven't seen anything else we need to do. I suspect most indirect mailflow managers are in the same boat. It seems to me that more than the implementers themselves, it's going to be system managers choosing implementations and channel managers choosing behaviors who need refer to, and will benefit from, this BCP. Steve