From nobody Mon Jan 4 12:48:38 2016 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 CC6FC1A92BA for ; Mon, 4 Jan 2016 12:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, 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 ZhIe8Znlo9fi for ; Mon, 4 Jan 2016 12:48:36 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 3F8F21A92B5 for ; Mon, 4 Jan 2016 12:48:36 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id to4so147086igc.0 for ; Mon, 04 Jan 2016 12:48:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+6stL2M0ukVUI6WbimY505mRV9Z73F5B1JU6rQkIFl8=; b=iBNiBoh7qQ+cDQNtUqiCvgN+kZHHvJr+GTxphvSH19F8YYbpNy/Pqo8goWMMdlC43s Phdzl6aBzvs0ufV032+5YXg4IFrB5irufoZbhU8kEPZZDaT2h7aI5+CHazQT1rOMUIfi kOFCEXinhEbr+E6HCnrOZ2ObAW2OsLIX+YsWGWB9uc8NWPhL8SH8KHib44pjooZ8Lx7F GrBncVYiwQQ1iO035ecCr8LAiVD9Q6o3pQTiYbxhBxuQqxg/q9dWtJ4/utwAeFJ3ZhfN Xa0xLkQUwVmuc2j2/YB6aiRz+TT/bgUyu3vBkUTgtUWzx0wnU84+MP2IfFRNVBsM+mZe 5UYQ== 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:content-type; bh=+6stL2M0ukVUI6WbimY505mRV9Z73F5B1JU6rQkIFl8=; b=DF4QQeK+Tu7kI2eF92DwnB/ebZiFE6fpQpX1BoCARpVs+GulPE6PqCA+c0cDcCv3Kp JBLECg9x1VDuOh0GB6DSOdSdnCHTh+TOv/0ZVAnuZLrkAEdltIaTeW4gfRzB6XaFsaVz ngr32papyl8L/JNCOsraRW8ndrWU5lyIkt7qXhstiPOABRKDGevO7B55hoif7hmQ4+Fv hv9ng+MK61pUbayoFpUuvpoTfY8aYEX+F7r/CNfDlXd+BnxV3RqCX2AoJMV+urrnqUbO wEUXQL3qqZnv8MSqtoz+2zZ/xcPf+fdTp8Un/aqgjYOBR+oSvZOdWVaswPsyLtIJguVl VrQw== X-Gm-Message-State: ALoCoQmFGBsslT5L1YOCgunn0KHSsSn07t3qVldPAMHPbJhh0KH48nRcxFZii51xQUmg2cGH26ShCRe69L/dgz7E7VkfNu+UaMZtDkH5eviwGWt4hH9f7iA= MIME-Version: 1.0 X-Received: by 10.50.160.11 with SMTP id xg11mr316070igb.83.1451940515314; Mon, 04 Jan 2016 12:48:35 -0800 (PST) Received: by 10.64.19.144 with HTTP; Mon, 4 Jan 2016 12:48:35 -0800 (PST) In-Reply-To: <20151208235650.16949.5186.idtracker@ietfa.amsl.com> References: <20151208235650.16949.5186.idtracker@ietfa.amsl.com> Date: Mon, 4 Jan 2016 12:48:35 -0800 Message-ID: From: Brandon Long To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a1135e238a6f1490528883e46 Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-13.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, 04 Jan 2016 20:48:38 -0000 --001a1135e238a6f1490528883e46 Content-Type: text/plain; charset=UTF-8 The current draft seems complete to me. Brandon On Tue, Dec 8, 2015 at 3:56 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance Working Group of the IETF. > > Title : Interoperability Issues Between DMARC and > Indirect Email Flows > Authors : Franck Martin > Eliot Lear > Tim Draegen > Elizabeth Zwicky > Kurt Andersen > Filename : draft-ietf-dmarc-interoperability-13.txt > Pages : 23 > Date : 2015-12-08 > > Abstract: > DMARC introduces a mechanism for expressing domain-level policies and > preferences for email message validation, disposition, and reporting. > The DMARC mechanism can encounter interoperability issues when > messages do not flow directly from the author's administrative domain > to the final recipients. Collectively these email flows are referred > to as indirect email flows. This document describes interoperability > issues between DMARC and indirect email flows. Possible methods for > addressing interoperability issues are presented. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-13 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a1135e238a6f1490528883e46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The current draft seems complete to me.

Brandon

