From nobody Thu Nov 5 18:09:48 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 4E6151B2BC0 for ; Thu, 5 Nov 2015 18:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, NORMAL_HTTP_TO_IP=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 eeHAWWhXuEQb for ; Thu, 5 Nov 2015 18:09:46 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 E4B061B2BF3 for ; Thu, 5 Nov 2015 18:09:45 -0800 (PST) Received: by qgec40 with SMTP id c40so21252214qge.2 for ; Thu, 05 Nov 2015 18:09:45 -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:cc:content-type; bh=iquJJnRIsuxy3VKWjgiteoRpB8S1xa/rvOn9eQ3cQCc=; b=U1Jl7lzrKWZyqik6Xvy1RdA1Wp/lzaEWoapC59bfBiUX7VDZrdBXwzRiAzWDzAyXYp DwXHJaFbhf4G0ergAPn4GFdrFIPfJvvNzxaGncEAmbn3MJUQp8k9oAgH5QeDL4Q/QECh njma05njUL9wtObVbPLYrAG+tPJ9aubwBqRvU= 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:cc:content-type; bh=iquJJnRIsuxy3VKWjgiteoRpB8S1xa/rvOn9eQ3cQCc=; b=fNbq26Ylpv01ZTys4qbjO05ye9GOc3IxQhaMxpp1N5EtLPqBksM0uieaF4a63ToWYX yys+O5jAtlxvq8OLy2+LYSbokKIPE5SJG0Ht/uVqVR1pjA3eNorU3ihPtAijgZ5gQyyl 1J+X8YXK8kXA20I2gJt6HN8ZB4gvpUn1fLHNIZCPGP5LiIMj1forPLQZAzWBbEoS3uUr 9ZNQ4NaDfqCHF6WHzl70mwRlPIagKsaBRlJOksXZHsFOPf3tFyX5rpCUqPC1JxBBMYBe 38I/YsU/I2DK8u3bdYernOpJtSme8qwv8U7fRSriL0fo3FEFk2H+QzOq6mNUgL5bO5YA PxLg== X-Gm-Message-State: ALoCoQn3qFKKuJz2K6HC8N4IukaoyXv0BkhoyNADMXvPidb1idWrknbtFd9/754WqaDL1XbsJNaJ MIME-Version: 1.0 X-Received: by 10.140.238.139 with SMTP id j133mr11488790qhc.78.1446775785066; Thu, 05 Nov 2015 18:09:45 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.198.219 with HTTP; Thu, 5 Nov 2015 18:09:45 -0800 (PST) Date: Thu, 5 Nov 2015 18:09:45 -0800 X-Google-Sender-Auth: -B7jkH20dOkT2-ffGQXcDKMfQqQ Message-ID: From: "Kurt Andersen (b)" To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a1135c8e0bd2a3e0523d5bc0d Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 06 Nov 2015 02:09:47 -0000 --001a1135c8e0bd2a3e0523d5bc0d Content-Type: text/plain; charset=UTF-8 Removing the editorial fixes which I've incorporated into the recently posted -09, I'm responding inline below to the discussion questions. On Sat, Oct 31, 2015 at 4:56 AM, Murray S. Kucherawy wrote: > > Section 4.1.3.3: > > - Is that fist bullet talking about things like "On behalf of"? Also, > what sort of collision is the concern here? > Not the "on behalf of" as much as the practice of taking the address part and putting it into the display name while possibly tweaking the address part to be "invalid". Section 4.2: > > I'm generally unsure about this section. It will eventually (sooner than > later) refer to a number of expired documents. It might be more helpful to > the reader to just summarize the idea behind each approach in a paragraph > rather than forcing the reader to chase down specific expired I-Ds. > I don't see a good way to avoid referring to (eventually) expired I-Ds. That's the best way to catalog the ideas, but I did take your suggestions on rephrasing the intent of some of them into some new wording. --Kurt --001a1135c8e0bd2a3e0523d5bc0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Removing the editorial fixes which I've incorporated i= nto the recently posted -09, I'm responding inline below to the discuss= ion questions.

On Sat, Oct 31, 2015 at 4:56 AM, Murray S. Kucherawy <superuser@gm= ail.com> wrote:

Sectio= n 4.1.3.3:

- Is that fist bullet talking about things like "On behalf of"= ?=C2=A0 Also, what sort of collision is the concern here?

Not the "on behalf of"= as much as the practice of taking the address part and putting it into the= display name while possibly tweaking the address part to be "invalid&= quot;.

Section 4.2:

I'm generally unsure about this section.=C2=A0 It will eventua= lly (sooner than later) refer to a number of expired documents.=C2=A0 It mi= ght be more helpful to the reader to just summarize the idea behind each ap= proach in a paragraph rather than forcing the reader to chase down specific= expired I-Ds.

= I don't see a good way to avoid referring to (eventually) expired I-Ds.= That's the best way to catalog the ideas, but I did take your suggesti= ons on rephrasing the intent of some of them into some new wording.
--Kurt
--001a1135c8e0bd2a3e0523d5bc0d-- From nobody Thu Nov 5 19:59:04 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 AB1501A8851 for ; Thu, 5 Nov 2015 19:59:02 -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 9BRbHpPUVKFr for ; Thu, 5 Nov 2015 19:59:00 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 687891A884E for ; Thu, 5 Nov 2015 19:59:00 -0800 (PST) Received: by ykek133 with SMTP id k133so169557417yke.2 for ; Thu, 05 Nov 2015 19:58:59 -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=ZpHSctpIE5g5O+cEmTsrylg2O5WhKOmOEPQRw6Xz2Zw=; b=VojoWA0rcYRgv1dE6MWSLQB0wpgLY7mnuEe8yP0ayCPWq/nugYie5A6TGcmlYfxxaj nNLEpCW0Ht+bTxr9eceMCIy8sM9V0FLFvkVsGXjtKDPWkIppzYgalUThpF3ZwAyIxuPo +livcj8jpkobVHERyXD/Kqm6Ipk0NRnAeDSzyO1v0N7pw5qIUckEGh7RSzGGw8buficH mkLUDbQ8OJXtl9H2efrqxrHl3z/kVra3EOQs2Tv6OqKdg90Md3sWG349aqGKYrcox1PU 4MTwYT4EcYQEjhJ+SKAy0rBozA5YYfvAMJhyUe/XrjJ1auMvx6VKFdU+PF6QO63IoO4e EXrg== MIME-Version: 1.0 X-Received: by 10.31.41.149 with SMTP id p143mr3743816vkp.144.1446782339752; Thu, 05 Nov 2015 19:58:59 -0800 (PST) Received: by 10.103.83.73 with HTTP; Thu, 5 Nov 2015 19:58:59 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Nov 2015 12:58:59 +0900 Message-ID: From: "Murray S. Kucherawy" To: "Kurt Andersen (b)" Content-Type: multipart/alternative; boundary=001a113ee6a46da7cb0523d74380 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 06 Nov 2015 03:59:02 -0000 --001a113ee6a46da7cb0523d74380 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 6, 2015 at 11:09 AM, Kurt Andersen (b) wrote: > > > Section 4.2: >> >> I'm generally unsure about this section. It will eventually (sooner than >> later) refer to a number of expired documents. It might be more helpful to >> the reader to just summarize the idea behind each approach in a paragraph >> rather than forcing the reader to chase down specific expired I-Ds. >> > > I don't see a good way to avoid referring to (eventually) expired I-Ds. > That's the best way to catalog the ideas, but I did take your suggestions > on rephrasing the intent of some of them into some new wording. > I don't think you actually need to cite I-Ds just to enumerate the general approaches that have been proposed. Perhaps use this for the bullet list: o Third party authorization schemes provide ways to extend identifier alignment under control of the domain owner. o A way to canonicalize messages that transit mailing lists so that their alterations can be isolated from the original signed content. o A way to record message transformations applied at each hop so they can be reversed and the original signed content recovered. o "Conditional" DKIM signatures, whereby the author domain indicates its signature is only good if accompanied by a signature from an expected downstream relay. o Mechanisms to extend Authentication-Results [RFC7601] to multiple hops, creating a provable chain of custody as well as a view to message authentication results at each handling step. -MSK --001a113ee6a46da7cb0523d74380 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 6, 2015 at 11:09 AM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:


Section 4.2:

I'm generally unsure about this section.=C2=A0 It will eventual= ly (sooner than later) refer to a number of expired documents.=C2=A0 It mig= ht be more helpful to the reader to just summarize the idea behind each app= roach in a paragraph rather than forcing the reader to chase down specific = expired I-Ds.

I= don't see a good way to avoid referring to (eventually) expired I-Ds. = That's the best way to catalog the ideas, but I did take your suggestio= ns on rephrasing the intent of some of them into some new wording.

I don't think you actually need to cite I-Ds just to enumerate = the general approaches that have been proposed.=C2=A0 Perhaps use this for = the bullet list:

o Third party authorization schemes prov= ide ways to extend identifier alignment under control of the domain owner.<= br>
o A way to canonicalize messages that transit mailing lis= ts so that their alterations can be isolated from the original signed conte= nt.

o A way to record message transformations = applied at each hop so they can be reversed and the original signed content= recovered.

o "Conditional" DKIM signatures, whereby the a= uthor domain indicates its signature is only good if accompanied by a signa= ture from an expected downstream relay.

o Mechanisms to extend Authe= ntication-Results [RFC7601] to multiple hops, creating a provable chain of = custody as well as a view to message authentication results at each handlin= g step.

