From nobody Wed Jan 2 17:14:22 2019 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 2AB3A130F8B; Wed, 2 Jan 2019 17:14:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154647806011.32519.11761658134444749805@ietfa.amsl.com> Date: Wed, 02 Jan 2019 17:14:20 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-eaiauth-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 03 Jan 2019 01:14:20 -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 WG of the IETF. Title : E-mail Authentication for Internationalized Mail Author : John Levine Filename : draft-ietf-dmarc-eaiauth-00.txt Pages : 6 Date : 2018-12-19 Abstract: SPF, DKIM, and DMARC enable a domain owner to publish e-mail authentication and policy information in the DNS. In internationalized e-mail, domain names can occur both as U-labels and A-labels. The Authentication-Results header reports the result of authentication checks made with SPF, DKIM, DMARC, and other schemes. This specification clarifies when to use which form of domain names when using SPF, DKIM, and DMARC and when creating Authentication- Results headers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-eaiauth-00 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-eaiauth-00 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 Sat Jan 5 18:21:08 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D41130EE8; Sat, 5 Jan 2019 18:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9e9rBOjQD9Nv; Sat, 5 Jan 2019 18:21:04 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 2095012D4E7; Sat, 5 Jan 2019 18:21:01 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id c19-v6so35413265lja.5; Sat, 05 Jan 2019 18:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VqEKFCgw25hqkLLVnHKBLo/CW/BS8ZVbZnTn5Fcxpww=; b=mEPtEPU4fGkMEMNDLpl7cV4apO6ZW6KhSPNTJn5Q5AZEGWM5L+fPhNL47mhz9+pzZc nt6xf1jw64PFhov4reRKbSw2Imf3S4bOqk6ybW/nnLnQOaewm5BFCRm8saFgyqARxeq3 OiziEMTREix+eAUnhr5k+takFCqaA2qG66Yd/8Lw2lnklLhQwIFtDDZMfbfrnCOF/M1M WP66Yh2KPXCb87PIjV62o5UqAW6Gvn+tXW+Ly1I2mbE4MkODSjBV75LLTPzJcZaJcRZb 8a2faCOvDytTHjDQaygVIfRxOOf+yFrGXpL/c5o4gyodjKNrF0AGymm7lxEjc71KxKmT 1w0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VqEKFCgw25hqkLLVnHKBLo/CW/BS8ZVbZnTn5Fcxpww=; b=b4IP5rCviYFmHlmP4sh6ELoWPg6P1ppXbN7Lrhk7BPRHGQT2DXMzC65JF/HLdx/uua HRGpFXjQHNtc6+3pK70QjFgFfMTEUYEak/sonzoJ0GB8197axOTnQHB5Tiu83cRXumfc tHgjZTJtYwk8+kjCyqIQalBVRTwv4V0a3yrTISbJuN6brbR2EFQv5xMlm4VaIBlo4aCk 9y3MFMOdue9ZWChjSeT+fcP06FqiTQMYYN1YTZJUH4tfBlYGe+uASTd3jjQsOVgma8oH Xxqt9+4R+A8L+6qLf+QZWsUsDF81Nc65xOinfiM97QQptIzuD3KsuEKQAEHbm09q+aZt F4lg== X-Gm-Message-State: AJcUukcz/LXqt5cRSUyxuV3uETGBo+YqcKFh1vq+YeXkcFT9a0UJPhb7 FQDGTjjIxrkCDWxXwl0xSRTZbNUwsosy1XJHNkw= X-Google-Smtp-Source: ALg8bN7QETYHJj9pLXeP2KzQ3+GpBxwBJdJNhqZMvVDFOWdhwe2UH9nbn/fxcgTN+7DwluWRfDc1Bkj1LgePBX7iRsI= X-Received: by 2002:a2e:750a:: with SMTP id q10-v6mr28046657ljc.39.1546741258798; Sat, 05 Jan 2019 18:20:58 -0800 (PST) MIME-Version: 1.0 References: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com> In-Reply-To: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sat, 5 Jan 2019 18:20:47 -0800 Message-ID: To: Eric Rescorla Cc: The IESG , Tim Draegen , IETF DMARC WG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000004a560d057ec0c34a" Archived-At: Subject: Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jan 2019 02:21:07 -0000 --0000000000004a560d057ec0c34a Content-Type: text/plain; charset="UTF-8" Hi Eric, thanks for your comments and sorry for the delay in replying. I've applied all of your comments except those below, for discussion: On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla wrote: > > IMPORTANT > S 7.10. > > processing of these is outside of the intended scope of this > document > > (see Section 1.3), some early guidance to MUA developers is > > appropriate here. > > > > Since MTAs are unlikely to strip Authentication-Results header > fields > > after mailbox delivery, MUAs are advised in Section 4.1 to ignore > > I think you want to be stronger than "are advised to" > I changed "advised" to "warned"; is that adequate? It's referring to a SHOULD in 4.1. S 1.2. > > Thus, this document defines a "trust boundary" as the delineation > > between "external" and "internal" entities. Services that are > > internal -- within the trust boundary -- are provided by the ADMD's > > infrastructure for its users. Those that are external are outside > of > > the authority of the ADMD. By this definition, hosts that are > within > > a trust boundary are subject to the ADMD's authority and policies, > > This seems like a reasonable design, but not the only one. For > instance, Gmail might attach these headers, but I don't think of my > MUA as being subject to its authority and policies. > The MUA in the Gmail case is Gmail itself, isn't it? Or at least their client? Or are you referring to some IMAP access to it? S 1.5.3. > > agents, assign (some) responsibility for the message (which implies > > authorization), and ensure that the listed portions of the message > > were not modified in transit. Since the signatures are not tied to > > SMTP connections, they can be added by either the ADMD of origin, > > intermediate ADMDs (such as a mailing list server), other handling > > agents, or any combination. > > I'm not sure how persuaded I am by this terminology. However, > regardless of that, this claim about SPF seems problematic in the > sense that you could have an intermediate MTA decorate the message > with the incoming IP address (in some unspecified way) but then have > the terminal MTA do the SPF validation. > Right, that's a property of SPF: It only evaluates the latest ("connecting" in that paragraph) hop, while DKIM often survives end-to-end irrespective of who's relaying it in to the local ADMD. S 2.2. > > combination of these can be applied. > > > > 2.2. Formal Definition > > > > Formally, the header field is specified as follows using Augmented > > Backus-Naur Form ([ABNF]): > > An example would be kind of helpful here. > I put in a forward reference to the Examples section instead. S 2.4. > > > > This ptype existed in the original specification for this header > > field, but without a complete description or example of intended > use. > > As a result, it has not seen any practical use to date that matches > > its intended purpose. These added details are provided to guide > > implementers toward proper use. > > This text is odd in a bis draft, because "the original" is not 7601 or > 7001. > Would actual RFC numbers be better? The point here is that the original (5451) didn't do a great job of explaining how this works, and then the intervening versions (7001, 7601) didn't fix it. We're finally fixing it here. -MSK --0000000000004a560d057ec0c34a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric, thanks for your comments and sor= ry for the delay in replying.

I've applied all of you= r comments except those below, for discussion:

On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla = <ekr@rtfm.com> wrote:

IMPORTANT
S 7.10.
>=C2=A0 =C2=A0 =C2=A0 processing of these is outside of the intended sco= pe of this document
>=C2=A0 =C2=A0 =C2=A0 (see Section 1.3), some early guidance to MUA deve= lopers is
>=C2=A0 =C2=A0 =C2=A0 appropriate here.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 Since MTAs are unlikely to strip Authentication-Re= sults header fields
>=C2=A0 =C2=A0 =C2=A0 after mailbox delivery, MUAs are advised in Sectio= n 4.1 to ignore

I think you want to be stronger than "are advised to"

I changed "advised" to "warned"= ;; is that adequate?=C2=A0 It's referring to a SHOULD in 4.1.

S 1.2.
>=C2=A0 =C2=A0 =C2=A0 Thus, this document defines a "trust boundary= " as the delineation
>=C2=A0 =C2=A0 =C2=A0 between "external" and "internal&qu= ot; entities.=C2=A0 Services that are
>=C2=A0 =C2=A0 =C2=A0 internal -- within the trust boundary -- are provi= ded by the ADMD's
>=C2=A0 =C2=A0 =C2=A0 infrastructure for its users.=C2=A0 Those that are= external are outside of
>=C2=A0 =C2=A0 =C2=A0 the authority of the ADMD.=C2=A0 By this definitio= n, hosts that are within
>=C2=A0 =C2=A0 =C2=A0 a trust boundary are subject to the ADMD's aut= hority and policies,

This seems like a reasonable design, but not the only one. For
instance, Gmail might attach these headers, but I don't think of my
MUA as being subject to its authority and policies.
The MUA in the Gmail case is Gmail itself, isn't it?=C2=A0= Or at least their client?=C2=A0 Or are you referring to some IMAP access t= o it?

S 2.2.
>=C2=A0 =C2=A0 =C2=A0 combination of these can be applied.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A02.2.=C2=A0 Formal Definition
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 Formally, the header field is specified as follows= using Augmented
>=C2=A0 =C2=A0 =C2=A0 Backus-Naur Form ([ABNF]):

An example would be kind of helpful here.

I put in a forward reference to the Examples section instead.
<= div>
S 2.4.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 This ptype existed in the original specification f= or this header
>=C2=A0 =C2=A0 =C2=A0 field, but without a complete description or examp= le of intended use.
>=C2=A0 =C2=A0 =C2=A0 As a result, it has not seen any practical use to = date that matches
>=C2=A0 =C2=A0 =C2=A0 its intended purpose.=C2=A0 These added details ar= e provided to guide
>=C2=A0 =C2=A0 =C2=A0 implementers toward proper use.

This text is odd in a bis draft, because "the original" is not 76= 01 or
7001.

Would actual RFC numbers be bette= r?=C2=A0 The point here is that the original (5451) didn't do a great j= ob of explaining how this works, and then the intervening versions (7001, 7= 601) didn't fix it.=C2=A0 We're finally fixing it here.

-MSK
--0000000000004a560d057ec0c34a-- From nobody Sat Jan 5 21:07:44 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A39B130DEA; Sat, 5 Jan 2019 21:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kg6-ijPAiRIE; Sat, 5 Jan 2019 21:07:40 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 E3EC7130DCD; Sat, 5 Jan 2019 21:07:39 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id u89-v6so35582582lje.1; Sat, 05 Jan 2019 21:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xNUfnK9DJh7dTsu30SaVedpgKLDWgqupJzBvXmx4GIA=; b=VC0t5HpDZQVtnkrtqV91ZHqDDERDxlu5uAP0L7hOIqRVwEkc53v3HARXRxf0rhYMFX gKq7KsXG7w/r9CSYqBwTd2ka0+VxhZTjariOyYGqbBb4UQAO7vSw6QphNTGgMUGUlVR+ VKzMFvHqEqong7XfHyf9HP1aCFXYJJ5gjH5pJBo6LTbYD/uEzf4N3Kat0396IqmAEVZ8 lmtZKSdTiw+4F84NciLI+nq3/KWdRZ7ivr8eyQKhg9NK2jM6D26zOWHqD70UNI/00i3B cCsgo4ZOfLqS9Vfcb9PZPIteOYeJufZXX5MWWx7w16iBhxf/17rJWGKuLvgAlyB6LOa+ hTzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xNUfnK9DJh7dTsu30SaVedpgKLDWgqupJzBvXmx4GIA=; b=D8yRA527X3KNivSmLHKA/HK9KLBmUK9nNtVJUNf1tYR+C2YepXMlvd7xDYU/CzNv5K onfO6S0pr+fL/rZXlStdZ9cJd5wmUWL7YDJ6w8v23CPBvGhOxjhMl0+NgoyshhwxTS6Y qluJi4l5evO48EUkZGXziX/bUxEbQOOsCz823pOzwxobHbPlQ3Xh5vtfsfXqCLGFSsu6 B7hCGrle5P6V40TNjUXPmkOe7a5Zitb172ySfP0VDRcgYObNWTseId6zSnzH/qtvW/0r osYhzJBq7UmcQynviUc/97gbaAv/XcYbHRAxsT/uW9zZtJlTRCw8mtQJJsYVOSpSoQZl wMAQ== X-Gm-Message-State: AJcUukfW2gnIxCBND28vBnSKmY2Hsd5YFcXbAB3Wa4L0cM166z+cd7i2 90q3lSQ9Xg9Ew8+1q4P83srwfyYXBCZ7GxoMiI0= X-Google-Smtp-Source: ALg8bN598t2GjxUu+Z3gmzQmTzCoF9GwsiqDNrTIoiGZLQxUdVAxWiZIVeSlXvHkexHHFCK0BDB6cdybD0asyAWs1uI= X-Received: by 2002:a2e:5747:: with SMTP id r7-v6mr30795309ljd.141.1546751257585; Sat, 05 Jan 2019 21:07:37 -0800 (PST) MIME-Version: 1.0 References: <154280871768.11502.10059395575461348698.idtracker@ietfa.amsl.com> In-Reply-To: <154280871768.11502.10059395575461348698.idtracker@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sat, 5 Jan 2019 21:07:24 -0800 Message-ID: To: Benjamin Kaduk Cc: The IESG , Tim Draegen , IETF DMARC WG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000043ae34057ec317ab" Archived-At: Subject: Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jan 2019 05:07:43 -0000 --00000000000043ae34057ec317ab Content-Type: text/plain; charset="UTF-8" On Wed, Nov 21, 2018 at 5:58 AM Benjamin Kaduk wrote: > > For example, in Section 1: > > There exist registries for tokens used within this header field that > refer to the specifications listed above. Section 6 describes the > registries and their contents and specifies the process by which > > I don't think all of this is still present anymore. (If we were talking > about registration policies, for example, we'd need an 8126 reference to > replace the 5226 reference that was removed.) > There appears to be obvious consensus for restoring all of the text so that this document is a complete description of Authentication-Results. Hopefully the update I'm planning to post takes care of all of this. [We should double-check that everything that now allows EAI-formatted > stuff is updated to also refer to this document from the IANA registry. > On first glance this might include vbr.mv and vbr.md, but probably much > more.] > The pending update should take care of this as well. Don't we need to mention the updates (or obsoletes) relationship w.r.t. > 7601 in the Abstract and Introduction? > Since I started doing IETF work, it seems like there's never been consistent guidance on this. Some ADs ask for it, others find it redundant to what's in the header of the first page and have asked me to remove it in prior work. I'll add it here and hopefully nobody pushes back. Section 4.1 has: > > MUAs and downstream filters MUST ignore any result reported using a > "result" not specified in the IANA "Result Code" registry or a > "ptype" not listed in the "Email Authentication Property Types" > registry for such values as defined in Section 6. [...] > > This would seem to be an internal inconsistency, in that it seems to > preclude any sort of experimental usage as described in Sections 2.7.x. > Fixed next version. In Section 2.3: > > Combinations of ptypes and properties are registered and described in > the "Email Authentication Methods" registry, coupled with the > authentication methods with which they are used. This is further > described in Section 6. > > The relevant subsection of section 6 is a pretty empty stub now. > Fixed next version. ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks you for updating in response to the secdir review! > > Are we now intending to restrict ourselvesto domain-based authentication > schemes, having removed the disclaimer present in 7601 about the intent > of the document? > No; this document talks about SMTP AUTH and reverse DNS authentication, neither of which necessarily tie directly to domain names for domains in the message. Which disclaimer are you referring to? > Section 1.1 > > In particular, the mere presence of this header field does not mean > its contents are valid. Rather, the header field is reporting > assertions made by one or more authentication schemes applied > somewhere upstream. For an MUA or downstream filter to treat the > assertions as actually valid, there must be an assessment of the > trust relationship among such agents, the validating MTA, and the > mechanism for conveying the information > > If this document is reporting assertions made upstream, we should say > what kind of integrity and authenticity guarantees we do or do not > provide for the reported information. (That is, "this header is > transmitted in cleartext and could be modified by any agent along the > delivery path", modulo the speculation we have later about potential > ways to improve on that situation.) Section 1.6 goes a bit farther in > this vein; maybe a forward reference is in order? > Eric made a suggestion about mentioning that the paths between components that either generate or consume this header field must also be trusted, and I've added that already. Is that satisfactory? Section 1.4 > > Isn't there a requirement to drop this header on the boundary, if there > are any internal consumers? This is not a global requiremnet on > existing servers, of course, but a deployment consideration that may > affect existing servers. The end of section 7.1 seems to cover this > situation pretty well, as well. > This section is talking about changes to other protocols (there are none) and required changes to message handling logic (i.e., you don't have to start rejecting mail just because "dkim=fail" or something). Section 1.5.1 > > Please consider using the RFC 8174 version of the BCP 14 boilerplate. > Done in the new version. Section 1.5.4 > > o An "intermediate MTA" is any MTA that is not a delivery MTA and is > also not the first MTA to handle the message. > > Is this intended to be global or within an ADMD? > It's global. Section 2.2 > > I guess wouldn't be a whole lot of value in subtyping Keyword to have > one symbol per registry, though the thought did occur to me while > reading. > I agree, not really. Section 2.3 > > body: Information that was extracted from the body of the message. > [...] > interest. The "property" is an indication of where within the > message body the extracted content was found, and can indicate an > offset, identify a MIME part, etc. > > I'm not seeing where it's specified how the "property" gives an offset. > I see other descriptions below about specific header fields and SMTP > verbs and such, though. That's text from the 2009 version of this work. Those were speculative at the time and haven't yet materialized, at least not in standardized use. > (Do we need to make it more clear that the > "property" is defined within the context of the method?) > That doesn't appear to have been necessary in the ~10 years since the first version. The results for Sender ID are listed and described in Section 4.2 of > [SENDERID], but for the purposes of this specification, the SPF > definitions enumerated above are used instead. Also, [SENDERID] > specifies result codes that use mixed case, but they are typically > used all lowercase in this context. > > We use much stronger statements about lowercasing than "typically", > elsewhere in this doc. Is this time different? > Removed. Section 2.7.6 > > Experimental method identifiers MUST only be used within ADMDs that > have explicitly consented to use them. These method identifiers and > the parameters associated with them are not documented in RFCs. > Therefore, they are subject to change at any time and not suitable > for production use. [...] > > This part seems to value RFC status too highly -- earlier in the section > we only say that they should "preferably" be published in an RFC. > I'll just make it "formally". Section 2.7.7 > > Do we want to say that temporary registrations are available for > wide-scale or long-running experiments? > It's never come up before. Since the registry includes the ability to mark something "deprecated", one could do the registration and then deprecate it if the experiment fails. Or we could allow a third status of "experimental". But since there's never been such demand in the ten years since the original version, I'd just as soon leave it until someone wants to do it. Section 3 > > of the validity of the connection's identity using DNS. It is > incumbent upon an agent making use of the reported "iprev" result to > understand what exactly that particular verifier is attempting to > report. > > Does that in practice constrain "iprev" usage to within a single ADMD? > I would imagine so. Section 4.1 > > MUAs SHOULD ignore instances of this header field discovered within > message/rfc822 MIME attachments. > > When would I want to not ignore it? > The discretion is left for operators that know what they're doing. You have to understand, for example, that you're going to be applying the results of authentication checks done in the possibly very distant past. I can add a sentence or two to that effect. Section 5 > > I guess there's not really any special behavior to worry about when a > message's path causes it to have two or more disjoint path segments in > its delivery path that go through a given ADMD. (That is, delete on > entry is still the right thing to do.) The last paragraph of Section > 1.2 covers a related case, but I am thinking of something like a message > that gets delivered to an expander and some of the recipients' delivery > path would then return through a previously visited domain. > > For example, an MTA for > example.com receiving a message MUST delete or otherwise obscure any > instance of this header field bearing an authentication service > identifier indicating that the header field was added within > example.com prior to adding its own header fields. [...] > > Do we want to say anything about the authserv-id here? > That's the "authentication service identifier". Section 6.4 > > I think we need to update the registry to also refer to this document. > It's in the pending update. Appendix C > > 2. Border MTAs are more likely to have direct access to external > sources of authentication or reputation information since modern > MUAs are more likely to be heavily firewalled. [...] > > It's unclear that this statement about "modern MUAs" is still true, > given the "zero trust" movement and such. > It's certainly still true in my work environment, but perhaps less so for mobile devices. I'll tweak the text accordingly. -MSK --00000000000043ae34057ec317ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 21, 2018 at 5:58 AM Benjamin = Kaduk <kaduk@mit.edu> wrote:
=

For example, in Section 1:

=C2=A0 =C2=A0There exist registries for tokens used within this header fiel= d that
=C2=A0 =C2=A0refer to the specifications listed above.=C2=A0 Section 6 desc= ribes the
=C2=A0 =C2=A0registries and their contents and specifies the process by whi= ch

I don't think all of this is still present anymore.=C2=A0 (If we were t= alking
about registration policies, for example, we'd need an 8126 reference t= o
replace the 5226 reference that was removed.)

There appears to be obvious consensus for restoring all of the text = so that this document is a complete description of Authentication-Results.= =C2=A0 Hopefully the update I'm planning to post takes care of all of t= his.

[We should double-check that everything that now allows EAI-formatted
stuff is updated to also refer to this document from the IANA registry.
On first glance this might include vbr.mv and vbr.md, but probably much
more.]

The pending update should take c= are of this as well.

Don't we need to mention the updates (or obsoletes) relationship w.r.t.=
7601 in the Abstract and Introduction?

= Since I started doing IETF work, it seems like there's never been consi= stent guidance on this.=C2=A0 Some ADs ask for it, others find it redundant= to what's in the header of the first page and have asked me to remove = it in prior work.=C2=A0 I'll add it here and hopefully nobody pushes ba= ck.

Section 4.1 has:

=C2=A0 =C2=A0MUAs and downstream filters MUST ignore any result reported us= ing a
=C2=A0 =C2=A0"result" not specified in the IANA "Result Code= " registry or a
=C2=A0 =C2=A0"ptype" not listed in the "Email Authentication= Property Types"
=C2=A0 =C2=A0registry for such values as defined in Section 6.=C2=A0 [...]<= br>
This would seem to be an internal inconsistency, in that it seems to
preclude any sort of experimental usage as described in Sections 2.7.x.
=

Fixed next version.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> In Section 2.3:

=C2=A0 =C2=A0Combinations of ptypes and properties are registered and descr= ibed in
=C2=A0 =C2=A0the "Email Authentication Methods" registry, coupled= with the
=C2=A0 =C2=A0authentication methods with which they are used.=C2=A0 This is= further
=C2=A0 =C2=A0described in Section 6.

The relevant subsection of section 6 is a pretty empty stub now.

Fixed next version.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks you for updating in response to the secdir review!

Are we now intending to restrict ourselvesto domain-based authentication schemes, having removed the disclaimer present in 7601 about the intent
of the document?

No; this document talk= s about SMTP AUTH and reverse DNS authentication, neither of which necessar= ily tie directly to domain names for domains in the message.

=
Which disclaimer are you referring to?


Section 1.1

=C2=A0 =C2=A0In particular, the mere presence of this header field does not= mean
=C2=A0 =C2=A0its contents are valid.=C2=A0 Rather, the header field is repo= rting
=C2=A0 =C2=A0assertions made by one or more authentication schemes applied<= br> =C2=A0 =C2=A0somewhere upstream.=C2=A0 For an MUA or downstream filter to t= reat the
=C2=A0 =C2=A0assertions as actually valid, there must be an assessment of t= he
=C2=A0 =C2=A0trust relationship among such agents, the validating MTA, and = the
=C2=A0 =C2=A0mechanism for conveying the information

If this document is reporting assertions made upstream, we should say
what kind of integrity and authenticity guarantees we do or do not
provide for the reported information.=C2=A0 (That is, "this header is<= br> transmitted in cleartext and could be modified by any agent along the
delivery path", modulo the speculation we have later about potential ways to improve on that situation.)=C2=A0 Section 1.6 goes a bit farther in=
this vein; maybe a forward reference is in order?

=
Eric made a suggestion about mentioning that the paths between c= omponents that either generate or consume this header field must also be tr= usted, and I've added that already.=C2=A0 Is that satisfactory?

Section 1.4

Isn't there a requirement to drop this header on the boundary, if there=
are any internal consumers?=C2=A0 This is not a global requiremnet on
existing servers, of course, but a deployment consideration that may
affect existing servers.=C2=A0 The end of section 7.1 seems to cover this situation pretty well, as well.

This se= ction is talking about changes to other protocols (there are none) and requ= ired changes to message handling logic (i.e., you don't have to start r= ejecting mail just because "dkim=3Dfail" or something).

Section 1.5.1

Please consider using the RFC 8174 version of the BCP 14 boilerplate.

Done in the new version.

Section 1.5.4

=C2=A0 =C2=A0o=C2=A0 An "intermediate MTA" is any MTA that is not= a delivery MTA and is
=C2=A0 =C2=A0 =C2=A0 also not the first MTA to handle the message.

Is this intended to be global or within an ADMD?

<= /div>It's global.

Section 2.2

I guess wouldn't be a whole lot of value in subtyping Keyword to have one symbol per registry, though the thought did occur to me while
reading.

I agree, not really.

Section 2.3

=C2=A0 =C2=A0body:=C2=A0 Information that was extracted from the body of th= e message.
[...]
=C2=A0 =C2=A0 =C2=A0 interest.=C2=A0 The "property" is an indicat= ion of where within the
=C2=A0 =C2=A0 =C2=A0 message body the extracted content was found, and can = indicate an
=C2=A0 =C2=A0 =C2=A0 offset, identify a MIME part, etc.

I'm not seeing where it's specified how the "property" gi= ves an offset.
I see other descriptions below about specific header fields and SMTP
verbs and such, though.

That's tex= t from the 2009 version of this work.=C2=A0 Those were=20 speculative at the time and haven't yet materialized, at least not in= =20 standardized use.
=C2=A0
(Do we need to make it more clear that the
"property" is defined within the context of the method?)

That doesn't appear to have been necessary in th= e ~10 years since the first version.

=C2=A0=C2=A0 The results for Sender ID are listed and described in Section = 4.2 of
=C2=A0 =C2=A0[SENDERID], but for the purposes of this specification, the SP= F
=C2=A0 =C2=A0definitions enumerated above are used instead.=C2=A0 Also, [SE= NDERID]
=C2=A0 =C2=A0specifies result codes that use mixed case, but they are typic= ally
=C2=A0 =C2=A0used all lowercase in this context.

We use much stronger statements about lowercasing than "typically"= ;,
elsewhere in this doc.=C2=A0 Is this time different?
<= br>
Removed.

Section 2.7.6

=C2=A0 =C2=A0Experimental method identifiers MUST only be used within ADMDs= that
=C2=A0 =C2=A0have explicitly consented to use them.=C2=A0 These method iden= tifiers and
=C2=A0 =C2=A0the parameters associated with them are not documented in RFCs= .
=C2=A0 =C2=A0Therefore, they are subject to change at any time and not suit= able
=C2=A0 =C2=A0for production use.=C2=A0 [...]

This part seems to value RFC status too highly -- earlier in the section we only say that they should "preferably" be published in an RFC.=

I'll just make it "formally&q= uot;.

Section 2.7.7

Do we want to say that temporary registrations are available for
wide-scale or long-running experiments?

It's never come up before.=C2=A0 Since the registry includes the abili= ty to mark something "deprecated", one could do the registration = and then deprecate it if the experiment fails.=C2=A0 Or we could allow a th= ird status of "experimental".=C2=A0 But since there's never b= een such demand in the ten years since the original version, I'd just a= s soon leave it until someone wants to do it.

Section 3

=C2=A0 =C2=A0of the validity of the connection's identity using DNS.=C2= =A0 It is
=C2=A0 =C2=A0incumbent upon an agent making use of the reported "iprev= " result to
=C2=A0 =C2=A0understand what exactly that particular verifier is attempting= to
=C2=A0 =C2=A0report.

Does that in practice constrain "iprev" usage to within a single = ADMD?

I would imagine so.
Section 4.1

=C2=A0 =C2=A0MUAs SHOULD ignore instances of this header field discovered w= ithin
=C2=A0 =C2=A0message/rfc822 MIME attachments.

When would I want to not ignore it?

The= discretion is left for operators that know what they're doing.=C2=A0 Y= ou have to understand, for example, that you're going to be applying th= e results of authentication checks done in the possibly very distant past.= =C2=A0 I can add a sentence or two to that effect.

Section 5

I guess there's not really any special behavior to worry about when a message's path causes it to have two or more disjoint path segments in<= br> its delivery path that go through a given ADMD.=C2=A0 (That is, delete on entry is still the right thing to do.)=C2=A0 The last paragraph of Section<= br> 1.2 covers a related case, but I am thinking of something like a message that gets delivered to an expander and some of the recipients' delivery=
path would then return through a previously visited domain.

=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 For example, an MTA for
=C2=A0 =C2=A0example.com receiving a message MUST delete or otherwise obscure = any
=C2=A0 =C2=A0instance of this header field bearing an authentication servic= e
=C2=A0 =C2=A0identifier indicating that the header field was added within =C2=A0 =C2=A0example.com prior to adding its own header fields.=C2=A0 [...]
Do we want to say anything about the authserv-id here?

That's the "authentication service identifier"= ;.

Section 6.4

I think we need to update the registry to also refer to this document.
<= /blockquote>

It's in the pending update.
=
Appendix C

=C2=A0 =C2=A02.=C2=A0 Border MTAs are more likely to have direct access to = external
=C2=A0 =C2=A0 =C2=A0 =C2=A0sources of authentication or reputation informat= ion since modern
=C2=A0 =C2=A0 =C2=A0 =C2=A0MUAs are more likely to be heavily firewalled.= =C2=A0 [...]

It's unclear that this statement about "modern MUAs" is still= true,
given the "zero trust" movement and such.
It's certainly still true in my work environment, but perh= aps less so for mobile devices.=C2=A0 I'll tweak the text accordingly.<= /div>

-MSK
--00000000000043ae34057ec317ab-- From nobody Sat Jan 5 21:46:16 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11021131007; Sat, 5 Jan 2019 21:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6tvoKL3RqSC0; Sat, 5 Jan 2019 21:46:12 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 B91A0131002; Sat, 5 Jan 2019 21:46:11 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id v15-v6so35530962ljh.13; Sat, 05 Jan 2019 21:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WSWLdDUasSM8dhnkE8o3OzybLfPSBfrfy8I+6fKi6uE=; b=ptNz1eA14mPcx25+eECYVzuq5keP8oZw70fOfIA1MCG2Bz1OKPKvJM9JYd6SwKDO0c k/hfZQ70R6yB965ytPgPOAfcAyEpMnOk0RzT19AUhnUbymQ5zRmYdrSHg6XZcHIuMxe/ o5qi50Oa+MdZN4/ZGxDrZLhQ64kRSJmh3OKDlZS8dAFHXzNjMbociG2uXf7arUFdnCvG PlZChbL0eBzIjWVLMV8kQqJNkbZbL/qJ3YbtYPEgCnScxGYb8vpwZKNwUdotANcJ2frQ jogEO/J0y8EIjSwo5usIDpRRwPr6tX/KkYo7Z0jtKXiYtOjJDNhuObqJcIdQUr9N6+Op v1Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WSWLdDUasSM8dhnkE8o3OzybLfPSBfrfy8I+6fKi6uE=; b=KZ5aFYTRjBTgmkYX9U62D2aPfYWdeqbuM4qG/oawvhUxwYvO6jmfORrvCuVsp61jT/ gbdzFREV5ad+rDX01tfxyCS+9boNYjQOIo5qsO3h+9mAchN2oi8apIiuy59M1P8tiO4i xyEomIa56jaRUngn6QbUGO/mw7KJmPJXknmq4z9Qyo+CSbgk6hLiJnT826ySDgIS8uAB j7sWsQ00PKYvIqhgnumf+AbBAyupXhNHRTt1AWhfuwBhKP23dcZQXtTMHHNLWUy90YBG QjILLVrt4jKO+s0h0SNERtPx4qhXW6gDwPS3nw15ohrcIfkRL2OlFurZftqIhuRWg1Du sXZg== X-Gm-Message-State: AJcUukcQigVUgltbkFMqfctjz4QAEhxFh3i2N4TC/1eUOcqRn9Aqkbzw RYnX9w3TeulSiaSpknrEI3XWzVWTSK18v5ROmUWTPIsM X-Google-Smtp-Source: ALg8bN5INNhoVFd5Yvo9wr+8zOYGm5AuQ75QSvQ9+jPKNVE5IySOupSYzYjUGM9V6RnSQMSIUblAM0hGtAIi4QEkokY= X-Received: by 2002:a2e:a202:: with SMTP id h2-v6mr31303313ljm.72.1546753569426; Sat, 05 Jan 2019 21:46:09 -0800 (PST) MIME-Version: 1.0 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> <1543613485.3765543.1594837224.1E64FAB8@webmail.messagingengine.com> In-Reply-To: <1543613485.3765543.1594837224.1E64FAB8@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Sat, 5 Jan 2019 21:45:57 -0800 Message-ID: To: Alexey Melnikov Cc: Barry Leiba , Ben Campbell , Tim Draegen , IETF DMARC WG , IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000000f91d7057ec3a190" Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jan 2019 05:46:15 -0000 --0000000000000f91d7057ec3a190 Content-Type: text/plain; charset="UTF-8" Here's what I've come up with. This is a diff between RFC7601 as published and what I propose as RFC7601bis to resolve all of the DISCUSSes and most of the COMMENTs from IESG review. Please let me know if I've missed anything. I'll post it at the end of the coming week if there are no issues raised. http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601.diff.html -MSK On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov wrote: > On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote: > > Murray, would you please copy the relevant IANA Considerations > > sections from RFC 7601 into 7601bis and change the tenses > > appropriately (perhaps just with a sentence in each subsection that > > says, "The following was done in the previous edition of this > > document, RFC 7601:", or some such > > Even better if you say something like "the following is unchanged from RFC > 7601:". > > >), and then let's have a quick > > working group review of the result? (And, of course, change it back > > to "obsoletes" rather than "updates".) > > > > As it's editorial, I'm sure we don't need to go back through any > > approval process, and we can get the DISCUSS cleared and move forward. > > I agree. I think this is purely editorial, albeit an important issue for > the final document. > > > Thanks, > > Barry > > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov > wrote: > > > > > > Hi all, > > > > > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: > > > > I actually agree with this: I think the better answer is to go back > to > > > > "obsoletes" and to have this document include the details of what was > > > > put in the registries before. But the working group decided to do it > > > > the other way, and there's been criticism in the past of ADs (and, > so, > > > > by extension, chairs) picking on this sort of stuff, so I decided to > > > > let it go. I'll let the IESG sort this one out, but I'll go on > record > > > > as saying what I think the better way to handle it is. > > > > > > I think incorporating older registrations is the cleaner way of > dealing with Ben's & Benjamin's DISCUSSes, as then the document is self > contained and there is no need for readers to see obsoleted RFCs. So this > would be my preference. > > > > > > If the WG doesn't want to do this, then the document needs editing to > be correct as per Benjamin's DISCUSS. > > > > > > Best Regards, > > > Alexey > > > > > > > That said, I don't think it's a huge deal either way. > > > > > > > > Barry > > > > > > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell > wrote: > > > > > > > > > > Ben Campbell has entered the following ballot position for > > > > > draft-ietf-dmarc-rfc7601bis-04: Discuss > > > > > > > > > > When responding, please keep the subject line intact and reply to > all > > > > > email addresses included in the To and CC lines. (Feel free to cut > this > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > DISCUSS: > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > This is mainly a process discuss. I share Alvaro's concern about > this being > > > > > marked as "updating" RFC7601, when it seem like a full > replacement. I'm > > > > > promoting it to a DISCUSS because I think this needs to be > resolved before > > > > > publication. > > > > > > > > > > The current structure will make it very difficult for readers to > figure out > > > > > which parts of each doc they need to worry about. I think it needs > to either go > > > > > back to "obsoleting" 7601, or it needs to be recast to just talk > about the > > > > > changes. Note that if the former path is chosen, the IANA > considerations in > > > > > 7601 will need to be copied forward. > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > COMMENT: > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > I mostly just reviewed the diff. Thank you for mostly avoiding > unnecessary > > > > > changes. That makes the diff tools much more useful than they are > for bis > > > > > drafts that make wholesale organization and stylistic changes. > > > > > > > > > > > > > > > > > > > > > > -- > > > > Barry > > > > -- > > > > Barry Leiba (barryleiba@computer.org) > > > > http://internetmessagingtechnology.org/ > > > > > --0000000000000f91d7057ec3a190 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's what I've come up wit= h.=C2=A0 This is a diff between RFC7601 as published and what I propose as = RFC7601bis to resolve all of the DISCUSSes and most of the COMMENTs from IE= SG review.=C2=A0 Please let me know if I've missed anything.=C2=A0 I= 9;ll post it at the end of the coming week if there are no issues raised.

<= br>
-MSK

On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
On Fri, Nov 30, 2018,= at 8:54 PM, Barry Leiba wrote:
> Murray, would you please copy the relevant IANA Considerations
> sections from RFC 7601 into 7601bis and change the tenses
> appropriately (perhaps just with a sentence in each subsection that > says, "The following was done in the previous edition of this
> document, RFC 7601:", or some such

Even better if you say something like "the following is unchanged from= RFC 7601:".

>), and then let's have a quick
> working group review of the result?=C2=A0 (And, of course, change it b= ack
> to "obsoletes" rather than "updates".)
>
> As it's editorial, I'm sure we don't need to go back throu= gh any
> approval process, and we can get the DISCUSS cleared and move forward.=

I agree. I think this is purely editorial, albeit an important issue for th= e final document.

> Thanks,
> Barry
> On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov <aamelnikov@fastmail.fm> wr= ote:
> >
> > Hi all,
> >
> > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote:
> > > I actually agree with this: I think the better answer is to = go back to
> > > "obsoletes" and to have this document include the = details of what was
> > > put in the registries before.=C2=A0 But the working group de= cided to do it
> > > the other way, and there's been criticism in the past of= ADs (and, so,
> > > by extension, chairs) picking on this sort of stuff, so I de= cided to
> > > let it go.=C2=A0 I'll let the IESG sort this one out, bu= t I'll go on record
> > > as saying what I think the better way to handle it is.
> >
> > I think incorporating older registrations is the cleaner way of d= ealing with Ben's & Benjamin's DISCUSSes, as then the document = is self contained and there is no need for readers to see obsoleted RFCs. S= o this would be my preference.
> >
> > If the WG doesn't want to do this, then the document needs ed= iting to be correct as per Benjamin's DISCUSS.
> >
> > Best Regards,
> > Alexey
> >
> > > That said, I don't think it's a huge deal either way= .
> > >
> > > Barry
> > >
> > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell <ben@nostrum.com> wrote: > > > >
> > > > Ben Campbell has entered the following ballot position = for
> > > > draft-ietf-dmarc-rfc7601bis-04: Discuss
> > > >
> > > > When responding, please keep the subject line intact an= d reply to all
> > > > email addresses included in the To and CC lines. (Feel = free to cut this
> > > > introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to https:/= /www.ietf.org/iesg/statement/discuss-criteria.html
> > > > for more information about IESG DISCUSS and COMMENT pos= itions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be= found here:
> > > > https://datatracker= .ietf.org/doc/draft-ietf-dmarc-rfc7601bis/
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------= ---------------
> > > > DISCUSS:
> > > > -------------------------------------------------------= ---------------
> > > >
> > > > This is mainly a process discuss. I share Alvaro's = concern about this being
> > > > marked as "updating" RFC7601, when it seem li= ke a full replacement. I'm
> > > > promoting it to a DISCUSS because I think this needs to= be resolved before
> > > > publication.
> > > >
> > > > The current structure will make it very difficult for r= eaders to figure out
> > > > which parts of each doc they need to worry about. I thi= nk it needs to either go
> > > > back to "obsoleting" 7601, or it needs to be = recast to just talk about the
> > > > changes. Note that if the former path is chosen, the IA= NA considerations in
> > > > 7601 will need to be copied forward.
> > > >
> > > >
> > > > -------------------------------------------------------= ---------------
> > > > COMMENT:
> > > > -------------------------------------------------------= ---------------
> > > >
> > > > I mostly just reviewed the diff. Thank you for mostly a= voiding unnecessary
> > > > changes. That makes the diff tools much more useful tha= n they are for bis
> > > > drafts that make wholesale organization and stylistic c= hanges.
> > > >
> > > >
> > >
> > >
> > > --
> > > Barry
> > > --
> > > Barry Leiba=C2=A0 (barryleiba@computer.org)
> > > http://internetmessagingtechnology.org/ > > >
--0000000000000f91d7057ec3a190-- From nobody Sat Jan 5 23:27:33 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F15129B88 for ; Sat, 5 Jan 2019 23:27:31 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=fkAF6Yf4; dkim=pass (2048-bit key) header.d=kitterman.com header.b=dqQRzRJG 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 PVEljtGu6gei for ; Sat, 5 Jan 2019 23:27:29 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13EF31200D7 for ; Sat, 5 Jan 2019 23:27:28 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1546759645; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=RsfhnEzdBEUelE32oujcpKtVaWAJuUv2VyArlJ4zD8s=; b=fkAF6Yf4pME7qlp2armP2TNjSY/67k0cgOK6TgZVsqG0bcwd1K0zgybg wQfyEaqIjXzD81I8wJljqsn4iUWMDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1546759645; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=RsfhnEzdBEUelE32oujcpKtVaWAJuUv2VyArlJ4zD8s=; b=dqQRzRJGFHDYfvA+UPbxG+zV1k4xKlTOaDRN5PUIeD7rfsGDZ5dTndyJ K442M1fVEzCEC/sh9D1EoUiOU177EWUTdryW5Mb/GVVt6liNEyRgF4pP42 0qD9nuRXNjRTk8GgtJEzrGuOY5zk9o1SPSmrbryyUqvYS0D94SbOn+c0BT 2eb691HkLSFtdrAk7bWadbEJc+73dOyOeeAb4eeHBJc8qbfDIW5K8gs/ba HsVbu8ba4IQg9SjTGIMcSDhhE02oIerXZzx3yNtHMhich5xs3S9SSBGaEE txHBCP2zXsKEyfFf2jg/gS/vp8GV85477iVYIHKMOkjMcS9WLR4DcQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 098A82D40834 for ; Sun, 6 Jan 2019 01:27:25 -0600 (CST) From: Scott Kitterman To: IETF DMARC WG Date: Sun, 06 Jan 2019 02:27:24 -0500 Message-ID: <12578706.O8KzW9sDEf@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-163-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543613485.3765543.1594837224.1E64FAB8@webmail.messagingengine.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jan 2019 07:27:31 -0000 I think this is generally good. I, of course, have a few comments. Hunk at "page 17, line 44": Perhaps another sentence (more for completeness than anything) at the end of the new paragraph. Something like, "Additionally, [RFC8463] added a new signing algorithm in DKIM, ed25519-sha256 and it is also useful to be able to distinguish such signatures to identify cryptographic algorithm specific failures." That would also need a new informative reference to RFC 8463. Hunk at "page 18, line 32": "Note that in an EAI-formatted message, the "mailfrom" value can be expressed in UTF-8." Isn't it more correct to say that the local part of the "mailfrom" value can be expressed in UTF-8? The domain part is still a U-label as I understand it. The text as written is literally correct since the entire mailfrom is valid UTF-8, but I'm afraid it may be misleading. As written, I could see it causing confusion relative to the guidance in Section 5. Hunk at "page 21, line 21": Same comment re UTF-8. Hunk at "page 22, line 4": Someone who has read the VBR RFC recently enough to remember should check and see if my UTF-8 comment applies here nor not. I'm not sure either way. Scott K On Saturday, January 05, 2019 09:45:57 PM Murray S. Kucherawy wrote: > Here's what I've come up with. This is a diff between RFC7601 as published > and what I propose as RFC7601bis to resolve all of the DISCUSSes and most > of the COMMENTs from IESG review. Please let me know if I've missed > anything. I'll post it at the end of the coming week if there are no > issues raised. > > http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601.d > iff.html > > -MSK > > On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov > > wrote: > > On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote: > > > Murray, would you please copy the relevant IANA Considerations > > > sections from RFC 7601 into 7601bis and change the tenses > > > appropriately (perhaps just with a sentence in each subsection that > > > says, "The following was done in the previous edition of this > > > document, RFC 7601:", or some such > > > > Even better if you say something like "the following is unchanged from RFC > > 7601:". > > > > >), and then let's have a quick > > > > > > working group review of the result? (And, of course, change it back > > > to "obsoletes" rather than "updates".) > > > > > > As it's editorial, I'm sure we don't need to go back through any > > > approval process, and we can get the DISCUSS cleared and move forward. > > > > I agree. I think this is purely editorial, albeit an important issue for > > the final document. > > > > > Thanks, > > > Barry > > > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov > > > > wrote: > > > > Hi all, > > > > > > > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: > > > > > I actually agree with this: I think the better answer is to go back > > > > to > > > > > > > "obsoletes" and to have this document include the details of what > > > > > was > > > > > put in the registries before. But the working group decided to do > > > > > it > > > > > the other way, and there's been criticism in the past of ADs (and, > > > > so, > > > > > > > by extension, chairs) picking on this sort of stuff, so I decided to > > > > > let it go. I'll let the IESG sort this one out, but I'll go on > > > > record > > > > > > > as saying what I think the better way to handle it is. > > > > > > > > I think incorporating older registrations is the cleaner way of > > > > dealing with Ben's & Benjamin's DISCUSSes, as then the document is self > > contained and there is no need for readers to see obsoleted RFCs. So this > > would be my preference. > > > > > > If the WG doesn't want to do this, then the document needs editing to > > > > be correct as per Benjamin's DISCUSS. > > > > > > Best Regards, > > > > Alexey > > > > > > > > > That said, I don't think it's a huge deal either way. > > > > > > > > > > Barry > > > > > > > > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell > > > > wrote: > > > > > > Ben Campbell has entered the following ballot position for > > > > > > draft-ietf-dmarc-rfc7601bis-04: Discuss > > > > > > > > > > > > When responding, please keep the subject line intact and reply to > > > > all > > > > > > > > email addresses included in the To and CC lines. (Feel free to cut > > > > this > > > > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > > > > Please refer to > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found > > > > > > here: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > > > > ---------------------------------------------------------------------- > > > > > > > > DISCUSS: > > ---------------------------------------------------------------------- > > > > > > > > This is mainly a process discuss. I share Alvaro's concern about > > > > this being > > > > > > > > marked as "updating" RFC7601, when it seem like a full > > > > replacement. I'm > > > > > > > > promoting it to a DISCUSS because I think this needs to be > > > > resolved before > > > > > > > > publication. > > > > > > > > > > > > The current structure will make it very difficult for readers to > > > > figure out > > > > > > > > which parts of each doc they need to worry about. I think it needs > > > > to either go > > > > > > > > back to "obsoleting" 7601, or it needs to be recast to just talk > > > > about the > > > > > > > > changes. Note that if the former path is chosen, the IANA > > > > considerations in > > > > > > > > 7601 will need to be copied forward. > > > > ---------------------------------------------------------------------- > > > > > > > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > > > I mostly just reviewed the diff. Thank you for mostly avoiding > > > > unnecessary > > > > > > > > changes. That makes the diff tools much more useful than they are > > > > for bis > > > > > > > > drafts that make wholesale organization and stylistic changes. > > > > > > > > > > -- > > > > > Barry > > > > > -- > > > > > Barry Leiba (barryleiba@computer.org) > > > > > http://internetmessagingtechnology.org/ From nobody Sun Jan 6 08:43:32 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A321312867A for ; Sun, 6 Jan 2019 08:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 TbWUBBGy5yoz for ; Sun, 6 Jan 2019 08:43:26 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 90590128B01 for ; Sun, 6 Jan 2019 08:43:22 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id b20so28497009lfa.12 for ; Sun, 06 Jan 2019 08:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z7rE5WNgiJMYSSoBi0vR9cqkG5OEpyL1UCmvG1hbdh8=; b=Dh+ApcQ3jXXZehs46xSCoxdNk81JuLeBGNjzVJQb6wJ0o7T7isTiZcIJ1dGsPL3TBF uIygzKvWXm0dhH20FcxGVei0adjCo2dqn3EWLfXH8Eioc5Lc1ksHH4AioaGSXGq09Ce4 LzYbDXXDXWVG+qrFMUJdVDJ8SSpk49LH4XRCrtrrbkBkqK3HPU8lGhNKJfiDeqYVq4ON H1HQ+YwXOyW/PLyLhWcGvOcmOAj5hsMxPnvsbvN3xPsZ4f/J0AXWhVBiOOWYVh295Wrw 7uXVCuxA09hM+ENyvQyw+1g17W3nsBIpw7lnu7452bm/GP/dJIvwGuCf997vHil2Lneg Y7sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z7rE5WNgiJMYSSoBi0vR9cqkG5OEpyL1UCmvG1hbdh8=; b=l09Y/YHbnUyF0MlP6pTBKQ9dZ6M20Umm/JORkb9+s9eZ9YDupBbiTPiiQlG9XT1r1K O4KZ8wkVAQt6/ZQntqGbli1Hwa7P76LPuxTfN73r9U3VNtgIMuj/dKOIxi71Uut3UGHJ kZt4pP/mw3ebawsO0SicVanobWx17UDPpDnzkMJH1oTT1KSabnzL9EDiryuhX1zAZln8 nL6+3m9E7Vuwv1tWeP63KEKv8rJUaOQr8mzJpoqGBWbRInCwCddgwdvSFInJl5xMZ7Q5 IaQ5gVh6X7houTlP2VsAFkxrZxghNJsk1cmo+UECbEOkunWohoKs00kbbcTTZ55z8xkB nznQ== X-Gm-Message-State: AA+aEWZ65IBD3Vid0f5sQXrSnhUG4f/XFcQc9AhmouwbVLW0+LN9+y5H 3KxeeLOCoyleZQmimSWHz9+7SlwYR41r9KvbZ0O+Yw== X-Google-Smtp-Source: AFSGD/X2+0UR+uCMddxEG9puTWGje3thJNmXQWlzqZkweUS9EuTV1hBilTMBswAN1IyvPnlcPyxUc6rak17Q4j8e0X8= X-Received: by 2002:a19:a9d2:: with SMTP id s201mr27615680lfe.154.1546793000510; Sun, 06 Jan 2019 08:43:20 -0800 (PST) MIME-Version: 1.0 References: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Sun, 6 Jan 2019 08:42:42 -0800 Message-ID: To: "Murray S. Kucherawy" Cc: The IESG , Tim Draegen , IETF DMARC WG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000564554057ecccf94" Archived-At: Subject: Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jan 2019 16:43:28 -0000 --000000000000564554057ecccf94 Content-Type: text/plain; charset="UTF-8" On Sat, Jan 5, 2019 at 6:20 PM Murray S. Kucherawy wrote: > Hi Eric, thanks for your comments and sorry for the delay in replying. > > I've applied all of your comments except those below, for discussion: > > On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla wrote: > >> >> IMPORTANT >> S 7.10. >> > processing of these is outside of the intended scope of this >> document >> > (see Section 1.3), some early guidance to MUA developers is >> > appropriate here. >> > >> > Since MTAs are unlikely to strip Authentication-Results header >> fields >> > after mailbox delivery, MUAs are advised in Section 4.1 to ignore >> >> I think you want to be stronger than "are advised to" >> > > I changed "advised" to "warned"; is that adequate? It's referring to a > SHOULD in 4.1. > What I am thinking is that this should be normative language. > > S 1.2. >> > Thus, this document defines a "trust boundary" as the delineation >> > between "external" and "internal" entities. Services that are >> > internal -- within the trust boundary -- are provided by the ADMD's >> > infrastructure for its users. Those that are external are outside >> of >> > the authority of the ADMD. By this definition, hosts that are >> within >> > a trust boundary are subject to the ADMD's authority and policies, >> >> This seems like a reasonable design, but not the only one. For >> instance, Gmail might attach these headers, but I don't think of my >> MUA as being subject to its authority and policies. >> > > The MUA in the Gmail case is Gmail itself, isn't it? Or at least their > client? Or are you referring to some IMAP access to it? > Yes. Like what I have on my phone. S 1.5.3. >> > agents, assign (some) responsibility for the message (which implies >> > authorization), and ensure that the listed portions of the message >> > were not modified in transit. Since the signatures are not tied to >> > SMTP connections, they can be added by either the ADMD of origin, >> > intermediate ADMDs (such as a mailing list server), other handling >> > agents, or any combination. >> >> I'm not sure how persuaded I am by this terminology. However, >> regardless of that, this claim about SPF seems problematic in the >> sense that you could have an intermediate MTA decorate the message >> with the incoming IP address (in some unspecified way) but then have >> the terminal MTA do the SPF validation. >> > > Right, that's a property of SPF: It only evaluates the latest > ("connecting" in that paragraph) hop, while DKIM often survives end-to-end > irrespective of who's relaying it in to the local ADMD. > Hmm.. I think I'm making a different argument here. If the evaluating ADMD trust claims made by a relaying hop, then it is able to do its own SPF evaluation by having the relaying hop supply the IP address of the originating MTA, even if the relaying hop didn't itself do SPF validation. In this sense, it's not tied to the incoming connection. S 2.2. >> > combination of these can be applied. >> > >> > 2.2. Formal Definition >> > >> > Formally, the header field is specified as follows using Augmented >> > Backus-Naur Form ([ABNF]): >> >> An example would be kind of helpful here. >> > > I put in a forward reference to the Examples section instead. > > S 2.4. >> > >> > This ptype existed in the original specification for this header >> > field, but without a complete description or example of intended >> use. >> > As a result, it has not seen any practical use to date that matches >> > its intended purpose. These added details are provided to guide >> > implementers toward proper use. >> >> This text is odd in a bis draft, because "the original" is not 7601 or >> 7001. >> > > Would actual RFC numbers be better? The point here is that the original > (5451) didn't do a great job of explaining how this works, and then the > intervening versions (7001, 7601) didn't fix it. We're finally fixing it > here. > Yeah, I think RFC #s would be better... -Ekr > -MSK > --000000000000564554057ecccf94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 5, 2019 at 6:20 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
Hi Eric, thanks for your comments and sorry= for the delay in replying.

I've applied all of your = comments except those below, for discussion:


IMPORTANT
S 7.10.
>=C2=A0 =C2=A0 =C2=A0 processing of these is outside of the intended sco= pe of this document
>=C2=A0 =C2=A0 =C2=A0 (see Section 1.3), some early guidance to MUA deve= lopers is
>=C2=A0 =C2=A0 =C2=A0 appropriate here.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 Since MTAs are unlikely to strip Authentication-Re= sults header fields
>=C2=A0 =C2=A0 =C2=A0 after mailbox delivery, MUAs are advised in Sectio= n 4.1 to ignore

I think you want to be stronger than "are advised to"

I changed "advised" to "warned"= ;; is that adequate?=C2=A0 It's referring to a SHOULD in 4.1.

What I am thinking is that this sh= ould be normative language.

S 1.2.
>=C2=A0 =C2=A0 =C2=A0 Thus, this document defines a "trust boundary= " as the delineation
>=C2=A0 =C2=A0 =C2=A0 between "external" and "internal&qu= ot; entities.=C2=A0 Services that are
>=C2=A0 =C2=A0 =C2=A0 internal -- within the trust boundary -- are provi= ded by the ADMD's
>=C2=A0 =C2=A0 =C2=A0 infrastructure for its users.=C2=A0 Those that are= external are outside of
>=C2=A0 =C2=A0 =C2=A0 the authority of the ADMD.=C2=A0 By this definitio= n, hosts that are within
>=C2=A0 =C2=A0 =C2=A0 a trust boundary are subject to the ADMD's aut= hority and policies,

This seems like a reasonable design, but not the only one. For
instance, Gmail might attach these headers, but I don't think of my
MUA as being subject to its authority and policies.
The MUA in the Gmail case is Gmail itself, isn't it?=C2=A0= Or at least their client?=C2=A0 Or are you referring to some IMAP access t= o it?

Yes. Like what I ha= ve on my phone.


S 1.5.3.
>=C2=A0 =C2=A0 =C2=A0 agents, assign (some) responsibility for the messa= ge (which implies
>=C2=A0 =C2=A0 =C2=A0 authorization), and ensure that the listed portion= s of the message
>=C2=A0 =C2=A0 =C2=A0 were not modified in transit.=C2=A0 Since the sign= atures are not tied to
>=C2=A0 =C2=A0 =C2=A0 SMTP connections, they can be added by either the = ADMD of origin,
>=C2=A0 =C2=A0 =C2=A0 intermediate ADMDs (such as a mailing list server)= , other handling
>=C2=A0 =C2=A0 =C2=A0 agents, or any combination.

I'm not sure how persuaded I am by this terminology. However,
regardless of that, this claim about SPF seems problematic in the
sense that you could have an intermediate MTA decorate the message
with the incoming IP address (in some unspecified way)=C2=A0 but then have<= br> the terminal MTA do the SPF validation.

Right, that's a property of SPF: It only evaluates the latest ("c= onnecting" in that paragraph) hop, while DKIM often survives end-to-en= d irrespective of who's relaying it in to the local ADMD.

Hmm.. I think I'm making a dif= ferent argument here. If the evaluating ADMD trust claims made by a relayin= g hop, then it is able to do its own SPF evaluation by having the relaying = hop supply the IP address of the originating MTA, even if the relaying hop = didn't itself do SPF validation. In this sense, it's not tied to th= e incoming connection.


S 2.2.
>=C2=A0 =C2=A0 =C2=A0 combination of these can be applied.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A02.2.=C2=A0 Formal Definition
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 Formally, the header field is specified as follows= using Augmented
>=C2=A0 =C2=A0 =C2=A0 Backus-Naur Form ([ABNF]):

An example would be kind of helpful here.

I put in a forward reference to the Examples section instead.
<= div>
S 2.4.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 This ptype existed in the original specification f= or this header
>=C2=A0 =C2=A0 =C2=A0 field, but without a complete description or examp= le of intended use.
>=C2=A0 =C2=A0 =C2=A0 As a result, it has not seen any practical use to = date that matches
>=C2=A0 =C2=A0 =C2=A0 its intended purpose.=C2=A0 These added details ar= e provided to guide
>=C2=A0 =C2=A0 =C2=A0 implementers toward proper use.

This text is odd in a bis draft, because "the original" is not 76= 01 or
7001.

Would actual RFC numbers be bette= r?=C2=A0 The point here is that the original (5451) didn't do a great j= ob of explaining how this works, and then the intervening versions (7001, 7= 601) didn't fix it.=C2=A0 We're finally fixing it here.

Yeah, I think RFC #s would be be= tter...

-Ekr


-MSK
--000000000000564554057ecccf94-- From nobody Sun Jan 6 09:27:55 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDBE130DD2; Sun, 6 Jan 2019 09:27:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 hALpGb9Kyd_f; Sun, 6 Jan 2019 09:27:36 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790092.outbound.protection.outlook.com [40.107.79.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE8E12DF71; Sun, 6 Jan 2019 09:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g/11h++VBEz7EIMho7vls8QDp+QOO+UA3SEOaw2W4qI=; b=a7xWl2MvAaOKEy+sOQiBYm/s2GqHVxk7bwB9K1xhwiOv/2F9dPj1bOSCiFkuGBfiR2ls1p0b9DvoB7CkEeQ1NAli9lSftqBqy5ZrCeuTPPpV7HKvNYx5ObnaPSADU/JuSGusAhMdQVqMTJ/H4yNooztTVVXfpvPhG7VSi1unhMM= Received: from DM5PR0102CA0029.prod.exchangelabs.com (2603:10b6:4:9c::42) by DM6PR01MB4026.prod.exchangelabs.com (2603:10b6:5:2e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Sun, 6 Jan 2019 17:27:34 +0000 Received: from DM3NAM03FT057.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::201) by DM5PR0102CA0029.outlook.office365.com (2603:10b6:4:9c::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1495.6 via Frontend Transport; Sun, 6 Jan 2019 17:27:34 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT057.mail.protection.outlook.com (10.152.83.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Sun, 6 Jan 2019 17:27:34 +0000 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x06HRUb3014396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Jan 2019 12:27:32 -0500 Date: Sun, 6 Jan 2019 11:27:30 -0600 From: Benjamin Kaduk To: "Murray S. Kucherawy" CC: The IESG , Tim Draegen , IETF DMARC WG , , Message-ID: <20190106172729.GL28515@kduck.kaduk.org> References: <154280871768.11502.10059395575461348698.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(376002)(39860400002)(396003)(346002)(2980300002)(199004)(189003)(60444003)(43544003)(51444003)(50466002)(786003)(316002)(55016002)(6916009)(446003)(426003)(36906005)(5024004)(14444005)(11346002)(956004)(47776003)(336012)(356004)(305945005)(23726003)(106002)(5660300001)(478600001)(53546011)(76176011)(33656002)(104016004)(26826003)(229853002)(46406003)(7696005)(4326008)(39060400002)(2906002)(16586007)(186003)(9686003)(54906003)(26005)(53416004)(1076003)(486006)(106466001)(126002)(8676002)(6246003)(8936002)(97756001)(58126008)(86362001)(476003)(1411001)(246002)(88552002)(4744004)(75432002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB4026; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT057; 1:AnnURoAZqU1Mv4d5nX96iBsFb/QDrhxBSvfg7MAmgXPP+pKDVeWPf6R7lWFWYVxZW5VE8LWEarYo1ZuBpH/oi7T6bsYhusqCEaKNfQ+qgTg95/eK7EwdHPP0RMcagwqN X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6e5f23af-ca85-4042-7e3c-08d673fc3f0f X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:DM6PR01MB4026; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4026; 3:k7XGP0nJqc7UafGqBi3yOXv6l/pOLYohEb2SufbolN3M/0KWx8YrcfpNtcYSe57rncIh6tOHPLLuqBTFOw9qYrcdkOpbKF7X/I6Y+DgXpiaDA08Q7K2ShcHgmjyQ3lomD4lf89UGw2iLAOP7XYBdmZYLqDQtF2CWx/RWp2KjVTIAPOdm86JanMvu+rY/TY9pLJVu0viJM6Tdr0lygDKHIh7OGhJy1h+I49MvOcVaLK9qu7iORzzWUfAV6jmHZzrrY7qe685XMRBSUmmIyF6irERItkOGjcpxTG41Vbf/+g8QK3QitDnlyI5V7nPograReRWnuHQ/cU8YLriTgv5hKZ6u5MlQDRt9iV+FsTEbeMuWWYN+PQ/v6qw9Zc9+5OjA; 25:BIErpaFWxQEonfmAAzZWlrnfzsdbRh2uADlBZI8iRBEGrKO5x2XCTVt44kgXJu/w4dFsr7kB8AV8umSKTRnC+Ea86DUWPKQ/njWJT/Y7bHInVduG3uCELUlzgb1bf94XX5z6ra1OFf5fv+CYUtnE+TM12XqYtQKynTbWACix7tVK88nAqqWFRD7XkLr6PGBBWwViAMLTpP1bRooG7IfuxiBfqRmEIoL7ECBnd8b8gTABnxtUyqNt9s5Jl6Ii4WAjo51nVM0i/rfoe7Nm4AxJGSRdIHMY70PF9nHaL4PjnJNitauIwvefxTcUWU6fwnS7wGzzHoI+vcGON3DJFMtS6w== X-MS-TrafficTypeDiagnostic: DM6PR01MB4026: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4026; 31:B4qwhOgzg6dXHlLlMbNJHw5gJIJakAgOY9Mgm1L7YurX6LLUhE8Q4xo/Z5aHRglF2HHXZpL6PZc3btDnQuzV2zPo5qQLr3vDnK8+PO8yE73YYt4RNhzmIHxjyPHXumPna4kT8lIcj6hioanN+3/YAtIh70apYIdG9eFsf1EPx0QEkhUZ9cgCzcNnQFFUhkkjwyeYboXUT9aXpq09TW8DvJzIRFQetpDuotYc6UOC63o=; 20:waBgIMwLkrSYHQ7Pq0OKRW+hqv/gL2kD1/6vWV7O8ofLUjW8ukS+wErrECKBOnbNmFMsZLkjD/3q9UioBrQaiTGRlNSZjpKbRvlAZHlH2yHULgU+LI1n8tn/LMoD0EfhtlPZYqrW7Tm3jYbVTjILxovsGfT5N5DNVpKjIGAhCul0uyzNreAh+XsrcMEd42lZz/q1RO9iTbJjTouh7XaSldEyyl/zYxjJoDPTCpbjP2Mq+5NvbdHjkVLEfgtzeSAX+e5woF4BMrhph4A02yibjnErjXqFKZF3hkd/js5IHqGrGrOyr4vCDLT1q8V1i9RL26AC8oVzA7R19P0NPmOiL36ylYVR4OeKsJ7LPjjd+4e6XzIOnOXRg+nOW6f3d26sFWP+yzgNEmJvYFS5s5U6uEhc5UevWowPz749JZ/oZ8UDozMNsUltFKd9dSXftm1guma2r//whqm4PnsomoWHV1BzxczP3DWDUP7EMJ/C/In2FGP4zR2rXp97BBrW4Dys X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(93006095)(93004095)(3231475)(944501520)(52105112)(3002001)(10201501046)(6041310)(20161123562045)(201703131423095)(201702281528075)(201702281529075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DM6PR01MB4026; BCL:0; PCL:0; RULEID:; SRVR:DM6PR01MB4026; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4026; 4:wYzgU8zaKxPH7gwb99VFH2zZSybDQsW1Glu2m19tZb4s/RzaaSIsQZjLSanCTxDeFp+FkrGpGuSiD4LFII5SFtCBtT8ZiZrzzi48wSkYzDRhCVJDjwOKSiEPLFNFwbVa1uFwROlr36EGDe6UAIp6vwQowCn2u3flU4U0xukfzVI+ZasL8TMG6TWlP0up2FpMZHSR71+hzHQDIY3d9XjgAjrIgrXg513Okz/Vskpuj7jP68N7Go7Ov6MYjtn+Rct8nCc1kKVkFnbge+E5vUfktlx6FwTuqN+QGFnVsgqIE79ZfDGto+CSZu3jJm0oOVtN X-Forefront-PRVS: 09090B6B69 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM6PR01MB4026; 23:ZjqhGtBC1pZjwywq2Mlx0gZd3OPKvxTSlxZP1jtvw?= =?us-ascii?Q?vFSV6ell9jBqySopKa8GcWhPZU7DGaIbnrgODH21MIui8BR1wspIdgNBONfM?= =?us-ascii?Q?ZX054p/c381GkwxfaTKtmWLrwBGFrhOENfAWPSreGt1dDqFqlSS5n4WtY0lj?= =?us-ascii?Q?hebO022ofciDvUHaIXLP/bCjWh0Wo/FLjpKmFsyfqadkMmLvZPmj+O4/jvEa?= =?us-ascii?Q?XYwiB4dHxRdqm3c5zBNm1SpPo8zPro2qwo+uhI99CkrXNrnuJhecabjuFjJk?= =?us-ascii?Q?EmLiUqpFppNTKZxZ09UdlrUaSxFS00oRNLJtl96bisviPaQFvBRCnAYMsJOb?= =?us-ascii?Q?GoEMyLajE0mY/n6htLt+K9yqN4FQNmuflxCoIeFUQQWXYiMtt9W/W1bag6jB?= =?us-ascii?Q?bN5MzvhSi8eOYEqxT9LNORbicrBXpfiMRKP/pHhF+SrdqDh2qhoB5pdiHnDQ?= =?us-ascii?Q?xRgTtjBUmRURdIo0tXQSLiZNfozk9Ojjma1MrjgleeS66cBcSrYpSoysQ0JP?= =?us-ascii?Q?z3gD1bLvWlQZaM9uJM27lhMlvIsQgscRyCUsXpoOuPkEYmkdVZItGiQyr0pA?= =?us-ascii?Q?idYJ5iWr+mZI1Rh+76zOuwq/IHgi5xjx9BPkIt17QyJ8XCMyoRtC7zjzvSjB?= =?us-ascii?Q?cRpkFEltfPtICcZFjw4uUgs5xTmg3BLzVzn5mpSbIgQABV43yOQo7PHQhIQA?= =?us-ascii?Q?akdw6HH/xag4cm536dj9SCS1LUgdMAfjCpHjLJqK+b+3z72xFxgNIBVSAQzA?= =?us-ascii?Q?XmbmqBRCkqhDT6og6fjcLfZRGF6eAu60HWT7ktFQGO5eD6CmyXTajwzPHarJ?= =?us-ascii?Q?XC0RzIMtqe30e5heDRQ16T94z26tATia75N+OGDR/FjwdMsCWyeegWyTKQ4K?= =?us-ascii?Q?+aIczPY6ArpNhV1neDahGQ/77a0uWk5f9cRk+M2UQPZHmceKX9bYHbmYmbRq?= =?us-ascii?Q?kGYR9BMZ8HljEnPrdDOneSE8qv+ESJL20CKzX3Egt/ClGNy2NDZubUQNBwa7?= =?us-ascii?Q?P4GFPw306xLpzLMOWU7XAJcyENN/NUSBey+bS0yQ4r5gEblLCjBAeNZdktKZ?= =?us-ascii?Q?GmEZF8IPeJt5AoQKJdrx3JUoYlYXQ1rxefmk6ekziXpkUIlID5JuYCCDKfYA?= =?us-ascii?Q?DffmfIp9bOEc0T2MId4FJxAIwHc+aHfOT7qdS2FP51AkuyQBZiMbIh65UEJC?= =?us-ascii?Q?duMoX8+WPYcQJqdpwx40lKcNVn5stlmZ/ri9CSd3JNnqYKHmDn4FNKw9Ch2L?= =?us-ascii?Q?nsyV7BBGz40/y5+aRp9nQNh6O+/9prVuzsHzupATI5ghnI0lzslqdbOfzPAe?= =?us-ascii?Q?/mjn1lGfFHcBgdciZwb73eN7Z0dC29eHy52SMN3dg6DcG9LiFeKFRSGqqmAq?= =?us-ascii?Q?oshbMsFFDleDdpK6+MOgpOd76HI8zDnvF+08zSHnhEP63Fax15K2llCGWqoq?= =?us-ascii?Q?HmXoAyctw=3D=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: fjF0NoLKh9h5BHn4SteyAkzCu38W7oTtSDDJB6uzBkMU2A5gAF5oA9zD/7fZYdkKI/pEoOwsXK15yWwFIMetp4Kb7JMlNNuYNyPwqL8bW0nNAt7oVBRVpTwh4Y6QoF+ZeDok6zur860oKYREESHUR3o3T9q9BQTQFZCx45FgKvDIf20PiXtJ0uKSYAhgmVwW8YIhFRt4i2Hnt8EkwxKkaOv5bdDq1zO+UwYbbCGGVQ0x+tMF4oKd176wFnhD/niK5rcgsa7yJneykgFhsC1nhyHH5pfY+vN6ZYT/JgRNlVd+mDUXFgq7Dro8SBIiQfRl X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4026; 6:3TrPVMjLF9gPuMbrVz34xhriHuKgds6pF/jfO0Rs5ZiYA6+TcZpIVo6z7joLnO4x4wG+kblmbAKBAgYt62ujUIKTanoD7cvFqTTJIRacQfNaPeQbxZbEN5GqIp3xdcB0SmAYOIDJzEeLwtOmkU3WVwwRJOQ8GFIONza3ZHKFw9lhUjTjDqhUPnTlgS7EPh0EcmT+pH+LoHvitgoIUKI2uQIvvFS8zCPCynVlOLfHHXSckioR64ruwoCSCIbzERaNmPpbe4iZ6LYFpkgPDmEIgu0mLnE/HYjb8kk5lDkwHsqfHEt6n2+2JcGE8n7o9wSbCSkCmAIG3rHu2VbJQMOR3zLwgUYAZMAOLsP4qT6XmYc3UldJLL7nXbBCrLB2c6/p9TvEhehCZw1BYI77NxC5byPOcSGR4vEWGT7gz/K/yfZM/mo9ih1g7J1UnhVpIxHc2iB/c5+XE1MK1mRJY72kqw==; 5:dG3bRGEhPuQkfkZmksbDuiyHLgY0XZ7DYMfC631OTgLZ5glsWxyZdbgCzixf2Yj+AwTcNTvX/7h5usk8mteX8CpGF6N1qBsW723rb1xa/3y0akZUO8IwChRb7gIN0yMJ4GBYbPZ8WH2krZWQRTco79ViMSd9egLIPrnr558HhvP17RAEVjMg5KbzlHxZi9YYgWzC1MxHOxGGCcorHEuvDA==; 7:hO+SnX+yjBBW5sh4f/WDT2w1LCEFkAKadPRor4QIwIGZwzG4KJ5NaJahu/vZk+2yeD2c9hY3t0wSWS1zXx5qj9m2PvfYjl26/IyonQZVS809X4npb4PGUlYyBY2qfsGupBRHRaZJJYZ3bWQ5HH74fw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2019 17:27:34.1124 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6e5f23af-ca85-4042-7e3c-08d673fc3f0f X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB4026 Archived-At: Subject: Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jan 2019 17:27:46 -0000 On Sat, Jan 05, 2019 at 09:07:24PM -0800, Murray S. Kucherawy wrote: > On Wed, Nov 21, 2018 at 5:58 AM Benjamin Kaduk wrote: > > > > > For example, in Section 1: > > > > There exist registries for tokens used within this header field that > > refer to the specifications listed above. Section 6 describes the > > registries and their contents and specifies the process by which > > > > I don't think all of this is still present anymore. (If we were talking > > about registration policies, for example, we'd need an 8126 reference to > > replace the 5226 reference that was removed.) > > > > There appears to be obvious consensus for restoring all of the text so that > this document is a complete description of Authentication-Results. > Hopefully the update I'm planning to post takes care of all of this. It seems pretty likely, yes. I'll keep an eye out for the next rev and clear my discuss accordingly. > [We should double-check that everything that now allows EAI-formatted > > stuff is updated to also refer to this document from the IANA registry. > > On first glance this might include vbr.mv and vbr.md, but probably much > > more.] > > > > The pending update should take care of this as well. > > Don't we need to mention the updates (or obsoletes) relationship w.r.t. > > 7601 in the Abstract and Introduction? > > > > Since I started doing IETF work, it seems like there's never been > consistent guidance on this. Some ADs ask for it, others find it redundant > to what's in the header of the first page and have asked me to remove it in > prior work. I'll add it here and hopefully nobody pushes back. > > Section 4.1 has: > > > > MUAs and downstream filters MUST ignore any result reported using a > > "result" not specified in the IANA "Result Code" registry or a > > "ptype" not listed in the "Email Authentication Property Types" > > registry for such values as defined in Section 6. [...] > > > > This would seem to be an internal inconsistency, in that it seems to > > preclude any sort of experimental usage as described in Sections 2.7.x. > > > > Fixed next version. > > In Section 2.3: > > > > Combinations of ptypes and properties are registered and described in > > the "Email Authentication Methods" registry, coupled with the > > authentication methods with which they are used. This is further > > described in Section 6. > > > > The relevant subsection of section 6 is a pretty empty stub now. > > > > Fixed next version. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks you for updating in response to the secdir review! > > > > Are we now intending to restrict ourselvesto domain-based authentication > > schemes, having removed the disclaimer present in 7601 about the intent > > of the document? > > > > No; this document talks about SMTP AUTH and reverse DNS authentication, > neither of which necessarily tie directly to domain names for domains in > the message. > > Which disclaimer are you referring to? > I was thinking about "[t]his specification is not intended to be restricted to domain-based authentication schemes, [...]". I don't think we should make any change to the document text (but if the answer was "yes", I might have suggested something). > > > Section 1.1 > > > > In particular, the mere presence of this header field does not mean > > its contents are valid. Rather, the header field is reporting > > assertions made by one or more authentication schemes applied > > somewhere upstream. For an MUA or downstream filter to treat the > > assertions as actually valid, there must be an assessment of the > > trust relationship among such agents, the validating MTA, and the > > mechanism for conveying the information > > > > If this document is reporting assertions made upstream, we should say > > what kind of integrity and authenticity guarantees we do or do not > > provide for the reported information. (That is, "this header is > > transmitted in cleartext and could be modified by any agent along the > > delivery path", modulo the speculation we have later about potential > > ways to improve on that situation.) Section 1.6 goes a bit farther in > > this vein; maybe a forward reference is in order? > > > > Eric made a suggestion about mentioning that the paths between components > that either generate or consume this header field must also be trusted, and > I've added that already. Is that satisfactory? I think that covers my concern, yes. > Section 1.4 > > > > Isn't there a requirement to drop this header on the boundary, if there > > are any internal consumers? This is not a global requiremnet on > > existing servers, of course, but a deployment consideration that may > > affect existing servers. The end of section 7.1 seems to cover this > > situation pretty well, as well. > > > > This section is talking about changes to other protocols (there are none) > and required changes to message handling logic (i.e., you don't have to > start rejecting mail just because "dkim=fail" or something). It talks about required changes to message handling logic on existing servers, and I am claiming that there is one such, in certain cases. In particular, when the new deployments that use this header are in the interior of a network, the boundary servers of that network must drop instances of this header that claim to represent that network from incoming traffic, to ensure that the internal consumers only receive accurate data. This is hardly a universal case, but may be worth mentioning explicitly. > Section 1.5.1 > > > > Please consider using the RFC 8174 version of the BCP 14 boilerplate. > > > > Done in the new version. > > Section 1.5.4 > > > > o An "intermediate MTA" is any MTA that is not a delivery MTA and is > > also not the first MTA to handle the message. > > > > Is this intended to be global or within an ADMD? > > > > It's global. Okay, thanks. > Section 2.2 > > > > I guess wouldn't be a whole lot of value in subtyping Keyword to have > > one symbol per registry, though the thought did occur to me while > > reading. > > > > I agree, not really. > > Section 2.3 > > > > body: Information that was extracted from the body of the message. > > [...] > > interest. The "property" is an indication of where within the > > message body the extracted content was found, and can indicate an > > offset, identify a MIME part, etc. > > > > I'm not seeing where it's specified how the "property" gives an offset. > > I see other descriptions below about specific header fields and SMTP > > verbs and such, though. > > > That's text from the 2009 version of this work. Those were speculative at > the time and haven't yet materialized, at least not in standardized use. Are you proposing to leave the text unchanged regardless? > > > (Do we need to make it more clear that the > > "property" is defined within the context of the method?) > > > > That doesn't appear to have been necessary in the ~10 years since the first > version. A pretty solid argument :) > The results for Sender ID are listed and described in Section 4.2 of > > [SENDERID], but for the purposes of this specification, the SPF > > definitions enumerated above are used instead. Also, [SENDERID] > > specifies result codes that use mixed case, but they are typically > > used all lowercase in this context. > > > > We use much stronger statements about lowercasing than "typically", > > elsewhere in this doc. Is this time different? > > > > Removed. > > Section 2.7.6 > > > > Experimental method identifiers MUST only be used within ADMDs that > > have explicitly consented to use them. These method identifiers and > > the parameters associated with them are not documented in RFCs. > > Therefore, they are subject to change at any time and not suitable > > for production use. [...] > > > > This part seems to value RFC status too highly -- earlier in the section > > we only say that they should "preferably" be published in an RFC. > > > > I'll just make it "formally". > > Section 2.7.7 > > > > Do we want to say that temporary registrations are available for > > wide-scale or long-running experiments? > > > > It's never come up before. Since the registry includes the ability to mark > something "deprecated", one could do the registration and then deprecate it > if the experiment fails. Or we could allow a third status of > "experimental". But since there's never been such demand in the ten years > since the original version, I'd just as soon leave it until someone wants > to do it. Fair enough. (IIUC, temporary registrations are globally available for ~all IANA registries, as a function of BCP 37 (e.g., RFC 2780 section 2), so my suggestion was just to make this more widely advertised rather than changing registration policy.) > Section 3 > > > > of the validity of the connection's identity using DNS. It is > > incumbent upon an agent making use of the reported "iprev" result to > > understand what exactly that particular verifier is attempting to > > report. > > > > Does that in practice constrain "iprev" usage to within a single ADMD? > > > > I would imagine so. This is just the COMMENT section, so do what you will, but I would consider mentioning this property of "iprev" more explicitly. > Section 4.1 > > > > MUAs SHOULD ignore instances of this header field discovered within > > message/rfc822 MIME attachments. > > > > When would I want to not ignore it? > > > > The discretion is left for operators that know what they're doing. You > have to understand, for example, that you're going to be applying the > results of authentication checks done in the possibly very distant past. I > can add a sentence or two to that effect. Thanks! > Section 5 > > > > I guess there's not really any special behavior to worry about when a > > message's path causes it to have two or more disjoint path segments in > > its delivery path that go through a given ADMD. (That is, delete on > > entry is still the right thing to do.) The last paragraph of Section > > 1.2 covers a related case, but I am thinking of something like a message > > that gets delivered to an expander and some of the recipients' delivery > > path would then return through a previously visited domain. > > > > For example, an MTA for > > example.com receiving a message MUST delete or otherwise obscure any > > instance of this header field bearing an authentication service > > identifier indicating that the header field was added within > > example.com prior to adding its own header fields. [...] > > > > Do we want to say anything about the authserv-id here? > > > > That's the "authentication service identifier". Whoops, sorry for missing that. > Section 6.4 > > > > I think we need to update the registry to also refer to this document. > > > > It's in the pending update. > > Appendix C > > > > 2. Border MTAs are more likely to have direct access to external > > sources of authentication or reputation information since modern > > MUAs are more likely to be heavily firewalled. [...] > > > > It's unclear that this statement about "modern MUAs" is still true, > > given the "zero trust" movement and such. > > > > It's certainly still true in my work environment, but perhaps less so for > mobile devices. I'll tweak the text accordingly. Thanks! -Benjamin From nobody Sun Jan 6 11:10:12 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA66712D4F0 for ; Sun, 6 Jan 2019 11:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 XBVV8MMfm_MX for ; Sun, 6 Jan 2019 11:10:04 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 AFED912D4EF for ; Sun, 6 Jan 2019 11:10:03 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1OU133R2O00D6XF@mauve.mrochek.com> for dmarc@ietf.org; Sun, 6 Jan 2019 11:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546801499; bh=pCas/9NYJ0VDOWbaHrjnbipgZLmrlQigFC/CJPT0/lk=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=Ur+E9C8Riov742N22ol9CQ6MtJ6Y8cv+uaBcCOx0R4s1XASqk9DjkXJCHc+o5UZSL paA+L3LgkIFAsUuelaphXIYwWdFYiFUo04ecT8BpmM1zBe8JsUy4Er8d4725n/yFxb ju7KKVp0QPALFId/GQ+xzpdsOWf/ABA6hfx4I2k4= 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 <01R1N39ADWKW00004L@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Sun, 6 Jan 2019 11:04:55 -0800 (PST) From: ned+dmarc@mrochek.com Cc: "Murray S. Kucherawy" , Tim Draegen , IETF DMARC WG , The IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org Message-id: <01R1OU11IFIK00004L@mauve.mrochek.com> Date: Sun, 06 Jan 2019 10:29:31 -0800 (PST) In-reply-to: "Your message dated Sun, 06 Jan 2019 08:42:42 -0800" References: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com> To: Eric Rescorla Archived-At: Subject: Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jan 2019 19:10:06 -0000 > On Sat, Jan 5, 2019 at 6:20 PM Murray S. Kucherawy > wrote: > > Hi Eric, thanks for your comments and sorry for the delay in replying. > > > > I've applied all of your comments except those below, for discussion: > > > > On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla wrote: > > > >> > >> IMPORTANT > >> S 7.10. > >> > processing of these is outside of the intended scope of this > >> document > >> > (see Section 1.3), some early guidance to MUA developers is > >> > appropriate here. > >> > > >> > Since MTAs are unlikely to strip Authentication-Results header > >> fields > >> > after mailbox delivery, This sentence seems nonsensical to me: A message that has undergone delivery is by definition out of the MTA's hands - this is an essential part of delivery semantics. Now, if you're talking about what MTAs do before, as opposed to after, delivery, or submitting a previously delivered messge, or submitting a message part from a previously delivered message, or submitting a new message containing content extracted from a previously delivered message, then you need to be clear that's what you mean. But in the submission cases I'll note that it's not unlikely that Authentication-Results fields at the top of such a message will be removed by the submission process. > MUAs are advised in Section 4.1 to ignore > >> > >> I think you want to be stronger than "are advised to" > >> > > > > I changed "advised" to "warned"; is that adequate? It's referring to a > > SHOULD in 4.1. > > > What I am thinking is that this should be normative language. Whereas I'm thinking that this is poor advice in general and should either be more tightly qualified or removed. The problem is that there are many different reasons for exacting an encapsulated message, and the optimum handling of header fields varies dependin on the reason. If the intention is, say, to "burst" a mailing list digest into its component messages, since these fields cannot be asumed to have been generated by a trusted agent, whereas top-level Authentication-Results: fields may have some trust associated with them, then by all means remove the fields. However, if the digest was constucted from previously delivered messages with trusted Authentication-Results fields, retaining them is OK and may even be of value. And if the the intent is to use the messages as input to some sort of security scanning process, removing them may actually have an adverse effect. There are undoubtedly many other cases that arise, but I think this demonstrates the point. Of course having a simple rule would be nice. But there's no simple rule for deciding where the boundary between trusted and untrusted Received: fields lies - something which already complicates the handling of extracted messages - and we manage to deal with that all the time. > > > > S 1.2. > >> > Thus, this document defines a "trust boundary" as the delineation > >> > between "external" and "internal" entities. Services that are > >> > internal -- within the trust boundary -- are provided by the ADMD's > >> > infrastructure for its users. Those that are external are outside > >> of > >> > the authority of the ADMD. By this definition, hosts that are > >> within > >> > a trust boundary are subject to the ADMD's authority and policies, > >> > >> This seems like a reasonable design, but not the only one. For > >> instance, Gmail might attach these headers, but I don't think of my > >> MUA as being subject to its authority and policies. > >> > > > > The MUA in the Gmail case is Gmail itself, isn't it? Or at least their > > client? Or are you referring to some IMAP access to it? > > > Yes. Like what I have on my phone. Indeed. IMAP and POP in the MSP case are a bit at odds with the simple ADMD model. That said, I'm not entirely sure what can be done about it that will clarify rather than further obscure the picture. > S 1.5.3. > >> > agents, assign (some) responsibility for the message (which implies > >> > authorization), and ensure that the listed portions of the message > >> > were not modified in transit. Since the signatures are not tied to > >> > SMTP connections, they can be added by either the ADMD of origin, > >> > intermediate ADMDs (such as a mailing list server), other handling > >> > agents, or any combination. > >> > >> I'm not sure how persuaded I am by this terminology. However, > >> regardless of that, this claim about SPF seems problematic in the > >> sense that you could have an intermediate MTA decorate the message > >> with the incoming IP address (in some unspecified way) but then have > >> the terminal MTA do the SPF validation. > >> > > > > Right, that's a property of SPF: It only evaluates the latest > > ("connecting" in that paragraph) hop, while DKIM often survives end-to-end > > irrespective of who's relaying it in to the local ADMD. > > > Hmm.. I think I'm making a different argument here. If the evaluating ADMD > trust claims made by a relaying hop, then it is able to do its own SPF > evaluation by having the relaying hop supply the IP address of the > originating MTA, even if the relaying hop didn't itself do SPF validation. > In this sense, it's not tied to the incoming connection. Quite right. And these sorts of arrangements where IP address information is derived not from the connection but from a Received: field, XCLIENT command, etc. are actually pretty common. Ned From nobody Sun Jan 6 12:14:07 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99A6130DF5 for ; Sun, 6 Jan 2019 12:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 XdMPGa5lvMrW for ; Sun, 6 Jan 2019 12:14:02 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 1D209130DEF for ; Sun, 6 Jan 2019 12:13:58 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id p6so28765975lfc.1 for ; Sun, 06 Jan 2019 12:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2OL6NZEIsrzfo3s6mtWUi/qYM4YEkMjbiBcu8CkL+9M=; b=MO/lbYb3s0zPKsmmgwjKIgB2X2Wmuq8T2FQ4zdDIC+nI7kf/1p32mDfUWZHEnjjW5I NgorpgfqmAK2U90wAIGXPKUcRI7uVAEj9N93bcVcCPthpxlpPwtahXlDvtcQjQAKaLGD 7k4UFiWFAommSJGzp69/7ZpHL6Ts0CsBkk109KYMkz+TAZ4urKRnV6T90zwRn2CK183v k7VTb+E9xvfMsvfXBlIUHdTPwQf5ybYvgmIR7sxInHgPGJHoCMX7aU8pAAouLe/om9R7 XsraTT2JqXzcR+CAuXqPk23xhvWEwtYep2FC9RTkcmdTWVmK1VGe/+l33vlb0SrlkzIt 3E6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2OL6NZEIsrzfo3s6mtWUi/qYM4YEkMjbiBcu8CkL+9M=; b=LA6PGJ8kFkOY6Wpsny5bOldSFWCYRMEnirmljaMXwzaEqhYaqgAFnWFQuHhOl/qNeg 9ChK7OsOzBxlF/mjenVOTAnPUAoxko4kWgkaCHi5nfybXhsuKHa720Kfo+7PVmYwaLCV RyMWEAuVxT6pe/vsJSx/n7d+Yaip5skCJj71zhLmVj0lnNpo5dtDyS28tVN+BuSWSO9l mt4O4sN/2wwVPZ7lG82xE1pjwSQjCmXl9Nn3MNqHiJvvgkxY69iAWRKw6ZLeibqU1le2 HbcowB9GjkTgnajY/DYcn67FMnUg5bNaxEKH3c9R+1AdX5CNjL8GmU+fldxP2KTHq5f0 5Elw== X-Gm-Message-State: AA+aEWagfu7qWhS93iQkSSAC4GXXl5yYEv3R8q6hnFlHxgLcos+C9gQA ToCXz3a5KCIJPpXO+wB8JjKAjm8TvYSBqP6WsTUMFg== X-Google-Smtp-Source: AFSGD/V+I1YQOV85Ewad3mmpbBWy1qFVcy8AXl5uMbhuPUdHx0+qKb0ioVixJ3m0yCabBPV9npuSdEyrYi6/vEkxh5o= X-Received: by 2002:a19:910d:: with SMTP id t13mr27448163lfd.98.1546805636240; Sun, 06 Jan 2019 12:13:56 -0800 (PST) MIME-Version: 1.0 References: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com> <01R1OU11IFIK00004L@mauve.mrochek.com> In-Reply-To: <01R1OU11IFIK00004L@mauve.mrochek.com> From: Eric Rescorla Date: Sun, 6 Jan 2019 12:13:17 -0800 Message-ID: To: Ned Freed Cc: "Murray S. Kucherawy" , Tim Draegen , IETF DMARC WG , The IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000007c45d3057ecfc0bf" Archived-At: Subject: Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jan 2019 20:14:05 -0000 --0000000000007c45d3057ecfc0bf Content-Type: text/plain; charset="UTF-8" On Sun, Jan 6, 2019 at 11:10 AM Ned Freed wrote: > > On Sat, Jan 5, 2019 at 6:20 PM Murray S. Kucherawy > > wrote: > > > > Hi Eric, thanks for your comments and sorry for the delay in replying. > > > > > > I've applied all of your comments except those below, for discussion: > > > > > > On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla wrote: > > > > > >> > > >> IMPORTANT > > >> S 7.10. > > >> > processing of these is outside of the intended scope of this > > >> document > > >> > (see Section 1.3), some early guidance to MUA developers is > > >> > appropriate here. > > >> > > > >> > Since MTAs are unlikely to strip Authentication-Results header > > >> fields > > >> > after mailbox delivery, > > This sentence seems nonsensical to me: A message that has undergone > delivery is by definition out of the MTA's hands - this is an essential > part of delivery semantics. > > Now, if you're talking about what MTAs do before, as opposed to after, > delivery, or submitting a previously delivered messge, or submitting a > message > part from a previously delivered message, or submitting a new message > containing content extracted from a previously delivered message, then you > need > to be clear that's what you mean. But in the submission cases I'll note > that > it's not unlikely that Authentication-Results fields at the top of such a > message will be removed by the submission process. > > > MUAs are advised in Section 4.1 to ignore > > >> > > >> I think you want to be stronger than "are advised to" > > >> > > > > > > I changed "advised" to "warned"; is that adequate? It's referring to a > > > SHOULD in 4.1. > > > > > > What I am thinking is that this should be normative language. > > Whereas I'm thinking that this is poor advice in general and should either > be > more tightly qualified or removed. > I could also live with that. I don't really have a substantive opinion here about this advice, I'm just trying to avoid having language which sort of exhorts people do to things, but not really. -Ekr > The problem is that there are many different reasons for exacting an > encapsulated message, and the optimum handling of header fields varies > dependin on the reason. > > If the intention is, say, to "burst" a mailing list digest into its > component > messages, since these fields cannot be asumed to have been > generated by a trusted agent, whereas top-level Authentication-Results: > fields > may have some trust associated with them, then by all means remove the > fields. > > However, if the digest was constucted from previously delivered messages > with trusted Authentication-Results fields, retaining them is OK and may > even be of value. > > And if the the intent is to use the messages as input to some sort of > security > scanning process, removing them may actually have an adverse effect. > > There are undoubtedly many other cases that arise, but I think this > demonstrates the point. > > Of course having a simple rule would be nice. But there's no simple rule > for deciding where the boundary between trusted and untrusted Received: > fields lies - something which already complicates the handling of extracted > messages - and we manage to deal with that all the time. > > > > > > > S 1.2. > > >> > Thus, this document defines a "trust boundary" as the > delineation > > >> > between "external" and "internal" entities. Services that are > > >> > internal -- within the trust boundary -- are provided by the > ADMD's > > >> > infrastructure for its users. Those that are external are > outside > > >> of > > >> > the authority of the ADMD. By this definition, hosts that are > > >> within > > >> > a trust boundary are subject to the ADMD's authority and > policies, > > >> > > >> This seems like a reasonable design, but not the only one. For > > >> instance, Gmail might attach these headers, but I don't think of my > > >> MUA as being subject to its authority and policies. > > >> > > > > > > The MUA in the Gmail case is Gmail itself, isn't it? Or at least their > > > client? Or are you referring to some IMAP access to it? > > > > > > Yes. Like what I have on my phone. > > Indeed. IMAP and POP in the MSP case are a bit at odds with the simple > ADMD model. That said, I'm not entirely sure what can be done about it > that will clarify rather than further obscure the picture. > > > S 1.5.3. > > >> > agents, assign (some) responsibility for the message (which > implies > > >> > authorization), and ensure that the listed portions of the > message > > >> > were not modified in transit. Since the signatures are not > tied to > > >> > SMTP connections, they can be added by either the ADMD of > origin, > > >> > intermediate ADMDs (such as a mailing list server), other > handling > > >> > agents, or any combination. > > >> > > >> I'm not sure how persuaded I am by this terminology. However, > > >> regardless of that, this claim about SPF seems problematic in the > > >> sense that you could have an intermediate MTA decorate the message > > >> with the incoming IP address (in some unspecified way) but then have > > >> the terminal MTA do the SPF validation. > > >> > > > > > > Right, that's a property of SPF: It only evaluates the latest > > > ("connecting" in that paragraph) hop, while DKIM often survives > end-to-end > > > irrespective of who's relaying it in to the local ADMD. > > > > > > Hmm.. I think I'm making a different argument here. If the evaluating > ADMD > > trust claims made by a relaying hop, then it is able to do its own SPF > > evaluation by having the relaying hop supply the IP address of the > > originating MTA, even if the relaying hop didn't itself do SPF > validation. > > In this sense, it's not tied to the incoming connection. > > Quite right. And these sorts of arrangements where IP address information > is derived not from the connection but from a Received: field, XCLIENT > command, etc. are actually pretty common. > > Ned > --0000000000007c45d3057ecfc0bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 6, 2019 at 11:10 AM Ned Freed <ned.freed@mrochek.com> wrote:
=
> On Sat, Jan 5, 2019 = at 6:20 PM Murray S. Kucherawy <superuser@gmail.com>
> wrote:

> > Hi Eric, thanks for your comments and sorry for the delay in repl= ying.
> >
> > I've applied all of your comments except those below, for dis= cussion:
> >
> > On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >>
> >> IMPORTANT
> >> S 7.10.
> >> >=C2=A0 =C2=A0 =C2=A0 processing of these is outside of th= e intended scope of this
> >> document
> >> >=C2=A0 =C2=A0 =C2=A0 (see Section 1.3), some early guidan= ce to MUA developers is
> >> >=C2=A0 =C2=A0 =C2=A0 appropriate here.
> >> >
> >> >=C2=A0 =C2=A0 =C2=A0 Since MTAs are unlikely to strip Aut= hentication-Results header
> >> fields
> >> >=C2=A0 =C2=A0 =C2=A0 after mailbox delivery,

This sentence seems nonsensical to me: A message that has undergone
delivery is by definition out of the MTA's hands - this is an essential=
part of delivery semantics.

Now, if you're talking about what MTAs do before, as opposed to after,<= br> delivery, or submitting a previously delivered messge, or submitting a mess= age
part from a previously delivered message, or submitting a new message
containing content extracted from a previously delivered message, then you = need
to be clear that's what you mean. But in the submission cases I'll = note that
it's not unlikely that Authentication-Results fields at the top of such= a
message will be removed by the submission process.

> MUAs are advised in Section 4.1 to ignore
> >>
> >> I think you want to be stronger than "are advised to&quo= t;
> >>
> >
> > I changed "advised" to "warned"; is that adeq= uate?=C2=A0 It's referring to a
> > SHOULD in 4.1.
> >

> What I am thinking is that this should be normative language.

Whereas I'm thinking that this is poor advice in general and should eit= her be
more tightly qualified or removed.

I co= uld also live with that. I don't really have a substantive opinion here= about this
advice, I'm just trying to avoid having language = which sort of exhorts people
do to things, but not really.

-Ekr


The problem is that there are many different reasons for exacting an
encapsulated message, and the optimum handling of header fields varies
dependin on the reason.

If the intention is, say, to "burst" a mailing list digest into i= ts component
messages, since these fields cannot be asumed to have been
generated by a trusted agent, whereas top-level Authentication-Results: fie= lds
may have some trust associated with them, then by all means remove the fiel= ds.

However, if the digest was constucted from previously delivered messages with trusted Authentication-Results fields, retaining them is OK and may even be of value.

And if the the intent is to use the messages as input to some sort of secur= ity
scanning process, removing them may actually have an adverse effect.

There are undoubtedly many other cases that arise, but I think this
demonstrates the point.

Of course having a simple rule would be nice. But there's no simple rul= e
for deciding where the boundary between trusted and untrusted Received:
fields lies - something which already complicates the handling of extracted=
messages - and we manage to deal with that all the time.

> >
> > S 1.2.
> >> >=C2=A0 =C2=A0 =C2=A0 Thus, this document defines a "= trust boundary" as the delineation
> >> >=C2=A0 =C2=A0 =C2=A0 between "external" and &qu= ot;internal" entities.=C2=A0 Services that are
> >> >=C2=A0 =C2=A0 =C2=A0 internal -- within the trust boundar= y -- are provided by the ADMD's
> >> >=C2=A0 =C2=A0 =C2=A0 infrastructure for its users.=C2=A0 = Those that are external are outside
> >> of
> >> >=C2=A0 =C2=A0 =C2=A0 the authority of the ADMD.=C2=A0 By = this definition, hosts that are
> >> within
> >> >=C2=A0 =C2=A0 =C2=A0 a trust boundary are subject to the = ADMD's authority and policies,
> >>
> >> This seems like a reasonable design, but not the only one. Fo= r
> >> instance, Gmail might attach these headers, but I don't t= hink of my
> >> MUA as being subject to its authority and policies.
> >>
> >
> > The MUA in the Gmail case is Gmail itself, isn't it?=C2=A0 Or= at least their
> > client?=C2=A0 Or are you referring to some IMAP access to it?
> >

> Yes. Like what I have on my phone.

Indeed. IMAP and POP in the MSP case are a bit at odds with the simple
ADMD model. That said, I'm not entirely sure what can be done about it<= br> that will clarify rather than further obscure the picture.

> S 1.5.3.
> >> >=C2=A0 =C2=A0 =C2=A0 agents, assign (some) responsibility= for the message (which implies
> >> >=C2=A0 =C2=A0 =C2=A0 authorization), and ensure that the = listed portions of the message
> >> >=C2=A0 =C2=A0 =C2=A0 were not modified in transit.=C2=A0 = Since the signatures are not tied to
> >> >=C2=A0 =C2=A0 =C2=A0 SMTP connections, they can be added = by either the ADMD of origin,
> >> >=C2=A0 =C2=A0 =C2=A0 intermediate ADMDs (such as a mailin= g list server), other handling
> >> >=C2=A0 =C2=A0 =C2=A0 agents, or any combination.
> >>
> >> I'm not sure how persuaded I am by this terminology. Howe= ver,
> >> regardless of that, this claim about SPF seems problematic in= the
> >> sense that you could have an intermediate MTA decorate the me= ssage
> >> with the incoming IP address (in some unspecified way)=C2=A0 = but then have
> >> the terminal MTA do the SPF validation.
> >>
> >
> > Right, that's a property of SPF: It only evaluates the latest=
> > ("connecting" in that paragraph) hop, while DKIM often = survives end-to-end
> > irrespective of who's relaying it in to the local ADMD.
> >

> Hmm.. I think I'm making a different argument here. If the evaluat= ing ADMD
> trust claims made by a relaying hop, then it is able to do its own SPF=
> evaluation by having the relaying hop supply the IP address of the
> originating MTA, even if the relaying hop didn't itself do SPF val= idation.
> In this sense, it's not tied to the incoming connection.

Quite right. And these sorts of arrangements where IP address information is derived not from the connection but from a Received: field, XCLIENT
command, etc. are actually pretty common.

=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 =C2=A0 =C2=A0 =C2=A0 Ned
--0000000000007c45d3057ecfc0bf-- From nobody Mon Jan 7 03:09:47 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D241130E9A; Mon, 7 Jan 2019 03:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=j/IOxBAG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bzHtmNFM 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 b1B5huVK_9w0; Mon, 7 Jan 2019 03:09:42 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2523B130DE7; Mon, 7 Jan 2019 03:09:42 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 032292206F; Mon, 7 Jan 2019 06:09:41 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 07 Jan 2019 06:09:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:date:subject:references:in-reply-to; s=fm2; bh=YXa yO5+Selv2bRNBANear2PQ50BeQ1M7tYQyMBWJx4Q=; b=j/IOxBAG1R5ZUKVfmbJ a1K5Eqv9a8KmztWq59Z4ubxLfCxFqlOiSFlBuQORSup8A00WhRNxsYfK0S3Cy7Cc qp0sjE9esuUVnf4dO26O4RHg3uAX1lWsLX7TZoD+Op8y11s/KNsRAiDcqAP78QRz ucv6oJvogCbjcTSToCpCOKEbsFj3KLhmDkiqosPWdcWVAH4JdGKMeAlnTCLaTiyz KPZtNlnBWDK+EkAyBwuZcVA0CFJhj7VSjn8K6vEcACpNa3mrXD2HL7TJb1Nr+ZAa BLh3Kmb4LJjAo4NpgxutKC/tEqAxnv7qnxA1qXCyEK9kX3XKWGaS1XZ4CJtYPovR tdA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=YXayO5+Selv2bRNBANear2PQ50BeQ1M7tYQyMBWJx 4Q=; b=bzHtmNFMSAcRF+ktDyy5lCqKOETltB4gytMzJxgahLQaRoNBVeZHmeHb0 jiSvKjhyi1Py93oXOWGXzEdn5ona1xdMn2qW5AW+eNwZw4ejLrfnxx20PVnV2Xn/ KlXRJGbu9MaWc08idWpB03DCVTLsP6TtIyepwmQdxEfW7NEovQJr1cBb2FuUtjTc Ku9WXHjZWbAzbOjUrVRceyr6Hp/IBoIlmTphugKM9eMqr+Pf1dStqGxLDghgxMwJ pxzsT23MX90mfI+LjmUbYNghX7JWV97FOr3Pdb6KjnpKxQZIjHVFHVYFuB9fQsG2 Yswi9qU916CzHLr9Hnqdi2kLIpkeg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdejgddvvdculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkffhvfgggfgtofffufhfjgesrgejreerredtjeenucfhrhhomheptehlvgig vgihucfovghlnhhikhhovhcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh eqnecuffhomhgrihhnpegslhgrtghkohhpshdrohhrghdpihgvthhfrdhorhhgpdhinhht vghrnhgvthhmvghsshgrghhinhhgthgvtghhnhholhhoghihrdhorhhgnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucev lhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0E2C29E22A; Mon, 7 Jan 2019 06:09:40 -0500 (EST) Message-Id: <1546859379.2718501.1627553176.011EB82B@webmail.messagingengine.com> From: Alexey Melnikov To: "Murray S. Kucherawy" Cc: Barry Leiba , Ben Campbell , Tim Draegen , IETF DMARC WG , IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_154685937927185011" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fc1a05a6 Date: Mon, 07 Jan 2019 11:09:39 +0000 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> <1543613485.3765543.1594837224.1E64FAB8@webmail.messagingengine.com> In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 11:09:45 -0000 This is a multi-part message in MIME format. --_----------=_154685937927185011 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sun, Jan 6, 2019, at 5:45 AM, Murray S. Kucherawy wrote: > Here's what I've come up with. This is a diff between RFC7601 as > published and what I propose as RFC7601bis to resolve all of the > DISCUSSes and most of the COMMENTs from IESG review. Please let me > know if I've missed anything. I'll post it at the end of the coming > week if there are no issues raised.> > http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601.diff.htmlThis is looks good to me. One small ABNF glitch introduced: >authres-header-field = "Authentication-Results:" authres-payload > >authres-payload = "Authentication-Results:" [CFWS] authserv-id You have "Authentication-Results:" twice now. I think you want to delete it from authres-payload. > > -MSK > > On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov > wrote:>> On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote: >> > Murray, would you please copy the relevant IANA Considerations >> > sections from RFC 7601 into 7601bis and change the tenses >> > appropriately (perhaps just with a sentence in each subsection >> > that>> > says, "The following was done in the previous edition of this >> > document, RFC 7601:", or some such >> >> Even better if you say something like "the following is unchanged >> from RFC 7601:".>> >> >), and then let's have a quick >> > working group review of the result? (And, of course, change it >> > back>> > to "obsoletes" rather than "updates".) >> > >> > As it's editorial, I'm sure we don't need to go back through any >> > approval process, and we can get the DISCUSS cleared and move >> > forward.>> >> I agree. I think this is purely editorial, albeit an important issue >> for the final document.>> >> > Thanks, >> > Barry >> > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov >> > wrote:>> > > >> > > Hi all, >> > > >> > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: >> > > > I actually agree with this: I think the better answer is to go >> > > > back to>> > > > "obsoletes" and to have this document include the details of >> > > > what was>> > > > put in the registries before. But the working group decided >> > > > to do it>> > > > the other way, and there's been criticism in the past of ADs >> > > > (and, so,>> > > > by extension, chairs) picking on this sort of stuff, so I >> > > > decided to>> > > > let it go. I'll let the IESG sort this one out, but I'll go >> > > > on record>> > > > as saying what I think the better way to handle it is. >> > > >> > > I think incorporating older registrations is the cleaner way of >> > > dealing with Ben's & Benjamin's DISCUSSes, as then the document >> > > is self contained and there is no need for readers to see >> > > obsoleted RFCs. So this would be my preference.>> > > >> > > If the WG doesn't want to do this, then the document needs >> > > editing to be correct as per Benjamin's DISCUSS.>> > > >> > > Best Regards, >> > > Alexey >> > > >> > > > That said, I don't think it's a huge deal either way. >> > > > >> > > > Barry >> > > > >> > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell >> > > > wrote:>> > > > > >> > > > > Ben Campbell has entered the following ballot position for >> > > > > draft-ietf-dmarc-rfc7601bis-04: Discuss >> > > > > >> > > > > When responding, please keep the subject line intact and >> > > > > reply to all>> > > > > email addresses included in the To and CC lines. (Feel free >> > > > > to cut this>> > > > > introductory paragraph, however.) >> > > > > >> > > > > >> > > > > Please refer to >> > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html>> > > > > for more information about IESG DISCUSS and COMMENT >> > > > > positions.>> > > > > >> > > > > >> > > > > The document, along with other ballot positions, can be >> > > > > found here:>> > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/>> > > > > >> > > > > >> > > > > >> > > > > ------------------------------------------------------------ >> > > > > ---------->> > > > > DISCUSS: >> > > > > ------------------------------------------------------------ >> > > > > ---------->> > > > > >> > > > > This is mainly a process discuss. I share Alvaro's concern >> > > > > about this being>> > > > > marked as "updating" RFC7601, when it seem like a full >> > > > > replacement. I'm>> > > > > promoting it to a DISCUSS because I think this needs to be >> > > > > resolved before>> > > > > publication. >> > > > > >> > > > > The current structure will make it very difficult for >> > > > > readers to figure out>> > > > > which parts of each doc they need to worry about. I think it >> > > > > needs to either go>> > > > > back to "obsoleting" 7601, or it needs to be recast to just >> > > > > talk about the>> > > > > changes. Note that if the former path is chosen, the IANA >> > > > > considerations in>> > > > > 7601 will need to be copied forward. >> > > > > >> > > > > >> > > > > ------------------------------------------------------------ >> > > > > ---------->> > > > > COMMENT: >> > > > > ------------------------------------------------------------ >> > > > > ---------->> > > > > >> > > > > I mostly just reviewed the diff. Thank you for mostly >> > > > > avoiding unnecessary>> > > > > changes. That makes the diff tools much more useful than >> > > > > they are for bis>> > > > > drafts that make wholesale organization and stylistic >> > > > > changes.>> > > > > >> > > > > >> > > > >> > > > >> > > > -- >> > > > Barry >> > > > -- >> > > > Barry Leiba (barryleiba@computer.org) >> > > > http://internetmessagingtechnology.org/ >> > > > --_----------=_154685937927185011 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sun, Jan 6, 2019, at 5:45 AM, Murray S. Kucherawy wrote:
Here's what I've come up with.  This is a diff between RFC7601 as published and what I propose as RFC7601bis to resolve all of the DISCUSSes and most of the COMMENTs from IESG review.  Please let me know if I've missed anything.  I'll post it at the end of the coming week if there are no issues raised.

This is looks good to me. One small ABNF glitch introduced:

>authres-header-field  = "Authentication-Results:" authres-payload
>
>authres-payload = "Authentication-Results:" [CFWS] authserv-id

You have "Authentication-Results:" twice now. I think you want to delete it from authres-payload.


-MSK

On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote:
> Murray, would you please copy the relevant IANA Considerations
> sections from RFC 7601 into 7601bis and change the tenses
> appropriately (perhaps just with a sentence in each subsection that
> says, "The following was done in the previous edition of this
> document, RFC 7601:", or some such

Even better if you say something like "the following is unchanged from RFC 7601:".

>), and then let's have a quick
> working group review of the result?  (And, of course, change it back
> to "obsoletes" rather than "updates".)
>
> As it's editorial, I'm sure we don't need to go back through any
> approval process, and we can get the DISCUSS cleared and move forward.

I agree. I think this is purely editorial, albeit an important issue for the final document.

> Thanks,
> Barry
> On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
> >
> > Hi all,
> >
> > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote:
> > > I actually agree with this: I think the better answer is to go back to
> > > "obsoletes" and to have this document include the details of what was
> > > put in the registries before.  But the working group decided to do it
> > > the other way, and there's been criticism in the past of ADs (and, so,
> > > by extension, chairs) picking on this sort of stuff, so I decided to
> > > let it go.  I'll let the IESG sort this one out, but I'll go on record
> > > as saying what I think the better way to handle it is.
> >
> > I think incorporating older registrations is the cleaner way of dealing with Ben's & Benjamin's DISCUSSes, as then the document is self contained and there is no need for readers to see obsoleted RFCs. So this would be my preference.
> >
> > If the WG doesn't want to do this, then the document needs editing to be correct as per Benjamin's DISCUSS.
> >
> > Best Regards,
> > Alexey
> >
> > > That said, I don't think it's a huge deal either way.
> > >
> > > Barry
> > >
> > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell <ben@nostrum.com> wrote:
> > > >
> > > > Ben Campbell has entered the following ballot position for
> > > > draft-ietf-dmarc-rfc7601bis-04: Discuss
> > > >
> > > > When responding, please keep the subject line intact and reply to all
> > > > email addresses included in the To and CC lines. (Feel free to cut this
> > > > introductory paragraph, however.)
> > > >
> > > >
> > > > for more information about IESG DISCUSS and COMMENT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be found here:
> > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------------
> > > > DISCUSS:
> > > > ----------------------------------------------------------------------
> > > >
> > > > This is mainly a process discuss. I share Alvaro's concern about this being
> > > > marked as "updating" RFC7601, when it seem like a full replacement. I'm
> > > > promoting it to a DISCUSS because I think this needs to be resolved before
> > > > publication.
> > > >
> > > > The current structure will make it very difficult for readers to figure out
> > > > which parts of each doc they need to worry about. I think it needs to either go
> > > > back to "obsoleting" 7601, or it needs to be recast to just talk about the
> > > > changes. Note that if the former path is chosen, the IANA considerations in
> > > > 7601 will need to be copied forward.
> > > >
> > > >
> > > > ----------------------------------------------------------------------
> > > > COMMENT:
> > > > ----------------------------------------------------------------------
> > > >
> > > > I mostly just reviewed the diff. Thank you for mostly avoiding unnecessary
> > > > changes. That makes the diff tools much more useful than they are for bis
> > > > drafts that make wholesale organization and stylistic changes.
> > > >
> > > >
> > >
> > >
> > > --
> > > Barry
> > > --
> > > Barry Leiba  (barryleiba@computer.org)
> > >

--_----------=_154685937927185011-- From nobody Sun Jan 13 16:16:14 2019 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 5C29F1200B3; Sun, 13 Jan 2019 16:16:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154742496333.14750.14552328203377285616@ietfa.amsl.com> Date: Sun, 13 Jan 2019 16:16:03 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 00:16: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 WG of the IETF. Title : DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) Author : Scott Kitterman Filename : draft-ietf-dmarc-psd-01.txt Pages : 9 Date : 2019-01-13 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. DMARC policies can be applied at the individual domain level or for a set of domains at the organizational level. The design of DMARC precludes grouping policies for a set of domains above the organizational level, such as TLDs (Top Level Domains). These types of domains (which are not all at the top level of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). For the subset of PSDs that require DMARC usage, this memo describes an extension to DMARC to enable DMARC functionality for such domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-psd-01 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-01 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 Sun Jan 13 16:19:51 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288F812F18C for ; Sun, 13 Jan 2019 16:19:50 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=WRy6KJwS; dkim=pass (2048-bit key) header.d=kitterman.com header.b=cYR6o69T 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 hYi31H_h-wbo for ; Sun, 13 Jan 2019 16:19:48 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B4212D4EB for ; Sun, 13 Jan 2019 16:19:47 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1547425180; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=OdproJYQbPwOB2UoPifqU2ywwKvwNtfJMfgVcA1Ndvw=; b=WRy6KJwSi+Nd1L1HEZI6FyUcpWsGq788Vk1In0sWlgE0tBH7uquY9dtZ 6GMooAqlIuUfSCbigKP49Em4jycmAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1547425180; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=OdproJYQbPwOB2UoPifqU2ywwKvwNtfJMfgVcA1Ndvw=; b=cYR6o69T1fL7YxljNMvYJKS7PT6UuqgrFFh5iYCMzHDyg9Cf44iefHKp g+omcL3UTvU7238dLnffkbQ/vtzg7O5QZp1IGTtrSPXc+jaOYwyS7GTRq2 LRCiBTaopATXNQ0xMOYUHINCEYi+yHYqlZ6/vLulHTuXRpmv8OFmzyjuwH NZY+8H6MBhRuzxFD6jL8JXSPZYRD4Hc9ZMW1xE4wNJzf2sawb5pItTNWO7 BSesk0msXC6zEfVcDR7hUdlOtEalkcpW6qrpOJ/OFREl4F56cQyfD+y9V4 yLP+TtG6XSYGUi1FV5ikTudiqF5btk2AT05GDGxaSFDYwSS4DlQAEA== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 625362D4078E for ; Sun, 13 Jan 2019 18:19:40 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 13 Jan 2019 19:19:39 -0500 Message-ID: <5126347.eOcQ2jtf8Q@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-163-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 00:19:50 -0000 This update removes the IANA registry (which is what I think I was supposed to do based on the feedback to date). I also bulked up the Privacy/Security considerations descriptions since they are no longer mitigated. I'd like feedback on the best path forward. Essentially this draft replaces the IANA registry with an undefined way to know where PSD DMARC is appropriate. I think we need something better than that, but I didn't know what. Suggestions please. Scott K ---------- Forwarded Message ---------- Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-01.txt Date: Sunday, January 13, 2019, 04:16:03 PM From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: dmarc@ietf.org 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 WG of the IETF. Title : DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) Author : Scott Kitterman Filename : draft-ietf-dmarc-psd-01.txt Pages : 9 Date : 2019-01-13 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. DMARC policies can be applied at the individual domain level or for a set of domains at the organizational level. The design of DMARC precludes grouping policies for a set of domains above the organizational level, such as TLDs (Top Level Domains). These types of domains (which are not all at the top level of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). For the subset of PSDs that require DMARC usage, this memo describes an extension to DMARC to enable DMARC functionality for such domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-psd-01 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-01 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 ----------------------------------------- From nobody Mon Jan 14 01:54:45 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4CF130FC5 for ; Mon, 14 Jan 2019 01:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 jLpjkPYLujzl for ; Mon, 14 Jan 2019 01:54:40 -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 5169612896A for ; Mon, 14 Jan 2019 01:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1547459678; bh=2l0WP33m3B/U/QNqEIfPkhBFfvJRY0nvI3ZiN9Dx5r0=; l=894; h=To:Cc:References:From:Date:In-Reply-To; b=CetHgD4Y3d0Ni0itD+Jy1F6DtHdcYZDtHk2Y8eepXK3stEA304+4NkqlEaubP/sRU vO1cHlaGtqf25AqtA9lQC8OtEFROq2dXE6QiZA94Q8CYCwLfDvhy2MZVVA8MqQp39L kB3WAhsA77sIxFMd3IM0cGxPqwurlRojgStP0acnYb6bgmPDxidkzf5u+Vpe1 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 14 Jan 2019 10:54:38 +0100 id 00000000005DC013.000000005C3C5C5E.000006FD To: "Murray S. Kucherawy" , Alexey Melnikov Cc: Barry Leiba , dmarc-ietf References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> <1543613485.3765543.1594837224.1E64FAB8@webmail.messagingengine.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <2272f6d5-6c80-b80d-4aff-bdcc69449cf8@tana.it> Date: Mon, 14 Jan 2019 10:54:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 09:54:43 -0000 On Sun 06/Jan/2019 06:45:57 +0100 Murray S. Kucherawy wrote: > Here's what I've come up with.  This is a diff between RFC7601 as published and > what I propose as RFC7601bis to resolve all of the DISCUSSes and most of the > COMMENTs from IESG review.  Please let me know if I've missed anything.  I'll > post it at the end of the coming week if there are no issues raised. > > http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601.diff.html I see sender-id still has full citizenship. Now I'm not clear which will be first, but my feeling is that rfc7601bis and status-change-change-sender-id-to-historic are going to be published more or less at the same time. When a method is moved to historic, are the corresponding parameters in the IANA registry moved to deprecated? If yes, should the move be stated by which document? Thank you Ale -- From nobody Mon Jan 14 02:03:51 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6652130FB8 for ; Mon, 14 Jan 2019 02:03:49 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=1wBsNPk1; dkim=pass (2048-bit key) header.d=kitterman.com header.b=i9zixT4x 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 BeiJif3P4dmx for ; Mon, 14 Jan 2019 02:03:47 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD65F12896A for ; Mon, 14 Jan 2019 02:03:47 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1547460225; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=YnlFq9ZeW4KnftevfhTzpRpNgLSZwKvQ4icGXlXooa0=; b=1wBsNPk160EJ/yO6fPs+muGIcLY3/Z8eXI6Hw4FHP9HaXLZaN/grouOX wtpEfJF32J2C/ITGu2e1kHyS0MUtCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1547460225; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=YnlFq9ZeW4KnftevfhTzpRpNgLSZwKvQ4icGXlXooa0=; b=i9zixT4xxjG9X51zLVS4NyRd8p4uygaUtxOkHe+RSnp9sVWw9Gtl1Ien S8Gh2OsVqyODjLtpYk+wejDoi5H4TUvcRrh5wVH+7e64ftbaiOq4ULyF9n gYmA9yXS2vKw5lbhUCw+j+l3awhtZ2c0saWd0eu5Q6eKbTGkP/qMrDzmmS +8ebAE4IW5B85jN75w6MiyvDSwYhd6F4CpLahkbjFqpw32aj3iKlfcczSQ 1YRA4fxfzIbpx7wZyZ0wyt+qFEtheoRXLiS1gojRaUGWm6XNdlJJKY7qQ/ Q3RBe0soNFV6tacF2LVcpSLlkaEpX1iq/3SjAHgVbjnme9XeSAOTxg== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 3FAD62D4078E for ; Mon, 14 Jan 2019 04:03:45 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 14 Jan 2019 05:03:41 -0500 Message-ID: <1927558.aO5YKDjPkr@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <2272f6d5-6c80-b80d-4aff-bdcc69449cf8@tana.it> References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <2272f6d5-6c80-b80d-4aff-bdcc69449cf8@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 10:03:50 -0000 On Monday, January 14, 2019 10:54:37 AM Alessandro Vesely wrote: > On Sun 06/Jan/2019 06:45:57 +0100 Murray S. Kucherawy wrote: > > Here's what I've come up with. This is a diff between RFC7601 as > > published and what I propose as RFC7601bis to resolve all of the > > DISCUSSes and most of the COMMENTs from IESG review. Please let me know > > if I've missed anything. I'll post it at the end of the coming week if > > there are no issues raised. > > > > http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601 > > .diff.html > I see sender-id still has full citizenship. Now I'm not clear which will be > first, but my feeling is that rfc7601bis and > status-change-change-sender-id-to-historic are going to be published more or > less at the same time. > > When a method is moved to historic, are the corresponding parameters in the > IANA registry moved to deprecated? If yes, should the move be stated by > which document? A quick look at Domainkeys in the registry and RFC 7601 will answer that question for you. Let's not hold this up. Scott K From nobody Mon Jan 14 06:16:33 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3B8131068 for ; Mon, 14 Jan 2019 06:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 l4nUdNJ-L1ic for ; Mon, 14 Jan 2019 06:16:31 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 B281D13102D for ; Mon, 14 Jan 2019 06:16:30 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id c19-v6so19147655lja.5 for ; Mon, 14 Jan 2019 06:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PtK1TJ63qMiLwIP0rnkMObGGHlT74pGtkHKqHixZ0CQ=; b=MqPqNcNOTQqgvBAQauzEb+0p+DSjcl5w/wGbli8uCOI3ikck/qxC7/y3+V75zmwGQI +vNvpR7t41+KjrTyaDFtKfcUZCe9WWhk4FEsseeIjxMIs+LyC9t0ybr/bnd5woqeeNMX L6Rv6ROURfcNUR6nrSDLl7VMosWDEtQ+lcDFQ1DeHDlCiUsOoQkxdeqIu1RTlFNT+uEm mp0OyNmOIZB9kudbFlwdubaHasHaBrtn3qQLGp3tVV3lH2D6RqgmrVtCU2ipvQcsPkoA iKUMz83P9hPp9c+zK8pRyXLpJnnttZDZrHkXbJXi6UajAGfrr7R2Dof7q8YlPIym9SUw spCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PtK1TJ63qMiLwIP0rnkMObGGHlT74pGtkHKqHixZ0CQ=; b=dBF4FwIPefxuXTAJD75iWub4HlgmhV1baC1xUVNbV9MQ2hVDiytMMzB0WEwfk50+RN Dp9e75NcsI3MnwcmwzfOId2FZlRzh2+m8sQIjI6ymR0HXvfdEFi9Ev+4gLlK6CCv0hLY 18QZaTVxOusZKbo8B1lKZlqNND3qE6rz31CO6VIoYOl7j6dtBYsvud57hFu+lG5fjjfC 6fkje6BmZmRgEiOpT55t+MR+LavqO6sYzWdIg6W1+bv7Ybx2QYLlQsiDOIvo47iVAwQH kRDpzbVO/uvqr/7qLkD8jHxVPd8YsVzsYVpJ7kfesHSm+SodFZmnfMkKwSjRC3Y5EvXK CmOg== X-Gm-Message-State: AJcUukfvS9xLxPUQiP46H2vW1AY6oj8pnCK8r+IFTSfFZ1GgAYo5Du+e eEwAjzeeoUohd3qLoZN9d3qw5hVYgFNEwr9zPh8v8w== X-Google-Smtp-Source: ALg8bN7geap3k5erwYR/LSU8+W29pLgOLFLfnAWARghH3J5zhmZEx394pVBABsmsEes3bDlx5YKWjFIP9auhqkye60E= X-Received: by 2002:a2e:1603:: with SMTP id w3-v6mr14712460ljd.33.1547475388571; Mon, 14 Jan 2019 06:16:28 -0800 (PST) MIME-Version: 1.0 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <2272f6d5-6c80-b80d-4aff-bdcc69449cf8@tana.it> <1927558.aO5YKDjPkr@kitterma-e6430> In-Reply-To: <1927558.aO5YKDjPkr@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 14 Jan 2019 09:16:16 -0500 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000d5a985057f6bb091" Archived-At: Subject: Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 14:16:32 -0000 --000000000000d5a985057f6bb091 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman wrote: > > > I see sender-id still has full citizenship. Now I'm not clear which > will be > > first, but my feeling is that rfc7601bis and > > status-change-change-sender-id-to-historic are going to be published > more or > > less at the same time. > > > > When a method is moved to historic, are the corresponding parameters in > the > > IANA registry moved to deprecated? If yes, should the move be stated by > > which document? > > A quick look at Domainkeys in the registry and RFC 7601 will answer that > question for you. Let's not hold this up. > +1. This was not identified in IESG Review as something that needs fixing so I'd just as soon not make more changes now. If we keep changing it, it's going to need another cycle through the working group. -MSK --000000000000d5a985057f6bb091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 14, 2019 at 5:03 AM Scott Kit= terman <sklist@kitterman.com= > wrote:

> I see sender-id still has full citizenship.=C2=A0 Now I'm not clea= r which will be
> first, but my feeling is that rfc7601bis and
> status-change-change-sender-id-to-historic are going to be published m= ore or
> less at the same time.
>
> When a method is moved to historic, are the corresponding parameters i= n the
> IANA registry moved to deprecated?=C2=A0 If yes, should the move be st= ated by
> which document?

A quick look at Domainkeys in the registry and RFC 7601 will answer that question for you.=C2=A0 Let's not hold this up.
+1.=C2=A0 This was not identified in IESG Review as something = that needs fixing so I'd just as soon not make more changes now.=C2=A0 = If we keep changing it, it's going to need another cycle through the wo= rking group.

-MSK
--000000000000d5a985057f6bb091-- From nobody Mon Jan 14 07:02:23 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADA31277BB for ; Mon, 14 Jan 2019 07:02:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 XsolS3h_VG8z for ; Mon, 14 Jan 2019 07:02:12 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 CA10D12D4EC for ; Mon, 14 Jan 2019 07:02:12 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id k2so17807058iog.7 for ; Mon, 14 Jan 2019 07:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TESckSnfRa+ISeIpfy9CbPvPYjMVM06xdHXxehOCqnA=; b=XKiTlE99JPlJUFwIC8aKoz571sDDsMIkgGdzCXtcYwo0mooU8z11yXWrZc7l0Rnf33 1Gh3Ak09nXoTN1MaBVsvCDzq3/B4uycmAIshUvX9PIDR/DQwOEdTNhIPafimfpBDuHeh MhUzKCGcxMlROLKe7NlpGXN7drozZd04Mjqn8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TESckSnfRa+ISeIpfy9CbPvPYjMVM06xdHXxehOCqnA=; b=BvtKnbl0J65YlwMqmSHvBIWBrQFjKvnJc97kHTIy7F6kwZv6JET4zn6WdG4MeTCE2g dZNsJtU95uVTVHWDL0JaDhD6kWU2drfxm3PA6fRMhXfkiq8EkJ1EbM0Tx50QKueLti9J vnFFm0C3Wif51fYcT5z0J0vTk1Ptwg/W5tt9iH27FC3UGeOLDhG+w5Mzb/H2Jhq7Oz5t KWsAPJTz6L39ByukV0axXHKucJsGmbudO3CYJB573/Mr6j9vTullDYuBgF9DVzUUuL1T uA1z5Aey7A1IsgdztboLSKesAjTdpyIwl7rmYVsJ8UT8YcVVZIjR63sfHSxj6tIWFVcQ JOag== X-Gm-Message-State: AJcUukfKGpp7btYuUQ0GWPS6JRf7ZDjCuKo/AFtycPESaPwpXm+LmB3c GFdugy8Go5NtHMWD7IuA1fPFuxKOMpUzUKmx0MyTgA== X-Google-Smtp-Source: ALg8bN5isF0D9vRctOUJrryMABwb3vZ9AaHHrEaB8n5ap4zm1RbsO9DxFzz5JNBLIvOb45FaIWRzqdO+q1cclBw+muA= X-Received: by 2002:a6b:6306:: with SMTP id p6mr16840554iog.196.1547478131952; Mon, 14 Jan 2019 07:02:11 -0800 (PST) MIME-Version: 1.0 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <2272f6d5-6c80-b80d-4aff-bdcc69449cf8@tana.it> <1927558.aO5YKDjPkr@kitterma-e6430> In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 14 Jan 2019 07:02:01 -0800 Message-ID: To: "Murray S. Kucherawy" Cc: Scott Kitterman , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005a6718057f6c5403" Archived-At: Subject: Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 15:02:20 -0000 --0000000000005a6718057f6c5403 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 14, 2019 at 6:16 AM Murray S. Kucherawy wrote: > On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman > wrote: > >> >> > I see sender-id still has full citizenship. Now I'm not clear which >> will be >> > first, but my feeling is that rfc7601bis and >> > status-change-change-sender-id-to-historic are going to be published >> more or >> > less at the same time. >> > >> > When a method is moved to historic, are the corresponding parameters in >> the >> > IANA registry moved to deprecated? If yes, should the move be stated by >> > which document? >> >> A quick look at Domainkeys in the registry and RFC 7601 will answer that >> question for you. Let's not hold this up. >> > > +1. This was not identified in IESG Review as something that needs fixing > so I'd just as soon not make more changes now. If we keep changing it, > it's going to need another cycle through the working group. > I had flagged the lack of deprecating Sender ID in my notes to Murray. Since he did not comment back on that, I had assumed he was good with ripping it all out (or marking it as obsolete). --Kurt --0000000000005a6718057f6c5403 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 14, 2019 at 6:16 AM Murray S.= Kucherawy <superuser@gmail.com> wrote:

> I see sender-id still has full citizenship.=C2=A0 Now I'm not clea= r which will be
> first, but my feeling is that rfc7601bis and
> status-change-change-sender-id-to-historic are going to be published m= ore or
> less at the same time.
>
> When a method is moved to historic, are the corresponding parameters i= n the
> IANA registry moved to deprecated?=C2=A0 If yes, should the move be st= ated by
> which document?

A quick look at Domainkeys in the registry and RFC 7601 will answer that question for you.=C2=A0 Let's not hold this up.
+1.=C2=A0 This was not identified in IESG Review as something = that needs fixing so I'd just as soon not make more changes now.=C2=A0 = If we keep changing it, it's going to need another cycle through the wo= rking group.

I had flagge= d the lack of deprecating Sender ID in my notes to Murray. Since he did not= comment back on that, I had assumed he was good with ripping it all out (o= r marking it as obsolete).

--Kurt=C2=A0
--0000000000005a6718057f6c5403-- From nobody Mon Jan 14 09:39:09 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F701311DC for ; Mon, 14 Jan 2019 09:39:08 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=tkcSkdHj; dkim=pass (2048-bit key) header.d=kitterman.com header.b=eDVTIoT0 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 B6gxYM_IYg5E for ; Mon, 14 Jan 2019 09:39:06 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9953B1311DB for ; Mon, 14 Jan 2019 09:39:06 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1547487541; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=p/MWIXJALdiCpJtV4jbNOVfN8D0UWPM2Lce9KJPlGzA=; b=tkcSkdHjlNdRLIcNDvHpMWW8wyjbeOXShBZx1At5tzHR/T6eEj91b6Ot 85ZwKick1EeRQ4nXHZICHqyZ4P7bDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1547487541; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=p/MWIXJALdiCpJtV4jbNOVfN8D0UWPM2Lce9KJPlGzA=; b=eDVTIoT0thik9EsG99WnUJSHmy4RL8QfBmZwvw8cK27PNXhzgcKujoB/ SOZ2LGnZFXtGl4FQQCL1MOdi0AE/93s2tO+Jnznve4p2SOmt1hYyS3Ubok Tq31Y5/88o7AVK+osQSMkVa8fm3kIKj23UWR7SCetOSX/oHRxsFNslCiRI v/smif3JoklN6wqpNXzjfBeK0aqmPw3++gxi0a/ApJ/7KU/r1qvk+BpjS4 zmM1vcwJxqI+oGKo5a8rmQZjHe+N3BbT+Pv2WaFMBzQqZm+V8Yne2W+4rb iXEc9TMQHeiVVya8mGf4mX+mbfR9h/CfzHL64vp364Kccc4ZhCR1Ug== Received: from [192.168.1.148] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id C05932D4081D; Mon, 14 Jan 2019 11:39:01 -0600 (CST) Date: Mon, 14 Jan 2019 17:38:59 +0000 In-Reply-To: References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <2272f6d5-6c80-b80d-4aff-bdcc69449cf8@tana.it> <1927558.aO5YKDjPkr@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <9223F7C0-4412-4123-9DBA-7E0BDC822C32@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 17:39:09 -0000 On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)" wrote: >On Mon, Jan 14, 2019 at 6:16 AM Murray S=2E Kucherawy > >wrote: > >> On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman > >> wrote: >> >>> >>> > I see sender-id still has full citizenship=2E Now I'm not clear >which >>> will be >>> > first, but my feeling is that rfc7601bis and >>> > status-change-change-sender-id-to-historic are going to be >published >>> more or >>> > less at the same time=2E >>> > >>> > When a method is moved to historic, are the corresponding >parameters in >>> the >>> > IANA registry moved to deprecated? If yes, should the move be >stated by >>> > which document? >>> >>> A quick look at Domainkeys in the registry and RFC 7601 will answer >that >>> question for you=2E Let's not hold this up=2E >>> >> >> +1=2E This was not identified in IESG Review as something that needs >fixing >> so I'd just as soon not make more changes now=2E If we keep changing >it, >> it's going to need another cycle through the working group=2E >> > >I had flagged the lack of deprecating Sender ID in my notes to Murray=2E >Since he did not comment back on that, I had assumed he was good with >ripping it all out (or marking it as obsolete)=2E The registry update policy is expert review=2E We won't need another RFC = to deprecate Sender ID when the time comes=2E Scott K From nobody Mon Jan 14 10:06:19 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD31A1311ED for ; Mon, 14 Jan 2019 10:06:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 NvorLSsbxWcg for ; Mon, 14 Jan 2019 10:06:14 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 C4E6812426E for ; Mon, 14 Jan 2019 10:06:14 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id a6so682465itl.4 for ; Mon, 14 Jan 2019 10:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R3mUxrQ2iCsMwU4QLUKj91v64Daj8zup6lISLkMgack=; b=ZHaFoi9X1i2v9KGi5hrpglme6/XsqCaRsOlqknv/f1NdpqVkqJXNDKQqglHG5DXi0J GyGaR5vA61+gtpOiNZwFKdGxaFCqtYVpET9DZkPFoQnCQRycwWk/3eG6sAkR8keCbSqY ErTweBtkkyiC9xOlqx5Sv192wUDkggS/iAavw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R3mUxrQ2iCsMwU4QLUKj91v64Daj8zup6lISLkMgack=; b=AcuwMmD4qrCgUGPytnlPS53xFBY2Q6HaAEcgrpyGx6kW6RZfveExsOJ+BmJVjeDw8w HHXzTyYlDGscEIn2E8PWA3/VvWgCDGbBn20pVA8h9mftxUoPuIaxCTzTy7tHzpIZhiq5 ECubhfJIoNuMrCVXCO2rO468UsIFrQmOQbsmjPxyw3LfAS3g0/LDQdNYAOnnFfrVCorQ Sw+uxI/quZKVRC9F1VlWJMt64UQN/UTlMB5Y+O41oDBI7szNIllV++tAbEmOP8TgZDmT C2UKa9lY8zxVmWm7xJehh34XnL2KI372dxQ9C+XtOsF4WpsJECKYHUmO0PyR/YVmz5Xr TeHA== X-Gm-Message-State: AJcUukf7p/ALV3jVhA9/2geSFsESd8RRnfi8Xv7VLw9TcCJ2PxQL2DxC PoknV6OgcrbA9Ryte6ZBju8/eZJLp2ZZnJOm+fhpB+B6+6I= X-Google-Smtp-Source: ALg8bN7mEf4q4n0wkcdtF3q/Y87ZLv+ptdi6pg93OFN5LWK0cBjie4Cr+kQ1uCqQApxsr1jYQhnUKEueDlGc2Vx3srY= X-Received: by 2002:a24:3047:: with SMTP id q68mr271605itq.78.1547489173915; Mon, 14 Jan 2019 10:06:13 -0800 (PST) MIME-Version: 1.0 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <2272f6d5-6c80-b80d-4aff-bdcc69449cf8@tana.it> <1927558.aO5YKDjPkr@kitterma-e6430> <9223F7C0-4412-4123-9DBA-7E0BDC822C32@kitterman.com> In-Reply-To: <9223F7C0-4412-4123-9DBA-7E0BDC822C32@kitterman.com> From: "Kurt Andersen (b)" Date: Mon, 14 Jan 2019 10:06:02 -0800 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000816d3c057f6ee670" Archived-At: Subject: Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 18:06:17 -0000 --000000000000816d3c057f6ee670 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 14, 2019 at 9:39 AM Scott Kitterman wrote: > > > On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)" > wrote: > >On Mon, Jan 14, 2019 at 6:16 AM Murray S. Kucherawy > > > >wrote: > > > >> On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman > > > >> wrote: > >> > >>> > >>> > I see sender-id still has full citizenship. Now I'm not clear > >which > >>> will be > >>> > first, but my feeling is that rfc7601bis and > >>> > status-change-change-sender-id-to-historic are going to be > >published > >>> more or > >>> > less at the same time. > >>> > > >>> > When a method is moved to historic, are the corresponding > >parameters in > >>> the > >>> > IANA registry moved to deprecated? If yes, should the move be > >stated by > >>> > which document? > >>> > >>> A quick look at Domainkeys in the registry and RFC 7601 will answer > >that > >>> question for you. Let's not hold this up. > >>> > >> > >> +1. This was not identified in IESG Review as something that needs > >fixing > >> so I'd just as soon not make more changes now. If we keep changing > >it, > >> it's going to need another cycle through the working group. > >> > > > >I had flagged the lack of deprecating Sender ID in my notes to Murray. > >Since he did not comment back on that, I had assumed he was good with > >ripping it all out (or marking it as obsolete). > > The registry update policy is expert review. We won't need another RFC to > deprecate Sender ID when the time comes. > Understood, but I was thinking that cutting Sender ID mostly out of 7601bis would be appropriate. --Kurt --000000000000816d3c057f6ee670 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 14, 2019 at 9:39 AM Scott Kit= terman <sklist@kitterman.com= > wrote:


On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)" <kboth@drkurt.com> w= rote:
>On Mon, Jan 14, 2019 at 6:16 AM Murray S. Kucherawy
><superuser@= gmail.com>
>wrote:
>
>> On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman
><sklist@ki= tterman.com>
>> wrote:
>>
>>>
>>> > I see sender-id still has full citizenship.=C2=A0 Now I&#= 39;m not clear
>which
>>> will be
>>> > first, but my feeling is that rfc7601bis and
>>> > status-change-change-sender-id-to-historic are going to b= e
>published
>>> more or
>>> > less at the same time.
>>> >
>>> > When a method is moved to historic, are the corresponding=
>parameters in
>>> the
>>> > IANA registry moved to deprecated?=C2=A0 If yes, should t= he move be
>stated by
>>> > which document?
>>>
>>> A quick look at Domainkeys in the registry and RFC 7601 will a= nswer
>that
>>> question for you.=C2=A0 Let's not hold this up.
>>>
>>
>> +1.=C2=A0 This was not identified in IESG Review as something that= needs
>fixing
>> so I'd just as soon not make more changes now.=C2=A0 If we kee= p changing
>it,
>> it's going to need another cycle through the working group. >>
>
>I had flagged the lack of deprecating Sender ID in my notes to Murray.<= br> >Since he did not comment back on that, I had assumed he was good with >ripping it all out (or marking it as obsolete).

The registry update policy is expert review.=C2=A0 We won't need anothe= r RFC to deprecate Sender ID when the time comes.

=
Understood, but I was thinking that cutting Sender ID mostly out= of 7601bis would be appropriate.

--Kurt=C2=A0
--000000000000816d3c057f6ee670-- From nobody Mon Jan 14 10:33:05 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A11131203 for ; Mon, 14 Jan 2019 10:33:03 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=cWryh/cF; dkim=pass (2048-bit key) header.d=kitterman.com header.b=oh6CxlOA 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 2qVA5ZxtkZu5 for ; Mon, 14 Jan 2019 10:33:02 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF16131201 for ; Mon, 14 Jan 2019 10:33:01 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1547490777; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=nyABqZJsTqvDdUP/Ky6DrLiyzaOQe8exgI66Ps0qq4U=; b=cWryh/cF0/R/ZxWJLlq0Sdjic/nZzwcphxdUdR50Km51oxp81mxLy8pY xjvg6G1wD8BgQvIO03Ux3cwrZq41DQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1547490777; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=nyABqZJsTqvDdUP/Ky6DrLiyzaOQe8exgI66Ps0qq4U=; b=oh6CxlOAtMi7+rHzkAp7q+QJbCoAbfDn5vrxzZCOiwi6uru7yudvurmx peiTXORZu6gG5oDazgFQXlL4lEDc8v1m7WlG3jug5P+469J4MTmS5y4MTG Nm/7eKaKdSx6kjxX23/BsipU37uORTNU2IKZB0Q7T1mBCadNA+rIel33Jw YH2ggFaqi38cbAJRFqsK4WuCHcCjbGgwHka1MAB8mcPePn0yS0+HM/9p1A BBAeg6ox/7Q6k9UwDBfco/fKJZVeu7KmBN/QMyAu5cOmLRy9fEA/d1GY+F PEjQoB+wmk86RsGGgmEN47Xii+zWlVSSsImg61MksU53EP7Nzaeuyg== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 064782D408C5 for ; Mon, 14 Jan 2019 12:32:57 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 14 Jan 2019 13:32:56 -0500 Message-ID: <3900818.4E7hUKDgJz@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <9223F7C0-4412-4123-9DBA-7E0BDC822C32@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 18:33:04 -0000 On Monday, January 14, 2019 10:06:02 AM Kurt Andersen wrote: > On Mon, Jan 14, 2019 at 9:39 AM Scott Kitterman > > wrote: > > On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)" > > > > wrote: > > >On Mon, Jan 14, 2019 at 6:16 AM Murray S. Kucherawy > > > > > > > > >wrote: > > >> On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman > > > > > > > > > > > >> wrote: > > >>> > I see sender-id still has full citizenship. Now I'm not clear > > > > > >which > > > > > >>> will be > > >>> > > >>> > first, but my feeling is that rfc7601bis and > > >>> > status-change-change-sender-id-to-historic are going to be > > > > > >published > > > > > >>> more or > > >>> > > >>> > less at the same time. > > >>> > > > >>> > When a method is moved to historic, are the corresponding > > > > > >parameters in > > > > > >>> the > > >>> > > >>> > IANA registry moved to deprecated? If yes, should the move be > > > > > >stated by > > > > > >>> > which document? > > >>> > > >>> A quick look at Domainkeys in the registry and RFC 7601 will answer > > > > > >that > > > > > >>> question for you. Let's not hold this up. > > >> > > >> +1. This was not identified in IESG Review as something that needs > > > > > >fixing > > > > > >> so I'd just as soon not make more changes now. If we keep changing > > > > > >it, > > > > > >> it's going to need another cycle through the working group. > > > > > >I had flagged the lack of deprecating Sender ID in my notes to Murray. > > >Since he did not comment back on that, I had assumed he was good with > > >ripping it all out (or marking it as obsolete). > > > > The registry update policy is expert review. We won't need another RFC to > > deprecate Sender ID when the time comes. > > Understood, but I was thinking that cutting Sender ID mostly out of 7601bis > would be appropriate. So far we have not removed any registry entries, only marked them deprecated (domainkeys for example). I don't think there's any particular rush to start now. Scott K From nobody Mon Jan 14 10:40:21 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D35413124F for ; Mon, 14 Jan 2019 10:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=a0Asf3Nz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pqr/7iZ6 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 bxyhAk-zJ8Zg for ; Mon, 14 Jan 2019 10:40:11 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34AFC131213 for ; Mon, 14 Jan 2019 10:40:11 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 48AF6288EE; Mon, 14 Jan 2019 13:40:10 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Mon, 14 Jan 2019 13:40:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:references:subject:date:in-reply-to; s=fm2; bh=1ns i8KWdeLs5qQJB8kmfR0L3nY4oZUb7ERkB4W3YctA=; b=a0Asf3NzMfu/mkwGeGY bu0G90bRRVmartavcZcDmDWZkFg8uiE8xU0+uR6t0tS18xrGS/kF9ou1WvBKy25S w4n3KruuC1Ci77ay95TYaUQ8HuMNGePHhCRW8v2sAYLPzz1Am4Vu6s3CJGHXdXtr vWPCrQRQm+OlsgsRVhsv6V0/qB6vF1NZY/UE8jlWphhgVE2uDA5TVmL8YW6aV4cm 53ZrUX+FLkZtHiV++yQQJAB+jLyy8A5JWGrnVTtYkmHQqbCuQIePExtpZOpGWjHE ij3iNOsRPdJPODgWLPn4OGYjbXb2uyRPfGkTPZ8zvc+61wv4MinWeYnnPTJbgJPv 3zQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=1nsi8KWdeLs5qQJB8kmfR0L3nY4oZUb7ERkB4W3Yc tA=; b=pqr/7iZ6tttsAHqLSvqvIGa9GH/xJRxzmQnulbUyD4UeOOgII/HfNAwoG N259QSLrj14fn/DA3R4/Phu0WvBBDUP8n9aYYmhP/ooBFXnX6Jjfdvwbv3VlxUmT NmOJW9eN5dhRqYGSvDAFDZ3f+qNiZ7qYtK8YS8XYU2HxpijWDHHGXu265e3Hn0qP CGQ/ojAREBcpjqb24bPcoA2+YRewoRyy2qrHMKE2lMJquKq5X+nsA9+IhX8X7npE fSuN7+h/aVEeR+SEfWmkMf27BE4LSyAStBe/DS8bodYCERfGNeHhSdsmDT3o5Zvv TT7MB2uHwTc/WqiZQVu0wJT+SJGUg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgedugdduudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepkffhvfgggfgtofhfufffjgesthejredtredtjeenucfhrhhomh eptehlvgigvgihucfovghlnhhikhhovhcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgr ihhlrdhfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfh grshhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A049462325; Mon, 14 Jan 2019 13:40:09 -0500 (EST) Message-Id: <1547491209.3002084.1634374944.4B4105A9@webmail.messagingengine.com> From: Alexey Melnikov To: Scott Kitterman , dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-36e4bfd3 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <9223F7C0-4412-4123-9DBA-7E0BDC822C32@kitterman.com> <3900818.4E7hUKDgJz@kitterma-e6430> Date: Mon, 14 Jan 2019 18:40:09 +0000 In-Reply-To: <3900818.4E7hUKDgJz@kitterma-e6430> Archived-At: Subject: Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 18:40:20 -0000 On Mon, Jan 14, 2019, at 6:32 PM, Scott Kitterman wrote: > On Monday, January 14, 2019 10:06:02 AM Kurt Andersen wrote: > > On Mon, Jan 14, 2019 at 9:39 AM Scott Kitterman > > > > wrote: > > > On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)" > > > > > > wrote: > > > >On Mon, Jan 14, 2019 at 6:16 AM Murray S. Kucherawy > > > > > > > > > > > >wrote: > > > >> On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman > > > > > > > > > > > > > > > >> wrote: > > > >>> > I see sender-id still has full citizenship. Now I'm not clear > > > > > > > >which > > > > > > > >>> will be > > > >>> > > > >>> > first, but my feeling is that rfc7601bis and > > > >>> > status-change-change-sender-id-to-historic are going to be > > > > > > > >published > > > > > > > >>> more or > > > >>> > > > >>> > less at the same time. > > > >>> > > > > >>> > When a method is moved to historic, are the corresponding > > > > > > > >parameters in > > > > > > > >>> the > > > >>> > > > >>> > IANA registry moved to deprecated? If yes, should the move be > > > > > > > >stated by > > > > > > > >>> > which document? > > > >>> > > > >>> A quick look at Domainkeys in the registry and RFC 7601 will answer > > > > > > > >that > > > > > > > >>> question for you. Let's not hold this up. > > > >> > > > >> +1. This was not identified in IESG Review as something that needs > > > > > > > >fixing > > > > > > > >> so I'd just as soon not make more changes now. If we keep changing > > > > > > > >it, > > > > > > > >> it's going to need another cycle through the working group. > > > > > > > >I had flagged the lack of deprecating Sender ID in my notes to Murray. > > > >Since he did not comment back on that, I had assumed he was good with > > > >ripping it all out (or marking it as obsolete). > > > > > > The registry update policy is expert review. We won't need another RFC to > > > deprecate Sender ID when the time comes. > > > > Understood, but I was thinking that cutting Sender ID mostly out of 7601bis > > would be appropriate. I think removing them from 7601bis != removing them from the IANA registry. > So far we have not removed any registry entries, only marked them deprecated > (domainkeys for example). I don't think there's any particular rush to start > now. Entries should never be removed from an IANA registry, as this would defeat one purpose of having a registry. They can only be marked historic/deprecated/obsolete, as appropriate for the registry. Best Regards, Alexey From nobody Mon Jan 14 10:43:08 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA14613120B for ; Mon, 14 Jan 2019 10:43:05 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=SqmToPNG; dkim=pass (2048-bit key) header.d=kitterman.com header.b=UYox2nyp 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 rGbPJU5lTK6v for ; Mon, 14 Jan 2019 10:43:03 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF91131209 for ; Mon, 14 Jan 2019 10:43:03 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1547491382; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=KagiZTm+owJy/56xPIiwu5d9RpG9x6DnFlDQ+0zJKnU=; b=SqmToPNGCo8ESc0clpooursQDRxugRbk5L33KxKqWJuhtuF05v9eKye2 yGvZY3xKmkrMZ4WRrzIvSSPvfRvAAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1547491382; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=KagiZTm+owJy/56xPIiwu5d9RpG9x6DnFlDQ+0zJKnU=; b=UYox2nyp+OyMPuGaGtRnRcIov6OiTXize9gYJkfHHduImqHL+YCQHVnY fVx3uGBTSI93gvCHD68L8Zm1uLRh5dVlppA8EyVXcttc8PSXiL9Pg3r5MC XWl8w9V8RsfaHJlBwl2CEysg2QRsmMB10Xhq4wxOrzKCm4hOU7vgMQAw4m K0cDUQJjaLQge3Xvi5WZN/uWKdUVvNjOkn98P7CdMaKSzAhFPG4RQ5teuh uOKgTp4Euy/sUN7ma1VFMj8aL5LdDCfYWs2CbntXJPBsmwegeU+H0iokfI ySccgDVkiXaekcxGT/Gi9+66lFLetQnrIvvsamrZIC9JU87bzQcU7w== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 541FF2D408C5 for ; Mon, 14 Jan 2019 12:43:02 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 14 Jan 2019 13:43:01 -0500 Message-ID: <1798090.dmMY03Hzt3@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1547491209.3002084.1634374944.4B4105A9@webmail.messagingengine.com> References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <3900818.4E7hUKDgJz@kitterma-e6430> <1547491209.3002084.1634374944.4B4105A9@webmail.messagingengine.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jan 2019 18:43:06 -0000 On Monday, January 14, 2019 06:40:09 PM Alexey Melnikov wrote: > On Mon, Jan 14, 2019, at 6:32 PM, Scott Kitterman wrote: > > On Monday, January 14, 2019 10:06:02 AM Kurt Andersen wrote: > > > On Mon, Jan 14, 2019 at 9:39 AM Scott Kitterman > > > > > > wrote: > > > > On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)" > > > > > > > > > > > > wrote: > > > > >On Mon, Jan 14, 2019 at 6:16 AM Murray S. Kucherawy > > > > > > > > > > > > > > >wrote: > > > > >> On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman > > > > > > > > > > > > > > > > > > > >> wrote: > > > > >>> > I see sender-id still has full citizenship. Now I'm not clear > > > > > > > > > >which > > > > > > > > > >>> will be > > > > >>> > > > > >>> > first, but my feeling is that rfc7601bis and > > > > >>> > status-change-change-sender-id-to-historic are going to be > > > > > > > > > >published > > > > > > > > > >>> more or > > > > >>> > > > > >>> > less at the same time. > > > > >>> > > > > > >>> > When a method is moved to historic, are the corresponding > > > > > > > > > >parameters in > > > > > > > > > >>> the > > > > >>> > > > > >>> > IANA registry moved to deprecated? If yes, should the move be > > > > > > > > > >stated by > > > > > > > > > >>> > which document? > > > > >>> > > > > >>> A quick look at Domainkeys in the registry and RFC 7601 will > > > > >>> answer > > > > > > > > > >that > > > > > > > > > >>> question for you. Let's not hold this up. > > > > >> > > > > >> +1. This was not identified in IESG Review as something that needs > > > > > > > > > >fixing > > > > > > > > > >> so I'd just as soon not make more changes now. If we keep changing > > > > > > > > > >it, > > > > > > > > > >> it's going to need another cycle through the working group. > > > > > > > > > >I had flagged the lack of deprecating Sender ID in my notes to > > > > >Murray. > > > > >Since he did not comment back on that, I had assumed he was good with > > > > >ripping it all out (or marking it as obsolete). > > > > > > > > The registry update policy is expert review. We won't need another > > > > RFC to > > > > deprecate Sender ID when the time comes. > > > > > > Understood, but I was thinking that cutting Sender ID mostly out of > > > 7601bis > > > would be appropriate. > > I think removing them from 7601bis != removing them from the IANA registry. > > > So far we have not removed any registry entries, only marked them > > deprecated (domainkeys for example). I don't think there's any > > particular rush to start now. > > Entries should never be removed from an IANA registry, as this would defeat > one purpose of having a registry. They can only be marked > historic/deprecated/obsolete, as appropriate for the registry. Right, but taking it out of 7601bis would leave the problem then of what's the appropriate reference in the registry, which, more generally, is how we got to the full text replacement of 7601. Leaving it out of 7601bis would just replicate the problem that the latest update was created to fix. Scott K From nobody Mon Jan 14 16:20:24 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4398E128CE4 for ; Mon, 14 Jan 2019 16:20:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 33jJvvqEpcoD for ; Mon, 14 Jan 2019 16:20:18 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 1D2F212785F for ; Mon, 14 Jan 2019 16:20:18 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id b5so2124345iti.2 for ; Mon, 14 Jan 2019 16:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z2hMuM1rx57SsUa2GVc/p3UAgHOYt3OZ+eV2quWYqAk=; b=Byuo3+TDwCeaUY9mDpYtdhQu5t1k9aKtf614ipETeuqczQOz9GN1oOs/DPLTANxoKS J3SM8gk0McY6sHguG3x8Rk3wAqwTJuaCtZGy82YgPVnzBbiYEevQfGxMTW7J2kKh8Dqt IJGZJUAaIuxvHViK57B1pHSVtjvgI6W/4JVB4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z2hMuM1rx57SsUa2GVc/p3UAgHOYt3OZ+eV2quWYqAk=; b=XevNXJWSLsaUxMQRyE3KHa7gF5rgVBz6nXnvqaLwAyaB3GmYincjR37hH6RBDxl/1K 45W/t0f3+FutasM9RZXaSVYNsJ+7OGH1jqDFaUY/5twtw5z3POLy6YdqmQEtNhKTYPnI r3lVt5Zpa3HvpGWFkdu87Mjkr9tFAPwZN1PGWfjLD+dZVNvm9+cv4o1bUft8mctss8vw SewrPJ8nw9EbD41oIrRjsfTT5Xml+04n48tjAA4T2IS5dEzgdOzKy8R7O64ruzriOGY0 jPQOoR77VOZo38fzTMChdRtHNRayBBPMMw+VRkenIj85wYsiF3FCrSnUa5siVQJkccrK tsoA== X-Gm-Message-State: AJcUukdIDy8HaYM1VkuyPZyl5LhDTVC3aFTRxicHdHDK7pPTNllFhm8t HXeMZmBQK2rMjq+rTFhjKPIti0aoEM//fYnsmPuQs809xWA= X-Google-Smtp-Source: ALg8bN59PJdD3MTQgiGmKYhDfdKLLWQnv0kum4cqV93HyjtfHAqGKfaF95S+ETbtJDvllWCkATs8Zz+oC12sw1xNVU8= X-Received: by 2002:a24:3047:: with SMTP id q68mr1229115itq.78.1547511617152; Mon, 14 Jan 2019 16:20:17 -0800 (PST) MIME-Version: 1.0 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <3900818.4E7hUKDgJz@kitterma-e6430> <1547491209.3002084.1634374944.4B4105A9@webmail.messagingengine.com> <1798090.dmMY03Hzt3@kitterma-e6430> In-Reply-To: <1798090.dmMY03Hzt3@kitterma-e6430> From: "Kurt Andersen (b)" Date: Mon, 14 Jan 2019 16:20:05 -0800 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003a07ee057f742098" Archived-At: Subject: Re: [dmarc-ietf] New diff rfc7601 vs rfc7601bis, was Ben Campbell's Discuss... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jan 2019 00:20:21 -0000 --0000000000003a07ee057f742098 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 14, 2019 at 10:43 AM Scott Kitterman wrote: > > Right, but taking it out of 7601bis would leave the problem then of what's > the > appropriate reference in the registry, which, more generally, is how we > got to > the full text replacement of 7601. Leaving it out of 7601bis would just > replicate the problem that the latest update was created to fix. > That depends on how it is done. I was proposing moving all the Sender ID related content to an Appendix which documents it for posterity as historical and otherwise removing all references elsewhere in the document to Sender ID. That both obsoletes 7601 and deals with the deprecation. --Kurt --0000000000003a07ee057f742098 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000003a07ee057f742098-- From nobody Mon Jan 14 19:51:57 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DB7126BED; Mon, 14 Jan 2019 19:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 Bjjg8Pz--JHG; Mon, 14 Jan 2019 19:51:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3236F130DBE; Mon, 14 Jan 2019 19:51:53 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0F3pe1B002172 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Jan 2019 21:51:41 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547524304; bh=XI90bNvoqGQyOTYABgj/ykYljlDAgJymn0+kcEe82Do=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=YBnZb2mPN1mdwer9SNcKo/F9TNDInBBG1onAJrRyx2CP3v9NCLcL1rvCsvorLoEub ZzCHvBmCZCT0XSxC81NRgu6hSAJox9A9kPRtmRZp/L28hvxpdaVd/FrGslr8ciRW7J 1JP+kk3jjelnnQmjNORD13URQ4d4qp+391f1y4F0= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <0E1DBF74-4F2E-4BC4-BA40-D17E51A76EEA@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7C976A97-1F15-4CEC-BF98-F5612B42F6BD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 14 Jan 2019 21:51:39 -0600 In-Reply-To: Cc: Alexey Melnikov , Barry Leiba , Tim Draegen , IETF DMARC WG , IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org To: "Murray S. Kucherawy" References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> <1543613485.3765543.1594837224.1E64FAB8@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jan 2019 03:51:55 -0000 --Apple-Mail=_7C976A97-1F15-4CEC-BF98-F5612B42F6BD Content-Type: multipart/alternative; boundary="Apple-Mail=_90606490-22B3-487B-8DDD-0511CB896A29" --Apple-Mail=_90606490-22B3-487B-8DDD-0511CB896A29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Am I correct to assume the header and boilerplate changes are just = artifacts of this being a temporary =E2=80=9Cdraft-kucherawy...=E2=80=9D = draft rather than an actual revision to rfc7601bis? Otherwise, this would address my DISCUSS. Thanks! Ben. > On Jan 5, 2019, at 11:45 PM, Murray S. Kucherawy = wrote: >=20 > Here's what I've come up with. This is a diff between RFC7601 as = published and what I propose as RFC7601bis to resolve all of the = DISCUSSes and most of the COMMENTs from IESG review. Please let me know = if I've missed anything. I'll post it at the end of the coming week if = there are no issues raised. >=20 > = http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc7601= .diff.html = >=20 > -MSK >=20 > On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov = > wrote: > On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote: > > Murray, would you please copy the relevant IANA Considerations > > sections from RFC 7601 into 7601bis and change the tenses > > appropriately (perhaps just with a sentence in each subsection that > > says, "The following was done in the previous edition of this > > document, RFC 7601:", or some such >=20 > Even better if you say something like "the following is unchanged from = RFC 7601:". >=20 > >), and then let's have a quick > > working group review of the result? (And, of course, change it back > > to "obsoletes" rather than "updates".) > > > > As it's editorial, I'm sure we don't need to go back through any > > approval process, and we can get the DISCUSS cleared and move = forward. >=20 > I agree. I think this is purely editorial, albeit an important issue = for the final document. >=20 > > Thanks, > > Barry > > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov = > wrote: > > > > > > Hi all, > > > > > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: > > > > I actually agree with this: I think the better answer is to go = back to > > > > "obsoletes" and to have this document include the details of = what was > > > > put in the registries before. But the working group decided to = do it > > > > the other way, and there's been criticism in the past of ADs = (and, so, > > > > by extension, chairs) picking on this sort of stuff, so I = decided to > > > > let it go. I'll let the IESG sort this one out, but I'll go on = record > > > > as saying what I think the better way to handle it is. > > > > > > I think incorporating older registrations is the cleaner way of = dealing with Ben's & Benjamin's DISCUSSes, as then the document is self = contained and there is no need for readers to see obsoleted RFCs. So = this would be my preference. > > > > > > If the WG doesn't want to do this, then the document needs editing = to be correct as per Benjamin's DISCUSS. > > > > > > Best Regards, > > > Alexey > > > > > > > That said, I don't think it's a huge deal either way. > > > > > > > > Barry > > > > > > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell > wrote: > > > > > > > > > > Ben Campbell has entered the following ballot position for > > > > > draft-ietf-dmarc-rfc7601bis-04: Discuss > > > > > > > > > > When responding, please keep the subject line intact and reply = to all > > > > > email addresses included in the To and CC lines. (Feel free to = cut this > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found = here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ = > > > > > > > > > > > > > > > > > > > > = ---------------------------------------------------------------------- > > > > > DISCUSS: > > > > > = ---------------------------------------------------------------------- > > > > > > > > > > This is mainly a process discuss. I share Alvaro's concern = about this being > > > > > marked as "updating" RFC7601, when it seem like a full = replacement. I'm > > > > > promoting it to a DISCUSS because I think this needs to be = resolved before > > > > > publication. > > > > > > > > > > The current structure will make it very difficult for readers = to figure out > > > > > which parts of each doc they need to worry about. I think it = needs to either go > > > > > back to "obsoleting" 7601, or it needs to be recast to just = talk about the > > > > > changes. Note that if the former path is chosen, the IANA = considerations in > > > > > 7601 will need to be copied forward. > > > > > > > > > > > > > > > = ---------------------------------------------------------------------- > > > > > COMMENT: > > > > > = ---------------------------------------------------------------------- > > > > > > > > > > I mostly just reviewed the diff. Thank you for mostly avoiding = unnecessary > > > > > changes. That makes the diff tools much more useful than they = are for bis > > > > > drafts that make wholesale organization and stylistic changes. > > > > > > > > > > > > > > > > > > > > > > -- > > > > Barry > > > > -- > > > > Barry Leiba (barryleiba@computer.org = ) > > > > http://internetmessagingtechnology.org/ = > > > > --Apple-Mail=_90606490-22B3-487B-8DDD-0511CB896A29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Am = I correct to assume the header and boilerplate changes are just = artifacts of this being a temporary =E2=80=9Cdraft-kucherawy...=E2=80=9D = draft rather than an actual revision to rfc7601bis?

Otherwise, this would address my = DISCUSS.

Thanks!

Ben.

On Jan 5, 2019, at 11:45 PM, = Murray S. Kucherawy <superuser@gmail.com> wrote:

Here's what I've = come up with.  This is a diff between RFC7601 as published and what = I propose as RFC7601bis to resolve all of the DISCUSSes and most of the = COMMENTs from IESG review.  Please let me know if I've missed = anything.  I'll post it at the end of the coming week if there are = no issues raised.

http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-f= rom-rfc7601.diff.html

-MSK

On = Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
On Fri, Nov 30, 2018, at 8:54 PM, = Barry Leiba wrote:
> Murray, would you please copy the relevant IANA Considerations
> sections from RFC 7601 into 7601bis and change the tenses
> appropriately (perhaps just with a sentence in each subsection = that
> says, "The following was done in the previous edition of this
> document, RFC 7601:", or some such

Even better if you say something like "the following is unchanged from = RFC 7601:".

>), and then let's have a quick
> working group review of the result?  (And, of course, change = it back
> to "obsoletes" rather than "updates".)
>
> As it's editorial, I'm sure we don't need to go back through any
> approval process, and we can get the DISCUSS cleared and move = forward.

I agree. I think this is purely editorial, albeit an important issue for = the final document.

> Thanks,
> Barry
> On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
> >
> > Hi all,
> >
> > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote:
> > > I actually agree with this: I think the better answer is = to go back to
> > > "obsoletes" and to have this document include the details = of what was
> > > put in the registries before.  But the working group = decided to do it
> > > the other way, and there's been criticism in the past of = ADs (and, so,
> > > by extension, chairs) picking on this sort of stuff, so I = decided to
> > > let it go.  I'll let the IESG sort this one out, but = I'll go on record
> > > as saying what I think the better way to handle it is.
> >
> > I think incorporating older registrations is the cleaner way = of dealing with Ben's & Benjamin's DISCUSSes, as then the document = is self contained and there is no need for readers to see obsoleted = RFCs. So this would be my preference.
> >
> > If the WG doesn't want to do this, then the document needs = editing to be correct as per Benjamin's DISCUSS.
> >
> > Best Regards,
> > Alexey
> >
> > > That said, I don't think it's a huge deal either way.
> > >
> > > Barry
> > >
> > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell <ben@nostrum.com> wrote:
> > > >
> > > > Ben Campbell has entered the following ballot = position for
> > > > draft-ietf-dmarc-rfc7601bis-04: Discuss
= > > > >
> > > > When responding, please keep the subject line intact = and reply to all
> > > > email addresses included in the To and CC lines. = (Feel free to cut this
> > > > introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT = positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can = be found here:
> > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/
> > > >
> > > >
> > > >
> > > > = ----------------------------------------------------------------------
> > > > DISCUSS:
> > > > = ----------------------------------------------------------------------
> > > >
> > > > This is mainly a process discuss. I share Alvaro's = concern about this being
> > > > marked as "updating" RFC7601, when it seem like a = full replacement. I'm
> > > > promoting it to a DISCUSS because I think this needs = to be resolved before
> > > > publication.
> > > >
> > > > The current structure will make it very difficult = for readers to figure out
> > > > which parts of each doc they need to worry about. I = think it needs to either go
> > > > back to "obsoleting" 7601, or it needs to be recast = to just talk about the
> > > > changes. Note that if the former path is chosen, the = IANA considerations in
> > > > 7601 will need to be copied forward.
> > > >
> > > >
> > > > = ----------------------------------------------------------------------
> > > > COMMENT:
> > > > = ----------------------------------------------------------------------
> > > >
> > > > I mostly just reviewed the diff. Thank you for = mostly avoiding unnecessary
> > > > changes. That makes the diff tools much more useful = than they are for bis
> > > > drafts that make wholesale organization and = stylistic changes.
> > > >
> > > >
> > >
> > >
> > > --
> > > Barry
> > > --
> > > Barry Leiba  (barryleiba@computer.org)
> > > http://internetmessagingtechnology.org/
> > >

= --Apple-Mail=_90606490-22B3-487B-8DDD-0511CB896A29-- --Apple-Mail=_7C976A97-1F15-4CEC-BF98-F5612B42F6BD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw9WMsACgkQgFZKbJXz 1A17bQ//bZsyfJSFQHgojeNKp90txGuyEJwYWqKueU5YkWm0YrVAHoVxIvlP4X+L kO3CjJ21LZyopsTlvQ1uebS0D9W11t4bavFvMwsvHi7s88ATeNppYacJGANlX8Uc eGGy9R9OkcSL2Y9w/HKEiQl9SxZpX413HFs/f7AVb8J0bFExkp8it/6LNkGx6iRN SJyJmnxL5+LQMotcZMhsxjRgFUtUJW08Euq9Xn0A6YyIHiHT+bttV8r1kgX4Q3Xi WxiHsgFbeYENp0Z3GD88rNykBCGgfduVcxedasqhY0cYnO/Zl+CbriEcY2KL4wKY 8xKswPmrLjigsYLdHCqllPNu3EXBLTd9fN/1fgvfmqlEGcPRkjW+WL8zGZM7TQZ7 aKsMlsH8halUqL/MJhglIJMhQQAHAZK+gYCmtM9mUQ79jE+ubvJkGGNOaqGz9CP6 4+jI0hMcwmFnT8nhJKKFooVtKag9v5dm6DU5wHtfqYMpcRnLrgG1Z6w2cCMJbZeF Nc1/F25KFVyeC7CDaFcjp01NYClUzSgPg9TjvIAW/nj+haLhXMYz1MtUdvVZMrXg pLVGDRhkNMhTUX60SDapcAhQimdlAMOkvnYm+LZQgVEYYKU42s/n+AwxKZVYnSHM gUbx+1HYhRaf0+4Jydnr7OMi+bdGbM/BWNFFO8sPVQAaXNdiB3E= =HyRQ -----END PGP SIGNATURE----- --Apple-Mail=_7C976A97-1F15-4CEC-BF98-F5612B42F6BD-- From nobody Tue Jan 15 07:50:54 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDD2130E6B; Tue, 15 Jan 2019 07:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=u/caPnfk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i8z6cIAp 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 xNUoSPV6Ofk4; Tue, 15 Jan 2019 07:50:47 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43201130ECE; Tue, 15 Jan 2019 07:50:47 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 02B3F2627D; Tue, 15 Jan 2019 10:50:46 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute7.internal (MEProxy); Tue, 15 Jan 2019 10:50:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:references:in-reply-to:date; s=fm2; bh=/4s Ov4Q4LvHuDbu96D6Jj6zlHavkAUf0FWsBMKcxrP0=; b=u/caPnfkJoP5y9V1HPn XQ+5X/MzDqXRxVKBUPQvTtKtz2xiQsXdyk/n2XvfrSTk67jo2FuWSOgHceDG2ft5 mkeWI1Pg2LF0XcYs9OFr0+CrUUyVWJSV/Yf+VEhPp5KSl1QEft4BlDbTrl0oZePs D6l1vDtybUHbZqqEmImwJ8sqFAt8m1ixudI0ZdR7VEng99W+rHTvYYNLlXUP31oM Nka4HoPZhPUNNDkHHMx8TILZnwSIXc6wYSO+/5A2XBxKPGdVxr5RineamFRlc4yE iUy2jTt67eUKXs3PrVhih4SqYB6eintUjNUp13PnMgY6tvb1bMT/eyE4N8nyAyQi Gmw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=/4sOv4Q4LvHuDbu96D6Jj6zlHavkAUf0FWsBMKcxr P0=; b=i8z6cIAprF8le/W+Khno6jp898rWL/2GYAMA3bRyPuQ5RnIWHqY3Ol8lE xFEHSkc0po+KmXvMWe6q6I2k4mmgv8VAHfanHwg9meq3dK/qlKgc6uv+LUX6K23f hoLcQAj1hWoIQA9TydAXA+WM6IOh3sAOVO3HBHwD91O0hbu3zFqIzXcNLYREFwZ/ je03QMKqxWO9hbue85yxezkKETB+8vJrxwIvtboh0HB7CPeT2IlR8qIo0xvpxZVJ 3UG6ORwmYuF4Q82dVYJ2DmltTjbW6Svb6rqTgpzHZNKhhXsMsm/I7UmRZ53Zv63W 70ZSPCsRan3cmJVILUIKGK/ukd7Jg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeefgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof fufhgjffesrgejreerredtjeenucfhrhhomheptehlvgigvgihucfovghlnhhikhhovhcu oegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuffhomhgrihhnpegslh grtghkohhpshdrohhrghdpihgvthhfrdhorhhgpdhinhhtvghrnhgvthhmvghsshgrghhi nhhgthgvtghhnhholhhoghihrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrg hmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D15FA9E564; Tue, 15 Jan 2019 10:50:44 -0500 (EST) Message-Id: <1547567444.782708.1635254408.43FDC547@webmail.messagingengine.com> From: Alexey Melnikov To: Ben Campbell , "Murray S. Kucherawy" Cc: Barry Leiba , Tim Draegen , IETF DMARC WG , IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15475674447827080" X-Mailer: MessagingEngine.com Webmail Interface - ajax-36e4bfd3 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> <1543613485.3765543.1594837224.1E64FAB8@webmail.messagingengine.com> <0E1DBF74-4F2E-4BC4-BA40-D17E51A76EEA@nostrum.com> In-Reply-To: <0E1DBF74-4F2E-4BC4-BA40-D17E51A76EEA@nostrum.com> Date: Tue, 15 Jan 2019 15:50:44 +0000 Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jan 2019 15:50:51 -0000 This is a multi-part message in MIME format. --_----------=_15475674447827080 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tue, Jan 15, 2019, at 3:51 AM, Ben Campbell wrote: > Am I correct to assume the header and boilerplate changes are just > artifacts of this being a temporary =E2=80=9Cdraft-kucherawy...=E2=80=9D = draft rather > than an actual revision to rfc7601bis?I believe so. >=20 > Otherwise, this would address my DISCUSS. >=20 > Thanks! >=20 > Ben. >=20 >> On Jan 5, 2019, at 11:45 PM, Murray S. Kucherawy >> wrote:>>=20 >> Here's what I've come up with. This is a diff between RFC7601 as >> published and what I propose as RFC7601bis to resolve all of the >> DISCUSSes and most of the COMMENTs from IESG review. Please let me >> know if I've missed anything. I'll post it at the end of the coming >> week if there are no issues raised.>>=20 >> http://www.blackops.org/~msk/draft-kucherawy-dmarc-rfc7601bis-from-rfc76= 01.diff.html>>=20 >> -MSK >>=20 >> On Fri, Nov 30, 2018 at 1:31 PM Alexey Melnikov >> wrote:>>> On Fri, Nov 30, 2018, at 8:54 PM, Bar= ry Leiba wrote: >>> > Murray, would you please copy the relevant IANA Considerations >>> > sections from RFC 7601 into 7601bis and change the tenses >>> > appropriately (perhaps just with a sentence in each subsection >>> > that>>> > says, "The following was done in the previous edition of = this >>> > document, RFC 7601:", or some such >>>=20 >>> Even better if you say something like "the following is unchanged >>> from RFC 7601:".>>>=20 >>> >), and then let's have a quick >>> > working group review of the result? (And, of course, change it >>> > back>>> > to "obsoletes" rather than "updates".) >>> >=20 >>> > As it's editorial, I'm sure we don't need to go back through any>>> = > approval process, and we can get the DISCUSS cleared and move >>> > forward.>>>=20 >>> I agree. I think this is purely editorial, albeit an important >>> issue for the final document.>>>=20 >>> > Thanks, >>> > Barry >>> > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov >>> > wrote:>>> > > >>> > > Hi all, >>> > > >>> > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: >>> > > > I actually agree with this: I think the better answer is to >>> > > > go back to>>> > > > "obsoletes" and to have this document inclu= de the details of >>> > > > what was>>> > > > put in the registries before. But the workin= g group decided >>> > > > to do it>>> > > > the other way, and there's been criticism in = the past of ADs >>> > > > (and, so,>>> > > > by extension, chairs) picking on this sort o= f stuff, so I >>> > > > decided to>>> > > > let it go. I'll let the IESG sort this one= out, but I'll go >>> > > > on record>>> > > > as saying what I think the better way to han= dle it is. >>> > > >>> > > I think incorporating older registrations is the cleaner way of >>> > > dealing with Ben's & Benjamin's DISCUSSes, as then the document >>> > > is self contained and there is no need for readers to see >>> > > obsoleted RFCs. So this would be my preference.>>> > > >>> > > If the WG doesn't want to do this, then the document needs >>> > > editing to be correct as per Benjamin's DISCUSS.>>> > > >>> > > Best Regards, >>> > > Alexey >>> > > >>> > > > That said, I don't think it's a huge deal either way. >>> > > > >>> > > > Barry >>> > > > >>> > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell >>> > > > wrote:>>> > > > > >>> > > > > Ben Campbell has entered the following ballot position for>>> = > > > > draft-ietf-dmarc-rfc7601bis-04: Discuss >>> > > > > >>> > > > > When responding, please keep the subject line intact and >>> > > > > reply to all>>> > > > > email addresses included in the To an= d CC lines. (Feel free >>> > > > > to cut this>>> > > > > introductory paragraph, however.) >>> > > > > >>> > > > > >>> > > > > Please refer to >>> > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html>>> = > > > > for more information about IESG DISCUSS and COMMENT >>> > > > > positions.>>> > > > > >>> > > > > >>> > > > > The document, along with other ballot positions, can be >>> > > > > found here:>>> > > > > https://datatracker.ietf.org/doc/draft= -ietf-dmarc-rfc7601bis/>>> > > > > >>> > > > > >>> > > > > >>> > > > > ----------------------------------------------------------- >>> > > > > ----------->>> > > > > DISCUSS: >>> > > > > ----------------------------------------------------------- >>> > > > > ----------->>> > > > > >>> > > > > This is mainly a process discuss. I share Alvaro's concern >>> > > > > about this being>>> > > > > marked as "updating" RFC7601, whe= n it seem like a full >>> > > > > replacement. I'm>>> > > > > promoting it to a DISCUSS because= I think this needs to be >>> > > > > resolved before>>> > > > > publication. >>> > > > > >>> > > > > The current structure will make it very difficult for >>> > > > > readers to figure out>>> > > > > which parts of each doc they= need to worry about. I think >>> > > > > it needs to either go>>> > > > > back to "obsoleting" 7601, o= r it needs to be recast to just >>> > > > > talk about the>>> > > > > changes. Note that if the former pa= th is chosen, the IANA >>> > > > > considerations in>>> > > > > 7601 will need to be copied forw= ard. >>> > > > > >>> > > > > >>> > > > > ----------------------------------------------------------- >>> > > > > ----------->>> > > > > COMMENT: >>> > > > > ----------------------------------------------------------- >>> > > > > ----------->>> > > > > >>> > > > > I mostly just reviewed the diff. Thank you for mostly >>> > > > > avoiding unnecessary>>> > > > > changes. That makes the diff = tools much more useful than >>> > > > > they are for bis>>> > > > > drafts that make wholesale organi= zation and stylistic >>> > > > > changes.>>> > > > > >>> > > > > >>> > > > >>> > > > >>> > > > -- >>> > > > Barry >>> > > > -- >>> > > > Barry Leiba (barryleiba@computer.org) >>> > > > http://internetmessagingtechnology.org/ >>> > > > > Email had 1 attachment: > * signature.asc 1k (application/pgp-signature) --_----------=_15475674447827080 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Tue, Jan 15, 2019, at 3:51 AM, Ben Campbell wrote:
Am I correct to assume the header and boiler= plate changes are just artifacts of this being a temporary =E2=80=9Cdraft-k= ucherawy...=E2=80=9D draft rather than an actual revision to rfc7601bis?
I believe so.

Otherwise, this would address my DISCUSS.

Thanks!

Ben.

On Jan 5, 2019, at 11:45 PM, Murray S. Kuche= rawy <superuser@gmail.com>= wrote:

Here's what I've come up with.&= nbsp; This is a diff between RFC7601 as published and what I propose as RFC= 7601bis to resolve all of the DISCUSSes and most of the COMMENTs from IESG = review.  Please let me know if I've missed anything.  I'll post i= t at the end of the coming week if there are no issues raised.


-MSK

On Fri, Nov 30, 2018 a= t 1:31 PM Alexey Melnikov <aam= elnikov@fastmail.fm> wrote:
On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote:
> Murray, would you please copy the relevant IANA Considerations
> sections from RFC 7601 into 7601bis and change the tenses
> appropriately (perhaps just with a sentence in each subsection t= hat
> says, "The following was done in the previous edition of this
> document, RFC 7601:", or some such

Even better if you say something like "the following is unchanged fro= m RFC 7601:".

>), and then let's have a quick
> working group review of the result?  (And, of course, chang= e it back
> to "obsoletes" rather than "updates".)
>
> As it's editorial, I'm sure we don't need to go back through any=
> approval process, and we can get the DISCUSS cleared and move fo= rward.

I agree. I think this is purely editorial, albeit an important issue = for the final document.

> Thanks,
> Barry
> On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
> >
> > Hi all,
> >
> > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote:
> > > I actually agree with this: I think the better answer = is to go back to
> > > "obsoletes" and to have this document include the deta= ils of what was
> > > put in the registries before.  But the working gr= oup decided to do it
> > > the other way, and there's been criticism in the past = of ADs (and, so,
> > > by extension, chairs) picking on this sort of stuff, s= o I decided to
> > > let it go.  I'll let the IESG sort this one out, = but I'll go on record
> > > as saying what I think the better way to handle it is.=
> >
> > I think incorporating older registrations is the cleaner wa= y of dealing with Ben's & Benjamin's DISCUSSes, as then the document is= self contained and there is no need for readers to see obsoleted RFCs. So = this would be my preference.
> >
> > If the WG doesn't want to do this, then the document needs = editing to be correct as per Benjamin's DISCUSS.
> >
> > Best Regards,
> > Alexey
> >
> > > That said, I don't think it's a huge deal either way.<= br>
> > >
> > > Barry
> > >
> > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell <ben@nostrum.com> wrote:
> > > >
> > > > Ben Campbell has entered the following ballot pos= ition for
> > > > draft-ietf-dmarc-rfc7601bis-04: Discuss
> > > >
> > > > When responding, please keep the subject line int= act and reply to all
> > > > email addresses included in the To and CC lines. = (Feel free to cut this
> > > > introductory paragraph, however.)
> > > >
> > > >
> > > > for more information about IESG DISCUSS and COMME= NT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, = can be found here:
> > > >
> > > >
> > > >
> > > > -------------------------------------------------= ---------------------
> > > > DISCUSS:
> > > > -------------------------------------------------= ---------------------
> > > >
> > > > This is mainly a process discuss. I share Alvaro'= s concern about this being
> > > > marked as "updating" RFC7601, when it seem like a= full replacement. I'm
> > > > promoting it to a DISCUSS because I think this ne= eds to be resolved before
> > > > publication.
> > > >
> > > > The current structure will make it very difficult= for readers to figure out
> > > > which parts of each doc they need to worry about.= I think it needs to either go
> > > > back to "obsoleting" 7601, or it needs to be reca= st to just talk about the
> > > > changes. Note that if the former path is chosen, = the IANA considerations in
> > > > 7601 will need to be copied forward.
> > > >
> > > >
> > > > -------------------------------------------------= ---------------------
> > > > COMMENT:
> > > > -------------------------------------------------= ---------------------
> > > >
> > > > I mostly just reviewed the diff. Thank you for mo= stly avoiding unnecessary
> > > > changes. That makes the diff tools much more usef= ul than they are for bis
> > > > drafts that make wholesale organization and styli= stic changes.
> > > >
> > > >
> > >
> > >
> > > --
> > > Barry
> > > --
> > > Barry Leiba  (barryleiba@computer.org)
> > >

Email had 1 attachment:

  • signature.asc
      1k (application/pgp-signature)

--_----------=_15475674447827080-- From nobody Tue Jan 15 16:49:24 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DE3130F85 for ; Tue, 15 Jan 2019 16:49:22 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=1davU6sH; dkim=pass (1536-bit key) header.d=taugh.com header.b=cLWqMIuF 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 rwY7Dyxcgwpy for ; Tue, 15 Jan 2019 16:49:20 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 F0960130F80 for ; Tue, 15 Jan 2019 16:49:19 -0800 (PST) Received: (qmail 787 invoked from network); 16 Jan 2019 00:49:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=30f.5c3e7f8e.k1901; bh=TuxP29Zr71gJNc3i7EjSvtU3ip1lxTEF3n2l8atMiuE=; b=1davU6sH/NncWikFLx3O/pqJ00WhuJ08eyGYL+euUOzmJH7WB96skNjAUYFeXuCiBGKDJk03ricn9r53m6lsreXj+fvV0LE3xBZHk8fvTRpByc9AouAMkv1SJaF/rmlbg5spzEjUChlMwEa09TKfsiNXcd76Tw1equeyQtUcdkGALiAJhVEk9wmaptoYtjmJEA+2c/6R7pe9ZdPXNT8y1Mu9CFlqm1nWoRtXiRyiPrrqHGlaEk9uQWNab2W56Ez9 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=30f.5c3e7f8e.k1901; bh=TuxP29Zr71gJNc3i7EjSvtU3ip1lxTEF3n2l8atMiuE=; b=cLWqMIuFDCVirMpRwolmmBy/B4baXpr8d/xiAv34YObfWM16yAB3cJYZ5MIpcp4JqNmyHVyec7cqAw4FfdLeNXIpX78HIf6o3dhMuO4Hl5lB3Fs/Cq/FlbGxP+DqaSylvz+plEBY0Ts2ylSKOOXvet1zF8xv1DQBuhInqF4nimHjQ1tYV3y+H7sWLaxh7MyQ28ksrQm6WscEr6F4FlJbxuHKe7Ev2JYO3oBlMUP+un3Qiy46zVcxtL6kZ8nKrE3z Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Jan 2019 00:49:18 -0000 Received: by ary.qy (Postfix, from userid 501) id 22F1A200CACCFC; Tue, 15 Jan 2019 19:49:17 -0500 (EST) Date: 15 Jan 2019 19:49:17 -0500 Message-Id: <20190116004918.22F1A200CACCFC@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <5126347.eOcQ2jtf8Q@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 00:49:23 -0000 In article <5126347.eOcQ2jtf8Q@kitterma-e6430> you write: >This update removes the IANA registry (which is what I think I was supposed to >do based on the feedback to date). I also bulked up the Privacy/Security >considerations descriptions since they are no longer mitigated. > >I'd like feedback on the best path forward. Essentially this draft replaces >the IANA registry with an undefined way to know where PSD DMARC is >appropriate. I think we need something better than that, but I didn't know >what. The more I look at this, the less I understand what problem it solves. If you manage a zone that can publish a PSD policy, you have some kind of relationship with the zone members so you should be auditing their policies anyway. To take a non-random example, I looked at the 2700 names in .BANK. There are 122 with no DMARC at all, which PSD might help, but there are also 164 with p=none, 29 with p=quarantine, 7 with pct=N where N is not 100, 4 with multiple policies, and about 30 where the DMARC record is invalid. Assuming your goal is to get everyone to p=none, PSD doesn't impress me as offering significant help. R's, John From nobody Tue Jan 15 16:58:10 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97937130F8A for ; Tue, 15 Jan 2019 16:58:07 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=iS0YPBZE; dkim=pass (1536-bit key) header.d=taugh.com header.b=kMbtBATL 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 mlJ1rtVOVmmj for ; Tue, 15 Jan 2019 16:58:06 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E4CDC130F86 for ; Tue, 15 Jan 2019 16:58:05 -0800 (PST) Received: (qmail 2974 invoked from network); 16 Jan 2019 00:58:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=b9b.5c3e819d.k1901; bh=76KhIBtwNCZRzxOG/tGPo40sV1EnWrGn4hxN7V0/YgQ=; b=iS0YPBZEijRtqFMrh+dHZ8ATQNgBGm9yiKPBQ49ddNyEoWJoMDKXGgXZjP7U8vldKecJ4UDVlGUQkOBxafqfPqk6zvuWr0XvCgjUh7IuidU2hWPmLcaSsUd9uQ30M40UEyC1AUyGupgzXuRCIfIy6/hWfNesMWRXlFVKR6hpWezeLttzVtPn6C5NYJSinQY55TjFxuA8WXlHk75Q1iYRbJ2d025M3ygfA8av68U/kEUTHMREJGx8nzSWXDZK/ucs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=b9b.5c3e819d.k1901; bh=76KhIBtwNCZRzxOG/tGPo40sV1EnWrGn4hxN7V0/YgQ=; b=kMbtBATLq7RfEu66MBUbHlWbEYm47/G670O1AEqmkMu4SnwtPw9eNApJlfs2n4U7pMItPGTt3ir6pEv43ScVGGhpKqZ5uecPLkC3mB+mnguW3H49oU1DMjfouYG7B7uE3AV1XfRE2nn74yKodU1cJWZU46K06MMQ2in2HrJiC1+anInUcn2/ICeaExyMzuMg+j1Xc76KbagjvCdgfidVqoO/XEPx8YOkGhuREmd/2v3XzJ+FHGJtp7E2vdoEds+d Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Jan 2019 00:58:04 -0000 Received: by ary.qy (Postfix, from userid 501) id A0A80200CACDA9; Tue, 15 Jan 2019 19:58:04 -0500 (EST) Date: 15 Jan 2019 19:58:04 -0500 Message-Id: <20190116005804.A0A80200CACDA9@ary.qy> From: "John Levine" To: dmarc@ietf.org Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 00:58:08 -0000 I am staring at RFC 7489, and at a bunch of purported DMARC records (see previous message.) The RFC says that all records must start with "v=DMARC1". Is it OK if they start with "v=dmarc1"? It says that record is a DKIM tag-value list, and the DKIM ABBF defines all the characters with hex escapes rather than letters which tells me that it's specifically saying that case matters. How about if there's a space before the v=DMARC1? The tag-value syntax allows FWS before the first tag, but 7489 says in several places Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. R's, John PS: I know it's not hard to write a parser that can accept mutant forms. The question is whether that's a good idea. From a quick look, people who get v=DMARC1 wrong often get other things wrong, too. From nobody Tue Jan 15 21:43:44 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03131310E2 for ; Tue, 15 Jan 2019 21:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=KRBzCL3g; dkim=pass (2048-bit key) header.d=kitterman.com header.b=IZMPLqaR 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 4qdqbiRWrVId for ; Tue, 15 Jan 2019 21:43:40 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F951310DB for ; Tue, 15 Jan 2019 21:43:40 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1547617413; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=fMnraTAS5sRgti3uXBSlxk50xEKxAPlPgRYJx4Jq7GE=; b=KRBzCL3gXpEcC2aooMpE1P8VJrc/adadLjtc2K+626tpX9JSQSfRVSWX ParIVBsy5Yw2RXLX2/Te3wyU166OCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1547617413; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=fMnraTAS5sRgti3uXBSlxk50xEKxAPlPgRYJx4Jq7GE=; b=IZMPLqaRM4nRE1LBGL5sAQF5epOT8UBsWVr7RiWHrcZggeWLwm/BOTA5 kic7uOONYXBNB7A5ZeUTDRGMVUrObuvusu2CDK/TOEwU4YcjxsE4rUiL8G fTyw/kaHzVnYtyUNDpjNmWB0wmLh4UQb9YcgW2yRyC1jlCns5tEQ8WXRYh xu/XneB+KF+RVANY5/dOWq3PVZ22mXuVAScL9bHvS1H1TqpPG4Uc6RzjJV OTg4Dv4CUXSaCpbBypnCxW4q3a1tEoUpK4Ns//U8J4A7iGeeajPI2M9LzR bibEA67McAtAU5jY1Xq6N5GF4SAVq8o9cPSxbpJ8XrFCQVFTNbgSlg== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 902062D4078E for ; Tue, 15 Jan 2019 23:43:33 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 16 Jan 2019 00:43:32 -0500 Message-ID: <3104294.rU99Ex2XNH@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20190116004918.22F1A200CACCFC@ary.qy> References: <20190116004918.22F1A200CACCFC@ary.qy> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 05:43:43 -0000 On Tuesday, January 15, 2019 07:49:17 PM John Levine wrote: > In article <5126347.eOcQ2jtf8Q@kitterma-e6430> you write: > >This update removes the IANA registry (which is what I think I was supposed > >to do based on the feedback to date). I also bulked up the > >Privacy/Security considerations descriptions since they are no longer > >mitigated. > > > >I'd like feedback on the best path forward. Essentially this draft > >replaces the IANA registry with an undefined way to know where PSD DMARC > >is appropriate. I think we need something better than that, but I didn't > >know what. > > The more I look at this, the less I understand what problem it solves. > If you manage a zone that can publish a PSD policy, you have some kind > of relationship with the zone members so you should be auditing their > policies anyway. > > To take a non-random example, I looked at the 2700 names in .BANK. > There are 122 with no DMARC at all, which PSD might help, but there > are also 164 with p=none, 29 with p=quarantine, 7 with pct=N where N > is not 100, 4 with multiple policies, and about 30 where the DMARC > record is invalid. Assuming your goal is to get everyone to p=none, > PSD doesn't impress me as offering significant help. My understanding is that, since, as you say, PSOs (like .bank) have a pre- existing relationship with their registrants, they don't need PSD DMARC to audit their registrant's policies. For an entity like that, it offers the chance to get feedback on other, presumably non-existent, domains so as to better understand abuse patterns within the PSD they manage. It also gives them a mechanism to express a reject policy for those domains, which does not currently exist. This may help improve rejection of cousin domains by receivers. For single entity PSDs, like for a very large Internet company that is, conveniently not named after a large South American rain forest (so they can get it registered), it offers other advantages. In cases like this, the PSD operates like an organizational domain except for the fact that in the current DMARC instantiation, their record won't work for subdomains. PSD DMARC would enable '.example' to publish a single record for all lower level entries in the zone. Scott K From nobody Wed Jan 16 07:05:25 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01E3130E74 for ; Wed, 16 Jan 2019 07:05:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1bzCsIv3t-gA for ; Wed, 16 Jan 2019 07:05:14 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 CEEBB130E5B for ; Wed, 16 Jan 2019 07:05:14 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id v23so7692072otk.9 for ; Wed, 16 Jan 2019 07:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=VrOtcSf85d3LF1geQFJPDHjZBA3ZekeUpzXyEl3yVfk=; b=tzFiwXK3TGhmN9QqKx0LTLzQsDMBlIfuCDVWbStIi9opCjoC7vn6GrTRH/FYqD6N3u c7tF2GkO2ueyU7rjaHXeWwhIv0hPqXwupbh+GSQ9iF5TIMc8FNd8Z7IYSAH9VbVcA741 F9Q8MBzUg7NXlIzIGGYD1YSkKUucwSa7qXrTTTwbPMweBZT60Isdci7TCAvXK63fW1eI FafzVmb6NqOiX/DbbXM0TXz5b1ElspOjM87FfLoRJIUKTmMyNe3J2/9QLUaJHubiI48Y +QTsDZmmnxnl6N8pwEz2oTTLwve0pdAJly7kSVHWnvY9Ke7VZgKtVGLOHS1IJiz3SEx0 goUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VrOtcSf85d3LF1geQFJPDHjZBA3ZekeUpzXyEl3yVfk=; b=Qt4HoJTKbXOO47OdPNshNzh3IfDoeeAh+zewse0mZz3MnmKRgRFLvkMZkYSZD/wxw0 1PyWj81W+2VUZ1J06cGW4NzCugNMB4qpR925yAd4YdWecYYG4AflzUa+LaMnLwahhNom +a2pmX9d6yIQCAIS+COcRGviZ51YJ98iPWNxAR+44qCDyF1ZqVOb8TszYzcFjYyq6/Cc 9ElcZL5+AwI4RUL57YIGhXOAAVJDHHib6zkA89XAHkfEeky4yE/Z5iTj6tV1a2Ml6JLn 0EHfUgfqp5CvoHNgvoBw7pbVflHq2PEBLTL3gDk6zWy40sWPN1XjJdPVAPyL17FYnia3 wB5A== X-Gm-Message-State: AJcUukdTYzmVkw6bCKQ+Un8HU5KUjXgmbqkpEtV7nj6ME48cRMtBTBjL T7ZqnL+NtIMXYn9JOKiyd1qnwg4d X-Google-Smtp-Source: ALg8bN7rVJS1x+ICbkwM5eiKU8DfMoOr1sNwzx+xlBZqt0rG7EKnkFJuwbbID2m9W5ITeEfGh/+clg== X-Received: by 2002:a9d:f05:: with SMTP id 5mr5952981ott.123.1547651113657; Wed, 16 Jan 2019 07:05:13 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net. [76.218.8.128]) by smtp.gmail.com with ESMTPSA id 31sm6099519otw.55.2019.01.16.07.05.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 Jan 2019 07:05:12 -0800 (PST) To: John Levine , dmarc@ietf.org References: <20190116005804.A0A80200CACDA9@ary.qy> From: Dave Crocker Message-ID: Date: Wed, 16 Jan 2019 07:05:10 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190116005804.A0A80200CACDA9@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 15:05:17 -0000 On 1/15/2019 4:58 PM, John Levine wrote: > I am staring at RFC 7489, and at a bunch of purported DMARC records > (see previous message.) > > The RFC says that all records must start with "v=DMARC1". Is it OK > if they start with "v=dmarc1"? It says that record is a DKIM tag-value > list, and the DKIM ABBF defines all the characters with hex escapes > rather than letters which tells me that it's specifically saying > that case matters. > > How about if there's a space before the v=DMARC1? The tag-value syntax > allows FWS before the first tag, but 7489 says in several places The formal specification is quite clear on both of your questions: Section 6.4: dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31 which means that the white space is required to be allowed and the value in this tag-value is case sensitive. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 16 07:30:24 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8231294FA for ; Wed, 16 Jan 2019 07:30:22 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=tKqUvUx+; dkim=pass (1536-bit key) header.d=taugh.com header.b=hLddLHhO 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 Dbi5c6yCNg3b for ; Wed, 16 Jan 2019 07:30:20 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 0A7F71200D7 for ; Wed, 16 Jan 2019 07:30:19 -0800 (PST) Received: (qmail 40954 invoked from network); 16 Jan 2019 15:30:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9ff7.5c3f4e0a.k1901; bh=BXsx+/s67QnfMwrBnUY6qE2AQNJbhQ0ARtepJFHDYkA=; b=tKqUvUx+UMZZUqkv9il7jD/0WgCGE+/ojxkPnLA/dON0F+yCZ223hdtwfCAofyS46NC+tUL3kvTXAo66r8ksdJTSF2Gk8lAKAQ3LSbpZOJCVnOf2ymsQaLiMziyjD+8hmPdhlyMh1L+AP1rTlAlhzSRkAAJG68v0o7OTeQ46R+67i3slNPCnYyraZBz+HyxNXR/ReVT7CrVPjna6XBPl4NyY7XNfvgwJoQCL9Y50fndHs3Zx6PhuXq5nvPIvraVG DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9ff7.5c3f4e0a.k1901; bh=BXsx+/s67QnfMwrBnUY6qE2AQNJbhQ0ARtepJFHDYkA=; b=hLddLHhOJJCgZ8bPQNCUqf39AQekWfzMRV8RlEcOs1qhwyITYVEd8T2sHZmLcaiMYovcnC4HvNWXzaxu9QCgF3EK0MMz/FTGaH9LEN61h/lssh129LlR0EgyR/fav8UFGm3pfCa914oIUcgwndh5Qd6nF/MV9BS/lfeiMFH5nz+wKOCjzxgoq4i6igpd2zesz8lUMGdCsvuE92Z8cGRdf8CVFgKbF9tAPhmtlJ51HqA5WCXN1NGL10VcYWQRcRzT Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Jan 2019 15:30:17 -0000 Date: 16 Jan 2019 10:30:17 -0500 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: dmarc@ietf.org In-Reply-To: References: <20190116005804.A0A80200CACDA9@ary.qy> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 15:30:22 -0000 > The formal specification is quite clear on both of your questions: > > Section 6.4: > > dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31 > > > which means that the white space is required to be allowed and the value in > this tag-value is case sensitive. Thanks, but the white space in question is before the "v". Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Jan 16 07:38:38 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30013130E57 for ; Wed, 16 Jan 2019 07:38:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 99yg8sPYg_0t for ; Wed, 16 Jan 2019 07:38:34 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 4A9AB1200D7 for ; Wed, 16 Jan 2019 07:38:34 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id 81so7957450otj.2 for ; Wed, 16 Jan 2019 07:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hDlwI/2CjZMa4+S0lrxVEv3OG53zdU6HtMYArFBlD+0=; b=J1l7W68mc+lb7EYGPiZkpuXcJbBZx+S4F7XIPYuxZuH+dGkA9JTO0XTAXZJ6Kx9dqS GrG3Rd17DrGzbzgJcMAgErp4YJw4FlGCNUfaLYRXt8ZtqQMZICVNigcB2RmEr1Wq0gc4 0vh/F9zx6/t5BeaKA0ArlEbCHVw4lPPFhAc7AbRN43WvD17dOA2rWIw3xSucSK3yjmuY 2ZSoaeXouZdK5K6huGhW1XtoVtJvl2t69NyO8AvLXHYiIii5GO2pTcNrYWGTvX8F6uaw gw6aZ1ACzdwky1SPqLLb+46L298OLqJlAOaWVd/NDQLdUEwI1EAM8bsQRIAWou24qRM1 EX6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hDlwI/2CjZMa4+S0lrxVEv3OG53zdU6HtMYArFBlD+0=; b=DQ44BwCDo0KYZZikyQFLvXXOgjDqOKMZJ/mXoU1UKSBl02ulWDLpm3b3wh9FdAjOsa BplnaFziRSozQScSFo0uGjlDgbc1bKYOpRb2ZxQaGUpiLY04oVV1s3mEXzQ1aQHPFS6u fYn4I33HHsP4wgWEiVy1Ot1vQF+mdPtihaYEQYmz6Xyma7SvnhA0Kl1W83v8H8KhjSdn En4IxqsCelZlMOhXGN6PCoVSXlMaDyuYNIga6P2dlHoIaZhJpXq4WjXp7d2MoZeOpG90 u9sueXlV+FWtipKTfCKzrEaVTf2WqIrFVMcrPAB/rlTe3VdNj6sgtNGQczhxc4Axa6Cj RHzw== X-Gm-Message-State: AJcUukeUVSHvv83JpnxCZX5LrAtr8DVprBhB+6eR3p9ABC3jCn/ivtsq 8+4F8lJYFvr8ePOwcQ0Jt3SleO8w X-Google-Smtp-Source: ALg8bN4Vb+bFqZjJxEGG8P2cJULX3Ayc/76K0PgXsf1AdnvMXiRm5kkigEBre8Rv4gtOhghQK9L9Yw== X-Received: by 2002:a9d:1d43:: with SMTP id m61mr6204313otm.170.1547653113242; Wed, 16 Jan 2019 07:38:33 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net. [76.218.8.128]) by smtp.gmail.com with ESMTPSA id 102sm2860605otj.65.2019.01.16.07.38.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 Jan 2019 07:38:32 -0800 (PST) To: John R Levine Cc: dmarc@ietf.org References: <20190116005804.A0A80200CACDA9@ary.qy> From: Dave Crocker Message-ID: Date: Wed, 16 Jan 2019 07:38:29 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 15:38:37 -0000 On 1/16/2019 7:30 AM, John R Levine wrote: >> The formal specification is quite clear on both of your questions: >> >>   Section 6.4: >> >>   dmarc-version   = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31 >> >> >> which means that the white space is required to be allowed and the >> value in this tag-value is case sensitive. > > Thanks, but the white space in question is before the "v". The ABNF rule I included, and the one that cites it (dmarc-record) do not show any white space permitted before the 'v', so no it's not legal. So the formalities are quite clear on both your questions. Whether there is benefit or detriment in making the parser more robust than the formal rules define goes to the heart of the last point in your original note. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 16 07:52:42 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BD412894E for ; Wed, 16 Jan 2019 07:52:40 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=iKz6KHg8; dkim=pass (1536-bit key) header.d=taugh.com header.b=YVtNck2k 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 LHuN5nZ_Nvs9 for ; Wed, 16 Jan 2019 07:52:38 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 5B9FE127B4C for ; Wed, 16 Jan 2019 07:52:38 -0800 (PST) Received: (qmail 46868 invoked from network); 16 Jan 2019 15:52:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b711.5c3f5345.k1901; bh=9hR1gBmMYJ4tt6kEFyszDLR/eveesMh0SPaX33nRg00=; b=iKz6KHg8cauZhem6uZiaqQ1zmPlDgiFP/OZllQH+DEfqW6Ejhp9gOcyY9b7mQNYGgvmxU4xAL59NUbaFfc6puZn1JgIU1LA1SN8Z7I7gkJbG/A6u5zqRZigcF/Tap685uaRpW5m7LfTx4UxGm7Ya6QRn57Dw9lk6FmUiew9Q29B+SRxKT2CsV8zJfx7yAwrShE8Sfdrw7DOu6eMPAOfDfhoFjeAZyOksPHyPdU/rSQ+Y/cXkyNkpm9YW5r3BNPlM DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b711.5c3f5345.k1901; bh=9hR1gBmMYJ4tt6kEFyszDLR/eveesMh0SPaX33nRg00=; b=YVtNck2kMNPP4cbUIVJeUOf+PlHUvIIMq/zcrRI06qsD7Tm/ifVtzFXmFB0+ndzVRgnsVZcLwz0llQWbYiOkq86Ye48+2ygPuP3iHWcUt8TOzsz0xPbZRsPQZMUxSN4p/FBA6JVVZBnQBqXwYx33PnqER3iNJ5Yg9kdOkMBwG5XynwKygd4qgQkiQ880fS9WyBdQc61h041Q2SA880UyJYrtV/gGPEHa/VU0thxtkrzcE9zMq+zeKdDPbFf9tMOn Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Jan 2019 15:52:37 -0000 Date: 16 Jan 2019 10:52:36 -0500 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: dmarc@ietf.org In-Reply-To: References: <20190116005804.A0A80200CACDA9@ary.qy> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 15:52:40 -0000 > The ABNF rule I included, and the one that cites it (dmarc-record) do not > show any white space permitted before the 'v', so no it's not legal. Ah, now that I look at it again, I see that the dmarc-record rule is the one that matters here, since it allows WSP after the version but not before. OK, they're all broken. That's what I'd sort of hoped. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Jan 16 09:16:20 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5E124BAA for ; Wed, 16 Jan 2019 09:16:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 GnMbn1LiBOX7 for ; Wed, 16 Jan 2019 09:16:16 -0800 (PST) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 EB850124B0C for ; Wed, 16 Jan 2019 09:16:15 -0800 (PST) Received: by mail-io1-xd44.google.com with SMTP id x6so5470128ioa.9 for ; Wed, 16 Jan 2019 09:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Aa8ma3+VyNmDdF9OUQOevIi33JCAZBHhUBw+bqh3gYQ=; b=Z40IDJvPZ6zVBzUUbQNTfaQr9cciv/CeWwD/i4+9QhWP6LKP1ErrIl+tU9pIx5JjA6 qBeIDdIQVs4CILEV9mKCMdtCVHA/vgo2XVUEXNy31Hqh4+YSxCebyaJJhG0KC5s+9Gr6 uSLtoO3s8gF7Pj8ONpjZmm2UuY8WWXC92iIFE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Aa8ma3+VyNmDdF9OUQOevIi33JCAZBHhUBw+bqh3gYQ=; b=nfMQkdmE8mMAXdwXjPCgtUMeN2btdDlYSj5oqwG9ktbran06IBEAxh75lWH/zozfkZ zfNEEYzuYshjhF8HptCuuvotFX0bVl8gpS84GTBEHv2f7qLCmf/jGsghdHwto1Q1HqaZ wDug9HEzmLEyy1XZTumHPc++6zf42N/c+R8dYm386F1qP90TFj6RPm84ALEz2amhfjgU tH3wOfpNB1Kg1eFwzsN9zj9JqIP+BYWo+oAqbGi6ZC/3nnHdT2z57OVj22Gvw4XgI5Pj 0uvhSVts2TfwitFHmM8bj5CkzbeJEoQR/NX3hWs9tYHCnJ4XMm/IKu1uPi/21u62u5Km YaNQ== X-Gm-Message-State: AJcUukebOM3aWMcVPFIVafHOMUFzvfbayk1qI5p83HBLhFm/NsR6J+Nd d7Lm3DmmW8EmaCxszswVagab0JSQ5MqR7WukUV3BZQ== X-Google-Smtp-Source: ALg8bN6vYx+EnlKzRaxsSFCrM9gDaRcn1opS+Wvqldvlrd5X+ory1vGWRmYJhESLztAVIMTkLRgXbAX15eG+m3Ul2hs= X-Received: by 2002:a5d:8597:: with SMTP id f23mr5765410ioj.238.1547658974933; Wed, 16 Jan 2019 09:16:14 -0800 (PST) MIME-Version: 1.0 References: <20190116005804.A0A80200CACDA9@ary.qy> In-Reply-To: From: Kurt Andersen Date: Wed, 16 Jan 2019 09:16:01 -0800 Message-ID: To: John Levine Cc: Dave Crocker , dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000006f5676057f966f67" Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 17:16:19 -0000 --0000000000006f5676057f966f67 Content-Type: text/plain; charset="UTF-8" Is there really a benefit in filtering out people/organizations that are not fastidious in the use of whitespace and character case? Seems overly nitpicky and something to reconsider as we look forward forward a standards track for DMARC. On Wed, Jan 16, 2019, 07:52 John R Levine > The ABNF rule I included, and the one that cites it (dmarc-record) do > not > > show any white space permitted before the 'v', so no it's not legal. > > Ah, now that I look at it again, I see that the dmarc-record rule is the > one that matters here, since it allows WSP after the version but not > before. > > OK, they're all broken. That's what I'd sort of hoped. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000006f5676057f966f67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is there really a benefit in filtering out people/organiz= ations that are not fastidious in the use of whitespace and character case?=

Seems overly nitpicky and som= ething to reconsider as we look forward forward a standards track for DMARC= .

On Wed, Jan 16= , 2019, 07:52 John R Levine <johnl@ta= ugh.com wrote:
> The ABNF ru= le I included, and the one that cites it (dmarc-record) do not
> show any white space permitted before the 'v', so no it's = not legal.

Ah, now that I look at it again, I see that the dmarc-record rule is the one that matters here, since it allows WSP after the version but not
before.

OK, they're all broken.=C2=A0 That's what I'd sort of hoped.
Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
dmarc mailing list
dmar= c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000006f5676057f966f67-- From nobody Wed Jan 16 09:26:18 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FF7124BAA for ; Wed, 16 Jan 2019 09:26:16 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=1w9Iyhls; dkim=pass (1536-bit key) header.d=taugh.com header.b=DBP7rKjc 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 0vp0_alauhqT for ; Wed, 16 Jan 2019 09:26:14 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 70D671228B7 for ; Wed, 16 Jan 2019 09:26:14 -0800 (PST) Received: (qmail 4044 invoked from network); 16 Jan 2019 17:26:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fc6.5c3f6932.k1901; bh=WwQKwQtFEVIs1jFwtqOfNTuV3oEg78lSEh1H+cEx94w=; b=1w9IyhlsYh4vsMii9z1Nm7DjiC76fxHQSHkZe+J2lrjgTQinbVtkFoN2lLGe6GugcP5DQR48Ri5lw404/x8rKSraqEB4PJ7/e4xBPVTJ01hRtk+rLwSiUwNhbjoTHQqlLWLGAORTLQ3+QMIqUx7RbNpBsvU0BDxwdFnu8IiUE7w692hlZ0sUpOVYNUtsODggZqXcMiPSZG7DIrmNZE+B0D99NbP1c3Yz2Z8DNP8JD+KedXjX0xyZpl69Krk4sbzg DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fc6.5c3f6932.k1901; bh=WwQKwQtFEVIs1jFwtqOfNTuV3oEg78lSEh1H+cEx94w=; b=DBP7rKjc+tkn1cqNMBqaCArXM4+qUqoy/2oL/+WYzh8cM7ng3kER2/rLfjVFE6ygPfhUsV3p75lH9++eagATwvKN/Qw0hSVCPG4GpTWc0WDe4nCzCCqnlMQNKpxv3m4xr63yPifyETKnzFBK8mj/pEbkZ43UD8xtzhg6l47SoaAgWKqYvfqk5SlG3HzfPT55DjhWPiipELUdmxrhFHs5zkpNZGdxbwMV1sSERWQ+8BDl5jeUbP8H7HwNd7d4qzMf Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Jan 2019 17:26:10 -0000 Date: 16 Jan 2019 12:26:10 -0500 Message-ID: From: "John R Levine" To: "Kurt Andersen" Cc: dmarc@ietf.org In-Reply-To: References: <20190116005804.A0A80200CACDA9@ary.qy> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 17:26:17 -0000 > Is there really a benefit in filtering out people/organizations that are > not fastidious in the use of whitespace and character case? Maybe, but that's not what standards are about. The point of a standard is to say here's what you do if you want to interoperate. I have never found it productive to speculate about what you might or might not want to do when you run into people who didn't read the spec. In the particlar case I ran into, they're all in .bank and I would expect that .bank's auditors would contact their clients and get them to fix things. They have worse problems than wrong capitalizations, like banks publishing two different DMARC policies, or one that includes "pct:1" whatever that's supposed to mean. Also, in this case keep in mind that the default is not to filter, so you're not going to lose any mail. You might receive a few more phishes. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Jan 16 10:35:04 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6882C130E69 for ; Wed, 16 Jan 2019 10:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net 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 jsN2H7ZlmDdI for ; Wed, 16 Jan 2019 10:34:58 -0800 (PST) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (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 3F69A130E62 for ; Wed, 16 Jan 2019 10:34:58 -0800 (PST) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id x0GIYusp014467 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 16 Jan 2019 12:34:57 -0600 ARC-Filter: OpenARC Filter v0.1.0 tncsrv06.tnetconsulting.net x0GIYusp014467 Authentication-Results: tncsrv06.tnetconsulting.net; arc=none header.d=tnetconsulting.net ARC-Seal: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1547663697; cv=none; b=qGn8H+Pow+tYGNs1n1ho38shPHDEydH67sjaFJJJ5/sdMDHeGfKhXVxrPywJbBQDccRElCtIhEXqk/0xaJpfyIuBAu4xGnuG8wvZIhKb4CU4m8vSVCz/XoMZymp8ChPb8yx0WUI0ZQFQqXGDjdv7XDhGsbwGQ+SkfPod6OvH73g= ARC-Message-Signature: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1547663697; c=relaxed/simple; bh=Y9nePK6DSaTzi3qjQZDm3DQEDDGxYSzHH6P7kfQUbG4=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type; b=j8Gvxrbf/qLnCn0HS5thllAdiKc+AqEtcbw3sg7KEiSoJpV3BxT87tPRXQ+C0smy3rgwszAUzAFbUHkSDgq1peGyHhfLQT0G4ThW2rlTN0i+juDrqjwdNgrFEOeKf7ifWWOxlv6geX6DoFjhmJPCwaMInd8h2p1TgXdSbDqTBd4= ARC-Authentication-Results: i=1; tncsrv06.tnetconsulting.net; none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1547663697; bh=Y9nePK6DSaTzi3qjQZDm3DQEDDGxYSzHH6P7kfQUbG4=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=MfjtEU6uIJ0qa2qLSVLeVZzzS01pZsBlnmZmxcH5JrGZlFfDP5Ill3iGJnkqLFkig /S0+pRG63LFWOtqrMB+1Xzr8Svi7zjtsY2AJZDSpYlu823EWf+HHtd1lKLICU1/c7o i01OE+Kud10rh47Tr/HlQpY2o27ne9b8SJOdPOn0= To: dmarc@ietf.org References: <20190116005804.A0A80200CACDA9@ary.qy> From: Grant Taylor Organization: TNet Consulting Message-ID: <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> Date: Wed, 16 Jan 2019 11:34:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000203050700020301010505" Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 18:35:03 -0000 This is a cryptographically signed message in MIME format. --------------ms000203050700020301010505 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01/16/2019 10:26 AM, John R Levine wrote: > Maybe, but that's not what standards are about.=C2=A0 The point of a st= andard=20 > is to say here's what you do if you want to interoperate.=C2=A0 I have = never=20 > found it productive to speculate about what you might or might not want= =20 > to do when you run into people who didn't read the spec. I agree with you conceptually. However I feel like rejecting things because of additional white space=20 (in front of v=3D...) or the wrong case is being a little bit pedantic. Rather, I think that if removing a spurious / leading space or folding=20 case causes the DMARC record to be valid, it behooves us to tolerate=20 such minor errors. I don't want to be so pedantic that people push back on adopting what I=20 (and I assume others) think is a good technology. Is doing so against the letter of the specification, absolutely. Is it=20 within the spirit of the specification, I think so. --=20 Grant. . . . unix || die --------------ms000203050700020301010505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Cy4wggVAMIIEKKADAgECAhEA01fiRe1k2R6LEQCcImIMYTANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgxMTE4MDAw MDAwWhcNMTkxMTE4MjM1OTU5WjArMSkwJwYJKoZIhvcNAQkBFhpndGF5bG9yQHRuZXRjb25z dWx0aW5nLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANgOhvncDgc4KAlD +pyhFpw6wCfeERlSOAXowjdTjlOR2zcIgzL0TM9A+hkSv2wsVh6fn6VvHGxKrLemReiGd7fQ 15Y9J/pxKOmShkw9DDtFsa18ozydp95X2IuzY8Z2JukxouqrfpSH4fOrrHLkOgvlFG4xaQHW 0KB8xUP5DFWyyZM5QCdq278GSJ5pUd+B6qmzwHESNF6syyvgLppXkFatLTz8pWf6eEngDA0Y 3fQ3Q2gnbgpryRhVQMa1GjQJ7LDroUGQhX2zBWePW+sShiTwo8jADYKsbgSGtvZ/42A8zxyg s9YZMHQoCeeuLNuX/MBp9rCTl5nlzP3jGWQTC5ECAwEAAaOCAfAwggHsMB8GA1UdIwQYMBaA FIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQg2PeEKxHWd4FaHe0T+gqAOWkC1jAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRT MFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29t b2RvY2EuY29tMCUGA1UdEQQeMByBGmd0YXlsb3JAdG5ldGNvbnN1bHRpbmcubmV0MA0GCSqG SIb3DQEBCwUAA4IBAQCPxlHHG57PA5GUYlQuC8VHB7TcMQeEJKnB/S+bamyrck4vpIEaF9rG EM+OnAQsJzSkSVHD2707jxh1ng0jrsH2+F9qNGTpCksXo0fMqm4tf28Ag092+CZ5sfdjVZ4E ELG4xNhFZF9/aFaAY7RIeJ89Vvn6s6BnKsaAPjVB/sO+5gIm0BIeoVauq71ue6jS7o2Jn94o BuAhjuh34gk/Wxzcku96MLmEwCY63GWWKVRYbqrDhqROmnQPdyrDYrU8uD0vb4SAdpSKfRqO DrerlQgX3euyYqcnVJSA8Ec+NdiJrGKXW76C7DrTi7IxDgjIHL+DPyFgtj+p6wYOEkYJwKtp MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBS U0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpY PpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1 wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP 1cHWse9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5 LFLG3yQK+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy 1DAdBgNVHQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0 dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHEGCCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJ CAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/h k6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWl nhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNm NppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tU U1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR 6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ 16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8ao rYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5 v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfK ehIxggQ4MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx PTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQDTV+JF7WTZHosRAJwiYgxhMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTAxMTYxODM0NTZaMC8GCSqG SIb3DQEJBDEiBCAYyd9tvezVvyFDfP0TRzMWWm5xNUfszMc3Ma1/P/bFbzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEE AYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0 ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYD VQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEA01fiRe1k2R6LEQCcImIMYTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA01fiRe1k2R6LEQCcImIM YTANBgkqhkiG9w0BAQEFAASCAQB0G1AivteBWaKreMJizdbOGRm8RySXlKMHY6uQwyEZObSp GomyKqMiZJsQiXgJU08Lz2BJpfxf895qeZyV9ZCPFLZoGuk9ESSiMFbcja+K0j/wNmuYwb1g F/hYMflhOvEhq+9XyJK4PYlZ6XuF4QIMcKVsUzgcFZck11ueFnsP0j8pGXzbbPgVPgfaf/ju 1/orasCn7qa8tI4UA8uExAx7275BliM9RnX2pwPDEMrjm/pFq3H6syZfhWmhKJJcUyj+QfKn jWQOAK286Yau9oNaUCR7/HAhffOayKbDibUAu/Q0vQLc5kMMDV9Pb6Rme0gin5BG6CjBDQot nbYmZKgIAAAAAAAA --------------ms000203050700020301010505-- From nobody Wed Jan 16 10:41:47 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE66130E85 for ; Wed, 16 Jan 2019 10:41: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1oRR6YzoM568 for ; Wed, 16 Jan 2019 10:41:43 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 3A513130E83 for ; Wed, 16 Jan 2019 10:41:43 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id a11so8642988otr.10 for ; Wed, 16 Jan 2019 10:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=EPDOKHpjvgFHGaBi8EC8l5YSJ7IHDSpRnpJz3Yqct3Y=; b=eBqasULsCPO2rsbShR9LVkACMD3CwzFu7UCwpBauTp4qQFlghtHG0s3E2CVTPlSIzm eM4HXw9o1Vcac23SL6TwQ5FVt5pjLA/KEpWG90qW94vll+0Z535k+z4t6ZO7/vuJ899n ddtM1BlctN0Ir6U0a46r7aGpO9AoeQXMHBB4rZwxuRi5QRTJNX4hK0Rfthr0wfHIrAF6 9PZwIBWLlnByn7Ziqj0bGbsLzLYg8AAUK3KFc4TEaCKnTNW0M2QbZrMK+ECtQHvtND7M 5wkxRG+YqGYc6FfsTUNZOjP3xtxOJEwMMD7kshXKvnt4Rl5laP3R44fdGVVQ5A8sx6vq 0Rgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EPDOKHpjvgFHGaBi8EC8l5YSJ7IHDSpRnpJz3Yqct3Y=; b=uUNOOo/oJRQiRijOmhQGdB+ayc83IMXKMFZchotmYzUIco3ddHv0/CCfVf4E0KqntN 3eXRMX2PdthBGmwXRgeH3JnJB0E9eRLGBatYExa8LMHg13Uw8oTeH3IiAAOL2qt1VzJm /6PU7ewHFbB2ZCjhUk2flewXMH1Dm3+zjV45TYj7nOISrBioHBteZGXwj4swmFESD/zV Xf5CBfZ0B1/T7RbFcVsO9K90p2oeiJ66zZwfk1we8bfK7N59let4kWLbgp5KEWvmUCO1 RvjlGcjI659wh3nc1ITtP2jXNmnm3vBQeW/TGG8GVxzFT0IUXahY9LfE9s4NQ+K6j/XC 2ndA== X-Gm-Message-State: AJcUukeXCgbKmmALQwhxrZ44HC+OsGuiSEwvAvWh4XSPtHKrKNO9VL5O dOqYGVadnIk2nQwjrSz6/uaaEz1s X-Google-Smtp-Source: ALg8bN4agrmFw6A0V1knRF2EBLOjl5+2Gj7hEatYBetT/z8z94hgFo9NF34vfMITKTc50zh+P811Ng== X-Received: by 2002:a9d:7749:: with SMTP id t9mr6780432otl.342.1547664102071; Wed, 16 Jan 2019 10:41:42 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net. [76.218.8.128]) by smtp.gmail.com with ESMTPSA id v68sm3214017oie.16.2019.01.16.10.41.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 Jan 2019 10:41:41 -0800 (PST) To: Grant Taylor , dmarc@ietf.org References: <20190116005804.A0A80200CACDA9@ary.qy> <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> From: Dave Crocker Message-ID: <7c8aa4a8-7d75-db07-7e97-82d9b0ffb29a@gmail.com> Date: Wed, 16 Jan 2019 10:41:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 18:41:45 -0000 > However I feel like rejecting things because of additional white space > (in front of v=...) or the wrong case is being a little bit pedantic. > > Rather, I think that if removing a spurious / leading space or folding > case causes the DMARC record to be valid, it behooves us to tolerate > such minor errors. > > I don't want to be so pedantic that people push back on adopting what I > (and I assume others) think is a good technology. > > Is doing so against the letter of the specification, absolutely.  Is it > within the spirit of the specification, I think so. There is quite a bit of dynamic tension in this topic. There is pressure to be tolerant, best captured in Jon Postel's robustness directive, and there is a slippery slope of having no firm, clear and precise standard. If more flexibility is viewed by the community as desirable, then the community should enhance the specification to allow it. This improves robustness while retaining a firm, clear and precise standard. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 16 11:18:29 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F291130ED9 for ; Wed, 16 Jan 2019 11:18:28 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=w2WX/JJE; dkim=pass (1536-bit key) header.d=taugh.com header.b=AajVMZhA 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 MIMZ6rluMxO0 for ; Wed, 16 Jan 2019 11:18:26 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 62703130ED6 for ; Wed, 16 Jan 2019 11:18:26 -0800 (PST) Received: (qmail 66947 invoked from network); 16 Jan 2019 19:18:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1057d.5c3f8380.k1901; bh=m7vLJrUdqYcYVJii+O5ogLyMoY/QCanOZA81lKkV+j8=; b=w2WX/JJE2ZN+4FEF6eqYPp0jOJ8reBNxddqXaFgC46nErMx1oYrb6kPNlXPdvytnGisAzho3nTHsRkRlK5k8ii92c/USfy6OKWJQ+spu6sRs1Kj+K1ZXbdmifWWvJUk2jklSpCPCfQWDOSjJ8XQSBXIp5uMQaNpJokbhNDymExDDFNiqW1ofkOwvnDHvXtwbQWRnpmk1yvLsFFKxbgg64n39LmLer0OiMIb2PjVaNqsUVgaD3RC+qiu8BH541qI6 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1057d.5c3f8380.k1901; bh=m7vLJrUdqYcYVJii+O5ogLyMoY/QCanOZA81lKkV+j8=; b=AajVMZhAChmWe79IDsCqn9LAukTXvrw7zgDlk1Ag3prHzsXrEzXh8bYpciF2aBezPc2030+bNYkGuvVbUs5bH6/QbmGXcT90sctAxAOwS04EfDqZgf5xE6yp2fDRJ+H4eQGAGltR+bm+6nsXbwvS+wzRGuW2Jt+8M5KFp0xVzrwRdaTRkDCgPAZW8qZxvV1BbI2CFIrkI1JIGyu/ezJwRdjdGpSFayc8VAzaSu27J/2OCKjOj4BlT/NgF+GkSLAE Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Jan 2019 19:18:24 -0000 Received: by ary.qy (Postfix, from userid 501) id 0E64F200CC135A; Wed, 16 Jan 2019 14:18:23 -0500 (EST) Date: 16 Jan 2019 14:18:23 -0500 Message-Id: <20190116191824.0E64F200CC135A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: <7c8aa4a8-7d75-db07-7e97-82d9b0ffb29a@gmail.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 19:18:28 -0000 In article <7c8aa4a8-7d75-db07-7e97-82d9b0ffb29a@gmail.com> you write: >If more flexibility is viewed by the community as desirable, then the >community should enhance the specification to allow it. This improves >robustness while retaining a firm, clear and precise standard. Do keep in mind that most of the DMARC records I've looked at follow the spec. They may not have the expected policy, but the syntax is fine. If a small minority get it wrong, I think it's better to educate and fix them than to try to guess when someone misreads the spec in a way that leads them to screw up the syntax of the record, but not to screw up anything else. Remember, that if your software rewrites an invalid record into a correct one, you are trying to read the mind of the person who wrote the misformed record. I can guess what v=dmarc1 was supposed to say but I have no clue what pct:1 is supposed to mean. Let's not start. R's, John From nobody Wed Jan 16 12:00:28 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637E2131142 for ; Wed, 16 Jan 2019 12:00:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nz7KDveu5nBu for ; Wed, 16 Jan 2019 12:00:18 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::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 5EFA5131139 for ; Wed, 16 Jan 2019 12:00:18 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id r62so4267030oie.1 for ; Wed, 16 Jan 2019 12:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=UjjEF05rHXwnwXX4nxtKle5/2xRM5cKlhz2Rdf/nFso=; b=KwAAhyCk9wO3GxBSgcGoa4NJoStvyV+9hgYBE9O8B5W8NEq4ogh9ysIOFOaTWQ/wu6 BbLMjET1Okacy0gQ81oTpaszgLHW1DC9uZw0tA3+aTULvVj2Ie4NZMrrT5imbd03iCK6 azYDuDL/O/yPkDqLJbNpCQMAtKBSv9L917VGWbSNnqfx6dAbe8dEmQ369P18dJCOH63G BNXCTpr2ssQqMKkqbn4JI909jbZFQwRD3nXmD8Hp4Fmy4tVoMlCPjHKEMoqB8ObGvkQb mVTskZyykQ9QBPfK2rFlr7hJskG3OWxV+JOVhqxCIPbR4Au/6CuTgqN67/fZTQzvqRVC aj4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UjjEF05rHXwnwXX4nxtKle5/2xRM5cKlhz2Rdf/nFso=; b=dg1iS7fsBhlVoOYxBY/5WIKMv54BWMpgc4s5mBHEurA0XRoSUbLVqHTbSyxsTOE6V7 aRHGovmD//EmlgLwgYQR/LNwTQz/rpGLeqPRB+L0B6YXaB2ylcSPfXQJQNDPg6M77nva DCyFeyBj7qlE6UK9pNGC+3exKyU35JmhLy9uunZG1WqcxFFjBrmzVKtT6rZZ3dtQ9rxk a+TLbyG6MD/vW6IdNgjmyuWuTH1Fg2i/nSQHTutPy54I8pnh8tpLdoddqF/BkIqjxFiW BwLbSnC3824bK3xwC9uLJ7kbGJPyZqOophEA5xLbLpe8xFnwcQPjFbzYNVCFa26UM716 UGSg== X-Gm-Message-State: AJcUukfMQ6iGyMJNFjWLtrAA2tnjStGjQ8cAPtwFLBWqTyYbMvFbVUbM Drt9JcGviDbXC0g+uL6pbV2nuWpI X-Google-Smtp-Source: ALg8bN5d7NuClYlFcGDYLhcA+2nI5i9YkMDRoj/nOjRVILK0JguVrLv6+vAt4tpL02xHjfv11qa/3Q== X-Received: by 2002:aca:5406:: with SMTP id i6mr1683288oib.344.1547668817335; Wed, 16 Jan 2019 12:00:17 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net. [76.218.8.128]) by smtp.gmail.com with ESMTPSA id 75sm5370032otc.67.2019.01.16.12.00.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 Jan 2019 12:00:16 -0800 (PST) To: John Levine , dmarc@ietf.org References: <20190116191824.0E64F200CC135A@ary.qy> From: Dave Crocker Message-ID: <8217a12c-385b-ab11-0453-b1be185f1701@gmail.com> Date: Wed, 16 Jan 2019 12:00:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190116191824.0E64F200CC135A@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 20:00:27 -0000 On 1/16/2019 11:18 AM, John Levine wrote: > Remember, that if your software rewrites an invalid record into a > correct one, you are trying to read the mind of the person who wrote > the misformed record. To emphasize a point you made earlier: There are many, small adjustments that a receiver might make, with the intention of operating more robustly. The current examples certainly quality as small and seemingly innocuous. But the earlier point was that one deviation from the specification bodes ill for more important questions of conformance... If they didn't read this part carefully, why believe they read other parts more carefully? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 16 13:50:20 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279421311C4 for ; Wed, 16 Jan 2019 13:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.841 X-Spam-Level: X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 Z6WJsqeuTvlC for ; Wed, 16 Jan 2019 13:50:14 -0800 (PST) Received: from smtp48.i.mail.ru (smtp48.i.mail.ru [94.100.177.108]) (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 66200130ECE for ; Wed, 16 Jan 2019 13:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=giBZM8W1NJEOrPBSirc+P91Vuu2++LrSrgMIdsLCc0c=; b=LTyo9PifDaksnp5hyYhvUuat+UTUjTRviOyo7aLlXaoyyQ3PnS9oZYIhvJPDUTcx5Gtuc5thW+1Vyv+KY5CHRBauHSeMmUPvcM4CvPHkS+ut/Y0xEbByoF01KrsNYAVqbkGrd/8mkzDsouYNeIdsCdbgRQTiJaXyqz2VyoZzWCc=; Received: by smtp48.i.mail.ru with esmtpa (envelope-from ) id 1gjt4c-0003xI-99; Thu, 17 Jan 2019 00:50:10 +0300 To: Grant Taylor , dmarc@ietf.org References: <20190116005804.A0A80200CACDA9@ary.qy> <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: <132ef6dc-86f0-3283-71fb-ea80d8800428@corp.mail.ru> Date: Thu, 17 Jan 2019 00:50:07 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> Content-Type: multipart/alternative; boundary="------------131DC729BF01490DE695721F" Content-Language: en-US Authentication-Results: smtp48.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: 45FC86C5E5471C34CA1242935FE4E02783D3C0612D38DE4669A4C5A289F4A982 X-77F55803: BBE463BEF7A60BD05A78504BD2AC2941382F125FEC086B485109C54C1DDE6CFCEC84803AE87C3D22E8D454A4765AA473 X-7FA49CB5: 0D63561A33F958A541532057215B2FC12E870B1DD9634BF6F44FEF15D260A59B8941B15DA834481FA18204E546F3947C1D471462564A2E19F6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8BF1175FABE1C0F9B6A471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C2249E5E764EB5D94DBD43AA81AA40904B5D9CF19DD082D7633A0E7DDDDC251EA7DABD81D268191BDAD3D78DA827A17800CE7BFC02AB3DF06BA5ACD04E86FAF290E2D40A5AABA2AD3711975ECD9A6C639B01B78DA827A17800CE749F2E05FB3BF77DA6E4794A9BA48C0DE75ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC85B5698D31FB5189B627F269C8F02392CD5571747095F342E88FB05168BE4CE3AF X-Mailru-Sender: C5364AD02485212FE93695002315C043B8117D5B1DEDDB7FAE61A51775438CF30A3546B62FC67E47DF27400FA58A4AF1E66B5C1DBFD5D09D63761FFB9297ED015BF713DEE2A5F4A567EA787935ED9F1B X-Mras: OK Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 21:50:18 -0000 This is a multi-part message in MIME format. --------------131DC729BF01490DE695721F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I believe in the situation where standard is absolutely clear like this, any implementer must strictly follow the standard. Otherwise, it can lead to unpredictable behavior and security issues. Example: there are absolutely legal situations where non-trusted or less privileged side can partially control the name and/or content of the DNS record. I can provide users or customers with possibility to register a hostname and TXT record in my zone but I want to prevent them from corrupting or changing SPF/DMARC/etc policy. I can rely on filtering TXT record content. Non-standard behavior of DMARC implementation can allow to bypass this filtering. While this example doesn't seem realistic, I can demonstrate quite realistic ones. For example, a minor relaxation for ARC version check can lead to DKIM signature spoofing, compromising DMARC as a result. For DMARC DNS record itself, realistic scenario may appear in the future. We already have a lot of problems in-the-wild because of standards relaxations, e.g. it's usually possible to bypass DMARC which relies on RFC5322 via malformed From: due to fact invalid From: header is generally accepted and parsing From: header for DMARC validation and for visual representation is usually made by different pieces of code with different behavior. 16.01.2019 21:34, Grant Taylor пишет: > On 01/16/2019 10:26 AM, John R Levine wrote: >> Maybe, but that's not what standards are about.  The point of a >> standard is to say here's what you do if you want to interoperate.  I >> have never found it productive to speculate about what you might or >> might not want to do when you run into people who didn't read the spec. > > I agree with you conceptually. > > However I feel like rejecting things because of additional white space > (in front of v=...) or the wrong case is being a little bit pedantic. > > Rather, I think that if removing a spurious / leading space or folding > case causes the DMARC record to be valid, it behooves us to tolerate > such minor errors. > > I don't want to be so pedantic that people push back on adopting what > I (and I assume others) think is a good technology. > > Is doing so against the letter of the specification, absolutely.  Is > it within the spirit of the specification, I think so. > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru --------------131DC729BF01490DE695721F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I believe in the situation where standard is absolutely clear like this, any implementer must strictly follow the standard. Otherwise, it can lead to unpredictable behavior and security issues.

Example: there are absolutely legal situations where non-trusted or less privileged side can partially control the name and/or content of the DNS record. I can provide users or customers with possibility to register a hostname and TXT record in my zone but I want to prevent them from corrupting or changing SPF/DMARC/etc policy. I can rely on filtering TXT record content. Non-standard behavior of DMARC implementation can allow to bypass this filtering.

While this example doesn't seem realistic, I can demonstrate quite realistic ones. For example, a minor relaxation for ARC version check can lead to DKIM signature spoofing, compromising DMARC as a result. For DMARC DNS record itself, realistic scenario may appear in the future.

We already have a lot of problems in-the-wild because of standards relaxations, e.g. it's usually possible to bypass DMARC which relies on RFC5322 via malformed From: due to fact invalid From: header is generally accepted and parsing From: header for DMARC validation and for visual representation is usually made by different pieces of code with different behavior.


16.01.2019 21:34, Grant Taylor пишет:
On 01/16/2019 10:26 AM, John R Levine wrote:
Maybe, but that's not what standards are about.  The point of a standard is to say here's what you do if you want to interoperate.  I have never found it productive to speculate about what you might or might not want to do when you run into people who didn't read the spec.

I agree with you conceptually.

However I feel like rejecting things because of additional white space (in front of v=...) or the wrong case is being a little bit pedantic.

Rather, I think that if removing a spurious / leading space or folding case causes the DMARC record to be valid, it behooves us to tolerate such minor errors.

I don't want to be so pedantic that people push back on adopting what I (and I assume others) think is a good technology.

Is doing so against the letter of the specification, absolutely.  Is it within the spirit of the specification, I think so. 




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



-- 
Vladimir Dubrovin
@Mail.Ru
--------------131DC729BF01490DE695721F-- From nobody Wed Jan 16 15:10:25 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E34B131201 for ; Wed, 16 Jan 2019 15:10:23 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=UMTrH0y8; dkim=pass (1024-bit key) header.d=yitter.info header.b=Nu9t/ImI 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 NphrlopHcr4w for ; Wed, 16 Jan 2019 15:10:21 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57216130E46 for ; Wed, 16 Jan 2019 15:10:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 6288BC0633 for ; Wed, 16 Jan 2019 23:09:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1547680189; bh=2zWfERGi6v2JH1TUbuUisF0G1dCqyN5NYLHD4i+M/hs=; h=Date:From:To:Subject:References:In-Reply-To:From; b=UMTrH0y8cRkj6M0mYxIr3kj2jN8zGb5GowrPxzTTFYeicbuB/0MeuMSNYE/eEuAxT KKQZ35O2Z/RGOcz1/VZm0z8yZRFEfWGtlVn7IrBldHB8qE4Q/KY8geIpwcAII+mohJ pul415DHzkGCmDylDR3TtcVZjClEphcJ1ThcuMoo= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVPn37YJVovg for ; Wed, 16 Jan 2019 23:09:48 +0000 (UTC) Date: Wed, 16 Jan 2019 18:09:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1547680188; bh=2zWfERGi6v2JH1TUbuUisF0G1dCqyN5NYLHD4i+M/hs=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Nu9t/ImIkvxvNqRoGqTVp0U0tXIVQPiWlT+foX6QU3fsrmJOnp2kgLsJj18Zl5AVm ArTIA3ojmcZQpkJoQIp11UQuxVJdncH1x00eklOsakvB/Fep/88zAmU4UbiyDJbHvK MoVEzF7wNDq3JbHZRzcf/jlWQWVkmK95Lq9lzdOU= From: Andrew Sullivan To: dmarc@ietf.org Message-ID: <20190116230946.tkfqcdmiawm4a3bu@mx4.yitter.info> References: <20190116005804.A0A80200CACDA9@ary.qy> <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 23:10:23 -0000 Hi, On Wed, Jan 16, 2019 at 11:34:56AM -0700, Grant Taylor wrote: > > However I feel like rejecting things because of additional white space (in > front of v=...) or the wrong case is being a little bit pedantic. I want to point out, because it's making me extremely itchy, that the DNS itself did this for years. One result is that vendors are about to have a flag day in which a whole bunch of things are deprecated at once in an effort to get rid of a lot of cruft. Vendors are going to have a difficult time rejecting any heuristic improvements if some of them work. Already it is hard for DNS providers to process these records because they're all TXT and the semantics of the RRTYPE say that anything is allowed. So I think stricter implementations overall are probably the better path to interoperability here, even if that hurts in the immediate term. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jan 16 15:47:15 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A40D131227 for ; Wed, 16 Jan 2019 15:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FMOhI_iE9JvH for ; Wed, 16 Jan 2019 15:47:10 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 DA695131126 for ; Wed, 16 Jan 2019 15:47:09 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id q18so8945862wrx.9 for ; Wed, 16 Jan 2019 15:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uvAdhr3rSC02oqIqss1cB3Kx0ROBEr3pUDPJMpD56dE=; b=TmWBeZUTUBr8WZV43Le53ySlpnh8ruCu+8Xg5Sggx8Lp9ypzFHpilmK46rHumnlQo4 s2u6IB6EYk1e5ajvGvuImS1w74aNmRIuPhW3NZNLNFXNu46ZbKfMUSmiRXYeIGPnnPZL 5HIAP7qR+YwgTa9+u41lXC4AqyGd/aQvqLP7eWvZ9XOqe7Itp6fTZ8v/R6iUamJ1rTcT Pq6TC8CuocsNRAQkWQU+DLuCnqug+OVkEbd07nFuTg4vcqTwRpyVvBGrFpS7mZCUkrIM ZxsK+9nb3kleg4jCWSvhZICOnWm1SibjrnQS6ymyZhutsqTB5ggmxeYhiEcu5I0vnTCz UN2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uvAdhr3rSC02oqIqss1cB3Kx0ROBEr3pUDPJMpD56dE=; b=Harm45ZZbffc64memn/QmVmIJRN77TehF1ZPSlJ21SnM0+UBxUG5RVkF6qMSjZW0ss P2STNwSi2IAE/9l9JRqM3xJQJToLHVseOzy2pzKh7RHQY1V/X4+e42la+aGfdCLhkKjK TNrQ80TCFz6KLOGA1HmxtLaucMmADXmA5ObL2XuE8kLlVQIdUhAwzTsiOtxUyAQCGpgA S2AUecUzjDyZ1YP+Bn18xC2s7Iws0c8LBuqv1q2O6tIdev1sclinvSnxFuUM4dPqcXcu f8hhoB9B0jZ0G2c5jmjXFPJOf1BZ8Mc/Syka8uW0HFigkztH5Bis3lkzsbSiR16hzPPH ZmEg== X-Gm-Message-State: AJcUukdoGfUcph9RfGYVpx3zdA0Iq0flTm70RgN+nBUKMRUQqC7lx4ET WJ6s2RAHctedt4fmu88TsDFIvMkEctajXcp5AWMa6w== X-Google-Smtp-Source: ALg8bN5XCxFIGXFfldkxAh45K9QDBC1kBZn5I7IT0yiclVs9kmkBzFlbKjbwVlW09IMWT3bcFmyj9ZRls5kOFeT6u/o= X-Received: by 2002:adf:81c4:: with SMTP id 62mr8913043wra.266.1547682428181; Wed, 16 Jan 2019 15:47:08 -0800 (PST) MIME-Version: 1.0 References: <20190116005804.A0A80200CACDA9@ary.qy> <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> <20190116230946.tkfqcdmiawm4a3bu@mx4.yitter.info> In-Reply-To: <20190116230946.tkfqcdmiawm4a3bu@mx4.yitter.info> From: Dotzero Date: Wed, 16 Jan 2019 18:46:58 -0500 Message-ID: To: Andrew Sullivan Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005b6150057f9be585" Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 23:47:13 -0000 --0000000000005b6150057f9be585 Content-Type: text/plain; charset="UTF-8" +1 Too many times we (collectively) have avoided the short term pain because it is pain, but we have set ourselves up for greater pain at a later point. Part of the problem with ignoring the requirements of a standard is that while interoperability works in most cases, it sets up failure in corner cases and opens up the potential for abuse in ways that are not easily discerned. Michael Hammer On Wed, Jan 16, 2019 at 6:10 PM Andrew Sullivan wrote: > Hi, > > On Wed, Jan 16, 2019 at 11:34:56AM -0700, Grant Taylor wrote: > > > > However I feel like rejecting things because of additional white space > (in > > front of v=...) or the wrong case is being a little bit pedantic. > > I want to point out, because it's making me extremely itchy, that the > DNS itself did this for years. One result is that vendors are about > to have a flag day in which a whole bunch of things are deprecated at > once in an effort to get rid of a lot of cruft. > > Vendors are going to have a difficult time rejecting any heuristic > improvements if some of them work. Already it is hard for DNS > providers to process these records because they're all TXT and the > semantics of the RRTYPE say that anything is allowed. So I think > stricter implementations overall are probably the better path to > interoperability here, even if that hurts in the immediate term. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000005b6150057f9be585 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

Too many times we (collectively) hav= e avoided the short term pain because it is pain, but we have set ourselves= up for greater pain at a later point. Part of the problem with ignoring th= e requirements of a standard is that while interoperability works in most c= ases, it sets up failure in corner cases and opens up the potential for abu= se in ways that are not easily discerned.

Michael Ha= mmer

On We= d, Jan 16, 2019 at 6:10 PM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,

On Wed, Jan 16, 2019 at 11:34:56AM -0700, Grant Taylor wrote:
>
> However I feel like rejecting things because of additional white space= (in
> front of v=3D...) or the wrong case is being a little bit pedantic.
I want to point out, because it's making me extremely itchy, that the DNS itself did this for years.=C2=A0 One result is that vendors are about to have a flag day in which a whole bunch of things are deprecated at
once in an effort to get rid of a lot of cruft.

Vendors are going to have a difficult time rejecting any heuristic
improvements if some of them work.=C2=A0 Already it is hard for DNS
providers to process these records because they're all TXT and the
semantics of the RRTYPE say that anything is allowed.=C2=A0 So I think
stricter implementations overall are probably the better path to
interoperability here, even if that hurts in the immediate term.

A

--
Andrew Sullivan
ajs@anvilwalrus= den.com

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000005b6150057f9be585-- From nobody Wed Jan 16 15:56:11 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E860131227 for ; Wed, 16 Jan 2019 15:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 11RsgWWfMlOv for ; Wed, 16 Jan 2019 15:56:07 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 EDB1A130F0F for ; Wed, 16 Jan 2019 15:56:06 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id a8so6356230lfk.5 for ; Wed, 16 Jan 2019 15:56:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iXp7L6Slier1aS08Qj7qsSZ+w59BKiJ6xoKd56m92po=; b=M2FGpljOfl53FIPgV1eAZyN3UXuohlcy6IpOFIun14NdJz5nLUzsr9oVIYAuIT0dR/ br217UDLdiYEKIJl8v3X0TFGpUPDumMe0olPTtjKr/GKQ4rEZIemBjq7XeQ4XPesWfVF 64JfMAEiiKE1yqTSlM2tsV2cFCIcgDkqcvXqaHgT3Ap9aTPj3v1xYxQg47olo2i6WCjz PcBBrqriDBEvFhbPXYAR8N+fuI2PKquX17AwYRMxF8Lrh527Bk7VEcIc8fzUtm1IkFJf ierFvPtS7xy2gGzr5Udt6SgAiskDDXuedNYIe2wIV4emgavbbMvH/WRfJvj4YmbTwaw0 W7sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iXp7L6Slier1aS08Qj7qsSZ+w59BKiJ6xoKd56m92po=; b=h3l+gfMu2kZmiZ9PI1uPPalUTJ77PoGeu/agui/C9zMauh8ji4sZWRl4b4DduppgZu 6+JPAM9ozQ5aStMww5MBTqO2zZmkLfpaPiqNKvBTfziH0CJeYue4FAVmbiJz6sK5+mNX EzWAsOyrGyxmqQs6g+e8NtB5lIu03Z5EV+XMkHMdqsj/DabArnjeVh8jB4Z4g7RBvnw5 Q+C28m0LfnVYHEnconHsxG+zCJtMeHhK5DfJMJOXTkIxfbQMIdyfzmmDdjM44s1buVL+ rVg4EbvztC1+Gq27SFXbngfGc2+5iqKaQyV4ePu6iixYdUSIGvkRpMYG4XMolpiR7RTD +JvA== X-Gm-Message-State: AJcUukcTcZnj7MYTVW1J2ayOzwKYvX12iKU+iNgYu9jndSWMAGsLGl9T HRGTtmyhBtUqHSLegxIc7/KLHkkVIkBVPXsU7Qna4hR5 X-Google-Smtp-Source: ALg8bN5L67M6pPLjIB/IzVqmOW17RXr2JOqz7dkXZUmXrbyldXVCq/AIhX3Ehu++FQPCUqKSOED1LJe81kI+ls4JBMg= X-Received: by 2002:ac2:4116:: with SMTP id b22mr9023330lfi.19.1547682964592; Wed, 16 Jan 2019 15:56:04 -0800 (PST) MIME-Version: 1.0 References: <20190116005804.A0A80200CACDA9@ary.qy> <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> <20190116230946.tkfqcdmiawm4a3bu@mx4.yitter.info> In-Reply-To: From: "Peter M. Goldstein" Date: Wed, 16 Jan 2019 15:55:53 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000545e4d057f9c0592" Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 23:56:10 -0000 --000000000000545e4d057f9c0592 Content-Type: text/plain; charset="UTF-8" +1 I concur with Mike and Andrew. There's no no reason to ignore this element of the standard because there's no real barrier (other than lack of attention to the spec) preventing implementors from doing this correctly. And all we'd be doing is pushing the burden of handling ambiguity to the receivers. Avoiding ambiguity is important for avoiding failure in interoperability. And to Dave's point, this item (and others like it) essentially serves as a "No Brown M&Ms" clause - https://www.npr.org/sections/therecord/2012/02/14/146880432/the-truth-about-van-halen-and-those-brown-m-ms . If you're implementing a spec, it's important to pay attention to the details. Best, Peter On Wed, Jan 16, 2019 at 3:47 PM Dotzero wrote: > +1 > > Too many times we (collectively) have avoided the short term pain because > it is pain, but we have set ourselves up for greater pain at a later point. > Part of the problem with ignoring the requirements of a standard is that > while interoperability works in most cases, it sets up failure in corner > cases and opens up the potential for abuse in ways that are not easily > discerned. > > Michael Hammer > > On Wed, Jan 16, 2019 at 6:10 PM Andrew Sullivan > wrote: > >> Hi, >> >> On Wed, Jan 16, 2019 at 11:34:56AM -0700, Grant Taylor wrote: >> > >> > However I feel like rejecting things because of additional white space >> (in >> > front of v=...) or the wrong case is being a little bit pedantic. >> >> I want to point out, because it's making me extremely itchy, that the >> DNS itself did this for years. One result is that vendors are about >> to have a flag day in which a whole bunch of things are deprecated at >> once in an effort to get rid of a lot of cruft. >> >> Vendors are going to have a difficult time rejecting any heuristic >> improvements if some of them work. Already it is hard for DNS >> providers to process these records because they're all TXT and the >> semantics of the RRTYPE say that anything is allowed. So I think >> stricter implementations overall are probably the better path to >> interoperability here, even if that hurts in the immediate term. >> >> A >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000545e4d057f9c0592 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

I concur with Mike and Andrew.=C2=A0 There's no no reaso= n to ignore this element of the standard because there's no real barrie= r (other than lack of attention to the spec) preventing implementors from d= oing this correctly.=C2=A0 And all we'd be doing is pushing the burden = of handling ambiguity to the receivers.

Avoiding ambigui= ty is important for avoiding failure in interoperability.=C2=A0 And to Dave= 's point, this item (and others like it) essentially serves as a "= No Brown M&Ms" clause -=C2=A0https://www.npr.org/sections/therecord/2012/02/14/146880432/the-trut= h-about-van-halen-and-those-brown-m-ms .=C2=A0 If you're implementi= ng a spec, it's important to pay attention to the details.
Best,

Peter

On Wed, Jan 16, 2019 at 3:47 PM Dot= zero <dotzero@gmail.com> wro= te:
+1

Too many times we (collectively) have avoided th= e short term pain because it is pain, but we have set ourselves up for grea= ter pain at a later point. Part of the problem with ignoring the requiremen= ts of a standard is that while interoperability works in most cases, it set= s up failure in corner cases and opens up the potential for abuse in ways t= hat are not easily discerned.

Michael Hammer

On Wed, Jan 16, 2= 019 at 6:10 PM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,

On Wed, Jan 16, 2019 at 11:34:56AM -0700, Grant Taylor wrote:
>
> However I feel like rejecting things because of additional white space= (in
> front of v=3D...) or the wrong case is being a little bit pedantic.
I want to point out, because it's making me extremely itchy, that the DNS itself did this for years.=C2=A0 One result is that vendors are about to have a flag day in which a whole bunch of things are deprecated at
once in an effort to get rid of a lot of cruft.

Vendors are going to have a difficult time rejecting any heuristic
improvements if some of them work.=C2=A0 Already it is hard for DNS
providers to process these records because they're all TXT and the
semantics of the RRTYPE say that anything is allowed.=C2=A0 So I think
stricter implementations overall are probably the better path to
interoperability here, even if that hurts in the immediate term.

A

--
Andrew Sullivan
ajs@anvilwalrus= den.com

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000545e4d057f9c0592-- From nobody Thu Jan 17 04:59:49 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6761F124BF6 for ; Thu, 17 Jan 2019 04:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 wUK88XeTCNfY for ; Thu, 17 Jan 2019 04:59:47 -0800 (PST) Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 5938912426E for ; Thu, 17 Jan 2019 04:59:47 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R23UAVRQE800GT75@mauve.mrochek.com> for dmarc@ietf.org; Thu, 17 Jan 2019 04:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547729685; bh=7uxN12LiOpMVdv/ZcLND4Qq6s0Cy5XyaYtqrIVagsFc=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=kjGbW8Q2XnG96qMKkS6kbSMTmmvS9mvFhqlkJYoI7ftLG3ymWKDfSG9RRugsXSBvs 9pb/uKd2E8F1YE3/H/YuSS5qKJw01lCsCUn23Tu+T1g0zBFWD7l8WpKNQAdMH2mV7i D2xxG06ihLWKU7OLYHdCIg6x2GJcxzswhVn/hwN0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Thu, 17 Jan 2019 04:54:41 -0800 (PST) From: ned+dmarc@mrochek.com Cc: John Levine , dmarc@ietf.org Message-id: <01R23UAU5E3C00004L@mauve.mrochek.com> Date: Thu, 17 Jan 2019 04:42:26 -0800 (PST) In-reply-to: "Your message dated Wed, 16 Jan 2019 12:00:13 -0800" <8217a12c-385b-ab11-0453-b1be185f1701@gmail.com> References: <20190116191824.0E64F200CC135A@ary.qy> <8217a12c-385b-ab11-0453-b1be185f1701@gmail.com> To: Dave Crocker Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jan 2019 12:59:48 -0000 > On 1/16/2019 11:18 AM, John Levine wrote: > > Remember, that if your software rewrites an invalid record into a > > correct one, you are trying to read the mind of the person who wrote > > the misformed record. > To emphasize a point you made earlier: There are many, small > adjustments that a receiver might make, with the intention of operating > more robustly. The current examples certainly quality as small and > seemingly innocuous. But the earlier point was that one deviation from > the specification bodes ill for more important questions of conformance... > If they didn't read this part carefully, why believe they read other > parts more carefully? The seemingly innocuous nature of the accomodation is only one of several factors that need to be considered when deciding whether or not to implement these things. Others include, but are not limited to: (0) What are the worst case security considerations? (1) Whether or not the misbehavior is widespread. (2) Is the misbehavior likely to be corrected if you don't accomodate it? (3) What wiil the effect of telling customers experiencing difficulties that it's Someone Else's Problem be? (4) What is the long term impact on your code going to be? All that said, in the present case this appears to be a nobrainer: Since the correct behavior is to ignore malformed records, the security implications may be significant, it is not widespread behavior, it's very likely to be corrected, telling people that banks should get their security right seems like an easy argument to make, and it's a bit of a wart on the code. I'll also note that transmitters as well as receivers can play the accomodatation game, with similar effects: What should be common cases get turned into corner cases, and interoperability suffers as a result. Ned From nobody Thu Jan 17 05:07:14 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B231612426E for ; Thu, 17 Jan 2019 05:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 M5vRi9mL0Y1i for ; Thu, 17 Jan 2019 05:07:11 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (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 52000124BF6 for ; Thu, 17 Jan 2019 05:07:11 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R23UK29VR400GOXL@mauve.mrochek.com> for dmarc@ietf.org; Thu, 17 Jan 2019 05:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547730128; bh=VlM7UvfSy25nI6xQ3fNc2A+WmqnCom4EOxqbyY9p38w=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=dw+rmy4gIb95/XzLr/nIvnNNfY1cUWmq1eVYduB2er9OyFK7PfTU3pFuern1nFiWT BeoCCbjGoycIt/mI2xPjxX556fn/hffJPUongZ/fONBpMkRSfcOFskGmeZly0QdQ7T M1JVzExIz7XggQ+Kx6A3+kKqbz8ATAtywFus0R3k= 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 <01R1N39ADWKW00004L@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Thu, 17 Jan 2019 05:02:05 -0800 (PST) From: ned+dmarc@mrochek.com Cc: Grant Taylor , dmarc@ietf.org Message-id: <01R23UK0KSK800004L@mauve.mrochek.com> Date: Thu, 17 Jan 2019 05:00:01 -0800 (PST) In-reply-to: "Your message dated Thu, 17 Jan 2019 00:50:07 +0300" <132ef6dc-86f0-3283-71fb-ea80d8800428@corp.mail.ru> References: <20190116005804.A0A80200CACDA9@ary.qy> <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> <132ef6dc-86f0-3283-71fb-ea80d8800428@corp.mail.ru> To: Vladimir Dubrovin Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jan 2019 13:07:13 -0000 > I believe in the situation where standard is absolutely clear like this, > any implementer must strictly follow the standard. Otherwise, it can > lead to unpredictable behavior and security issues. Sorry, I meant to mention this in my previous response. It's one thing when there's wiggle-room or lack of clarity in the standard. It's quite another when things are clear, as is the case here. > Example: there are absolutely legal situations where non-trusted or less > privileged side can partially control the name and/or content of the DNS > record. I can provide users or customers with possibility to register a > hostname and TXT record in my zone but I want to prevent them from > corrupting or changing SPF/DMARC/etc policy. I can rely on filtering TXT > record content. Non-standard behavior of DMARC implementation can allow > to bypass this filtering. > While this example doesn't seem realistic, I can demonstrate quite > realistic ones. For example, a minor relaxation for ARC version check > can lead to DKIM signature spoofing, compromising DMARC as a result. For > DMARC DNS record itself, realistic scenario may appear in the future. > We already have a lot of problems in-the-wild because of standards > relaxations, e.g. it's usually possible to bypass DMARC which relies on > RFC5322 via malformed From: due to fact invalid From: header is > generally accepted and parsing From: header for DMARC validation and for > visual representation is usually made by different pieces of code with > different behavior. Exactly. This is a security protocol and there are real security implications of doing stuff like this. Another reason to Just Say No. Ned From nobody Thu Jan 17 08:10:43 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A772C130E83 for ; Thu, 17 Jan 2019 08:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net 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 Qba-8L7T53kk for ; Thu, 17 Jan 2019 08:10:39 -0800 (PST) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (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 47977130E11 for ; Thu, 17 Jan 2019 08:10:39 -0800 (PST) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id x0HGAaii026446 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 17 Jan 2019 10:10:38 -0600 ARC-Filter: OpenARC Filter v0.1.0 tncsrv06.tnetconsulting.net x0HGAaii026446 Authentication-Results: tncsrv06.tnetconsulting.net; arc=none header.d=tnetconsulting.net ARC-Seal: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1547741438; cv=none; b=UF7Imq3yxkBpdr+SHjIBsfx3Z5O8sDfkKMsDjLMWTaSNrAZLfM52eQzvLj0/eLbAGmQpthdu+pDSLT19r+CW2Sy9QtXTeQdIyPHSZXljWTqm9wdL5OUJJK5SRmIww5lLFjENZ6eUxs+lQUK7vcUQBHYQhcYw/EFQk2oswRiJblE= ARC-Message-Signature: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1547741438; c=relaxed/simple; bh=M5KhTEQP8DTTxXsg3VoWicLV3Mnh8Y6kxIUBJJxgk5g=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type; b=Mqa5UzT5Its7qjf02dG44opgOU8E3ib2zciCnY5wiZMBgXEaOKvDiSFVQTn+2e7p5jP1mS/6s5cJtbXiuUhZ1d4LKC1yvYPqWTKV/warUuzL0PHLrdhv2X/wbmSLVUYSoT2mh+C9odIZMQKGEShCwEL/P0Zb7uvFC6m0pBjNvZQ= ARC-Authentication-Results: i=1; tncsrv06.tnetconsulting.net; none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1547741438; bh=M5KhTEQP8DTTxXsg3VoWicLV3Mnh8Y6kxIUBJJxgk5g=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=B/fpIYt6ABY0/aUt872+R//GgkPVWMFJO4OIGFfMBGPZ98Mf7MYJ/4lzAHQdcGlne bpqoWUmGCCbSf03Mm20M9dcRJlbDQxMDP5W9ZyBcClsg20ZB2YyvSmZM54D8xKAgv7 oyRXswK2R0mZuO0qE2HEfXppnhwj5gGSi+tDAVRw= To: dmarc@ietf.org References: <20190116005804.A0A80200CACDA9@ary.qy> <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> From: Grant Taylor Organization: TNet Consulting Message-ID: <43ae9a84-75e3-1292-d3f4-68f3a74458a3@spamtrap.tnetconsulting.net> Date: Thu, 17 Jan 2019 09:10:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <11a5d635-a16b-17b9-0ba6-7713b8f169e2@spamtrap.tnetconsulting.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090504050704080902080409" Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jan 2019 16:10:42 -0000 This is a cryptographically signed message in MIME format. --------------ms090504050704080902080409 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01/16/2019 11:34 AM, Grant Taylor wrote: > However I feel like rejecting things because of additional white space = > (in front of v=3D...) or the wrong case is being a little bit pedantic.= >=20 > Rather, I think that if removing a spurious / leading space or folding = > case causes the DMARC record to be valid, it behooves us to tolerate=20 > such minor errors. >=20 > I don't want to be so pedantic that people push back on adopting what I= =20 > (and I assume others) think is a good technology. >=20 > Is doing so against the letter of the specification, absolutely.=C2=A0 = Is it=20 > within the spirit of the specification, I think so. I've seen a number of intriguing, if not compelling, replies in this=20 thread. Some of which have changed my thoughts some. I now concede accommodating a leading space is questionable. However I still feel like /requiring/ exact case is contrary to the idea = of "Be liberal in what you accept and conservative in what you send.". I don't see any security implications in accepting the following: dmarc-version =3D ("v" / "V") *WSP "=3D" *WSP ("D" / "d") ("M" / "m") ("A= " /=20 "a") ("R" / "r") ("C" / "c") "1" I agree that this is contrary to the letter of the specification.=20 However I think it is completely within the spirit. Especially when=20 dealing with DNS data which is inherently / invariable human entered. I don't (yet) see any security implications of accepting improper case=20 record data for the dmarc-version *IF* that is the /only/ TXT record at=20 a given QName that is DMARC related. - If there are multiple DMARC=20 records, especially if they are conflicting, strictly adhere to the=20 standard. I'm curious if anyone sees any security implications with the above=20 dmarc-version. This is me trying to learn and understand. I'm not trying to argue one=20 way or the other. --=20 Grant. . . . unix || die --------------ms090504050704080902080409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Cy4wggVAMIIEKKADAgECAhEA01fiRe1k2R6LEQCcImIMYTANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgxMTE4MDAw MDAwWhcNMTkxMTE4MjM1OTU5WjArMSkwJwYJKoZIhvcNAQkBFhpndGF5bG9yQHRuZXRjb25z dWx0aW5nLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANgOhvncDgc4KAlD +pyhFpw6wCfeERlSOAXowjdTjlOR2zcIgzL0TM9A+hkSv2wsVh6fn6VvHGxKrLemReiGd7fQ 15Y9J/pxKOmShkw9DDtFsa18ozydp95X2IuzY8Z2JukxouqrfpSH4fOrrHLkOgvlFG4xaQHW 0KB8xUP5DFWyyZM5QCdq278GSJ5pUd+B6qmzwHESNF6syyvgLppXkFatLTz8pWf6eEngDA0Y 3fQ3Q2gnbgpryRhVQMa1GjQJ7LDroUGQhX2zBWePW+sShiTwo8jADYKsbgSGtvZ/42A8zxyg s9YZMHQoCeeuLNuX/MBp9rCTl5nlzP3jGWQTC5ECAwEAAaOCAfAwggHsMB8GA1UdIwQYMBaA FIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQg2PeEKxHWd4FaHe0T+gqAOWkC1jAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRT MFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29t b2RvY2EuY29tMCUGA1UdEQQeMByBGmd0YXlsb3JAdG5ldGNvbnN1bHRpbmcubmV0MA0GCSqG SIb3DQEBCwUAA4IBAQCPxlHHG57PA5GUYlQuC8VHB7TcMQeEJKnB/S+bamyrck4vpIEaF9rG EM+OnAQsJzSkSVHD2707jxh1ng0jrsH2+F9qNGTpCksXo0fMqm4tf28Ag092+CZ5sfdjVZ4E ELG4xNhFZF9/aFaAY7RIeJ89Vvn6s6BnKsaAPjVB/sO+5gIm0BIeoVauq71ue6jS7o2Jn94o BuAhjuh34gk/Wxzcku96MLmEwCY63GWWKVRYbqrDhqROmnQPdyrDYrU8uD0vb4SAdpSKfRqO DrerlQgX3euyYqcnVJSA8Ec+NdiJrGKXW76C7DrTi7IxDgjIHL+DPyFgtj+p6wYOEkYJwKtp MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBS U0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpY PpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1 wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5 5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP 1cHWse9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5 LFLG3yQK+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy 1DAdBgNVHQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0 dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHEGCCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJ CAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/h k6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWl nhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNm NppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tU U1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR 6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ 16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8ao rYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5 v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfK ehIxggQ4MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx PTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQDTV+JF7WTZHosRAJwiYgxhMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTAxMTcxNjEwMzZaMC8GCSqG SIb3DQEJBDEiBCAif5D/35t/XBovoxOoBiaUIfg9j1C/NWwLnISbf7T9gzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEE AYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0 ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYD VQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEA01fiRe1k2R6LEQCcImIMYTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA01fiRe1k2R6LEQCcImIM YTANBgkqhkiG9w0BAQEFAASCAQAf5x9289/zOOy9F/hJmcs4jQhUpQ+yynNYbkT9nc7nT/t6 9zhUVTslQw9iQHKSVA3Dp+zY8xM9erUa9QtSKE0k3aYhkGBR/rISsIVfoq0zswSVJ0Il+ZET K5tUnKJQ/R3RktMGQjQpL/FD1aY8tUGl7A3Y2T7Wtmx5FpTiJRkvtQGOJXfT7urhrPo7lJWg 6hn+VhQjrOHjK5IJCHq99nBseLYcagJCq1sPbY2naeYh/NXigUHfBTKOn6czNEtBtGRbvfL5 ivQw9sqCE4u5VujbIMyq80D8j+Ab4OLBp7OxBO0SlIbdR6bPeOG8Qig24Ikj1VEW9KYDFq06 3oakKAbDAAAAAAAA --------------ms090504050704080902080409-- From nobody Thu Jan 17 08:53:22 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1442130EAB for ; Thu, 17 Jan 2019 08:53:21 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=DPjAo8/o; dkim=pass (1536-bit key) header.d=taugh.com header.b=aABF58UO 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 1ZHm1YSUdV1F for ; Thu, 17 Jan 2019 08:53:19 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 96312130EA0 for ; Thu, 17 Jan 2019 08:53:19 -0800 (PST) Received: (qmail 54548 invoked from network); 17 Jan 2019 16:53:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d512.5c40b2fe.k1901; bh=VFos/77HqdthkwKEjr9Qtf6cm+KEsA2+z9Rqv+pDGYw=; b=DPjAo8/o3mU30FnFUFwk70GpJouY+EK/WiQzbDfKJxLYKXsGhnd21LP0Jya9hCGni83eeWdVgOJhdeZ56sYF9AKm7EOj80qawSqOeUgf0df7PYxgvuV1YUSnlhnM86fJGvu5jwlEV7RZLAQ13di6yfSz7Jr13bU5P4/rABy65+q/1C1YfIw2/+bzVbDEKrbFQ5KI3MlTh5YISxzz74EOouOgm09KdnO49GD9j5PBvE3qXiubCpJ8RmffPgfnKp3k DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d512.5c40b2fe.k1901; bh=VFos/77HqdthkwKEjr9Qtf6cm+KEsA2+z9Rqv+pDGYw=; b=aABF58UODIySn/D9F68rtXwiVQFK16L67s7W3CU1sYHKxJOjE4R7NZFHvJF/khqqWiGoyV2bg0nTFLfQafN4nbk6m5Owpv9O/WRhF3pL1lTLZ0fht9B1h0DHROEkfE/F3T1z8+/q0B/XuuzeQcbGkacYtgUeBOgbB972IZwdDA5bhsYnWIPRMVWJfC5d00E4rBbNSdu2XPpe7MEzF32U3w7qxnslwI8GvFQWTn7+85MCwaUUVig4aLF5x6X5DI1+ Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 17 Jan 2019 16:53:18 -0000 Received: by ary.qy (Postfix, from userid 501) id E79D7200CD8A31; Thu, 17 Jan 2019 11:53:17 -0500 (EST) Date: 17 Jan 2019 11:53:17 -0500 Message-Id: <20190117165317.E79D7200CD8A31@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: gtaylor@tnetconsulting.net In-Reply-To: <43ae9a84-75e3-1292-d3f4-68f3a74458a3@spamtrap.tnetconsulting.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jan 2019 16:53:22 -0000 In article <43ae9a84-75e3-1292-d3f4-68f3a74458a3@spamtrap.tnetconsulting.net> you write: >However I still feel like /requiring/ exact case is contrary to the idea >of "Be liberal in what you accept and conservative in what you send.". Yup. See https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance a/k/a "Postel was wrong". >I don't see any security implications in accepting the following: > >dmarc-version = ("v" / "V") *WSP "=" *WSP ("D" / "d") ("M" / "m") ("A" / >"a") ("R" / "r") ("C" / "c") "1" Please see the previous several dozen messages, particularly the one about the brown M&M's. If you know that someone didn't read the spec, you can only guess what else they got wrong, and you're not doing anyone a favor by doing that. >I agree that this is contrary to the letter of the specification. >However I think it is completely within the spirit. Especially when >dealing with DNS data which is inherently / invariable human entered. Once again, please try not to assume that everyone's experience is the same as yours. On my DNS server, the DMARC records are generated automatically when I add a new mail domain and their syntax is correct. (Or every DMARC record is wrong, but I would notice that pretty soon.) On the large systems which these days host most mail it's hard to see how they could do it manually. R's, John From nobody Thu Jan 17 09:54:59 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9B012426E for ; Thu, 17 Jan 2019 09:54:55 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XhKOOEFfLQ5L for ; Thu, 17 Jan 2019 09:54:53 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 F2DC5130EB5 for ; Thu, 17 Jan 2019 09:54:52 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id u16so11898924otk.8 for ; Thu, 17 Jan 2019 09:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LJRfeZn6lp4Tyg6JVowiyeoP9TouTnA35/avLWEXCBI=; b=ou1RKz/3eXUkLKEhQ3DAgW6E4W+eaa98S7W7x2G3X8M3YfzTfp4FGCctukTpbxacC8 Cv6jT9g53P4o5TqGI9XdM+rjuM2ePQG4gHe+c+Zxmdxcljg5ceqnxs56svOZyat1FR1Q pHAxWnDnRj7hZJL6seoH5dp9ZyFKvcaKvvR3Jn0ywE7in64HFlB8Wuuyy0COGnRY+xJN fh9q9gfc5mzHTt5nBvU2aVi+M8MjdWE3lNmuiFoyUkKueVynQqmP0dW3bJ4TYLwd/RPM Se+5vjty9rS/SZxFODPWlPUFGU2xc7zEJa3LwJzuyQ4WIMDZlOfNHfMDAfBpb7HHnOyR rQXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LJRfeZn6lp4Tyg6JVowiyeoP9TouTnA35/avLWEXCBI=; b=b4c4wWFlCa9Y3Aef5s+yW1fQFS/9ELZtMBdaWuO4F9mmOMPxoPoreh1sIMy7+B0SDl c+Joln4Xz0EyAX4DWy82O1X+iToTcWByLZy6dCR67XW895l/ACnnt7BvfnyCrR/Bz869 0mQZKQO+LbRQsCJf0Owmr7QPOULm4COHpFUNeRQ1X4PmcHrXYbhCsO5vh5qtjEu4znes IQfx/OEdApyETlHpwN/rlCkUVtUpq5UyzvQcQPTBa7rVg1cceNcpz3JUIRH7dP6C7wbe srhRlu5NBHWFmA9KMiOxxnNq/M7fEkW5FRKqJryQ61+B+71tR8aPKxJpMhAbVqKndrpm DYnQ== X-Gm-Message-State: AJcUukfU4xYT34eUkz213fO+FUYaCQNs8G2Q8D/hmGwkmeuJrJsG9luW xwJzWDFyDi2MUKd6CFnCX7YRqX7g X-Google-Smtp-Source: ALg8bN7BIVB3zqoL7vbMdY/88eGRZDN0fyEW9qNAV8aO6PBhUvTvwJx9iWeFhBKAmAI0M2UvtQa/8Q== X-Received: by 2002:a9d:3e4a:: with SMTP id h10mr9999191otg.74.1547747692073; Thu, 17 Jan 2019 09:54:52 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net. [76.218.8.128]) by smtp.gmail.com with ESMTPSA id h24sm914322otm.72.2019.01.17.09.54.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Jan 2019 09:54:51 -0800 (PST) To: John Levine , dmarc@ietf.org Cc: gtaylor@tnetconsulting.net References: <20190117165317.E79D7200CD8A31@ary.qy> From: Dave Crocker Message-ID: Date: Thu, 17 Jan 2019 09:54:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190117165317.E79D7200CD8A31@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jan 2019 17:54:56 -0000 On 1/17/2019 8:53 AM, John Levine wrote: > In article<43ae9a84-75e3-1292-d3f4-68f3a74458a3@spamtrap.tnetconsulting.net > you write: >> However I still feel like/requiring/ exact case is contrary to the idea >> of "Be liberal in what you accept and conservative in what you send.". > Yup. See > > https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance > > a/k/a "Postel was wrong". The common interpretation of Postel's dictum is to use it as an excuse to ignore specification details. That was not what he intended. Rather, he intended its use in the way that Ned invoked: > On 1/17/2019 5:00 AM, ned+dmarc@mrochek.com wrote: >> Sorry, I meant to mention this in my previous response. It's one thing >> when there's wiggle-room or lack of clarity in the standard. It's quite >> another when things are clear, as is the case here. Be liberal when the specification leaves room for doubt. Not when it doesn't. d/ ps. I don't know why the spec, here, demands case sensitivity but it is quite clear that it does. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jan 17 10:50:24 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B9C130E72 for ; Thu, 17 Jan 2019 10:50:22 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=F69AeyUX; dkim=pass (1536-bit key) header.d=taugh.com header.b=GZTZT+gj 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 ib1earfhNBHU for ; Thu, 17 Jan 2019 10:50:21 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 B8C891288BD for ; Thu, 17 Jan 2019 10:50:20 -0800 (PST) Received: (qmail 14430 invoked from network); 17 Jan 2019 18:50:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=385b.5c40ce6b.k1901; bh=DVFEqCQSqF1QrxKAQ2tCMgzIpd5CONl/6+jm1Tq5L1w=; b=F69AeyUXbqBc0kFgEFi6An4fAyQcQp/KwA0G9ijf4Gz1OdGKnrrntd16WgeVksp8IVQLVNWmzFCghH9m1ta8bsFbVTjN1C+D/DlvANFAEh3FQLH7gxhoEimUtgSZEs3aaTPojppOfte4LSlmGN+APFg14GKj9Jl1K2oh+BVHchTenGXEiFvcmt/ebjBheW7f36r0Xp1p+RouV8IpI49OwWprdGbPR6eu+k9jdXg/5Fy2v1dWHwjwjl/6XOzBvPMy DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=385b.5c40ce6b.k1901; bh=DVFEqCQSqF1QrxKAQ2tCMgzIpd5CONl/6+jm1Tq5L1w=; b=GZTZT+gj6yvbD8IbDEOPvA63kBa40eW9GdsTpPCzNOuv18x96FmtLmsQg4y9N2y+A5Ev9UhTC35DFRJOeg+OFnytGaJDV7PM2W4V2rjTEnLLy6WQl90B2wkJIt7oQkwB4zxn1R0Oto/CyUJLyejziXqiDe1lYtLIpbMRDoSD/sphzMR40n4I7o3A/a2QcSi5gij3/4FPifJZoRC4NjT0dIr4iK9U0L+CMFt2wnpzrQlNisM/743GeKEGJSl7Dnm/ Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 17 Jan 2019 18:50:19 -0000 Received: by ary.qy (Postfix, from userid 501) id 16153200CDA113; Thu, 17 Jan 2019 13:50:18 -0500 (EST) Date: 17 Jan 2019 13:50:18 -0500 Message-Id: <20190117185019.16153200CDA113@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <3104294.rU99Ex2XNH@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jan 2019 18:50:23 -0000 In article <3104294.rU99Ex2XNH@kitterma-e6430> you write: >My understanding is that, since, as you say, PSOs (like .bank) have a pre- >existing relationship with their registrants, they don't need PSD DMARC to >audit their registrant's policies. For an entity like that, it offers the >chance to get feedback on other, presumably non-existent, domains so as to >better understand abuse patterns within the PSD they manage. It also gives >them a mechanism to express a reject policy for those domains, which does not >currently exist. This may help improve rejection of cousin domains by >receivers. > >For single entity PSDs, like for a very large Internet company that is, >conveniently not named after a large South American rain forest (so they can >get it registered), it offers other advantages. In cases like this, the PSD >operates like an organizational domain except for the fact that in the current >DMARC instantiation, their record won't work for subdomains. PSD DMARC would >enable '.example' to publish a single record for all lower level entries in >the zone. That all seems reasonable but it still feels like a lot of mechanism for marginial benefit, particularly since we have no clue who's going to run it if we can't foist it off on Mozilla. I wonder if there's any way to get the PSL to tag vanity TLDs. R's, John From nobody Thu Jan 17 11:25:57 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420D3130E94 for ; Thu, 17 Jan 2019 11:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com 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 fDsNznx3nmDz for ; Thu, 17 Jan 2019 11:25:51 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::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 98188130E93 for ; Thu, 17 Jan 2019 11:25:51 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id y23so7092654oia.4 for ; Thu, 17 Jan 2019 11:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SXNNfrA3f05P/V1KMh8Tc68pz06Opu9MLvoCGvIFViU=; b=EL9KDB0Q8xDuNtieyoUjwwVV95qgY3U2QbACIrw2iKRCoX0eQaQqfHgRy73Wei0Kxq 0tFEa1w8cvilirQDJ10RHtfDPeSGSVm8xMwbqwACw14o2JgvxvVy9P0w9kifvL0A5GOz mkRynfWWKj8HEG6ypu8kytk6TuGYt64mkPK26V4rPaTmxYTVwneQyqqQs1GLVQt78Id0 9GcAdCGCBKf8BufwZh4w9gkSKs5K2bFtYN9wukmYhR32qIv/N6jxd7g0fNybmRNRuZKt Ut4knMbhkqqaZHRwopaAcbSEeDtB45xbc63RV2yrQfJLmw5j505DSvSPuDJ7GS+W5YKo ih/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SXNNfrA3f05P/V1KMh8Tc68pz06Opu9MLvoCGvIFViU=; b=MWh0f4MbSXalshQYrVIoA25jpEe/sFeKD3y5mP9mV4BQufMy8nxqeZ5RQU2HD7Mbfn MDbzq/K3K5AiHqfqWoteUp2E+BA1+VZ8RWhnbmbX1iF+Gi7jZUNHmvg+kyEopEr2p2jv oIKiggRlfOi6QGMbzSfKetx2NIf8y+UgeGg5SaCEohYOLI0ICHfTLwjckX6DeYSkorbS 8B5Bq8yGv9afY2SkbaXprx6iKXuD4XT+ccQAjS6Jvv9zlt652PEww2rNnrgIn/GBSDBE MzPUtmIZDT7XVTDcDWa6V8w06JSsmYZUWbqby7j0k6C3xmFIdT9aediRfRxSk0y15ud/ WRug== X-Gm-Message-State: AJcUukchjib84l1YdgTLFeRgq6VbZcJJqFGjXhP8R3HoDsQZj2+ff9iq cBZbHDN/MblRuXIoyicmVDR0WLWZWpxLYrMrB6+SqJIQlQs= X-Google-Smtp-Source: ALg8bN5KseS5rQUMWI/hKkmUlktX93LzagqZvqtCycNPIWuj5uZcUR/00nkfAFA+HY6B6UnSUD4Mhq5XE4e0qFDQNIQ= X-Received: by 2002:aca:1918:: with SMTP id l24mr6523463oii.236.1547753150105; Thu, 17 Jan 2019 11:25:50 -0800 (PST) MIME-Version: 1.0 References: <3104294.rU99Ex2XNH@kitterma-e6430> <20190117185019.16153200CDA113@ary.qy> In-Reply-To: <20190117185019.16153200CDA113@ary.qy> From: Seth Blank Date: Thu, 17 Jan 2019 11:25:33 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b6691d057fac5c44" Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jan 2019 19:25:55 -0000 --000000000000b6691d057fac5c44 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 17, 2019 at 10:50 AM John Levine wrote: > I wonder if there's any way to get the PSL to tag vanity TLDs. > I believe a single list is the best long term solution. It just needs the domain and two flags, one for if the domain is a public suffix, and the other is if its a public suffix domain (per this draft). For instance; domain | PS | PSD --------------------------------- .co.uk | true | false .gov.uk | true | true .brand | false | true This seems to adequately cover all uses cases described (with the .co.uk example being the state of everything currently on the PSL), is simple, and in one place. I think the primary question (before we go down the PSL/Mozilla rabbit hole) is what the proper technical solution is - one list, multiple lists, no list. After clarity on that, then we can dig into how and where this thing lives. Seth --000000000000b6691d057fac5c44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 17, 2019 at 10:50 AM John Lev= ine <johnl@taugh.com> wrote:
I wonder if there's any way to get the PSL to tag vanity TLDs.

I believe a single list is the best long term s= olution. It just needs the domain and two flags, one for if the domain is a= public suffix, and the other is if its a public suffix domain (per this dr= aft).

For instance;

domai= n=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | PS | PSD
------------------= ---------------
.co.uk=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| true | false
.gov.uk=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | true | true
.brand=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| false | true
<= br>
This seems to adequately cover all uses cases described (with= the .co.uk example being the state of everyth= ing currently on the PSL), is simple, and in one place.

I think the primary question (before we go down the PSL/Mozilla rabbi= t hole) is what the proper technical solution is - one list, multiple lists= , no list.

After clarity on that, then we can dig = into how and where this thing lives.

Seth

--000000000000b6691d057fac5c44-- From nobody Thu Jan 17 12:41:14 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C7112958B for ; Thu, 17 Jan 2019 12:41:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 qnNcJYFblu9J for ; Thu, 17 Jan 2019 12:41:10 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 EA1DB1271FF for ; Thu, 17 Jan 2019 12:41:09 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id z7so3584488iti.0 for ; Thu, 17 Jan 2019 12:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jp5YVO+6ROXKEf1Cl0cX+DWffOktdYURWj4M121h6Qc=; b=Frh4t/3v6QnX+UjZqlfoOCLgmDro2+mkyzjp1xG6NqdBL6Pjbi/gxyfgm6Qp9X4/6g wj5yUqbj3SnqwrcIlVT4OgINNetf1UHom4j09HF4DLv5kfeVscDH83JrkZR3CFfByEiI Apqg1MoGBtkdm3FJWijR/5hvxf4sc9wLDOGnQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jp5YVO+6ROXKEf1Cl0cX+DWffOktdYURWj4M121h6Qc=; b=VYTBTzMYzOpqpZK4JVhLmzgj6a0kR/zUOOtZTy+zPA3kXbnnmN2xlhWV7/DrhWoUzv Wqgb698z/8GOswwa1sdmRQu3rY1i4VqAsIhdE8y73Njbsu4l9qR/P3rdYKcpDu8jk1Mk nupyVx6FcgW/X/qimrjC9u306ijCNFR9Cttn72RBg+vU/LHWANYDQfOI/3rc70RQ26P+ 6e5KDbLEpj04nXAOA3+BaiTBH1dIM4q3CuG2iEkBtZ/KOTcHuotbcPXfSkBGKDqeIldq CxNkO/+4yt+PCJVYN/mf+W86P7mo0L0TtCJ1dxv8ZssxTmNR1s/DSqd1cW1Rq2P2d3O1 jekA== X-Gm-Message-State: AJcUukcwRlSSnIMyIaTblOxBzDEQ4CoKugXfJcixnYKFIfg41ssvemqQ zuPOz+Rep60qHGX2rp4vT3QapZvBKw9NQTwsDmO7tyBY X-Google-Smtp-Source: ALg8bN6K8hwLjv9uPulDgDbUBR6Hz6ujIcXnxt/7vnWx32vbtBF6mXAZec2Ia72zA7C5FCHdebNbSh2a/hKbjnCFTYY= X-Received: by 2002:a02:818c:: with SMTP id n12mr8825905jag.108.1547757669089; Thu, 17 Jan 2019 12:41:09 -0800 (PST) MIME-Version: 1.0 References: <3104294.rU99Ex2XNH@kitterma-e6430> <20190117185019.16153200CDA113@ary.qy> In-Reply-To: From: Kurt Andersen Date: Thu, 17 Jan 2019 12:40:55 -0800 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000109e59057fad6add" Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jan 2019 20:41:13 -0000 --000000000000109e59057fad6add Content-Type: text/plain; charset="UTF-8" What is the difference between a PS vs a PSD in your statement? For the DNS a record is a record is a record. --Kurt On Thu, Jan 17, 2019, 11:26 Seth Blank On Thu, Jan 17, 2019 at 10:50 AM John Levine wrote: > >> I wonder if there's any way to get the PSL to tag vanity TLDs. >> > > I believe a single list is the best long term solution. It just needs the > domain and two flags, one for if the domain is a public suffix, and the > other is if its a public suffix domain (per this draft). > > For instance; > > domain | PS | PSD > --------------------------------- > .co.uk | true | false > .gov.uk | true | true > .brand | false | true > > This seems to adequately cover all uses cases described (with the .co.uk > example being the state of everything currently on the PSL), is simple, and > in one place. > > I think the primary question (before we go down the PSL/Mozilla rabbit > hole) is what the proper technical solution is - one list, multiple lists, > no list. > > After clarity on that, then we can dig into how and where this thing lives. > > Seth > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000109e59057fad6add Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What is the difference between a PS vs a PSD in your stat= ement? For the DNS a record is a record is a record.

<= /div>
--Kurt

On Thu, Jan 17, 2019, 11:26 Seth Blank <seth@sethblank.com wrote:
On Thu, Jan 17, 2019 at 10= :50 AM John Levine <johnl@taugh.com> wrote:
I wonder if there's any way to get the PSL to tag vanity TLDs.

I believe a single list is the best long term s= olution. It just needs the domain and two flags, one for if the domain is a= public suffix, and the other is if its a public suffix domain (per this dr= aft).

For instance;

domai= n=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | PS | PSD
------------------= ---------------
.co.uk=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| true | = false
.gov.uk=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | true | true
.brand=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| false | true
=
This seems to adequately cover all uses cases described (wit= h the .co.uk<= /a> example being the state of everything currently on the PSL), is simple,= and in one place.


_______________________________________________
dmarc mailing list
dmar= c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000109e59057fad6add-- From nobody Thu Jan 17 12:58:45 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE98130E72 for ; Thu, 17 Jan 2019 12:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com 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 kr3KnoJqmOBV for ; Thu, 17 Jan 2019 12:58:42 -0800 (PST) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) (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 4C16C12958B for ; Thu, 17 Jan 2019 12:58:42 -0800 (PST) Received: by mail-oi1-x241.google.com with SMTP id y23so7313649oia.4 for ; Thu, 17 Jan 2019 12:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JFoNjLxFt5nbLmpgijMJ7YX9aYhxYscmyi2NlaqB6WQ=; b=bSsAoMF+QNYJri37szJO72KCp5V3i/8aAf3ISQtVLZuYL0DZNb5SQ0Ci0ZCFGFHb42 8rzdBet7jz98ZFVqsVJf2C0vErEj2PPVv8Q26xQv4XsG3fhsLUruelCtSEvCDu7gJecK mw6cn0X+BqgjqsL69iWfZauPWtOIX2SkUIRgb7/A3On1H/KhpSxErN9hLInnyXEP2sqX sEVS5Pe/gu0vOJdRcKXu+Y30DRMdLMKnhTqjhl7LmB3gHDQa8yI2T5h8bBlSxc7q0Yki KjGrS8S+RiUJ+EvWInUuEdDJOwEtXqjjKJOAGpQTwLrF2qPZwHbeaAbFqo2fQs+S9TeN 58pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JFoNjLxFt5nbLmpgijMJ7YX9aYhxYscmyi2NlaqB6WQ=; b=JCPUivhriqgT/SYHQ4iYx+lMF4Uj+ON6+v9RO0lDwo9JkK3yr5S10oHIfD7QS1ryuu XS5zDT8IG0CT/mMfrLpiEyE9HLRKgwUdcK0ugb666iCqRlaH81SP+u1ScXrlXH83jvdh R/DH9obVEhrDAtW3/MlEZd+ikGupZfJP4Ry1Cm4NsaRrGpZQubhZwwoxOpc5+PSorzO8 j9eB6yMax+zeAOKayf/xawHKSpkyZqRLFjWauiknJ2nHljny9UW1JorNnOziMJKct8PG /lcEmHaLAb4r+2Emqn7pbbAtQBnVcsKZmQUg81xKVYt1AMAiZeJB2d0kRWAxHoxUpdNg BsSQ== X-Gm-Message-State: AJcUukf5JQ8mjzkbzODwWy3fthj1SmEeHX0n7ukdHKfgqwbPd+SRUj36 3SY5I89QV3JTA/BZHfSMtrzcpbZSVVvUGCAK+AZ+qKl+LD4= X-Google-Smtp-Source: ALg8bN5RFB29iwypsblV5pge4YghbCWb3aNJ6XH1t5tsWw7mmisqSdayD+IIqlEh9osdgjimnFhjWR8MMnu012UBPek= X-Received: by 2002:aca:5117:: with SMTP id f23mr4970790oib.72.1547758721253; Thu, 17 Jan 2019 12:58:41 -0800 (PST) MIME-Version: 1.0 References: <3104294.rU99Ex2XNH@kitterma-e6430> <20190117185019.16153200CDA113@ary.qy> In-Reply-To: From: Seth Blank Date: Thu, 17 Jan 2019 12:58:23 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c761a2057fada837" Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jan 2019 20:58:44 -0000 --000000000000c761a2057fada837 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 17, 2019 at 12:41 PM Kurt Andersen wrote: > What is the difference between a PS vs a PSD in your statement? For the > DNS a record is a record is a record. > Specifically, there are some domains (like .brand in my example) that should be capable of being used as an organizational domain but are not public suffixes themselves. This is exactly what "branded PSD" in https://tools.ietf.org/html/draft-ietf-dmarc-psd-01#section-1 refers to. Without this distinction, these domains don't make sense on a list of public suffixes like the PSL. If we're going to have one list that enumerate both public suffixes and public suffix domains, then this distinction is critical for the branded PSD use case. --000000000000c761a2057fada837 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What is t= he difference between a PS vs a PSD in your statement? For the DNS a record= is a record is a record.

Specificall= y, there are some domains (like .brand in my example)=C2=A0that should be c= apable of being used as an organizational domain but are not public suffixe= s themselves. This is exactly what=C2=A0"branded PSD" in https://= tools.ietf.org/html/draft-ietf-dmarc-psd-01#section-1 refers to.
<= div>
Without this distinction, these domains don't make s= ense on a list of public suffixes like the PSL. If we're going to have = one list that enumerate both public suffixes and public suffix domains, the= n this distinction is critical for the branded PSD use case.

=
--000000000000c761a2057fada837-- From nobody Fri Jan 18 01:14:51 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F6713117E for ; Fri, 18 Jan 2019 01:14:49 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=zDL5dnM2; dkim=pass (2048-bit key) header.d=kitterman.com header.b=boY3ALSm 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 hfLMPQ8bkcoO for ; Fri, 18 Jan 2019 01:14:46 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF76131178 for ; Fri, 18 Jan 2019 01:14:46 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1547802883; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=onxHPlvaxZvG/AaR/UKKw/Owsp51gKNGLEltZ8LkAAQ=; b=zDL5dnM2On5vrHpipCJ53iJEEE4xSHeyFST0BXBnSukVniiuiWwemIjv oQM960kbhGSQla7vqx1Yi7/mhcxGAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1547802883; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=onxHPlvaxZvG/AaR/UKKw/Owsp51gKNGLEltZ8LkAAQ=; b=boY3ALSmBHId4qDwLGm3AkL+Xnv6iZ8AYHVxasVWI1Q4AbgCiaWHjzyB WgqyLbNoO35jBZkC35TTWG4ZdPB9jAfEVTCLzWp51wZoE2GU4G/DRPwMO7 CRlEDK95JQLu+ROQtIk0+lYNo3WAeGFs1rvAGXfUZvmkKNR7pBiM8TR/8P z/cAPHP6+58sFpsBqW3+uJSk/PlZY1ixHt52WFywXlp5hZZXnfUXmZp4qH 8emVD+zjsAB+ndGEDhW5gD5ejMGB7QZ1aDPsRUhvVyhgORNdjxhwL7sVvW iymsEgvrTVdAeY0jYRdaVfYynoZbemkXnC10midDFvY82n/a59RC8w== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 421622D4081D for ; Fri, 18 Jan 2019 03:14:43 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 18 Jan 2019 04:14:42 -0500 Message-ID: <11058591.22vd1BysGP@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20190117185019.16153200CDA113@ary.qy> References: <20190117185019.16153200CDA113@ary.qy> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jan 2019 09:14:49 -0000 On Thursday, January 17, 2019 01:50:18 PM John Levine wrote: > In article <3104294.rU99Ex2XNH@kitterma-e6430> you write: > >My understanding is that, since, as you say, PSOs (like .bank) have a pre- > >existing relationship with their registrants, they don't need PSD DMARC to > >audit their registrant's policies. For an entity like that, it offers the > >chance to get feedback on other, presumably non-existent, domains so as to > >better understand abuse patterns within the PSD they manage. It also gives > >them a mechanism to express a reject policy for those domains, which does > >not currently exist. This may help improve rejection of cousin domains by > >receivers. > > > >For single entity PSDs, like for a very large Internet company that is, > >conveniently not named after a large South American rain forest (so they > >can get it registered), it offers other advantages. In cases like this, > >the PSD operates like an organizational domain except for the fact that in > >the current DMARC instantiation, their record won't work for subdomains. > >PSD DMARC would enable '.example' to publish a single record for all lower > >level entries in the zone. > > That all seems reasonable but it still feels like a lot of mechanism for > marginial benefit, particularly since we have no clue who's going to run it > if we can't foist it off on Mozilla. > > I wonder if there's any way to get the PSL to tag vanity TLDs. There are two parts to the PSL; a section called "ICANN DOMAINS" and another called "PRIVATE DOMAINS". All the TLDs (single user or not) are in the ICANN DOMAINS section. I don't know if it would be enough to have them also listed in PRIVATE DOMAINS. I don't expect they would want to remove them from ICANN DOMAINS, since that's not wrong, it just doesn't fit out use case. It would require some adjustments to the current DMARC algorithm for organizational domain identification. The current process is to take the 2822.From domain and (assuming there is no DMARC record for that domain) look-up in the PSL and reduce the 2822.From domain to the PSL ICANN DOMAIN + one level. If that level has no DMARC record, then the domain does not participate in DMARC. If Mozilla would add these single user TLDs to the PRIVATE DOMAINS section also, we could adjust this slightly and for this use case (which is only one of three in the draft) it would work: After checking PSL ICANN DOMAIN + one level, if there is no DMARC record, then check the PSL PRIVATE DOMAIN list and if the domain is listed there, check for a DMARC record. I don't know that this would violate the sematics of the PSL and they are, in fact, both ICANN domains and private. Based on the description at https://publicsuffix.org/list/ it seems like it might be accepted. Regardless of exactly how we do this for PSD DMARC, it is probably work documenting that for DMARC (the regular kind), only the ICANN domain section of the PSL is used. Does anyone know someone at Mozilla to ask? For the other, non-single user domains, maybe the best we can do is an appendix that describes the characteristics of PSDs for which PSD DMARC checks are suitable and lists our three from the initial registry as examples. Otherwise, I think we need a new list somewhere because those (like .bank) are clearly not private. If IANA is not the right place to host a list, does anyone have any other suggestions for the ones that won't work on the PSL? Scott K From nobody Sun Jan 20 23:26:09 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3DB130F65; Sun, 20 Jan 2019 23:26:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vYXGPJMmekkO; Sun, 20 Jan 2019 23:26:00 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 035B1130F5B; Sun, 20 Jan 2019 23:26:00 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q2-v6so16595580lji.10; Sun, 20 Jan 2019 23:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J3MsZcCM58gXtTFxoo56lwgZGsKANZmPDeerDDKF0OY=; b=Kii20hkIAnMB8/fFF8wom47xlfS5oDVxn66EtZvGyx+WdVmdzvapmFNvZcVKUytZ+A XEa+NZFyajipS6tNDqJ2Dj9B/ipynz9yZ7eXcVL6qfcp2z50phaBmt6XegER2wNBR93h y2rQWe6XmRvhHClAH2UZTiGgOwUsfMhbe6GhNCf7ilSU+zbq1MP2tM4K6vtTaQ8Yva4W PSQUvmcoMmePidcYVD9KCL1JMR6zAgmIuDfGnLLFc/Krzcxv+DR4LVyRL/FfgvhPbuYs uRwDh7gLiss93sxMHXq+R6CjCSsiGJE+GsAKh526DdIOZLoqASEHHMA6KdOtS5YvMJVN WWOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J3MsZcCM58gXtTFxoo56lwgZGsKANZmPDeerDDKF0OY=; b=php8c8APYj4TWes1nNOjKup2HmSZS0VQt4OD/co5+hIjfsZFkchoLyqT5RzbUqRQfM vJVrOEAk2UcG/DKbCwbE5Xf0ux+kojp3aicI+rpPPpRhGEUOok8LVKO4+ndYnNnAh9ne 6I953HGrmxOMaHQDyyICReiqN1Z8nqOf5zPO0+oKmVjvj2XPBKRgJdf80AxxGkoZ01jf BvccuvGJMl0OkIC3kdvrAPrbVMt4kSrC3fEauIV7F9ke13jPglmIKuZOPper1kvEsgG9 r4HPnntrqUK+DtjIxfU0eEIDSD+c4rtWXahfbl07VsIRIokEkxgVjbpDT2a73nTe9/w4 usWg== X-Gm-Message-State: AJcUukdw7ZTOHR7yv+zh69bBL4EAB5Na/apiojoTB6FbKh7xcankr7BO A4/y9j5dj8nteUr/gpC4RrhUhwEDKtt2mOa89D1Pig== X-Google-Smtp-Source: ALg8bN7lceXGtY2KF0psXgIbJQidmxLq9YzpCA4NMDgrGtKGzKlNsholSqCqNrE7iG47FdJIpUinGnsZeCXECIdlQpA= X-Received: by 2002:a2e:750a:: with SMTP id q10-v6mr19074824ljc.39.1548055558091; Sun, 20 Jan 2019 23:25:58 -0800 (PST) MIME-Version: 1.0 References: <154280871768.11502.10059395575461348698.idtracker@ietfa.amsl.com> <20190106172729.GL28515@kduck.kaduk.org> In-Reply-To: <20190106172729.GL28515@kduck.kaduk.org> From: "Murray S. Kucherawy" Date: Mon, 21 Jan 2019 02:25:45 -0500 Message-ID: To: Benjamin Kaduk Cc: The IESG , Tim Draegen , IETF DMARC WG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a1f762057ff2c51f" Archived-At: Subject: Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jan 2019 07:26:02 -0000 --000000000000a1f762057ff2c51f Content-Type: text/plain; charset="UTF-8" On Sun, Jan 6, 2019 at 12:27 PM Benjamin Kaduk wrote: > > Section 2.3 > > > > > > body: Information that was extracted from the body of the message. > > > [...] > > > interest. The "property" is an indication of where within the > > > message body the extracted content was found, and can indicate an > > > offset, identify a MIME part, etc. > > > > > > I'm not seeing where it's specified how the "property" gives an offset. > > > I see other descriptions below about specific header fields and SMTP > > > verbs and such, though. > > > > > > That's text from the 2009 version of this work. Those were speculative > at > > the time and haven't yet materialized, at least not in standardized use. > > Are you proposing to leave the text unchanged regardless? > I know the use case exists, because I wrote that text when I worked for a company that was likely to make use of it, but it appears that hasn't happened in the deployed universe. So now we have a registry entry for the "body" ptype which isn't deprecated, but possibly no live uses of it. The working group didn't discuss taking any action to either "fix" or bolster this, as its focus was elsewhere (specifically the changes needed to support the DMARC/ARC work). I'm inclined to leave it as-is, possibly with a remark capturing what I just said here. If no uses of it appear before someone decides to revise this again, we can formally deprecate it. > Section 3 > > > > > > of the validity of the connection's identity using DNS. It is > > > incumbent upon an agent making use of the reported "iprev" result to > > > understand what exactly that particular verifier is attempting to > > > report. > > > > > > Does that in practice constrain "iprev" usage to within a single ADMD? > > > > > > > I would imagine so. > > This is just the COMMENT section, so do what you will, but I would consider > mentioning this property of "iprev" more explicitly. > Actually, on second thought, it doesn't: ADMD #1 could attach an "iprev" result that ADMD #2 could decide it trusts. That is, sort of, the ARC model -- you decide whose external results you're going to believe. About to post the new version. -MSK --000000000000a1f762057ff2c51f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jan 6, 2019 at 12:27 PM Benjamin = Kaduk <kaduk@mit.edu> wrote:
=
> Section 2.3
> >
> >=C2=A0 =C2=A0 body:=C2=A0 Information that was extracted from the = body of the message.
> > [...]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0interest.=C2=A0 The "property"= ; is an indication of where within the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0message body the extracted content was = found, and can indicate an
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0offset, identify a MIME part, etc.
> >
> > I'm not seeing where it's specified how the "propert= y" gives an offset.
> > I see other descriptions below about specific header fields and S= MTP
> > verbs and such, though.
>
>
> That's text from the 2009 version of this work.=C2=A0 Those were s= peculative at
> the time and haven't yet materialized, at least not in standardize= d use.

Are you proposing to leave the text unchanged regardless?
<= div>
I know the use case exists, because I wrote that text wh= en I worked for a company that was likely to make use of it, but it appears= that hasn't happened in the deployed universe.=C2=A0 So now we have a = registry entry for the "body" ptype which isn't deprecated, b= ut possibly no live uses of it.=C2=A0 The working group didn't discuss = taking any action to either "fix" or bolster this, as its focus w= as elsewhere (specifically the changes needed to support the DMARC/ARC work= ).

I'm inclined to leave it as-is, possibly wi= th a remark capturing what I just said here.=C2=A0 If no uses of it appear = before someone decides to revise this again, we can formally deprecate it.<= /div>

> = Section 3
> >
> >=C2=A0 =C2=A0 of the validity of the connection's identity usi= ng DNS.=C2=A0 It is
> >=C2=A0 =C2=A0 incumbent upon an agent making use of the reported &= quot;iprev" result to
> >=C2=A0 =C2=A0 understand what exactly that particular verifier is = attempting to
> >=C2=A0 =C2=A0 report.
> >
> > Does that in practice constrain "iprev" usage to within= a single ADMD?
> >
>
> I would imagine so.

This is just the COMMENT section, so do what you will, but I would consider=
mentioning this property of "iprev" more explicitly.

Actually, on second thought, it doesn't: ADMD #= 1 could attach an "iprev" result that ADMD #2 could decide it tru= sts.=C2=A0 That is, sort of, the ARC model -- you decide whose external res= ults you're going to believe.
About to post the new version.

-MSK
--000000000000a1f762057ff2c51f-- From nobody Sun Jan 20 23:42:25 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EA9130F83 for ; Sun, 20 Jan 2019 23:42:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qdz65gonRHqE for ; Sun, 20 Jan 2019 23:42:14 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 60192130FDC for ; Sun, 20 Jan 2019 23:42:12 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id p6so14784010lfc.1 for ; Sun, 20 Jan 2019 23:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FNQ4hUaJUvVnSrIJD9rv8qQB0UoNyNaOFYzALe8HlYI=; b=ouObnAD7blq49hPrrrU8QFadR/wQeXeSfdsE4GX0MDwsdWEfwLrOOFg/MgzwDbTNPR DenXnmn5KNXsOCJoZl2Piov7bmgLDOiJH8QkKC2Y1oKOUBiE9ySWLAmPkea6HtYwLXB2 BsSagtmKnSZVCeH2WUZRg35N13MS2r4bkTL3xjMSxF+q9n3we5PlRSh99Gtqn+6tEUYw LKqI/rGJWvLS/tit5c5ZENQK8eMr9lHW7t88fbcpMU5RPcpjluIBzpw5TiseoVgnihhO DJWU8SUdQ0ShNH5L+MdtdiTQaUaeRhbep24PTxs247JN5ezpH+htjr7QjmqCT4VeVB5u 403w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FNQ4hUaJUvVnSrIJD9rv8qQB0UoNyNaOFYzALe8HlYI=; b=f9AexjC6kII57mpT/EAWuuo204gLWWy9CPyrNcdvC1FUWd3R0IEd3nAUnApDDJF5H2 ctw+rn1g/TsUFIOprnqO0nBj+YxbsHUHdqzNL0MDDk1dvQln1fK70/zCSJva8ytFinL9 i6TWk1dgFBBXQ8IyCeNJlrqBo5OpNjbVxsioAd7tN7ENoNt9CHDYhqKKGehP9snCJyxg cOHGGGOQP7Jy76LPnmfLGlQrFKgsDQ5q0P2PIovqdGXpFfDlF+fEwQPuzeU5qvwdwI4A nnKwrWYLp6pTMqWlgdjo/rFAABR9ujgxtJn1stMvU+oDkpyNLwU8wsR70EW11q3pmqyP PBsA== X-Gm-Message-State: AJcUuke5SH34+wzFCIEeJE96AxiUrL/Rcw8HhUGoDJlI1eMxJ5qkwTVJ evGW5dtNy38a2ePc2U3oiSTPD7wdG9HB8ehXjlPHZg== X-Google-Smtp-Source: ALg8bN5xPl9H7081ZpPk3Pp9sl2mQS4Z+vdJ1lXD9y+4E3f5saCkqI/KNlItx0bGfTOO30NQedctCn2mVnPLKuBKp8w= X-Received: by 2002:a19:6f0a:: with SMTP id k10mr17041579lfc.119.1548056530456; Sun, 20 Jan 2019 23:42:10 -0800 (PST) MIME-Version: 1.0 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543613485.3765543.1594837224.1E64FAB8@webmail.messagingengine.com> <12578706.O8KzW9sDEf@kitterma-e6430> In-Reply-To: <12578706.O8KzW9sDEf@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 21 Jan 2019 02:41:58 -0500 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000972090057ff2ff8c" Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jan 2019 07:42:23 -0000 --000000000000972090057ff2ff8c Content-Type: text/plain; charset="UTF-8" On Sun, Jan 6, 2019 at 2:27 AM Scott Kitterman wrote: > Hunk at "page 17, line 44": > > Perhaps another sentence (more for completeness than anything) at the end > of > the new paragraph. Something like, "Additionally, [RFC8463] added a new > signing algorithm in DKIM, ed25519-sha256 and it is also useful to be able > to > distinguish such signatures to identify cryptographic algorithm specific > failures." > > That would also need a new informative reference to RFC 8463. > I'll take Alexey's direction here, but I'm uneasy adding new references and text like this after IESG Review. Hunk at "page 18, line 32": > > "Note that in an EAI-formatted message, the "mailfrom" value can be > expressed > in UTF-8." > > Isn't it more correct to say that the local part of the "mailfrom" value > can > be expressed in UTF-8? The domain part is still a U-label as I understand > it. > The text as written is literally correct since the entire mailfrom is > valid > UTF-8, but I'm afraid it may be misleading. As written, I could see it > causing confusion relative to the guidance in Section 5. > > Hunk at "page 21, line 21": > > Same comment re UTF-8. > > Hunk at "page 22, line 4": > > Someone who has read the VBR RFC recently enough to remember should check > and > see if my UTF-8 comment applies here nor not. I'm not sure either way. > I'm less concerned about making these adjustments since they're just refinements, so, done. -MSK --000000000000972090057ff2ff8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jan 6, 2019 at 2:27 AM Scott Kitt= erman <sklist@kitterman.com&= gt; wrote:
Hunk at "page 17, line 44":

Perhaps another sentence (more for completeness than anything) at the end o= f
the new paragraph.=C2=A0 Something like, "Additionally, [RFC8463] adde= d a new
signing algorithm in DKIM, ed25519-sha256 and it is also useful to be able = to
distinguish such signatures to identify cryptographic algorithm specific failures."

That would also need a new informative reference to RFC 8463.

I'll take Alexey's direction here, but I'= ;m uneasy adding new references and text like this after IESG Review.
=

Hunk at "page 18, line 32":

"Note that in an EAI-formatted message, the "mailfrom" value= can be expressed
in UTF-8."

Isn't it more correct to say that the local part of the "mailfrom&= quot; value can
be expressed in UTF-8?=C2=A0 The domain part is still a U-label as I unders= tand it.=C2=A0
The text as written is literally correct since the entire mailfrom is valid=
UTF-8, but I'm afraid it may be misleading.=C2=A0 As written, I could s= ee it
causing confusion relative to the guidance in Section 5.

Hunk at "page 21, line 21":

Same comment re UTF-8.

Hunk at "page 22, line 4":

Someone who has read the VBR RFC recently enough to remember should check a= nd
see if my UTF-8 comment applies here nor not.=C2=A0 I'm not sure either= way.

I'm less concerned about maki= ng these adjustments since they're just refinements, so, done.

-MSK
--000000000000972090057ff2ff8c-- From nobody Sun Jan 20 23:45:21 2019 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 32AC412D7F8; Sun, 20 Jan 2019 23:45:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154805671014.2130.7090025393754029957@ietfa.amsl.com> Date: Sun, 20 Jan 2019 23:45:10 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jan 2019 07:45:10 -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 WG of the IETF. Title : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-dmarc-rfc7601bis-05.txt Pages : 53 Date : 2019-01-20 Abstract: This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. This document obsoletes [RFC7601]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-rfc7601bis-05 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-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 Mon Jan 21 00:20:20 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF13130FB5 for ; Mon, 21 Jan 2019 00:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Su5f4p2Z; dkim=pass (2048-bit key) header.d=kitterman.com header.b=GwQR+Tmf 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 wX6kC3DF3023 for ; Mon, 21 Jan 2019 00:20:17 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C78130F2D for ; Mon, 21 Jan 2019 00:20:17 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1548058812; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ZxU7UQbiBjDWTj6i7H0P1jq3/isxGf7MZssTewJ4ZLg=; b=Su5f4p2Zf5WBgI7cF/1ZYZQIXLZE/QwgIk5h4WeHpKRZK4iG4CgfcqDG tNQ//9pkZirEPhUceTrcP+tj5eccCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1548058812; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ZxU7UQbiBjDWTj6i7H0P1jq3/isxGf7MZssTewJ4ZLg=; b=GwQR+TmfBAb1Pg/ixbLgolXdwgAMYM6FzPIAYHXnaef06vSm3vUeKABE /n3HkTUBlk4OaNUiGwnQKzDykiOW4jYje+nw2HuXgPUnCnLzqPDmAP6BL3 AMWCW46RyywXCfVM5Y7CmytCHxy3BgN74aiCrgKzZ77mTROwh66MtVJgPR UZrKoiq0H7be48coLmvpSqxlkXtiv2nf9B3U+7OtRdVidXoB3A6gPU74kp 58/jn80h/q37zCINMrMK/SsFlsXEFnEJ1gYMVyUq5QSkzVgB4JcKyXmbtm SgjrWnJ+QtPUgLPPnm5/tAAH7dYWG0bfARR/MEOxFh2URYHwCGPTcw== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 353F22D40423 for ; Mon, 21 Jan 2019 02:20:12 -0600 (CST) From: Scott Kitterman To: IETF DMARC WG Date: Mon, 21 Jan 2019 03:20:11 -0500 Message-ID: <3080508.dEIuz3QfSj@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <12578706.O8KzW9sDEf@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jan 2019 08:20:19 -0000 On Monday, January 21, 2019 02:41:58 AM Murray S. Kucherawy wrote: > On Sun, Jan 6, 2019 at 2:27 AM Scott Kitterman wrote: > > Hunk at "page 17, line 44": > > > > Perhaps another sentence (more for completeness than anything) at the end > > of > > the new paragraph. Something like, "Additionally, [RFC8463] added a new > > signing algorithm in DKIM, ed25519-sha256 and it is also useful to be able > > to > > distinguish such signatures to identify cryptographic algorithm specific > > failures." > > > > That would also need a new informative reference to RFC 8463. > > I'll take Alexey's direction here, but I'm uneasy adding new references and > text like this after IESG Review. > > Hunk at "page 18, line 32": > > "Note that in an EAI-formatted message, the "mailfrom" value can be > > expressed > > in UTF-8." > > > > Isn't it more correct to say that the local part of the "mailfrom" value > > can > > be expressed in UTF-8? The domain part is still a U-label as I understand > > it. > > The text as written is literally correct since the entire mailfrom is > > valid > > UTF-8, but I'm afraid it may be misleading. As written, I could see it > > causing confusion relative to the guidance in Section 5. > > > > Hunk at "page 21, line 21": > > > > Same comment re UTF-8. > > > > Hunk at "page 22, line 4": > > > > Someone who has read the VBR RFC recently enough to remember should check > > and > > see if my UTF-8 comment applies here nor not. I'm not sure either way. > > I'm less concerned about making these adjustments since they're just > refinements, so, done. Thanks. This update addresses my concerns. In the area of the tiniest of nits possible, in Section 2.2, did you really mean to add the second space after authres-header-field and before = in the ABNF? Scott K From nobody Mon Jan 21 06:48:31 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97415130DC4; Mon, 21 Jan 2019 06:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 1xLMpU5H6cv2; Mon, 21 Jan 2019 06:48:25 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820128.outbound.protection.outlook.com [40.107.82.128]) (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 82B8E12DDA3; Mon, 21 Jan 2019 06:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r+arsYU3W8q0Wda3rkZt0CnePgLKrYX2vsHUchYXn9k=; b=dWvyQd4Xmd8/TpbnRDA3fK6/PQL163pz1heC+oWYMzQF0ZNUnH36YDMr/emAK3AWplOLoaiOT1hxYLnDNoZ5zJVHGmI6z1q+2q7/StcYQZQtTcS++Hs9g0mQ4IgAJfWTAEKqQXZO7xobKOh7pwhLuikjmT1REAUjHuZNTlRHaS8= Received: from DM5PR0102CA0003.prod.exchangelabs.com (2603:10b6:4:9c::16) by BN6PR01MB3202.prod.exchangelabs.com (2603:10b6:404:d6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.26; Mon, 21 Jan 2019 14:48:22 +0000 Received: from DM3NAM03FT050.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::208) by DM5PR0102CA0003.outlook.office365.com (2603:10b6:4:9c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.24 via Frontend Transport; Mon, 21 Jan 2019 14:48:22 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT050.mail.protection.outlook.com (10.152.82.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.11 via Frontend Transport; Mon, 21 Jan 2019 14:48:21 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0LEmIIw004779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Jan 2019 09:48:20 -0500 Date: Mon, 21 Jan 2019 08:48:18 -0600 From: Benjamin Kaduk To: "Murray S. Kucherawy" CC: The IESG , Tim Draegen , IETF DMARC WG , , Message-ID: <20190121144817.GB81907@kduck.mit.edu> References: <154280871768.11502.10059395575461348698.idtracker@ietfa.amsl.com> <20190106172729.GL28515@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(376002)(136003)(346002)(39860400002)(2980300002)(189003)(199004)(33656002)(106002)(58126008)(16586007)(54906003)(6916009)(39060400002)(1411001)(356004)(53546011)(93886005)(88552002)(55016002)(7696005)(76176011)(47776003)(8676002)(46406003)(6246003)(36906005)(229853002)(246002)(316002)(786003)(305945005)(8936002)(1076003)(26826003)(104016004)(86362001)(106466001)(23726003)(11346002)(336012)(446003)(426003)(53416004)(2906002)(4326008)(26005)(126002)(186003)(14444005)(476003)(956004)(5024004)(75432002)(486006)(97756001)(50466002)(478600001)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR01MB3202; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT050; 1:LLZj8/AjPfhqAwfAAewTE0R66HMMAdaf2XprTJ3iYxnzuiZ7pPm3d3nGGEBk44DpyXZbM/4GGLIPCHXmSZ/Dm2+WYu17c7aVArrow365cDeZM7BMhPQuxrWROQEXFTLA7kkJawjIHwWcOl/dI9+TQQ== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: caf8c354-c926-493a-b2a1-08d67faf7da7 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BN6PR01MB3202; X-Microsoft-Exchange-Diagnostics: 1; BN6PR01MB3202; 3:ohcvAXnnhRomNMVew1xwIHxw2rMWXwVFniMHRfuiHKQkbsia6OHM+U92G/S8u0g8UeMIpPYccVtsnNtACiw2+DmCli3M0jwWGFMaE1vgsexqNgznwOp0UoATiWMqIt2UYiJ91dPhiZ8Oozbb3nws3GycJif/B17irEZ8W4Ir6mFZj9AWpygcWKv03UQclhu5NHcxUYkIRk/BG3NkKM9R9yprvMAWZ5+I0Fkkzt2WQzqHu6FWuRyf+Kb5AOZ0ka8ZMfIZ7s/9r/ggFakD/JqqvxVwTWsVwfDiFkHTQTyLDsBVQW2eEIE+C0OXYBHJ7gOAmzDCQpZWFx3rwv8azKZVYzkHinP80k5vKaw/t2GUHZglG/T/E/RUais1lu2rlAbK; 25:hDOtP0m4QO4hPj6tCkPYapEc8QI3WEOO6Vuj/C0xQgQIhr43ZipAKh9AF2+bIdJEmiw3yHlimh9b3V8laBl/SyXt9orZmUZhErvPQrr1Zl8zPkKIeQusOQYELASEnthHR9xYksl31DJV1Ukw92Gkgobq9FEwslo1Ulx95jktRiDJUfskldVqzRBf2eHPHv1ExiAdSFcc4+3TkhxhUNAju/sUgt1gEZ6ORBctrZOfQaPVTg/9uc7xRSqxGUJ+pkVlU1mC86LrtlHtH2o02maO/hsOBa4hV7I8atXH5Z/oZT7lsHeoMng/SqCcGadrkAiMQTi9hf9iOgXec4Pg2SUl4Q== X-MS-TrafficTypeDiagnostic: BN6PR01MB3202: X-Microsoft-Exchange-Diagnostics: 1; BN6PR01MB3202; 31:A3/HML2gF6KFlSvRBJfSQrM/iI+j4zvGkchhe5kGyKJS90sF+twmHEVlYa29EHCopClXEjtWTR8wOHu/68Xal5qkt3uuq4EEBmywjDIOfVZ/ca8yGV+ESLNSw/mLKVeen6ovTDJmCO9VyFtVyXZ9zJqARnRprn8/eXRNYS9S5PUTcOigFv5Pe4Ydh1/rI6MjQlO95BGzqwfP6HG8Vw4jymS8CRMbQ0zyyOJlnvDexGw=; 20:7Ae+wfZg+uuXkAgh1tpp3I4aDxT7atndW9afvALSKZEefGZeIMb6puOVLOIztF+BO3a0JS1H2wdk9uwofF/gLYjYqL1rGIbvcOaWohFJJvMbf51hzwuLhEXVqv1u1V+ChWjfCFxDlZlSbUu5a7BA73DbF7Ocg9JDasY3db0a/tt19GgDfdMQSYUoBfRGE6SsZCS+ELfS/VrV0wVxVlsGYXTfYb0kFry/ZjyDdUw7mMNcOGFEwnyz4RI4tVpqn1d/DiibAmwVONoKNkRAR9m6Ogjc5oylHOKZAkPV/KusLaiQUNEPGwxMsxGKtYj87N5Y8SBNVM2ABPU6Ay+6J9hOcZawJyM6/iVbjA1CecDqSOtAvd3pw0aC5hPEOQ2cp3H5mSdiSyDgAsRFkdmR18CYnSPU3CBiG2WM7LYMI20vtwNV52b6z4tl68sHy+LhVzSa5xZoHaa0V86wFonMyiQ/18HtKdyFSQFgwSyCEyTnocZWxkMg2HUFoyqm31PRsQbRzNRxXfWKDzlgWNAMSE5EHssKWrZYDiUV84IAeWzmMKmv5O5vPVGN8EVmRmiqDpNgc9YwpZWc0K/egjhTOcozmMdSIWvsx7ozk0lNxIn+I2A= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; BN6PR01MB3202; 4:ri7Sy8uKr37gINIU2EA02dAIHHGGE3Ypo0lD2Nl0FuouHOouKGy2jQ+WOk/EIZlJGIquH3N2pxdbUldr62dSt1hr1TWjjWH4PX1SvarfEKH0G6smLnfvmgCPjTtxWfaY72WHeGt0Z765u12ql+JGAWnkJzW6hnKWkywnVLlrHhMxsu/0RHanxyLuaMiSNpAArB/MdZkIzE+fdjkP72GcZPbpOWKkc2AAP8d/g508L7RMr+DBaUHGaAvI1W+QueOzt4jzQtf8MPTecWBgVHpgwUzR/otCnjUKzjl3JIJ7u7y652oFwjEFiPMAzB2nMB0R X-Forefront-PRVS: 0924C6A0D5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR01MB3202; 23:PmAhWCCEgQfh+zU+EXAxsqUejep8FtrOhVnuOvhvm?= =?us-ascii?Q?lpK/D/lDqVIPlZSA6DJtQx955c74ZvU91BBVEBK0projk2tlXsbBt+9UgZzT?= =?us-ascii?Q?SRVdU5/lFqdUXrs9TMpb1JExmuzXBYf5c345kDgFkycgrsc7Q1/grGr1+iq2?= =?us-ascii?Q?4a/tCXaIFCbzJo0AqKtGjT7a1k248vhlKHjCrT3SNNIoK02skQE+Es7alS8z?= =?us-ascii?Q?uWGIm9wWu58N7h/0EvvzfSaBVoGvBphU2zfkx7aEr30JmCEAzmyOVCZRLfZZ?= =?us-ascii?Q?IDmHjZ8m5Rqzp6BdN+3uqLWqnQ0U9UcQ/CUBWR8oEV45ZxwMnC4/cHdJC5A/?= =?us-ascii?Q?e+knw2BzrDTw1pH9VYDtXEPPf/FdX950LRB+FbX3mNaYFLzltojMDlPo8rUq?= =?us-ascii?Q?WDkcHQQCQa/oEScuYHooyNxUP0P9D8DIcjj/8g9B7zAMWoLXpFm4Lc1m7bNH?= =?us-ascii?Q?88pP1p802EFIHa7TpNg4UdaytBu2axOekfcpdgRC+2IjyqheWvRhgpPHHN+l?= =?us-ascii?Q?7WRxktG9uulonX7HsNphTcP9nEI8+qnxOZJppVce5byRoak/wblx8uD8Xe9w?= =?us-ascii?Q?wzLy/gUXKcLgKYPMf5pMj7o66SW7GrpBd7D535MXU0RIqyMSPsfAHzJ9UKOe?= =?us-ascii?Q?ekmTsFgrXfepgNLpXOUXl4XzmEb32kZ0vTlmgimMXrv2nrzJ5clBNeBjEpbH?= =?us-ascii?Q?zdPlYGabrLib6+d191DaBBfx+6VdrHPFnrrOcBBlkQpjYDZGcPKIloJIteCg?= =?us-ascii?Q?558+yyErtsCTd/cdX2weVH6cApKeRFphut4jt41lNcIpu/hL2igDDjvGR6A7?= =?us-ascii?Q?kUBsyDfeZPMsHnEN2TqN3gdJmtpVMSwaqkGRBHrr0GNdQ2cK+2owwPCxLC1/?= =?us-ascii?Q?pqkVl3xkGB7Y9yQtLife/5cc5GL8CBfQF90FsMwdPqJ1QvScFX87I6AOtCOv?= =?us-ascii?Q?BcL5oIUx+19+Zg8pB74cresRoXGQqzVUOYmJc6jhC0FUa+DXjLKpyBffCH4K?= =?us-ascii?Q?iqgURl46qTW/+InEWQsoguJ+gzUlAbMgPzf8nQVSiRQXiPDYIFh/9ToRdN/x?= =?us-ascii?Q?izqYiGbmpMmPssYPCvloVS8xUFAgLUN8FAK2KIFr9Pu7uDE2PJTGUF0SvSya?= =?us-ascii?Q?79gPDCvhduz7b4QsfQLqudSizpmvM+4+L7t1fAnDEvjhEgliDoIql+MJWgvc?= =?us-ascii?Q?CPomJo/frwLrSh7ZrzhMBeGdUCr/S9QzFXwOw2iU2mZ9j09oWp2X99pYsNmg?= =?us-ascii?Q?+vMuFq1iuK+R7Jxew6Kp33BlzQBqKIzlL1zWNT/qTuts47HAQ7kH/2F8tT9m?= =?us-ascii?Q?aQziiehVYLwOnAAno/9snQ=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: Cog1nUs4wKKbTlulqbVSldwYYar3i3PDGv9XRNlMhcJXqakqwIgGRfMyQwwN1rrR3FPfMW0SASsbCPWq5OWWf4DkZVG2gbu7sZytzVXIcqB5vFmr9CExO7x2nDfcgRtfidUM6N5uTQ6elA/pKwckt7fsSAdI+Eu4gcNxKWRvdm5+6GW6iKfHCV718iR2DDP2nfgyNgt3uq1YWlCSBnLqJuawM03W0BEDpi1QZiFR5olVW8dNaZMS/xY8oILR/BqJq7zoMWPi6LG++yf5ri1Y8QU1NNQ0Id3k3L1zkTuAyOmwS276Ty4HgzdyfpzrScHPGzOYks19ESSTruSgbDaXt9iVUBA5jn15MxxmrbpYd6WG86+Kf4qwOAG4taPVIMEpX2r7dijbdjtjUjzfiJjs/9vv5gGyE4ytSt3C6r7y70c= X-Microsoft-Exchange-Diagnostics: 1; BN6PR01MB3202; 6:SONux1QCcNEEhNbZqW9U6K5zI3xHh3q1eteYyX8gqYAdHnjE3CbYPtys34rDPEuj1XC6jeXv5+VfHV5PrS2cgYBtQyGD+dTz/+cKcwS+LhhjvckQCkOpWE8YC4y1au2tld8da3pHmTV9EOly2noDpk8vxaQhJ+0mcysNEjM55pcoMBFsuOwBr1mGM2SN7WAi2Z7/LvSEOhne86gRQPJ/wd4xYSLyHo02RUoFe2Sa2KyTAdnVvQUN0TFJj7Or7oPxfQTzxv8nDEtvq8XJ9h2JrdgY/+4Gkx+fAkMxF2/ZZ2DmvOt9MHcimULa4OLPJbiQsAaKLUjtbki0v0vfGaAcnLxdCv+4TkcKJLBlCJ5rDdTU+fYM7C/OQaIwcgBoUuAaFlVVeof4elvaBF4Mh6fgLL0P/ZQTmHJ/Z2lnFdZZSgaVsqPiygKn0u5ff4sVD/no/pTH/GFwPHwMsXgl6Ml/Zw==; 5:ZOOIBGsHsTvR8tbOAth9/ZHdgypvlMw0P6bcDEwLGk0wKtnbeYgomolfyV45QLITIUraTST1JVVA30bCYmTWgfBm2Jb2fJ4Wvlarv5FyF0GLUeYKPj7UUV245UooDmHno9aXRLMv6gJ0js0Vivfhhc9VxniO//4kfzU4fDcu5u3fkaCRZOjE12FJbSm2YyHmmalbMfmVFHh54jV7bCojyQ==; 7:oVsLL5c7kzjPA/OPL6NHIawJadnzhcHxU3+aeuRJ/SsDvq2x2fjLqsFOn4lzhVUZ3Gh4mSTGRs4vl+IL/5zh0Kt1HIAFJxuyeq7Kf2CeywMYq8xs5iuhSP93c/VnZkL7XfFcl1eaybRmPqvEsmfABA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2019 14:48:21.8806 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: caf8c354-c926-493a-b2a1-08d67faf7da7 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR01MB3202 Archived-At: Subject: Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jan 2019 14:48:30 -0000 On Mon, Jan 21, 2019 at 02:25:45AM -0500, Murray S. Kucherawy wrote: > On Sun, Jan 6, 2019 at 12:27 PM Benjamin Kaduk wrote: > > > > Section 2.3 > > > > > > > > body: Information that was extracted from the body of the message. > > > > [...] > > > > interest. The "property" is an indication of where within the > > > > message body the extracted content was found, and can indicate an > > > > offset, identify a MIME part, etc. > > > > > > > > I'm not seeing where it's specified how the "property" gives an offset. > > > > I see other descriptions below about specific header fields and SMTP > > > > verbs and such, though. > > > > > > > > > That's text from the 2009 version of this work. Those were speculative > > at > > > the time and haven't yet materialized, at least not in standardized use. > > > > Are you proposing to leave the text unchanged regardless? > > > > I know the use case exists, because I wrote that text when I worked for a > company that was likely to make use of it, but it appears that hasn't > happened in the deployed universe. So now we have a registry entry for the > "body" ptype which isn't deprecated, but possibly no live uses of it. The > working group didn't discuss taking any action to either "fix" or bolster > this, as its focus was elsewhere (specifically the changes needed to > support the DMARC/ARC work). > > I'm inclined to leave it as-is, possibly with a remark capturing what I > just said here. If no uses of it appear before someone decides to revise > this again, we can formally deprecate it. Okay. > > Section 3 > > > > > > > > of the validity of the connection's identity using DNS. It is > > > > incumbent upon an agent making use of the reported "iprev" result to > > > > understand what exactly that particular verifier is attempting to > > > > report. > > > > > > > > Does that in practice constrain "iprev" usage to within a single ADMD? > > > > > > > > > > I would imagine so. > > > > This is just the COMMENT section, so do what you will, but I would consider > > mentioning this property of "iprev" more explicitly. > > > > Actually, on second thought, it doesn't: ADMD #1 could attach an "iprev" > result that ADMD #2 could decide it trusts. That is, sort of, the ARC > model -- you decide whose external results you're going to believe. Part of that seems to be having a side agreement between ADMD #1 and ADMD #2 about the semantics in use in order for the trust to be meaningful. But I guess we don't need an IETF standard for that to be possible. > About to post the new version. Thanks. -Benjamin From nobody Mon Jan 21 08:20:42 2019 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 F3836130F1B; Mon, 21 Jan 2019 08:20:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc-chairs@ietf.org, tim@dmarcian.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154808763299.8236.15527578247635487733.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2019 08:20:32 -0800 Archived-At: Subject: [dmarc-ietf] Benjamin Kaduk's No Objection on draft-ietf-dmarc-rfc7601bis-05: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jan 2019 16:20:33 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dmarc-rfc7601bis-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss points! From nobody Mon Jan 21 09:38:53 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA87C124D68 for ; Mon, 21 Jan 2019 09:38:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 9E8m36AaEOxL for ; Mon, 21 Jan 2019 09:38:49 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 B35FE12426E for ; Mon, 21 Jan 2019 09:38:49 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id h193so16294942ita.5 for ; Mon, 21 Jan 2019 09:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=JpV1uhxA0SIVqeJKlFdv8pEtBU6ls2Lz8Z9ai3PO34I=; b=bpD8QL8UJ19cJiVrVJBpaK7SdZ/1x7Va4dMB8BMPZZaisUzAfneGg2w3zRgMko4xnb rBK6ivFjGSDps4nWEoy5jYyyWHMbcNoA+zQddMczX0/qKUWujmTVOEwkgBePyW6kDOMm 3Gc2scPCfQYyVQ3g/TSrAfQa2sPK/tfaHku6k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JpV1uhxA0SIVqeJKlFdv8pEtBU6ls2Lz8Z9ai3PO34I=; b=B/6wGO3C+He+TiIUhB89Wkix3QWQPc2RDPwyj/Mp5IykzZJkqZZku7KR4AK1UEgaNa 9b1ns+72QfIHQAJ0RzC4RvPmQLctc0x2zH8a9s958+hNmvWWkr86+Ykv6qaAaQldmvYA EH5zdMQVayc4G7Rbf39Y6XQh7gsdXBwQ8cL39b06+ylVlVhZtN3V33OsD8/tTJm1Ez7a QjvD+jsQqcPwnuaKEcJSpO5OlmIzV2Qev8l+pveoZ6X00u+wvVELGQmzLh4LR0UpQ9um pOsfP1L5FaaBHDv5eLiqzwgzMcxg9AEE40g9l9zQgxm+Na66Q3bSYE62ZRkwK9cNO3AC PNCg== X-Gm-Message-State: AJcUukdwp5bm5AU9w2V1r7ppLDlod1gx7OYSqBmsoB6UO2kDrud3FPb1 j6VxOfIoBBICZ1n/d606LD3utVTE/0z2lp2ZmtShMBdmf8ZaRw== X-Google-Smtp-Source: AHgI3Ibmv0i/1o/bO0nTdwxDYGJ3w1sibC6Qbn7jy3uX6Qo08XNF58lJXpfZyLrmuM9+Vqtb4UCQeaMutfhlmlrXbUk= X-Received: by 2002:a24:3047:: with SMTP id q68mr262735itq.78.1548092328560; Mon, 21 Jan 2019 09:38:48 -0800 (PST) MIME-Version: 1.0 From: "Kurt Andersen (b)" Date: Mon, 21 Jan 2019 07:38:37 -1000 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000052e2ec057ffb5557" Archived-At: Subject: [dmarc-ietf] Proposing last call for draft-ietf-dmarc-eaiauth-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jan 2019 17:38:52 -0000 --00000000000052e2ec057ffb5557 Content-Type: text/plain; charset="UTF-8" Since we've had no controversy or concerns expressed regarding John's document (draft-ietf-dmarc-eaiauth-00 ), do people feel that it is ready for last call? --Kurt --00000000000052e2ec057ffb5557 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since we've had no controversy or concerns expressed r= egarding John's document (draft-ietf-dmarc-eaiauth-00), do people feel = that it is ready for last call?

--Kurt
--00000000000052e2ec057ffb5557-- From nobody Mon Jan 21 10:07:12 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DB8127B4C for ; Mon, 21 Jan 2019 10:07:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NY2MHhOfRPPb for ; Mon, 21 Jan 2019 10:07:08 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 8221C126C7E for ; Mon, 21 Jan 2019 10:07:08 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id x85-v6so18346451ljb.2 for ; Mon, 21 Jan 2019 10:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=e5ND6wmWYOAnhgpc++0vfYOyb7Q7uqepvxsAbopyZSg=; b=kReD+u4kF+oiARH+c5tr0zqzIRPzGesqhVTIgbgOpdhZjhpUnCQ7z0YyQmv1c84O9V 4SxD9tboffGx0rithm7FrsJiy53SECbPbeZYWI2bx4+DfYl2P1Q6NTypYoVrXxDpRwfB fzM71Qpqy+YVhtUcBF0BRyvBmh84wKJBGd1j73m9I22Z6VvRrxAmtyAZ6iVO9ilhoN1N fMY2CSNGh0QBc2pKkbsFpg3bNNNneZuKG4l8V/vE1xkqBJpCE/BcsE5V7e0ix5lQGDsV CTb20XjvBFVBe8fuc9ggSkUITIuT1SMznT8hT9VgKMa3SSIq1CSofgosd3mYijwADbOq mOow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=e5ND6wmWYOAnhgpc++0vfYOyb7Q7uqepvxsAbopyZSg=; b=KFJZ5Z6vKhZmwgTiim20YrhPuhiSYtim6O8Ybm+7K+4iIhWtlbHi5UVzAKKR3t972W wI6FJGSreatt0mMd2atr1Sm8BFwO9lPJqRaqZnM/NY4SsId24MctNtKkiAZaAkXguVas k4USIaPbkn34t98TI6GK51QlLildFJQvShDp+UCW3pw3ff6Jjn9tiDOSxKLpVPs3jfu5 3ArSkrXRpIUiyKV3Gc9zZTr37pI6RNxSabP+2jNPqtLYrl/iiuAWwz62czCD/MfKbjIS ehwqOB0lB3yKEkzP+iCp7To9jCw/rhNqFCZyia1K+IcJtFo7VQATIlrByjQ9fJQCQ08z 0zqw== X-Gm-Message-State: AJcUuke9jbc8Jp+YiurwOSVsDb4fyw9l7G3FNEcxvC/tzkeWG3E+o0ba mIbHQIb0EpYFHd+Zgy5lYmn5ARXkSkOFzM3/KBPd4w== X-Google-Smtp-Source: ALg8bN42r3xLQgWkJYuIxCurQamH9gE4USMJg8WWusEB4Tdb3jf2oFE6k4mUmDN3cw4R/Irskw13FwxWv4bm9cuOvog= X-Received: by 2002:a2e:6a13:: with SMTP id f19-v6mr20261368ljc.41.1548094026278; Mon, 21 Jan 2019 10:07:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Peter M. Goldstein" Date: Mon, 21 Jan 2019 10:06:54 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000083ec88057ffbbaf2" Archived-At: Subject: Re: [dmarc-ietf] Proposing last call for draft-ietf-dmarc-eaiauth-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jan 2019 18:07:11 -0000 --00000000000083ec88057ffbbaf2 Content-Type: text/plain; charset="UTF-8" +1 I think it should be submitted for last call. Best, Peter On Mon, Jan 21, 2019 at 9:39 AM Kurt Andersen (b) wrote: > Since we've had no controversy or concerns expressed regarding John's > document (draft-ietf-dmarc-eaiauth-00 > ), do people > feel that it is ready for last call? > > --Kurt > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000083ec88057ffbbaf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

I think it should be submitted f= or last call.

Best,

Peter=

On Mon, Jan 21,= 2019 at 9:39 AM Kurt Andersen (b) <= kboth@drkurt.com> wrote:
Since we've had no controversy or conc= erns expressed regarding John's document (draft-ietf-dmar= c-eaiauth-00), do people feel that it is ready for last call?

<= /div>
--Kurt
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000083ec88057ffbbaf2-- From nobody Mon Jan 21 12:11:14 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F615126BED for ; Mon, 21 Jan 2019 12:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com 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 VQdcPcS42UZI for ; Mon, 21 Jan 2019 12:11:10 -0800 (PST) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C96A128766 for ; Mon, 21 Jan 2019 12:11:08 -0800 (PST) Received: by mail-oi1-x22d.google.com with SMTP id y1so15507655oie.12 for ; Mon, 21 Jan 2019 12:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=tIvvhm+I0vGDC9TcVFT7WQMCSje/XvfZCpo4Jk5DVhM=; b=zfUlISJRKinY9iqlstapSzoaq0KIv7eOa/NdZ/JE2EHn6w+s99PlGIrlABBGiZ/aW0 tWeZpi8iveP7Ml9uW7C/JvVCcUI1gsGbBeMduEDhDmtexc0lDX0AgHY6IFXpMh9MI9uz mILRxFjAh7Tb0BW3+1ECsUjnSZf5f+TK7pjprIiVZYGnB3uTYqDd/M999lA6VH9AUkuo DJh79t+m+pURXKLoup+MdYUOj6CxmIU5WRxWycu+i2yUP5Z4iw14DbKMVMfoLmtHa5L9 BTZfa5Ohz+vl3ZjSA1zJE10SFOQnMzcLmeZveNkNOcSs0kYPKjy1Ovh44tS9WidSqry5 SPsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=tIvvhm+I0vGDC9TcVFT7WQMCSje/XvfZCpo4Jk5DVhM=; b=aDfJ+G9/4rF/F84DPnoYOB++s4/YFpx2MAqBoNpAYR5HTIxWlsq0+qz475XZcD7BFE CcJidzQbLLfnHmsNjOgaD1gmAqRb00DDoIZF2va+Txhuje0BCB6HiJqMW2CiVxrsD0yV Q4DIyWdhes0kZSRmVOl3Dg0Y3UrBmgT7IW7PsMjAtrzz4VO6plxqx+Yj2xuv5aEcyImz QYJVF74KFRbnYKYa0xDMxl2XMDB6T8dwKcYQ4LOZAyyZ0oNJYrMM/zuEiqiy6Iv9dmCe n6epVbrlBVZf0tj1l7N7p9cOzl29DolS3kL/K89oyJCY14pQvPGV+fR4zzvLxyJyQGZL 1btQ== X-Gm-Message-State: AJcUukeRBeGaKTlxNGZFSXjB2d40+e2Eg8xtSsGqb+vcIqsqCNRQXJZJ RTczfm8l+DccUXzvY3wKLpjWXLKoyx374yYRVMFUdL6K X-Google-Smtp-Source: ALg8bN4nlHjgrbb7sCZDbPtjgb5XQ/1HumjW0Z0327meil+pydNmRF/5kUdxPVY93gMyTYnP8s7xQdOPWDjO/DEW5kQ= X-Received: by 2002:aca:c682:: with SMTP id w124mr6697503oif.319.1548101467092; Mon, 21 Jan 2019 12:11:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Mon, 21 Jan 2019 12:10:55 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000005d27a057ffd7680" Archived-At: Subject: Re: [dmarc-ietf] Proposing last call for draft-ietf-dmarc-eaiauth-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jan 2019 20:11:13 -0000 --00000000000005d27a057ffd7680 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 I concur it=E2=80=99s time for last call On Mon, Jan 21, 2019 at 10:07 Peter M. Goldstein < peter.m.goldstein@gmail.com> wrote: > +1 > > I think it should be submitted for last call. > > Best, > > Peter > > On Mon, Jan 21, 2019 at 9:39 AM Kurt Andersen (b) > wrote: > >> Since we've had no controversy or concerns expressed regarding John's >> document (draft-ietf-dmarc-eaiauth-00 >> ), do people >> feel that it is ready for last call? >> >> --Kurt >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000005d27a057ffd7680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

I concur it=E2=80=99s time for last call

On Mon, Jan 21, 2019 at 10:07 Peter M. Goldstein <<= a href=3D"mailto:peter.m.goldstein@gmail.com">peter.m.goldstein@gmail.com> wrote:
+1

I think it should be submitted for last call.

Best,

Peter

On Mon, Jan 21, 2019 at 9:39 AM Kurt= Andersen (b) <kbo= th@drkurt.com> wrote:
Since we've had no controversy or concern= s expressed regarding John's document (draft-ietf-dmarc-e= aiauth-00), do people feel that it is ready for last call?

--Kurt
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000005d27a057ffd7680-- From nobody Mon Jan 21 19:14:57 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EB5130F4D for ; Mon, 21 Jan 2019 19:14:55 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=xzPQLlUu; dkim=pass (1536-bit key) header.d=taugh.com header.b=OXcqI9o3 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 3S1gOK-WqFjX for ; Mon, 21 Jan 2019 19:14:53 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9185E130EB4 for ; Mon, 21 Jan 2019 19:14:52 -0800 (PST) Received: (qmail 4566 invoked from network); 22 Jan 2019 03:14:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11d1.5c468aab.k1901; bh=HTyJIYdYontrVwQMWY07FGb7agQHG6nJeQ8BHY5obj4=; b=xzPQLlUu0KD14+dZgqHhJ4YFpF7P3uhcl1QuOPG8UWJXP52OZNhOMUuiqCP/4zdR9u3a8yVETyn/HePVb2PBCpI6tOpYn4Ld3t+SzPV0CPP221y443Y6IkZL27bL9Fc1MHg3BnlnLMprQ3EENCwO8KcuOxmlUSZBHXeDb6ywwLIKwtE25Ool5IzRLkgrxRIsb2KZfUSZelbloO1etyYhIZQiRa4HmfdZlwL61JSgBgz/aa++nyz7Pbtwa9U9hY+9 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11d1.5c468aab.k1901; bh=HTyJIYdYontrVwQMWY07FGb7agQHG6nJeQ8BHY5obj4=; b=OXcqI9o3OoE0gr1UW8gthB5kl+rrj7ok9RwJnjbnM259/jlGFbb39QF/YLSaY74PP38bRFbZvLaOxsDLXHEh/HllubYO7+8W5Ot1wsuFJCzj7iPtu9K6QJH2eR898O3UvFMASQ7Lz2hEoqeQr+RDhRI5AEV6gIHgbJ99neXdTixZTk3uP4yqQlV+ioaHPDii/FT/UPTyTy1tVP3ewHXr5mfaZOJrinSqKiHVV8iuqzugG2MWXL9dUyKwxNLwmxOf Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 22 Jan 2019 03:14:50 -0000 Received: by ary.qy (Postfix, from userid 501) id B1B2A200D02A85; Mon, 21 Jan 2019 22:14:50 -0500 (EST) Date: 21 Jan 2019 22:14:50 -0500 Message-Id: <20190122031450.B1B2A200D02A85@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jan 2019 03:14:55 -0000 In article you write: >happened in the deployed universe. So now we have a registry entry for the >"body" ptype which isn't deprecated, but possibly no live uses of it. ... I'd leave it there, at least so nobody inadvertently reuses the ptype name. Apropos the comment about VBR, as far as I can tell nobody uses it so I'm not inclined to spend much effort on it, but the text in -04 is fine. If someone wants to put U-labels in their VBR headers, it's OK with me. R's, JOhn From nobody Tue Jan 22 10:09:04 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871571286D9 for ; Tue, 22 Jan 2019 10:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com 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 ugKFiMiUkJL6 for ; Tue, 22 Jan 2019 10:09:00 -0800 (PST) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A4C1277BB for ; Tue, 22 Jan 2019 10:08:59 -0800 (PST) Received: by mail-oi1-x22d.google.com with SMTP id x202so18165438oif.13 for ; Tue, 22 Jan 2019 10:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=laAt2OWhw6RTAXhr8LvaPvDmD5yfPQMo0WHyfzSaGR8=; b=vWPXsgUur/uOOKEbjweDqxws4btA77JQ82hrLs0edmneFk/Z4i8CpTUWlJih5W9hQK FT2oImOM8Jbp68c2skjwCkeD9PJOp7pJIFE9I13nVN00wt/7BBEx6m1lJde7ULOJGuWZ ST202KWpKG6pm09eIHu8ZOVdNz3ya/HZBJaEWL4iQOr6hRHxIV/cLZDwFKcZCHME4KwS niz4zhugvBj2vNfWAaspeaiiD/JYXQ5YEaEVXqZi6+jCWkvp8jVk8c3pKoZARokUcRcd Bq3QUo5B+XlLqbGczprIalseQ42x8boFR2QH1bYNw2nd7jYmQvE1lBPltwFtPxsmkeaf r+iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=laAt2OWhw6RTAXhr8LvaPvDmD5yfPQMo0WHyfzSaGR8=; b=UwPzhZ1jBB9hLZ+X3S2+PsLzHzDQfK/LnFA2yqha+k2ng4uFJhXrrUMWQgZjz6Uwx7 BAL66vl/WJK1TIkS5v+K8JXv2kFuIUXkcvMpjv6f08I1GiTSpaBmjiY0lKiry5fmWGKe 0JyXVm6MxIMKJ093d/gKTsmczinvcZi2c+w6+LGIwgojVQLvSGqbqPG5ItkjUaQLP+Ka WgRycmqKzIvXBoYUBpH+u0+rkpti7gJUNWeEcu8dF0oolZ9QfHkMXvIOSzItK8NsTCmP EEPk0+WedGC7PjsAaF+2w9kZQZBLf29cDAIM8CPyFzFdKfHT3pG7+QoVQ41X2VJXqdMQ m0Jw== X-Gm-Message-State: AJcUukd4+A77/o7w0zZGhT6VFRA2M4qZjTtLC8N1F9QIA2lyO6le6Ktt 6RVyV5tI7gO622JwotmdXHXQd9Or2gOxUBGawzVr6n9+ X-Google-Smtp-Source: ALg8bN4GpQBKCXIeRPjI28pDbmTqhEvwQkyuI5Ct6FeH1MZT1xH6Pa+Eq4KuNnbNcpwpfzwZCiIfhkMWRpmHZZN2vk4= X-Received: by 2002:aca:844:: with SMTP id 65mr8575621oii.333.1548180538948; Tue, 22 Jan 2019 10:08:58 -0800 (PST) MIME-Version: 1.0 References: <2393746.3XrAvFVKfY@kitterma-e6430> <5694407E-6D84-4266-93DE-21FB90D803B2@kitterman.com> In-Reply-To: <5694407E-6D84-4266-93DE-21FB90D803B2@kitterman.com> From: Seth Blank Date: Tue, 22 Jan 2019 10:08:41 -0800 Message-ID: To: IETF DMARC WG , Scott Kitterman Content-Type: multipart/alternative; boundary="000000000000129ca405800fdf77" Archived-At: Subject: [dmarc-ietf] Fwd: Proposed charter spiff to accept EAI clarification within email authentication stack X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jan 2019 18:09:03 -0000 --000000000000129ca405800fdf77 Content-Type: text/plain; charset="UTF-8" Scott, does this need to be addressed during WGLC for draft-levine-eaiauth? ---------- Forwarded message --------- From: Scott Kitterman Date: Sun, Nov 4, 2018 at 9:14 PM Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack To: Kurt Andersen (b) Cc: dmarc@ietf.org On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" wrote: >This came out of this morning's DISPATCH meeting at IETF103 ( >https://tools.ietf.org/wg/dispatch/agenda) to be able to accept >http://tools.ietf.org/html?draft=draft-levine-appsarea-eaiauth into the >WG >for advancing it to an RFC (probably informational). Thanks. It doesn't appear that it proposes any changes for SPF. It merely documents that non-ascii local parts don't match the related macros. During the SPFbis working group we looked at this and explicitly decided on it. It's not by accident. Since local part macros are very rarely used, it seemed like very much a corner case not worth it to break the installed base over. If there's going to be a charter change around this, I think it needs some words to constrain the work to limit interoperability implications. I know less about the implications for DKIM and DMARC, but would imagine backward compatibility is important there too. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --000000000000129ca405800fdf77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Scott, does this need to be addressed during WGLC for draf= t-levine-eaiauth?

------= ---- Forwarded message ---------
From: Scott Kitterman <sklist@kitterman.com>
Date: Sun= , Nov 4, 2018 at 9:14 PM
Subject: Re: [dmarc-ietf] Proposed charter spif= f to accept EAI clarification within email authentication stack
To: Kurt= Andersen (b) <kboth@drkurt.com&= gt;
Cc: dmarc@ietf.org <dmarc@ietf.org>




On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <kboth@drkurt.com> w= rote:
>This came out of this morning's DISPATCH meeting at IETF103 (
>https://tools.ietf.org/wg/dispatch/agenda) to be ab= le to accept
>http://tools.ietf.org/html?draft= =3Ddraft-levine-appsarea-eaiauth into the
>WG
>for advancing it to an RFC (probably informational).

Thanks.=C2=A0 It doesn't appear that it proposes any changes for SPF.= =C2=A0 It merely documents that non-ascii local parts don't match the r= elated macros.=C2=A0 During the SPFbis working group we looked at this and = explicitly decided on it.=C2=A0 It's not by accident.

Since local part macros are very rarely used, it seemed like very much a co= rner case not worth it to break the installed base over.

If there's going to be a charter change around this, I think it needs s= ome words to constrain the work to limit interoperability implications.

I know less about the implications for DKIM and DMARC, but would imagine ba= ckward compatibility is important there too.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000129ca405800fdf77-- From nobody Tue Jan 22 10:53:52 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BA9130F3A for ; Tue, 22 Jan 2019 10:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 w1ctffQebg5Y for ; Tue, 22 Jan 2019 10:53:49 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 945AC130EE1 for ; Tue, 22 Jan 2019 10:53:48 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id e26so18899435lfc.2 for ; Tue, 22 Jan 2019 10:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=aQn7atEnpdp+pEmIIlvDuJePpX6eNFhdZD9nw8O1Heo=; b=HltgDu/zln/lk65xB1P50hyAozWglqldlBCpp+5CqnUwOoRrpojLZM+zEdg1hz3XZk ewQDJIhWl4ftamYV4YI+3idNv68TQ4FmmDBDo3IXfw+gScQnc5MvVPp4QpzhdyTrNVnv HJrG4SDBqG+RF0sgFouLlDnAGKbU0CbMfxNjWoRx4CyyO/UsIIa4FCu887ImVl1A26dt i0MRzqOhBEQYkINbgU5sY8IbydgLRfXyerKlM+9pb8BSFLSBkBXrbP39jwM5/AddybGy n6GzAU18PyKJZrDZwYlFzWwI4TWWKULkQaLnyBkUHtKg5OPhMzAL10fYCRrz6/+mljMN ni8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aQn7atEnpdp+pEmIIlvDuJePpX6eNFhdZD9nw8O1Heo=; b=kY3yqQ7nZNG8POGZks2chbwlaxuYXkbuUIiXsQ/3p18GGqQP33hpw+ZuhDYVG+2LNE iCVk3gmauyu6CntCDpB1jNlG5aeD9VpE8W3HLgbvQyto5/UJW3WJ90wq1c5xQLI1/jpn PSZJ4I3K2NjMsF4HAPQOp5I+YlocaGO5wjD5hP/E4v7KTcN8xFXI/yZwzRBSO926ENHm MmcAJoQnQF92CFlglR9CDMx3CPI+10OeRT4C0U3nXzwABcFS6U4z4VLwGmlDr4pJEbgH QlGIV3ooEXcD24V6BvJAXEFEqvfzgy6f45rZt7RClDfHdNZaydIaKOB+IUFebjPAKe2I n8mw== X-Gm-Message-State: AJcUukdhs/WL3Y+MmgE8obtLpwoiopAo8ZW/F26919XZpRNoGPd7CObe Z3NaSZ4J3LlJcH9HtsZfrP+UJZBPVU5tC343wYgEwA== X-Google-Smtp-Source: ALg8bN4DCrfnZUJTv+/MMRvoxx28FH3msHwy+JpQ/u6/6r7GgT1i3o7/FE0TJjeXPVzDbb/3FdEqWr4mlpcrZnnSN1M= X-Received: by 2002:a19:c203:: with SMTP id l3mr8708468lfc.113.1548183226148; Tue, 22 Jan 2019 10:53:46 -0800 (PST) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Tue, 22 Jan 2019 10:53:33 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003dec9e0580107f47" Archived-At: Subject: [dmarc-ietf] Post-IESG Review edits to RFC7601bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jan 2019 18:53:51 -0000 --0000000000003dec9e0580107f47 Content-Type: text/plain; charset="UTF-8" With the posting of -05, we expect the last DISCUSSes to clear (one already has) and the document can proceed. During DISCUSS discussions, it was pointed out that the ADSP, Sender ID, and DomainKeys specifications bear "Historic" status, and thus they should not be carried forward into the new version; they will continue to exist in the Authentication-Results registries, but their status will be changed to "deprecated" and their defining documents will be left at RFC7601, while the others that are still current will remain "active" and their defining documents will be updated to point to this new one. As this wasn't expressly part of the Working Group Last Call, it's appropriate that this be posted here and people be given a chance to express their opinions on this last-minute change. Thus, with the Chairs' approval, I'll post this on Friday absent any sustained objection, and Alexey can then send it off to the editors. The proposed diff to -05 can be seen here: http://www.blackops.org/~msk/diff.html -MSK --0000000000003dec9e0580107f47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With the posting of -05, we expect the last DISCUSSes= to clear (one already has) and the document can proceed.

During DISCUSS discussions, it was pointed out that the ADSP, Sende= r ID, and DomainKeys specifications bear "Historic" status, and t= hus they should not be carried forward into the new version; they will cont= inue to exist in the Authentication-Results registries, but their status wi= ll be changed to "deprecated" and their defining documents will b= e left at RFC7601, while the others that are still current will remain &quo= t;active" and their defining documents will be updated to point to thi= s new one.

As this wasn't expressly part of th= e Working Group Last Call, it's appropriate that this be posted here an= d people be given a chance to express their opinions on this last-minute ch= ange.=C2=A0 Thus, with the Chairs' approval, I'll post this on Frid= ay absent any sustained objection, and Alexey can then send it off to the e= ditors.

The proposed diff to -05 can be seen here: http://www.b= lackops.org/~msk/diff.html

-MSK
--0000000000003dec9e0580107f47-- From nobody Tue Jan 22 11:17:38 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0216C130F7E for ; Tue, 22 Jan 2019 11:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Foy2GjmgPWPz for ; Tue, 22 Jan 2019 11:17:34 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::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 35483130F1B for ; Tue, 22 Jan 2019 11:17:34 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id t18-v6so21683245ljd.4 for ; Tue, 22 Jan 2019 11:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2k1+eYCgd2HgR5FIw+b1LIaoXq2FxDiJcSuMQqXfeLI=; b=sV/eGRCiL4zTH+Svoe++UrjAVwBTe5R0Eu8TO+nbQFxMeisg80qDBj2+64OLzCGFIv ZmFIo8WwJlFPQc6q9lSLzJ3redBqkz03E5CFQ6hhfaWz0336L2waHbUmTRs1et26y2F6 PTi+OsLfb1WL64kVadgvp1nVmeiu1zUySItBJdHd3avoj3PI8v+esvbri6kMmuW8ZN7a 748o6qyfLSoAWOemWieO6pZZploGsQ7mjZvoHI5kfNoZQ0M0c16VK02/r3m8vCZBUD2H 8vHKV1Ka5FDrhdKnxkdyfDXHb4sGS4dhl/3JODPqQy4FOG9bI0Fo3uG3Tk6U3Zt9g7hq ut9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2k1+eYCgd2HgR5FIw+b1LIaoXq2FxDiJcSuMQqXfeLI=; b=jtpriSkQxPKwXTc5uKFCgKnkDY4Z0OzyNifOeIris4IjlNE4CU3eCmDpZWJNijdtJC zftBjb1c9NF31zE3cHDYSX8Xv/ivuNURP8a+mXDKmpUJ6YGZhurQCcJnB/C20Ij1BWQI J27WsYBuCGeQ0+jVBDFJNUC+fwJTGFv9b5AN7N+nmBZ3ZOnpH75dgWAg5WexaZ3rZZrM /jcB/4YPtUaN2fFgEUG0/YOKfuiwegh+gIxE1lmYUzx3dpUjb5IoeKeGT84mzSjdWwbD Q+wjZTX118TmgEp9PwII4XURCFrudWN2qUTsP9ogMU1glKz5stDnZCxxvnz5qBazF9Xv vofQ== X-Gm-Message-State: AJcUukf+SMO/9RU3oHU6APgyBdxkwivjeSURNIgjogumqnKsLGLH8yYF 6xyut8YVgH0ZoCAv/C2b2beFsRZtA7cr6PPB94m4iQ== X-Google-Smtp-Source: ALg8bN6UIPPJUEXADDE2PN4eV/oJHPJw+rhONG/PbfHAY8DID7Mj+CM6lnmrkRRRX94Etlf54Jk8ME2kTz4NCGqFnvY= X-Received: by 2002:a2e:9ad0:: with SMTP id p16-v6mr23259426ljj.102.1548184652210; Tue, 22 Jan 2019 11:17:32 -0800 (PST) MIME-Version: 1.0 References: <2393746.3XrAvFVKfY@kitterma-e6430> <5694407E-6D84-4266-93DE-21FB90D803B2@kitterman.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 22 Jan 2019 11:17:19 -0800 Message-ID: To: Seth Blank Cc: IETF DMARC WG , Scott Kitterman Content-Type: multipart/alternative; boundary="0000000000003def21058010d412" Archived-At: Subject: Re: [dmarc-ietf] Fwd: Proposed charter spiff to accept EAI clarification within email authentication stack X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jan 2019 19:17:37 -0000 --0000000000003def21058010d412 Content-Type: text/plain; charset="UTF-8" I'm pretty sure charter adjustments are independent of WGLC (which is to say don't hold up one with the other). -MSK On Tue, Jan 22, 2019 at 10:09 AM Seth Blank wrote: > Scott, does this need to be addressed during WGLC for draft-levine-eaiauth? > > ---------- Forwarded message --------- > From: Scott Kitterman > Date: Sun, Nov 4, 2018 at 9:14 PM > Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI > clarification within email authentication stack > To: Kurt Andersen (b) > Cc: dmarc@ietf.org > > > > > On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" > wrote: > >This came out of this morning's DISPATCH meeting at IETF103 ( > >https://tools.ietf.org/wg/dispatch/agenda) to be able to accept > >http://tools.ietf.org/html?draft=draft-levine-appsarea-eaiauth into the > >WG > >for advancing it to an RFC (probably informational). > > Thanks. It doesn't appear that it proposes any changes for SPF. It > merely documents that non-ascii local parts don't match the related > macros. During the SPFbis working group we looked at this and explicitly > decided on it. It's not by accident. > > Since local part macros are very rarely used, it seemed like very much a > corner case not worth it to break the installed base over. > > If there's going to be a charter change around this, I think it needs some > words to constrain the work to limit interoperability implications. > > I know less about the implications for DKIM and DMARC, but would imagine > backward compatibility is important there too. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000003def21058010d412 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm pretty sure charter adjustments are independe= nt of WGLC (which is to say don't hold up one with the other).

-MSK

On Tue, Jan 22, 2019 at 10:09 AM Seth Blank = <seth@sethblank.com> wrote:=
Scott, does this need to be addressed during WGLC for draft-levine-eaiaut= h?

---------- Forwarded = message ---------
From: = Scott Kitterman <sklist@kitterman.com>
Date: = Sun, Nov 4, 2018 at 9:14 PM
Subject: Re: [dmarc-ietf] Proposed charter s= piff to accept EAI clarification within email authentication stack
To: K= urt Andersen (b) <= kboth@drkurt.com>
Cc: dmarc@ietf.org <dmarc@ietf.org>




On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <kboth@drkurt.com> w= rote:
>This came out of this morning's DISPATCH meeting at IETF103 (
>https://tools.ietf.org/wg/dispatch/agenda) to be ab= le to accept
>http://tools.ietf.org/html?draft= =3Ddraft-levine-appsarea-eaiauth into the
>WG
>for advancing it to an RFC (probably informational).

Thanks.=C2=A0 It doesn't appear that it proposes any changes for SPF.= =C2=A0 It merely documents that non-ascii local parts don't match the r= elated macros.=C2=A0 During the SPFbis working group we looked at this and = explicitly decided on it.=C2=A0 It's not by accident.

Since local part macros are very rarely used, it seemed like very much a co= rner case not worth it to break the installed base over.

If there's going to be a charter change around this, I think it needs s= ome words to constrain the work to limit interoperability implications.

I know less about the implications for DKIM and DMARC, but would imagine ba= ckward compatibility is important there too.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000003def21058010d412-- From nobody Tue Jan 22 12:09:13 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1688B130F72 for ; Tue, 22 Jan 2019 12:09:12 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=8zKsXC5S; dkim=pass (2048-bit key) header.d=kitterman.com header.b=EqTilJ0m 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 VYPy9K8IRuDS for ; Tue, 22 Jan 2019 12:09:10 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DBB128AFB for ; Tue, 22 Jan 2019 12:09:10 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1548187748; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=WoUN2pwScHhpO11psbK9PYwchcBf1DS7Kk5Hy8YzHik=; b=8zKsXC5Sldb6Erlk7SGyJbGG1/Ybyo/49admlmbROnYQGpk7MOEqSE/0 GrMxB5MMZ7pr1JjHs24Majf0ZzhABA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1548187748; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=WoUN2pwScHhpO11psbK9PYwchcBf1DS7Kk5Hy8YzHik=; b=EqTilJ0mRj3Aac/L5UIqyLE9YWOTnGMI9p9vNlH7vRgjlkO3heLyRBKB ejOlAL/zW4lNZdft/G3ibHoBycFxoz0sHI3BCqj6Hg9543wmx11MmLhcq4 rKXZHX4dvp0jHv/1WymqZnIbOsyAIyoArf4zXS25KoHHGPCuBpLtter+F+ 1ClxAo/zhspT6iKzN+zqUY5YnSCRlgXDpxT3KYElUBYXETPUERv++P0nnU 4pOUerKfq9ENNb9YXJhYH1QS7vNAyfn8v+DZRrhttoCRyVSBYYLJizS9a6 aA/rnUW3XxFhdelri4NGjG71WrzbZoXyHPt8eo9XU4pvBg575lsH9Q== Received: from [10.90.67.30] (mobile-166-171-59-116.mycingular.net [166.171.59.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id ACEE52D407A4; Tue, 22 Jan 2019 14:09:08 -0600 (CST) Date: Tue, 22 Jan 2019 20:09:03 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Post-IESG Review edits to RFC7601bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jan 2019 20:09:12 -0000 On January 22, 2019 6:53:33 PM UTC, "Murray S=2E Kucherawy" wrote: >With the posting of -05, we expect the last DISCUSSes to clear (one >already >has) and the document can proceed=2E > >During DISCUSS discussions, it was pointed out that the ADSP, Sender >ID, >and DomainKeys specifications bear "Historic" status, and thus they >should >not be carried forward into the new version; they will continue to >exist in >the Authentication-Results registries, but their status will be changed >to >"deprecated" and their defining documents will be left at RFC7601, >while >the others that are still current will remain "active" and their >defining >documents will be updated to point to this new one=2E > >As this wasn't expressly part of the Working Group Last Call, it's >appropriate that this be posted here and people be given a chance to >express their opinions on this last-minute change=2E Thus, with the >Chairs' >approval, I'll post this on Friday absent any sustained objection, and >Alexey can then send it off to the editors=2E > >The proposed diff to -05 can be seen here: >http://www=2Eblackops=2Eorg/~msk/diff=2Ehtml > >-MSK According to the rules of the registry (as described in RFC 7601), a desig= nated expert can change entries to deprecated without a specification=2E No need to tie this to 7601bis=2E Just ask IANA to make the changes (sinc= e you're the primary designated expert)=2E If you do that, then dropping them from 7601bis is obviously correct=2E I= think it's correct anyway, but that's cleaner=2E Scott K From nobody Tue Jan 22 12:27:53 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A085513105D for ; Tue, 22 Jan 2019 12:27:51 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 qrYyiep5Lkvb for ; Tue, 22 Jan 2019 12:27:49 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 C8B1D13103C for ; Tue, 22 Jan 2019 12:27:48 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id h65so22047402ith.3 for ; Tue, 22 Jan 2019 12:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kOF7lKdxZybm1PDhsguhvhItCGjxxag/d6iHA1LPzTE=; b=ay5nWInrf/IN537QdZwOzWBHTCMi3ZVdkFRyL0viDD6qPkrYpPKBpOlfK1DkOAsQXj z/sijQKYgb9+2V5rTj3Kakf/XwNwP1V9dxr99vJTWwZrwhhdf/HdLeR0f4C5GJRQcF+W vaSZgKJgS60oVu+7pB/VRnBSKs/ME/tZ4Rqbo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kOF7lKdxZybm1PDhsguhvhItCGjxxag/d6iHA1LPzTE=; b=jJ2DD101pQdFQO5TFrm7F3TzzRyrR4CbIuSz5/Fag0U9a+MrrFmUf0fD2OMbybQgYq bb+2E25DqBz/b14z5ZJ4tNumaO+ldasSAv7UmiRQ00o3R2NtAsE0vq+OOSc0vh7d7oNB 47EILJPsxRjo53WLwbFxF8g01sGQuu0PO1hB+048IgJTY2Dkx6QNLJx3JTLeFSv3elgq WB5l+ftao4sNE0mPPjMLUbYHXTB2ad76cpmaEi8sqy8iVURG884aCvLU8hr778GsbTDR AjwwS01s+FHhOhITgzvXUGAymMyQmR9HorxrKp61oi+eMq/rMS/WtYPBj/kbu3CZcV5+ OqLA== X-Gm-Message-State: AHQUAub4Yz586pLVZEG9S1okkcTjHbqh+v6l9ruA66r6VSJg1GJM7qon pOYyrzecL4XgwAVHbUy2aiVo37XxhaZfXQzdt2znvw== X-Google-Smtp-Source: ALg8bN75buVIvUvhqicAbHDVEqrTc8G++cYjZxKr5YQuuGuaa0osP14cXU22MFuJ8J4Bww5HvqEa6hj1iLhSqiTsbZA= X-Received: by 2002:a05:660c:12c7:: with SMTP id k7mr2621itd.148.1548188867911; Tue, 22 Jan 2019 12:27:47 -0800 (PST) MIME-Version: 1.0 References: <2393746.3XrAvFVKfY@kitterma-e6430> <5694407E-6D84-4266-93DE-21FB90D803B2@kitterman.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Tue, 22 Jan 2019 10:27:36 -1000 Message-ID: To: "Murray S. Kucherawy" Cc: Seth Blank , IETF DMARC WG , Scott Kitterman Content-Type: multipart/alternative; boundary="00000000000084767b058011cf2a" Archived-At: Subject: [dmarc-ietf] Does EAI doc need to flag SPF macro implications more explicitly? (was: Proposed charter spiff ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jan 2019 20:27:52 -0000 --00000000000084767b058011cf2a Content-Type: text/plain; charset="UTF-8" I think that Seth is referring to Scott's "merely" designation: It doesn't appear that it proposes any changes for SPF. It merely > documents that non-ascii local parts don't match the related macros. > During the SPFbis working group we looked at this and explicitly decided on > it. It's not by accident. > Since local part macros are very rarely used, it seemed like very much a > corner case not worth it to break the installed base over. rather than the charter change itself. I did not read this as something that needed to change in the document unless Scott is looking for bold flashing lights around it :-) --Kurt On Tue, Jan 22, 2019 at 9:17 AM Murray S. Kucherawy wrote: > I'm pretty sure charter adjustments are independent of WGLC (which is to > say don't hold up one with the other). > > -MSK > > On Tue, Jan 22, 2019 at 10:09 AM Seth Blank wrote: > >> Scott, does this need to be addressed during WGLC for >> draft-levine-eaiauth? >> >> ---------- Forwarded message --------- >> From: Scott Kitterman >> Date: Sun, Nov 4, 2018 at 9:14 PM >> Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI >> clarification within email authentication stack >> To: Kurt Andersen (b) >> Cc: dmarc@ietf.org >> >> >> >> >> On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" >> wrote: >> >This came out of this morning's DISPATCH meeting at IETF103 ( >> >https://tools.ietf.org/wg/dispatch/agenda) to be able to accept >> >http://tools.ietf.org/html?draft=draft-levine-appsarea-eaiauth into the >> >WG >> >for advancing it to an RFC (probably informational). >> >> Thanks. It doesn't appear that it proposes any changes for SPF. It >> merely documents that non-ascii local parts don't match the related >> macros. During the SPFbis working group we looked at this and explicitly >> decided on it. It's not by accident. >> >> Since local part macros are very rarely used, it seemed like very much a >> corner case not worth it to break the installed base over. >> >> If there's going to be a charter change around this, I think it needs >> some words to constrain the work to limit interoperability implications. >> >> I know less about the implications for DKIM and DMARC, but would imagine >> backward compatibility is important there too. >> >> Scott K >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000084767b058011cf2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that Seth is referring to Scott&#= 39;s "merely" designation:

It doesn't appear that it proposes any change= s for SPF.=C2=A0 It merely documents that non-ascii local parts don't m= atch the related macros.=C2=A0 During the SPFbis working group we looked at= this and explicitly decided on it.=C2=A0 It's not by accident.
Sinc= e local part macros are very rarely used, it seemed like very much a corner= case not worth it to break the installed base over.

<= /div>
rather than the charter change itself. I did not read this as som= ething that needed to change in the document unless Scott is looking for bo= ld flashing lights around it :-)

--Kurt=C2=A0

On Tue, Jan 22, 2019 at 9:17 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
I'm prett= y sure charter adjustments are independent of WGLC (which is to say don'= ;t hold up one with the other).

-MSK

On Tue, Jan 22, 2019 at 10:09 AM Seth Blank <seth@sethblank.com&= gt; wrote:
Scott, does this need to be addressed during WGLC for draft-lev= ine-eaiauth?

---------- = Forwarded message ---------
From: Scott Kitterman <sklist@kitterman.com>=
Date: Sun, Nov 4, 2018 at 9:14 PM
Subject: Re: [dmarc-ietf] Proposed= charter spiff to accept EAI clarification within email authentication stac= k
To: Kurt Andersen (b) <kboth@drkurt.com>
Cc: dmarc@ietf.org <dmarc@ietf.org>




On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <kboth@drkurt.com> w= rote:
>This came out of this morning's DISPATCH meeting at IETF103 (
>https://tools.ietf.org/wg/dispatch/agenda) to be ab= le to accept
>http://tools.ietf.org/html?draft= =3Ddraft-levine-appsarea-eaiauth into the
>WG
>for advancing it to an RFC (probably informational).

Thanks.=C2=A0 It doesn't appear that it proposes any changes for SPF.= =C2=A0 It merely documents that non-ascii local parts don't match the r= elated macros.=C2=A0 During the SPFbis working group we looked at this and = explicitly decided on it.=C2=A0 It's not by accident.

Since local part macros are very rarely used, it seemed like very much a co= rner case not worth it to break the installed base over.

If there's going to be a charter change around this, I think it needs s= ome words to constrain the work to limit interoperability implications.

I know less about the implications for DKIM and DMARC, but would imagine ba= ckward compatibility is important there too.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000084767b058011cf2a-- From nobody Tue Jan 22 12:39:44 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BDA1310E4 for ; Tue, 22 Jan 2019 12:39:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 YKMkGDP8vpVZ for ; Tue, 22 Jan 2019 12:39:41 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 07F1613101B for ; Tue, 22 Jan 2019 12:39:41 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id k2so20259052iog.7 for ; Tue, 22 Jan 2019 12:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v8/xq9WdP7kTG7nG2or4FcT6P4qoH2YXCYvGcQLE558=; b=VcamfSIjymn/IJegDeDfsAX/Pi1F8KHi0wh7VsssM2b19vYlXG1GDNdk6p8XW29WrD wI7ktoRNcRCORoeyW8NHH7BsdGOg6i8meAyD+EgbdSznj7YbxYT2BnB10IP2giHhU5Dn Uf0kJODP5+1L2bMJOqDEMylXN5qC1p0DIGQks= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v8/xq9WdP7kTG7nG2or4FcT6P4qoH2YXCYvGcQLE558=; b=hC+DS6CBUzmgEszslxa1wLme7JPA449zfzlblrvWXsQ+WroJJ4APShFldDK3Li0z/s Cw4Qw8SE/+c7oL0xsL7XGJh1GDXQfCj5izuxn8alP+ltI2Nm9bj6bhv7YUrFDHqrjgQa 5EsBFsF0Hh/9IncWbtYFgjfbIIyv9X7QM5ySQjaCpI+03cx0bc80dUa5+Mpz7MWKsx6x 0H1MOQpCl95y0+bfcxf8KHHOc6O0XSCC1WKvW9jo0XzIcsNBUGMuZflqIi+yz7GubaQJ 1iScWlWKxdHZYxwEJO0PcMB0gPMZgqy+4IX1ZATEwrhUkearUIbrmaw9NfKhspPHB61z EOcw== X-Gm-Message-State: AJcUukepbaH1ndoQ2C9i6o9xrKGY7oe44STO8qYEtySCiV/snmwhl4+x A/5Ti9QtizGJKFH8KRVGhJnoKgjiFyOXLjwMVWg9RQFUm0E= X-Google-Smtp-Source: ALg8bN5jIBMUF+s7uf7f0gLPryXSEgFPbpsCZmMLAX0Wf6ihu8wi6Snfpo7GP15HDiPFgf7p6hcjUH9N0rV8KaCslLw= X-Received: by 2002:a5d:8597:: with SMTP id f23mr21251900ioj.238.1548189580151; Tue, 22 Jan 2019 12:39:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Tue, 22 Jan 2019 10:39:28 -1000 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f85d6c058011f9b3" Archived-At: Subject: Re: [dmarc-ietf] Post-IESG Review edits to RFC7601bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jan 2019 20:39:43 -0000 --000000000000f85d6c058011f9b3 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 22, 2019 at 10:09 AM Scott Kitterman wrote: > > According to the rules of the registry (as described in RFC 7601), a > designated expert can change entries to deprecated without a specification. > > No need to tie this to 7601bis. Just ask IANA to make the changes (since > you're the primary designated expert). > It's not so much a matter of tying it to 7601bis - there's just one or two sentences in the IANA considerations to make it happen. It's more a matter of cleaning out the obsolete sections of 7601 rather than carrying forward verbiage about obsolete protocols. --Kurt --000000000000f85d6c058011f9b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 22, 2019 at 10:09 AM Scott Ki= tterman <sklist@kitterman.com> wrote:

According to the rules of the registry (as described in RFC 7601), a design= ated expert can change entries to deprecated without a specification.

No need to tie this to 7601bis.=C2=A0 Just ask IANA to make the changes (si= nce you're the primary designated expert).
--000000000000f85d6c058011f9b3-- From nobody Tue Jan 22 13:18:17 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FCC1310FD for ; Tue, 22 Jan 2019 13:18:15 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=ROuOC93e; dkim=pass (2048-bit key) header.d=kitterman.com header.b=txRdsC1p 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 Ja94Xn2Alu5q for ; Tue, 22 Jan 2019 13:18:13 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1574E1310F8 for ; Tue, 22 Jan 2019 13:18:13 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1548191891; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=SLQYlYoXIhgd64pH7BqyGsko83NDK8lzWJ0YfHrXIwI=; b=ROuOC93ePOspmqIeQyp+ZKZfKm4NN0nU1fHM8lR/l9bTPIkKlm8zuGGj qF4pF2G3exOCh3Ggh96xwh5OdsEpCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1548191891; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=SLQYlYoXIhgd64pH7BqyGsko83NDK8lzWJ0YfHrXIwI=; b=txRdsC1peuILx53J6e8ukDSphGr2vWTnpFY+UJ4kFISoKZPjz+++Mvkg K6EZC8eupIuMQpbgfrFZWS6PGTwkwvt/0PRIT9Wd5tFH38TGSa4gfsF2L0 wvHyMnNKRRsEre2XIrxe/4//VfFto0LsBoiOfJV43I5293m4IbIIFwTidi ELOLQA3/sBX2uiMwT4ZnSMKmS02885a+jzc/kpYNEB9RJ+bfuXs4E5Tdh5 1+ZqeUwFvgmzgK4vvnvDGMZ0LrThwux9qezR3Wl8zg82m1Lk4lfoH8g58+ 0hZisDuGn2cML/kuDQj2v6pRauodkkw0Mie2x7d3Ou87uF+/O3J73g== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id C9CE82D404E4 for ; Tue, 22 Jan 2019 15:18:11 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 22 Jan 2019 16:18:10 -0500 Message-ID: <2183408.rbh8fdV8Tg@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Does EAI doc need to flag SPF macro implications more explicitly? (was: Proposed charter spiff ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jan 2019 21:18:16 -0000 When I wrote that, several months ago, I was concerned there might be an incompatible update. I don't see any problems with the draft as it currently stands, so no issue. What's there describes things correctly. Scott K On Tuesday, January 22, 2019 10:27:36 AM Kurt Andersen wrote: > I think that Seth is referring to Scott's "merely" designation: > > It doesn't appear that it proposes any changes for SPF. It merely > > > documents that non-ascii local parts don't match the related macros. > > During the SPFbis working group we looked at this and explicitly decided > > on > > it. It's not by accident. > > Since local part macros are very rarely used, it seemed like very much a > > corner case not worth it to break the installed base over. > > rather than the charter change itself. I did not read this as something > that needed to change in the document unless Scott is looking for bold > flashing lights around it :-) > > --Kurt > > On Tue, Jan 22, 2019 at 9:17 AM Murray S. Kucherawy > > wrote: > > I'm pretty sure charter adjustments are independent of WGLC (which is to > > say don't hold up one with the other). > > > > -MSK > > > > On Tue, Jan 22, 2019 at 10:09 AM Seth Blank wrote: > >> Scott, does this need to be addressed during WGLC for > >> draft-levine-eaiauth? > >> > >> ---------- Forwarded message --------- > >> From: Scott Kitterman > >> Date: Sun, Nov 4, 2018 at 9:14 PM > >> Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI > >> clarification within email authentication stack > >> To: Kurt Andersen (b) > >> Cc: dmarc@ietf.org > >> > >> > >> > >> > >> On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" > >> > >> > >> wrote: > >> >This came out of this morning's DISPATCH meeting at IETF103 ( > >> >https://tools.ietf.org/wg/dispatch/agenda) to be able to accept > >> >http://tools.ietf.org/html?draft=draft-levine-appsarea-eaiauth into the > >> >WG > >> >for advancing it to an RFC (probably informational). > >> > >> Thanks. It doesn't appear that it proposes any changes for SPF. It > >> merely documents that non-ascii local parts don't match the related > >> macros. During the SPFbis working group we looked at this and explicitly > >> decided on it. It's not by accident. > >> > >> Since local part macros are very rarely used, it seemed like very much a > >> corner case not worth it to break the installed base over. > >> > >> If there's going to be a charter change around this, I think it needs > >> some words to constrain the work to limit interoperability implications. > >> > >> I know less about the implications for DKIM and DMARC, but would imagine > >> backward compatibility is important there too. > >> > >> Scott K > >> > >> _______________________________________________ > >> dmarc mailing list > >> dmarc@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmarc > >> _______________________________________________ > >> dmarc mailing list > >> dmarc@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmarc > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Jan 22 13:19:34 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D081310FC for ; Tue, 22 Jan 2019 13:19:31 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=2Gxgb9oO; dkim=pass (2048-bit key) header.d=kitterman.com header.b=oQ/liU1m 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 V7zVudytO3ek for ; Tue, 22 Jan 2019 13:19:30 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4488D1310F8 for ; Tue, 22 Jan 2019 13:19:30 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1548191969; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=EEGdSqsZmYkToIc4W65P3S3X8nGbdYZ33/F25NUXtoA=; b=2Gxgb9oOmz1kHRdx3Zt5Tkkz63PGlFCORsjhOwK/OzLX907H59TRC4Zf sfF11eJAzJpI7rj0yn7y5i7JtnUSBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1548191969; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=EEGdSqsZmYkToIc4W65P3S3X8nGbdYZ33/F25NUXtoA=; b=oQ/liU1mpL8STvqioZM+RaMGVoASVyWtrmoxaauDQrxHZsVnJkFMcSuK W5tERWq+Sy9hQ7Xqo8ro4wCmjgRb6MaWfCdXeNr5jlRwfEEymQfX2BR92k dU+3RIz62GSdCoN5w5GUX7wt8vEND90WMQSjMQDv7QJLmeESZoyYwBwwKa h+QpSTQ0lR1r+L45o6IsxnYYIalaDTm0cBliefQbAP5R0OARzWUDqjPCGu jm7BZZJiQZkU2xa5IRF9AHEsAPt5IOzidEJlnk6oL0Tq5EvWvbcEqZuPQp fP/AE3gyFXKXyDqyOLsluuakJyf5XBRwgMCivuejoPZqW8u3EQGeVw== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 5F1B22D404E4 for ; Tue, 22 Jan 2019 15:19:29 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 22 Jan 2019 16:19:28 -0500 Message-ID: <3742451.8nFmiOgACY@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <5694407E-6D84-4266-93DE-21FB90D803B2@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Fwd: Proposed charter spiff to accept EAI clarification within email authentication stack X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jan 2019 21:19:32 -0000 For avoidance of doubt: It's draft-ietf-dmarc-eaiauth and no. It's fine. Scott K On Tuesday, January 22, 2019 10:08:41 AM Seth Blank wrote: > Scott, does this need to be addressed during WGLC for draft-levine-eaiauth? > > ---------- Forwarded message --------- > From: Scott Kitterman > Date: Sun, Nov 4, 2018 at 9:14 PM > Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI > clarification within email authentication stack > To: Kurt Andersen (b) > Cc: dmarc@ietf.org > > > > > On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" > > wrote: > >This came out of this morning's DISPATCH meeting at IETF103 ( > >https://tools.ietf.org/wg/dispatch/agenda) to be able to accept > >http://tools.ietf.org/html?draft=draft-levine-appsarea-eaiauth into the > >WG > >for advancing it to an RFC (probably informational). > > Thanks. It doesn't appear that it proposes any changes for SPF. It merely > documents that non-ascii local parts don't match the related macros. > During the SPFbis working group we looked at this and explicitly decided on > it. It's not by accident. > > Since local part macros are very rarely used, it seemed like very much a > corner case not worth it to break the installed base over. > > If there's going to be a charter change around this, I think it needs some > words to constrain the work to limit interoperability implications. > > I know less about the implications for DKIM and DMARC, but would imagine > backward compatibility is important there too. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Jan 22 13:49:30 2019 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 2CA14129A87; Tue, 22 Jan 2019 13:49:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc-chairs@ietf.org, tim@dmarcian.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154819376817.13311.4490788182520189499.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2019 13:49:28 -0800 Archived-At: Subject: [dmarc-ietf] Ben Campbell's No Objection on draft-ietf-dmarc-rfc7601bis-05: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jan 2019 21:49:28 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dmarc-rfc7601bis-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for resolving my DISCUSS points. From nobody Tue Jan 22 21:10:46 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93A2130DFA for ; Tue, 22 Jan 2019 21:10:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PBma41ji9QYw for ; Tue, 22 Jan 2019 21:10:44 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2432127AC2 for ; Tue, 22 Jan 2019 21:10:43 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id n18-v6so745967lji.7 for ; Tue, 22 Jan 2019 21:10:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2z9oIRY02uYztt2hUYIWT8GafFYrsOjjTCuP62ah328=; b=edCA3wKPAdIXYSkehyRpEvjZKSifkjjIUfMbt9fM7QhjlJz5HlkLYNCF0BuLiEspxp vR+fDKaK8UcmFieMyd+qQ2mfnhvRxUoApciCeGszee2wo7zHgCz3zKLezeuN/xPg0paz NM3Xftav6FNiGVYtjpakzT77omVnWQ7R5LpImhrGLjF4jN5UJIHgm8sn3ntYI6EHyWV4 ZTkWC83g2+Pzj9EXbfWemQCd+/hhPnUUhpCwOnF2lRU+yNPgxl5w59IOoHhKQz5aVZsg goKY03eTn7/nkMyJT2Bbw+TxlY2BczqHdFU04MYC8QooS7919Wl2gZbDBGhnK1gYR55N sITw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2z9oIRY02uYztt2hUYIWT8GafFYrsOjjTCuP62ah328=; b=tKWy4S8t/WLL8M4qhWBJgP6GISn+oO1ZtwL/3F5orOpksk8fjhSayMw+Ilx21SQRPw /T3EpLmOvFVkqjejG2w8DgLMbZmtYPnbUuVpXnq0kor7KD3AdAmLCmr7nTfWCABM3pm9 +k57ZZWqpGASQcoeSSRj66iXGQ5rH37nLsFaAL15VGegXRHTxmPwN7jzNET9Ynpk62um vhqZslSgJAWD+Cn+9IV+QyEz0U8Lc8S80e0eeK56FYrxgGHVGCFz+jmO/4G9Mo4+vjrn 7lMscMCwHr4rTrwkND0pcO7cINU8pCyxOsH2A1WJ/8tEfuEJ5zNewuqKsKN+qy5fwgVv teuQ== X-Gm-Message-State: AJcUukd8z5IKigSiRxkkb5SoJwsmQJP69b78MNLHu6QpB4voyynjP5A/ DmPGBQp4NX9xver/Y/46gHoyKEsaHZbrWuOQb4WbyA== X-Google-Smtp-Source: ALg8bN7iVphE/X9f+nPUiPN/Ix1R3IWEnLj2T8aVhAWMsbJ4r6Ja6exDI/PKhe7gPODpq+X0VasFy3pVoGH/VwIDj/k= X-Received: by 2002:a2e:9ad0:: with SMTP id p16-v6mr654253ljj.102.1548220241707; Tue, 22 Jan 2019 21:10:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 22 Jan 2019 21:10:27 -0800 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008a88880580191d2f" Archived-At: Subject: Re: [dmarc-ietf] Post-IESG Review edits to RFC7601bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jan 2019 05:10:46 -0000 --0000000000008a88880580191d2f Content-Type: text/plain; charset="UTF-8" On Tue, Jan 22, 2019 at 12:09 PM Scott Kitterman wrote: > According to the rules of the registry (as described in RFC 7601), a > designated expert can change entries to deprecated without a specification. > True, but that's not the only change here. Not carrying deprecated entries into 7601bis was identified as something cleaner than carrying them forward and then immediately deprecating them. No need to tie this to 7601bis. Just ask IANA to make the changes (since > you're the primary designated expert). Yes, but since I'm also editing this thing now anyway, I may as well take advantage of it. And this way the audit trail is more visible, if that matters to someone. -MSK --0000000000008a88880580191d2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=
-MSK
--0000000000008a88880580191d2f-- From nobody Wed Jan 23 07:07:43 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B21126BED for ; Wed, 23 Jan 2019 07:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com 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 UlrS8jve9oXa for ; Wed, 23 Jan 2019 07:07:39 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 786FA124C04 for ; Wed, 23 Jan 2019 07:07:39 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id a11so2144697otr.10 for ; Wed, 23 Jan 2019 07:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zPBODxlKt7+V4JXK9qNc9sXPc7YrJFPwWWPpsq1DnqM=; b=ukP8He2AUktG/ZdLq8xHg0HYtwhpdxRXz+zMrvRkKThTY7ouYWHarZmQQXVbPuS2G4 qjyayW1K+UbYiSJbHtj2lEODIUIB4JffcruGKq8Ed3PqxesPUfhhUxF+a4yhgD1GfBoz NjaVll3XMMMuE7Y/RJK5NP5LHgqRxofbAZUecCvhQpmIaH48LAfipL23QHOGDJtjWuDi kMAFgkA11fKGJ7ART/+Xfql/gpnQtP4v3/hjhSHYhUrYl/XpxH5uD7gtj7E8jsnnQ6gV tZxMBmDqQ4hpdyBgEwLevtgkgdEMvnx6y4GreVpv4ETFCn2kUB4Gc/aG1TG8GgUaQQXA EPOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zPBODxlKt7+V4JXK9qNc9sXPc7YrJFPwWWPpsq1DnqM=; b=p1AOwjZM8rs9A0TxJwETYlxkwsgo6zDBLZsHItDy/hZ0ZKqBc2a091PlNHoreKJTOo bUiav7Y3UpRICb8mEk3TNOY/ow/LsBFi3OxpB/ie+9iA3kYOPe5Pu9Bou1Trvgdsz2qg f0JUeVmMzaLxEVfYAKc5LmLCBFCsaCdY8rv4wyHFWU8/vtpUQyVcXWoyOY/+VKJqlM+Q 0DQ3U3wvkJgk0huGuXMHV7Ki8OVjjVfEz13rpeeLBa/OaaFFBnKn1E2PIUoKNQJDhROO YCAufnFx+Y7AXEI/tTo7bB32PJU9h8w4fVk8DmDiAuSSPUcMZ0yRHT1lI+yV9HZIGIQ5 qRIQ== X-Gm-Message-State: AJcUukeY7tcR6qmEf9dbc6t+o6d3RyM5vxv4LTdiJX1kTLNyG/6aAn2B Qg5azpnxBkUf0q05nbKKtETBRMKoKOX0SeF56Y5M7xak X-Google-Smtp-Source: ALg8bN6SdW/qy6Rb1TXFmtfLdkkfjqwQPLI93cwD85gTo+JwB2MPGR7A3Rm2Zeh6EJ2HOtHQGcgaxPZH3YO1Y5V4SME= X-Received: by 2002:a9d:d83:: with SMTP id 3mr1524546ots.361.1548256058384; Wed, 23 Jan 2019 07:07:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Wed, 23 Jan 2019 07:07:21 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000061d2ee058021743f" Archived-At: Subject: Re: [dmarc-ietf] Post-IESG Review edits to RFC7601bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jan 2019 15:07:41 -0000 --00000000000061d2ee058021743f Content-Type: text/plain; charset="UTF-8" The changes look good and clean to me, and allow anyone reading 7601bis to understand the deprecated entries without needing to hunt them down in obsoleted documents. On Tue, Jan 22, 2019 at 9:10 PM Murray S. Kucherawy wrote: > On Tue, Jan 22, 2019 at 12:09 PM Scott Kitterman > wrote: > >> According to the rules of the registry (as described in RFC 7601), a >> designated expert can change entries to deprecated without a specification. >> > > True, but that's not the only change here. Not carrying deprecated > entries into 7601bis was identified as something cleaner than carrying them > forward and then immediately deprecating them. > > No need to tie this to 7601bis. Just ask IANA to make the changes (since >> you're the primary designated expert). > > > Yes, but since I'm also editing this thing now anyway, I may as well take > advantage of it. And this way the audit trail is more visible, if that > matters to someone. > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000061d2ee058021743f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The changes look good and clean to me, and allow anyone re= ading 7601bis to understand the deprecated entries without needing to hunt = them down in obsoleted documents.

On Tue, Jan 22, 2019 at 9:10 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Jan 22, 2019 at 12:09 PM Scott Kitterman <sklist@kitterman.com> = wrote:
According to the rules of the registry (as described in R= FC 7601), a designated expert can change entries to deprecated without a sp= ecification.

True, but that's not t= he only change here.=C2=A0 Not carrying deprecated entries into 7601bis was= identified as something cleaner than carrying them forward and then immedi= ately deprecating them.

No need to tie this to 7601bis.=C2=A0 Just ask IANA to make the changes (si= nce you're the primary designated expert).

<= div>Yes, but since I'm also editing this thing now anyway, I may as wel= l take advantage of it.=C2=A0 And this way the audit trail is more visible,= if that matters to someone.

=
-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000061d2ee058021743f-- From nobody Wed Jan 23 07:11:10 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008BA12426A for ; Wed, 23 Jan 2019 07:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com 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 T9K1hUKcAzGB for ; Wed, 23 Jan 2019 07:11:06 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 3A029124D68 for ; Wed, 23 Jan 2019 07:11:06 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id j10so2150236otn.11 for ; Wed, 23 Jan 2019 07:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IlYQZMQBdA6+xycR7wC8r5BAWyCrt80XuMABspypbMM=; b=JijQCRhDor6AA5M0M5W5mzR8sGlTUR0CYD3V3N5RF9ktM1LE6fa3ElPIGXZ7URkke5 G29B3DF/BZf8Hxn3RG2lwHva+4Vv1T2TV0V2Fs3agtID9pIsyUyJtxezA1zlgcXN7lLb AHqo8nPD/2WowokYCgayrsrQS4486yseNbpWHgJHKVkv//Xzmk442xRW5/RMqY9Pe5uU t9vA0gUv3mjh0JwEEPwQHr6tgztbmx7aVk40ouP9Z5kYw/oR+Q8s8Cn7zLrYLG7ZFDyy OpzhHqWskc/M96KW9o8XzZKhFC6TxEGgj/lkTW/YRR4p2tD6LpHkhK+b7Mpo6uwUw5A6 126w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IlYQZMQBdA6+xycR7wC8r5BAWyCrt80XuMABspypbMM=; b=tABUfmaZ+OSOi+PTUIhBRSctnmIfR7T36n8tYvcR7+L5bNdR1X0faMrZ3NViqKEwlO jaT08SitwKcRoKoUyZ3pBToSkg+A80YzBS23q8hxg3bqwIo31bLk/+z4Ji256HtCiC7P 9zWOd8r3MxbrVHe2V1w4c98SwVw8Kgi9O4GHAk3xCKNetN6ARWXsYrzjrL4Tv0PPn37q kajwCeTINQPZwNixNUZO8vtKC0J8sKZ8X+hBVbuSHjmk01D81gwy6HoO4g/4xD968uEv Vpo4p0upNIT3NuV7I/CW8oQMbHrG77q/2gSVK90YLYmFoQG7Y5rJrMl1c56NAIP5UH0I TRFg== X-Gm-Message-State: AJcUukeTcNyc3ymxEfwhA/rTmEb0eYeGxrS5QjKmyr4Gq7QiWESFFnGu sMBkO3RO4l+uiD1cSu6ejJtzOA34atU+7MbzabohBL3x X-Google-Smtp-Source: ALg8bN7QQKOxPI7DkFNmghezRSjVJEKBddDyu/zYXT3NR3zPs3s46fgM+Ufqle46ZbE0piRYlbbnMGfpgowsDgYNjlo= X-Received: by 2002:a9d:6847:: with SMTP id c7mr1721937oto.120.1548256265154; Wed, 23 Jan 2019 07:11:05 -0800 (PST) MIME-Version: 1.0 References: <2183408.rbh8fdV8Tg@kitterma-e6430> In-Reply-To: <2183408.rbh8fdV8Tg@kitterma-e6430> From: Seth Blank Date: Wed, 23 Jan 2019 07:10:48 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b4cbcf05802180cd" Archived-At: Subject: Re: [dmarc-ietf] Does EAI doc need to flag SPF macro implications more explicitly? (was: Proposed charter spiff ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jan 2019 15:11:09 -0000 --000000000000b4cbcf05802180cd Content-Type: text/plain; charset="UTF-8" Excellent, thanks for the clarification. On Tue, Jan 22, 2019 at 1:18 PM Scott Kitterman wrote: > When I wrote that, several months ago, I was concerned there might be an > incompatible update. I don't see any problems with the draft as it > currently > stands, so no issue. What's there describes things correctly. > > Scott K > > On Tuesday, January 22, 2019 10:27:36 AM Kurt Andersen wrote: > > I think that Seth is referring to Scott's "merely" designation: > > > > It doesn't appear that it proposes any changes for SPF. It merely > > > > > documents that non-ascii local parts don't match the related macros. > > > During the SPFbis working group we looked at this and explicitly > decided > > > on > > > it. It's not by accident. > > > Since local part macros are very rarely used, it seemed like very much > a > > > corner case not worth it to break the installed base over. > > > > rather than the charter change itself. I did not read this as something > > that needed to change in the document unless Scott is looking for bold > > flashing lights around it :-) > > > > --Kurt > > > > On Tue, Jan 22, 2019 at 9:17 AM Murray S. Kucherawy > > > > > wrote: > > > I'm pretty sure charter adjustments are independent of WGLC (which is > to > > > say don't hold up one with the other). > > > > > > -MSK > > > > > > On Tue, Jan 22, 2019 at 10:09 AM Seth Blank > wrote: > > >> Scott, does this need to be addressed during WGLC for > > >> draft-levine-eaiauth? > > >> > > >> ---------- Forwarded message --------- > > >> From: Scott Kitterman > > >> Date: Sun, Nov 4, 2018 at 9:14 PM > > >> Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI > > >> clarification within email authentication stack > > >> To: Kurt Andersen (b) > > >> Cc: dmarc@ietf.org > > >> > > >> > > >> > > >> > > >> On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" > > >> > > >> > > >> wrote: > > >> >This came out of this morning's DISPATCH meeting at IETF103 ( > > >> >https://tools.ietf.org/wg/dispatch/agenda) to be able to accept > > >> >http://tools.ietf.org/html?draft=draft-levine-appsarea-eaiauth into > the > > >> >WG > > >> >for advancing it to an RFC (probably informational). > > >> > > >> Thanks. It doesn't appear that it proposes any changes for SPF. It > > >> merely documents that non-ascii local parts don't match the related > > >> macros. During the SPFbis working group we looked at this and > explicitly > > >> decided on it. It's not by accident. > > >> > > >> Since local part macros are very rarely used, it seemed like very > much a > > >> corner case not worth it to break the installed base over. > > >> > > >> If there's going to be a charter change around this, I think it needs > > >> some words to constrain the work to limit interoperability > implications. > > >> > > >> I know less about the implications for DKIM and DMARC, but would > imagine > > >> backward compatibility is important there too. > > >> > > >> Scott K > > >> > > >> _______________________________________________ > > >> dmarc mailing list > > >> dmarc@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dmarc > > >> _______________________________________________ > > >> dmarc mailing list > > >> dmarc@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dmarc > > > > > > _______________________________________________ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000b4cbcf05802180cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Excellent, thanks for the clarification.

On Tue, Jan 22, 2019 at 1:18 PM Scott K= itterman <sklist@kitterman.com> wrote:
Wh= en I wrote that, several months ago, I was concerned there might be an
incompatible update.=C2=A0 I don't see any problems with the draft as i= t currently
stands, so no issue.=C2=A0 What's there describes things correctly.

Scott K

On Tuesday, January 22, 2019 10:27:36 AM Kurt Andersen wrote:
> I think that Seth is referring to Scott's "merely" desig= nation:
>
> It doesn't appear that it proposes any changes for SPF.=C2=A0 It m= erely
>
> > documents that non-ascii local parts don't match the related = macros.
> > During the SPFbis working group we looked at this and explicitly = decided
> > on
> > it.=C2=A0 It's not by accident.
> > Since local part macros are very rarely used, it seemed like very= much a
> > corner case not worth it to break the installed base over.
>
> rather than the charter change itself. I did not read this as somethin= g
> that needed to change in the document unless Scott is looking for bold=
> flashing lights around it :-)
>
> --Kurt
>
> On Tue, Jan 22, 2019 at 9:17 AM Murray S. Kucherawy <superuser@gmail.com>
>
> wrote:
> > I'm pretty sure charter adjustments are independent of WGLC (= which is to
> > say don't hold up one with the other).
> >
> > -MSK
> >
> > On Tue, Jan 22, 2019 at 10:09 AM Seth Blank <seth@sethblank.com> wrote: > >> Scott, does this need to be addressed during WGLC for
> >> draft-levine-eaiauth?
> >>
> >> ---------- Forwarded message ---------
> >> From: Scott Kitterman <sklist@kitterman.com>
> >> Date: Sun, Nov 4, 2018 at 9:14 PM
> >> Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EA= I
> >> clarification within email authentication stack
> >> To: Kurt Andersen (b) <kboth@drkurt.com>
> >> Cc: dmarc= @ietf.org <dmarc= @ietf.org>
> >>
> >>
> >>
> >>
> >> On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)&q= uot;
> >> <kbo= th@drkurt.com>
> >>
> >> wrote:
> >> >This came out of this morning's DISPATCH meeting at I= ETF103 (
> >> >https://tools.ietf.org/wg/dispatch/agenda= ) to be able to accept
> >> >http://tools.ietf.= org/html?draft=3Ddraft-levine-appsarea-eaiauth into the
> >> >WG
> >> >for advancing it to an RFC (probably informational).
> >>
> >> Thanks.=C2=A0 It doesn't appear that it proposes any chan= ges for SPF.=C2=A0 It
> >> merely documents that non-ascii local parts don't match t= he related
> >> macros.=C2=A0 During the SPFbis working group we looked at th= is and explicitly
> >> decided on it.=C2=A0 It's not by accident.
> >>
> >> Since local part macros are very rarely used, it seemed like = very much a
> >> corner case not worth it to break the installed base over. > >>
> >> If there's going to be a charter change around this, I th= ink it needs
> >> some words to constrain the work to limit interoperability im= plications.
> >>
> >> I know less about the implications for DKIM and DMARC, but wo= uld imagine
> >> backward compatibility is important there too.
> >>
> >> Scott K
> >>
> >> _______________________________________________
> >> dmarc mailing list
> >> dmarc@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/dma= rc
> >> _______________________________________________
> >> dmarc mailing list
> >> dmarc@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/dma= rc
> >
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/dmarc=

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000b4cbcf05802180cd-- From nobody Fri Jan 25 16:15:33 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBEC12DDA3 for ; Fri, 25 Jan 2019 16:15:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 3nL52zyOdmMS for ; Fri, 25 Jan 2019 16:15:29 -0800 (PST) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 AE0811295D8 for ; Fri, 25 Jan 2019 16:15:28 -0800 (PST) Received: by mail-io1-xd42.google.com with SMTP id x6so9146922ioa.9 for ; Fri, 25 Jan 2019 16:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T/7pOHqcxhhITdxFMQvHCRJnY2yHkyen16szts0DXSw=; b=L7qyWSXJHSmP6dCsUK1xCdgfwJqvn1aYmbOF3Ct4d3L41cp0QZqnXpaYMqKbPupFUk 2IoMv98kspMLGM5wm3x2APxXjoDfsPDNWtkrRQlMqIMETV3f/SfTAWtQ1FD/JIf2TBze HFJR0YLAnJjRhxSEEb0xXjtXCPhuzzsVntqAA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T/7pOHqcxhhITdxFMQvHCRJnY2yHkyen16szts0DXSw=; b=f3MBLX81jxQMzS4YcipbfjRdHHh6GMSHw1sd04H5pYAIeW6CflsnFxAwqvqOhw5YEg V22Ug09z7ZXosziJAgl+nCwTnDuqGlZqqK7RzRAUSKXei9Wf1fDrHvEcAmLaVZ3MaHAl qzAUbiQqMe6dQf6BEhVyd0Gj4WIGrtbIppSaiPfhjYzuYIHKh7Q/c7Oz1/R+XV31Bx5M PdC6UVDdsnVLhFTWPiMAbGqvytb9pUMWFKKp29vUysgwDvU0XeCP+Z97JDwFhSijwYUy 2/4BAFi+DMHX3A03UEPKgNLiDO0WX+yIi9aI2XovGXdPPWbIiQ9FfDiyO4xtcRvbGkxo I3pw== X-Gm-Message-State: AHQUAuaW/ztIhXL+Kt+EBir/KFCwP946AdhZgdh2sjW3YyEj2zGrcQFw L0JL8DfvVUYYujiIn7xEsGUNI+5xFrlvO7e318wRE7y5v2KBZQ== X-Google-Smtp-Source: AHgI3IZByGXPD44qmDQBUNrDAzePsFyn7/hMkVyYbTzH5pS8EDCPSU1z5BtnVxZbx1eWdAu5zCQT/hiO7j1yMYZyQ3c= X-Received: by 2002:a6b:6306:: with SMTP id p6mr8085786iog.196.1548461727754; Fri, 25 Jan 2019 16:15:27 -0800 (PST) MIME-Version: 1.0 References: <20190125221241.4D54E200D31436@ary.qy> <3b0e2e2fe48ec290fb51f4623a4e8d114d6b143f.camel@aegee.org> In-Reply-To: <3b0e2e2fe48ec290fb51f4623a4e8d114d6b143f.camel@aegee.org> From: "Kurt Andersen (b)" Date: Fri, 25 Jan 2019 14:15:16 -1000 Message-ID: To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , "dmarc@ietf.org" Cc: John Levine Content-Type: multipart/alternative; boundary="0000000000003b46c10580515797" Archived-At: Subject: Re: [dmarc-ietf] [ietf-smtp] ietf-smtp@ietf.org and DMARC with p=quarantine; pct=0 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 00:15:31 -0000 --0000000000003b46c10580515797 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is worthwhile, if aspirational, input to a future phase of the DMARC WG (added to the distro and moving SMTP to BCC). It is, as you observe, not the current state of the spec. One further complication is that relatively few receivers generate forensic report (ruf), in part due to privacy concerns. As a result, even if the process worked the way you advocate, you won't get much if any information. --Kurt On Fri, Jan 25, 2019 at 1:27 PM =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0= =D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: > Hello, > > at a high level the common interest is to reach a state, where deployed > DMARC works in practice reliably: > - verifiers and signers are compatible > - signature are not broken on their way to the recipients, so no bad > delivery > - the path from sender to recipient always works reliably and whenever > something does not work as expected an individual > failure report is sent > =E2=80=A6 > > Receiving aggregate report, stating 0,1% of mails do not verify DKIM, > shows that signers and verifiers in that > combination are not compatible. The aggregate report does not say whethe= r > the the signer or the verifier does bad job, > it just proves that DMARC is not going to work 100% reliably. This is ba= d > for both parties, as it just means that DMARC > shall not be trusted as it in practice does not work as expected (and > therefore deploying it is=E2=80=A6) > > The individual failure reports provide the means to find exactly what is > going wrong, on which system. To tackle a > failure report I want to be sure that something wrong happened. A failur= e > report for p=3Dnone cannot mean, that something > wrong happened, in particular it does not mean that DMARC is violated. S= o > sending a report on p=3Dnone makes no sense. > > Shall a failure report be sent for p=3Dquarantine; pct=3D0? > https://mailarchive.ietf.org/arch/msg/ietf-dkim/fUGKyF0iE6DmKPJj-qH4XHz4_= Lg > says =E2=80=9Cp=3Dreject;pct=3D0; is to force MLMs to > rewrite From:, so as to > avoid useless reports=E2=80=9D. > > This is discussable but the common aim is to have a state, where reports > get very seldom and every report has an added > value =E2=80=94 indicates a problem that is investigated. Sending too mu= ch > reports, on real and unreal troubles, makes tracking > manually all reports impossible and does not help to make DMARC reliable. > Keep in mind that not every person deploying > DMARC or mailing lists understands DMARC or acknowledges that its MLM > modifies messages but does not change the From: > sender. > > The current discussion does not lead in the direction of reaching the > state, where reports are sent seldom and indicate > troubles, which troubles shall and can be handled in a way, that prevents > happening them again in the future. That > said, the current setups in general do not permit to improve the accuracy > of DKIM/DMARC evaluations. > > There are not only theoretical, but also practical concerns. Having > DKIM-Signature: r=3Dy; =E2=80=A6 in a message, sent over a > mailing list, the From: is changed and DKIM invalidated. Per RFC 6651 a > report is sent. But this report is useless, as > the MLM broke the intentionally the DKIM-Signature, so there is no > information to extract from the report and there is > no approprite handling. > > In summary, the specifications shall be read in such a way, that: > * reports shall only be sent, when the recipient of the report can and > shall take actions to improve the accuracy of > DMARC/DKIM, and > * for the purposes of testing there must be a way only to get reports for > bad situations, without having the bad > consequences. > > Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > --0000000000003b46c10580515797 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is worthwhile, if aspirational, inpu= t to a future phase of the DMARC WG (added to the distro and moving SMTP to= BCC). It is, as you observe, not the current state of the spec.

One further complication is that rel= atively few receivers generate forensic report (ruf), in part due to privac= y concerns. As a result, even if the process worked the way you advocate, y= ou won't get much if any information.

--Kurt

On Fri, Jan 25, 2019 at 1:27 PM =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0= =B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 <dilyan.palauzov@aegee.org> wrote:
Hello,

at a high level the common interest is to reach a state, where deployed DMA= RC works in practice reliably:
- verifiers and signers are compatible
- signature are not broken on their way to the recipients, so no bad delive= ry
- the path from sender to recipient always works reliably and whenever some= thing does not work as expected an individual
failure report is sent
=E2=80=A6

Receiving aggregate report, stating 0,1% of mails do not verify DKIM, shows= that signers and verifiers in that
combination are not compatible.=C2=A0 The aggregate report does not say whe= ther the the signer or the verifier does bad job,
it just proves that DMARC is not going to work 100% reliably.=C2=A0 This is= bad for both parties, as it just means that DMARC
shall not be trusted as it in practice does not work as expected (and there= fore deploying it is=E2=80=A6)

The individual failure reports provide the means to find exactly what is go= ing wrong, on which system.=C2=A0 To tackle a
failure report I want to be sure that something wrong happened.=C2=A0 A fai= lure report for p=3Dnone cannot mean, that something
wrong happened, in particular it does not mean that DMARC is violated.=C2= =A0 So sending a report on p=3Dnone makes no sense.

Shall a failure report be sent for p=3Dquarantine; pct=3D0?=C2=A0
https://mailarchive.ietf.= org/arch/msg/ietf-dkim/fUGKyF0iE6DmKPJj-qH4XHz4_Lg says =E2=80=9Cp=3Dre= ject;pct=3D0; is to force MLMs to
rewrite From:, so as to
avoid useless reports=E2=80=9D.

This is discussable but the common aim is to have a state, where reports ge= t very seldom and every report has an added
value =E2=80=94 indicates a problem that is investigated.=C2=A0 Sending too= much reports, on real and unreal troubles, makes tracking
manually all reports impossible and does not help to make DMARC reliable.= =C2=A0 Keep in mind that not every person deploying
DMARC or mailing lists understands DMARC or acknowledges that its MLM modif= ies messages but does not change the From:
sender.

The current discussion does not lead in the direction of reaching the state= , where reports are sent seldom and indicate
troubles, which troubles shall and can be handled in a way, that prevents h= appening them again in the future.=C2=A0 That
said, the current setups in general do not permit to improve the accuracy o= f DKIM/DMARC evaluations.

There are not only theoretical, but also practical concerns.=C2=A0 Having D= KIM-Signature: r=3Dy; =E2=80=A6 in a message, sent over a
mailing list, the From: is changed and DKIM invalidated.=C2=A0 Per RFC 6651= a report is sent.=C2=A0 But this report is useless, as
the MLM broke the intentionally the DKIM-Signature, so there is no informat= ion to extract from the report and there is
no approprite handling.

In summary, the specifications shall be read in such a way, that:
* reports shall only be sent, when the recipient of the report can and shal= l take actions to improve the accuracy of
DMARC/DKIM, and
* for the purposes of testing there must be a way only to get reports for b= ad situations, without having the bad
consequences.

Regards
=C2=A0 =D0=94=D0=B8=D0=BB=D1=8F=D0=BD
--0000000000003b46c10580515797-- From nobody Sat Jan 26 03:37:50 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE0313119E for ; Sat, 26 Jan 2019 03:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 WEs82_8Hm35C for ; Sat, 26 Jan 2019 03:37:46 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 09AED13119B for ; Sat, 26 Jan 2019 03:37:45 -0800 (PST) Authentication-Results: mail.aegee.org/x0QBbfUm024256; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1548502661; i=dkim+MSA-tls@aegee.org; r=y; bh=ZAr7AirdIm383HBIJ79hhjE8DgOr7hXljSzxPQwXMqs=; h=Subject:From:To:Date; b=Uj1SFul+sSVj/b11ymhYc6SaXxPzdnYp61n3vXatzk0XPpbdCGovuZc5s0wTn8Pjv 2UBHZmvNJPLxU/qlShp7Cak/pWtmh5m1p7d6A/kL0atogH0Tvn/OEcWg/7YmseReGS a9pyMiPASCyZGfb5hORoW/0na2gUVLwKcp4A9Ooz/tQXbseSBiyuxYhJoRjiZfBN0f mtw6TlqGPqw+9B0E2J5xJaWtvdbhIGIy5h4z5Ta/dpzUVU5Q6RS2asr0Ke6R44rK1r Y6FlPEZmARfwrkPDiQj7U68gI/vUWjXsUHMVB6euNtc6fFUez7j5Xy4wXjQbZTmFkh 7fgU+lftfURZr8rOJwjCvwncanR2xoD486cdqTKVipBhiDjjca/mVgqQcLvzE0M1Ml XOEB5uCKaaF76FzlV5ZJ4BHZci+Ryl60FEe7+AbvqxiQR3xjrW5Qk/PCiVwgbnFmU0 veylTDKaJonamYMWhBeGKNTzFM59D6ZuG5Gu7RjEsSzjDa4KVculJMMp5fER3jUfib lsBfid0UWH9RYPBMiDpgwTbAP1aAgctMT2oL0FDixPun7myjBpSRYX3nsL39sOJARt F+Iy4YZ+cjuCVAI0uzxV1hubaEApaaJXjFHzvg/wpq7nkWXqTVlSoGpGOJTwXGUm2Y /jrvikDHOhiHZ7spMlwDRIIg= Authentication-Results: mail.aegee.org/x0QBbfUm024256; dkim=none Received: from Tylan (adsl-62-167-97-198.adslplus.ch [62.167.97.198]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x0QBbfUm024256 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 26 Jan 2019 11:37:41 GMT Message-ID: <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: dmarc@ietf.org Date: Sat, 26 Jan 2019 11:37:41 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.90 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 11:37:49 -0000 Hello, for a smooth working DMARC DKIM signers and verifiers must be interoperatable. When a server DKIM-signs a message and sends it to another server without intermediates, the latter shall be able verify the signature. Imagine, the DKIM validation fails and the ruf= dmarc report email address points to the sending server. What are the privacy concerns in this simple scenario that speak against sending a DMARC/DKIM report to sending server, telling that the DKIM validation fails? https://tools.ietf.org/html/rfc7489#section-9 mentions some privacy thoughts, but these are not applicable when the sending server obviously has already the reported message and no intermediates are involved, that could expose additional information. Regards Дилян From nobody Sat Jan 26 05:26:29 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120A81311BC for ; Sat, 26 Jan 2019 05:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.842 X-Spam-Level: X-Spam-Status: No, score=-2.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 6TopjDwpQey6 for ; Sat, 26 Jan 2019 05:26:24 -0800 (PST) Received: from smtp53.i.mail.ru (smtp53.i.mail.ru [94.100.177.113]) (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 CD9E51311BB for ; Sat, 26 Jan 2019 05:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=gbMyTpz8rA1fRUr/Ohs58SwMkc3Skw6fHL566X/8b3Q=; b=AQHqFlt8Oqil5T6KrUj8sEXlEL1wH+5b6MMos7aVpUAvwXahM8Ind8yuC8S3A4jFNZ8++Uihs2oUprumXI8d+17ICrcv3lFccJbuR3BnyOwGQMyHWCSwJ60ewMgWnTQz7zwd7/p5+aCjeGPqEgzhelKeuMYCKpGEIa+dEYg0gJI=; Received: by smtp53.i.mail.ru with esmtpa (envelope-from ) id 1gnNyW-0002Bp-Hj; Sat, 26 Jan 2019 16:26:21 +0300 To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , dmarc@ietf.org References: <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.camel@aegee.org> From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: <129785b9-952e-611b-cff9-7a909b3fe4a4@corp.mail.ru> Date: Sat, 26 Jan 2019 16:26:18 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.camel@aegee.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: smtp53.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: 890C00A99BF67EFAF8787DE96DB044641DF1F2D11C1BC0D4B9CA1E903B6768C3 X-77F55803: 6115F4D8777AF1675A78504BD2AC294108AEA42614CCE77CA8F2DF7D05A75CCFC6FEBDDEBACE8411FE6FF01A181F7FA3 X-7FA49CB5: 0D63561A33F958A5AFE1CD5B0CC66B9836B9A558B29563816FA8C8E11A0CCF108941B15DA834481FA18204E546F3947C5EF3C447179F0106F6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8B0920FC4EF0AE1D47A471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C22498B372E35CF5A2D2DD32BA5DBAC0009BE395957E7521B51C24DA2F55E57A558BE49FD398EE364050FB28585415E75ADA9040F9FF01DFDA4A8C4224003CC836476C0CAF46E325F83A522CA9DD8327EE4930A3850AC1BE2E7358D8083C743180710F370CE93649EA8CD731C566533BA786A40A5AABA2AD371193C9F3DD0FB1AF5EBFD6F4F5CC2EFF5953C9F3DD0FB1AF5EB4E70A05D1297E1BBCB5012B2E24CD356 X-Mailru-Sender: DBC2F4F1B1B33C64B837EEACE6D760D018CAEB05198BA02CA3EB5A3D49264654DC5C483502D9B882DF27400FA58A4AF1E66B5C1DBFD5D09D63761FFB9297ED015BF713DEE2A5F4A567EA787935ED9F1B X-Mras: OK Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 13:26:27 -0000 Message sender can expect message content is only stored in sender's and recipient's mailboxes after delivery. If deleted by both sender and recipient, this message is not longer exists and it's content can not be recovered. In this scenario, (partial) message content can be stored in DMARC forensic subsystem unknowingly to user, it may violate user's privacy expectations and/or rights, depending on local legislation. 26.01.2019 14:37, Дилян Палаузов пишет: > Hello, > > for a smooth working DMARC DKIM signers and verifiers must be interoperatable. When a server DKIM-signs a message and > sends it to another server without intermediates, the latter shall be able verify the signature. Imagine, the DKIM > validation fails and the ruf= dmarc report email address points to the sending server. > > What are the privacy concerns in this simple scenario that speak against sending a DMARC/DKIM report to sending server, > telling that the DKIM validation fails? > > https://tools.ietf.org/html/rfc7489#section-9 mentions some privacy thoughts, but these are not applicable when the > sending server obviously has already the reported message and no intermediates are involved, that could expose > additional information. > > Regards > Дилян > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru From nobody Sat Jan 26 06:05:50 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43A412867A for ; Sat, 26 Jan 2019 06:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 18GOnwjJvmEG for ; Sat, 26 Jan 2019 06:05:46 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 11467124B0C for ; Sat, 26 Jan 2019 06:05:45 -0800 (PST) Authentication-Results: mail.aegee.org/x0QE5eeY004163; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1548511541; i=dkim+MSA-tls@aegee.org; r=y; bh=bfF9WUSebbnXcv2k9XT71heWG3TMmZnMjTi9RGH9yN0=; h=Subject:From:To:Date:In-Reply-To:References; b=lGpZSVJqJqKwNiZrdN1v86YdR/vHWRV4Po0fYfc9a9ZpdNPLiIPUkmNxcC/Spsko1 Fj44j5/fxNIgNDHdfjNYGIOftu6/7ojPtYXs+HtrWDqjtOHcYxw0jk80qZRWdfHK/T mID58ezaUxEk1e5aGtoydEhpgaqH2sLg+pgF/0Hp/Y92zsSrGekYvAkvIxf4taJcwr rie84l244uJ0X4fo6aP+GKq1by3Ay2lsIbtDugdqeeRurD5J9yuu7qAtRpvh627PmZ L4W0qr+ITcZhslIX1HTQtHebAwxW/dMyydgWlBvca1dFOd4qlzeaJiR9pgWxs5/zoq F6JUTwUbP7poos0FZ6liRHBXyB9faIomnbZ9wtI8qY6vyysKfKiWe5Wadl9g6jFcZf O2FRPIflgvWo2Es/fA6blWgBobwseiTQth+nVOmUYigWhGyscWTHcNCXRbTPGajoRa Shjm55KeMehecXjpGhdGqeY02eFKASG7QBKOtlPVztELtsnhqYHdsSvFYXr8CzTln1 AFiOqd9SsFJFVSSdPU/GfuiDOOE5MYgmG8joZoOqimBTg9AosSiXr3qkQiJN0thoIe d6V17zI7dmCxEgLIwRUCC1gnW9wPks9tL9Ng2+MYCj1t0pTzu62jFIquha5xNLgv7L nnctW5frvLe5sIb05JeeKsyo= Authentication-Results: mail.aegee.org/x0QE5eeY004163; dkim=none Received: from Tylan (adsl-62-167-97-198.adslplus.ch [62.167.97.198]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x0QE5eeY004163 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 26 Jan 2019 14:05:40 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Vladimir Dubrovin , dmarc@ietf.org Date: Sat, 26 Jan 2019 14:05:40 +0000 In-Reply-To: <129785b9-952e-611b-cff9-7a909b3fe4a4@corp.mail.ru> References: <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.camel@aegee.org> <129785b9-952e-611b-cff9-7a909b3fe4a4@corp.mail.ru> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.90 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 14:05:49 -0000 Hello, how does the unrealistic expectation of message sender and recipient, that a “deleted” message is immediately irreversibly removed from all backups, differ from the expectation that an “erased” message does not exist in a forensic subsystem? Do Terms of Use, that clarify the sending of forensic reports (and backup policies) close the expectation/reality gap? Regards Дилян On Sat, 2019-01-26 at 16:26 +0300, Vladimir Dubrovin wrote: > Message sender can expect message content is only stored in sender's and > recipient's mailboxes after delivery. If deleted by both sender and > recipient, this message is not longer exists and it's content can not be > recovered. > > In this scenario, (partial) message content can be stored in DMARC > forensic subsystem unknowingly to user, it may violate user's privacy > expectations and/or rights, depending on local legislation. > > > > 26.01.2019 14:37, Дилян Палаузов пишет: > > Hello, > > > > for a smooth working DMARC DKIM signers and verifiers must be interoperatable. When a server DKIM-signs a message and > > sends it to another server without intermediates, the latter shall be able verify the signature. Imagine, the DKIM > > validation fails and the ruf= dmarc report email address points to the sending server. > > > > What are the privacy concerns in this simple scenario that speak against sending a DMARC/DKIM report to sending server, > > telling that the DKIM validation fails? > > > > https://tools.ietf.org/html/rfc7489#section-9 mentions some privacy thoughts, but these are not applicable when the > > sending server obviously has already the reported message and no intermediates are involved, that could expose > > additional information. > > > > Regards > > Дилян > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Sat Jan 26 07:36:57 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF645130DCB for ; Sat, 26 Jan 2019 07:36:54 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=xFJ/Q9lU; dkim=pass (1536-bit key) header.d=taugh.com header.b=BvexV8rF 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 lF6X_Q7lC408 for ; Sat, 26 Jan 2019 07:36:53 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 46635130E58 for ; Sat, 26 Jan 2019 07:36:52 -0800 (PST) Received: (qmail 93236 invoked from network); 26 Jan 2019 15:36:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=16c32.5c4c7e92.k1901; bh=DJtD8orXJzp4zdmxm1B9MIiJkBmi9MrhZvTV5xgS1Dc=; b=xFJ/Q9lUYk/S8o/wzENr9YBx4ZkkgNXJeJ114woUBl3HYRg606n5NNiwc4wGVJ8nlgam0d3tRMmZp4Kel6eVeu6ETVrc9P1gORHiKycKA7k4bgvvQkRBqy8nrkYe/0HmUwCeiBSLivcxlYcCHAE4KKEkyOX1jrEPXxDT6esUyep70LChbS2rH8vZpNXPa69O4Ts0OYeXaD0AugFHWnMWamiWSqq4tDJookz8Yzja9G8zO5JSLoyH22+TG1fKTyjm DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=16c32.5c4c7e92.k1901; bh=DJtD8orXJzp4zdmxm1B9MIiJkBmi9MrhZvTV5xgS1Dc=; b=BvexV8rF9e74FophUqNQI3aZO8h//1zE/naEFFztJb9nW0oKrAplO/YrBQNKFdRHSgJ++HXqhU0Dbdza88m1psD0gWkMErFsd9X5YITVStBQHjTCoyBYoTrValwGpDOyt20EfcSpUJQVedc0gt/5L/Xyi4yUiOcqy13JQiM1slHF1l04J0KDDoRKWPemE31Nh4K/kzOjZwpgJ79igi3oPX9p6U9g1bpMVCB9yvitvbQFgv81KaFACi3zXdBm//dv Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 26 Jan 2019 15:36:49 -0000 Received: by ary.qy (Postfix, from userid 501) id 491F6200D38D44; Sat, 26 Jan 2019 10:36:49 -0500 (EST) Date: 26 Jan 2019 10:36:49 -0500 Message-Id: <20190126153650.491F6200D38D44@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dilyan.palauzov@aegee.org In-Reply-To: <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.camel@aegee.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 15:36:56 -0000 In article <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.camel@aegee.org> you write: >What are the privacy concerns in this simple scenario that speak against sending a DMARC/DKIM report to sending server, >telling that the DKIM validation fails? The person reading the DMARC reports had enough authority to put a record in the DNS, but that is not the same thing as being able to read all of the users' mail. In large mail systems, different staff have different roles, and very few of them can look at users' mail. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jan 26 08:03:46 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DC8130E76 for ; Sat, 26 Jan 2019 08:03: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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 uW-VZSIHBn5T for ; Sat, 26 Jan 2019 08:03:42 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 6054E130E83 for ; Sat, 26 Jan 2019 08:03:42 -0800 (PST) Authentication-Results: mail.aegee.org/x0QG3dIc015713; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1548518620; i=dkim+MSA-tls@aegee.org; r=y; bh=9vtQQzV+JV3TfMI9j86CQ9i7G4UvF+HfBaQRJWTR8q4=; h=Subject:From:To:Date:In-Reply-To:References; b=Dq45TwnECioPkXQXL91eJX+bP+9lJ5an4kBRGaxF1oN0MqGCSHpcS7Z/L70iTciPB 7bvIbX+zBEEkscZi4ZBkIe9raJ2x3h5exhByccA/f5Wsgu/jZtbzmtyT3mv64UxLx2 5v7XRxwlgH8c32WNSOPRGjO8U+kd1hrZXMed3LXqLTeklaIhqcN8OzX1eXax6eO9tL qfEVA9PQAMo0qlWEVZerKzoVqHu6+n68IA0J3w6htKaJjuQ+xphf6ADsBeA5sEHaf2 wXL1y0dSn7Gjk7O2gxSOGd0wKUW3cYlkJOc5EA82V2cEUfyIOkFIp7IsNIVaFK1B9n nNsMzLXX8SJ9DgA9mrKxfT+Yx55an54nTfjS8NJUacCmmxBYCXzyjHweqEqVvPOn4d XFti4D0eFGjeK3zlFkmctrrrSrAp1xP9ju+YnfcHlwmJHAJYRj048qhiLPtFfF67+F sIFwktVjxKnZJrt0NVRzfy1ad0dSe6VIrJmhtz/GNjx2p427yNV5443TBszzvI5hs0 X8mS0jYCqYgUpXR83OuCOLNFaT9Ai94sYj3cxUEquFdhBpe4Lr4D5xuG79mgj4wW9+ 1yUCQyVsVkVtU8Yfk3U86pkP7U8QlOwG9rCFVIDXfcxQcP+x31ynjhZu+nW0Cza6U7 f1K6qEpd9q+T3os+/ZJdEyqY= Authentication-Results: mail.aegee.org/x0QG3dIc015713; dkim=none Received: from Tylan (adsl-62-167-97-198.adslplus.ch [62.167.97.198]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x0QG3dIc015713 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 26 Jan 2019 16:03:40 GMT Message-ID: <6a56a3831dd4651e0d7610ee0c90f50749a7203b.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: dmarc@ietf.org Date: Sat, 26 Jan 2019 16:03:39 +0000 In-Reply-To: <20190126153650.491F6200D38D44@ary.qy> References: <20190126153650.491F6200D38D44@ary.qy> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.90 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 16:03:44 -0000 Hello, On Sat, 2019-01-26 at 10:36 -0500, John Levine wrote: > In article <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.camel@aegee.org> you write: > > What are the privacy concerns in this simple scenario that speak against sending a DMARC/DKIM report to sending server, > > telling that the DKIM validation fails? > > The person reading the DMARC reports had enough authority to put a > record in the DNS, but that is not the same thing as being able to > read all of the users' mail. > > In large mail systems, different staff have different roles, and very > few of them can look at users' mail. Aha, we have staff dealing with DNS, staff dealing with email boxes and domain owners. How can a domain owner communicate, that its users agree to have investigations on forensic reports, where DKIM signatures failed (fot the purpose of avoiding repeating errors in DKIM signing/validation)? In particular, that there is no expectation of the users that a deleted message is erased and that the domain owner, DNS staff and email staff function good as whole? Regards Дилян From nobody Sat Jan 26 08:31:28 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B882C130E81 for ; Sat, 26 Jan 2019 08:31:26 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=NqVqBRMe; dkim=pass (1536-bit key) header.d=taugh.com header.b=k7LXmfft 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 h8wFzALKmOu2 for ; Sat, 26 Jan 2019 08:31:25 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 101F9130E70 for ; Sat, 26 Jan 2019 08:31:24 -0800 (PST) Received: (qmail 2907 invoked from network); 26 Jan 2019 16:31:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b59.5c4c8b5b.k1901; bh=jZWmw/DwhG4+tTxxpbrMA3gG+oB81EA4s4tUcq9kKRY=; b=NqVqBRMeiuq52asj95oK8m5OSKBY1cMOLvXtKYTOdS4LWTnOsEE4RQeArnqgmwzMFQL/pn97VhOKb9QlSzTuHuuFXWwCM9LOCai7odpdS1V2eIR8ZnaKkf6QFbIBP3rO+bJh9SZ19+Auo4bPIlrpOwjc7IviO9vC6dTw9LKMiGwKZn+UZN0UcaS51cUjzv7S4sSFo4y2rlooG91roE/NK4XKtu08TPGx1Mups6Q3n4w0iogTVxrJAm2ctPT6imIX DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b59.5c4c8b5b.k1901; bh=jZWmw/DwhG4+tTxxpbrMA3gG+oB81EA4s4tUcq9kKRY=; b=k7LXmfftEEKuzdhqUhIruuuCTORQcMYhnKbA38RvL26C4us0nid00qV33G/ITnn5tR9KiHxE3KP+Z7YKwf1c1zMrl+0d+s4V1QmKH7sVxHKATkiL9Qu8Zb5gRzgLWdTzILjeRIQ8YH/lbSt2F2rTNS06wQIB0cQEFy9n6JMddyMTZTvuHAOV2a65cmA9xcSu0OABGSCjt5oc43iyPEzwpmeLJOgy8DAUdgoD5SJSewz+CZKLge8t9s2NUZT/YvVM Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 26 Jan 2019 16:31:23 -0000 Received: by ary.qy (Postfix, from userid 501) id AAA4B200D39816; Sat, 26 Jan 2019 11:31:23 -0500 (EST) Date: 26 Jan 2019 11:31:23 -0500 Message-Id: <20190126163123.AAA4B200D39816@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dilyan.palauzov@aegee.org In-Reply-To: <6a56a3831dd4651e0d7610ee0c90f50749a7203b.camel@aegee.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 16:31:27 -0000 In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.camel@aegee.org> you write: >How can a domain owner communicate, that its users agree to have investigations on forensic reports, where DKIM >signatures failed (fot the purpose of avoiding repeating errors in DKIM signing/validation)? In particular, that there >is no expectation of the users that a deleted message is erased and that the domain owner, DNS staff and email staff >function good as whole? I suppose they could try to put it in the terms of service, but I wouldn't begin to guess whether that would be enforcable or even legal in places with the GDPR and other privacy laws. More to the point, I wouldn't bother. The failure reports are almost entirely useless. Of the ones I get, the majority are random Chinese spam that happened to forge one of my domains on the From line, the rest are from mailing lists where I wouldn't expect DMARC to pass. R's, John From nobody Sat Jan 26 09:07:17 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA94D130F0F for ; Sat, 26 Jan 2019 09:07:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 Jl8IuQGUAmgv for ; Sat, 26 Jan 2019 09:07:14 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 2C1A1130F17 for ; Sat, 26 Jan 2019 09:07:13 -0800 (PST) Authentication-Results: mail.aegee.org/x0QH7B0E025285; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1548522432; i=dkim+MSA-tls@aegee.org; r=y; bh=HzaAXH+zpoY2ykxfA3jeC3eD4yxc1SnyvAR1f0rFTNw=; h=Subject:From:To:Date; b=fejfavlU/K7lowsEGcBQfWNy3bPm07DHigUFHImi14IQdTsnji4T4JYow9gXQGFDe 5yOQL/2MAuwhUD5l8Dg3l4RYFIqK71iaNmcKjAxil+wONvWCKUHP6B/GVKSKuI1D92 oe/NGVpmmKJr8aG1xsAaaEZqLfttgvwOBvkPt3TsR+MVhzc9hoyja7KDJAhJ+iCBAh yfKY0xTUMYhzWZtKeUOFI5JItSUxH4mNIdA8nhoDDwbZDbIY/+lFSRA6SFWvhE9Fv5 qGuHPtiCAjfDwGVy321BJ6l+j8tHMMD3Lr1Ew2bCOxEnpbSuB3vznlFzm8W/hUENM4 DYnemHIcEKfC8zwCVNPRsIxtD1lYeJ0Zcr27XnmqlXzuv8cV4wAaVf2QZY66MdbzRT vQjrnDYCNUaGkjdhC3cSRxBA4RqYswxYo87Wx9WAM11yIIS7CYXAHM5+WZG3Z/v7I1 yITZgRVYCRK+ifW7V9EAKX3A9cHMg2rlcvoVpK0oy2oxdCBcH876O9rKdkOoazho0/ Z1VNxBRi9KtcWnVNWbk6HihZOT9Od+BwUz5jjWZeLvtFIdX5nFdYPpnrnAfQHX2lQ8 6Cs2psyPCrU3fTFPvJ7TqGxjQg8z7l1h2NJa4tw4yyX7twTqoFyOaFWituVCpVoM0Z DjcL64t7ggZrE8KesXj2E2dE= Authentication-Results: mail.aegee.org/x0QH7B0E025285; dkim=none Received: from Tylan (adsl-62-167-97-198.adslplus.ch [62.167.97.198]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x0QH7B0E025285 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 26 Jan 2019 17:07:12 GMT Message-ID: <7ff0d2fc379d7d61576fe4d419e0bcd0390f408c.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: dmarc@ietf.org Date: Sat, 26 Jan 2019 17:07:11 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.90 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] Thin forensic DMARC reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 17:07:17 -0000 Hello, will be there any concerns for sending slim forensic DMARC reports (ruf=) on failed DKIM validation, if * between sender and recipient there are no intermedates/aliases/redirecting providers, * the third MIME part of multipart/report is cut (contrary to https://tools.ietf.org/html/rfc5965#section-2 bullet d), and * in the message/feedback-report part - either the Original-Envelope-Id is included, - or Original-Message-Id is included (where Original-Message-Id will be defined to be the Message-Id of the message that is reported)? The Original-*-Id identifiers do not expose privacy information, but let the sending server identify for which message the DKIM signing/validation do not match. Whether the sending user has deleted the message in the meantime does not matter. Knowing which message is problematic is a huge improvement compared to the current situation. First, the sender can validate with different implementations whether they all produce the same signature for that message. Second, if the message in question is sent over a mailing list, the From: was changed by the MLM, the DKIM signature was added after the mail left the MLM but before leaving the MLM-mail-server, then this very message is likely to be distributed to several mail providers. If one provider does not validate the signature, and the other providers validate the signatures, (or all mail providers do not validate), then somebody can take some actions so that the cause for the failure is resolved and does not happen again in the future. A clear plus for all DMARC-users. Regards Дилян From nobody Sat Jan 26 09:21:34 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC18130F33 for ; Sat, 26 Jan 2019 09:21:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 HTJpC39GS8YN for ; Sat, 26 Jan 2019 09:21:31 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 137FB130E5F for ; Sat, 26 Jan 2019 09:21:30 -0800 (PST) Authentication-Results: mail.aegee.org/x0QHLSA4029944; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1548523289; i=dkim+MSA-tls@aegee.org; r=y; bh=B1H4Hxh75PAr1Msqd3tw7hCZ0+thZ4INlyGw1UIX7Es=; h=Subject:From:To:Date:In-Reply-To:References; b=U7pN5ca74zHcYbh3M2IyVAI9qH7D0YwECPTUyZ4Ft3goLDMUVYKm6nMfJxTxuldCY mDuaRcnvA9+iv4jD+uR8ueerOmQuU1c/KB2uqhTP90uJy9jaxD2Hzkx/gzCDQV4K8A nWbfRveLecQKvzCsNK3hSMib7ffPIElyAl2t63TtcOorvhV4TnVUz6RQ/ib2Xnu1tV V+e+fQ1sD+cmYTM7C4wRTTtIm8yiB1Ci/ao9+l6f8zsk91npiIFdItrCLKLm/2lum0 npEA/g/nFZvDUM76BMdVF+ky29J8DvQsuD2vTY8rvJ5dEq6AgOHWKTy6j/Zu+Ir+n8 zW4icYPDzIY2xuxy0/qhtY2WLm03IvHZ1mZejNcsO0ylycfyBOHDFRZ1OIRO03mLUj whLs2eTcA7usvbDFWnqZPIvy+4aKvwGAnYyDDQHc1zSCq6n8BnNoKSjgLf0hWEVS+p dIQ2wWOWIBm3ezdhuTZtEc5E6G+HXAwAISm+YuGtHjh7EpuklaEK2dy8c5Lv4Ye4PB gg6Igs++TY1wPTfMvwao5z44v7npZc2FpVGuaLli1+LPXBNeF8EZxLBClrdzcgNL0o 4cNJ/dBPvr3VHsMFqaNXg6uhS3TpRedwDgoJ98FIWx7++OLI7TONGHxwH+x0m+kWAy xuXduWBsg2YlzfCUleP1vHyc= Authentication-Results: mail.aegee.org/x0QHLSA4029944; dkim=none Received: from Tylan (adsl-62-167-97-198.adslplus.ch [62.167.97.198]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x0QHLSA4029944 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 26 Jan 2019 17:21:28 GMT Message-ID: <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: dmarc@ietf.org Date: Sat, 26 Jan 2019 17:21:28 +0000 In-Reply-To: <20190126163123.AAA4B200D39816@ary.qy> References: <20190126163123.AAA4B200D39816@ary.qy> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.90 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 17:21:33 -0000 Hello John, On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: > In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.camel@aegee.org> you write: > > How can a domain owner communicate, that its users agree to have investigations on forensic reports, where DKIM > > signatures failed (fot the purpose of avoiding repeating errors in DKIM signing/validation)? In particular, that there > > is no expectation of the users that a deleted message is erased and that the domain owner, DNS staff and email staff > > function good as whole? > > I suppose they could try to put it in the terms of service, but I > wouldn't begin to guess whether that would be enforcable or even legal > in places with the GDPR and other privacy laws. > > More to the point, I wouldn't bother. The failure reports are almost > entirely useless. Of the ones I get, the majority are random Chinese > spam that happened to forge one of my domains on the From line, the > rest are from mailing lists where I wouldn't expect DMARC to pass. A domain owner can certainly clarify anything in the terms of service, but even if the domain owner does these clarifications, s/he will not receive DKIM/DMARC forensic reports, because there is no mean to communicate to the generators of those reports, that sending forensic reports violates users expectations. The reasons mentioned here against sending forensic reports were, that this might not match user expectations (on deleted information) and because email staff and DNS staff may differ. I approached both concerns, by stating that user expections can be put in Terms of Use and that a domain owner can decide, that for a domain it is acceptable to receive forensic reports and insert this infomation in the Terms of Use. So… what else exactly needs to happen, to resolve the concerns against sending forensic reports (which was my original question)? If GDPR is the only concern, this can also be clarified. But clarifying that GDPR is not a problem, will be losing time, if independent of it there are other concerns. Imagine there is a failure report stating that after a direct communication between your server and another server, the receiving server sends you an aggregate report, stating that 1% of the messages you sent yesterday do not validate DKIM. How do you suggest to proceed to reduce this to 0%? Regards Дилян From nobody Sat Jan 26 09:57:10 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173FC130F19 for ; Sat, 26 Jan 2019 09:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 o7XBb_HT73QU for ; Sat, 26 Jan 2019 09:57:05 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 A306A130F26 for ; Sat, 26 Jan 2019 09:57:04 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id r10so13471854wrs.10 for ; Sat, 26 Jan 2019 09:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=14oqOnedjC/TdmtsqNmk37Qr7Wrg0zq8aUGnW6poCKY=; b=UU/RK0jP6GyWczn6dX4671Eguf5VGsxlba5h295lH2O7RRjE/OCijjOxnu1vFQ2eo4 PPGp/y6z5DIiQDKKRUhCfjrAflxrJqZKFcppTsgvtVt2VRyEEvMimhjNpYZ4pLQUVtWs 3bCAAfPRCc0ZLloh/PyHKSGzdgNts6yp5ZGhr6AI8DJXxCxMxKSYbrfR3vwJimFO/YAy +yMGAlIOcfjEevDT2m10+lr1USGbFX8i7et5DNp94o0Z+BHJliSAdVEU7YOfb1Boe5HO sjSkMStPtbqdOEcQ4vO4XBfwFjPhYNPi8ag30zEaiFLBHv/C1FfUYtOfl9YZzeRytdo+ FkbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=14oqOnedjC/TdmtsqNmk37Qr7Wrg0zq8aUGnW6poCKY=; b=oMM7WdPJO+J3AsudwxP8MtynNi9WZEaqsLT4xC1L+YyJ0SKYJGJWrakPiFpzoYCc+a lWozUXaI8YZRY46xf4SuUIe85nBP9p3jLD73sHtM8rpFuuZzsuebUEFii0G7KV1CnpEz vOCG8KcL2wkBVYNtZVQD+ARje7JuxA4P/FIGn5di82N+xSxAP4v1lnj9Cj70U0+zGomC sHqEPh2LeDo6wZfEkKQu8bdXURcoZ4hTrtmYbufZJBi89o5z5wk1BaQwDB6sBheQGnj1 3SJhSZpZDNDpQQb48whW8auHRNu9zSN1EVMHVE4AY3oJFA3wQN/dLjFcxQCVzuJgIPh7 GMzg== X-Gm-Message-State: AJcUukeHP71MQdV1pSwUmPaU3sKNaIyXUOf7SKWgCODvSmQcfvyS/ZC1 s5KmW6QH0FDJJpcKCuQukz/MApRI+J35JsuyxpU= X-Google-Smtp-Source: ALg8bN7x1zOrKvstEtNitjtoEaKNLG4JXqaHQD4kpcQqmoSBh5ZQl5SzSpdxuUobuvyw5a2lCVK5VH4dX1DXEhDScbw= X-Received: by 2002:a5d:6b09:: with SMTP id v9mr16477771wrw.304.1548525422935; Sat, 26 Jan 2019 09:57:02 -0800 (PST) MIME-Version: 1.0 References: <20190126163123.AAA4B200D39816@ary.qy> <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org> In-Reply-To: <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org> From: Dotzero Date: Sat, 26 Jan 2019 12:56:52 -0500 Message-ID: To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c284b20580602b4d" Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 17:57:08 -0000 --000000000000c284b20580602b4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please, RUF is a ""Failure Report", not a "Forensic Report". Please read RFC 7489 - https://datatracker.ietf.org/doc/rfc7489/ On Sat, Jan 26, 2019 at 12:21 PM =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0= =B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: > Hello John, > > On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: > > In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.camel@aegee.org> > you write: > > > How can a domain owner communicate, that its users agree to have > investigations on forensic reports, where DKIM > > > signatures failed (fot the purpose of avoiding repeating errors in > DKIM signing/validation)? In particular, that there > > > is no expectation of the users that a deleted message is erased and > that the domain owner, DNS staff and email staff > > > function good as whole? > > > This is way outside the scope of DMARC., however, the very fact that the domain has provided an email address for receiving RUF reports is a pretty reliable indicator. Presumably DNS and mailops staff work for/on behalf of the domain owner. > > I suppose they could try to put it in the terms of service, but I > > wouldn't begin to guess whether that would be enforcable or even legal > > in places with the GDPR and other privacy laws. > > > > More to the point, I wouldn't bother. The failure reports are almost > > entirely useless. Of the ones I get, the majority are random Chinese > > spam that happened to forge one of my domains on the From line, the > > rest are from mailing lists where I wouldn't expect DMARC to pass. > Clearing out the chaff originating from servers other than your own helps, but I'm not going to try to teach John anything. > > A domain owner can certainly clarify anything in the terms of service, bu= t > even if the domain owner does these > clarifications, s/he will not receive DKIM/DMARC forensic reports, becaus= e > there is no mean to communicate to the > generators of those reports, that sending forensic reports violates users > expectations. > Individual user expectations are well outside the scope of DMARC. It is a domain/subdomain level protocol. If you don't want the reports then don't provide a destination for them to be delivered to. > > The reasons mentioned here against sending forensic reports were, that > this might not match user expectations (on > deleted information) and because email staff and DNS staff may differ. I > approached both concerns, by stating that user > expections can be put in Terms of Use and that a domain owner can decide, > that for a domain it is acceptable to receive > forensic reports and insert this infomation in the Terms of Use. So=E2= =80=A6 what > else exactly needs to happen, to resolve the > concerns against sending forensic reports (which was my original question= )? > > If GDPR is the only concern, this can also be clarified. But clarifying > that GDPR is not a problem, will be losing > time, if independent of it there are other concerns. > > Imagine there is a failure report stating that after a direct > communication between your server and another server, the > receiving server sends you an aggregate report, stating that 1% of the > messages you sent yesterday do not validate DKIM. > How do you suggest to proceed to reduce this to 0%? > Over time you are unlikely to keep "legitimate" failures at 0%. There are lots of moving parts and pieces that can cause a failure. It also depends on the characteristics of the mail streams involved. The domain owner(s) and staff will need to determine how much effort they are willing to put in eliminating (legitimate) email failures. If I'm sending 10 million emails to a domain and 1% are failing then I'm likely to look into it. On the other hand, if I'm sending 100 emails a day to a domain from an overall large system and 1% (1 email) is failing, that really falls into the noise and is unlikely to get much time spent on it. Michael Hammer --000000000000c284b20580602b4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please, RUF is a ""Failure= Report", not a "Forensic Report". Please read RFC 7489 -=C2= =A0https://datatracke= r.ietf.org/doc/rfc7489/

On Sat, Jan 26, 2019 at 12:21 PM =D0=94=D0=B8=D0= =BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 <dilyan.palauzov@aegee.org> wr= ote:
Hello John,=

On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote:
> In article <6a56a3831dd4651e0d7610ee0c90f50749a7= 203b.camel@aegee.org> you write:
> > How can a domain owner communicate, that its users agree to have = investigations on forensic reports, where DKIM
> > signatures failed (fot the purpose of avoiding repeating errors i= n DKIM signing/validation)?=C2=A0 In particular, that there
> > is no expectation of the users that a deleted message is erased a= nd that the domain owner, DNS staff and email staff
> > function good as whole?
>

This is way outside the scope of = DMARC., however, the very fact that the domain has provided an email addres= s for receiving RUF reports is a pretty reliable indicator. Presumably DNS= =C2=A0 and mailops staff work for/on behalf of the domain owner.
= =C2=A0
> I suppose they could try to put it in the terms of service, but I
> wouldn't begin to guess whether that would be enforcable or even l= egal
> in places with the GDPR and other privacy laws.
>
> More to the point, I wouldn't bother.=C2=A0 The failure reports ar= e almost
> entirely useless.=C2=A0 Of the ones I get, the majority are random Chi= nese
> spam that happened to forge one of my domains on the From line, the > rest are from mailing lists where I wouldn't expect DMARC to pass.=

Clearing out the chaff originating fro= m servers other than your own helps, but I'm not going to try to teach = John anything.=C2=A0

A domain owner can certainly clarify anything in the terms of service, but = even if the domain owner does these
clarifications, s/he will not receive DKIM/DMARC forensic reports, because = there is no mean to communicate to the
generators of those reports, that sending forensic reports violates users e= xpectations.

Individual user expectatio= ns are well outside the scope of DMARC. It is a domain/subdomain level prot= ocol. If you don't want the reports then don't provide a destinatio= n for them to be delivered to.

The reasons mentioned here against sending forensic reports were, that this= might not match user expectations (on
deleted information) and because email staff and DNS staff may differ.=C2= =A0 I approached both concerns, by stating that user
expections can be put in Terms of Use and that a domain owner can decide, t= hat for a domain it is acceptable to receive
forensic reports and insert this infomation in the Terms of Use.=C2=A0 So= =E2=80=A6 what else exactly needs to happen, to resolve the
concerns against sending forensic reports (which was my original question)?=

If GDPR is the only concern, this can also be clarified.=C2=A0 But clarifyi= ng that GDPR is not a problem, will be losing
time, if independent of it there are other concerns.

Imagine there is a failure report stating that after a direct communication= between your server and another server, the
receiving server sends you an aggregate report, stating that 1% of the mess= ages you sent yesterday do not validate DKIM.
How do you suggest to proceed to reduce this to 0%?
Over time you are unlikely to keep "legitimate" fail= ures at 0%. There are lots of moving parts and pieces that can cause a fail= ure. It also depends on the characteristics of the mail streams involved. T= he domain owner(s) and staff will need to determine how much effort they ar= e willing to put in eliminating (legitimate) email failures. If I'm sen= ding 10 million emails to a domain and 1% are failing then I'm likely t= o look into it. On the other hand, if I'm sending 100 emails a day to a= domain from an overall large system and 1% (1 email) is failing, that real= ly falls into the noise and is unlikely to get much time spent on it.
=

Michael Hammer
--000000000000c284b20580602b4d-- From nobody Sat Jan 26 13:14:27 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A73130FFA for ; Sat, 26 Jan 2019 13:14:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 51d5BSDgQ41B for ; Sat, 26 Jan 2019 13:14:23 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 B383B130FC7 for ; Sat, 26 Jan 2019 13:14:21 -0800 (PST) Authentication-Results: mail.aegee.org/x0QLEJRs026638; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1548537259; i=dkim+MSA-tls@aegee.org; r=y; bh=PIY5sHFD+BT5WQmj2zkglsLaUmgUJCX22WepHcfDIbU=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=jWHmJ6sW9Xe3T8uVoWaU47Azle4XqJ9QHle2r1BvS9FRy7FdksjE2Vkpo5BUF3Qw7 c6WgrAZeSnmWdOCRQ8nj3COULSzF8UvJYrGgEgeq4Zki1Q0m79TtDwx6TVuml0cuVZ 0dgY/79O0r31GQ8Sim21P3rtI9k00P6q1do0Kkt2pz95MSl61j1wYogmKWKbpQ9KJs JexWzKfC2y7pV0NiLco7mNztynnWdum6d3j54+llHZjWKXDoajHCjZxMZlVtYr28+k RfrJGhqev/eYTuZdnIApbZyEVuXFp3CFMpU7vdRsTfEsCSHi3t+9d2GCxqq4sCUSH+ dYCoeMgHZLBZPrbmUqqhTDkj3bmcPKd3PL1+JBUAZ+a/3013cZOKoc/d8Td3OojvvO +/XyDzeekXGHahWl30mRMns6tET1qWwOefNG4aqxyap2gTl+ATQVABpkxYUxifNEwJ 6TdaUiIhcQ9AXOumdpT65GTpMDwIrP6tK4Esbbv6zfGR+yWdVgKngOW5sNeyl29iEg npAgf9jCrNQjd8r/tvwZnGe4k/THmSoOc+Q8/tv1GtjwT8IPoANn/ZXJnzC99ZGrqq u5BNCwDq/P4KjD0DOWr06kZqkNxaXquBhM1SIyprc9YYs/B8tfZ0EM2at9xd1mgGyP uNUdVhy3aM9cQ6tn0l0OXnVM= Authentication-Results: mail.aegee.org/x0QLEJRs026638; dkim=none Received: from Tylan (adsl-62-167-97-198.adslplus.ch [62.167.97.198]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x0QLEJRs026638 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 26 Jan 2019 21:14:19 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Dotzero Cc: IETF DMARC WG Date: Sat, 26 Jan 2019 21:14:18 +0000 In-Reply-To: References: <20190126163123.AAA4B200D39816@ary.qy> <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.90 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 21:14:26 -0000 Hello, reiterating over the arguments against sending reports to the ruf= …dmarc address, the first provided reason was, that such report will not match the expectations of the users. Which users? On the site that sent the initial mail or on the site that generated the report. It can be assumed, that sending reports to the ruf= address at a certain domain matches the expectations of the users of that domain and any non-matching expectation is a problem of the one who published the ruf= entry, not the one generating a report. I do not say that once the report is generated and sent the sender has to store the report, so that the expectation of the user, that received the initial mail, are also met, when the report generating server does not store a copy of the sent report. The second argument was, that staff managing DNS and staff managing emails (and able to read user’s email) are completely different persons. I do read here, that the DNS staff can use its posititon to insert arbitrary email addresses in the ruf= tag and by this way come in a position to read emails, that otherwise the DNS staff would not be entitled to read. Seriously, if the ruf= tag is not trusted, why shall the p= tag be honoured, and why shall also be the DKIM public signature and MX record be trusted? Either the ruf= email address is trusted to receive reports, or the whole DNS of the sending domain is not trusted. The third argument is, that in case 1% ouf of 10 000 000 messages between two hosts are reported in the aggregate message not to match DKIM, then it is worth investigating the cause. Alright, that is exactly my point. I want the reports, provide ruf=, and don’t receive the reports. Where will you start investigating? How can you find out if the problem is on the sender or receiver side? If you validate once again your implementation and find nothing wrong with it, does it prove, that the implementation of other side has bugs? Perhaps the other side has also proven in the very same way, that it is error-free. You see only that 1% of the messages do not match DKIM validation, now and then. What is the next step to make signer and verifier compatible? Guessing? If making signers and verifier compatible can be achieved only by guessing, then DMARC cannot be trusted/is not mature. I have no problems if due changes somewhere DKIM for a while fails, as in this case there is nothing I can do. But I want to be sure, that the cause is not on my side, and currently this is not evident. It is just not clear, if there is a problem report, if the problem is temporary, when the cause was resolved, if the cause is on my side… This properties make DMARC not reliable. Regards Дилян On Sat, 2019-01-26 at 12:56 -0500, Dotzero wrote: > Please, RUF is a ""Failure Report", not a "Forensic Report". Please read RFC 7489 - https://datatracker.ietf.org/doc/rfc7489/ > > On Sat, Jan 26, 2019 at 12:21 PM Дилян Палаузов wrote: > > Hello John, > > > > On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: > > > In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.camel@aegee.org> you write: > > > > How can a domain owner communicate, that its users agree to have investigations on forensic reports, where DKIM > > > > signatures failed (fot the purpose of avoiding repeating errors in DKIM signing/validation)? In particular, that there > > > > is no expectation of the users that a deleted message is erased and that the domain owner, DNS staff and email staff > > > > function good as whole? > > > > > This is way outside the scope of DMARC., however, the very fact that the domain has provided an email address for receiving RUF reports is a pretty reliable indicator. Presumably DNS and mailops staff work for/on behalf of the domain owner. > > > > I suppose they could try to put it in the terms of service, but I > > > wouldn't begin to guess whether that would be enforcable or even legal > > > in places with the GDPR and other privacy laws. > > > > > > More to the point, I wouldn't bother. The failure reports are almost > > > entirely useless. Of the ones I get, the majority are random Chinese > > > spam that happened to forge one of my domains on the From line, the > > > rest are from mailing lists where I wouldn't expect DMARC to pass. > > Clearing out the chaff originating from servers other than your own helps, but I'm not going to try to teach John anything. > > A domain owner can certainly clarify anything in the terms of service, but even if the domain owner does these > > clarifications, s/he will not receive DKIM/DMARC forensic reports, because there is no mean to communicate to the > > generators of those reports, that sending forensic reports violates users expectations. > > Individual user expectations are well outside the scope of DMARC. It is a domain/subdomain level protocol. If you don't want the reports then don't provide a destination for them to be delivered to. > > The reasons mentioned here against sending forensic reports were, that this might not match user expectations (on > > deleted information) and because email staff and DNS staff may differ. I approached both concerns, by stating that user > > expections can be put in Terms of Use and that a domain owner can decide, that for a domain it is acceptable to receive > > forensic reports and insert this infomation in the Terms of Use. So… what else exactly needs to happen, to resolve the > > concerns against sending forensic reports (which was my original question)? > > > > If GDPR is the only concern, this can also be clarified. But clarifying that GDPR is not a problem, will be losing > > time, if independent of it there are other concerns. > > > > Imagine there is a failure report stating that after a direct communication between your server and another server, the > > receiving server sends you an aggregate report, stating that 1% of the messages you sent yesterday do not validate DKIM. > > How do you suggest to proceed to reduce this to 0%? > > Over time you are unlikely to keep "legitimate" failures at 0%. There are lots of moving parts and pieces that can cause a failure. It also depends on the characteristics of the mail streams involved. The domain owner(s) and staff will need to determine how much effort they are willing to put in eliminating (legitimate) email failures. If I'm sending 10 million emails to a domain and 1% are failing then I'm likely to look into it. On the other hand, if I'm sending 100 emails a day to a domain from an overall large system and 1% (1 email) is failing, that really falls into the noise and is unlikely to get much time spent on it. > > Michael Hammer > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sat Jan 26 14:38:18 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E24124D68 for ; Sat, 26 Jan 2019 14:38:16 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=V+pFI106; dkim=pass (1536-bit key) header.d=taugh.com header.b=KohZPGvy 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 dT-K1Y_GHhlH for ; Sat, 26 Jan 2019 14:38:14 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E3FB71277BB for ; Sat, 26 Jan 2019 14:38:13 -0800 (PST) Received: (qmail 74690 invoked from network); 26 Jan 2019 22:38:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=123c0.5c4ce154.k1901; bh=jcxF+otBkbHLLw6suGZfomXF+IapI69DfRafLVfxGUY=; b=V+pFI1066DQG07DBJaXCWfwFL1twEbuEwTCUwMHOiI0lBetaEWJj+EqoNNycHPlfkaXBZz9o0u9uvyMsD0zFCc+iFYkR20G5q/eFYwIE8OrM+tcNilx7o64DYjU9UV2Xf1ckJ7r+FOYgLVE7uKd39+Y/eF9TrOQO0YDzGpZom/IyuKG5w2bi84+ZPKokeTEo6p8Tg57iJbnGQz2tJaMRqNcw9kYVrIlDBGwKuMC/Bp964KtrNgu4NarpIG/iSKll DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=123c0.5c4ce154.k1901; bh=jcxF+otBkbHLLw6suGZfomXF+IapI69DfRafLVfxGUY=; b=KohZPGvyckut2At0DTVSDYTfHVWQUZU97/47GgCP5ojqj24UxAKgn+jInqf77zIpPclsDXniPrQ6l614JV+TQcgFGrYoeNsC2vymQbVGBDuO3SgepCcTDuSZM7EP800M7hU3Phbg1MhI2mtLI2cMLtXaLRHnbOKAHM2vMc50/f7XjIrmWJ3BJM4ezUmmgVDRFG6iPR+VJ/Kwh79mW1tO9PSs8azyMG9lQWdtvOWoXGOlU+WQsKUWYV0xksPp1tK/ Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 26 Jan 2019 22:38:11 -0000 Received: by ary.qy (Postfix, from userid 501) id 51EAC200D3CEF9; Sat, 26 Jan 2019 17:38:12 -0500 (EST) Date: 26 Jan 2019 17:38:12 -0500 Message-Id: <20190126223812.51EAC200D3CEF9@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dilyan.palauzov@aegee.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 22:38:17 -0000 In article you write: >reiterating over the arguments against sending reports to the ruf= …dmarc address, the first provided reason was, that >such report will not match the expectations of the users. I'm pretty sure that the people you think you are arguing with are not on this mailing list. R's, John From nobody Sat Jan 26 15:29:51 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BCA130EB0 for ; Sat, 26 Jan 2019 15:29:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 o7fiwGcjoYGb for ; Sat, 26 Jan 2019 15:29:48 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 A9431126DBF for ; Sat, 26 Jan 2019 15:29:48 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id u16so11752235otk.8 for ; Sat, 26 Jan 2019 15:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8WAji/iZs8GLScDu9miGHgAXdPYWw7Ts9g8oZ9woE24=; b=dLP8C2/joWMFafe5B34F8pmRdEzKyuiFkjxo9Q8H3u/Aq6iajEL1T/94U5daHKRVYU tIrG3aqARkmHPHts1wCgZ4lfHTf35X9EJpLgzwv0/nhboeu6aAqUz1TfxiSPMHBQfFCG gwVvIiTYYzN27gpgk3M3Uh6NaTUXU6W6ej5+E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8WAji/iZs8GLScDu9miGHgAXdPYWw7Ts9g8oZ9woE24=; b=FldLRW4jTOEkwnXJdJWMp0Y5S9dQ6JUE7PN6JTMh5CwtCd6UYJbBdN4ITCxvzZKy9P mANr5z8ina9mTqaTiJsLWdoPcXIzgnZGxbsLhxdmt/RwkRi16Zc3xP7ECt+GeqB8ElzT UYMp4l3HMnMAwJ9tla5BgyRoKMLv/HIxI5hv6KYizHZWGfby2fdfulynTbgtbzLaN3Ak IkE3cayD+TQLxFqo3BOKpT/29IOveWsSTOpFft4ex2mp4yxeY71wkpMjWTRTtFMXYNq8 oVpqtIUxHemY6uR9yToa+5dnXd9Db+qpvhkUl5VY3KHGN595R1/3Am6JyaYM74pHJmP9 qNLQ== X-Gm-Message-State: AJcUukeGomwD2o/+TWNC9mQgszQaiDL4v2jKlMJaOB6B3mf5xoexfrwm U6J3HJTTmNubLeGgoXBlIfXF6h1YNGCHGQINE/Dj5nyWZJg= X-Google-Smtp-Source: ALg8bN6hy+xHjYjLpjcesVfXs8pFtlkKtQRw+TTQBesuJIkp05SyH87LN4bnQKVZGVCSWXozqayF2PGaDZvISCgmOJs= X-Received: by 2002:a24:3047:: with SMTP id q68mr8029964itq.78.1548545387491; Sat, 26 Jan 2019 15:29:47 -0800 (PST) MIME-Version: 1.0 References: <20190126223812.51EAC200D3CEF9@ary.qy> In-Reply-To: <20190126223812.51EAC200D3CEF9@ary.qy> From: "Kurt Andersen (b)" Date: Sat, 26 Jan 2019 13:29:36 -1000 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Content-Type: multipart/alternative; boundary="000000000000bd7b47058064d12a" Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jan 2019 23:29:51 -0000 --000000000000bd7b47058064d12a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 26, 2019 at 12:38 PM John Levine wrote: > In article you > write: > >reiterating over the arguments against sending reports to the ruf=3D =E2= =80=A6dmarc > address, the first provided reason was, that > >such report will not match the expectations of the users. > > I'm pretty sure that the people you think you are arguing with are not > on this mailing list. > Nor on any of the other IETF lists :-) --Kurt --000000000000bd7b47058064d12a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jan 26, 2019 at 12:38 PM John Lev= ine <johnl@taugh.com> wrote:
In article <ad02c03115cebe042ba0c6f815b5e9= 8cec0398ae.camel@aegee.org> you write:
>reiterating over the arguments against sending reports to the ruf=3D = =E2=80=A6dmarc address, the first provided reason was, that
>such report will not match the expectations of the users.

I'm pretty sure that the people you think you are arguing with are not<= br> on this mailing list.

Nor on any of the= other IETF lists :-)

--Kurt=C2=A0
--000000000000bd7b47058064d12a-- From nobody Sat Jan 26 16:36:18 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CC5130EAF for ; Sat, 26 Jan 2019 16:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 Imli4UlxELHG for ; Sat, 26 Jan 2019 16:36:12 -0800 (PST) Received: from smtp38.i.mail.ru (smtp38.i.mail.ru [94.100.177.98]) (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 388C612DF72 for ; Sat, 26 Jan 2019 16:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=Dij/8XerWy6A5lP29KBbGCN3r/d2DhrsCnTRUCE2Ets=; b=JaUEaNjP0BLDTHezWCOHrEZq8UfHmpW9DSMHD9imvy/Iyixqxv294c64aeDKbJWlRwroa18IjHppBP4QxgE6qb3K8980Uoi+w7AjUueUh6K8t7B4DtfUfvU5fnO4lBSi9myoI4ke5+uWycP1598tgtL/CMUzBMZ6z6YDD2d5IW8=; Received: by smtp38.i.mail.ru with esmtpa (envelope-from ) id 1gnYQi-0001aj-9q; Sun, 27 Jan 2019 03:36:08 +0300 To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , Dotzero Cc: IETF DMARC WG References: <20190126163123.AAA4B200D39816@ary.qy> <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org> From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: Date: Sun, 27 Jan 2019 03:36:06 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: smtp38.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: 81FD5A73BC5E955B3B62BF16355A2F9CD5726B99309011CDA92371E9ECBAA7EC X-77F55803: 689590B63E0A4B015A78504BD2AC294108AEA42614CCE77CEB08515F5588567FA02EBCA0187532DCF73B5AEBDB4B5463 X-7FA49CB5: 0D63561A33F958A500FFD96411788983460A730502DF659607F79E37EC8612C98941B15DA834481FA18204E546F3947C2FFDA4F57982C5F4F6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8BF1175FABE1C0F9B6A471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C22498B372E35CF5A2D2DD32BA5DBAC0009BE395957E7521B51C24DA2F55E57A558BE49FD398EE364050FB28585415E75ADA9040F9FF01DFDA4A8C4224003CC836476C0CAF46E325F83A522CA9DD8327EE4930A3850AC1BE2E735051E786F7189A1785298F17BCD5CD198731C566533BA786A40A5AABA2AD371193C9F3DD0FB1AF5EBFD6F4F5CC2EFF5953C9F3DD0FB1AF5EB4E70A05D1297E1BBCB5012B2E24CD356 X-Mailru-Sender: DBC2F4F1B1B33C64B837EEACE6D760D0B80410A2C624C14EDFA0BCB064EF36BE31F5BB1E3305B3FEDF27400FA58A4AF1E66B5C1DBFD5D09D63761FFB9297ED015BF713DEE2A5F4A567EA787935ED9F1B X-Mras: OK Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jan 2019 00:36:17 -0000 27.01.2019 0:14, Дилян Палаузов пишет: > Hello, > > reiterating over the arguments against sending reports to the ruf= …dmarc address, the first provided reason was, that > such report will not match the expectations of the users. > .... very good technical arguments skipped.... Nope, the point was it can finally lead to violation of privacy and legal risks. Since you probably speak Russian, I can give some good example. As you may be know, E-mail in Russia is regulated by Telecommunication Act (Закон о связи). Article 63.4 ("communication privacy") says "Information about messages sent via electronic communications ... and said messages .... can only be provided to sender or recipient ...". To make a ruf report one should send information about message to address which is neither sender nor recipient. Your argumentation is very good to explain a technical staff why some partial information can be safely sent to some site. The only problem is, there is no need to explain it here, you should satisfy a lawyer. > It can be assumed, that sending reports to the ruf= address at a certain domain > matches the expectations of the users of that domain and any non-matching expectation is a problem of the one who > published the ruf= entry, not the one generating a report. I do not say that once the report is generated and sent the > sender has to store the report, so that the expectation of the user, that received the initial mail, are also met, when > the report generating server does not store a copy of the sent report. > > The second argument was, that staff managing DNS and staff managing emails (and able to read user’s email) are > completely different persons. I do read here, that the DNS staff can use its posititon to insert arbitrary email > addresses in the ruf= tag and by this way come in a position to read emails, that otherwise the DNS staff would not be > entitled to read. Seriously, if the ruf= tag is not trusted, why shall the p= tag be honoured, and why shall also be > the DKIM public signature and MX record be trusted? Either the ruf= email address is trusted to receive reports, or the > whole DNS of the sending domain is not trusted. > > The third argument is, that in case 1% ouf of 10 000 000 messages between two hosts are reported in the aggregate > message not to match DKIM, then it is worth investigating the cause. Alright, that is exactly my point. I want the > reports, provide ruf=, and don’t receive the reports. Where will you start investigating? How can you find out if the > problem is on the sender or receiver side? If you validate once again your implementation and find nothing wrong with > it, does it prove, that the implementation of other side has bugs? Perhaps the other side has also proven in the very > same way, that it is error-free. You see only that 1% of the messages do not match DKIM validation, now and then. What > is the next step to make signer and verifier compatible? > > Guessing? If making signers and verifier compatible can be achieved only by guessing, then DMARC cannot be trusted/is > not mature. > > I have no problems if due changes somewhere DKIM for a while fails, as in this case there is nothing I can do. But I > want to be sure, that the cause is not on my side, and currently this is not evident. It is just not clear, if there is > a problem report, if the problem is temporary, when the cause was resolved, if the cause is on my side… This properties > make DMARC not reliable. > > Regards > Дилян > > On Sat, 2019-01-26 at 12:56 -0500, Dotzero wrote: >> Please, RUF is a ""Failure Report", not a "Forensic Report". Please read RFC 7489 - https://datatracker.ietf.org/doc/rfc7489/ >> >> On Sat, Jan 26, 2019 at 12:21 PM Дилян Палаузов wrote: >>> Hello John, >>> >>> On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: >>>> In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.camel@aegee.org> you write: >>>>> How can a domain owner communicate, that its users agree to have investigations on forensic reports, where DKIM >>>>> signatures failed (fot the purpose of avoiding repeating errors in DKIM signing/validation)? In particular, that there >>>>> is no expectation of the users that a deleted message is erased and that the domain owner, DNS staff and email staff >>>>> function good as whole? >> This is way outside the scope of DMARC., however, the very fact that the domain has provided an email address for receiving RUF reports is a pretty reliable indicator. Presumably DNS and mailops staff work for/on behalf of the domain owner. >> >>>> I suppose they could try to put it in the terms of service, but I >>>> wouldn't begin to guess whether that would be enforcable or even legal >>>> in places with the GDPR and other privacy laws. >>>> >>>> More to the point, I wouldn't bother. The failure reports are almost >>>> entirely useless. Of the ones I get, the majority are random Chinese >>>> spam that happened to forge one of my domains on the From line, the >>>> rest are from mailing lists where I wouldn't expect DMARC to pass. >> Clearing out the chaff originating from servers other than your own helps, but I'm not going to try to teach John anything. >>> A domain owner can certainly clarify anything in the terms of service, but even if the domain owner does these >>> clarifications, s/he will not receive DKIM/DMARC forensic reports, because there is no mean to communicate to the >>> generators of those reports, that sending forensic reports violates users expectations. >> Individual user expectations are well outside the scope of DMARC. It is a domain/subdomain level protocol. If you don't want the reports then don't provide a destination for them to be delivered to. >>> The reasons mentioned here against sending forensic reports were, that this might not match user expectations (on >>> deleted information) and because email staff and DNS staff may differ. I approached both concerns, by stating that user >>> expections can be put in Terms of Use and that a domain owner can decide, that for a domain it is acceptable to receive >>> forensic reports and insert this infomation in the Terms of Use. So… what else exactly needs to happen, to resolve the >>> concerns against sending forensic reports (which was my original question)? >>> >>> If GDPR is the only concern, this can also be clarified. But clarifying that GDPR is not a problem, will be losing >>> time, if independent of it there are other concerns. >>> >>> Imagine there is a failure report stating that after a direct communication between your server and another server, the >>> receiving server sends you an aggregate report, stating that 1% of the messages you sent yesterday do not validate DKIM. >>> How do you suggest to proceed to reduce this to 0%? >> Over time you are unlikely to keep "legitimate" failures at 0%. There are lots of moving parts and pieces that can cause a failure. It also depends on the characteristics of the mail streams involved. The domain owner(s) and staff will need to determine how much effort they are willing to put in eliminating (legitimate) email failures. If I'm sending 10 million emails to a domain and 1% are failing then I'm likely to look into it. On the other hand, if I'm sending 100 emails a day to a domain from an overall large system and 1% (1 email) is failing, that really falls into the noise and is unlikely to get much time spent on it. >> >> Michael Hammer >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru From nobody Mon Jan 28 01:15:20 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7EF130FBB for ; Mon, 28 Jan 2019 01:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 DbwJOebM8KGr for ; Mon, 28 Jan 2019 01:15:17 -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 EDB6D1294FA for ; Mon, 28 Jan 2019 01:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1548666914; bh=xLWK6fQwDtNsFsZ6qLFO49owdU+OyNrULT3qEzlQjZQ=; l=972; h=To:References:From:Date:In-Reply-To; b=CwTtdIL+CGsRYnrOoBMgrAaVeqfUd5uO3P/aUXMYb1MsTJxJMb2NkJyjp/XYwoOKp Q+k/eqeGt4bbaLeH6xvnC8eMqVXZNNle+Q8zPir412lwrzbi0eohA5nZJMPszcpOqf 1mvcGneZ6Viq9v1PlHG97IMQs9AwkEE5n7PofLu1ClTlwomw7F4ZlDVeQLpbH Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 28 Jan 2019 10:15:13 +0100 id 00000000005DC013.000000005C4EC821.00005660 To: dmarc@ietf.org References: <20190126163123.AAA4B200D39816@ary.qy> <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <78afc62c-740d-0762-2d29-ba952ab35003@tana.it> Date: Mon, 28 Jan 2019 10:15:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jan 2019 09:15:19 -0000 On Sat 26/Jan/2019 18:21:28 +0100 Дилян Палаузов wrote: > Imagine there is a failure report stating that after a direct communication > between your server and another server, the receiving server sends you an > aggregate report, stating that 1% of the messages you sent yesterday do not > validate DKIM. How do you suggest to proceed to reduce this to 0%? No way. There are lots of little traps, for one example plain text messages where a line start with "From ", like so: >From here on, this message likely fails DKIM. As small as this cases appear, if you program your MTA to fix them before DKIM signing, you are going to break any OpenPGP/SMIME signatures that users had affixed before. You can educate users to use format=flowed, good luck. You can push for global maildir usage, even harder. The bottom line is that, in practice, understanding where that 1% failures come from won't help eliminate them. Best Ale -- From nobody Mon Jan 28 04:04:01 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66014131023 for ; Mon, 28 Jan 2019 04:03:59 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 PwdYRnKomwrU for ; Mon, 28 Jan 2019 04:03:56 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 7EAC6131025 for ; Mon, 28 Jan 2019 04:03:56 -0800 (PST) Authentication-Results: mail.aegee.org/x0SC3c61013721; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1548677027; i=dkim+MSA-tls@aegee.org; r=y; bh=N4fP/VjxhInNCE0w3tE+52E00yHkTGLm8W0msxIFvl4=; h=Subject:From:To:Date:In-Reply-To:References; b=LXBDXAKgZ6h/cqzpNrrbGRwRbzGp+GL525o32fyA+OF/RWcngttk9NCx5UgbYy3Bg KOrEtWDdUMEqvSwEkloRcB5TXAAnadfEUaPVZlL8aZFmNlqJhdcG6SdMPOu+QkRHNC Q4ZbNDGvRLUIj/IZHlYx5PUxNnOtFpHh0NFYcT6TsO7tNimVHWVCqsxY3Rq7vn8zpS J/pGXqVuw1x9fjb6ntmDDkCdRRBhKNEfUm4CpE8Vn/nBB+8g9QgA/rzm/CpoTvEha1 tF0IF5pa5w87MmK8pynfqfPctnBrKwEGo9yQWT6c18nh8GX4hKC6hM/IUuxXC66pm7 VhQVcXzleyHkUHSSwcUdWkVpsfLn2SNepTcNcXRH1ICbbrKWiiIXudpr/zamHq4Nwg P5yYwL0F60zjme2lhPHX2gzlxT+Uz7JrvcoX2yEPUfz8IiPRLnNuWPSK95jLT481oR V0cliDkQ31DIMqCkxMlCwcpDEdJy6EHvBvDFeAeyyBO7VGSoXUT9T8J3QiIIZC0GqM YIKNj+0zs+rqajIup7gu+W1LZdlaLAp9CAUxyts7EXwhap2cC4V9omF4reZFaQ+rM/ rFzDA32oU9AhKt4m0ibjgacJvtc9c90QMVyEG6lMvFHD3tCyicGvRESukwloXnaUNY XaqBM7ExCDVD1f2fVn0lVIF8= Authentication-Results: mail.aegee.org/x0SC3c61013721; dkim=none Received: from Tylan (adsl-62-167-97-198.adslplus.ch [62.167.97.198]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x0SC3c61013721 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Jan 2019 12:03:38 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Alessandro Vesely , dmarc@ietf.org Date: Mon, 28 Jan 2019 12:03:37 +0000 In-Reply-To: <78afc62c-740d-0762-2d29-ba952ab35003@tana.it> References: <20190126163123.AAA4B200D39816@ary.qy> <5cd324dcd2d76a77618f3f77d7d7a644c2d13564.camel@aegee.org> <78afc62c-740d-0762-2d29-ba952ab35003@tana.it> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.90 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jan 2019 12:04:00 -0000 Hello, sending a notification, when DMARC does not match is comparable to sending a notification/feedback loop, when a user clicks a message as spam. In practice, when a company owns two labels, that were distinct companies in the past, for the one label the new company sends in the feedback loop the user, who clicked the the mail as unwanted, and the other label does not include the recipient’s mailbox. Both labels include the Message-Id in the report. So when the messege was sent to one user, with the Message-Id it is possible to determine which user clicked the mail as unwanted (provided no transparent MLMs were involved). When the message was sent over a mailing list, from the Message-Id it is not possible to determine which user marked the mail as unwanted. It is technically possible to provide to every single recipient-copy spread over a mailing list a distinct Message-Id, in order to be able to conclude from the feedback-loop message, which user marked the mail as unwanted, and be able to unsubscribe the user from the mailing list. Is this the way to go, or is the rationalle that the one who implemented the feedback loop including Message-Id intentionally skipping the recipient mailbox do not understand the big picture? Will be there any rational concerns, if for a failed DKIM validation a report is sent to the signing server, containing just the Message-Id, when From: alignes and DMARC p!=none? Regards Дилян On Mon, 2019-01-28 at 10:15 +0100, Alessandro Vesely wrote: > On Sat 26/Jan/2019 18:21:28 +0100 Дилян Палаузов wrote: > > > Imagine there is a failure report stating that after a direct communication > > between your server and another server, the receiving server sends you an > > aggregate report, stating that 1% of the messages you sent yesterday do not > > validate DKIM. How do you suggest to proceed to reduce this to 0%? > > No way. There are lots of little traps, for one example plain text messages > where a line start with "From ", like so: > > > From here on, this message likely fails DKIM. > > As small as this cases appear, if you program your MTA to fix them before DKIM > signing, you are going to break any OpenPGP/SMIME signatures that users had > affixed before. > > You can educate users to use format=flowed, good luck. > > You can push for global maildir usage, even harder. > > The bottom line is that, in practice, understanding where that 1% failures come > from won't help eliminate them. > > > Best > Ale From nobody Mon Jan 28 09:54:19 2019 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 7611B1310D8; Mon, 28 Jan 2019 09:54:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc@ietf.org, alexey.melnikov@isode.com, tim@dmarcian.com, rfc-editor@rfc-editor.org, dmarc-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154869804947.2967.8834979870275709451.idtracker@ietfa.amsl.com> Date: Mon, 28 Jan 2019 09:54:09 -0800 Archived-At: Subject: [dmarc-ietf] Protocol Action: 'Message Header Field for Indicating Message Authentication Status' to Proposed Standard (draft-ietf-dmarc-rfc7601bis-05.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jan 2019 17:54:10 -0000 The IESG has approved the following document: - 'Message Header Field for Indicating Message Authentication Status' (draft-ietf-dmarc-rfc7601bis-05.txt) as Proposed Standard This document is the product of the Domain-based Message Authentication, Reporting & Conformance Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ Technical Summary This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. Working Group Summary There is strong consensus for this document in the DMARC WG. The WG set out to update 7601 with only minimal changes needed to bring the document current with existing practice (EAI), ongoing refinement of existing specification (DKIM), and change needed to simplify ongoing WG development (ABNF changes). Editorial changes are only picked up to correct errors and grammar nits. There was some appetite to include additional editorial and content changes, but the WG's scope required changes to be obvious and non-controversial. Document Quality This is widely implemented specification and there are multiple implementations. Personnel The Document Shepherd for this document is Tim Draegen. The responsible Area Director is Alexey Melnikov. From nobody Mon Jan 28 10:30:25 2019 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 67713131113; Mon, 28 Jan 2019 10:30:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154870021337.3001.8219304411425338018@ietfa.amsl.com> Date: Mon, 28 Jan 2019 10:30:13 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-06.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jan 2019 18:30:13 -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 WG of the IETF. Title : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-dmarc-rfc7601bis-06.txt Pages : 52 Date : 2019-01-28 Abstract: This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. This document obsoletes [RFC7601]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-rfc7601bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-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/ From nobody Mon Jan 28 11:22:04 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E7F13118E for ; Mon, 28 Jan 2019 11:22: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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=LnspRAr7; dkim=pass (1536-bit key) header.d=taugh.com header.b=RNTSYUpy 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 NscGCwjel3wY for ; Mon, 28 Jan 2019 11:22:00 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 1DCB9130EAE for ; Mon, 28 Jan 2019 11:22:00 -0800 (PST) Received: (qmail 55664 invoked from network); 28 Jan 2019 19:21:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d96c.5c4f5657.k1901; bh=Y8EHwpXcx70kBTqoR1JTUoIX2Q++dGyexrgXQ+Ugnm8=; b=LnspRAr7n5xjKfy5AG8PO2MXyRnrjUN9U5uNr45ltIRPGGRCAOEuw4F3HPSfE8T7kKK6JT1/pEVEX5ZH0+Qr35FKXHJbj+TRbuxTMjV2k73HzS7/jvEce8/MHNJ8wR9absO8bkXOP1t7MP1M/zW7mgjLRNmLmvlv7e7cCMnpuFkw6WeICAmE8TqkuF+Ji2SeKPqo0hAwZT2vsW6T/DncidQhRi3dSu92nqQ3EG/dxVr7S8LR3P+9Kz4QyHRcSVf5 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d96c.5c4f5657.k1901; bh=Y8EHwpXcx70kBTqoR1JTUoIX2Q++dGyexrgXQ+Ugnm8=; b=RNTSYUpygJXejWxBE3D0G7aaIrsAPJJ9uAzB/iJMwR+tCxykm5drYgaKHdLi2II70rnapg9PWvsM+zwWu7Z6R8h5fgAenb8jNAd+InX5Fgq2N2X9pvVfrCIvmZ8DDi34zzPKiCCchN27CYyFd7W35PGhFUs7zGcgU1l6U4ETu54maWGUXhyULJmp1pC7TCoge68u02vDuD/SbeJYrBEvl0uadYjod+R526hr8j/kc/bY/dNnakSodtLX5zHjM3GG Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 28 Jan 2019 19:21:58 -0000 Received: by ary.qy (Postfix, from userid 501) id D02A2200D64851; Mon, 28 Jan 2019 14:21:58 -0500 (EST) Date: 28 Jan 2019 14:21:58 -0500 Message-Id: <20190128192158.D02A2200D64851@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dilyan.palauzov@aegee.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jan 2019 19:22:02 -0000 In article you write: >sending a notification, when DMARC does not match is comparable to sending a notification/feedback loop, when a user >clicks a message as spam. No, it isn't. When the user clicks the spam button, she has taken a specific step to notify someone about the message. DMARC forensic reports are entirely automated. But once again, I am pretty sure the people who you would need to persuade are not on this mailing list, or any IETF mailing list. R's, John