On Tue, Dec 8, 2015 at 3:56 PM, <internet-drafts@ietf.org&g= t; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Domain-based Message Authentication,= Reporting & Conformance Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Interoperability Issues Between DMARC and Indirect Email Flows
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Fran= ck Martin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Eliot Lear
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tim Draegen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Elizabeth Zwicky
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kurt Andersen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-interoperability-13.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 23
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-12-08

Abstract:
=C2=A0 =C2=A0DMARC introduces a mechanism for expressing domain-level polic= ies and
=C2=A0 =C2=A0preferences for email message validation, disposition, and rep= orting.
=C2=A0 =C2=A0The DMARC mechanism can encounter interoperability issues when=
=C2=A0 =C2=A0messages do not flow directly from the author's administra= tive domain
=C2=A0 =C2=A0to the final recipients.=C2=A0 Collectively these email flows = are referred
=C2=A0 =C2=A0to as indirect email flows.=C2=A0 This document describes inte= roperability
=C2=A0 =C2=A0issues between DMARC and indirect email flows.=C2=A0 Possible = methods for
=C2=A0 =C2=A0addressing 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-ie= tf-dmarc-interoperability-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-dmarc-interoperability-13


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--001a1135e238a6f1490528883e46-- From nobody Mon Jan 18 09:49:49 2016 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 B28791B3AFC for ; Mon, 18 Jan 2016 09:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 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, J_CHICKENPOX_16=0.6, 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 L9RpYnslC-Gv for ; Mon, 18 Jan 2016 09:49:46 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 5377C1B3289 for ; Mon, 18 Jan 2016 09:49:46 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id b66so20618829qkf.3 for ; Mon, 18 Jan 2016 09:49:46 -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=sgYxRxb+zIbzvUArFCI19oBM2aQ1uACbnj834VE3mTo=; b=F3R7eZ+YGJFjyo1wdVeZTz54p5g2xTFm3JLRYiDWhxXcTV7S9Q6w4oaZUmcbqf39Zx /7qlsCFQs5SPodtycdtRk9s8952cBdmgKE0wmW5M1Or7DhEYjMO4c3BZriw8Y0mIKRv2 F0aFa6DMj39bBcKxzIBNLv/opsvgbmCbmumi4= 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=sgYxRxb+zIbzvUArFCI19oBM2aQ1uACbnj834VE3mTo=; b=H0b1WjT43KW7SSogACDDCYczxwPk87ITloL2TrYCHcekNa2IFO/SLK7JmwY/GnlNDg 3iQmadsJz10hjkQVIqhaeV5J11pPTuxkGQk0pRpVDYWSXDL06D0xgXkkezrOuWJ+BliZ +nObE2VEXfhoVBfxFTAQY0D5dEOnzEGk1NMO32hH7ST+2z66RRlIYp5wFsrcrlwcoS/V 3xgM9X/T6DcYiVNEdwXaCWhf3IaqL7R4DUUGntSnaQs0sah8QSupNsmHc52hqidGnv4g WhCNKhxuzYaQbD16o0hR34drEdfZwUpbzjXeEO3X2Jga0gIfJkVR/939lImg5cyrKaYN YGgg== X-Gm-Message-State: ALoCoQlvWsUWST97RlQl7Xovm2b6hdcNwSf5KBL8lUCWqV63lH4wzIMK9CSfMRZ3V0YR8So3ooNWXz5tpfujb2lGVbm3pc7ZAA== MIME-Version: 1.0 X-Received: by 10.55.53.208 with SMTP id c199mr33083877qka.109.1453139385368; Mon, 18 Jan 2016 09:49:45 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.42.67 with HTTP; Mon, 18 Jan 2016 09:49:45 -0800 (PST) Date: Mon, 18 Jan 2016 09:49:45 -0800 X-Google-Sender-Auth: B2Al2RgOOftR7afDyt6VZUWHyAU Message-ID: From: "Kurt Andersen (b)" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11470ed2dff73d05299f6060 Archived-At: Subject: [dmarc-ietf] Clarification question on handling multiple domains in RFC5322.from (section 6.6.1) 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, 18 Jan 2016 17:49:47 -0000 --001a11470ed2dff73d05299f6060 Content-Type: text/plain; charset=UTF-8 While revising the interop document, I am adding a note about the situation with multiple domains in a syntactically correct RFC5322.from header (section 6.6.1). The last paragraph of that section reads: > > The case of a syntactically valid multi-valued RFC5322.From field presents > a particular challenge. The process in this case is to apply the DMARC > check using each of those domains found in the RFC5322.From field as the > Author Domain and apply the most strict policy selected among the checks > that fail. I realize that an earlier statement in the section defines the actual handling to be implementation dependent, but it's not clear to me how the advice in the last paragraph would really be applied. Say for example that a message is received with two domains in the RFC5322.from: test1.example and test2.example. If test1.example fails to have an aligned, authenticated identifier but specifies p=reject while test2.example *does* have an aligned, authenticated identifier, then it seems to me that the message receives a DMARC pass evaluation and the policy for test1.example is irrelevant since p=reject doesn't apply to a message that passes DMARC. Am I misunderstanding the recommended algorithm? --Kurt Andersen --001a11470ed2dff73d05299f6060 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While revising the interop document, I am adding a note ab= out the situation with multiple domains in a syntactically correct RFC5322.= from header (section 6.6.1). The last paragraph of that section reads:The case of a syntactically valid multi-valued RFC5322.From fie= ld presents a particular challenge. The process in this case is to apply the DMARC check using each of those domains found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail.