-MSK
--001a113ee6a46da7cb0523d74380-- From nobody Fri Nov 6 13:37: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 DDC611A21C2 for ; Fri, 6 Nov 2015 13:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 qY92sMrz_5dQ for ; Fri, 6 Nov 2015 13:37:55 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id BEFFE1A21C1 for ; Fri, 6 Nov 2015 13:37:54 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 3368B563EA1; Fri, 6 Nov 2015 15:37:54 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 27273602A6; Fri, 6 Nov 2015 15:37:54 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cU7vr7Dcx-Hn; Fri, 6 Nov 2015 15:37:53 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id C6872602B2; Fri, 6 Nov 2015 15:37:53 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com C6872602B2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1446845873; bh=njKdS8HIXFXn0PFAxmFUcUx78b9jcWoJ0nh7e9tu3bs=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=lD6MjqQZS0jZl7ENsP1BPkI3g4PayWHqlhmjolWBkej5+DA10q9mVQtkETzQExEDE v23E93YjBU/9tPotddKYfwTVTf2QyXbHsw/hNakzXEN+RGnZiLuTkcxc0yqTn+Zkm9 aOXJBCD75a+Jl8RT/j6ZlGtRidqGyhLUf5FMAyD8= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A5163602B0; Fri, 6 Nov 2015 15:37:53 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rhEZrT68m62t; Fri, 6 Nov 2015 15:37:53 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 7AC95602A6; Fri, 6 Nov 2015 15:37:53 -0600 (CST) Date: Fri, 6 Nov 2015 15:37:51 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1698815655.77932.1446845871633.JavaMail.zimbra@peachymango.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_77931_532531872.1446845871631" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF41 (Mac)/8.0.5_GA_5839) Thread-Topic: Responses to comments on draft-ietf-dmarc-interoperability-08.txt Thread-Index: ltIz4kMFUjywpWh7u9g4bCi7STkqwA== Archived-At: Cc: dmarc@ietf.org, "Kurt Andersen \(b\)" Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 06 Nov 2015 21:37:58 -0000 ------=_Part_77931_532531872.1446845871631 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Kurt Andersen (b)" > Cc: dmarc@ietf.org > Sent: Thursday, November 5, 2015 7:58:59 PM > Subject: Re: [dmarc-ietf] Responses to comments on > draft-ietf-dmarc-interoperability-08.txt > On Fri, Nov 6, 2015 at 11:09 AM, Kurt Andersen (b) < kboth@drkurt.com > > wrote: > > > Section 4.2: > > > > > > I'm generally unsure about this section. It will eventually (sooner than > > > later) refer to a number of expired documents. It might be more helpful > > > to > > > the reader to just summarize the idea behind each approach in a paragraph > > > rather than forcing the reader to chase down specific expired I-Ds. > > > > > I don't see a good way to avoid referring to (eventually) expired I-Ds. > > That's the best way to catalog the ideas, but I did take your suggestions > > on > > rephrasing the intent of some of them into some new wording. > > I don't think you actually need to cite I-Ds just to enumerate the general > approaches that have been proposed. Perhaps use this for the bullet list: > o Third party authorization schemes provide ways to extend identifier > alignment under control of the domain owner. > o A way to canonicalize messages that transit mailing lists so that their > alterations can be isolated from the original signed content. > o A way to record message transformations applied at each hop so they can be > reversed and the original signed content recovered. > o "Conditional" DKIM signatures, whereby the author domain indicates its > signature is only good if accompanied by a signature from an expected > downstream relay. > o Mechanisms to extend Authentication-Results [RFC7601] to multiple hops, > creating a provable chain of custody as well as a view to message > authentication results at each handling step. While the I-D will likely expires they will not be removed from the website, so references will still work, so I don't see as that bad that they are properly referenced in this document. I however agree we should provide a quick summary for people that do not need the details. ------=_Part_77931_532531872.1446845871631 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable




<= hr id=3D"zwchr">
= From: "Murray S. Kucherawy" <superuser@gmail.com>
To: "Kurt Andersen (b)" <kboth@drkurt.com>
Cc: dmarc@ietf.org=
Sent: Thursday, November 5, 2015 7:58:59 PM
Subject: R= e: [dmarc-ietf] Responses to comments on      = ;  draft-ietf-dmarc-interoperability-08.txt

On Fri, Nov 6, 2015 at 11:09 AM, Kurt Andersen (b) <kboth@dr= kurt.com> wrote:


Section 4.2:

<= /div>
I'm generally unsure about this section.  It will even= tually (sooner than later) refer to a number of expired documents.  It= might be more helpful to the reader to just summarize the idea behind each= approach in a paragraph rather than forcing the reader to chase down speci= fic expired I-Ds.

I don't see a good way to avoid referring to (eventually) expired I-Ds. = That's the best way to catalog the ideas, but I did take your suggestions o= n rephrasing the intent of some of them into some new wording.

I don't think you ac= tually need to cite I-Ds just to enumerate the general approaches that have= been proposed.  Perhaps use this for the bullet list:

o Third party authorization schemes provide ways to extend id= entifier alignment under control of the domain owner.

o A way to canonicalize messages that transit mailing lists so that= their alterations can be isolated from the original signed content.

o A way to record message transformations applied at= each hop so they can be reversed and the original signed content recovered= .

o "Conditional" DKIM signatures, whereby the author dom= ain indicates its signature is only good if accompanied by a signature from= an expected downstream relay.

o Mechanisms to extend Aut= hentication-Results [RFC7601] to multiple hops, creating a provable chain o= f custody as well as a view to message authentication results at each handl= ing step.

While= the I-D will likely expires they will not be removed from the website, so = references will still work, so I don't see as that bad that they are proper= ly referenced in this document. I however agree we should provide a quick s= ummary for people that do not need the details.

<= /html> ------=_Part_77931_532531872.1446845871631-- From nobody Sat Nov 7 16:36:26 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 89E381B3807 for ; Sat, 7 Nov 2015 16:36:25 -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 YlkDC9ezGZRh for ; Sat, 7 Nov 2015 16:36:24 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 32D5F1B3806 for ; Sat, 7 Nov 2015 16:36:24 -0800 (PST) Received: by vkfw189 with SMTP id w189so36938237vkf.2 for ; Sat, 07 Nov 2015 16:36:23 -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=ZgWfzVymjd4aLU2vCSmuE+Ly+Euzj8QKsGQHZHtSyLs=; b=wHqnBjfXOhWwNKYrx7N1sdzuP7NUai8PuBFWc8tzh1ddQzpMdGwQxfDPiKfC3qXlfQ jTmjWhqccTWhYqwJMKCHOYH8GIRh6TfZBRNZnuyiZkYQqYRWknbsQ1O83G8/6i2PlT5o nYmsSpwTy1j33eDk8nBUVG1FRRDmHARtWfCxr60gVzTEx2oMRjeNPcQKCaNcc/P3z67d 3YnxlcMoBrrT45yOu1p6/a3MooJTsTHIWgKkmpPBxCL5joHRElZdduKyzoDL9RwUKcYT xQ5uxI0M6DEeAxg9bKhfQi2VX9RYsEbai22LlvNlfjJng2jCzskBVPlF2t95q7vvDz9h ARDQ== MIME-Version: 1.0 X-Received: by 10.31.2.18 with SMTP id 18mr701751vkc.131.1446942983153; Sat, 07 Nov 2015 16:36:23 -0800 (PST) Received: by 10.103.83.73 with HTTP; Sat, 7 Nov 2015 16:36:23 -0800 (PST) In-Reply-To: <1698815655.77932.1446845871633.JavaMail.zimbra@peachymango.org> References: <1698815655.77932.1446845871633.JavaMail.zimbra@peachymango.org> Date: Sat, 7 Nov 2015 16:36:23 -0800 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=001a11466c2e856c580523fcaa59 Archived-At: Cc: "dmarc@ietf.org" , "Kurt Andersen \(b\)" Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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: Sun, 08 Nov 2015 00:36:25 -0000 --001a11466c2e856c580523fcaa59 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin wrote: > While the I-D will likely expires they will not be removed from the > website, so references will still work, so I don't see as that bad that > they are properly referenced in this document. I however agree we should > provide a quick summary for people that do not need the details. > On the flipside, I don't see what value they add; the ones that gain consensus will be published in their own right, and the details of the ones that don't probably aren't interesting to later readers anyway. -MSK --001a11466c2e856c580523fcaa59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin <franc= k@peachymango.org> wrote:
While the= I-D will likely expires they will not be removed from the website, so refe= rences will still work, so I don't see as that bad that they are proper= ly referenced in this document. I however agree we should provide a quick s= ummary for people that do not need the details.

On the flipside, I don't se= e what value they add; the ones that gain consensus will be published in th= eir own right, and the details of the ones that don't probably aren'= ;t interesting to later readers anyway.

-MSK
--001a11466c2e856c580523fcaa59-- From nobody Sat Nov 7 21:01:04 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 29B321ADBFA for ; Sat, 7 Nov 2015 21:01:03 -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 9bEI76oyybgM for ; Sat, 7 Nov 2015 21:01:02 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 077AF1A87E7 for ; Sat, 7 Nov 2015 21:01:01 -0800 (PST) Received: by qgec40 with SMTP id c40so59741697qge.2 for ; Sat, 07 Nov 2015 21:01:01 -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:cc:content-type; bh=nKAoGzPFLvUFdvIQoP9aej+kOcUEj25ZvRvZYU/juqU=; b=P5nCJxOR7pp38WbKYbuCyX47yb2otJYi4ENZy3Gkh0Bhbmir9Djq/qAj0yrClrw2IY x9sH0P9bXpfcNYnKgvKVe2rpqapC4M0Dt+QOeQb+yNjD+NKf0ErUXFeitcs7p9cENmE2 xdzptlXfhBODC24fs+nCVwg99mSd4I/BHhn6U= 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:cc:content-type; bh=nKAoGzPFLvUFdvIQoP9aej+kOcUEj25ZvRvZYU/juqU=; b=NC5F6PO5ob+3jmIS+vRyWSiZaahLFqcccc+VHx1NDjvcOAa1oNKm4hXr1pWVFtabAp LX+2jciR3VDhAW3cTW5JcTZ+9BZwMQ4XtVJD5C3zQnbVq1n99IJAhhY9H4rUhfvspaB/ QGwhyu6cUBYIRt4uFLSWOznX2DH/XEPzzMmWaSoy1fIdL5ymrL4melIyTd1QjME9ieAO 2HYZnvP3a+Qn1Qe3+BUdi50p6ZHHGZIAdMJkZLdQbhqt1Vx+ES1v1JHsfLvh6IFo66AI TGtMcnq4lUeAyWysbki7MN3V16jhkiQLdA88qtgx8neMGu8ePHmfDhoOGWg8ansyCUCk pEVQ== X-Gm-Message-State: ALoCoQkPYaSCOZGukd3HWKji7Co5x3NbISrerVuoPhlNuywilC7geL/WzFf+InfHytTjKskrKuha MIME-Version: 1.0 X-Received: by 10.140.219.198 with SMTP id p189mr22953827qhb.80.1446958861071; Sat, 07 Nov 2015 21:01:01 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.198.219 with HTTP; Sat, 7 Nov 2015 21:01:01 -0800 (PST) Date: Sat, 7 Nov 2015 21:01:01 -0800 X-Google-Sender-Auth: Ji_CTANgHeh9fYev-Cnpwowmgbw Message-ID: From: "Kurt Andersen (b)" To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a1137258eeb510e0524005c80 Archived-At: Cc: "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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: Sun, 08 Nov 2015 05:01:03 -0000 --001a1137258eeb510e0524005c80 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 7, 2015 at 4:36 PM, Murray S. Kucherawy wrote: > On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin > wrote: > >> While the I-D will likely expires they will not be removed from the >> website, so references will still work, so I don't see as that bad that >> they are properly referenced in this document. I however agree we should >> provide a quick summary for people that do not need the details. >> > > On the flipside, I don't see what value they add; the ones that gain > consensus will be published in their own right, and the details of the ones > that don't probably aren't interesting to later readers anyway. > > -MSK > I'm OK either way. Tim, would you care to weigh in as the WG chair? It's an easy change to make and it would be nice to close out this milestone. What about demoting the I-D citations to an Appendix? --Kurt --001a1137258eeb510e0524005c80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 7, 2015 at 4:36 PM, Murray S. Kucherawy <su= peruser@gmail.com> wrote:
On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin <franck@pea= chymango.org> wrote:
While the I-D = will likely expires they will not be removed from the website, so reference= s will still work, so I don't see as that bad that they are properly re= ferenced in this document. I however agree we should provide a quick summar= y for people that do not need the details.

On the flipside, I don't = see what value they add; the ones that gain consensus will be published in = their own right, and the details of the ones that don't probably aren&#= 39;t interesting to later readers anyway.

-MSK

I'm OK either w= ay. Tim, would you care to weigh in as the WG chair? It's an easy chang= e to make and it would be nice to close out this milestone. What about demo= ting the I-D citations to an Appendix?

