From nobody Tue Aug 18 08:21: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 274851B30BE; Mon, 17 Aug 2015 19:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TPh6nocLr3SY; Mon, 17 Aug 2015 19:09:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D604B1A8A4C; Mon, 17 Aug 2015 19:09:02 -0700 (PDT) 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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150818020902.30524.83899.idtracker@ietfa.amsl.com> Date: Mon, 17 Aug 2015 19:09:02 -0700 Archived-At: X-Mailman-Approved-At: Tue, 18 Aug 2015 08:21:55 -0700 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 02:09:04 -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-05.txt Pages : 22 Date : 2015-08-17 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-05 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 Fri Aug 21 14:07:14 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 2150E1ACE1A for ; Fri, 21 Aug 2015 14:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-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 RNhzEb0pOAY1 for ; Fri, 21 Aug 2015 14:07:08 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B191ACE0E for ; Fri, 21 Aug 2015 14:07:08 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B6CE2C40477 for ; Fri, 21 Aug 2015 16:09:58 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1440191398; bh=mvgH4iKrYFPwZdYWqFr2H6rksWAPQ7LioRiF4dew1vI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Wl++gfNW5aNtqmtUQ+SXxoh99NfW+75PKB1ySpuo4+l/ZBxWWaw4B5wIAOAlgi/uc gzTPIKreJPRb0LVst7CtTxETb+fcy5WYGC9Ppg5zcNSQPTWJ5WifEby+puj3YOQMyk muBwTYlnRhXheew8lgN84hL3DTL3xlJSGAYTTtgk= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 21 Aug 2015 17:07:03 -0400 Message-ID: <5652619.OdQ08h74Lk@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-58-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20150818020902.30524.83899.idtracker@ietfa.amsl.com> References: <20150818020902.30524.83899.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.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, 21 Aug 2015 21:07:10 -0000 On Monday, August 17, 2015 07:09:02 PM internet-drafts@ietf.org 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. ... Comments: Page 3, Section 1, para 3: "... rejection policies on email flows can be significant ..." I think this should read: "... rejection policies on indirect email flows can be significant ..." otherwise it makes no sense in this paragraph. Page 4, Section 2.1, para 5: Recommend replace this text: SPF can provide two Authenticated Identifiers. The first one is the RFC7208.HELO [RFC7208] based on the RFC5321.HELO/EHLO. The second one 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 domain found in the HELO/ EHLO SMTP command. DMARC uses only the SPF results for the RFC7208.MAILFROM identifier for alignment (this is often true for local policies outside of DMARC as well). With: 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 domain found in the HELO/ EHLO SMTP command. I think it better keeps the focus on what's relevant to DMARC and is clearer. Regarding the last sentence of the paragraph, I would strike it. I'm not aware of anything would be particularly relevant to DMARC nor have I heard anything about issues caused by SPF libraries that haven't been updated. Page 6, section 2.2, second bullet point: SPF may pass/SPF might pass final paragraph: DKIM must be/DKIM will be Page 6, section 2.3, paragraph 2. The length tag is, as far as I know, unused. I would propose replacing the paragraph: Although DKIM provides a length flag so that, in theory, content can be appended without invalidating the signature, in practice, the length flag is seldom used due to security issues (see Section 8.2 of [RFC6376] for additional security considerations). While I agree we ought to mention this for completeness, let's make it clear that's all we're doing. Page 10, section 3.2.2, para 2: I think this paragraph is written backwards: ReSenders introduce DMARC interoperability issues as content modification invalidates DKIM signatures. SPF's ability to grant authorization via alignment is removed as the new Recipient receives the message from the Mediator rather than the initial organization. ReSenders haven't introduced any interoperability issues. DMARC has. How about: The DMARC design does not cope with common ReSender functionality such as content modifications that invalidate DKIM signatures and Mail From rewriting to support SPF authentication of resent mail when the new Recipient receives the message from the Mediator rather than the initial organization. Page 15 section 4.1.1.1, bullet 4: o MTAs sending email on behalf of multiple domains may require Domain Owners to provide DKIM keys to use DKIM to avoid SPF alignment issues. Managing DKIM keys with a third party has security risks which should be carefully managed. This can generally be done through CNAMES or subdomain delegation. I've yet to see anyone handle this situation by actually exchanging private keys across an administrative boundry. I think it's worth discussion (so I don't proppose text) since others may have different experiences. Page 16, section 4.1.3.1, para 2: A first option is to use the Original-From [RFC5703] (or X-Original- From) header field for this purpose in various contexts (X- header fields name are discouraged by [RFC6648]). However, handling of Original-From (or X-Original-From) is not defined anywhere. It is not currently used consistently or displayed to the user, and in any situation where it is used, it is a new unauthenticated identifier available for exploitation unless included within the scope of the new DKIM signature(s). Let's kill the bits about X-. We're past the third anniversary of the RFC that suggests it's a bad idea. I think Original-From is fine, but if people don't want to reuse that, then come up with something more descriptive than X-. Page 19, Section 6: In 4.1.3.3 where it discusses header rewriting, it mentions that this might undermine the effectiveness of DMARC. I think that qualifies as a security consideration that should be addressed (even if only by moving most of the existing text here with a pointer). Hope that helps, Scott K From nobody Fri Aug 21 15:49: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 A35721ACEEB for ; Fri, 21 Aug 2015 15:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn9CarARV5-i for ; Fri, 21 Aug 2015 15:48:59 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5DD1ACDCD for ; Fri, 21 Aug 2015 15:48:58 -0700 (PDT) Received: (qmail 3900 invoked from network); 21 Aug 2015 22:49:14 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Aug 2015 22:49:14 -0000 Date: 21 Aug 2015 22:48:34 -0000 Message-ID: <20150821224834.19670.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <5652619.OdQ08h74Lk@kitterma-e6430> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.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, 21 Aug 2015 22:48:59 -0000 >ReSenders haven't introduced any interoperability issues. DMARC has. How >about: Indeed. I agree with the advice to refrain from blaming the victim. > o MTAs sending email on behalf of multiple domains may require > Domain Owners to provide DKIM keys to use DKIM to avoid SPF > alignment issues. Managing DKIM keys with a third party has > security risks which should be carefully managed. > >This can generally be done through CNAMES or subdomain delegation. I've yet >to see anyone handle this situation by actually exchanging private keys across >an administrative boundary. A manager at a well known ESP told me that one of the free mail suspects gave them a DKIM signing key. (I forget whether it was A or Y.) R's, John From nobody Fri Aug 21 15:56:41 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 CAA1E1ACEE0 for ; Fri, 21 Aug 2015 15:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 50ssH5aI2AUp for ; Fri, 21 Aug 2015 15:56:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81311ACEEA for ; Fri, 21 Aug 2015 15:56:38 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t7LMucwG016199 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 21 Aug 2015 15:56:38 -0700 Message-ID: <55D7ACA4.1040500@dcrocker.net> Date: Fri, 21 Aug 2015 15:56:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150821224834.19670.qmail@ary.lan> In-Reply-To: <20150821224834.19670.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 21 Aug 2015 15:56:38 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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, 21 Aug 2015 22:56:40 -0000 On 8/21/2015 3:48 PM, John Levine wrote: >> ReSenders haven't introduced any interoperability issues. DMARC has. How >> about: > > Indeed. I agree with the advice to refrain from blaming the victim. On the average, a failure of a new mechanism to fully interoperate should never be cast as the responsibility of an entity that has been functioning legitimately since long before the new mechanism was defined. And to nitpick, I believe the relevant architectural classification for the entity of concern here is "Mediator". "Resender" is a subset and does not cover, for example, Mailings lists or Gateways. See RFC 5598. >> o MTAs sending email on behalf of multiple domains may require >> Domain Owners to provide DKIM keys to use DKIM to avoid SPF >> alignment issues. Managing DKIM keys with a third party has >> security risks which should be carefully managed. >> >> This can generally be done through CNAMES or subdomain delegation. I've yet >> to see anyone handle this situation by actually exchanging private keys across >> an administrative boundary. > > A manager at a well known ESP told me that one of the free mail > suspects gave them a DKIM signing key. (I forget whether it was A or > Y.) Is SPF "alignment" a valid term here? (The term does not appear in the SPF spec.) I thought 'alignment' was first defined in this space for DMARC and that it does not have formal meaning for SPF or DKIM. I assume what is meant is simply SPF validation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 21 16:20:33 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 EE7A71AD0B6 for ; Fri, 21 Aug 2015 16:20:31 -0700 (PDT) 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 3ghWTrfaUVPd for ; Fri, 21 Aug 2015 16:20:31 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 1BB3E1AD0BC for ; Fri, 21 Aug 2015 16:20:31 -0700 (PDT) Received: by padfo6 with SMTP id fo6so16442109pad.1 for ; Fri, 21 Aug 2015 16:20:30 -0700 (PDT) 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=gVTUjf9Q1QT+e8WRWw4/25uW6VD4Yd1WfKx39OqU8zM=; b=GSGSsj/SIW2NrfQj7m+I9eMelNr5/0ALA8q+aZ1Qk4uIU3tlS/8XxspHuVXWLjRjJe PFYWZpAVyOlSHzCfmSRCx1+r9S+heIyr1xX5LUpT52gJqiBWGqxfl5a4rPdFutyaP36Q 3IE+SW8Str2F7VygTioYr4tBlx8ZiKfPfZgb4= 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=gVTUjf9Q1QT+e8WRWw4/25uW6VD4Yd1WfKx39OqU8zM=; b=HwaWsACzHwPJm8kw5j4tUomprL7qYGXCpl2Cw2xJ4Jkcd8+pGVpPK4WwlYp0igMiNM lwr7UKoMjFt9nEUtgKa7+jby8RgqjwLgvVJK2rt5H18qkqmXD4DoOvWZgqVFK0+pMPQ4 KXZAa1rZMhO5gPhwZzwYbEcLg4gy22gYicwqBiVqvsb3UBT60iBsaMq47z1ihKcT9DZt +pjh4bAtwdgWhTwwvrUG6C1wX0o6BNDJdhvEOuVMGco9GxypZTHEHKaavwXDWoByqtXt FkMcEMGrA3l0cfF/5dtsVIEqBz4B6MTGS0hTKhsGL0iFH2WEIJCanHotTI0OEeLHXTEt Jf5g== X-Gm-Message-State: ALoCoQmjYL3Q7+3jKKVCeakyOeFim1gCpeBB/rROsoUZH2BOvLVsuThTdbGzb0arUs7C7+hyQXR/ MIME-Version: 1.0 X-Received: by 10.68.218.65 with SMTP id pe1mr21639319pbc.2.1440199230799; Fri, 21 Aug 2015 16:20:30 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.66.158.197 with HTTP; Fri, 21 Aug 2015 16:20:30 -0700 (PDT) Date: Fri, 21 Aug 2015 16:20:30 -0700 X-Google-Sender-Auth: -qJzAtd9YoMGdzVbHHqQe2NPixo Message-ID: From: "Kurt Andersen (b)" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ff256ac8edcde051dda8361 Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.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, 21 Aug 2015 23:20:32 -0000 --e89a8ff256ac8edcde051dda8361 Content-Type: text/plain; charset=UTF-8 Thanks to all who have contributed comments and suggestions. I'll wait until mid-next week to fold them all into the document. --Kurt Andersen --e89a8ff256ac8edcde051dda8361 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks to all who have contributed comments and suggestion= s. I'll wait until mid-next week to fold them all into the document.

--Kurt Andersen
--e89a8ff256ac8edcde051dda8361-- From nobody Fri Aug 21 17:30:45 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 EAE211AD0AF for ; Fri, 21 Aug 2015 16:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 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, MISSING_HEADERS=1.021, 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 kpJrGLERfSCb for ; Fri, 21 Aug 2015 16:16:45 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 D4A601AD0AE for ; Fri, 21 Aug 2015 16:16:45 -0700 (PDT) Received: by pacgr6 with SMTP id gr6so3467011pac.0 for ; Fri, 21 Aug 2015 16:16:45 -0700 (PDT) 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:cc :content-type; bh=JqQzAwCxVXFdA24bD0bASa725q9TbEyfS+jNdTaH2VE=; b=QVZ4QVOtuE54fIXvhIkBOmAeWwPAdIi5ybt0GjKHouqqRuvBWa1XeIz9wwa8uLKDH5 wyGKcjaCnY6hzZXDUNBZjZUzql6+nPsBF7F9KS4zCYU99+Nt0CiAzvpyTYz+SFZUGYJS eFwWF4tRqccw2udqJfXezbVgbG5Fu7Hh7ugPQ= 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:cc:content-type; bh=JqQzAwCxVXFdA24bD0bASa725q9TbEyfS+jNdTaH2VE=; b=Lv5qdP+hUhTWrXKYfkoXydGLKcQix4qhQoYjMVsyTjsM2Ux9YSkY3BfqJglzUmsJ55 jN2nFjOlytVnR5Vfxl768mzk6O11O6BxvmZCWW8sfztLpNzBXTHmuVoScoRMx9Ticecq tAYJSszdWDxcD1JdGRJMh00q1+zLFBMD0XHyZqUW/YqxqPyohpB9Mb7n+zsDIi0x7L5e EsDNLPK79qa5Q8YQ4NMH4l/A7MYiBwoBlthIs9Bft2cJGI7zQshcfHVh98BOi35h+Ou7 ESSQ7LkNJRthwC/Gua4fv+44ZG8O02dC/PRVeQkMJi12K4JdpVH7mm8YwTVfISXwURpp Igqw== X-Gm-Message-State: ALoCoQkfPwyMC9AcMMSKcenTdn6HyGBAVAGjFuuwqHMHPgUnrs9Pz4mw6ab+PjmWm5hFb0+bQGx0 MIME-Version: 1.0 X-Received: by 10.68.68.166 with SMTP id x6mr21606580pbt.101.1440199005382; Fri, 21 Aug 2015 16:16:45 -0700 (PDT) Received: by 10.66.158.197 with HTTP; Fri, 21 Aug 2015 16:16:45 -0700 (PDT) In-Reply-To: <55D7ACA4.1040500@dcrocker.net> References: <20150821224834.19670.qmail@ary.lan> <55D7ACA4.1040500@dcrocker.net> Date: Fri, 21 Aug 2015 16:16:45 -0700 Message-ID: From: Kurt Andersen Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113806a61f48a9051dda7662 Archived-At: X-Mailman-Approved-At: Fri, 21 Aug 2015 17:30:44 -0700 Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.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, 21 Aug 2015 23:16:50 -0000 --001a113806a61f48a9051dda7662 Content-Type: text/plain; charset=UTF-8 Thanks to all who have contributed comments and suggestions. I'll wait until mid-next week to fold them all into the document. --Kurt --001a113806a61f48a9051dda7662 Content-Type: text/html; charset=UTF-8
Thanks to all who have contributed comments and suggestions. I'll wait until mid-next week to fold them all into the document.

--Kurt

--001a113806a61f48a9051dda7662-- From nobody Fri Aug 28 17:41:32 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 215B61B376B for ; Fri, 28 Aug 2015 17:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.089 X-Spam-Level: X-Spam-Status: No, score=-3.089 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_14=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 WQ6OZzY8TJpR for ; Fri, 28 Aug 2015 17:41:26 -0700 (PDT) Received: from mail321.linkedin.com (mail321.linkedin.com [108.174.3.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316AE1B3751 for ; Fri, 28 Aug 2015 17:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1440808884; bh=9akzF4R8SBQOvOyJe/SaWz+q/IvkVBhJd/dwah9kYJE=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=TZODHw5FzNlhgTcBov55SCAVgwiDD6Lbd4Zzxf5qL06uwerDTZ6uVst3/aYvv8AJZ j0lvyydhhE1duI9C5n5v1ztBG8ZZzZXYfqqLqDPUef4psfQpNqEqBBKxoeNcAOEHxJ FXT1ZxniZ/xp7hzBX6dOKvfgI3Q10NQfv+nKbO7A= Authentication-Results: mail321.prod x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail321.prod.linkedin.com; iprev=pass policy.iprev="209.85.192.41"; spf=softfail smtp.mailfrom="fmartin@linkedin.com" smtp.helo="mail-qg0-f41.google.com"; dkim=none (message not signed) header.d=none; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [209.85.192.41] ([209.85.192.41:34051] helo=mail-qg0-f41.google.com) by mail321.prod (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id 3D/71-25981-4BFF0E55; Sat, 29 Aug 2015 00:41:24 +0000 Received: by qgi69 with SMTP id 69so9989030qgi.1 for ; Fri, 28 Aug 2015 17:41:24 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type; bh=9akzF4R8SBQOvOyJe/SaWz+q/IvkVBhJd/dwah9kYJE=; b=KmGFP7WMhy48QzqviMkeieQoLuMed4MquKBqFIZvEGI0OEIK4NXcqUg1LY/wev3/ey 2fPi8D2SkJ+/2/UaOXjCO8YYaLOOICgzpQhqLYefOSqVBpuJsTt6OIlVGP7y1cpU2rQ0 zGQekbLQUTNhAZd3pfoD/5FaGdahtkgi6W8XRBO8WAQaNVNK4yzCqHauuB0PSOrvdhRc OQoIQpeIQoL+dbRIuzKaqT1PstwyqYHWkdoBuwOYn0UV7MQVDjEOTDVF6fPioqyqWBhS yuO/qNqL3g+OvZH1UNWVu9tBwcnsrIb5xJaUmqKkKZU/9Ny4mFDP3BElANl1UrZlWlmt EiWg== X-Gm-Message-State: ALoCoQnNY4IWCGzWfqgIEjS+ARD8BhSTkWZ4/IL1uoc/RNFaoRuCAYBYf/iwr8ls0vzs/iSUdQpe30tsDo5IJPwFHmpOmZHuEiB9voocI2DI7ZO5/+YhVffFs7pXIM97rMcygEma1x3mf4MWghmEAHh9CL4Vktgyiw== X-Received: by 10.140.133.135 with SMTP id 129mr21579238qhf.95.1440808884155; Fri, 28 Aug 2015 17:41:24 -0700 (PDT) X-Received: by 10.140.133.135 with SMTP id 129mr21579219qhf.95.1440808883966; Fri, 28 Aug 2015 17:41:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.89.49 with HTTP; Fri, 28 Aug 2015 17:41:04 -0700 (PDT) In-Reply-To: <5652619.OdQ08h74Lk@kitterma-e6430> References: <20150818020902.30524.83899.idtracker@ietfa.amsl.com> <5652619.OdQ08h74Lk@kitterma-e6430> From: Franck Martin Date: Fri, 28 Aug 2015 17:41:04 -0700 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a1136fd7cb7fe7f051e68753b Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.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: Sat, 29 Aug 2015 00:41:29 -0000 --001a1136fd7cb7fe7f051e68753b Content-Type: text/plain; charset=UTF-8 On Fri, Aug 21, 2015 at 2:07 PM, Scott Kitterman wrote: > On Monday, August 17, 2015 07:09:02 PM internet-drafts@ietf.org 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. > ... > Comments: > > Page 3, Section 1, para 3: > > "... rejection policies on email flows can be significant ..." > > I think this should read: > > "... rejection policies on indirect email flows can be significant ..." > > otherwise it makes no sense in this paragraph. > done > > Page 4, Section 2.1, para 5: > > Recommend replace this text: > > SPF can provide two Authenticated Identifiers. The first one is the > RFC7208.HELO [RFC7208] based on the RFC5321.HELO/EHLO. The second > one 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 domain found in the HELO/ > EHLO SMTP command. DMARC uses only the SPF results for the > RFC7208.MAILFROM identifier for alignment (this is often true for > local policies outside of DMARC as well). > > With: > > 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 domain found in the HELO/ > EHLO SMTP command. > > I think it better keeps the focus on what's relevant to DMARC and is > clearer. > slightly reworded to still indicate SPF provides 2 identifiers. > > Regarding the last sentence of the paragraph, I would strike it. I'm not > aware of anything would be particularly relevant to DMARC nor have I heard > anything about issues caused by SPF libraries that haven't been updated. > > Page 6, section 2.2, second bullet point: > > SPF may pass/SPF might pass > > final paragraph: > > DKIM must be/DKIM will be > > Page 6, section 2.3, paragraph 2. > done > > The length tag is, as far as I know, unused. I would propose replacing the > paragraph: > > Although DKIM provides a length flag so that, in theory, content can be > appended without invalidating the signature, in practice, the length > flag is > seldom used due to security issues (see Section 8.2 of [RFC6376] for > additional security considerations). > > While I agree we ought to mention this for completeness, let's make it > clear > that's all we're doing. > > Page 10, section 3.2.2, para 2: > > I think this paragraph is written backwards: > > > ReSenders introduce DMARC interoperability issues as content > modification invalidates DKIM signatures. SPF's ability to grant > authorization via alignment is removed as the new Recipient receives > the message from the Mediator rather than the initial organization. > > ReSenders haven't introduced any interoperability issues. DMARC has. How > about: > > The DMARC design does not cope with common ReSender functionality > such as content modifications that invalidate DKIM signatures and Mail > From > rewriting to support SPF authentication of resent mail when the new > Recipient receives the message from the Mediator rather than the initial > organization. > done > > Page 15 section 4.1.1.1, bullet 4: > > > o MTAs sending email on behalf of multiple domains may require > Domain Owners to provide DKIM keys to use DKIM to avoid SPF > alignment issues. Managing DKIM keys with a third party has > security risks which should be carefully managed. > > This can generally be done through CNAMES or subdomain delegation. I've > yet > to see anyone handle this situation by actually exchanging private keys > across > an administrative boundry. I think it's worth discussion (so I don't > proppose > text) since others may have different experiences. > There is M3AAWG BCP on parked domains that treat on this subject. > > Page 16, section 4.1.3.1, para 2: > > > A first option is to use the Original-From [RFC5703] (or X-Original- > From) header field for this purpose in various contexts (X- header > fields name are discouraged by [RFC6648]). However, handling of > Original-From (or X-Original-From) is not defined anywhere. It is > not currently used consistently or displayed to the user, and in any > situation where it is used, it is a new unauthenticated identifier > available for exploitation unless included within the scope of the > new DKIM signature(s). > > Let's kill the bits about X-. We're past the third anniversary of the RFC > that suggests it's a bad idea. I think Original-From is fine, but if > people > don't want to reuse that, then come up with something more descriptive than > X-. > Bad idea, but I still see it in emails... so in practice is very much in use, therefore I prefer to name it and say it is a bad idea. > > Page 19, Section 6: > > In 4.1.3.3 where it discusses header rewriting, it mentions that this might > undermine the effectiveness of DMARC. I think that qualifies as a security > consideration that should be addressed (even if only by moving most of the > existing text here with a pointer). > hmm, let's see what you think of the text I provide. > > Hope that helps, > > It does indeed --001a1136fd7cb7fe7f051e68753b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 21, 2015 at 2:07 PM, Scott Kitterman <= sklist@kitterman.= com> wrote:
On Monday, August 17, 2015 07:09:02 PM internet-drafts@ietf.org 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.=
...
Comments:

Page 3, Section 1, para 3:

"... rejection policies on email flows can be significant ..."
I think this should read:

"... rejection policies on indirect email flows can be significant ...= "

otherwise it makes no sense in this paragraph.

done
=C2=A0

Page 4, Section 2.1, para 5:

Recommend replace this text:

=C2=A0 =C2=A0SPF can provide two Authenticated Identifiers.=C2=A0 The first= one is the
=C2=A0 =C2=A0RFC7208.HELO [RFC7208] based on the RFC5321.HELO/EHLO.=C2=A0 T= he second
=C2=A0 =C2=A0one is the RFC7208.MAILFROM [RFC7208] based on the RFC5321.Mai= lFrom
=C2=A0 =C2=A0[RFC5321] domain, or, if the RFC5321.MailFrom address is absen= t (as
=C2=A0 =C2=A0in the case of "bounce" messages, on the domain foun= d in the HELO/
=C2=A0 =C2=A0EHLO SMTP command.=C2=A0 DMARC uses only the SPF results for t= he
=C2=A0 =C2=A0RFC7208.MAILFROM identifier for alignment (this is often true = for
=C2=A0 =C2=A0local policies outside of DMARC as well).

With:

=C2=A0 =C2=A0The DMARC relevant Authenticated Identifiers that SPF provides= is the
=C2=A0 =C2=A0RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom
=C2=A0 =C2=A0[RFC5321] domain, or, if the RFC5321.MailFrom address is absen= t (as
=C2=A0 =C2=A0in the case of "bounce" messages, on the domain foun= d in the HELO/
=C2=A0 =C2=A0EHLO SMTP command.

I think it better keeps the focus on what's relevant to DMARC and is cl= earer.

slightly reworded to still indic= ate SPF provides 2 identifiers.
=C2=A0

Regarding the last sentence of the paragraph, I would strike it.=C2=A0 I= 9;m not
aware of anything would be particularly relevant to DMARC nor have I heard<= br> anything about issues caused by SPF libraries that haven't been updated= .

Page 6, section 2.2, second bullet point:

SPF may pass/SPF might pass

final paragraph:

DKIM must be/DKIM will be

Page 6, section 2.3, paragraph 2.

done<= /div>
=C2=A0

The length tag is, as far as I know, unused.=C2=A0 I would propose replacin= g the
paragraph:

=C2=A0 =C2=A0Although DKIM provides a length flag so that, in theory, conte= nt can be
=C2=A0 =C2=A0appended without invalidating the signature, in practice, the = length flag is
=C2=A0 =C2=A0seldom used due to security issues (see Section 8.2 of [RFC637= 6] for
=C2=A0 =C2=A0additional security considerations).

While I agree we ought to mention this for completeness, let's make it = clear
that's all we're doing.

Page 10, section 3.2.2, para 2:

I think this paragraph is written backwards:


=C2=A0 =C2=A0ReSenders introduce DMARC interoperability issues as content =C2=A0 =C2=A0modification invalidates DKIM signatures.=C2=A0 SPF's abil= ity to grant
=C2=A0 =C2=A0authorization via alignment is removed as the new Recipient re= ceives
=C2=A0 =C2=A0the message from the Mediator rather than the initial organiza= tion.

ReSenders haven't introduced any interoperability issues.=C2=A0 DMARC h= as.=C2=A0 How
about:

=C2=A0 =C2=A0The DMARC design does not cope with common ReSender functional= ity
=C2=A0 =C2=A0such as content modifications that invalidate DKIM signatures = and Mail From
=C2=A0 =C2=A0rewriting to support SPF authentication of resent mail when th= e new
=C2=A0 =C2=A0Recipient receives the message from the Mediator rather than t= he initial
=C2=A0 =C2=A0organization.

done
=C2=A0

Page 15 section 4.1.1.1, bullet 4:


=C2=A0 =C2=A0o=C2=A0 MTAs sending email on behalf of multiple domains may r= equire
=C2=A0 =C2=A0 =C2=A0 Domain Owners to provide DKIM keys to use DKIM to avoi= d SPF
=C2=A0 =C2=A0 =C2=A0 alignment issues.=C2=A0 Managing DKIM keys with a thir= d party has
=C2=A0 =C2=A0 =C2=A0 security risks which should be carefully managed.

This can generally be done through CNAMES or subdomain delegation.=C2=A0 I&= #39;ve yet
to see anyone handle this situation by actually exchanging private keys acr= oss
an administrative boundry.=C2=A0 I think it's worth discussion (so I do= n't proppose
text) since others may have different experiences.
There is M3AAWG BCP on parked domains that treat on this subjec= t.
=C2=A0

Page 16, section 4.1.3.1, para 2:


=C2=A0 =C2=A0A first option is to use the Original-From [RFC5703] (or X-Ori= ginal-
=C2=A0 =C2=A0From) header field for this purpose in various contexts (X- he= ader
=C2=A0 =C2=A0fields name are discouraged by [RFC6648]).=C2=A0 However, hand= ling of
=C2=A0 =C2=A0Original-From (or X-Original-From) is not defined anywhere.=C2= =A0 It is
=C2=A0 =C2=A0not currently used consistently or displayed to the user, and = in any
=C2=A0 =C2=A0situation where it is used, it is a new unauthenticated identi= fier
=C2=A0 =C2=A0available for exploitation unless included within the scope of= the
=C2=A0 =C2=A0new DKIM signature(s).

Let's kill the bits about X-.=C2=A0 We're past the third anniversar= y of the RFC
that suggests it's a bad idea.=C2=A0 I think Original-From is fine, but= if people
don't want to reuse that, then come up with something more descriptive = than
X-.

Bad idea, but I still see it in ema= ils... so in practice is very much in use, therefore I prefer to name it an= d say it is a bad idea.
=C2=A0

Hope that helps,

It does indeed=C2=A0
--001a1136fd7cb7fe7f051e68753b-- From nobody Fri Aug 28 17:46: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 B33BD1B37B3 for ; Fri, 28 Aug 2015 17:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.689 X-Spam-Level: X-Spam-Status: No, score=-3.689 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, 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 hrlhA6QAQFvf for ; Fri, 28 Aug 2015 17:46:45 -0700 (PDT) Received: from mail321.linkedin.com (mail321.linkedin.com [108.174.3.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F22D1B37B4 for ; Fri, 28 Aug 2015 17:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1440809204; bh=E83L/+DlFUxS01qWK/qt4hP9/jJfZjZeNdig9PBfBTU=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=DtvTvQx8ew6bfc/3YW7CLlxtFn7sAOBYgfpIRlkpcQmJ1MXH1CPRKP8UWK5vqdfks nFMm5/4yAjBVvuNkA7W0WcZRbGMM1ViW6El5GOr4pYrnUUbAfy57n3EBxxBZSr8dgI 5D4/V5ZTPloQiv/2+bxkQJ4LkvWUiI8JsTGJ8wxo= Authentication-Results: mail321.prod x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail321.prod.linkedin.com; iprev=pass policy.iprev="209.85.192.49"; spf=softfail smtp.mailfrom="fmartin@linkedin.com" smtp.helo="mail-qg0-f49.google.com"; dkim=none (message not signed) header.d=none; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [209.85.192.49] ([209.85.192.49:34693] helo=mail-qg0-f49.google.com) by mail321.prod (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id 94/92-25981-4F001E55; Sat, 29 Aug 2015 00:46:44 +0000 Received: by qgi69 with SMTP id 69so10030048qgi.1 for ; Fri, 28 Aug 2015 17:46:43 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type; bh=E83L/+DlFUxS01qWK/qt4hP9/jJfZjZeNdig9PBfBTU=; b=flXSD8SMXN0GmJGrBjl9v22bHlmg4Vh4fu9MhKTqksw9nVKpRYfaLlMY2W8IuP13Vl jIoaUJfk/E/i9qmI3gIlCpZkHAhW1ErTfZm9Xw0ky80lldyH/7ZAlTMRycAxbHcvHiL9 oN8RJH+cEOmprwUTC9xS171PGYybUGLaxSDRWWDIJ7yoa323k1liMsjYJ1fHv/IkY98w 7+Zk2KfkxSNrvOOkSimZZqXiGe9zs5RAJgEcezOzyzSNT+M3Kqcp+RDNjfAFIua7zAXJ 4pTNVV9A2KHcKtc5K6D1LS/OdSmX2+U6axi85IFHfjJPABtxjFGjHZU3sI0h22ypp2hl sYGA== X-Gm-Message-State: ALoCoQmyO4ljen5uVBdsLWIud26hZLxLUuAwVYJ092L+6mukg0iAS58sjq9MAywAbRLNnMYgfn9K/MzGoXtqxEuRWItOyrhxl4uIWe1sr9pHpFEO3ELwCTKTkDOgd9wwyvuitu0r0/NES3dCup5bNLiMSmIWHm+eJg== X-Received: by 10.140.232.201 with SMTP id d192mr20879676qhc.73.1440809203699; Fri, 28 Aug 2015 17:46:43 -0700 (PDT) X-Received: by 10.140.232.201 with SMTP id d192mr20879662qhc.73.1440809203565; Fri, 28 Aug 2015 17:46:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.89.49 with HTTP; Fri, 28 Aug 2015 17:46:24 -0700 (PDT) In-Reply-To: <55D7ACA4.1040500@dcrocker.net> References: <20150821224834.19670.qmail@ary.lan> <55D7ACA4.1040500@dcrocker.net> From: Franck Martin Date: Fri, 28 Aug 2015 17:46:24 -0700 Message-ID: To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=001a1135388ac4aba5051e688895 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.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: Sat, 29 Aug 2015 00:46:46 -0000 --001a1135388ac4aba5051e688895 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 21, 2015 at 3:56 PM, Dave Crocker wrote: > On 8/21/2015 3:48 PM, John Levine wrote: > >> ReSenders haven't introduced any interoperability issues. DMARC has. > How > >> about: > > > > Indeed. I agree with the advice to refrain from blaming the victim. > > On the average, a failure of a new mechanism to fully interoperate > should never be cast as the responsibility of an entity that has been > functioning legitimately since long before the new mechanism was defined. > > And to nitpick, I believe the relevant architectural classification for > the entity of concern here is "Mediator". "Resender" is a subset and > does not cover, for example, Mailings lists or Gateways. See RFC 5598. > ok, therefore moved to right section > > > >> o MTAs sending email on behalf of multiple domains may require > >> Domain Owners to provide DKIM keys to use DKIM to avoid SPF > >> alignment issues. Managing DKIM keys with a third party has > >> security risks which should be carefully managed. > >> > >> This can generally be done through CNAMES or subdomain delegation. > I've yet > >> to see anyone handle this situation by actually exchanging private keys > across > >> an administrative boundary. > > > > A manager at a well known ESP told me that one of the free mail > > suspects gave them a DKIM signing key. (I forget whether it was A or > > Y.) > > Is SPF "alignment" a valid term here? (The term does not appear in the > SPF spec.) I thought 'alignment' was first defined in this space for > DMARC and that it does not have formal meaning for SPF or DKIM. I > assume what is meant is simply SPF validation. > It is DMARC alignment with SPF, the confusion between SPF and DMARC-SPF lives on... --001a1135388ac4aba5051e688895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 21, 2015 at 3:56 PM, Dave Crocker <dhc@dcrocker.net>= wrote:
On 8/21/2= 015 3:48 PM, John Levine wrote:
>> ReSenders haven't introduced any interoperability issues.=C2= =A0 DMARC has.=C2=A0 How
>> about:
>
> Indeed.=C2=A0 I agree with the advice to refrain from blaming the vict= im.

On the average, a failure of a new mechanism to fully interoperate should never be cast as the responsibility of an entity that has been
functioning legitimately since long before the new mechanism was defined.
And to nitpick, I believe the relevant architectural classification for
the entity of concern here is "Mediator".=C2=A0 "Resender&qu= ot; is a subset and
does not cover, for example, Mailings lists or Gateways.=C2=A0 See RFC 5598= .

ok, therefore moved to right section<= /div>
=C2=A0


>>=C2=A0 =C2=A0o=C2=A0 MTAs sending email on behalf of multiple domai= ns may require
>>=C2=A0 =C2=A0 =C2=A0 Domain Owners to provide DKIM keys to use DKIM= to avoid SPF
>>=C2=A0 =C2=A0 =C2=A0 alignment issues.=C2=A0 Managing DKIM keys wit= h a third party has
>>=C2=A0 =C2=A0 =C2=A0 security risks which should be carefully manag= ed.
>>
>> This can generally be done through CNAMES or subdomain delegation.= =C2=A0 I've yet
>> to see anyone handle this situation by actually exchanging private= keys across
>> an administrative boundary.
>
> A manager at a well known ESP told me that one of the free mail
> suspects gave them a DKIM signing key.=C2=A0 (I forget whether it was = A or
> Y.)

Is SPF "alignment" a valid term here?=C2=A0 (The term does= not appear in the
SPF spec.) I thought 'alignment' was first defined in this space fo= r
DMARC and that it does not have formal meaning for SPF or DKIM.=C2=A0 I
assume what is meant is simply SPF validation.

It is DMARC alignment with SPF, the confusion between SPF and DMARC= -SPF lives on...
=C2=A0
--001a1135388ac4aba5051e688895-- From nobody Fri Aug 28 20:43: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 CE91F1A0276 for ; Fri, 28 Aug 2015 20:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 25Isrjai2MI1 for ; Fri, 28 Aug 2015 20:43:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B90C1A1AA7 for ; Fri, 28 Aug 2015 20:43:13 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t7T3hCfL005941 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 28 Aug 2015 20:43:13 -0700 References: <20150821224834.19670.qmail@ary.lan> <55D7ACA4.1040500@dcrocker.net> To: Franck Martin From: Dave Crocker X-Enigmail-Draft-Status: N1110 Organization: Brandenburg InternetWorking Message-ID: <55E12A4D.6000502@dcrocker.net> Date: Fri, 28 Aug 2015 20:43:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 28 Aug 2015 20:43:13 -0700 (PDT) Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 03:43:15 -0000 On 8/28/2015 5:46 PM, Franck Martin wrote: > Is SPF "alignment" a valid term here? (The term does not appear in the > SPF spec.) I thought 'alignment' was first defined in this space for > DMARC and that it does not have formal meaning for SPF or DKIM. I > assume what is meant is simply SPF validation. > > > It is DMARC alignment with SPF, the confusion between SPF and DMARC-SPF > lives on... The term "DMARC alignment with SPF" has no meaning within the DMARC spec. Per RFC 7489: Identifier Alignment: When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier Alignment. That is, 'alignment' is with the rfc5322.From field. Not 'with' SPF or DKIM. It is validated 'by' SPF or DKIM. Going back to the draft text I'm questioning: > o MTAs sending email on behalf of multiple domains may require > Domain Owners to provide DKIM keys to use DKIM to avoid SPF > alignment issues. Managing DKIM keys with a third party has > security risks which should be carefully managed. I think that the intended meaning is: ...to avoid SPF validation issues, given the requirement for DMARC alignment with the rfc5322.From field. or somesuch. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 30 23:21:37 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 E57651B2F40; Fri, 28 Aug 2015 18:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nsjGnh3IMnjL; Fri, 28 Aug 2015 18:02:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D53B41B2D5D; Fri, 28 Aug 2015 18:02:52 -0700 (PDT) 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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150829010252.17873.92899.idtracker@ietfa.amsl.com> Date: Fri, 28 Aug 2015 18:02:52 -0700 Archived-At: X-Mailman-Approved-At: Sun, 30 Aug 2015 23:21:37 -0700 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-06.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: Sat, 29 Aug 2015 01:02:55 -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-06.txt Pages : 22 Date : 2015-08-28 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-06 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/