<= div>I realize that an earlier statement in the section defines the actual h= andling to be implementation dependent, but it's not clear to me how th= e advice in the last paragraph would really be applied.

Say for example that a message is received with two domains in the RF= C5322.from: test1.example and test2.example. If test1.example fails to have= an aligned, authenticated identifier but specifies p=3Dreject while test2.= example *does* have an aligned, authenticated identifier, then it seems to = me that the message receives a DMARC pass evaluation and the policy for tes= t1.example is irrelevant since p=3Dreject doesn't apply to a message th= at passes DMARC.

Am I misunderstanding the recomme= nded algorithm?

--Kurt Andersen=C2=A0
--001a11470ed2dff73d05299f6060-- From nobody Mon Jan 18 10:02:56 2016 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 EE5531B3B3B for ; Mon, 18 Jan 2016 10:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.001, 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 FeBHWSXNq98W for ; Mon, 18 Jan 2016 10:02:53 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id CF5061B3B3A for ; Mon, 18 Jan 2016 10:02:53 -0800 (PST) Received: from [192.168.192.139] (unknown [12.31.71.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id AFBF0CB46; Mon, 18 Jan 2016 13:01:47 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_375173F4-4E05-481F-924A-48243B4AFEEB" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Draegen In-Reply-To: Date: Mon, 18 Jan 2016 13:02:50 -0500 Message-Id: <2E692A5B-1D15-4A17-989E-F7A1DF930088@eudaemon.net> References: To: "Kurt Andersen (b)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Clarification question on handling multiple domains in RFC5322.from (section 6.6.1) 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, 18 Jan 2016 18:02:55 -0000 --Apple-Mail=_375173F4-4E05-481F-924A-48243B4AFEEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 18, 2016, at 12:49 PM, Kurt Andersen (b) = wrote: >=20 > Am I misunderstanding the recommended algorithm? >=20 Maybe the example of @crime.net and @bank.com = might add clarity. If both have a p=3Dreject policy, = and only @crime.net successfully passes the DMARC = check, it would be wise to enforce @bank.com's reject policy, no? =3D- Tim --Apple-Mail=_375173F4-4E05-481F-924A-48243B4AFEEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Jan 18, 2016, at 12:49 PM, Kurt Andersen (b) <kboth@drkurt.com> = wrote:

Am I misunderstanding = the recommended algorithm?


Maybe the example of @crime.net and @bank.com might add clarity. =  If both have a p=3Dreject policy, and only @crime.net successfully = passes the DMARC check, it would be wise to enforce @bank.com's reject policy, = no?

=3D- = Tim

= --Apple-Mail=_375173F4-4E05-481F-924A-48243B4AFEEB-- From nobody Mon Jan 18 12:01:42 2016 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 79ACA1B3C95 for ; Mon, 18 Jan 2016 12:01:40 -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 wyUQlb5AdA-i for ; Mon, 18 Jan 2016 12:01:39 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 140441B3C8F for ; Mon, 18 Jan 2016 12:01:39 -0800 (PST) Received: by mail-qg0-x234.google.com with SMTP id b35so434281590qge.0 for ; Mon, 18 Jan 2016 12:01:39 -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=vx6KTn+H4DY7220w+rs/bA66c53rmyj3QCHSJjfAfsE=; b=a4pzmcYBRV59wfVcSnnXRVfOpLqHbVQrpiJeFps6M9kk0R5SW1p6SXkyw8jnV7j/dy hJH+SaB6bO1lL80sCFIYGC4EoQYN6y+KRSL7sACB27R6QCX6qu90OkxIMPwclF/qcDuP DzSYgjHBlGJFjW1E8vxnvzeY3jKoFJRgE/gyk= 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=vx6KTn+H4DY7220w+rs/bA66c53rmyj3QCHSJjfAfsE=; b=iSwog9GNFOz9a5zGEyFZt3FJKB2vKAR2ZjN39bSRd/mUSLqwCqQnDPmnK/0s06J5H5 byK/qhf6MQxu2yl3rEKPjaJJXVC0W7u0nROn05iWErihr+2jdqUQ9u/xX7LVlR9lWriA hyfQJf3+TqH2Bl38JDSsqm1T7VqwZBLRrjIlg4hJKsS5cu5lqiQMbjpP3nktQEbV39OS QenkvzjG5K2nNLAH9Bdeha7JV7yjTRJ9O5uEdTVEmYlw2cNwzn9kyAqtqJlQ/tYs3eD5 WSTIZx/EIHnw3IQVnLQW8PkOAP+mNeR/w71weOt9q3qBKmZL83XFdLFWr07eMIIKWgZa MMMg== X-Gm-Message-State: ALoCoQm4M0H4JaC9hVUqMxDeKvCseuuugozd5e5Owz3c06oIIzKqvuSqrgKsb1aQ1nVXht+8mOStCD0BQ9vIlDig8o7uziMNvg== MIME-Version: 1.0 X-Received: by 10.140.28.66 with SMTP id 60mr33119065qgy.74.1453147298152; Mon, 18 Jan 2016 12:01:38 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.42.67 with HTTP; Mon, 18 Jan 2016 12:01:38 -0800 (PST) Date: Mon, 18 Jan 2016 12:01:38 -0800 X-Google-Sender-Auth: 1_5hbT28xTzz9kYMZqGlZKPyaDA Message-ID: From: "Kurt Andersen (b)" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113a5fba836a2c0529a1388c Archived-At: Subject: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-14 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, 18 Jan 2016 20:01:40 -0000 --001a113a5fba836a2c0529a1388c Content-Type: text/plain; charset=UTF-8 A new version of I-D, draft-ietf-dmarc-interoperability-14.txt has been successfully submitted by Kurt Andersen and posted to the IETF repository. This version incorporates all of the comments that have been received during last call; particularly those from Steven Turnbull (clarifying some of the wording in section 2.1) and Eliot Lear (adding Appendix A to help explain the issue with bounce message handling). Please let me know if my interpretations of the feedback diverge from the intended comments and questions. --Kurt Name: draft-ietf-dmarc-interoperability Revision: 14 Title: Interoperability Issues Between DMARC and Indirect Email Flows Document date: 2016-01-18 Group: dmarc Pages: 25 URL: https://www.ietf.org/internet-drafts/draft-ietf-dmarc-interoperability-14.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ Htmlized: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-14 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-14 --001a113a5fba836a2c0529a1388c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A new version of I-D, draft-ietf-dmarc-interoperability-14= .txt=C2=A0has been successfully submitted by Kurt Andersen and posted to th= e=C2=A0IETF repository.

This version incorporates all of= the comments that have been received during last call; particularly those = from Steven Turnbull (clarifying some of the wording in section 2.1) and El= iot Lear (adding Appendix A to help explain the issue with bounce message h= andling).

Please let me know if my interpretations= of the feedback diverge from the intended comments and questions.

--Kurt

Name: = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-dmarc-interoperability
Rev= ision: =C2=A0 =C2=A0 =C2=A0 14
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Interoperability Issues Between DMARC and Indirect Email Flows
Document = date: =C2=A02016-01-18
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dmarcPages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A025
URL: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/dra= ft-ietf-dmarc-interoperability-14.txt
Status: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperabil= ity/
Htmlized: =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/dr= aft-ietf-dmarc-interoperability-14
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmarc-inte= roperability-14
--001a113a5fba836a2c0529a1388c-- From nobody Tue Jan 19 14:07:08 2016 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 85EE41B36D3 for ; Tue, 19 Jan 2016 14:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, 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 L9nieK2h_2ww for ; Tue, 19 Jan 2016 14:07:03 -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 503231B36D2 for ; Tue, 19 Jan 2016 14:07:01 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 80D50563E75; Tue, 19 Jan 2016 16:07:01 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 7149BA12FA; Tue, 19 Jan 2016 16:07:01 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xtNp5NitPht; Tue, 19 Jan 2016 16:07:01 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3AFBBA1370; Tue, 19 Jan 2016 16:07:01 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 3AFBBA1370 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1453241221; bh=j1ZzCb8fBcn4jYIOgfdTpxbw0Rl+neGfsrm9X85d3Wk=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=AVX5v/h3uylJ/vCX4liorZjVcBRq9rmzXIjrHSQ25H4Os991hfXha5x9BY4+11j4X nkRfNbVaq4AAadLylla1AxAqGNICk949+8pZugSaaDc+X2Ck89f7Aw7gStAIsE7CmD MAemhafSC5gKi3L6rwLbovnDmzlDjwA0SxXUkyFQ= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 11A87A12FF; Tue, 19 Jan 2016 16:07:01 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DD3E7Fy4Rvv9; Tue, 19 Jan 2016 16:07:00 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id CF739A12FA; Tue, 19 Jan 2016 16:07:00 -0600 (CST) Date: Tue, 19 Jan 2016 16:06:59 -0600 (CST) From: Franck Martin To: Tim Draegen Message-ID: <1127345667.21995.1453241219730.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <2E692A5B-1D15-4A17-989E-F7A1DF930088@eudaemon.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21994_197732168.1453241219729" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF43 (Mac)/8.0.5_GA_5839) Thread-Topic: Clarification question on handling multiple domains in RFC5322.from (section 6.6.1) Thread-Index: +FNEwLkK5QNWpxk027PW38VoTAI6UQ== Archived-At: Cc: dmarc@ietf.org, "Kurt Andersen \(b\)" Subject: Re: [dmarc-ietf] Clarification question on handling multiple domains in RFC5322.from (section 6.6.1) 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, 19 Jan 2016 22:07:07 -0000 ------=_Part_21994_197732168.1453241219729 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Yes, you look at all the DMARC policies you can find, select the ones with the most strict policy reject>quarantine>none and if any reject policy gets a dmarc fails you reject the email... You err in the side of caution rather than permission. ----- Original Message ----- From: "Tim Draegen" To: "Kurt Andersen (b)" Cc: dmarc@ietf.org Sent: Monday, January 18, 2016 10:02:50 AM Subject: Re: [dmarc-ietf] Clarification question on handling multiple domains in RFC5322.from (section 6.6.1) On Jan 18, 2016, at 12:49 PM, Kurt Andersen (b) < kboth@drkurt.com > wrote: Am I misunderstanding the recommended algorithm? Maybe the example of @ crime.net and @ bank.com might add clarity. If both have a p=reject policy, and only @ crime.net successfully passes the DMARC check, it would be wise to enforce @ bank.com 's reject policy, no? =- Tim _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ------=_Part_21994_197732168.1453241219729 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes, you look at all the DMARC polici= es you can find, select the ones with the most strict policy reject>quar= antine>none and if any reject policy gets a dmarc fails you reject the e= mail... You err in the side of caution rather than permission.

From: "Tim Draegen" <tim@eudaemon.ne= t>
To: "Kurt Andersen (b)" <kboth@drkurt.com>
Cc: = dmarc@ietf.org
Sent: Monday, January 18, 2016 10:02:50 AM
= Subject: Re: [dmarc-ietf] Clarification question on handling multipl= e domains in RFC5322.from (section 6.6.1)

On Jan 18, 2016, at 12:49 PM, Kurt Andersen (b= ) <kboth@drkurt.com> wrote:
=
Am I misunderstanding the recomme= nded algorithm?


Maybe the example of @crime.net and @bank.com might add = clarity.  If both have a p=3Dreject policy, and only @crime.net successfully passes the DMARC check, it would be wise = to enforce @bank.com's reject policy, no?

=3D- Tim
=

_______________________________________________dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listi= nfo/dmarc

------=_Part_21994_197732168.1453241219729-- From nobody Wed Jan 20 00:17:47 2016 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 6BD8D1B3C8C; Mon, 18 Jan 2016 11:54:35 -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.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160118195435.3176.99116.idtracker@ietfa.amsl.com> Date: Mon, 18 Jan 2016 11:54:35 -0800 Archived-At: X-Mailman-Approved-At: Wed, 20 Jan 2016 00:17:46 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-14.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, 18 Jan 2016 19:54:35 -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-14.txt Pages : 25 Date : 2016-01-18 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-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-14 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/