--Kurt
--001a1137258eeb510e0524005c80-- From nobody Sun Nov 8 18:40: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 4BD631B3E02 for ; Sun, 8 Nov 2015 18:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 RuReMCZlEh-P for ; Sun, 8 Nov 2015 18:40:44 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 DA40F1B3B63 for ; Sun, 8 Nov 2015 18:40:44 -0800 (PST) Received: by pacdm15 with SMTP id dm15so158718195pac.3 for ; Sun, 08 Nov 2015 18:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudev.net; s=s1; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=j/34OZCeol2RFsSNVvGO7SNYti4uBIsuOQUTbiQ6gyU=; b=ZyEH6O6kUtIpHINGGi0Evm7sP/fe//A5Ydjhu+e6fYa7WDJsk9GxW9cypM3OnhH3PY yO1tf0g2r99it3DQnfTBsghrZVICnMnpuwyITyJTfQbZNSLk0kvnlfUNXO36fmSXEbP4 565yM6YSNsVK0qOI1vji9JKfyD1/0dlwX97Pk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=j/34OZCeol2RFsSNVvGO7SNYti4uBIsuOQUTbiQ6gyU=; b=kPe5ad83RlBWflhXn5pbSEDhsHZ8+ItzK3B7LisFIWO+Z5kOz2GXFTyagfx453DY5n p55clPpFj5X0n42yJBb/dvySJ8rKFOe+bs9brtexvLm0RbrJAKSD2ZmbrjejY5ADQW1y 5rEZEFmpGUfnXlFFWE7y14eOq9zyljvsQ/5u8zyrJ2XlFeTsu3WwUqzamE9ZCuIYCaVo f1yZH9VJ7nOKQzwjOM9PoB5CrsP0DK9XuSV6VML0rAZi9OD+sDruxLowm1gHLgh7ZIoH 1qS05DLvdHhZqahQUcZGlqNi/y4JGSfa2o5vzBTVrJtGjtQwmpFVBZopwW8VkrE+5lJr PNJg== X-Gm-Message-State: ALoCoQkCsH/WJSx9O6FnLa0zGD08j8gZqw6Bzrt3iVuN+9Y8L+f7PtpYbuyf8PTm2Q3O0gKvKdxj X-Received: by 10.66.158.129 with SMTP id wu1mr8704088pab.146.1447036844466; Sun, 08 Nov 2015 18:40:44 -0800 (PST) Received: from [10.1.10.133] (c-73-222-37-236.hsd1.ca.comcast.net. [73.222.37.236]) by smtp.gmail.com with ESMTPSA id tp6sm12907991pbc.81.2015.11.08.18.40.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 08 Nov 2015 18:40:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_451B4B8D-77CD-41FF-8E16-3A5818B22961" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Draegen In-Reply-To: Date: Sun, 8 Nov 2015 18:40:40 -0800 Message-Id: References: To: "Kurt Andersen (b)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Franck Martin Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 09 Nov 2015 02:40:48 -0000 --Apple-Mail=_451B4B8D-77CD-41FF-8E16-3A5818B22961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 7, 2015, at 9:01 PM, Kurt Andersen (b) = wrote: > On the flipside, I don't see what value they add; the ones that gain = consensus will be published in their own right, and the details of the = ones that don't probably aren't interesting to later readers anyway. >=20 > -MSK >=20 > I'm OK either way. Tim, would you care to weigh in as the WG chair? = It's an easy change to make and it would be nice to close out this = milestone. What about demoting the I-D citations to an Appendix? Not as a WG Chair (as I don't think that matters here), but IMO going = with Murray's suggestion is wise.=20 The idea of moving the I-D citations to an Appendix is immediately = appealing, but I think in the future such an Appendix will just cause = confusion. =3D- Tim --Apple-Mail=_451B4B8D-77CD-41FF-8E16-3A5818B22961 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 7, 2015, at 9:01 PM, Kurt Andersen (b) <kboth@drkurt.com> = wrote:
On the flipside, I don't see what = value they add; the ones that gain consensus will be published in their = own right, and the details of the ones that don't probably aren't = interesting to later readers anyway.

-MSK

I'm OK either way. Tim, would you care = to weigh in as the WG chair? It's an easy change to make and it would be = nice to close out this milestone. What about demoting the I-D citations = to an Appendix?

