From nobody Tue Feb 6 08:53:46 2018 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 8AF4512D866 for ; Tue, 6 Feb 2018 08:53:24 -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, HTML_MESSAGE=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 (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 ZkZNoV9JwKVX for ; Tue, 6 Feb 2018 08:53:21 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 6326112D855 for ; Tue, 6 Feb 2018 08:53:21 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id h92so3687948lfi.7 for ; Tue, 06 Feb 2018 08:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BHKYu4XVg+0RkqP0iFDeHCBMiBNdMrIl6Arwyb3SBfY=; b=E5F3y9pWl98G98Isn+jc3V4K5nD5dSRWINS+uSsS9oDGYBsuu6+z2fjnHkfcRGhY7m ETO0HtL1Z+0FZgw7r46z1iFU5RKbN9p9OA4iHHScqjahuOztf3KyNNTE8GXJviYAKV37 sB39nAIj0orGwjFWIaAG3y3tVke/1e7YIj7J4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BHKYu4XVg+0RkqP0iFDeHCBMiBNdMrIl6Arwyb3SBfY=; b=buirfHCikrRfw5gbRfoVNGu/rvEvetx65MGS0CTgy78THe/np15oC2J4P+nPAvDkkA S1x0XVFW3I/ey0rvu3nyxcosUPlu9xBZtnwa9ftp6k1YzNQx4IkEtJB2qFIyGpqllrGZ Kp7psTGpJY8JFIXXIDs7WJcwoxnJdDFMQDgQswpRHWtIrRRYKfHm4Nbp5v9jKbiGqlyL f6dtb+O2YfCRQIw/7vqn51lNt3bPOGrdojpAuYjCPUNkubGXc7JXhDB9jt6KNeby1PJ2 I728a4R+0WGixlvrSdQYP5fk/LaVAGP3miDgIFTc4vjySohYiJ7m/LTlKab9U0+ZsOvM h3fA== X-Gm-Message-State: APf1xPCDZiz2nuQNzygWcdAAeONYSq8BBEXJZEaP0G7bP+rdrjR3H4sH gb3FBKC050cFLVpmGygoFxByjwOJ+VYP8z7Hv6ygPQ== X-Google-Smtp-Source: AH8x227FNEGsF6esX0NJYflOhLvvmZgYAu0x3pYvhIRdGRV8PvJPPXSWq4FRY60XEoZ35yIl9TF4eeUncXRQ+P6Gods= X-Received: by 10.46.32.66 with SMTP id g63mr2150913ljg.75.1517935999494; Tue, 06 Feb 2018 08:53:19 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.193.138 with HTTP; Tue, 6 Feb 2018 08:53:18 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 6 Feb 2018 11:53:18 -0500 X-Google-Sender-Auth: CMODWOLWdsdEG145rTbG3UPgIBw Message-ID: To: Barry Leiba Cc: Tim Draegen , Ned Freed , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1142bb700acf9e05648e044e" Archived-At: Subject: Re: [dmarc-ietf] DMARC-WG F2F @ IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 06 Feb 2018 16:53:24 -0000 --001a1142bb700acf9e05648e044e Content-Type: text/plain; charset="UTF-8" On Tue, Jan 30, 2018 at 2:05 PM, Barry Leiba wrote: > > I'd like to request a F2F meeting in London at IETF101. I plan to create > a > > WGLC-eligible draft as soon as the 7601bis-01 work lands in a form that > can > > be referenced by the protocol spec. > > > > Ideally we could launch WGLC for the ARC protocol before the end of > > February. > > Let's change that from "ideally" to a firm commitment, can we? Progress > hasn't been ideal, and we need to set schedules that we'll keep. > Still waiting for 7601bis-01 to be released (unless I've missed that notice). > > IETF101 would be a great opportunity to discuss the next steps for the > WG. > > I'm happy to have that time; I will request a one-hour session. Sounds good > I expect that we won't be spending any of that session time on the ARC > protocol document itself. We may want to chat a bit about the adjacent document for evolving signing algorithms but I think that the protocol doc should be settled. > Ideally (ah, there's that word...) we can spend some time reviewing early > results of using ARC in the field. > > In other words, let's see some implementations and find out how well this > works in practice. Sure - though I think we already have that info now and I'd be surprised to find any material changes in the next 6 weeks. There will be some discussions in SF at M3AAWG in a couple of weeks that may help to put the information into more readily consumable form. --Kurt --001a1142bb700acf9e05648e044e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 30, 2018 at 2:05 PM, Barry Leiba <barryleiba@computer.org> wrote:
>= I'd like to request a F2F meeting in London at IETF101. I plan to crea= te a
> WGLC-eligible draft as soon as the 7601bis-01 work lands in a form tha= t can
> be referenced by the protocol spec.
>
> Ideally we could launch WGLC for the ARC protocol before the end of > February.

Let's change that from "ideally" to a firm commitment,= can we? Progress hasn't been ideal, and we need to set schedules that = we'll keep.

Still waiting for 7601b= is-01 to be released (unless I've missed that notice).=C2=A0
= =C2=A0
> IETF101 wo= uld be a great opportunity to discuss the next steps for the WG.

I'm happy to have that time; I will request a one-hour session.= =C2=A0

Sounds good
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">I expect that we won't be spending any of= that session time on the ARC
protocol document itself.=C2=A0

We may wan= t to chat a bit about the adjacent document for evolving signing algorithms= but I think that the protocol doc should be settled.
=C2=A0
Ideally (ah, there's that word...) we c= an spend some time reviewing early results of using ARC in the field.

In other words, let's see some implementations and find out how well th= is works in practice.
=C2=A0
Sure - though I thi= nk we already have that info now and I'd be surprised to find any mater= ial changes in the next 6 weeks. There will be some discussions in SF at M3= AAWG in a couple of weeks that may help to put the information into more re= adily consumable form.

--Kurt

--001a1142bb700acf9e05648e044e-- From nobody Wed Feb 7 18:54:05 2018 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 3783E129515 for ; Wed, 7 Feb 2018 18:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 9tMSJ8944SE0 for ; Wed, 7 Feb 2018 18:54:02 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC5C12946D for ; Wed, 7 Feb 2018 18:54:01 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id t79so4310873lfe.3 for ; Wed, 07 Feb 2018 18:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5vOobk6uUtEvE2LFs398nPL3PouXb8LBKRFNzG5oEMY=; b=PskUZ8HcE12igfXR9LK7oB7pd0F6gKYGwLimF0YTOsAphT55nuR6mQG0VPQwgNhgyp 31atduUNDyDkMgY9VSXDVVt4GZuaQ1Aua+kv1pEr4S5A2n9e5+EtO9Ny+eEdbeShI0nr rl0FiWlyJFdyFp19YzwzNb7qZGzPSB3ywnKZkmfWcHZyPQWrVURLaUDUCn0V5OluOScK YvxVxyWQEhvAuzf/uA6mJrWLQH/duj+qeKhQOifAcmWmX3O2/VYg6U1BLBUasNK0RSAc 7YVHHBUE8UJby2NSg3HSmApeW+PyfL7Mg4Fx64De69p3dJSdoXwRDTQaqrlB24Nhqptu msnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5vOobk6uUtEvE2LFs398nPL3PouXb8LBKRFNzG5oEMY=; b=leropmaMp5wL3zPM5hYnuRLpJAjC2M9grALxyGXGc9CfwQq1cbsqAt0RFD+TgF0AlJ jszUmWtfkEINlRD4R5TknkvVnS2yhAAm7PqjlV1rxz+9MOJnpx1UYlh1dgL7Yhgyip7I 1RloEhFbkqd072DzKqOPGMluKHBFfPHiNfdZhXceXuWlBsBrnWUrv5wZDc5sSUuFxYlp SN23vDdrJbcjnKGX4XIeK5Vnuh54dTvvi8vw7SF/R6nCC70sqk6t8xEtVSflsOqv16AE qP7WBI9+kA5ocTK2wx2LWHq1ynjEIXRq3DLGyDc1tvGuXF6KfBkn9nn2uC6xbGd1txV2 zOFQ== X-Gm-Message-State: APf1xPBjKWoYn5PwHp/WQTlrj7Sf0Ex1/tisFEAtbRlYSTIJQdWkd7YA UJOwoY+5TcU69H9gYHwOzs7ANCOABx1qmex5w0w= X-Google-Smtp-Source: AH8x227+3O/tlMeWMWnsvBcf5e1QJoNFdmar2kDNH5UdM73B73grySXpmfHn8c6HRbgBBac8A8Vls5TH00yNugbL6us= X-Received: by 10.46.126.18 with SMTP id z18mr5434487ljc.131.1518058440092; Wed, 07 Feb 2018 18:54:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.66.79 with HTTP; Wed, 7 Feb 2018 18:53:59 -0800 (PST) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 7 Feb 2018 18:53:59 -0800 Message-ID: To: "Kurt Andersen (b)" Cc: Barry Leiba , Tim Draegen , "dmarc@ietf.org" , Ned Freed Content-Type: multipart/alternative; boundary="089e0827c10411f2760564aa86fc" Archived-At: Subject: Re: [dmarc-ietf] DMARC-WG F2F @ IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 02:54:04 -0000 --089e0827c10411f2760564aa86fc Content-Type: text/plain; charset="UTF-8" On Tue, Feb 6, 2018 at 8:53 AM, Kurt Andersen (b) wrote: > On Tue, Jan 30, 2018 at 2:05 PM, Barry Leiba > wrote: > >> > I'd like to request a F2F meeting in London at IETF101. I plan to >> create a >> > WGLC-eligible draft as soon as the 7601bis-01 work lands in a form that >> can >> > be referenced by the protocol spec. >> > >> > Ideally we could launch WGLC for the ARC protocol before the end of >> > February. >> >> Let's change that from "ideally" to a firm commitment, can we? Progress >> hasn't been ideal, and we need to set schedules that we'll keep. >> > > Still waiting for 7601bis-01 to be released (unless I've missed that > notice). > It's been sent to the datatracker and is awaiting WG chair approval as a WG document. -MSK --089e0827c10411f2760564aa86fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 6, 2018 at 8:53 AM, Kurt Andersen (b) <kboth@d= rkurt.com> wrote:
On Tue, Jan 30, 2= 018 at 2:05 PM, Barry Leiba <barryleiba@computer.org> = wrote:
> I'd like to request= a F2F meeting in London at IETF101. I plan to create a
> WGLC-eligible draft as soon as the 7601bis-01 work lands in a form tha= t can
> be referenced by the protocol spec.
>
> Ideally we could launch WGLC for the ARC protocol before the end of > February.

Let's change that from "ideally" to a firm commitment,= can we? Progress hasn't been ideal, and we need to set schedules that = we'll keep.

Still waiting fo= r 7601bis-01 to be released (unless I've missed that notice).=C2=A0

It's been sent to = the datatracker and is awaiting WG chair approval as a WG document.

-MSK
--089e0827c10411f2760564aa86fc-- From nobody Wed Feb 7 19:33:33 2018 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 E0E9C12D77D for ; Wed, 7 Feb 2018 19:33:32 -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, HTML_MESSAGE=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 (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 sqqZ-LGS3LSU for ; Wed, 7 Feb 2018 19:33:31 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 BE9F912D7E7 for ; Wed, 7 Feb 2018 19:33:30 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id t79so4402699lfe.3 for ; Wed, 07 Feb 2018 19:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ihkwMepUT3pqiorGQwIpjigCmFwuCiGeISsAe/tl/vE=; b=RHEuflS1boMiaotK2l1OkOSp6+NFTvA2UiwI8LUp4KxtdikHgcSyzqdCJmDTl4a11U biij+iIvOB7UPf7Kb3nzUv0rRzj1w6tGGPgeE8rTKM3voBb7ujNx4k302d/M7hWNbefX 31pViWRt+0/jk4X8PT1h/uU6L5+qgqsl8Mq3A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ihkwMepUT3pqiorGQwIpjigCmFwuCiGeISsAe/tl/vE=; b=OHJRueYdTXQn3I4/qA7GX5aHwdw+cLGe4uCr9S1b22rMe/IiAHVdFfPJgyl2LBDn+a 9g2gxEKv8N8QGaP72wYB7F6AtXjt6Ij9gRaSEvssCabZa4WkjrKxOtVVw+qwtoChwjVX tX6OpbAa4/GzBFSpd57p+iKfGKW4Gun+L2itgLfJsQTC1R/p88rp+3xqdA6WK+XmvcZS /iYPiaYf5P7NHM1lo2CxrRxYx/9psYfC8+OnYkJ+hrmqTvC6sk/mS5dNkVht5PkCxsL5 2OvFQhu/3+tIP4sjYvRMthiXGR0iSB/YLPY7Ull3d5VKi8aNCtx861jHseqCz/OAwvgI ZcKg== X-Gm-Message-State: APf1xPDKeOqjEITd2ingJUKCXpNJQym5Hfq825Xp0rmY73mJ2NYUfw3t HxbBuC78Q204wQx+nPM4hGHJGF2FDdwfOpBabCJVme65 X-Google-Smtp-Source: AH8x224WWNgDqC/Hj6KOP5RaUdrlTivvLD08GkXqz3xQU0/kj28h0ciLa/RbxcYrhtdEyV3rMQZ5O7oLAdpdkVJSA0Q= X-Received: by 10.25.80.92 with SMTP id z28mr5421042lfj.34.1518060808901; Wed, 07 Feb 2018 19:33:28 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.193.138 with HTTP; Wed, 7 Feb 2018 19:33:28 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 7 Feb 2018 22:33:28 -0500 X-Google-Sender-Auth: 1QX28aNXbFaaYFZewD-xeiwS3sg Message-ID: To: "Murray S. Kucherawy" Cc: Barry Leiba , Tim Draegen , "dmarc@ietf.org" , Ned Freed Content-Type: multipart/alternative; boundary="94eb2c1cd35e433f620564ab1346" Archived-At: Subject: Re: [dmarc-ietf] DMARC-WG F2F @ IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 03:33:33 -0000 --94eb2c1cd35e433f620564ab1346 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 7, 2018 at 9:53 PM, Murray S. Kucherawy wrote: > On Tue, Feb 6, 2018 at 8:53 AM, Kurt Andersen (b) > wrote: > >> On Tue, Jan 30, 2018 at 2:05 PM, Barry Leiba >> wrote: >> >>> > I'd like to request a F2F meeting in London at IETF101. I plan to >>> create a >>> > WGLC-eligible draft as soon as the 7601bis-01 work lands in a form >>> that can >>> > be referenced by the protocol spec. >>> > >>> > Ideally we could launch WGLC for the ARC protocol before the end of >>> > February. >>> >>> Let's change that from "ideally" to a firm commitment, can we? Progress >>> hasn't been ideal, and we need to set schedules that we'll keep. >>> >> >> Still waiting for 7601bis-01 to be released (unless I've missed that >> notice). >> > > It's been sent to the datatracker and is awaiting WG chair approval as a > WG document. > I thought that only the initial version of a document required chair-bump. Revisions to the documents have only taken author confirmation for me. --Kurt --94eb2c1cd35e433f620564ab1346 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 7, 2018 at 9:53 PM, Murray S. Kucherawy <superuser@gmail.com= > wrote:
On Tue, Feb 6, 2018 at 8:53 AM, Kurt Andersen (b) <kboth@drkurt= .com> wrote:
On Tue= , Jan 30, 2018 at 2:05 PM, Barry Leiba <barryleiba@computer.org&= gt; wrote:
> I'd like= to request a F2F meeting in London at IETF101. I plan to create a
> WGLC-eligible draft as soon as the 7601bis-01 work lands in a form tha= t can
> be referenced by the protocol spec.
>
> Ideally we could launch WGLC for the ARC protocol before the end of > February.

Let's change that from "ideally" to a firm commitment,= can we? Progress hasn't been ideal, and we need to set schedules that = we'll keep.

Still waiting fo= r 7601bis-01 to be released (unless I've missed that notice).=C2=A0

It's been s= ent to the datatracker and is awaiting WG chair approval as a WG document.<= /div>

I thought that only= the initial version of a document required chair-bump. Revisions to the do= cuments have only taken author confirmation for me.

--Kurt=C2=A0

--94eb2c1cd35e433f620564ab1346-- From nobody Wed Feb 7 19:58:37 2018 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 61FF712D84E for ; Wed, 7 Feb 2018 19:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkfW4Tnq0daa for ; Wed, 7 Feb 2018 19:58:33 -0800 (PST) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) (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 05C9512D849 for ; Wed, 7 Feb 2018 19:58:33 -0800 (PST) Received: by mail-qt0-f179.google.com with SMTP id s39so4589004qth.7 for ; Wed, 07 Feb 2018 19:58:32 -0800 (PST) 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=AjWuVUp2BEMwEIvgEoyVlConS3Gj8BvkVRkCUmBNGTg=; b=oomgi2jtMLkw2r+NzV7rk+hGamutzc8159sSaZDiyv03oNCR/iG2+4d9i3pAKcuMsp qF/LfXxP+GhuehFs1twkawnrlzcEYYOzfbajJxmLXwGTcYt0sP1G+hU0CEOELUJZtOpM PzB4ac/TcTd74gj+uWzNzKF5MLJyL/ONid0WnUEtL4FMgV55q9xQDLqC8H6KSEpkhcJO q/bUPMsSeXMmka6xKU5vyS1NWbvOfoIo29xtelmbrELwPC0xzrgTd42vVVFGuz3CvCdy VcMVoICTAFE3M5f7AcAVzmEOYNvIQ36kmj8XLvJZ0gRbC2qzdt2g7NmcwXO0xZt1DXNn kAOg== X-Gm-Message-State: APf1xPCmJPvFmgvnuOiZInqqm71z4OyuG/DzB7lWgZou6lOeqhAviHRM 0CjhPST8twJWedZCspDM6sznE3ppO1MZrywKBJc= X-Google-Smtp-Source: AH8x225tl6Th1bKPPoikU8R9MSWuS6+Bfs1EsjTx/1Fw8VmTMdYkN17/ynrGynu9/7RkJdsyiKAld5k8ET1KPUAxav8= X-Received: by 10.200.97.86 with SMTP id d22mr12834961qtm.217.1518062312085; Wed, 07 Feb 2018 19:58:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Thu, 08 Feb 2018 03:58:21 +0000 Message-ID: To: "Kurt Andersen (b)" Cc: "Murray S. Kucherawy" , Ned Freed , Tim Draegen , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c12b076dbe6b40564ab6cc3" Archived-At: Subject: Re: [dmarc-ietf] DMARC-WG F2F @ IETF101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 03:58:35 -0000 --94eb2c12b076dbe6b40564ab6cc3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The previous version was an individual submission, so this is the -00 version for the working group. I=E2=80=99m off to approve it now. b On Wed, Feb 7, 2018 at 10:33 PM Kurt Andersen (b) wrote: > On Wed, Feb 7, 2018 at 9:53 PM, Murray S. Kucherawy > wrote: > >> On Tue, Feb 6, 2018 at 8:53 AM, Kurt Andersen (b) >> wrote: >> >>> On Tue, Jan 30, 2018 at 2:05 PM, Barry Leiba >>> wrote: >>> >>>> > I'd like to request a F2F meeting in London at IETF101. I plan to >>>> create a >>>> > WGLC-eligible draft as soon as the 7601bis-01 work lands in a form >>>> that can >>>> > be referenced by the protocol spec. >>>> > >>>> > Ideally we could launch WGLC for the ARC protocol before the end of >>>> > February. >>>> >>>> Let's change that from "ideally" to a firm commitment, can we? Progres= s >>>> hasn't been ideal, and we need to set schedules that we'll keep. >>>> >>> >>> Still waiting for 7601bis-01 to be released (unless I've missed that >>> notice). >>> >> >> It's been sent to the datatracker and is awaiting WG chair approval as a >> WG document. >> > > I thought that only the initial version of a document required chair-bump= . > Revisions to the documents have only taken author confirmation for me. > > --Kurt > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --94eb2c12b076dbe6b40564ab6cc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The previous version was an individual submission, so thi= s is the -00 version for the working group.

I=E2=80=99m off to approve it now.

b

<= div>On Wed, Feb 7, 2018 at 10:33 PM Kurt Andersen (b) <kboth@drkurt.com> wrote:
= On Wed, Feb 7, 2018 at 9:53 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Feb 6, 2018= at 8:53 AM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
= On Tue, Jan 30, 2018 at 2:05 PM, Barry Leiba <barryleiba@computer.org> wrote:
> I'd like to re= quest a F2F meeting in London at IETF101. I plan to create a
> WGLC-eligible draft as soon as the 7601bis-01 work lands in a form tha= t can
> be referenced by the protocol spec.
>
> Ideally we could launch WGLC for the ARC protocol before the end of > February.

Let's change that from "ideally" to a firm commitment,= can we? Progress hasn't been ideal, and we need to set schedules that = we'll keep.

Still waiting fo= r 7601bis-01 to be released (unless I've missed that notice).=C2=A0

It's been s= ent to the datatracker and is awaiting WG chair approval as a WG document.<= /div>

<= div class=3D"gmail_extra">
I thought that on= ly the initial version of a document required chair-bump. Revisions to the = documents have only taken author confirmation for me.

--Kurt=C2=A0
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--94eb2c12b076dbe6b40564ab6cc3-- From nobody Wed Feb 7 19:59:24 2018 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 B92BC12D878; Wed, 7 Feb 2018 19:59:22 -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.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151806236270.17065.12258796242811833115@ietfa.amsl.com> Date: Wed, 07 Feb 2018 19:59:22 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 03:59:23 -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-00.txt Pages : 48 Date : 2018-02-07 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. 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-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 Wed Feb 7 21:11:54 2018 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 B31B2126C19 for ; Wed, 7 Feb 2018 21:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 KbQ_6rSbxYza for ; Wed, 7 Feb 2018 21:11:51 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 64D1B1241F5 for ; Wed, 7 Feb 2018 21:11:51 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id q17so4601627lfa.9 for ; Wed, 07 Feb 2018 21:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3LUABU5uPhXbaA9uPGEOLScBa+Ng5DcvYBiX5JWBzcU=; b=dEfi4R9opPyN6hU+uqxGZBQxe/DeDtt/LJ72YjVNSiK7hSeWJ8rFcd3wA5DgByu2Mn lgAfxws3TSV8HQYrCMh3jMMDKK7CYc21jOhNDoax8yFwODtlxVACymd1K9n58wH5ktTK uEYSM47/CYNd9zaQSQZSmroZay8HYeqY11N4SDvaumbbH8y3kyjOWrPDQCEjCQNcJeFB ugeC0hTAKPt+xIyzfsakbWeHJDHIBUPlmEYvAFY0JA05OAWx4oaqe/gK0PT8Bd6G+hMB JLbF6+e6iWfD/FXrQQVe9V4K0NRld5h4cn6KVZ+HqGc47sYMDCk4s/bUgMPxFEUVy+nK xF6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3LUABU5uPhXbaA9uPGEOLScBa+Ng5DcvYBiX5JWBzcU=; b=EApJ7xuA3mY8lSSJKECWgBYJMCoqLknUxnVEvU/YYUFlBYiWZ1zPUcOTV9hvdPQutk n/9+SqCXP29toxVFqiTZ4RlpJyRHhnDMFoAJSznAKyhBvea237COjtm4P2u1nnhf1Wum 20FZdZ09RZpiQGE0uID1s22+3JFSn8/DsUtWUo1K7DeZ7v/04g9bJIlyAzH6JKExMo48 VhpJ13oDbHOeeQefl+Z1nFXtNhXXYzRUnY6+rjECOfT+2KWT47yOfBdV25hhGgg315WU pDQEOP9dpgbsaNdmGeXP0VaTGTW1Lle5lxG0avCw/WySeS5ol+XbyGaLq8g0vlMFj3z1 AXnQ== X-Gm-Message-State: APf1xPAnxlZ+pF4UKKAOiPpUZKyuCvTICieoUnEjCyhgzlHeRueWQOc4 GsRYzsPKSEkKBLyiLPNECSU2+9Pslek0/Kgdi5/Z+enK X-Google-Smtp-Source: AH8x225xOpdYlY7ulxhGz76Ix3FwhsV/j9Gb18sYVjybKCHGZryc0aBko6uyrlVspxtVTbbYE3Ks+I7icOlt+EK8cJY= X-Received: by 10.25.198.201 with SMTP id w192mr5439050lff.40.1518066709192; Wed, 07 Feb 2018 21:11:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.66.79 with HTTP; Wed, 7 Feb 2018 21:11:48 -0800 (PST) In-Reply-To: <151806236270.17065.12258796242811833115@ietfa.amsl.com> References: <151806236270.17065.12258796242811833115@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Wed, 7 Feb 2018 21:11:48 -0800 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19d346f264710564ac72bd" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 05:11:53 -0000 --94eb2c19d346f264710564ac72bd Content-Type: text/plain; charset="UTF-8" On Wed, Feb 7, 2018 at 7:59 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > Title : Message Header Field for Indicating Message > Authentication Status > Author : Murray S. Kucherawy > Filename : draft-ietf-dmarc-rfc7601bis-00.txt > Pages : 48 > Date : 2018-02-07 > > 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. > > > 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-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-00 > Et voila. If you go to the "History" tab and request a diff from the individual -00 to the working group -00, you can see all of the changes made relative to RFC7601. Basically it loosens up the language about what categories of things can be recorded, makes the ABNF changes requested, and guts some stuff copied from RFC7601 that doesn't need to be there for this version because it describes registry changes that were already made by that RFC. Let me know if I missed anything. -MSK --94eb2c19d346f264710564ac72bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 7, 2018 at 7:59 PM, <internet-drafts@= ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain-based Message Authentication, Repor= ting & Conformance WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Message Header Field for Indicating Message Authentication Status
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Murr= ay S. Kucherawy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-rfc7601bis-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 48
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-02-07

Abstract:
=C2=A0 =C2=A0This document specifies a message header field called Authenti= cation-
=C2=A0 =C2=A0Results for use with electronic mail messages to indicate the = results
=C2=A0 =C2=A0of message authentication efforts.=C2=A0 Any receiver-side sof= tware, such
=C2=A0 =C2=A0as mail filters or Mail User Agents (MUAs), can use this heade= r field
=C2=A0 =C2=A0to relay that information in a convenient and meaningful way t= o users
=C2=A0 =C2=A0or to make sorting and filtering decisions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-dmarc-rfc7601bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-dmarc-rfc7601bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-00
Et voila.=C2=A0 If you go to the "History" tab and re= quest a diff from the individual -00 to the working group -00, you can see = all of the changes made relative to RFC7601.=C2=A0 Basically it loosens up = the language about what categories of things can be recorded, makes the ABN= F changes requested, and guts some stuff copied from RFC7601 that doesn'= ;t need to be there for this version because it describes registry changes = that were already made by that RFC.

Let me know if I missed anything.

-MSK
--94eb2c19d346f264710564ac72bd-- From nobody Thu Feb 8 12:17:55 2018 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 805191270A0 for ; Thu, 8 Feb 2018 12:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 JNmFnMpM3-0s for ; Thu, 8 Feb 2018 12:17:51 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 D8F63120047 for ; Thu, 8 Feb 2018 12:17:50 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id j15so4434103oii.5 for ; Thu, 08 Feb 2018 12:17:50 -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=6kGKCAaQ/iTIbOkZ881dKh4xO41p/SvBSFx+AjJ+SHY=; b=cvM1yVKuiqk2Vkg+v6wDLGjr2CCns03DxL0Lb7gp8+vk61VJxExQkms/TnWI40DjlQ jTcRreUuREvVrW30TTZX82l+sEf1L/Rr4t6VtDAoHodeADawllEMTCwRvhEHcILV0Z5w QL2NUJiGJudRryQ95TcG9gEd0q5WhaeyalM6wP06NHdS73AwELCf/NHss8Moxrm7BIHJ 047oOGyV6UvV1tG8X03IipQHQNZGpD4TyAOP3RpoV1nlPyjfBRG9D9yEn3M2JOy/PQhx oOCs2oVrVMmHyMres0t8blIhMkOQsvd1W6K6a+ENl8Iid3qVNk3iXlRNNr/E0ngfRKAd AYtg== 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=6kGKCAaQ/iTIbOkZ881dKh4xO41p/SvBSFx+AjJ+SHY=; b=NCrKoQ+CcAzWT/Hnyj5SUFNoaVDV5qbZvgeT1suSagQCJLYPyIXrw4H+zrm5XQm3nO kntoifUIrTg1LTLHTXNwT5PZanMUEuLMphZt3FlNomTj5Ezy3O7rjunMeMXOO4XrsAXC W9QCNB/Ksv/JE1bm7SrocHk043YtH3R3tCvZFeC6igE0kZLAWpYp2RE25bSafHpSVTBZ EwdGrdsYHsDkqGj0W59hPZwnItlI7bjh/RmTsSelUrklo37CXWhO/fYsOGiJG/rKnyJ2 2mPt+ngTf9JASL7tR2OW+rCkqSvY7sJTI2YQa2u4ekeEQUxv/8yP8hAx633eZO034N8F L1jg== X-Gm-Message-State: APf1xPDGMaKyXZTqaeIdtoSYDII5ezTLht1zfYYZwtsyqRzpica7Cx6J 6t+Z5z/aMdQ/pL3YCII30sN80wxgIRsJF5pHyJv94TE0 X-Google-Smtp-Source: AH8x2278QrRo0rUWTx6JlnEG3mCt67WHWL8nEAmLlJ1yepYyUUeEJRu4JvzaZtBbeBsfcvS1AwjQ0odro5D2g2v7nZo= X-Received: by 10.202.48.12 with SMTP id w12mr200832oiw.131.1518121069742; Thu, 08 Feb 2018 12:17:49 -0800 (PST) MIME-Version: 1.0 References: <151806236270.17065.12258796242811833115@ietfa.amsl.com> In-Reply-To: From: Seth Blank Date: Thu, 08 Feb 2018 20:17:39 +0000 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113cd59616a87b0564b91b25" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 20:17:53 -0000 --001a113cd59616a87b0564b91b25 Content-Type: text/plain; charset="UTF-8" Looks great to me. This allows us to simplify several pieces of ARC and make the draft easier to follow. Thank you! On Wed, Feb 7, 2018 at 21:11 Murray S. Kucherawy wrote: > On Wed, Feb 7, 2018 at 7:59 PM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain-based Message Authentication, >> Reporting & Conformance WG of the IETF. >> >> Title : Message Header Field for Indicating Message >> Authentication Status >> Author : Murray S. Kucherawy >> Filename : draft-ietf-dmarc-rfc7601bis-00.txt >> Pages : 48 >> Date : 2018-02-07 >> >> 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. >> >> >> 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-00 >> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-00 >> > > Et voila. If you go to the "History" tab and request a diff from the > individual -00 to the working group -00, you can see all of the changes > made relative to RFC7601. Basically it loosens up the language about what > categories of things can be recorded, makes the ABNF changes requested, and > guts some stuff copied from RFC7601 that doesn't need to be there for this > version because it describes registry changes that were already made by > that RFC. > > Let me know if I missed anything. > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a113cd59616a87b0564b91b25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks great to me. This allows us to simplify severa= l pieces of ARC and make the draft easier to follow.

Thank you!

On Wed, Feb 7, 2018 at 21:11 Murray S. Kucherawy <superuser@gmail.com> wrote:
On Wed, Feb 7, 2018 at 7:59 PM, <internet-drafts@i= etf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain-based Message Authentication, Repor= ting & Conformance WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Message Header Field for Indicating Message Authentication Status
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Murr= ay S. Kucherawy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-rfc7601bis-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 48
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-02-07

Abstract:
=C2=A0 =C2=A0This document specifies a message header field called Authenti= cation-
=C2=A0 =C2=A0Results for use with electronic mail messages to indicate the = results
=C2=A0 =C2=A0of message authentication efforts.=C2=A0 Any receiver-side sof= tware, such
=C2=A0 =C2=A0as mail filters or Mail User Agents (MUAs), can use this heade= r field
=C2=A0 =C2=A0to relay that information in a convenient and meaningful way t= o users
=C2=A0 =C2=A0or to make sorting and filtering decisions.


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-dm= arc-rfc7601bis-00
https://datatracker.ietf.org/doc= /html/draft-ietf-dmarc-rfc7601bis-00

<= div>Et voila.=C2=A0 If you go to the "History" tab and request a = diff from the individual -00 to the working group -00, you can see all of t= he changes made relative to RFC7601.=C2=A0 Basically it loosens up the lang= uage about what categories of things can be recorded, makes the ABNF change= s requested, and guts some stuff copied from RFC7601 that doesn't need = to be there for this version because it describes registry changes that wer= e already made by that RFC.

Let me know if I missed anything.

-MSK
<= /div>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--001a113cd59616a87b0564b91b25-- From nobody Sat Feb 10 10:40:11 2018 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 DDD7712D77D for ; Sat, 10 Feb 2018 10:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01, 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 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 wgQfiQKdNgId for ; Sat, 10 Feb 2018 10:40:07 -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 BD47B12426E for ; Sat, 10 Feb 2018 10:40:06 -0800 (PST) Received: (qmail 36807 invoked from network); 10 Feb 2018 18:40:05 -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=8fc5.5a7f3c85.k1802; bh=JwKnVo5XKsswcf8zPBJVA/peFJK2nJnYbRdkYwJ9pmo=; b=KAwvtsjydXcJXQ03LlFr85VeK6SW6J2uQZihJMSWviLz2jSL0WhEaS5KLGEfEBOTrv3WvCvORu8Lj2SA8SoWnxg/wb5bGU7zKn0UBO+SnIvoOfOlALhQwOYLJw1BEQHIWD/qsGuQBbAim/Z1LuXa70orz8ffSXJFae5tsUiXySF7pIFql9zbHDVNx9hu2w9XqT8xrB3NdriscqZspbSIjSv3znsQqky4I1zjkCvrb68KbA038eA1QeBg3HrLUVYs Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 10 Feb 2018 18:40:05 -0000 Date: 10 Feb 2018 13:40:04 -0500 Message-ID: From: "John R. Levine" To: "Murray S. Kucherawy" Cc: dmarc@ietf.org In-Reply-To: References: <151806236270.17065.12258796242811833115@ietfa.amsl.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 10 Feb 2018 18:40:09 -0000 Here's some stuff from my EAI authentication draft which it would be nice if you could fold in. In section 1.5, I'd add a section about EAI, pointing to RFCs 6530-2, and saying that in EAI messages, you can have UTF-8 most places you can have text intended for humans, and U-labels anywhere there is a domain name. In section 2.2, for EAI messages, local-part and domain-name are updated per RFC 6532, in that atext and dtext are redefined as UTF-8 which flows through to local-part and domain-name. In 2.5, an EAI Authentication Identifier can be UTF-8. In 2.7.1, an EAI header.d can be UTF-8. This flows through a change to 6376 which removes the advice to turn domains into A-labels in EAI messages. In 2.7.2, an EAI spf.mailfrom can be UTF-8. In 2.7.4, an EAI smtp.auth and smtp.mailfrom and smtp.rcptto can be UTF-8. In 2.7.5, an EAI vbr.md and vbr.mv can be UTF-8. A body.smime-identifier can be UTF-8 if they ever finish updating S/MIME. In section 5, it'd probably be a good idea to remove existing headers where the service identifer would match yours if you turned its A-labels into U-labels. 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 Sun Feb 11 07:45:23 2018 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 1919512421A for ; Sun, 11 Feb 2018 07:45:22 -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 4bi9rmyMlWHh for ; Sun, 11 Feb 2018 07:45:20 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 6252C1241FC for ; Sun, 11 Feb 2018 07:45:20 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id q194so17295957lfe.13 for ; Sun, 11 Feb 2018 07:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CVZL4kKXzlDglTV2sHoR9XzFf9sVTioSCRr2eUO5gIc=; b=oy4YI+GL2QEw/aI8SSYggdC+iF7UuWBFU+1Y5fSWFkHwE/e4eQ6bCnDosLmNMn34c3 9HH2694hZ0/+/++yAtKUwjV+Vs219VS6LUtySwBczLCX/o9eYi0WrC5oMTQHZgrkc3Po kqf8PbCYnh69mD7hCJBLnRuT3cqJqj0fp6eXmTpxzbfnZoZfhHHhz7tOh8Tb92SZBzvt z8A111ghnUOnJZorwMlkZukzOrg8c7ZAxr+nefiXSNzVly/CIzQok11g1BUlRgNXG8O7 vFKOCCEDmjoipxqKyYG3jbaxyzP4WWb/D9elvbGBSMrDVrRC6hoiFDnd0HKHi+wQ1ynS NBdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CVZL4kKXzlDglTV2sHoR9XzFf9sVTioSCRr2eUO5gIc=; b=Uio0TxIAh/iVbw1iPPpbkbedDxVUkC7JCQEtLkAb/NvXlGY4nNNKNr6mlXCt7cj2w8 opnUPDFwbhLDxkjBS2q+SqFyZFmYlJkBQ2sykv1s9Wx0Hvfw9Ijn2WCP2Z1nYG/lSpRC Xx4nKqb0Vatf63cpXCzMEbL61o6TbMTg3p1Ugeq6sHBXWHW31Kizc1d7C0ihoNIlUGQX 6cI2F7AZx2tVYUKVOXPr1aP/KtsuO4kAXe7TpozVPlpsMJl1I9Wh0F+lHNZM1SD08DEY 2xsQ6AMVra+xELX1CfvGqvL8ZYyUiCiDPaYRVlmKUeJqtXTUnv1Vknx17zdLpgqPJrv4 3k7w== X-Gm-Message-State: APf1xPA9we3C1aY9sqCPNadcQi4qJCBc8kXC0sVt+SZdBJHHtgNDdZr/ 025W6N9tuBExJxYtY8sIiZ9D4bcI/yJUhtt+U18GmQ== X-Google-Smtp-Source: AH8x227A3S26rGkeoWOZhgoEWSSGC0HKCiNTJfdNHG0bEr3BRF9liAu6OKxjieESC+1r8AVD1foiaDfw2M9LKVAVmb4= X-Received: by 10.25.224.17 with SMTP id x17mr5763786lfg.91.1518363918607; Sun, 11 Feb 2018 07:45:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.66.79 with HTTP; Sun, 11 Feb 2018 07:45:17 -0800 (PST) In-Reply-To: References: <151806236270.17065.12258796242811833115@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sun, 11 Feb 2018 07:45:17 -0800 Message-ID: To: "John R. Levine" Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="f403045ea4fa022b4d0564f1a687" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 11 Feb 2018 15:45:22 -0000 --f403045ea4fa022b4d0564f1a687 Content-Type: text/plain; charset="UTF-8" On Sat, Feb 10, 2018 at 10:40 AM, John R. Levine wrote: > Here's some stuff from my EAI authentication draft which it would be nice > if you could fold in. > [...] Is this stuff in scope for this working group? This feels a bit like feature creep. Or should your draft just modify this one instead of RFC7601? The changes are so small that this could go through pretty quickly. -MSK --f403045ea4fa022b4d0564f1a687 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Feb 10, 2018 at 10:40 AM, John R. Levine <johnl@iecc= .com> wrote:
Here's some stuff from my EAI a= uthentication draft which it would be nice if you could fold in.
[...]
=C2=A0
Is this stuff in scope for this wor= king group?=C2=A0 This feels a bit like feature creep.

Or should you= r draft just modify this one instead of RFC7601?=C2=A0 The changes are so s= mall that this could go through pretty quickly.

-MSK
=
--f403045ea4fa022b4d0564f1a687-- From nobody Sun Feb 11 08:11:44 2018 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 DD8841241FC for ; Sun, 11 Feb 2018 08:11: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, 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=kitterman.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 HVznnfzoB1r9 for ; Sun, 11 Feb 2018 08:11:40 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DBE1201F2 for ; Sun, 11 Feb 2018 08:11:40 -0800 (PST) Received: from [10.202.16.43] (mobile-166-170-30-78.mycingular.net [166.170.30.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 67675C4019E; Sun, 11 Feb 2018 10:11:39 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1518365499; bh=ISVgzgb56BAcfSO4beNCYk25ISVLK3l1UtpyVZ1DpQU=; h=Date:In-Reply-To:References:Subject:To:From:From; b=xR2rapaHqeBpFvM+qwC2igArmI6R+XGObM3B8nH1seG+0wR/l43ZHafEcSsCI7tuc noJBLE3PLPOj3zhSI23YgR01zDzo/ArFeySU5ITnlXlSkvegwTTWb1YzkDXVrFfRZJ bNpOGXRhMJjIMrzIka05av0nKnLfV64XizttOlP8= Date: Sun, 11 Feb 2018 16:10:53 +0000 In-Reply-To: References: <151806236270.17065.12258796242811833115@ietfa.amsl.com> 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: <4BDAFC42-E150-428E-A67F-751C3CD0963D@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 11 Feb 2018 16:11:43 -0000 On February 8, 2018 5:11:48 AM UTC, "Murray S=2E Kucherawy" wrote: >On Wed, Feb 7, 2018 at 7:59 PM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories=2E >> This draft is a work item of the Domain-based Message Authentication, >> Reporting & Conformance WG of the IETF=2E >> >> Title : Message Header Field for Indicating Message >> Authentication Status >> Author : Murray S=2E Kucherawy >> Filename : draft-ietf-dmarc-rfc7601bis-00=2Etxt >> Pages : 48 >> Date : 2018-02-07 >> >> 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=2E 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=2E >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker=2Eietf=2Eorg/doc/draft-ietf-dmarc-rfc7601bis/ >> >> There are also htmlized versions available at: >> https://tools=2Eietf=2Eorg/html/draft-ietf-dmarc-rfc7601bis-00 >> https://datatracker=2Eietf=2Eorg/doc/html/draft-ietf-dmarc-rfc7601bis-0= 0 >> > >Et voila=2E If you go to the "History" tab and request a diff from the >individual -00 to the working group -00, you can see all of the changes >made relative to RFC7601=2E Basically it loosens up the language about >what >categories of things can be recorded, makes the ABNF changes requested, >and >guts some stuff copied from RFC7601 that doesn't need to be there for >this >version because it describes registry changes that were already made by >that RFC=2E > >Let me know if I missed anything=2E My recollection is that last time around for what became 7601, we collecte= d all the Section 6 information into a single location since that would be = the reference in the registry=2E It seems odd to me to carry a normative r= eference to historic RFCs, including the one that this obsoletes=2E Maybe it would be better to change this to updates 7601, rather than obsol= etes=2E Then Section 6 turns into no IANA actions and there can be a singl= e normative reference to 7601=2E As usual, I confess I don't always follow all the nuance of IETF specifica= tion management, so the above may be wrong, but I think the documents liste= d in the IANA registry as the reference should actually describe the releva= nt details=2E Scott K From nobody Sun Feb 11 09:15:18 2018 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 C3D8E124235 for ; Sun, 11 Feb 2018 09:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 b2uA-YtPIZz2 for ; Sun, 11 Feb 2018 09:15:15 -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 EA6A81200F1 for ; Sun, 11 Feb 2018 09:15:14 -0800 (PST) Received: (qmail 24429 invoked from network); 11 Feb 2018 17:15:13 -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=5f6a.5a807a21.k1802; bh=4QZzjl8FuOr4N1BHd/su466R/QUnLc4tXGEXqFw5Ca4=; b=KmMcrrpKwiXWTVbCevJv5exsfk0nmZ++5EVMB2Xp+5E8thzjcTZLdlYFKOun9sydXJ6Yi+xsLOAcx9z/0jD0lxHATdOn5jEKmvUAaoAXHHVmQ9Tkr8JO0fkfAT+KLhei1f1JjsK8lHtlZKwb0DtPtt6aCibWU71LNKP5y4qXQiYRi4sIHVWLP0K6Mul3DIkwqv5WgnF0AOmdqglcpysPMKMEdhszxOQ7sNQD/yYY72upE+7m3Pfob0tyi0ikz/MT Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 11 Feb 2018 17:15:13 -0000 Date: 11 Feb 2018 12:15:14 -0500 Message-ID: From: "John R. Levine" To: "Murray S. Kucherawy" Cc: dmarc@ietf.org In-Reply-To: References: <151806236270.17065.12258796242811833115@ietfa.amsl.com> 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] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 11 Feb 2018 17:15:17 -0000 >> Here's some stuff from my EAI authentication draft which it would be nice >> if you could fold in. > Is this stuff in scope for this working group? This feels a bit like > feature creep. > > Or should your draft just modify this one instead of RFC7601? The changes > are so small that this could go through pretty quickly. I don't feel strongly but it seems gratuitously cruel to future readers to have two updates in a row where we could have published one. 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 Thu Feb 15 22:53:46 2018 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 14C07124217 for ; Thu, 15 Feb 2018 22:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 kpFuO_PkmeS3 for ; Thu, 15 Feb 2018 22:53:38 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2E912025C for ; Thu, 15 Feb 2018 22:53:38 -0800 (PST) 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 mailout03.controlledmail.com (Postfix) with ESMTPSA id 0AEFFC401F9 for ; Fri, 16 Feb 2018 00:53:36 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1518764016; bh=J1ey66hO7fiVia+Q3eu/e2R5yGI62loQQ9Hw6uo3g0w=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TIJEVDJbPqxk6haWh0lZaJetNqd2ZA8SARymzoLA5loTBQOmuLHP4kPqMAWEvuNlz +iUqlo4CYF05itWpuPmDHMbqlP2Xl0Huq0FUxeYiN5JOiJA+O8/RmkxY1Hi1YPUVIY JnbDZF+Eg9Yvmb7DSL+w7rYtezjg/5SxwYHvWh00= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 16 Feb 2018 01:53:37 -0500 Message-ID: <18989911.mvPrCMfLld@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-139-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <151806236270.17065.12258796242811833115@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart17462418.BxVF9I52J8" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 16 Feb 2018 06:53:44 -0000 This is a multi-part message in MIME format. --nextPart17462418.BxVF9I52J8 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Wednesday, February 07, 2018 09:11:48 PM Murray S. Kucherawy wrote: > On Wed, Feb 7, 2018 at 7:59 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. ... > > Let me know if I missed anything. On the DCRUP mailing list there has been discussion about adding header.a (algorithm) to authentication results. This is in addition to the discussion about adding header.s (selector) for ARC. The general view there was that since there is nothing experimental about those DKIM signature elements, it would be better not to have them included in an experimental document. 7601bis seems ideal both technically and timing wise. I'm attaching both a unified diff of the XML and an RFCdiff of my proposed text. Please review, comment, etc. I hope this can be included in 7601bis. Scott K --nextPart17462418.BxVF9I52J8 Content-Disposition: attachment; filename="draft-ietf-dmarc-rfc7601bis-00dsk-from-.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-dmarc-rfc7601bis-00dsk-from-.diff.html" Diff: draft-ietf-dmarc-rfc7601bis-00.txt - draft-ietf-dmarc-rfc7601bis-00dsk.txt
 draft-ietf-dmarc-rfc7601bis-00.txt   draft-ietf-dmarc-rfc7601bis-00dsk.txt 
DMARC Working Group M. Kucherawy DMARC Working Group M. Kucherawy
Internet-Draft Internet-Draft
Obsoletes: 7601 (if approved) February 15, 2018 Obsoletes: 7601 (if approved) February 16, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: August 19, 2018 Expires: August 20, 2018
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-dmarc-rfc7601bis-00 draft-ietf-dmarc-rfc7601bis-00
Abstract Abstract
This document specifies a message header field called Authentication- This document specifies a message header field called Authentication-
Results for use with electronic mail messages to indicate the results Results for use with electronic mail messages to indicate the results
of message authentication efforts. Any receiver-side software, such of message authentication efforts. Any receiver-side software, such
as mail filters or Mail User Agents (MUAs), can use this header field as mail filters or Mail User Agents (MUAs), can use this header field
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2018. This Internet-Draft will expire on August 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
2. Definition and Format of the Header Field . . . . . . . . . . 9 2. Definition and Format of the Header Field . . . . . . . . . . 9
2.1. General Description . . . . . . . . . . . . . . . . . . . 9 2.1. General Description . . . . . . . . . . . . . . . . . . . 9
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 9 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 9
2.3. Property Types (ptypes) and Properties . . . . . . . . . 12 2.3. Property Types (ptypes) and Properties . . . . . . . . . 12
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . 13 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . 13
2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 2.5. Authentication Identifier Field . . . . . . . . . . . . . 14
2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . 15 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . 15
2.7. Defined Methods and Result Values . . . . . . . . . . . . 15 2.7. Defined Methods and Result Values . . . . . . . . . . . . 15
2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 15 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 15
2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 18 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . 20 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . 21
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 20 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . 21 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . 22
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22
4. Adding the Header Field to a Message . . . . . . . . . . . . 23 4. Adding the Header Field to a Message . . . . . . . . . . . . 23
4.1. Header Field Position and Interpretation . . . . . . . . 24 4.1. Header Field Position and Interpretation . . . . . . . . 25
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . 25 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . 26
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. The Authentication-Results Header Field . . . . . . . . . 27 6.1. The Authentication-Results Header Field . . . . . . . . . 28
6.2. "Email Authentication Methods" Registry Description . . . 27 6.2. "Email Authentication Methods" Registry Description . . . 28
6.3. "Email Authentication Methods" Registry Update . . . . . 27 6.3. "Email Authentication Methods" Registry Update . . . . . 28
6.4. "Email Authentication Property Types" Registry . . . . . 27 6.4. "Email Authentication Property Types" Registry . . . . . 28
6.5. "Email Authentication Result Names" Description . . . . . 28 6.5. "Email Authentication Result Names" Description . . . . . 29
6.6. "Email Authentication Result Names" Update . . . . . . . 28 6.6. "Email Authentication Result Names" Update . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 28 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 29
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . 30 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . 31
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 30 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 31
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . 30 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . 31
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 30 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 31
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . 31 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . 32
7.7. Attacks against Authentication Methods . . . . . . . . . 31 7.7. Attacks against Authentication Methods . . . . . . . . . 32
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 31 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 32
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . 31 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . 32
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . 31 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . 32
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 32 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Authentication-Results Examples . . . . . . . . . . 36 Appendix B. Authentication-Results Examples . . . . . . . . . . 37
B.1. Trivial Case; Header Field Not Present . . . . . . . . . 36 B.1. Trivial Case; Header Field Not Present . . . . . . . . . 37
B.2. Nearly Trivial Case; Service Provided, but No B.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 37 Authentication Done . . . . . . . . . . . . . . . . . . . 38
B.3. Service Provided, Authentication Done . . . . . . . . . . 37 B.3. Service Provided, Authentication Done . . . . . . . . . . 39
B.4. Service Provided, Several Authentications Done, Single B.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.5. Service Provided, Several Authentications Done, Different B.5. Service Provided, Several Authentications Done, Different
MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . 39 MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.6. Service Provided, Multi-tiered Authentication Done . . . 41 B.6. Service Provided, Multi-tiered Authentication Done . . . 42
B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 43 B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 44
Appendix C. Operational Considerations about Message Appendix C. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 44 Authentication . . . . . . . . . . . . . . . . . . . 45
Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 45 Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 46
Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 47 Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This document describes a header field called Authentication-Results This document describes a header field called Authentication-Results
for electronic mail messages that presents the results of a message for electronic mail messages that presents the results of a message
authentication effort in a machine-readable format. The intent of authentication effort in a machine-readable format. The intent of
the header field is to create a place to collect such data when the header field is to create a place to collect such data when
message authentication mechanisms are in use so that a Mail User message authentication mechanisms are in use so that a Mail User
Agent (MUA) and downstream filters can make filtering decisions and/ Agent (MUA) and downstream filters can make filtering decisions and/
or provide a recommendation to the user as to the validity of the or provide a recommendation to the user as to the validity of the
skipping to change at page 16, line 49 skipping to change at page 16, line 49
permerror: The message could not be verified due to some error that permerror: The message could not be verified due to some error that
is unrecoverable, such as a required header field being absent. A is unrecoverable, such as a required header field being absent. A
later attempt is unlikely to produce a final result. later attempt is unlikely to produce a final result.
DKIM results are reported using a ptype of "header". The property, DKIM results are reported using a ptype of "header". The property,
however, represents one of the tags found in the DKIM-Signature however, represents one of the tags found in the DKIM-Signature
header field rather than a distinct header field. For example, the header field rather than a distinct header field. For example, the
ptype-property combination "header.d" refers to the content of the ptype-property combination "header.d" refers to the content of the
"d" (signing domain) tag from within the signature header field, and "d" (signing domain) tag from within the signature header field, and
not a distinct header field called "d". not a distinct header field called "d". In addition to previous
registrations, this document adds DKIM properties for "a"
(cryptographic algorithm used to sign the message) and "s"
(selector). These new properties will be used to aid receiver post-
verification processing. As an example, [RFC8301] obsoleted use of
the rsa-sha1 algorithm in DKIM, so it is important to be able to
distinguish such signatures from rsa-sha256. See Table 1.
The ability to report different DKIM results for a message with The ability to report different DKIM results for a message with
multiple signatures is described in [RFC6008]. multiple signatures is described in [RFC6008].
[DKIM] advises that if a message fails verification, it is to be [DKIM] advises that if a message fails verification, it is to be
treated as an unsigned message. A report of "fail" here permits the treated as an unsigned message. A report of "fail" here permits the
receiver of the report to decide how to handle the failure. A report receiver of the report to decide how to handle the failure. A report
of "neutral" or "none" preempts that choice, ensuring the message of "neutral" or "none" preempts that choice, ensuring the message
will be treated as if it had not been signed. will be treated as if it had not been signed.
skipping to change at page 27, line 40 skipping to change at page 28, line 21
Header field name: Authentication-Results Header field name: Authentication-Results
Applicable protocol: mail ([MAIL]) Applicable protocol: mail ([MAIL])
Status: Standard Status: Standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [this document] Specification document(s): [this document]
Related information: none Related information: none
6.2. "Email Authentication Methods" Registry Description 6.2. "Email Authentication Methods" Registry Description
No changes are made to this registry. IANA is requested to make the following additions to this registry.
+--------+--------+--------+----------+-------------+--------+------+
| METHOD | REF | PTYPE | PROPERTY | VALUE | STATUS | VERS |
+--------+--------+--------+----------+-------------+--------+------+
| dkim | [DKIM] | header | a | DKIM | active | 1 |
| | | | | signing | | |
| | | | | algorithm | | |
| dkim | [DKIM] | header | s | DKIM | active | 1 |
| | | | | selector | | |
+--------+--------+--------+----------+-------------+--------+------+
Table 1: DKIM Property Additions
6.3. "Email Authentication Methods" Registry Update 6.3. "Email Authentication Methods" Registry Update
No changes are made to this registry. No changes are made to this registry.
6.4. "Email Authentication Property Types" Registry 6.4. "Email Authentication Property Types" Registry
[RFC7410] created the "Email Authentication Property Types" registry. [RFC7410] created the "Email Authentication Property Types" registry.
No changes are made to this registry. However, it should be noted No changes are made to this registry. However, it should be noted
skipping to change at page 35, line 27 skipping to change at page 36, line 27
[PRA] Lyon, J., "Purported Responsible Address in E-Mail [PRA] Lyon, J., "Purported Responsible Address in E-Mail
Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006, Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006,
<http://www.rfc-editor.org/info/rfc4407>. <http://www.rfc-editor.org/info/rfc4407>.
[RFC7410] Kucherawy, M., "A Property Types Registry for the [RFC7410] Kucherawy, M., "A Property Types Registry for the
Authentication-Results Header Field", RFC 7410, DOI 10 Authentication-Results Header Field", RFC 7410, DOI 10
.17487/RFC7410, December 2014, .17487/RFC7410, December 2014,
<http://www.rfc-editor.org/info/rfc7410>. <http://www.rfc-editor.org/info/rfc7410>.
[RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage
Update to DomainKeys Identified Mail (DKIM)", RFC 8302,
DOI 10.17487/RFC8301, January 2018,
<http://www.rfc-editor.org/info/rfc8301>.
[RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- [RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid-
Since Header Field and SMTP Service Extension", RFC 7293, Since Header Field and SMTP Service Extension", RFC 7293,
DOI 10.17487/RFC7293, July 2014, DOI 10.17487/RFC7293, July 2014,
<http://www.rfc-editor.org/info/rfc7293>. <http://www.rfc-editor.org/info/rfc7293>.
[SECURITY] [SECURITY]
Rescorla, E. and B. Korver, "Guidelines for Writing RFC Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, DOI 10 Text on Security Considerations", BCP 72, RFC 3552, DOI 10
.17487/RFC3552, July 2003, .17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>. <http://www.rfc-editor.org/info/rfc3552>.
skipping to change at page 46, line 44 skipping to change at page 47, line 44
o RFC 7208 uses all-lowercase result strings now, so adjusted prose o RFC 7208 uses all-lowercase result strings now, so adjusted prose
accordingly. accordingly.
o Updated list of supported methods, and mentioned the registries o Updated list of supported methods, and mentioned the registries
immediately below. immediately below.
o Mentioned that when a local-part is removed, the "@" goes with it. o Mentioned that when a local-part is removed, the "@" goes with it.
o Referred to RFC 7328 in the "iprev" definition. o Referred to RFC 7328 in the "iprev" definition.
o Added IANA registration for DKIM "a" and "s" properties
o Corrected the "smime-part" prose. o Corrected the "smime-part" prose.
o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the
Received fields. Received fields.
o Made minor editorial adjustments. o Made minor editorial adjustments.
Appendix E. Acknowledgments Appendix E. Acknowledgments
The author wishes to acknowledge the following individuals for their The author wishes to acknowledge the following individuals for their
 End of changes. 14 change blocks. 
46 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart17462418.BxVF9I52J8 Content-Disposition: attachment; filename="7601xml.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="7601xml.patch" --- draft-ietf-dmarc-rfc7601bis-00.xml 2018-02-15 21:35:04.515992669 -0500 +++ draft-ietf-dmarc-rfc7601bis-00dsk.xml 2018-02-16 01:47:03.348119368 -0500 @@ -918,17 +918,27 @@ result. - DKIM results are reported using a ptype - of "header". The property, however, - represents one of the tags found in the - DKIM-Signature header field rather than - a distinct header field. For example, - the ptype-property combination "header.d" - refers to the content of the "d" - (signing domain) tag from within the - signature header field, and not a distinct - header field called "d". - + DKIM results are reported using a ptype + of "header". The property, however, + represents one of the tags found in the + DKIM-Signature header field rather than + a distinct header field. For example, + the ptype-property combination "header.d" + refers to the content of the "d" + (signing domain) tag from within the + signature header field, and not a distinct + header field called "d". In addition to + previous registrations, this document adds + DKIM properties for "a" (cryptographic + algorithm used to sign the message) and + "s" (selector). These new properties will + be used to aid receiver post-verification + processing. As an example, + obsoleted use of + the rsa-sha1 algorithm in DKIM, so it is + important to be able to distinguish such + signatures from rsa-sha256. See . The ability to report different DKIM results for a message with multiple signatures is described in . @@ -1666,7 +1676,35 @@
- No changes are made to this registry. + IANA is requested to make the following additions to + this registry. + + + METHOD + REF + PTYPE + PROPERTY + VALUE + STATUS + VERS + + dkim + + header + a + DKIM signing algorithm + active + 1 + + dkim + + header + s + DKIM selector + active + 1 +
+ + + Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) + + + The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms. + + + + @@ -2924,6 +2972,9 @@ Referred to RFC 7328 in the "iprev" definition. + + Added IANA registration for DKIM "a" and "s" + properties Corrected the "smime-part" prose. --nextPart17462418.BxVF9I52J8-- From nobody Fri Feb 16 19:49:50 2018 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 59651126CF6 for ; Fri, 16 Feb 2018 19:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Hvvzrvtb; dkim=pass (1536-bit key) header.d=taugh.com header.b=NWbjx1It 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 22MR-DOo3Al4 for ; Fri, 16 Feb 2018 19:49:46 -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 6A217124235 for ; Fri, 16 Feb 2018 19:49:46 -0800 (PST) Received: (qmail 60825 invoked from network); 17 Feb 2018 03:49:45 -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=ed96.5a87a659.k1802; bh=fHt7/p8zMknoxsqNF943/nr9rTt/zYDI/veHLW3LkA4=; b=HvvzrvtbIQsiGUVhLWwh7ubBf0r4Y3XYe5bJPtpn4BhzOa/SU0AEseWJdARA9MaTkS6QTRUEhQm2G6fd4BlMJ3fRsmTSWlxDXdZGqU8KbN8/gdGux/1V0x92+qd9JFPm2/mNW7h2VwfarZoUmWGAf7lslc38plKtP5iqZwijHK91oCzsVxJ/rDyXuTAGbpd/oZ8F4Og39Znvi0P4qvmotg8Kln0A/yHR2AKnQQA2VRbLyZcfBOoPLBCw0UxX9gvc 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=ed96.5a87a659.k1802; bh=fHt7/p8zMknoxsqNF943/nr9rTt/zYDI/veHLW3LkA4=; b=NWbjx1ItbSlbogNdC5XnI58X3onzkJvMrfwl6aRH4wXFvODWZE2cPMdnWC+jWYywl2ZAJEe3m4lXbraGZ6gUObJIeLR0M5Earf8tDHsP4Bluj1dJ3zITC/etWzUllcSmL+u0i2UmE/Yg4QkPZrwvVyS/dpote2VZC9Dnr3+Ndxogfi7B75l0jpsrYQ5p0aLkFFeEUtwmseVoB9Lga5rkFk2WDoa2hibUv4+LR4tekwp646CxAEcdSBSJ1zqMNcVJ 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 Feb 2018 03:49:44 -0000 Received: by ary.qy (Postfix, from userid 501) id AEBF71BA7FAA; Fri, 16 Feb 2018 22:49:44 -0500 (EST) Date: 16 Feb 2018 22:49:44 -0500 Message-Id: <20180217034944.AEBF71BA7FAA@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] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 17 Feb 2018 03:49:48 -0000 In article you write: >Et voila. If you go to the "History" tab and request a diff from the >individual -00 to the working group -00, you can see all of the changes >made relative to RFC7601. Basically it loosens up the language about what >categories of things can be recorded, makes the ABNF changes requested, and >guts some stuff copied from RFC7601 that doesn't need to be there for this >version because it describes registry changes that were already made by >that RFC. > >Let me know if I missed anything. Seems fine, although I've long found 7601 one of the most mysterious RFCs ever published. The IANA registry says that there is a dkim header.i property defined in RFC7601, but the only place it appears in 7601 is in examples in Appendix B. Section 2.4 says that a "policy" property is how you report a local policy that overrides the regular result, but I see policy=reject in reports about DMARC where it's just copying the p= from the _dmarc record. Is that right? If not, where if anywhere should it be reported? Can we add DKIM header.a here, please? R's, John From nobody Sun Feb 18 05:04:22 2018 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 E591C124B17 for ; Sun, 18 Feb 2018 05:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfVWIhAsHL3W for ; Sun, 18 Feb 2018 05:04:19 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 5625C120724 for ; Sun, 18 Feb 2018 05:04:19 -0800 (PST) Received: from [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90.107) id 1enOdc-0006fE-Vl for dmarc@ietf.org (return-path ); Sun, 18 Feb 2018 13:04:17 +0000 To: dmarc@ietf.org References: <151666124833.29662.2027318647035746565@ietfa.amsl.com> From: Jeremy Harris Message-ID: Date: Sun, 18 Feb 2018 13:04:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151666124833.29662.2027318647035746565@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-11.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 18 Feb 2018 13:04:21 -0000 On 22/01/18 22:47, internet-drafts@ietf.org wrote: > Title : Authenticated Received Chain (ARC) Protocol - Section 6 gives verifier actions for evaluating the chain state, but they do not cover the need for the arc.oldest-pass value required by 5.2.1. - 5.2.1 mentions a header.s but does not say to which header it relates. -- Cheers, Jeremy From nobody Sun Feb 18 09:22:14 2018 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 7BA421201F2 for ; Sun, 18 Feb 2018 09:22: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, 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 w4G-8Q_qdKLV for ; Sun, 18 Feb 2018 09:22:10 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 4C2A31200B9 for ; Sun, 18 Feb 2018 09:22:10 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id q194so10087848lfe.13 for ; Sun, 18 Feb 2018 09:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9pm0XyYml1EzxrkP4ZrGlIItJveHHYZxKSsuDC2tjwg=; b=ZRytUbgahq/81R4awoh7v/KKTpccWzEXGElOG6pB/0yXpKiJviD2QsBy9jlTVNKfNM Vm9uBq3yVppLgb2pSYT/rPuh84Wigs1951zF6ddIe79tZHcijrg+BcOMAy+JQyYvzPmw fN6vyqh83iLlnfqalx1YdjP/im9PWsIxQfWfg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9pm0XyYml1EzxrkP4ZrGlIItJveHHYZxKSsuDC2tjwg=; b=ldQ+vP45krvIqjAyuhCf0uqQDMV8c31I1GN2XwKbX/ATtRuqpM4OGngLnvpkx3NHjF XVs46idtzJqXE1zHL+Tuu9upf3XUAb7CJp3fntJDj4i2daJRzlZxJK2W53vhx0QxkZA9 5fXbTeA+rK038wTPkHBE/IGMPl7H6zFM5ffiPGGsjtCzHmHq8qGXOOzlm86ssvEumZR+ KQcyViBNGuiO+RIBn24szLtP41kXehvyjOJPk4Ft6GFJJ7S/AGpReRD4s4ntKnYT9S12 2SaeBfMKozfFx3CVXyzrsIyABBuVExbOsCkbIztIftM5w/2xnwvYhphloaRW/OSDQOLV Z25A== X-Gm-Message-State: APf1xPBatBWGS/X1MiHf7768DhhMheEd9hGcAMwuZIh0qUPa+3698I+f N37L84S4pln2zKqo0E7Z53gJx9Bz+m997HYLj3OXxG8x X-Google-Smtp-Source: AH8x226zc7w60SHoA/q0vKp0GV1cGdPYRl/LRD1Xn/dFXEhrpl/LWsR/1GdmEsLVAdXnXfr+nPzzAQrISILdD4Eyol8= X-Received: by 10.25.217.69 with SMTP id q66mr8432725lfg.62.1518974528246; Sun, 18 Feb 2018 09:22:08 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.81.206 with HTTP; Sun, 18 Feb 2018 09:22:07 -0800 (PST) In-Reply-To: <5A6F42F3.2070700@isdg.net> References: <151666124833.29662.2027318647035746565@ietfa.amsl.com> <5A68ABEC.4060501@isdg.net> <5A6F42F3.2070700@isdg.net> From: "Kurt Andersen (b)" Date: Sun, 18 Feb 2018 09:22:07 -0800 X-Google-Sender-Auth: 203mI7J1xJMsIS_YOichjGQ3cDc Message-ID: To: Hector Santos Cc: Brandon Long , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c063c102dec0605657fd17e" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-11.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 18 Feb 2018 17:22:12 -0000 --94eb2c063c102dec0605657fd17e Content-Type: text/plain; charset="UTF-8" On Mon, Jan 29, 2018 at 7:51 AM, Hector Santos wrote: > > I believe the intent of the domain is his published policy record. If a > restrictive policy is published, the receiver should not presume it did not > mean it. When failure is detected, the author domain with a restrictive > policy is given the world permission to treated it harshly. That also makes the extremely strong presumption that the publisher of said record is both authorized to make those representations, and full aware of the effects across the entire usage space that will be affected by the record. As RFC7960 and lots of pain with SPF has demonstrated, such coincidences are painfully rare - to the point where, as much as I would like to think otherwise, I have to assume incompetence. --Kurt --94eb2c063c102dec0605657fd17e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jan 29, 2018 at 7:51 AM, Hector Santos <hsantos@isdg.net>= wrote:

I believe the intent of the domain is his published policy record.=C2=A0 If= a restrictive policy is published, the receiver should not presume it did = not mean it.=C2=A0 When failure is detected, the author domain with a restr= ictive policy is given the world permission to treated it harshly.

That also makes the extremely strong presumption th= at the publisher of said record is both authorized to make those representa= tions, and full aware of the effects across the entire usage space that wil= l be affected by the record. As RFC7960 and lots of pain with SPF has demon= strated, such coincidences are painfully rare - to the point where, as much= as I would like to think otherwise, I have to assume incompetence.

--Kurt=C2=A0

--94eb2c063c102dec0605657fd17e-- From nobody Mon Feb 19 12:42:30 2018 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 21DB81200B9 for ; Mon, 19 Feb 2018 12:42:29 -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=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 j1FlZE3wESps for ; Mon, 19 Feb 2018 12:42:27 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 46F9E1205D3 for ; Mon, 19 Feb 2018 12:42:27 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id f136so1210395lff.8 for ; Mon, 19 Feb 2018 12:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vg8bwfYiSX/D7e2ASfZAbE7FWn5fvVeAhozbEGpCr8Y=; b=cnma61PAK3dkYfDm8EY+giAxxDdiXYwqjvjwCfsMtmJZclQs3HEm3z7T1CQh4CF+1v QaowZ21C1tAQT9fa/whNPZa0D1hldGgD/AFzBo3slqX7ybQs1SOzy8QBZ21W5opWbfgJ PVVERXW5hZalU/qdA9f/FxadNGnMyQy5LR6+fH6mny105ZWsirHi6VZgg8puHL+tcQzQ 6xC+6owAucWxA3tyFqn1rNf6x8GTbv7xc5X92Ea5JOeMmL5GzACEDttsesyAPPGtZz1i hEEg/1Yq3HAsDp2tdlaQKVwskVb9p3Bp+zNuA/j6UQkr3WH6eFwcUSOu3A7lbAbpK7jJ 3mSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vg8bwfYiSX/D7e2ASfZAbE7FWn5fvVeAhozbEGpCr8Y=; b=oiPJOktkKSYSCQgIvDdEpQiuDxEVa6FCqmje/AqKkJjuUPOPPh8CpZwBaaWc+nKrS+ LQKelYSdQt8i0aSzwVuyGfIQsMJRuA+MnFbxQmbAVpAlWk5/JYEoJFbnvx3rsnG0+eBC 3bURdrXbErQLb3RHBA4q7pjEZTSQ8J5gAQbVe2PAMryT/EADjEhThbk2uvAKKTp5nJc2 KsNnkRoLq55h5qkhEDhxZDm1Pw29Jc5p/ZXvKNFKT/N8/oFVaSdXB7p5i5rc8L+4xGqh hnxfuA1r5zL1zhaaE7zb/Cm817MGfXDfSTO3Eg6HDfddc3PQ1CGUQYlB+N9UT2Tr/Bqo OhQw== X-Gm-Message-State: APf1xPA1l/MH77CQVoNzoibQzuGNb1yZ4Mspl4bsQAPXh5/IKeBnsKaX 8WGYiJ2OEV/v3UpOi5MfAREqx2KPJ9TLlo2KZrYKbfkK X-Google-Smtp-Source: AH8x227AbEuxXBv2GPvmZJdHYoZHK8dCbE/uOtOXpYICHgs02EASxje8Dyb52BB0HKbkUmwsYQme+QT+Q3Sc2ErZO3g= X-Received: by 10.46.58.12 with SMTP id h12mr8668798lja.2.1519072945380; Mon, 19 Feb 2018 12:42:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.66.82 with HTTP; Mon, 19 Feb 2018 12:42:24 -0800 (PST) In-Reply-To: <20180217034944.AEBF71BA7FAA@ary.qy> References: <20180217034944.AEBF71BA7FAA@ary.qy> From: "Murray S. Kucherawy" Date: Mon, 19 Feb 2018 20:42:24 +0000 Message-ID: To: John Levine Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="089e082f543c4c2305056596bbe4" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 19 Feb 2018 20:42:29 -0000 --089e082f543c4c2305056596bbe4 Content-Type: text/plain; charset="UTF-8" On Sat, Feb 17, 2018 at 3:49 AM, John Levine wrote: > Seems fine, although I've long found 7601 one of the most mysterious RFCs > ever published. > Why's that? (And why wasn't this mentioned when 7601 or any of its antecedents was in last call? No errata?) > The IANA registry says that there is a dkim header.i property defined > in RFC7601, but the only place it appears in 7601 is in examples in > Appendix B. > 7601 says: DKIM results are reported using a ptype of "header". The property, however, represents one of the tags found in the DKIM-Signature header field rather than a distinct header field. So "header.d" means the d= tag, "header.i" means the i= tag, etc. Those are the only two identifiers DKIM evaluates, so they're the only ones that were ever registered. 7601bis loosens the language about what's appropriate to send downstream, from being only authenticated identifiers to also allowing other related stuff that downstream agents might want to use or log. That means things like "s" and "a" are now in play. Section 2.4 says that a "policy" property is how you report a local > policy that overrides the regular result, but I see policy=reject in > reports about DMARC where it's just copying the p= from the _dmarc > record. Is that right? If not, where if anywhere should it be > reported? > That would be "dmarc=fail policy.dmarc-rules=arc-failure", where "dmarc-rules" and "arc-failure" are things the rejecting operator is free to invent for its own records. -MSK --089e082f543c4c2305056596bbe4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Feb 17, 2018 at 3:49 AM, John Levine <johnl@taugh.c= om> wrote:
Seems fine, although I've long fo= und 7601 one of the most mysterious RFCs ever published.

Why's that?=C2=A0 (And why wasn't this mentioned = when 7601 or any of its antecedents was in last call?=C2=A0 No errata?)
= =C2=A0
The IANA registry says that there is a dkim header.i property defined
in RFC7601, but the only place it appears in 7601 is in examples in
Appendix B.

7601 says:
   DKIM results are reported using a ptype of "header&=
quot;.  The property,
   however, represents one of the tags found in the DKIM-Signature
   header field rather than a distinct header field.
So "header.= d" means the d=3D tag, "header.i" means the i=3D tag, etc.= =C2=A0 Those are the only two identifiers DKIM evaluates, so they're th= e only ones that were ever registered.

7601bis loosens th= e language about what's appropriate to send downstream, from being only= authenticated identifiers to also allowing other related stuff that downst= ream agents might want to use or log.=C2=A0 That means things like "s&= quot; and "a" are now in play.

Section 2.4 says that a "policy" property is how you report a loc= al
policy that overrides the regular result, but I see policy=3Dreject in
reports about DMARC where it's just copying the p=3D from the _dmarc record.=C2=A0 Is that right?=C2=A0 If not, where if anywhere should it be reported?

That would be "dmarc=3Df= ail policy.dmarc-rules=3Darc-failure", where "dmarc-rules" a= nd "arc-failure" are things the rejecting operator is free to inv= ent for its own records.

-MSK
--089e082f543c4c2305056596bbe4-- From nobody Mon Feb 19 13:37:59 2018 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 7D9AE1242EA for ; Mon, 19 Feb 2018 13:37:57 -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 (1536-bit key) header.d=iecc.com header.b=bD3Op4CV; dkim=pass (1536-bit key) header.d=taugh.com header.b=ngL+h1NX 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 wQkXcwdni03B for ; Mon, 19 Feb 2018 13:37:55 -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 AC89A12422F for ; Mon, 19 Feb 2018 13:37:55 -0800 (PST) Received: (qmail 80540 invoked from network); 19 Feb 2018 21:37:54 -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=13a9a.5a8b43b2.k1802; bh=Z5C8FznWTdQG17NcS/as2+3kHrfnLYglJLuwvfSSlyY=; b=bD3Op4CVgqdcdHy4wNVYxyXnyG8SBAquGfSqKHlqN9dTjmsKH4VYGzYENOgLIqn7TBXNJ1XEeRA2YfwlSGbcsHGXzNtkcqlUBK422YabPhoF+aWzAVNr7IW9eYyeFLhZfCBR/Jr0Le6hmI9qOqRO6hCcK/Mlq7SujhxSz6f3zfaZ+1NHr+EuAtE5cHT3xzrDCsXQG2UTb/mnMreSEJhjrRkiapMksNwCAgwKpPWQGBUY0kZw9T5d1N84ViaOISj1 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=13a9a.5a8b43b2.k1802; bh=Z5C8FznWTdQG17NcS/as2+3kHrfnLYglJLuwvfSSlyY=; b=ngL+h1NX+Z9eSv1fEY5/B30Q8MmrXRjmpyMVNhlS/vstfoQthV14g/Nvt7QwajiPsYk2ZVcFKM5TQf4lZ+f7IPNwSt0yPF4OoUqyHPX9nVwqsJ7Zy1wO07Sj5W+v2WPt7QGvnPegluSep/0nAjzMEZTfK/t22rWhQm4d8sNboSg2Y70eW1vuGC+NeffQyVgiXemgNNy1HmCrG8LjCAAc/c783I6fh+cBFnYtVRwq0BoDhFy5cn1tHUN7qXcgHdkF Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 19 Feb 2018 21:37:53 -0000 Date: 19 Feb 2018 13:37:52 -0800 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: dmarc@ietf.org In-Reply-To: References: <20180217034944.AEBF71BA7FAA@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] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 19 Feb 2018 21:37:58 -0000 On Mon, 19 Feb 2018, Murray S. Kucherawy wrote: >> Seems fine, although I've long found 7601 one of the most mysterious RFCs >> ever published. > > Why's that? (And why wasn't this mentioned when 7601 or any of its > antecedents was in last call? No errata?) I admit I could have been paying more attention. > 7601 says: > > DKIM results are reported using a ptype of "header". The property, > however, represents one of the tags found in the DKIM-Signature > header field rather than a distinct header field. > > So "header.d" means the d= tag, "header.i" means the i= tag, etc. Those > are the only two identifiers DKIM evaluates, so they're the only ones that > were ever registered. I get that, but I don't see where they were registered. I just see the examples in the RFC. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Feb 19 14:28:31 2018 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 2D523126BF6 for ; Mon, 19 Feb 2018 14:28:30 -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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=OvbBl5m6; dkim=pass (1024-bit key) header.d=kitterman.com header.b=EkF5U1vk 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 BsOubf9UF_xW for ; Mon, 19 Feb 2018 14:28:29 -0800 (PST) Received: from relay02.kitterman.com (unknown [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF1A1241FC for ; Mon, 19 Feb 2018 14:28:29 -0800 (PST) Received: from relay02.kitterman.com (localhost [127.0.0.1]) by relay02.kitterman.com (Postfix) with ESMTP id BEA9F7FF3E for ; Mon, 19 Feb 2018 17:28:28 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=simple/relaxed; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201802; t=1519079308; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=r22Blj/EYGUNOL2xC2M1+lIYhENe4/52djv6PQQ1x58=; b=OvbBl5m6ILHDNLsLL2FQQAWqDam/MwE8p62U9pZ86DKVttvOLsyrb30m BiBRfMU8xK/7vJnFEMFC+25bb/jzAg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201802r1; t=1519079308; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=r22Blj/EYGUNOL2xC2M1+lIYhENe4/52djv6PQQ1x58=; b=EkF5U1vkCJigtiDjaaSHahAQXaJtm37T+SwYp9X+DGOQDtM7xyEsoNXh Wvj9T8ZKmZSdHnevq2QCYxhEySF7Um48ZeeV0Pmx4K9SPj3I2alHT7KFUV PnCJIlvsFHA5jCjRc9VDcGkCfE9TYJ0Vw5sEo02xZadKP69zvfCsDI+pM= Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by relay02.kitterman.com (Postfix) with ESMTPS id 88FC87FEBA for ; Mon, 19 Feb 2018 17:28:28 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 19 Feb 2018 17:28:28 -0500 Message-ID: <2619955.zlbnIm20JI@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-139-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20180217034944.AEBF71BA7FAA@ary.qy> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 19 Feb 2018 22:28:30 -0000 On Monday, February 19, 2018 08:42:24 PM Murray S. Kucherawy wrote: > On Sat, Feb 17, 2018 at 3:49 AM, John Levine wrote: > > Seems fine, although I've long found 7601 one of the most mysterious RFCs > > ever published. > > Why's that? (And why wasn't this mentioned when 7601 or any of its > antecedents was in last call? No errata?) > > > The IANA registry says that there is a dkim header.i property defined > > in RFC7601, but the only place it appears in 7601 is in examples in > > Appendix B. > > 7601 says: > > DKIM results are reported using a ptype of "header". The property, > however, represents one of the tags found in the DKIM-Signature > header field rather than a distinct header field. > > So "header.d" means the d= tag, "header.i" means the i= tag, etc. Those > are the only two identifiers DKIM evaluates, so they're the only ones that > were ever registered. > > 7601bis loosens the language about what's appropriate to send downstream, > from being only authenticated identifiers to also allowing other related > stuff that downstream agents might want to use or log. That means things > like "s" and "a" are now in play. Any feedback on the patch I sent you to add them to 7601bis? Scott K From nobody Tue Feb 20 12:49:40 2018 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 E2C5012AAB6 for ; Tue, 20 Feb 2018 12:49:38 -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=eudaemon.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 6FhhN8Ct97jx for ; Tue, 20 Feb 2018 12:49:37 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 44109120725 for ; Tue, 20 Feb 2018 12:49:37 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id c19so18135873qtm.7 for ; Tue, 20 Feb 2018 12:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=VObgksdDUYAikGDoL2F4f3L7VRdW+BGG5Ad05FwKrAc=; b=MySFJHD6qA8+BWVaR67Z6KwfEZL0p37tb/EHPmN1Bw7o5V6NocFfElmohWmYvVmq0o luE7i5a1/AJ+jGd5R3ng41AslKIFHGZ2nb5gdxZWEDII31i8fiG93vmQC9bEp7uB9JXT bvouEnJvyqbPIAWgBfNBsJ4T+bI+sVn45aIFc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=VObgksdDUYAikGDoL2F4f3L7VRdW+BGG5Ad05FwKrAc=; b=bky+K7QQrNnHRakHpAF2mtJjVRL//qxjRRDFf4fJZzu0Jo9kHYJq39+6Q3qC+uB6ik GGwsUmMt9c4paARImeSGAdlBzyympX7AjJ1Uc/VLN94bUmnbxIWvbnyFy7FOidd/eIj3 AHuHgu4tjcCREBDoCCNhR0OTvFE4LxGdJ070Prlv5LwzE8X5XOSBb8RpXQeJu+xfAP7y 93qaNPH84RNdnvRH+eD9hn2U5Cqipmd7X55Vv9pNbVYT/2kWuFYy2KR8wyxRCf5TAZXn uM4m44ww58Om1gH1OLyXiuH2KRvwD46Wn33d1566MFiqGTXFcocWOdUymFi1kfyPblN0 bA0g== X-Gm-Message-State: APf1xPD+hLaUUbb4WscY6O+vMLs0ksNtWyDAiNO3MpqMOdJTo42ijQWd gHFqdIXV3eGPaeBv5kjlBfBpRF41k6I= X-Google-Smtp-Source: AH8x227pw3z0wn+3XcImVaMY+iEmZhQq1kll1R+VCFHTzMs1W3ONYtBzF4Jc9IeSOhTn9Elg5ECBnw== X-Received: by 10.200.57.8 with SMTP id s8mr1594805qtb.328.1519159775935; Tue, 20 Feb 2018 12:49:35 -0800 (PST) Received: from [172.16.19.145] ([50.226.7.216]) by smtp.gmail.com with ESMTPSA id t200sm15417684qke.72.2018.02.20.12.49.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Feb 2018 12:49:35 -0800 (PST) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <6B2B2198-FDDD-4673-A9DB-88B8BC227C35@eudaemon.net> Date: Tue, 20 Feb 2018 12:49:33 -0800 To: dmarc X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [dmarc-ietf] report from NL on need for DMARC standards track - open invite for participation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 20 Feb 2018 20:49:39 -0000 Hi all, last week I met with some of the folks involved with the Dutch = Standardisation Forum. I'm reporting on a real need for the DMARC = Working Group to make progress. The Netherlands would like to include DMARC into their list of = compulsory open standards. Also, in order for the European Commission to = recognize DMARC as a standard, the technical specification needs to move = from being an individual submission to being a standards track document. It's pretty clear that the state of the DMARC working group is now = blocking some facets of the adoption of DMARC. Our small group of = dedicated volunteers are currently tackling ARC. We might need more = people to be involved as our current volunteers can only do so much. This is an open invitation to participate to move ARC faster, and to = invite colleagues to get more people involved in the mainline work. Tell = a friend! If you know of people who would like to participate in this Working = Group but are otherwise shy, please reach out to any of the chairs and = they'll/we'll be happy to facilitate. From nobody Sat Feb 24 23:41:44 2018 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 DBAE6126BF6 for ; Sat, 24 Feb 2018 23:41:42 -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 w0HNNCdID1oA for ; Sat, 24 Feb 2018 23:41:36 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 4217E1204DA for ; Sat, 24 Feb 2018 23:41:35 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id v9so17919794lfa.11 for ; Sat, 24 Feb 2018 23:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Eu1qP/SPq3BN4djmrc7NzaCkmDyVXlWZ0ZMoDpoClzE=; b=SbCYZDMzruFGHjFPac1dIhzIhrw2QCk4BLEoSi5AMSonHRkxuvdFUhwp8ullDPBhRq XEUreKvQUPIywO3ykr84sXWe5oIj52Yz5N1FTBJGimYZ6HdJggqsxBz2Nwv0mPrSn0xq BzB5J7j55Fw5bzdadaSf+i6E3e1bEMN0oSqsjPHHnuxoqJvUepCseBidr8D9PCvcinsN 9v8znNHrbfgbYXASWHBThCD3vEGDgHq/fuEmAzZzVsoTkKUeWWWUMBHc7qBpHfRhEVay 1XvDMT7+9CsaiWPcDBb5V/wJhcLw15dD4T0k+rgIl6jx+gJKm8vfDZ+olwBZvDxNGrh0 +bag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Eu1qP/SPq3BN4djmrc7NzaCkmDyVXlWZ0ZMoDpoClzE=; b=qhr/U0/Z6lwSAmYnT53qY7OjdChqVfDYW43WSDhT6pjk3coFNNdNjmIBb3stjjbbgy oHl+Ms82aG/kXCwfujl3whOQzE5ykAxlMdZPrsKv0Gp9C0iwr4fURhV2ZWLf7aZMh54Q Mdp6PGwIb7hRzPwHzGR3sV0pUC0b2OxgFWqq5KVQXX2ADcpls+InlfvW4pNzxYhrZJIJ mE5MfmrQbyOFPCX7GlNZBjc4WEAuTSDO/XFoDCEN/zqgiWwxqqhAPAyXBEJw5fV0zKVY oYSfVHhWa8AXtrjOIwG3vShONhthX2q1ziqhM8YrJc/rbSTlccH/PDqmmWIGs870VHnL jItA== X-Gm-Message-State: APf1xPAocfkTOsFuO03FHUdCOeelMAwWXMFa4r+9gBrzmFcNbDcZ7muR IkwLXuD4Uok47x1vCt2RmAlsge6fpjWCVrhacW8fHw== X-Google-Smtp-Source: AG47ELv1GTkQ3hQOMR9t0dDEg2jZluKqcO+GYO9GmBZuxX/UQ2cHJOnSgkUi/I8lx0zZv7Cpgqm9FVXF75vQ7hVpSYQ= X-Received: by 10.46.75.17 with SMTP id y17mr474693lja.10.1519544494154; Sat, 24 Feb 2018 23:41:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.66.82 with HTTP; Sat, 24 Feb 2018 23:41:33 -0800 (PST) In-Reply-To: <2619955.zlbnIm20JI@kitterma-e6430> References: <20180217034944.AEBF71BA7FAA@ary.qy> <2619955.zlbnIm20JI@kitterma-e6430> From: "Murray S. Kucherawy" Date: Sat, 24 Feb 2018 23:41:33 -0800 Message-ID: To: Scott Kitterman Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="f403045ea6bccb68a00566048553" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 25 Feb 2018 07:41:43 -0000 --f403045ea6bccb68a00566048553 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 19, 2018 at 2:28 PM, Scott Kitterman wrote: > > 7601bis loosens the language about what's appropriate to send downstream, > > from being only authenticated identifiers to also allowing other related > > stuff that downstream agents might want to use or log. That means things > > like "s" and "a" are now in play. > > Any feedback on the patch I sent you to add them to 7601bis? > Not yet. As you've seen on the list (I think), I believe adding "a" or any EAI changes are actually out of scope for this WG, but it seems silly to spin up two different 7601bis efforts, one for what DMARC needs and one for other stuff. (I'm willing to do it in two steps, but I'm probably the only one who doesn't mind.) I talked to Barry at M3AAWG about this and I'm waiting to hear back from Alexey about how we should handle the requests. -MSK --f403045ea6bccb68a00566048553 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 19, 2018 at 2:28 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
> 7= 601bis loosens the language about what's appropriate to send downstream= ,
> from being only authenticated identifiers to also allowing other relat= ed
> stuff that downstream agents might want to use or log.=C2=A0 That mean= s things
> like "s" and "a" are now in play.

Any feedback on the patch I sent you to add them to 7601bis?

Not yet.=C2=A0 As you've seen on the list = (I think), I believe adding "a" or any EAI changes are actually o= ut of scope for this WG, but it seems silly to spin up two different 7601bi= s efforts, one for what DMARC needs and one for other stuff.=C2=A0 (I'm= willing to do it in two steps, but I'm probably the only one who doesn= 't mind.)

I talked to Barry at M3AAWG about this and I'm wai= ting to hear back from Alexey about how we should handle the requests.
<= br>
-MSK
--f403045ea6bccb68a00566048553-- From nobody Tue Feb 27 11:56:01 2018 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 870411201FA for ; Tue, 27 Feb 2018 11:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mixtur.onmicrosoft.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 R5NyR-zKCgUd for ; Tue, 27 Feb 2018 11:55:58 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0056.outbound.protection.outlook.com [104.47.33.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2322A12D7EC for ; Tue, 27 Feb 2018 11:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mixtur.onmicrosoft.com; s=selector1-bunker5-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wbr+l+kHmohbjd/SXs7pJ40xPROVNFmgBvLNXyOmicQ=; b=A/R4QmQUyVCwtCPDWcQUOK8OwrIEko+qkZ9dW2jmSLyXmTqhe+mZQcVuJ7dgl2eGRESD0/LcIluW5SsCGUyUM7zYUWpCOmCdAG/KPGvcOL3aC9LDbOi/eeqWsNePcqHZAPDfn9TXSZb4rC0iABX45I0VyRJqhWv/alQEOQGbYzU= Received: from CY4PR0401MB3651.namprd04.prod.outlook.com (52.132.100.31) by CY4PR0401MB3620.namprd04.prod.outlook.com (52.132.100.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Tue, 27 Feb 2018 19:55:53 +0000 Received: from CY4PR0401MB3651.namprd04.prod.outlook.com ([fe80::1993:a695:21d6:dd5a]) by CY4PR0401MB3651.namprd04.prod.outlook.com ([fe80::1993:a695:21d6:dd5a%13]) with mapi id 15.20.0506.028; Tue, 27 Feb 2018 19:55:53 +0000 From: Mark Eissler To: "dmarc@ietf.org" Thread-Topic: DMARC report format syntax error in ARC draft-10 section 9.3 Thread-Index: AQHTsATMgSwBohtuH0CIe8Mo8Cj7Cg== Date: Tue, 27 Feb 2018 19:55:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mark@bunker5.com; x-originating-ip: [206.169.144.132] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0401MB3620; 6:YDeawkRA1jDIJvpG4xKY+Y1dhVXA7GBOmltNZ9XDdhavj1cVm73YKrvInotRMSpeH36xUCx+fG3EpX3K/91ljnbfZZIYSAGaVxrQlwM10oTpZowvR2kFCShMjUDyRSfPeBy7WWSrVedimmwe+knAn8bjbTfyDaf9pB7m3LnxcCXGIm60QIsgZcTbANQCBq5JBaLLSRAXCs4cJpPF3KErM5UmqA3t0HD3VzkTXfjLKmRFU2ph5zhaiAYQ0AoM6Du2VB2kixldHVkzgoY038b0WHmfWsBUaxbpzVbTfPkh0stzYT/Ku/nzxR7IEZnH70cUNmoHk8y5OAJlR8m+bxCKLaGS/Z6yHIMJjVIZmMHw6v9cr+02WYSnptrW8BF64a5s; 5:J1sqmaFF3aczTPjsQHsLi76NSEbbgjGaxvkOdlSr3C7+OAnWTXXKCWy+ub2A4qGnVGe7w+4M1uc/G42+3cVVvlrN2Gc/eZTyciFnB9v9JQ12/Y10jCto/vk8XWYPEkyoUgrp28/3/JnqEDjn92yaT5F7BWeZOkTR1O4OxqgOR8I=; 24:Y2VhCOVDx10+YbTfRfOa20wg8ReXLSKW2Pca2pQl0WMF2oKbblHlhyzBUuIucXOm+IbcoaA7luP3Y0Kmu06LfzNDEwwccSLrQHqkcfZDkf0=; 7:gxWiBA6I3AJQl2N6AGe3t3sZ4GGpjCDELpWh6VKZtQWWundD4sULJD1DMKCKJcKDXNNByViSYCGyVVo/DCHbyeUb6Ns8A6+q4sQSA4xC9J+Mckl1IruzQT79c4yfZqkROQWYFGytgd+2xTJK6q9mT02VOyRTOZfgz9nk8TIkvkSK3lX0wW/S1HeQqufnVfLLesZm3bGah5NZy+Miovaeog9yG5WZLzsSDBpEMNgTizJap82Eot8shc3Vx7aSxUF9 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: dd0a6812-653a-4ed6-6cc6-08d57e1c1c23 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR0401MB3620; x-ms-traffictypediagnostic: CY4PR0401MB3620: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211171220733660)(185789414550570); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231220)(944501161)(3002001)(10201501046)(6041288)(20161123564045)(20161123558120)(20161123562045)(2016111802025)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:CY4PR0401MB3620; BCL:0; PCL:0; RULEID:; SRVR:CY4PR0401MB3620; x-forefront-prvs: 05961EBAFC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39830400003)(396003)(346002)(366004)(376002)(199004)(189003)(26005)(55016002)(14454004)(68736007)(5640700003)(9686003)(6306002)(6436002)(5660300001)(2351001)(1720100001)(105586002)(186003)(966005)(316002)(86362001)(66066001)(478600001)(2900100001)(53936002)(53366004)(25786009)(8936002)(6116002)(3846002)(7696005)(7736002)(5250100002)(2906002)(305945005)(1730700003)(97736004)(74316002)(81156014)(8676002)(3660700001)(6506007)(102836004)(6916009)(2501003)(3280700002)(33656002)(81166006)(99286004)(53376002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR0401MB3620; H:CY4PR0401MB3651.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bunker5.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: uVVsG1mXtq5ervyESJ+9Q1BimH+scq3gasOMDZPyfXVUyLq63kjssAvJ110QxUJ7fzCucOPKgfOm2VfF8xakD4tZwNelUzIrhEKWX3i1axvY4nvlh3hVEEKpv2inw/WAKJeSae6lGX6vrWDMyUEr3cIIDLlx61qD/5JnndOTP9o= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bunker5.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd0a6812-653a-4ed6-6cc6-08d57e1c1c23 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2018 19:55:53.7498 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 23596c3a-0c0d-492b-87e1-078e2ca29ed6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0401MB3620 Archived-At: Subject: [dmarc-ietf] DMARC report format syntax error in ARC draft-10 section 9.3 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 19:56:00 -0000 Hi. I met some of the members of this WG at M3AAWG #42 last week. I've been working on implementing several patches to the OpenDKIM, OpenARC,= OpenDMARC milters over the past few weeks as part of my work at Valimail. = I'm currently updating OpenDMARC's reporting to include ARC findings as per= draft-ietf-dmarc-arc-protocol-10 but I've found what looks like a typo in = the example XML report format as provided in section 9.3 of the draft: delivered fail fail source.ip=3D10.0.0.1 local_policy arc=3Dpass ams[2].d=3Dd2.example ams[2].s=3Ds1 as[2].d=3Dd= 2.example as[2].s=3Ds2 as[1].d=3Dd1.example as[1].s=3Ds3 Specifically, the element appears to be incorrect as it contains an e= mbedded element which not only results in invalid XML syntax but = also implies a schema that isn't defined: the value definition (DMARCResult= Type) doesn't provide for the provision of such an element. Furthermore, th= e source IP is already captured in the element--a sibling of . I think a corrected example would be this: delivered fail fail local_policy arc=3Dpass ams[2].d=3Dd2.example ams[2].s=3Ds1 as[2].d=3Dd= 2.example as[2].s=3Ds2 as[1].d=3Dd1.example as[1].s=3Ds3 -mark=20 -- Mark Eissler | mark@bunker5.com |=A0http://about.me/markeissler From nobody Tue Feb 27 15:19:42 2018 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 4A47E12EB2C; Tue, 27 Feb 2018 15:11:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dmarc@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977308230.5200.11185771883282583049.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:22 -0800 Archived-At: Subject: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 101 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 23:11:27 -0000 Dear Barry Leiba, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmarc Session 1 (1:00:00) Monday, Afternoon Session III 1740-1840 Room Name: Richmond/Chelsea/Tower size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: artarea dcrup dispatch iasa20 cfrg jmap mtgvenue saag People who must be present: Ned Freed Barry Leiba Alexey Melnikov Tim Draegen Resources Requested: Special Requests: Chair has to leave Thursday night, so please avoid Friday ---------------------------------------------------------