Not as a WG Chair (as I don't think = that matters here), but IMO going with Murray's suggestion is = wise. 

The = idea of moving the I-D citations to an Appendix is immediately = appealing, but I think in the future such an Appendix will just cause = confusion.

=3D- = Tim


= --Apple-Mail=_451B4B8D-77CD-41FF-8E16-3A5818B22961-- From nobody Mon Nov 9 14:30:55 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 D7F9A1B8672 for ; Mon, 9 Nov 2015 14:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rnu22ADhwGkJ for ; Mon, 9 Nov 2015 14:30:53 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 23B631B8670 for ; Mon, 9 Nov 2015 14:30:53 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSWWQLRFKG002UC1@mauve.mrochek.com> for dmarc@ietf.org; Mon, 9 Nov 2015 14:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1447107951; bh=O0Jxcsea3yjuV4//Kj3h0y6xRrdU8SFuh31kcNpXTkw=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=jgKDL1xoiiXZYtPkv4V4VKVceKVbUYRkCTX4euHP/uPBndeVt/uY5WjoVpkcdPHm2 wRQmceIOc/vNmb+eJbtl8QeMd8O/tJdjxs2Ugf1/G2Zn5PVX4XR+x8K8mbVtIbu5o/ puvJlLMQmT3hvmd1ABm47PdTQiUlLaIF1JKk+r64= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSWW3XTCW001729W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Mon, 09 Nov 2015 14:25:49 -0800 (PST) From: ned+dmarc@mrochek.com Message-id: <01PSWWQKDGN401729W@mauve.mrochek.com> Date: Mon, 09 Nov 2015 14:16:42 -0800 (PST) In-reply-to: "Your message dated Sat, 07 Nov 2015 16:36:23 -0800" References: <1698815655.77932.1446845871633.JavaMail.zimbra@peachymango.org> To: "Murray S. Kucherawy" Archived-At: Cc: "Kurt Andersen \(b\)" , "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 09 Nov 2015 22:30:55 -0000 > On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin > wrote: > > While the I-D will likely expires they will not be removed from the > > website, so references will still work, so I don't see as that bad that > > they are properly referenced in this document. I however agree we should > > provide a quick summary for people that do not need the details. > > > On the flipside, I don't see what value they add; the ones that gain > consensus will be published in their own right, and the details of the ones > that don't probably aren't interesting to later readers anyway. Generally speaking IETF Consensus/Publication != Adoption and Use. There are a number of drafts that never made it to RFC that contain information on stuff that did in fact deploy. (Although the best example of this by far is actually in X.400, where one of the most widely used text bodypart types was only ever described in a preliminary draft.) That said, I'm dubious of the value of this section in a more general sense, since in-progress work is likely to shift and change in unexpected ways, which could easily make any description we provide more confusing than not. I personally would prefer to limit this sort of thing to descrptions of things we know are currently deployed to some degree. It's then up to future work to describe it's own interoperability issues, which is going to be a requirement for anything that makes it to RFC status anyhow. And yes, this does leave the door open for something that doesn't make it to RFC but does achieve some degree of deployment. But I think we have enough current issues to cover without trying to detail the nature of future ones. Ned From nobody Mon Nov 9 21:13:20 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 E3F801A8704; Thu, 5 Nov 2015 17:42:55 -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.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151106014255.12291.80341.idtracker@ietfa.amsl.com> Date: Thu, 05 Nov 2015 17:42:55 -0800 Archived-At: X-Mailman-Approved-At: Mon, 09 Nov 2015 21:13:19 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-09.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: Fri, 06 Nov 2015 01:42:56 -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-09.txt Pages : 23 Date : 2015-11-05 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-09 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 Nov 9 21:13:21 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 285D51B7D7A; Mon, 9 Nov 2015 06:44:05 -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.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151109144405.20923.12116.idtracker@ietfa.amsl.com> Date: Mon, 09 Nov 2015 06:44:05 -0800 Archived-At: X-Mailman-Approved-At: Mon, 09 Nov 2015 21:13:19 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-10.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: Mon, 09 Nov 2015 14:44:05 -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-10.txt Pages : 22 Date : 2015-11-09 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-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-10 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 Tue Nov 10 04:02:04 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 2DDA71A8ABA for ; Tue, 10 Nov 2015 04:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dQgzH84q9Ha3 for ; Tue, 10 Nov 2015 04:02:01 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02441A8AC9 for ; Tue, 10 Nov 2015 04:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1447156918; bh=ODuA6sbEJHA1f4dBDO5pL8QIiMlERmLG3xM4zvcshrw=; l=2523; h=Date:From:To:CC:References:In-Reply-To; b=g50DDVwmQSkUU8zAEy2kO+4dTjOJWi/0+HrvAabtLe3B0IQukT3Ryo4yZcLBhGSWj 7ZC0QR3FUv0P2aqliZ6QnuUuf2lteKUwH1a7hi+6cuz0hQjXByl2osAbFQZKpW4Knu N2YsmlmGXVA22xL8dCc3Yby/8FIOvmVuAWu8f0dY= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 10 Nov 2015 13:01:58 +0100 id 00000000005DC033.000000005641DCB6.0000674E Message-ID: <5641DCB6.3000002@tana.it> Date: Tue, 10 Nov 2015 13:01:58 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: ned+dmarc@mrochek.com, "Murray S. Kucherawy" References: <1698815655.77932.1446845871633.JavaMail.zimbra@peachymango.org> <01PSWWQKDGN401729W@mauve.mrochek.com> In-Reply-To: <01PSWWQKDGN401729W@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 10 Nov 2015 12:02:03 -0000 On Mon 09/Nov/2015 23:16:42 +0100 ned+dmarc wrote: >> On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin wrote: > >>> While the I-D will likely expires they will not be removed from the >>> website, so references will still work, so I don't see as that bad that >>> they are properly referenced in this document. I however agree we should >>> provide a quick summary for people that do not need the details. >>> > >> On the flipside, I don't see what value they add; the ones that gain >> consensus will be published in their own right, and the details of the ones >> that don't probably aren't interesting to later readers anyway. > > Generally speaking IETF Consensus/Publication != Adoption and Use. There are a > number of drafts that never made it to RFC that contain information on stuff > that did in fact deploy. (Although the best example of this by far is actually > in X.400, where one of the most widely used text bodypart types was only ever > described in a preliminary draft.) > > That said, I'm dubious of the value of this section in a more general sense, > since in-progress work is likely to shift and change in unexpected ways, > which could easily make any description we provide more confusing than not. Somewhat agree, unless we're able to say more on the reasons why a specific approach failed to get broad consensus/ adoption. I'm thinking of RFC6541, for which the text in -10 (of the transient nature of I-Ds) doesn't hold. OTOH, conditional signatures have been discussed for more than five years (my dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document (John's dkim-conditional-02) which would match the charter's "form of DKIM signature that is better able to survive transit through intermediaries". Can the WG coordinate publication of these two I-Ds? > I personally would prefer to limit this sort of thing to descriptions of > things we know are currently deployed to some degree. It's then up to > future work to describe it's own interoperability issues, which is going > to be a requirement for anything that makes it to RFC status anyhow. > > And yes, this does leave the door open for something that doesn't make it to > RFC but does achieve some degree of deployment. But I think we have enough > current issues to cover without trying to detail the nature of future ones. I'm neutral on mentioning ARC, dkim-transform, and dkim-canon-list. Ale From nobody Tue Nov 10 04:26:01 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 3BA331A9175 for ; Tue, 10 Nov 2015 04:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jyPlSBj8Y83B for ; Tue, 10 Nov 2015 04:25:59 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030F61A90DC for ; Tue, 10 Nov 2015 04:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1447158357; bh=4oDSyDIxwyQQpc3Z58S1KYc19xTzo4syHYfmtFayHIk=; l=1039; h=Date:From:To:References:In-Reply-To; b=bzjM6WYc0KOwZFTUJXvHUN83Mn9z4xzrjv3CxRPFLWd3JdWPynp5h7Hk66uG+kBcU FWAkQV9wqBp9I5Hhbm2uY/btQBNZ5f2BNEAhhabpQ6qH0KX/8LtBOa8R9k5NXcaTxN jqaZr4odVBxa//9hEU5drOcDJo8t3UEH0VbXK3yc= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 10 Nov 2015 13:25:57 +0100 id 00000000005DC044.000000005641E255.000067FC Message-ID: <5641E255.7060905@tana.it> Date: Tue, 10 Nov 2015 13:25:57 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20151109144405.20923.12116.idtracker@ietfa.amsl.com> In-Reply-To: <20151109144405.20923.12116.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Last minute additions to 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, 10 Nov 2015 12:26:00 -0000 On Mon 09/Nov/2015 15:44:05 +0100 internet-drafts wrote: > > [...] This document describes interoperability > issues between DMARC and indirect email flows. Possible methods for > addressing interoperability issues are presented. I'm sorry I'm not sure whether this issue on the following text was discussed already: The later modification may create issues because it is an invalid domain name, and some MTAs may pay particular attention to the validity of email addresses in RFC5322.From and the reputation of the domains present there. Lots of mail have ``From: "user@example.com" ''. In this case, changing that to ``From: "user@example.com" '' seems to be even worse than having an invalid domain. A display phrase that resembles an address which differs from the effective one is a clear sign of phishing, isn't it? Is it worth to add a warning? For a nit, shouldn't s/The later modification/The latter modification/? (I'm no native English speaker) Ale From nobody Tue Nov 10 06:38:29 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 3249E1B2BF5 for ; Tue, 10 Nov 2015 06:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 srPpoxtp-DB6 for ; Tue, 10 Nov 2015 06:38:26 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 527C91B2BF1 for ; Tue, 10 Nov 2015 06:38:26 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSXUJ6VGHS001JH5@mauve.mrochek.com> for dmarc@ietf.org; Tue, 10 Nov 2015 06:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1447166004; bh=Yc2lU6p8IDpO49l4vVpMTRg9njUzbWQ2wVAbVIIa7jo=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=ThW232TO4LyTTlY9NI9013QLwW9C4b7JXcTgY9Vym4QKO+jR/970uieAMy05tBK4s 2N+2HLUlwubYC4o3ordUF1czhzAGtOpHhUB+FWIrM4dbW99K5ev4yQGdT27MqYHNQi Mir5intWf/6UUqJuo2bGUe/nfj6449jh0faEINkg= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSXB005A6801729W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Tue, 10 Nov 2015 06:33:21 -0800 (PST) From: ned+dmarc@mrochek.com Message-id: <01PSXUJ573NO01729W@mauve.mrochek.com> Date: Tue, 10 Nov 2015 06:30:14 -0800 (PST) In-reply-to: "Your message dated Tue, 10 Nov 2015 13:01:58 +0100" <5641DCB6.3000002@tana.it> References: <1698815655.77932.1446845871633.JavaMail.zimbra@peachymango.org> <01PSWWQKDGN401729W@mauve.mrochek.com> <5641DCB6.3000002@tana.it> To: Alessandro Vesely Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , ned+dmarc@mrochek.com, Franck Martin Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 10 Nov 2015 14:38:27 -0000 > On Mon 09/Nov/2015 23:16:42 +0100 ned+dmarc wrote: > >> On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin wrote: > > > >>> While the I-D will likely expires they will not be removed from the > >>> website, so references will still work, so I don't see as that bad that > >>> they are properly referenced in this document. I however agree we should > >>> provide a quick summary for people that do not need the details. > >>> > > > >> On the flipside, I don't see what value they add; the ones that gain > >> consensus will be published in their own right, and the details of the ones > >> that don't probably aren't interesting to later readers anyway. > > > > Generally speaking IETF Consensus/Publication != Adoption and Use. There are a > > number of drafts that never made it to RFC that contain information on stuff > > that did in fact deploy. (Although the best example of this by far is actually > > in X.400, where one of the most widely used text bodypart types was only ever > > described in a preliminary draft.) > > > > That said, I'm dubious of the value of this section in a more general sense, > > since in-progress work is likely to shift and change in unexpected ways, > > which could easily make any description we provide more confusing than not. > Somewhat agree, unless we're able to say more on the reasons why a specific > approach failed to get broad consensus/ adoption. I'm thinking of RFC6541, for > which the text in -10 (of the transient nature of I-Ds) doesn't hold. > OTOH, conditional signatures have been discussed for more than five years (my > dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha > (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document (John's > dkim-conditional-02) which would match the charter's "form of DKIM signature > that is better able to survive transit through intermediaries". Can the WG > coordinate publication of these two I-Ds? THat's a good point. However, I have to say that while it would be nice in theory to include information about whatever conditional scheme ends up getting standardized in this document and/or what's in deployed code, deferring this document in order to make that possible isn't really feasible from a process standpoint. Ned From nobody Tue Nov 10 09:40:35 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 38D1A1B3B82 for ; Tue, 10 Nov 2015 09:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 RyKyC9We9psg for ; Tue, 10 Nov 2015 09:40:31 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29E01B3B10 for ; Tue, 10 Nov 2015 09:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w61ES8qU+qU+K3R8/XTKRiJMjmzDbHgprdUJ8A+todQ=; b=Qwp5j1EPu48gjdotrexEq1qlrcjdTSZhd1vZjiWg9n59YXpnoR7QMPEP2p3NgORA9FFQPP+IHK1qbYf4SZzPHcWfGm+Wm1jIW1t1gSpd1pQvNPVEI9TL3GLGEaITiRMN2IsOupHjMIoRXfLyZVIhJfA6VRN5NHkct75dA1EesR0= Received: from BN1PR03MB038.namprd03.prod.outlook.com (10.255.225.146) by BN1PR03MB038.namprd03.prod.outlook.com (10.255.225.146) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 17:40:27 +0000 Received: from BN1PR03MB038.namprd03.prod.outlook.com ([169.254.16.228]) by BN1PR03MB038.namprd03.prod.outlook.com ([169.254.16.228]) with mapi id 15.01.0318.003; Tue, 10 Nov 2015 17:40:27 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt Thread-Index: AQHRGNuErty4/DGhDkO4QSbV0OZ0p56RSUWAgAMBqmuAAOKNAIAAXhaQ Date: Tue, 10 Nov 2015 17:40:27 +0000 Message-ID: References: <1698815655.77932.1446845871633.JavaMail.zimbra@peachymango.org> <01PSWWQKDGN401729W@mauve.mrochek.com> <5641DCB6.3000002@tana.it> In-Reply-To: <5641DCB6.3000002@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:6::1fa] x-microsoft-exchange-diagnostics: 1; BN1PR03MB038; 5:sXyWKCOk/gOZSVQuaXJrQvmxpA8a6BPKfb0E2Mg//nlYx0XqnZ0bcNtuEUpng5dvojLmAn7KwmKs6HB2ApOD1dS902iminm1maPFiJfNDg+XBgDbzGJ2240AMPAvFQmNuJa37hSr7synPIb7HYp2xw==; 24:WHOZVhhmfIRmKHnzRBHNwjRR+K4uDS2EOk1B3eidFwE3E7m41+JLmXeBnTR4fncAH/o+aMM/syro23dZfGRFsEWNegTAmlkEZXuTk8pZbTw=; 20:f/tWrMcKgnQSIBoZs2yEIjC3Uz3grMHyGpDVvQBjaVuGZPMnp6B/Sn+XhwGBxWfg9iIY8GbkoKioHDUFSF7l1g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB038; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426024)(61427024); SRVR:BN1PR03MB038; BCL:0; PCL:0; RULEID:; SRVR:BN1PR03MB038; x-forefront-prvs: 07562C22DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(13464003)(24454002)(189002)(76576001)(76176999)(86362001)(10090500001)(2900100001)(54356999)(2351001)(2950100001)(99286002)(106116001)(105586002)(5001960100002)(10290500002)(106356001)(107886002)(5005710100001)(10400500002)(5001920100001)(122556002)(8990500004)(50986999)(110136002)(189998001)(33656002)(74316001)(5003600100002)(40100003)(87936001)(5002640100001)(101416001)(102836002)(450100001)(19580395003)(5008740100001)(5007970100001)(5004730100002)(19580405001)(93886004)(11100500001)(92566002)(97736004)(81156007)(230783001)(2501003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB038; H:BN1PR03MB038.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2015 17:40:27.6414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB038 Archived-At: Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 10 Nov 2015 17:40:33 -0000 > OTOH, conditional signatures have been discussed for more than five years= (my > dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha > (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document (= John's > dkim-conditional-02) which would match the charter's "form of DKIM signat= ure > that is better able to survive transit through intermediaries". Can the = WG > coordinate publication of these two I-Ds? -1. Not because I don't think conditional DKIM can't work, but that we need to = focus on one solution. When someone asks "How do I get email to survive DMA= RC if forwarded" we tell them "Go do this one thing" and not "Go do either = this *or* this." It's also easier for receivers to implement, debug, and ma= intain one solution rather than two. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Alessandro Vesely Sent: Tuesday, November 10, 2015 4:02 AM To: ned+dmarc@mrochek.com; Murray S. Kucherawy Cc: dmarc@ietf.org; Franck Martin Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interop= erability-08.txt On Mon 09/Nov/2015 23:16:42 +0100 ned+dmarc wrote:=20 >> On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin wrote:=20 >=20 >>> While the I-D will likely expires they will not be removed from the >>> website, so references will still work, so I don't see as that bad that >>> they are properly referenced in this document. I however agree we shoul= d >>> provide a quick summary for people that do not need the details. >>> >=20 >> On the flipside, I don't see what value they add; the ones that gain >> consensus will be published in their own right, and the details of the o= nes >> that don't probably aren't interesting to later readers anyway. >=20 > Generally speaking IETF Consensus/Publication !=3D Adoption and Use. Ther= e are a > number of drafts that never made it to RFC that contain information on st= uff > that did in fact deploy. (Although the best example of this by far is ac= tually > in X.400, where one of the most widely used text bodypart types was only = ever > described in a preliminary draft.) >=20 > That said, I'm dubious of the value of this section in a more general sen= se, > since in-progress work is likely to shift and change in unexpected ways, > which could easily make any description we provide more confusing than no= t. Somewhat agree, unless we're able to say more on the reasons why a specific approach failed to get broad consensus/ adoption. I'm thinking of RFC6541,= for which the text in -10 (of the transient nature of I-Ds) doesn't hold. OTOH, conditional signatures have been discussed for more than five years (= my dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document (Jo= hn's dkim-conditional-02) which would match the charter's "form of DKIM signatur= e that is better able to survive transit through intermediaries". Can the WG coordinate publication of these two I-Ds? > I personally would prefer to limit this sort of thing to descriptions of > things we know are currently deployed to some degree. It's then up to > future work to describe it's own interoperability issues, which is going > to be a requirement for anything that makes it to RFC status anyhow. >=20 > And yes, this does leave the door open for something that doesn't make it= to > RFC but does achieve some degree of deployment. But I think we have enoug= h > current issues to cover without trying to detail the nature of future one= s. I'm neutral on mentioning ARC, dkim-transform, and dkim-canon-list. Ale=20 From nobody Tue Nov 10 10:22:17 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 B79EA1B3C62 for ; Tue, 10 Nov 2015 10:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uqjCzSTZzegu for ; Tue, 10 Nov 2015 10:22:14 -0800 (PST) Received: from mailer4.americangreetings.com (mailer4.americangreetings.com [66.119.43.173]) by ietfa.amsl.com (Postfix) with ESMTP id D06BB1B3C5F for ; Tue, 10 Nov 2015 10:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=americangreetings.com; s=q42010; c=relaxed/relaxed; q=dns/txt; i=@americangreetings.com; t=1447179733; x=1478715733; h=From:Subject:Date:To:Cc:Reply-To:Message-ID:MIME-Version:Content-Type; bh=JvJXqsatGYlA9my3vBZJqVpLu7oWq1TRU5qql5d8qb0=; b=rocVcVThLHkapp9bqHo3FkRJR/tHNJ5Tb36ladvZefHCrWBlSZqtyr2ymZ5QUEuQ niJcG6h7S7ZYtOfYjQE9aUG/3S1Z2L7ogI0Sd7S4qVB5TFyjR81w7MQaH+K/S8nb 1dJqxIFN6eJynCWTd2EY3E9BxMor9M6pJU0Ooe3WuOk=; Received: from [66.119.43.83] ([66.119.43.83:39290] helo=dc3-mbox.ops.ag.com) by momentum7 (envelope-from ) (ecelerity 3.5.9.42398 r(Platform:3.5.9.0)) with ESMTP id B7/A2-13378-4D532465; Tue, 10 Nov 2015 13:22:13 -0500 Received: from [10.10.232.66] ([10.10.232.66]) by dc3-mbox.ops.ag.com (8.14.4/8.14.4) with ESMTP id tAAIMCM9029023 for ; Tue, 10 Nov 2015 13:22:12 -0500 To: dmarc@ietf.org References: <1698815655.77932.1446845871633.JavaMail.zimbra@peachymango.org> <01PSWWQKDGN401729W@mauve.mrochek.com> <5641DCB6.3000002@tana.it> From: "M. Hammer" Message-ID: <564235D4.4080802@americangreetings.com> Date: Tue, 10 Nov 2015 13:22:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 10 Nov 2015 18:22:15 -0000 On 11/10/2015 12:40 PM, Terry Zink wrote: >> OTOH, conditional signatures have been discussed for more than five years (my >> dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha >> (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document (John's >> dkim-conditional-02) which would match the charter's "form of DKIM signature >> that is better able to survive transit through intermediaries". Can the WG >> coordinate publication of these two I-Ds? > -1. > > Not because I don't think conditional DKIM can't work, but that we need to focus on one solution. When someone asks "How do I get email to survive DMARC if forwarded" we tell them "Go do this one thing" and not "Go do either this *or* this." It's also easier for receivers to implement, debug, and maintain one solution rather than two. > > -- Terry I agree with Terry on this, mainly because of the implementation issue for receivers. > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Alessandro Vesely > Sent: Tuesday, November 10, 2015 4:02 AM > To: ned+dmarc@mrochek.com; Murray S. Kucherawy > Cc: dmarc@ietf.org; Franck Martin > Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt > > On Mon 09/Nov/2015 23:16:42 +0100 ned+dmarc wrote: >>> On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin wrote: >>>> While the I-D will likely expires they will not be removed from the >>>> website, so references will still work, so I don't see as that bad that >>>> they are properly referenced in this document. I however agree we should >>>> provide a quick summary for people that do not need the details. >>>> >>> On the flipside, I don't see what value they add; the ones that gain >>> consensus will be published in their own right, and the details of the ones >>> that don't probably aren't interesting to later readers anyway. >> Generally speaking IETF Consensus/Publication != Adoption and Use. There are a >> number of drafts that never made it to RFC that contain information on stuff >> that did in fact deploy. (Although the best example of this by far is actually >> in X.400, where one of the most widely used text bodypart types was only ever >> described in a preliminary draft.) >> >> That said, I'm dubious of the value of this section in a more general sense, >> since in-progress work is likely to shift and change in unexpected ways, >> which could easily make any description we provide more confusing than not. > Somewhat agree, unless we're able to say more on the reasons why a specific > approach failed to get broad consensus/ adoption. I'm thinking of RFC6541, for > which the text in -10 (of the transient nature of I-Ds) doesn't hold. > > OTOH, conditional signatures have been discussed for more than five years (my > dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha > (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document (John's > dkim-conditional-02) which would match the charter's "form of DKIM signature > that is better able to survive transit through intermediaries". Can the WG > coordinate publication of these two I-Ds? > >> I personally would prefer to limit this sort of thing to descriptions of >> things we know are currently deployed to some degree. It's then up to >> future work to describe it's own interoperability issues, which is going >> to be a requirement for anything that makes it to RFC status anyhow. >> >> And yes, this does leave the door open for something that doesn't make it to >> RFC but does achieve some degree of deployment. But I think we have enough >> current issues to cover without trying to detail the nature of future ones. > I'm neutral on mentioning ARC, dkim-transform, and dkim-canon-list. > > Ale > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Tue Nov 10 22:36:16 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 EA4B61B2CD5 for ; Tue, 10 Nov 2015 22:36:13 -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 JFXT1rYtpWiV for ; Tue, 10 Nov 2015 22:36:12 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 280691B2CCD for ; Tue, 10 Nov 2015 22:36:11 -0800 (PST) Received: by ykdv3 with SMTP id v3so35189491ykd.0 for ; Tue, 10 Nov 2015 22:36:10 -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=ujom4ELxJor5Oqp1MShVM8NKOW3oW40QBUbrtc9/T2o=; b=FLcFpeSPqtrZpLmNtY9evGU3VXO0ifnEwoFXWqoQQX4qhN0v9xxXqIQ62aBWSELx6Q j8mBWxAIqgfIMDWb99T9fYLTlIsW1PRQaYO/Jd9aOhLh0inuyrJD7BJFQ6FIiyzXN8tb gVbfCcYou+2ZJ5be9qlbXdLSe0z5buxUqpoxploYDwYfBy7C+5HvE33jzClLlcHhM+AN KHS57W4Bt0r1Aer/hQWwZ1sULnL+MFXhf5Q/bGKiZ3EnCnccQ0AbV9APRkVrEk5FteNK 0V4iCkLT2pXfqODEaOZGWPGKCMi9KusTDt2sILYLmCLrQ9+/8Dhgv6ORWD6pF8BAxM1+ uuew== MIME-Version: 1.0 X-Received: by 10.13.239.193 with SMTP id y184mr7557766ywe.173.1447223770421; Tue, 10 Nov 2015 22:36:10 -0800 (PST) Received: by 10.103.83.73 with HTTP; Tue, 10 Nov 2015 22:36:10 -0800 (PST) In-Reply-To: References: <1698815655.77932.1446845871633.JavaMail.zimbra@peachymango.org> <01PSWWQKDGN401729W@mauve.mrochek.com> <5641DCB6.3000002@tana.it> Date: Tue, 10 Nov 2015 22:36:10 -0800 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=94eb2c033e12bf264505243e0ab2 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 11 Nov 2015 06:36:14 -0000 --94eb2c033e12bf264505243e0ab2 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 10, 2015 at 9:40 AM, Terry Zink wrote: > > OTOH, conditional signatures have been discussed for more than five > years (my > > dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha > > (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document > (John's > > dkim-conditional-02) which would match the charter's "form of DKIM > signature > > that is better able to survive transit through intermediaries". Can the > WG > > coordinate publication of these two I-Ds? > > -1. > > Not because I don't think conditional DKIM can't work, but that we need to > focus on one solution. When someone asks "How do I get email to survive > DMARC if forwarded" we tell them "Go do this one thing" and not "Go do > either this *or* this." It's also easier for receivers to implement, debug, > and maintain one solution rather than two. > That makes it sound like we've already picked the one thing. I don't believe that's the case. But really I think we're getting a bit ahead of ourselves here. The current focus should be on finishing the interoperability document, not which protocol project(s) ought to progress toward standardization. -MSK --94eb2c033e12bf264505243e0ab2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 10, 2015 at 9:40 AM, Terry Zink <t= zink@exchange.microsoft.com> wrote:
> OTOH, conditional signatures have been discussed for more than f= ive years (my
> dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alp= ha
> (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG doc= ument (John's
> dkim-conditional-02) which would match the charter's "form of= DKIM signature
> that is better able to survive transit through intermediaries".= =C2=A0 Can the WG
> coordinate publication of these two I-Ds?

-1.

Not because I don't think conditional DKIM can't work, but that we = need to focus on one solution. When someone asks "How do I get email t= o survive DMARC if forwarded" we tell them "Go do this one thing&= quot; and not "Go do either this *or* this." It's also easier= for receivers to implement, debug, and maintain one solution rather than t= wo.

That makes it sound like we've = already picked the one thing.=C2=A0 I don't believe that's the case= .

But really I think we're getting a bit a= head of ourselves here.=C2=A0 The current focus should be on finishing the = interoperability document, not which protocol project(s) ought to progress = toward standardization.

-MSK
--94eb2c033e12bf264505243e0ab2-- From nobody Wed Nov 11 07:06:29 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 D66611AD0C7 for ; Wed, 11 Nov 2015 07:06:27 -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 NShMLhd44dR1 for ; Wed, 11 Nov 2015 07:06:26 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 A73151AD0C3 for ; Wed, 11 Nov 2015 07:06:26 -0800 (PST) Received: by qgeb1 with SMTP id b1so25124914qge.1 for ; Wed, 11 Nov 2015 07:06:25 -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=C8IBOYERujQF6BFjkEx9HnSCOV3C6fkVm0yMslJQsD0=; b=ew5ySP3iw43NtadKTr1fszkqlg3ZdDx2PiKjkV1Ek7XWYLXOLDkZ/h6X748XxQ64Ld /xwtgtuYWARvp/siVtbxHOWprNzIEANqJVjJzWnUozYaFtPxT+H4q9bemiMXvjpo1/ZU qyOdJq2/n9WPTXO9/45V6dkZ9xv0g483nstis= 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=C8IBOYERujQF6BFjkEx9HnSCOV3C6fkVm0yMslJQsD0=; b=PLe8Br86aNze1/84kjenH7puwNToH9DnkxxW9wwhf6dt1v5tNbN1XeDh/dm4NpvJ4f Ekiv5Smel81tfWQNO9bUSkCGJyX/zGfyxJwyHgZaQrWq5cCFXWo8yed1HQ2g5lzqryDB muDQ1TPcT2RG/zfPjH4hbwxDKHcrg++iYiQ87J7hPq7GzadjMq3KC4SZsGjfwe83SbI1 3jwOAH9owq4pDhXVxwF4ayv8XACQtjli8nAqfZzlew/JhmfAkfZwBvN++iQoiBcBJEnG FW0ufgLhxRMXZfah13Uhq8bQXM/czP2QVQK4A/ljfN8HuBW88Cg4HfcmM3I2FQy3C6Ql qmoQ== X-Gm-Message-State: ALoCoQmZlIqi9Ubpxt7nensRISEfOt30Q+51LGeKsi/ZSw1k4PquiQQ+M55bN1a8czeQStOypZ6G MIME-Version: 1.0 X-Received: by 10.140.30.101 with SMTP id c92mr10963650qgc.74.1447254385506; Wed, 11 Nov 2015 07:06:25 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.198.219 with HTTP; Wed, 11 Nov 2015 07:06:25 -0800 (PST) Date: Wed, 11 Nov 2015 07:06:25 -0800 X-Google-Sender-Auth: jRWBGNltkj_P0L3Fc_xQ1K8kaS8 Message-ID: From: "Kurt Andersen (b)" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113a2a7a8c58e50524452bce Archived-At: Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt 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, 11 Nov 2015 15:06:28 -0000 --001a113a2a7a8c58e50524452bce Content-Type: text/plain; charset=UTF-8 On Tue, Nov 10, 2015 at 10:36 PM, Murray S. Kucherawy wrote: > The current focus should be on finishing the interoperability document, > not which protocol project(s) ought to progress toward standardization. > I quite agree. The ask to coordinate the interop document against various other (potential) documents seems like a layer violation :-) With that said, I believe that I have incorporated all of the comments which were received on the interop document (with the exception of a missing 't' in one place which should read "latter" instead of "later") into the -10 revision (posted earlier this week). Any further inputs before we call this one done? --Kurt --001a113a2a7a8c58e50524452bce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 10, 2015 at 10:36 P= M, Murray S. Kucherawy <superuser@gmail.com> wrote:
The current foc= us should be on finishing the interoperability document, not which protocol= project(s) ought to progress toward standardization.

I quite agree. The ask to coordinate the inte= rop document against various other (potential) documents seems like a layer= violation :-)

With that said, I be= lieve that I have incorporated all of the comments which were received on t= he interop document (with the exception of a
missing 't' in one place which should read "latter"= ; instead of "later") into the -10 revision (posted earlier this = week).

Any further inputs before we= call this one done?

--Kurt
--001a113a2a7a8c58e50524452bce-- From nobody Fri Nov 13 21:56:51 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 060DA1B3827; Thu, 12 Nov 2015 14:03:01 -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.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151112220300.16680.20422.idtracker@ietfa.amsl.com> Date: Thu, 12 Nov 2015 14:03:00 -0800 Archived-At: X-Mailman-Approved-At: Fri, 13 Nov 2015 21:56:50 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-11.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: Thu, 12 Nov 2015 22:03:01 -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-11.txt Pages : 22 Date : 2015-11-12 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-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-11 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 Nov 16 23:00:01 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 BD3481B2B30 for ; Mon, 16 Nov 2015 23:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 5nDVeO45G8HN for ; Mon, 16 Nov 2015 22:59:59 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9637F1B2B2F for ; Mon, 16 Nov 2015 22:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5934; q=dns/txt; s=iport; t=1447743598; x=1448953198; h=to:from:subject:message-id:date:mime-version; bh=00ekAdQGnw4UPciHRkpJJ2xF7fuUdszW20Jtk1sgGG4=; b=VLjmWBloEGKYGslTxToMxg/dhxXIirdfKG5hNNdcOmeV5HaB4vPn/BQb ZcS6/FmPB6S0WKo0EphE/lGfevx2+W2Wjikv4o5btjFWi15BFMpA1eG3P RGxkuzHjpa4OQ0sIjNOyfDq4Dm0zDl+HlcpngxtoSGlft6wggoLkWesqn 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClBABYz0pW/xbLJq1VCcNtgWWIFhIBA?= =?us-ascii?q?QEBAQEBfwuENgQkSwoGNxYLAgsDAgECAUsKAwgBARaIDAiafo9wkEEBAQgCARc?= =?us-ascii?q?Jj3wHCQIBgziBRAWHQYVagTKHfIJTgWCDFoVeiR2TKCgLMIIRHYFXPYN0AgUZB?= =?us-ascii?q?4EjAQEB?= X-IronPort-AV: E=Sophos;i="5.20,306,1444694400"; d="asc'?scan'208";a="612835929" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2015 06:59:55 +0000 Received: from [10.61.171.186] ([10.61.171.186]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAH6xsfv007073 for ; Tue, 17 Nov 2015 06:59:55 GMT To: "dmarc@ietf.org" From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <564AD069.8070109@cisco.com> Date: Tue, 17 Nov 2015 07:59:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AP31b0KCjbVKNgKFuECtXVhkHE2dsdNL5" Archived-At: Subject: [dmarc-ietf] handful of issues with draft-ietf-dmarc-interoperability-11 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, 17 Nov 2015 07:00:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AP31b0KCjbVKNgKFuECtXVhkHE2dsdNL5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, In doing a review of this current version, I note a small number of issues that can be resolved fairly quickly, I think. In Section 1: > Email messages that do not conform to other email specifications but= > are considered legitimate by the intended recipients are not > discussed in this document. =20 I know this may seem obvious to those in this working group, but I think we mean other "IETF email specifications" above, and we should say so. In Section 2.1, re SPF: > 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 unles= s > it is also the domain checked by SPF. Also note that the > RFC7208.MAILFROM definition is different from the RFC5321.MailFrom > [RFC5321] definition. This section is sufficiently dense that I would suggest that an example would be very helpful. Thee examples could go here or they could go elsewhere, but a handful would definitely help. I'm happy to develop some, if people are comfortable with that. Similarly, a DKIM example could be useful. We could probably borrow a message from this mailing list to prove the point. In addition we should probably be matching case between RFC 7208 and this document as we did for RFC 5321 so that someone who is searching can easily find the name, and so "RFC7208.mailfrom". In Section 2.2: > Message forwarding is a generic concept encapsulating a variety of > behaviors. This sentence doesn't really convey anything relevant and should be remov= ed. The front of Section 3.1 may lead people to believe we are defining the term "Mediator". We are not. It also comes from RFC 5598 and it should be rephrased as follows: RFC 5598 also defines a Mediator is a hybrid of several component types. A Mediator is given special consideration in this section due to the unique issues they face when attempting to interoperate with DMARC. In Section 3.1.1, the following text is somewhat imprecise: > MSA interoperability issues with DMARC begin when an aMSA accepts a > message where the RFC5322.From header field contains a domain that i= s > outside of the ADMD of the MSA. The ADMD will almost certainly not > be capable of sending email that yields Authenticated Identifiers > aligned with the domain found in the RFC5322.From header field. > Examples of this issue include "forward-to-friend" functionality > commonly found on news/article websites or "send-as" functionality > present on some MUAs. In fact a number of systems have gotten around this by forming a message in the browser and passing it to the MUA. There is also an ambiguous meaning to the second sentence. For instance, it could mean that someone buying email service from Google who happens to have their own domain will not be able to send mail. If SPF records are configured in their domain, that is not the case. And so I would propose rewriting this paragraph as follows: MSA interoperability issues with DMARC begin when an aMSA accepts a message where the RFC5322.From header field contains a domain that is outside of the ADMD of the MSA. These issues manifest themselves in o= ne of several ways, such as when someone uses a mail service with their o= wn domain but has failed to properly configure an SPF record; or when an MUA attempts to transmit mail as someone else. Examples of the latter issue include "forward-to-friend" functionality commonly found on news/artic= le websites or "send-as" functionality present on some MUAs. It may also be worth mentioning in Section 4.1.1 an additional bullet: o When implementing "forward-to-friend" functionality one approach to avoid DMARC failures is to pass a well formed message to the user's MUA so that it may fill in an appropriate identity. Section 3.1.2. The chapeau seems to dangle with a meaninglessly general statement: > 3.1.2. Message Transfer Agents > > MTAs relay a message until the message reaches a destination MDA. I propose a slight change just for flow: 3.1.2. Message Transfer Agents MTAs relay a message until the message reaches a destination MDA; and are thus in a position to introduce interoperability problems. Section 3.2 Based on the previous edit the first sentence can be removed. Eliot --AP31b0KCjbVKNgKFuECtXVhkHE2dsdNL5 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 iQEcBAEBCAAGBQJWStBqAAoJEIe2a0bZ0nozHEIIAIssHqR0K1AQRgSKX6L6HZNW DsWPMxeuRkOjAXtt5UNtiAQMp/sTpPvW7H5ijGEpzv2EpOmhGDaRQrpxZVPShRgh c/ZcCdHErF6RcxEXBzakOfVlzJtWgTOx+cPC7/HJN7/ukzD+1Y5PiYWYY1jt1N9S jb7XQ98D2i4bIrQJXkXisz/trsMERfmsxzAwbuiGpep7v7yBuX3y1CYMZYAuvDJ2 KDdNkk05a8LmwHaRvyK2h3O5HXrWCcJDvoH4Zb7yrWjm1ZNEUhN6OI9Y8s/NUSET enl0C6oRCDmTsC11pSNWnPMisO02jeMCwyJC29UTlK6Xxz2tgli/r27bpjmDA1c= =+dCv -----END PGP SIGNATURE----- --AP31b0KCjbVKNgKFuECtXVhkHE2dsdNL5-- From nobody Tue Nov 17 09:20:03 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 C9B481A1EF3 for ; Tue, 17 Nov 2015 09:20:01 -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 jCBQGdEL_Yb4 for ; Tue, 17 Nov 2015 09:20:01 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 D34801A1EEA for ; Tue, 17 Nov 2015 09:20:00 -0800 (PST) Received: by qkao63 with SMTP id o63so5068725qka.2 for ; Tue, 17 Nov 2015 09:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zHXpN8cHws2/1of/MXScTNVDxZxeAkePalwa7Twa0XI=; b=HCF/UzJ6h8GZ26iN92xDZpfKeUPZS/r5/tmQHoYq7AGp8iC8+3nyfrNK7MExSjfLch iSCrbzxJZpMmuZvgbA0/JovS8mAhLiZr8sksf9MOiNiXHs/EjcuujAFDShN0/Pph8uSY oT9PM296jyfcz6eHGCbWgSJuJHp4Xp+v4/0y8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zHXpN8cHws2/1of/MXScTNVDxZxeAkePalwa7Twa0XI=; b=Hrbx0mwB9zJx99P6FVGxsyxxpp0fynKadgLAP4ZQzBwK5RpygrwXjRDhJI0hqcCqq0 VGTS4d52CVdpPHWcnpQ6xSqBJ6IICC0PmxZ/owltx+jUI3xjfaMpjyqrPjFGE1aSjMeq sLqKwtyn+SQd89VacN/J3zMbiqLPKwdoK2s5s1/dbA+yjZWAZ+9VWm7VTuCYSxkEimCv +Vugb7PFbWZwYAQ/y6LtfMOVrFszC6ZecwxeOP3c56idLWCjrZaBWtClIAMO/QFrTdQv POPJHgl7Q+PD4JDcFrHDHlpeOU+WzznQRsrexYlATsxMJOkh/f3DNM43xsUMYJgIfrVC JQVQ== X-Gm-Message-State: ALoCoQnSZEW7q2/5GC6sN+K2Bsv3rXkRnKPfkE+gSFd5DPTU/81vhDQmND+SESTKM5nhiANXguZh MIME-Version: 1.0 X-Received: by 10.55.217.147 with SMTP id q19mr43436920qkl.109.1447780799963; Tue, 17 Nov 2015 09:19:59 -0800 (PST) Received: by 10.55.198.219 with HTTP; Tue, 17 Nov 2015 09:19:59 -0800 (PST) In-Reply-To: <564AD069.8070109@cisco.com> References: <564AD069.8070109@cisco.com> Date: Tue, 17 Nov 2015 09:19:59 -0800 Message-ID: From: Kurt Andersen To: Eliot Lear Content-Type: multipart/alternative; boundary=001a11479e464b8d0c0524bfbc75 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] handful of issues with draft-ietf-dmarc-interoperability-11 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, 17 Nov 2015 17:20:02 -0000 --001a11479e464b8d0c0524bfbc75 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 16, 2015 at 10:59 PM, Eliot Lear wrote: > In doing a review of this current version, I note a small number of > issues that can be resolved fairly quickly, I think. > Thank you for the suggestions. I'll work on incorporating them in the next couple of days. If I have questions as I do that, I'll ping you (Eliot) directly. --Kurt --001a11479e464b8d0c0524bfbc75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 16, 2015 at 10:59 P= M, Eliot Lear <lear@cisco.com> wrote:
In doing a review of this current version, I note a small= number of
issues that can be resolved fairly quickly, I think.

Thank you for the suggestions. I'= ;ll work on incorporating them in the next couple of days. If I have questi= ons as I do that, I'll ping you (Eliot) directly.

--Kurt
--001a11479e464b8d0c0524bfbc75-- From nobody Tue Nov 17 20:32:54 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 9EFE61AC444 for ; Tue, 17 Nov 2015 20:32:53 -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 V5pZ8z45yVzz for ; Tue, 17 Nov 2015 20:32:52 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 526F21AC43C for ; Tue, 17 Nov 2015 20:32:52 -0800 (PST) Received: by ykba77 with SMTP id a77so44805458ykb.2 for ; Tue, 17 Nov 2015 20:32:51 -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=bqyuZmyxHOVBL6cvz2B+JYiQvrfpDP+0Ko9eCeeDZP4=; b=P3BTCLtUtzy5RZCy87Z5mhn65tEirTVcmhD+A9lPZEcOlfARCWeX5kISrzpK6CXgqs 2kK3/SxTh33yQ1V6Uq/S1pSZTOdQ+9aNbkqs+LfqCkB67rc2TY5o8k57LothkwXmlJVy Q1TN/caH3qsMauWeb1VeodRTHWypd1pPqpVQhjO5pmve/VZyhAgHSx9qPTeqePHoJOrz XD+AmnTdclNSwghnaVxT+V5MtxL8QVW2npecAVKrkN8G1bV267JZWMiNem9YSmR7ZWKe SIy6TPsCa+K1RN32OY7sUPecHzyGo5Efqig3XMxJRCcTvb6jg84GCYsR6dEfQuCnuuCy B88w== MIME-Version: 1.0 X-Received: by 10.129.159.7 with SMTP id w7mr3467600ywg.70.1447821171587; Tue, 17 Nov 2015 20:32:51 -0800 (PST) Received: by 10.103.83.73 with HTTP; Tue, 17 Nov 2015 20:32:51 -0800 (PST) In-Reply-To: References: <564AD069.8070109@cisco.com> Date: Tue, 17 Nov 2015 20:32:51 -0800 Message-ID: From: "Murray S. Kucherawy" To: Kurt Andersen Content-Type: multipart/alternative; boundary=94eb2c0bd330a193360524c922ac Archived-At: Cc: "dmarc@ietf.org" , Eliot Lear Subject: Re: [dmarc-ietf] handful of issues with draft-ietf-dmarc-interoperability-11 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, 18 Nov 2015 04:32:53 -0000 --94eb2c0bd330a193360524c922ac Content-Type: text/plain; charset=UTF-8 On Tue, Nov 17, 2015 at 9:19 AM, Kurt Andersen wrote: > > Thank you for the suggestions. I'll work on incorporating them in the next > couple of days. If I have questions as I do that, I'll ping you (Eliot) > directly.\\ > Since this document is in WGLC, could we please do that on the list? -MSK --94eb2c0bd330a193360524c922ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 17, 2015 at 9:19 AM, Kurt Andersen <kurta@dr= kurt.com> wrote:

Thank you for the suggestions. I&#= 39;ll work on incorporating them in the next couple of days. If I have ques= tions as I do that, I'll ping you (Eliot) directly.\\

Since this document is in WGLC, could we please do that on= the list?

-MSK
--94eb2c0bd330a193360524c922ac-- From nobody Thu Nov 19 14:56:57 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 5B90F1B36CF for ; Thu, 19 Nov 2015 14:56:55 -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 1lnCgxQVy7Rk for ; Thu, 19 Nov 2015 14:56:54 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 575091B36BC for ; Thu, 19 Nov 2015 14:56:54 -0800 (PST) Received: by qgeb1 with SMTP id b1so62139538qge.1 for ; Thu, 19 Nov 2015 14:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nfdqj1pAGghIaNXUxdPjIqz/tf05hMmo8mqmomHjuOU=; b=dQnp+O8sgLOVt0ss46vF2t5yqSY82NoYyYvP9JLUI3KxhYH1w/e70kIeGF6dmBShGN eywtUd1nPZEKd0cu//LCMu0nFlaKFxIghz51PC0KFOJBTHeOiChCFGunz7Z6gXir7g8M X6f+H1uXHnKRiYY5POlPtzexKT5t2D5M5wEms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nfdqj1pAGghIaNXUxdPjIqz/tf05hMmo8mqmomHjuOU=; b=C3mRU2ZOMnCTcqcUnLno8AlMV/9G94w/UxvpTZ0MRtOm5hunHEKcqZMGu/mwOLNjj2 eFW+VbZLmyPOCVR02i4Y1bKTVhQEwMMocAz7QYyTbwaRBJo6qfR8zRgBxlTYUKNU4u6f YxEp+y1Z74E/ilg9onN8qubPLG3kJCfksGGa1Qmy+gQIgjW/D3XKfvaagUJsvyDfx1X1 5EY11lXvsBi3OBQqhEKOltI+fwCpV1mlSp5ISZhc7FrSc9DxedViY5kgljMDZsz41Dvv 50hLq9U4lPK+lEIUaBbFqjPPh1H+6ykfL7cFpPU7EOES/mi9QL+MhIuVxEZr6SQjML40 zbDQ== X-Gm-Message-State: ALoCoQkYLe6NuINMNrRgOjCHZUz2s/zeHI4twaCNKOFqpXhLLRgFkzDDZSVPw04UASkWSspMfP23 MIME-Version: 1.0 X-Received: by 10.140.84.40 with SMTP id k37mr9888068qgd.33.1447973813471; Thu, 19 Nov 2015 14:56:53 -0800 (PST) Received: by 10.55.198.219 with HTTP; Thu, 19 Nov 2015 14:56:53 -0800 (PST) In-Reply-To: References: <564AD069.8070109@cisco.com> Date: Thu, 19 Nov 2015 14:56:53 -0800 Message-ID: From: Kurt Andersen To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c124b0cbebed0524ecac79 Archived-At: Cc: "dmarc@ietf.org" , Eliot Lear Subject: Re: [dmarc-ietf] handful of issues with draft-ietf-dmarc-interoperability-11 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: Thu, 19 Nov 2015 22:56:55 -0000 --001a11c124b0cbebed0524ecac79 Content-Type: text/plain; charset=UTF-8 Yes, will do. On Tue, Nov 17, 2015 at 8:32 PM, Murray S. Kucherawy wrote: > On Tue, Nov 17, 2015 at 9:19 AM, Kurt Andersen wrote: > >> >> Thank you for the suggestions. I'll work on incorporating them in the >> next couple of days. If I have questions as I do that, I'll ping you >> (Eliot) directly.\\ >> > > Since this document is in WGLC, could we please do that on the list? > > -MSK > --001a11c124b0cbebed0524ecac79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, will do.

On Tue, Nov 17, 2015 at 8:32 PM, Murray S. Kucherawy= <superuser@gmail.com> wrote:
On Tue, Nov 17, 2015 at 9:19 AM, Kurt Andersen <kurt= a@drkurt.com> wrote:

=
Thank you for the suggestions. I'll w= ork on incorporating them in the next couple of days. If I have questions a= s I do that, I'll ping you (Eliot) directly.\\

Since t= his document is in WGLC, could we please do that on the list?

-MSK

--001a11c124b0cbebed0524ecac79-- From nobody Tue Nov 24 16:13:05 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 63A541AC3D5 for ; Tue, 24 Nov 2015 16:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 0FHewsAkXYV9 for ; Tue, 24 Nov 2015 16:13:03 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 1B0161AC3C8 for ; Tue, 24 Nov 2015 16:13:03 -0800 (PST) Received: by pabfh17 with SMTP id fh17so38774978pab.0 for ; Tue, 24 Nov 2015 16:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=QDLhMQDGxn+QajOvq+GyjZQPxb/x4zSplAEDd1udaL0=; b=QFQxhxP7l22/hsGlAvVj68k2JRlLSFUSHBiVHzrrPjxsDWFeK4OrkJ2g6kJpERez0b xy+6iIjuQqwKNduXRD9vXBRgijk6I6dNbg/rmcQUqzq3TtebH8laqMz+826xH+iwxbSZ RsOLTJW5grWjihLvFl7CHAMF78/x6blc9w5pE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type; bh=QDLhMQDGxn+QajOvq+GyjZQPxb/x4zSplAEDd1udaL0=; b=cfzmPiJEU30UbJhMzUPv2chFP0PBktqZy1AvKFCAi/1v0fzsp+VeeIiNXTsSViCX4Y NbMITM5v6CZ7PWuYZI8ScHg+ApTIXjy2RZVB0gdkTpsqdnsZA24UHRQraJvrZvRiQ1Pr Xm4dTCTs2Ruxy15dR6Fx02R6o8Bx32Tqnu80S+dc2/3kRWSAbtnOzG1Lqwm56ylBy+ob Eq5J59aLfxqswLgA8vXz6nVzInqWgmk+L43DVXJK42at8FAS7eCtrJ45S0s6b6l1gv5/ GYPzmAzCCtv6fUqA9y3jjNc9Z8fQ4/FaEA6FaH1KDmIjGKxrw33hTdvHZCXS03W+ZPmt 54vg== X-Gm-Message-State: ALoCoQn7+3IqJKSMaDX3RRfOhHVjNSicKrp72NH26QErnFCmYeqtT4Rh3nYFbBMYhiGvgnKA0I21 X-Received: by 10.66.153.198 with SMTP id vi6mr47158596pab.37.1448410382674; Tue, 24 Nov 2015 16:13:02 -0800 (PST) Received: from [172.16.1.87] (50-197-151-169-static.hfc.comcastbusiness.net. [50.197.151.169]) by smtp.gmail.com with ESMTPSA id t26sm16632386pfa.52.2015.11.24.16.13.01 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Nov 2015 16:13:02 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.5.8.151023 Date: Tue, 24 Nov 2015 16:12:58 -0800 From: Tomki Camp To: "dmarc@ietf.org" Message-ID: Thread-Topic: spec RUA filename examples contradiction Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3531226381_5904021" Archived-At: Subject: [dmarc-ietf] spec RUA filename examples contradiction 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, 25 Nov 2015 00:13:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3531226381_5904021 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable The specification specifies that RUA filename attachments should follow thi= s pattern for the extension: extension =3D "xml" / =E2=80=9Cxml.gz" The extension MUST be "xml" for a plain XML file, or "xml.gz" for an XML file compressed using GZIP. However there are examples in the document which do not follow that pattern= : Content-Disposition: attachment; filename=3D"mail.receiver.example!example.com! 1013662812!1013749130.gz=E2=80=9D =E2=80=94Tomki --B_3531226381_5904021 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
The specification specifies that= RUA filename attachments should follow this pattern for the extension:
     extension =3D "xml" / “xml.gz"
The extension MUST be "xml" for a plain XML file, or "xm= l.gz" for an XML file compressed using GZIP.

However there are examples in the document which do not follow that p= attern:
     Content-Disposition: attachment;=

         filename=3D"mail.receiver.example!example.com!
                   1013662812!1013749130.gz”

—Tomki

=
--B_3531226381_5904021-- From nobody Thu Nov 26 07:37:47 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 C3E921B3B4A for ; Thu, 26 Nov 2015 07:37:44 -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 cBzj7_L1qbtF for ; Thu, 26 Nov 2015 07:37:42 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 739841B3B5D for ; Thu, 26 Nov 2015 07:37:39 -0800 (PST) Received: by vkfr145 with SMTP id r145so55828330vkf.0 for ; Thu, 26 Nov 2015 07:37:38 -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 :content-type; bh=oh7SERwR6Ay495wTHIjdvGYrLG9IwmCDQ1kqs/F8+98=; b=N33osZmXMmz/kNs8qLAzYl0O0btvcIM4jwFfTo8iuw1h7L39PL1ncdCeMvc8rXKZM2 m6UApS0e4AxFrgzNBlTQpN9o40O33D0CPiNDP2db9EfGQLiGcpZ7silsjV5r/V2cpjpg YJI/5UiiIu0EynVzAn8gUa8sDhQB4bxh6g3Gta775kznKzKaQDv6AMUOO9sBb93ZI18R xg086+2phxmZfv3INN+rAnlBPq/suVnvtyNEiolkc9J32VkpJuWqDsqhAvwWCtf15vKN uqYsUc4Bdb4HEdQb02HzJjJwQSlFrCtqC0U77X+6D+Rh1JNjpGUYcpP8PgxiBR2kIx44 xQfg== MIME-Version: 1.0 X-Received: by 10.31.52.211 with SMTP id b202mr38288571vka.82.1448552258620; Thu, 26 Nov 2015 07:37:38 -0800 (PST) Received: by 10.103.83.73 with HTTP; Thu, 26 Nov 2015 07:37:38 -0800 (PST) In-Reply-To: <20151125155025.6781.94353.idtracker@ietfa.amsl.com> References: <20151125155025.6781.94353.idtracker@ietfa.amsl.com> Date: Thu, 26 Nov 2015 07:37:38 -0800 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a1143e988d0535c0525735ad1 Archived-At: Subject: [dmarc-ietf] Fwd: New Non-WG Mailing List: Shutup -- SMTP Headers Unhealthy To User Privacy 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: Thu, 26 Nov 2015 15:37:44 -0000 --001a1143e988d0535c0525735ad1 Content-Type: text/plain; charset=UTF-8 Of likely interest to this WG. A proposed charter is under discussion. ---------- Forwarded message ---------- From: IETF Secretariat Date: Wed, Nov 25, 2015 at 7:50 AM Subject: New Non-WG Mailing List: Shutup -- SMTP Headers Unhealthy To User Privacy To: IETF Announcement List Cc: alexey.melnikov@isode.com, shutup@ietf.org, linus@nordberg.se A new IETF non-working group email list has been created. List address: shutup@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=shutup To subscribe: https://www.ietf.org/mailman/listinfo/shutup Purpose: Discuss ways in which user privacy can be protected when sending email, by making changes to the way header fields are used. For additional information, please contact the list administrators. --001a1143e988d0535c0525735ad1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Of likely interest to this WG.=C2=A0 A proposed charter is= under discussion.

---------- F= orwarded message ----------
From: IETF Sec= retariat <ietf-secretariat@ietf.org>
Date: Wed, Nov 25, 2015 at= 7:50 AM
Subject: New Non-WG Mailing List: Shutup -- SMTP Headers Unheal= thy To User Privacy
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: alexey.melnikov@isode.com, shutup@ietf.org, linus@nordberg.se


A new IETF non-working group email list= has been created.

List address: shutup@ietf.org
Archive: https://mailarchive.ietf.org/a= rch/search/?email_list=3Dshutup
To subscribe: https://www.ietf.org/mailman/listinfo/shu= tup

Purpose:

Discuss ways in which user privacy can be protected when sending email, by = making changes to the way header fields are used.

For additional information, please contact the list administrators.


--001a1143e988d0535c0525735ad1-- From nobody Mon Nov 30 17:15: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 400701B3565 for ; Mon, 30 Nov 2015 17:15:55 -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 NZ8CfY5HD6e7 for ; Mon, 30 Nov 2015 17:15:53 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 0CC111B3563 for ; Mon, 30 Nov 2015 17:15:53 -0800 (PST) Received: by qgcc31 with SMTP id c31so133371741qgc.3 for ; Mon, 30 Nov 2015 17:15:52 -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:cc:content-type; bh=xdooUWnssRft5AjuOTF0AjPbjyV2CgN+g4dpTFyGYhc=; b=PzYqvIpWX+zKeSd6C9J6fX/5sFvwk2fjrRUrJRSlUYzvdCFKEAbU+BZnLH0L6XQQxT J5xtWm6eJJMMyAArEDPtdJ/SY8CDMzRT8FFy1bFKZ1xYEgE4+10GD+n4fs37UGXyYKbw 4gdQLry0L4YkS9g1FCMv1TMLNtH7agNEf9f+0= 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:cc:content-type; bh=xdooUWnssRft5AjuOTF0AjPbjyV2CgN+g4dpTFyGYhc=; b=a07PTrty2g+9nW3n2/wW2EhBEphXkDlirNR0fMkkflQGKxY/nN6Rkt/iTedKaWh8vn 39qLD5Exqzu7UJlSSntN1WmRN0TjmD+5peoZBctqTGFbaF6bBHTwMsR8JRgiy/cdrVjA 10aP8RdIcfftOnAg4jUoRqfHvu6b/iiwHWHfzpfSLnLQ1L7EyzYzyoXNI94qXAjVbGm8 yJfmaDu3NHzcSHPRWif2mGcrfrq3dajDmF8QCzS22QB/JzJ6loEcvA2yclniRMqQA2Xd nqsZTacgFIZUKUEvlfP8BvgedjBulEZ7P0fKkZnSlaOrvpfufO6HeVxtQofNeMuy9up1 3QgA== X-Gm-Message-State: ALoCoQnm9OMQ4Ur3RpyefgeOX+bPO1EivIFkxo4HzU5TkNKRdy1tS/5Vn5e0qPhdevCfr/6eb+5F MIME-Version: 1.0 X-Received: by 10.141.3.212 with SMTP id f203mr81764891qhd.98.1448932552230; Mon, 30 Nov 2015 17:15:52 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.198.219 with HTTP; Mon, 30 Nov 2015 17:15:52 -0800 (PST) Date: Mon, 30 Nov 2015 17:15:52 -0800 X-Google-Sender-Auth: Pmq9n3eb0J2EN2Jcj54jzH1utAQ Message-ID: From: "Kurt Andersen (b)" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113a94e01483590525cbe61f Archived-At: Cc: Eliot Lear Subject: [dmarc-ietf] draft-ietf-dmarc-interoperability-12 posted 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, 01 Dec 2015 01:15:55 -0000 --001a113a94e01483590525cbe61f Content-Type: text/plain; charset=UTF-8 I just posted -12 which includes fixes for all of the inputs I had seen except for the following one: On Mon, Nov 16, 2015 at 10:59 PM, Eliot Lear wrote: > In Section 2.1, re SPF: > > > 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. > > This section is sufficiently dense that I would suggest that an example > would be very helpful. Thee examples could go here or they could go > elsewhere, but a handful would definitely help. I'm happy to develop > some, if people are comfortable with that. Similarly, a DKIM example > could be useful. We could probably borrow a message from this mailing > list to prove the point. > > In addition we should probably be matching case between RFC 7208 and > this document as we did for RFC 5321 so that someone who is searching > can easily find the name, and so "RFC7208.mailfrom". > I've been noodling on how to "fluff up" (in a non-pejorative sense) the dense language that Elliot pointed out but did not want to delay the other fixes any longer while I figure out a way to tackle this particular point. --Kurt --001a113a94e01483590525cbe61f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just posted -12 which include= s fixes for all of the inputs I had seen except for the following one:

On Mon, Nov 16, = 2015 at 10:59 PM, Eliot Lear <lear@cisco.com> wrote:
In Section 2.1, re SPF:

>=C2=A0 =C2=A0 SPF can provide two Authenticated Identifiers.=C2=A0 The = DMARC relevant
>=C2=A0 =C2=A0 Authenticated Identifiers that SPF provides is the RFC720= 8.MAILFROM
>=C2=A0 =C2=A0 [RFC7208] based on the RFC5321.MailFrom [RFC5321] domain,= or, if the
>=C2=A0 =C2=A0 RFC5321.MailFrom address is absent (as in the case of &qu= ot;bounce"
>=C2=A0 =C2=A0 messages), on the RFC5321.HELO/EHLO SMTP domain.=C2=A0 Th= e SPF validated
>=C2=A0 =C2=A0 domain in RFC7208.MAILFROM must be part of the same Organ= izational
>=C2=A0 =C2=A0 Domain as the domain in the RFC5322.From header field to = be aligned.
>=C2=A0 =C2=A0 It is important to note that even when an SPF record exis= ts for the
>=C2=A0 =C2=A0 domain in RFC5322.From [RFC5322], SPF will not authentica= te it unless
>=C2=A0 =C2=A0 it is also the domain checked by SPF.=C2=A0 Also note tha= t the
>=C2=A0 =C2=A0 RFC7208.MAILFROM definition is different from the RFC5321= .MailFrom
>=C2=A0 =C2=A0 [RFC5321] definition.

This section is sufficiently dense that I would suggest that an example
would be very helpful.=C2=A0 Thee examples could go here or they could go elsewhere, but a handful would definitely help.=C2=A0 I'm happy to deve= lop
some, if people are comfortable with that.=C2=A0 Similarly, a DKIM example<= br> could be useful.=C2=A0 We could probably borrow a message from this mailing=
list to prove the point.

In addition we should probably be matching case between RFC 7208 and
this document as we did for RFC 5321 so that someone who is searching
can easily find the name, and so "RFC7208.mailfrom".

I've been noodling on how to "fluff up" (= in a non-pejorative sense) the dense language that Elliot pointed out but d= id not want to delay the other fixes any longer while I figure out a way to= tackle this particular point.

--Kurt
--001a113a94e01483590525cbe61f--